patchGNU Octave - Patches: patch #9440, Add Flatpak build manifest

 
 

patch #9440: Add Flatpak build manifest

Submitted by:  Alexander Wilms <alexanderw>
Submitted on:  Sun 20 Aug 2017 02:16:01 PM UTC  
 
Category: Core : new featurePriority: 3 - Low
Status: Wont DoPrivacy: Public
Assigned to: NoneOpen/Closed: Closed

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Wed 21 Mar 2018 12:41:57 AM UTC, comment #67:

I think most manifests reside in Flathub only.

And yes, let's close this issue.

Alexander Wilms <alexanderw>
Wed 21 Mar 2018 12:06:16 AM UTC, comment #66:

I could see maintaining the manifest inside the Octave repository itself becoming problematic, but I'm willing to follow whatever community best practices are.

If you want to keep the manifest in Flathub primarily, should we close this patch item and keep discussion of Flatpak packaging on GitHub from now on?

Mike Miller <mtmiller>
Project Administrator
Tue 20 Mar 2018 11:22:55 PM UTC, comment #65:

> Octave 4.4 is imminent (a matter of weeks, if all goes according to plan).


Great! I'll push a new version of the manifest if everything builds fine with updated dependencies and a current Octave tarball.

I wouldn't mind the Flathub manifest being the reference, it would make things easier.

Today, there were a few issues being filed here: https://github.com/flathub/org.octave.Octave/issues
#4 and #7 should be investigated, maybe they resolve themselves after updating to the latest tarball.

> Does Flatpak tooling have a way to do a daily build of an application?


Git sources can point to the tip of a branch by simply not specifying a branch/tag/commit. For archive sources, a workaround with sed would be necessary.

Alexander Wilms <alexanderw>
Tue 20 Mar 2018 11:06:07 PM UTC, comment #64:

Does Flatpak tooling have a way to do a daily build of an application? From a source tarball that may have the same name but different contents (hence the sha26sum is different) every day?

Does one just have to do a sed substitution on a json.in file with the updated sha256sum every time the tarball is built?

Mike Miller <mtmiller>
Project Administrator
Tue 20 Mar 2018 11:04:23 PM UTC, comment #63:

Octave 4.4 is imminent (a matter of weeks, if all goes according to plan).

We should at the very least test building the Flatpak app with the current 4.3 (or 4.4 release candidates) and see if any remaining issues need to be fixed in Octave itself.

Do you still want to see a copy of the manifest in the Octave source distribution? Or will the Flathub copy of the manifest be the canonical copy?

I have renamed the desktop and appstream files to the canonical reverse DNS names in the Octave 4.3 development branch. Were there any other issues that you remember or know of that need to be fixed in Octave itself at the moment?

Mike Miller <mtmiller>
Project Administrator
Sun 15 Oct 2017 09:46:42 AM UTC, comment #62:

I added the JDK extension and successfully tested it with

javaObject()
javachk()
usejava() and
msgbox().

Alexander Wilms <alexanderw>
Tue 10 Oct 2017 04:56:11 AM UTC, comment #61:

Using the extension works now, I had to add "export PATH=$PATH:/usr/lib/sdk/gfortran-62/bin && " to the make commands.

Alexander Wilms <alexanderw>
Sun 08 Oct 2017 04:19:28 PM UTC, comment #60:

I had tried the gfortran extension some time ago, but at that time I misunderstood how they work. Now I've tried it again, but got stuck. When using an Sdk extension, there's another "root directory" with bin, lib, share etc folders available under /usr/lib/Sdk/gfortran.

The extension also contains two scripts, install.sh (which copies the shared object files to /app/lib ) and use.sh (which adds /usr/lib/Sdk/gfortran/bin to PATH).

But somehow, PATH doesn't change when running use.sh and copying the binary to /app/bin results in a linker error when building OpenBLAS.

I've asked how one is supposed to use the extension here [0], but haven received any reply so far.

https://github.com/flatpak/freedesktop-sdk-images/issues/44

Alexander Wilms <alexanderw>
Thu 05 Oct 2017 12:55:17 AM UTC, comment #59:

Hm, I didn't know about the extensions before.

Can we also use the "org.freedesktop.Sdk.Extension.gfortran-62" extension to avoid having to build gfortran from gcc ourselves?

Mike Miller <mtmiller>
Project Administrator
Fri 29 Sep 2017 02:03:31 PM UTC, comment #58:

An OpenJDK extension has been created [0], which we can use by simply adding "sdk-extensions": ["org.freedesktop.Sdk.Extension.openjdk-9"] to the manifest. As soon as Octave 4.4 is released, the GitHub repo could be created.

[0] https://github.com/flathub/flathub/pull/115

Alexander Wilms <alexanderw>
Sun 24 Sep 2017 01:05:38 PM UTC, comment #57:

The builds don't fail as early now, but they still fail. If there's demand, I'd look into it further, but I think for now the x86 builds are enough.

Alexander Wilms <alexanderw>
Fri 22 Sep 2017 03:02:09 PM UTC, comment #56:

Please try the OpenBLAS conditionals as "env" instead of "make-args", that is supported in the arch-dependent section right? I think the OpenBLAS makefile is written to pick up environment variables.

Mike Miller <mtmiller>
Project Administrator
Fri 22 Sep 2017 02:46:19 PM UTC, comment #55:

The make-args can't be conditional yet, but I've talked to Alexander Larsson about it, and for now I'd just exclude ARM builds.

Alexander Wilms <alexanderw>
Thu 21 Sep 2017 04:25:50 PM UTC, comment #54:

Both ARM builds didn't get very far, 32-bit failed on GCC and 64-bit failed on OpenBLAS.

I would be interested in looking into it if there was a failure in the Octave build itself, but if it's too hard to get the prerequisites working, it's up to you. Most of these things are built successfully in distros, so I don't see any theoretical problems, just effort.

For OpenBLAS, the make args have to be conditional, DYNAMIC_ARCH=1 for x86, TARGET=ARMV6 or TARGET=ARMV7 or TARGET=ARMV8 for the ARM platforms.

For GCC, the option '-with-float=hard' needs to be added for 32-bit ARM only.

Mike Miller <mtmiller>
Project Administrator
Thu 21 Sep 2017 12:53:27 PM UTC, comment #53:

Thanks for your help as well. Not every project is interested in providing Flatpaks.

Here are the CI builds: https://flathub.org/builds/#/builders/1/builds/422

Both ARM builds failed. Do you think it's worth to try to fix the builds? Otherwise we could exclude them using a flathub.json file: https://github.com/flathub/com.play0ad.zeroad/blob/master/flathub.json

Alexander Wilms <alexanderw>
Thu 21 Sep 2017 06:46:53 AM UTC, comment #52:

After pulling your latest and patching according to comment #49, I can build from scratch on a completely clean Debian stable system with Flatpak 0.8.5 installed. The host system also needs elfutils installed to build the gfortran module, that seems ok to me.

Thanks for all your effort on this so far. I'm looking forward to seeing the CI build results.

I'll try to go through outstanding .desktop and .appdata patches and get those files updated in the development version.

Mike Miller <mtmiller>
Project Administrator
Wed 20 Sep 2017 04:35:48 AM UTC, comment #51:

One more thing to report. With the "autoreconf" command in the octave build rules, a full TeX and GNU Texinfo installation are required on the host to build Octave from the source tarball. If I remove the "shell" block entirely, then it is possible to build without these. Since this is not included in the build manifest, I think we should either add dependencies on GNU Texinfo and TeX Live, or delete the autoreconf command.

I deleted it and was able to build on a minimal Debian stable system with only Flatpak installed.

Mike Miller <mtmiller>
Project Administrator
Wed 20 Sep 2017 01:34:38 AM UTC, comment #50:

The Flathub revierwe said he'd prefer a more readable manifest for Flathub, even if it can't be built using the LTS version. Like you said, we could use your work-around in the copy that's kept in the Octave hg repo and use the simple buildsystem in the Flathub version. As soon as Flatpak 1.0 is released, we can copy the Flathub manifest into the Octave repo.

Alexander Wilms <alexanderw>
Wed 20 Sep 2017 12:19:12 AM UTC, comment #49:

I'm able to build qscintilla with the following change

This treats the sed and qmake commands like a sort of bootstrap, and then creates a shim Makefile at the top-level to let the normal "make" and "make install" commands work. This allows it to succeed for me with Flatpak 0.8.7.

Mike Miller <mtmiller>
Project Administrator
Tue 19 Sep 2017 11:47:03 PM UTC, comment #48:

Sure enough, with Flatpak stable, I still get

Mike Miller <mtmiller>
Project Administrator
Tue 19 Sep 2017 10:44:43 PM UTC, comment #47:

Thanks for the changes, I've added them to the PR.

Alexander Wilms <alexanderw>
Tue 19 Sep 2017 10:41:08 PM UTC, comment #46:

No builds have yet been triggered. One of the admins comments with a link when that's been done, like here: https://github.com/flathub/flathub/pull/95#issuecomment-330676381

Alexander Wilms <alexanderw>
Tue 19 Sep 2017 10:38:40 PM UTC, comment #45:

Can you give a pointer to the builds as well? I thought it would be easy to find the builds for a PR from the github project but I can't. I dove through the buildbot interface but can't find anything relating to Octave in the output.

Mike Miller <mtmiller>
Project Administrator
Tue 19 Sep 2017 10:31:04 PM UTC, comment #44:

Your latest revision still gives me some small problems. I am able to build with Flatpak 0.9.11 with the following changes (annotations below each diff change)

  • This just looks like a typo, should be "url" instead of "path".
  • I still want to avoid external patch files if at all possible, and the tiny changes made in this patch can be done easily with sed, see below
  • No need to link an alias for the library here, Octave finds it under its original name on the default branch
  • Inline substitutions on qscintilla.pro to replace the external patch file

I also don't like that we are relying on an external file for the glu module. If you want that to be an external module when it is merged into flathub, that's fine, but I would rather have the entire file be standalone within Octave's original copy of the manifest.

Able to build with Flatpak 0.9.11, testing with Flatpak 0.8.7 next. I had thought that buildsystem==simple would not work at all with stable, I think that's the problem I had before when I was using 0.8.7, I'll post again when I get that far.

Mike Miller <mtmiller>
Project Administrator
Sun 17 Sep 2017 07:03:35 PM UTC, comment #43:

Here's the pull request: https://github.com/flathub/flathub/pull/102

Alexander Wilms <alexanderw>
Sun 17 Sep 2017 05:44:16 PM UTC, comment #42:

Yes that sounds fair to me, please link to it here.

I haven't had time to test your latest changes locally.

Mike Miller <mtmiller>
Project Administrator
Sun 17 Sep 2017 02:47:32 PM UTC, comment #41:

In order to make some more progress, I could create a pull request for https://github.com/flathub/flathub, so test builds on arm, aarch64, x86 and x86_64 could be triggered.

I'd add a comment to not merge this yet, would that be alright?

Alexander Wilms <alexanderw>
Fri 08 Sep 2017 03:07:05 AM UTC, comment #40:

Right now I can't think of any other issues.

I updated the manifest in the GitHub repo:

  • I changed the QScintilla module, it should build with Flatpak stable now.
  • FFTW is built with --enable-threads
Alexander Wilms <alexanderw>
Thu 07 Sep 2017 03:57:29 PM UTC, comment #39:

Sure.

Can you help identify remaining issues?

Here's my list:

  • unable to build Qscintilla with Flatpak stable
  • build FFTW with multi-threading support (--enable-threads)
  • rename desktop meta files to org.octave.Octave, apply other pending patches
  • Java is the only remaining missing dependency
Mike Miller <mtmiller>
Project Administrator
Thu 07 Sep 2017 04:53:32 AM UTC, comment #38:

Should I upload a .flatpak and ask people on the maintainers mailing list to test it?

Alexander Wilms <alexanderw>
Fri 01 Sep 2017 02:00:33 AM UTC, comment #37:

I added your changes: https://github.com/Alexander-Wilms/flathub/tree/org.octave.Octave

OpenJDK is a little more complicated, since it consists of many archives, which have to be extracted into the directory created from the first archive: http://www.linuxfromscratch.org/blfs/view/svn/general/openjdk.html

Alexander Wilms <alexanderw>
Fri 01 Sep 2017 01:20:47 AM UTC, comment #36:

Oh, and you also have a duplicated "arpack-ng" section which you have mislabeled as "sundials".

Mike Miller <mtmiller>
Project Administrator
Fri 01 Sep 2017 01:10:46 AM UTC, comment #35:

Sure, please take a look at adding OpenJDK 8 if you want to.

Please also include some of my changes. I'm attaching a diff to your latest, but I can also explain the highlights:

  • delete cups from the manifest
  • build ghostscript with --disable-cups
  • build Octave with --disable-silent-rules for verbose logging
  • no need to pass prefix=/app to Octave's make install
  • run autoreconf with -fi -I m4 to force files to be updated and to silence warning about the m4 directory

Also please run your file through "jq -M ." for proper formatting.

(file #41707)

Mike Miller <mtmiller>
Project Administrator
Fri 01 Sep 2017 01:00:35 AM UTC, comment #34:

Some of the libraries I had added before needed to be configured in order to be picked up by Octave. Now, only Java is missing. Should that be included?

https://raw.githubusercontent.com/Alexander-Wilms/flathub/org.octave.Octave/org.octave.Octave.json

Alexander Wilms <alexanderw>
Thu 31 Aug 2017 03:47:41 PM UTC, comment #33:

I configured suitesparse to not use lapack and dropped lapack.

(file #41704)

Alexander Wilms <alexanderw>
Wed 30 Aug 2017 09:12:33 PM UTC, comment #32:

I got a successful build by deleting the cups module entirely and adding --disable-cups to ghostscript's configure arguments.

Mike Miller <mtmiller>
Project Administrator
Wed 30 Aug 2017 07:22:55 PM UTC, comment #31:

Yeah, curious, because you even included a patch to try to force qrupdate to use OpenBLAS (which also shouldn't be necessary by passing make the right args). FFTW definitely has no dependency on any BLAS library.

Mike Miller <mtmiller>
Project Administrator
Wed 30 Aug 2017 07:03:17 PM UTC, comment #30:

Yes, I accidentally reverted to an older OpenBLAS version.
Lapack was required by any or all of these: fftw, qrupdate and suitesparse

Maybe there are some configure options to use OpenBLAS instead.

Alexander Wilms <alexanderw>
Wed 30 Aug 2017 04:25:38 PM UTC, comment #29:

I will be testing removing cups completely by building ghostscript with --disable-cups.

I think you lost one of your updates, your latest file is back to OpenBLAS 0.2.19.

I hope that lapack is not really needed since we already have OpenBLAS.

At this point I am mostly interested in cleaning up second-order dependencies.

I am still hoping you or I can find a way to make Qscintilla work with Flatpak stable. Or maybe this takes long enough that 0.9 or 1.0 become stable.

Mike Miller <mtmiller>
Project Administrator
Mon 28 Aug 2017 11:05:06 PM UTC, comment #28:

I added glpk. I'm just not sure how much of the dependencies can be cleaned up, since Octave Forge packages might still need it.

(file #41692)

Alexander Wilms <alexanderw>
Sun 27 Aug 2017 03:19:02 AM UTC, comment #27:

I've added hdf5, lapack, fftw, qrupdate and suitesparse.

(file #41674, file #41675, file #41676)

Alexander Wilms <alexanderw>
Thu 24 Aug 2017 07:08:20 PM UTC, comment #26:

Flatpak applications can only have a single dependency/runtime. So one doesn't need to have the Freedesktop runtime installed, but as you said, both Sdks/runtimes and Octave need to be rebuilt in the case of a change to the underlying Sdk/runtime. Otherwise, one would basically still have classical dependencies, with all its advantages and disadvantages.

Alexander Wilms <alexanderw>
Thu 24 Aug 2017 07:07:36 PM UTC, comment #25:

I'm trying to clean up files in the various builds, particularly cups, but I'm finding the post-install and cleanup directives to be very counterintuitive and quirky.

The big benefit of cleanup AIUI is it only deletes files that are installed by a particular module, so you can be a bit liberal and delete "/bin/*". The downside of cleanup is it only deletes files, you can't recursively delete a directory by name.

OTOH post-install lets me delete anything I want, but now I discover that it operates on the union of the current build and all previous builds. So if I try to delete "/app/bin/" in the cups post-install, I have lost gfortran by the time I get to building Octave.

Now trying to use a combination of the two, cleanup to delete files that are in directories shared with other modules, like bin, and post-install to clean up directories that are entirely owned by cups, like /app/lib/cups/.

Mike Miller <mtmiller>
Project Administrator
Thu 24 Aug 2017 06:14:11 PM UTC, comment #24:

I was curious about the way the flatpak runtimes layer on each other. So if a bug or security issue is fixed in the Freedesktop runtime, it doesn't automatically propagate to the layers that are built on it? The KDE runtime will have to be rebuilt, and then the Octave app will also have to be rebuilt?

In flatpak 0.9 they have fixed it to respect errors from appstream-compose: https://github.com/flatpak/flatpak/pull/673

Mike Miller <mtmiller>
Project Administrator
Wed 23 Aug 2017 11:47:31 PM UTC, comment #23:

The Freedesktop Sdk had finished building 5 hourse ago [0], and I think no new build of the KDE Sdk has since been triggered.

Just for reference, here's the output of my build:

[0] https://github.com/flatpak/flatpak/issues/947#issuecomment-324427357

Alexander Wilms <alexanderw>
Wed 23 Aug 2017 11:34:54 PM UTC, comment #22:

I ran flatpak update, but I still get the following (shown with some context):

The "Error loading AppData file" becomes a "WARNING: appstream-compose failed", and the build completes anyway.

I'm attaching the manifest I'm using, with Qscintilla removed and with some changes to make the cups build work cleanly with the stable version of flatpak.

I'm also using a standard 2-space indent, no tabs, as output by "jq ."

(file #41634)

Mike Miller <mtmiller>
Project Administrator
Wed 23 Aug 2017 09:10:51 AM UTC, comment #21:

I've talked to Alex Larsson, the main Flatpak dev and he backported that appstream-glib patch to the Freedesktop Sdk 1.6, which in turn is used by the KDE Sdk 5.9, after that Octave should build without a warning or error.

Alexander Wilms <alexanderw>
Mon 21 Aug 2017 11:57:18 PM UTC, comment #20:

Could be helpful to compare the output.

When I used org.kde.Platform as the runtime, I wasn't able to install packages from Octave-Forge. With the Sdk, I could install the control package and a quick test (s=tf(s); g=1/s) succeeded.

Alexander Wilms <alexanderw>
Mon 21 Aug 2017 11:51:47 PM UTC, comment #19:

It did print a warning or error message about project_group, but the build completed and I can use the app. I'll save the log next time I try to build it.

Octave runs for me just fine, minus the built-in editor because I skipped Qscintilla. All built-in tests pass, except for those that are skipped because of missing libraries for now.

Did you intentionally make the runtime dependency on org.kde.Sdk instead of org.kde.Platform because Octave includes the ability to compile code and expects compilers and libraries to be installed? That seems fair to me. I can compile and run a trivial oct file in the app.

Mike Miller <mtmiller>
Project Administrator
Mon 21 Aug 2017 09:47:58 PM UTC, comment #18:

Doesn't the project_group entry cause an appstream-compose issue for you? I've got libappstream-glib 0.7.1 installed, which should allow any string, but it flatpak-builder halts anyway at the last stage.

Alexander Wilms <alexanderw>
Mon 21 Aug 2017 08:15:55 PM UTC, comment #17:

Thanks, that worked.

I've updated OpenBLAS to version 0.2.20, so the build will not fail on Kaby Lake CPUs any more.

(file #41607)

Alexander Wilms <alexanderw>
Mon 21 Aug 2017 06:09:56 PM UTC, comment #16:

Octave itself is required to build the source distribution, so that would be

I always have a build of Octave, so I haven't tried 'make dist' on a fresh checkout. So try 'make all' first and see if that solves it.

Mike Miller <mtmiller>
Project Administrator
Mon 21 Aug 2017 05:06:41 PM UTC, comment #15:

How did you create the tarball?

I ran
dnf builddep octave
./bootstrap
./configure
make dist

with the tip of the default branch being checked out, but it fails due to some functions and variables not being declared in a scope.

Alexander Wilms <alexanderw>
Mon 21 Aug 2017 04:01:32 AM UTC, comment #14:

Changes I needed to make to cups:

This is because 0.8.7 also does not support the "no-make-install" option, so I had to add all these extra workarounds to support a full build.

Mike Miller <mtmiller>
Project Administrator
Mon 21 Aug 2017 03:59:19 AM UTC, comment #13:

I was able to build completely by removing qscintilla completely, and by also changing the cups module so it builds correctly with 0.8.7. With that I can install and run the app.

Mike Miller <mtmiller>
Project Administrator
Mon 21 Aug 2017 03:17:16 AM UTC, comment #12:

The 'simple' build system is available in flatpak 0.9.7

I've tried this module, but the make install still tries to copy files to /usr/... instead of /app/...

{
"name": "qscintilla",
"no-autogen": true,
"subdir": "Qt4Qt5",
"sources":
[
{
"type": "archive",
"url": "https://sourceforge.net/projects/pyqt/files/QScintilla2/QScintilla-2.10/QScintilla_gpl-2.10.tar.gz",
"sha256": "16be30577bc178470936c458551f2512cc068aff6e7a7de6ed244e28c045f6ec"
},
{
"type": "shell",
"commands":
[
"cd Qt4Qt5 && qmake \"QT_INSTALL_HEADERS=/app/include\" \"QT_INSTALL_LIBS=/app/lib\" qscintilla.pro"
]
}
],
"post-install": ["ln -s /app/lib/libqscintilla2_qt5.so /app/lib/libqscintilla2-qt5.so"]
},

Alexander Wilms <alexanderw>
Mon 21 Aug 2017 02:12:02 AM UTC, comment #11:

I get the following error when trying to build your latest recipe:

I would guess this requires a newer version of Flatpak than I am using. Is there a way to make this work with 0.8.7?

Mike Miller <mtmiller>
Project Administrator
Mon 21 Aug 2017 12:38:51 AM UTC, comment #10:

The source archive for Octave should probably be octave-4.3.0+.tar.{gz,bz2,lz,xz}. The source distribution is best produced by Octave itself running the "make dist" target. This is the way the mxe-octave build system is set up to accept a prepared Octave source distribution.

You shouldn't need --enable-shared --disable-static --disable-docs. The --with-lapack= option can be removed, just use --with-blas=openblas. Also use --prefix=/app as a configure option rather than as a make argument.

Mike Miller <mtmiller>
Project Administrator
Sun 20 Aug 2017 10:07:17 PM UTC, comment #9:

I had to specify EPSTOOL_BASE as part of the make-install-args.

Now I'm facing the problem, that all three kinds of archives of the tip listed here[0] cause an error when trying to extract them via the command line. I get either a "bad zipfile offset" or an "unexpected end of file".

[0] http://hg.savannah.gnu.org/hgweb/octave

(file #41602)

Alexander Wilms <alexanderw>
Sun 20 Aug 2017 09:10:33 PM UTC, comment #8:

I removed all of the patches, so you only need the manifest and an archive of the tip of the repository. Since the sha256 hash seems to change every I download it, you'll need to adapt the "sha256" entry in the octave module.

One issue that I wasn't able to fix is overriding the EPSTOOL_ROOT and EPSTOOL_BASE variables of the makefile. Somehow, the make-args get ignored.

(file #41601)

Alexander Wilms <alexanderw>
Sun 20 Aug 2017 05:45:16 PM UTC, comment #7:

I agree, I think we should focus on making this work with the default branch so that Octave 4.4.0 can be built as a Flatpak out of the box.

I'll take care of renaming the appdata and desktop files. I'll also try to get some time to get a Flatpak development environment set up so I can actually test this. Then maybe we can look at iterating on adding more libraries like SuiteSparse and FFTW.

Mike Miller <mtmiller>
Project Administrator
Sun 20 Aug 2017 05:31:34 PM UTC, comment #6:

Yeah, I was glad to get it running.

The process right now for new releases is to update the manifest hosted on GitHub. Gnome projects currently host their manifests in the own git repositories at gnome.org, and have a copy of them in their Flathub repo:

https://git.gnome.org/browse/polari/tree/flatpak
https://github.com/flathub/org.gnome.Polari

Since there's still a lot of work to do, it might be make sense to only work on providing a more complete package of the default branch for now.

Alexander Wilms <alexanderw>
Sun 20 Aug 2017 05:08:28 PM UTC, comment #5:

Thanks for the log. There are quite a lot of missing features here, but this shows a decent start proof of concept.

So are updates done with manual syncs to the github repo then?

PCRE - on the default branch we are now using pkg-config to set up PCRE, so that's fixed already.

Mike Miller <mtmiller>
Project Administrator
Sun 20 Aug 2017 04:24:35 PM UTC, comment #4:

Yes, I can help maintain the list of dependencies.

Pulling in the manifest from the upstream repository is not yet implemented, but I think the plan was to allow the maintainers to choose a VCS tag or archive and the path to the manifest.

Alexander Wilms <alexanderw>
Sun 20 Aug 2017 04:12:08 PM UTC, comment #3:
  • Does the directory have to be called "flatpak"?
    • No, the .json manifest and the patches can be placed anywhere
  • Why do you have to remove "<project_group>GNU</project_group>"? I know this has come up before but I still don't understand it.
  • Can't EPSTOOL_BASE be passed on the make command line instead of patching?
    • I'll have to take another look at that.
  • Isn't there a way to call qmake or make on qscintilla to avoid patching?
    • I'll have to take another look at that.
  • Why does the huge block of pcre tests have to be removed from configure? If the tests are failing can we fix that a different way?
    • The configure step failed with "gcc: error: unrecognized command line option '--should-not-have-used-/usr/bin/pcre-config'" Alexander Larsson, the main Flatpak dev said "Means it tried to use pcre-config to find pcre, but yocto kinda neuters all this. So you need to use pkg-config instead. Alternatively, I believe you can pass some --with-pcre=... kinds of flags to avoid the autodetection."

This https://github.com/01org/luv-yocto/blob/master/meta/recipes-devtools/swig/swig/0001-configure-use-pkg-config-for-pcre-detection.patch#L7 looks like that this issue might be fixed in a future version of PCRE

  • Should we name our desktop and appdata files to be "org.octave.Octave" instead of "www.octave.org-octave"?
    • Yes, and ideally, the desktop, appdata and icon files should all use the same ID.
  • I think the name of the application should be "org.octave.Octave"
    • I'll change this
  • I don't think the LIBGL_ALWAYS_SOFTWARE=1 environment variable is appropriate to set unconditionally. Some users might need it depending on their * graphics hardware but it should not be necessary for everyone.
    • I'll fix this. I've only run it in a VM so far, so that might be the reason why I needed that env variable. I would be helpful if someone could test it on a real machine
  • OpenBLAS should be built with DYNAMIC_ARCH=1, not TARGET=PRESCOTT
    • I'll fix this
  • Why are you downloading epstool from fedoraproject.org?
  • Do you have an example build log that you can share with us to show what the configure results look like?
    • I'm building it right now, I can upload the log later
Alexander Wilms <alexanderw>
Sun 20 Aug 2017 03:43:58 PM UTC, comment #2:

My biggest concern is that we will basically have to maintain this list of dependencies and URLs and checksums now.

Will you help maintain this list so that it is updated and does not become stale?

Let's say this becomes part of Octave and the Flatpak repository accepts our application. If something needs to be fixed in the manifest, does the repository pull from changes in hg or does it use the manifest that was in the most recent release tarball?

Mike Miller <mtmiller>
Project Administrator
Sun 20 Aug 2017 03:37:54 PM UTC, comment #1:

I support this in general, and I would like to try this out and learn more about building a Flatpak application.

I have some initial questions and comments on inspection, without trying anything:

  • Does the directory have to be called "flatpak"?
  • Why do you have to remove "<project_group>GNU</project_group>"? I know this has come up before but I still don't understand it.
  • Can't EPSTOOL_BASE be passed on the make command line instead of patching?
  • Isn't there a way to call qmake or make on qscintilla to avoid patching?
  • Why does the huge block of pcre tests have to be removed from configure? If the tests are failing can we fix that a different way?
  • Should we name our desktop and appdata files to be "org.octave.Octave" instead of "www.octave.org-octave"?
  • I think the name of the application should be "org.octave.Octave"
  • I don't think the LIBGL_ALWAYS_SOFTWARE=1 environment variable is appropriate to set unconditionally. Some users might need it depending on their graphics hardware but it should not be necessary for everyone.
  • OpenBLAS should be built with DYNAMIC_ARCH=1, not TARGET=PRESCOTT
  • Why are you downloading epstool from fedoraproject.org?
  • Do you have an example build log that you can share with us to show what the configure results look like?
Mike Miller <mtmiller>
Project Administrator
Sun 20 Aug 2017 02:16:01 PM UTC, original submission:

I created a build recipe for Octave, which could be used to distribute stable and development versions of Octave directly to the users.

There has also been a little discussion going on on the mailing list: http://octave.1599824.n4.nabble.com/Octave-4-2-binary-all-packages-in-Linux-td4682832.html

The package can be tested like this:
flatpak remote-add kderuntime --from http://distribute.kde.org/kderuntime.flatpakrepo
flatpak install kderuntime org.kde.Platform 5.9
flatpak install kderuntime org.kde.Sdk 5.9
flatpak-builder --repo=octave-repo octave org.gnu.Octave.json
flatpak remote-add --no-gpg-verify octave-repo octave-repo
flatpak install octave-repo org.gnu.Octave
flatpak run org.gnu.Octave

I've submitted a pull request to Flathub (flathub.org) here, as well: https://github.com/flathub/flathub/pull/49

At some point in the future, and if this gets merged here, it might be possible to just point Flathub to the Octave Hg repository to look for the manifest.

Alexander Wilms <alexanderw>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files
file #41707:  json.diff added by mtmiller (2KiB - text/x-patch)
file #41704:  org.octave.Octave.json added by alexanderw (8KiB - application/octet-stream)
file #41692:  org.octave.Octave.json added by alexanderw (8KiB - application/octet-stream)
file #41674:  org.octave.Octave.json added by alexanderw (8KiB - application/octet-stream)
file #41675:  appdata.patch added by alexanderw (259B - application/octet-stream)
file #41676:  qrupdate-1.1.2_Makeconf.patch added by alexanderw (313B - application/octet-stream)
file #41634:  org.octave.Octave.json added by mtmiller (6KiB - application/json)
file #41607:  org.octave.Octave.json added by alexanderw (6KiB - application/octet-stream)
file #41602:  org.octave.Octave.json added by alexanderw (6KiB - application/octet-stream)
file #41601:  org.octave.Octave.json added by alexanderw (6KiB - application/octet-stream)
file #41590:  configure.log added by alexanderw (70KiB - text/x-log - Output of Octave's configure step)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by alexanderw (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 17 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 21 Mar 2018 12:55:25 AM UTCmtmillerStatusNeed Info=>Wont Do
      Open/ClosedOpen=>Closed
    Fri 01 Sep 2017 01:10:46 AM UTCmtmillerAttached File-=>Added json.diff, #41707
    Thu 31 Aug 2017 03:47:41 PM UTCalexanderwAttached File-=>Added org.octave.Octave.json, #41704
    Mon 28 Aug 2017 11:05:06 PM UTCalexanderwAttached File-=>Added org.octave.Octave.json, #41692
    Sun 27 Aug 2017 03:19:02 AM UTCalexanderwAttached File-=>Added org.octave.Octave.json, #41674
      Attached File-=>Added appdata.patch, #41675
      Attached File-=>Added qrupdate-1.1.2_Makeconf.patch, #41676
    Wed 23 Aug 2017 11:34:54 PM UTCmtmillerAttached File-=>Added org.octave.Octave.json, #41634
    Mon 21 Aug 2017 08:15:55 PM UTCalexanderwAttached File-=>Added org.octave.Octave.json, #41607
    Sun 20 Aug 2017 10:07:17 PM UTCalexanderwAttached File-=>Added org.octave.Octave.json, #41602
    Sun 20 Aug 2017 09:10:33 PM UTCalexanderwAttached File-=>Added org.octave.Octave.json, #41601
    Sun 20 Aug 2017 05:27:31 PM UTCmtmillerCategoryCore : other=>Core : new feature
      Priority5 - Normal=>3 - Low
      StatusNone=>Need Info
    Sun 20 Aug 2017 04:52:02 PM UTCalexanderwAttached File-=>Added configure.log, #41590
    Sun 20 Aug 2017 02:16:01 PM UTCalexanderwAttached File-=>Added 0001-Add-Flatpak-build-manifest.patch, #41588

    Back to the top


    Powered by Savane 3.1-cleanup1