From: Alan W. I. <Ala...@gm...> - 2018-08-13 19:57:12
|
On 2018-08-13 08:41-0000 Arjen Markus wrote: > Hi Alan, > >> However, I hope those comments (such as the possibility mentioned above of >> building an octave MinGW-w64/MSYS2 package for yourself using the pacman >> packaging information at >> <https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-octave-hg>) >> are still of some use to you. >> > I have tried to build Octave under MinGW-w64/MSYS2 using that webpage. However: > - I had to remove the references to the patches, as these do not seem to be available. No idea what the effect is > - The build failed on a mismatch in the checksums: > > $ makepkg -sCLf > ==> Making package: mingw-w64-octave-hg r19590.6d75f1683ce8-1 (Sun, Aug 12, 2018 15:56:07) > ==> Checking runtime dependencies... > ==> Checking buildtime dependencies... > ==> Retrieving sources... > -> Updating gnulib git repo... > Fetching origin > -> Found tip.tar.bz2 > ==> ERROR: Integrity checks (sha256) differ in size from the source array. > > This is the point where I stopped. I have no clue as to whether this is a serious issue or not. Let's ignore octave for a bit and look at the more general picture. If you like the goal (in its own right) of learning to build packages for the MinGW-w64/MSYS2 platform, then I suggest you follow the package build documentation examples under the heading "Re-building a package" at <https://github.com/msys2/msys2/wiki/Creating-packages>. Can you use those steps to build both their examples (flex and python3)? If not, then you should take the problem to the MSYS2 mailing list to get help with that documentation. But if that general procedure works for you, then the next obvious step is to help out with the PLplot packaging at <https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-plplot> by first building that package as is, fixing it according to your own experience (e.g., by moving to Python 3, and by enabling qt), and drawing Alex's attention to your improvements (likely via a pull request) so they will be made part of the official Plplot package for this platform. Moving back to the octave case, I am pretty sure unless that semi-official package is completely broken, that the same procedures used to build flex, python3, and PLplot should also work fine for octave without all the issues you encountered above. Assuming you can build that octave package, then the next steps would be to evaluate the result for our needs, and assuming it does work for those needs (or can easily be fixed), advocate making it an official package that the PLplot package depends on. > I guess an alternative could be to simply build Octave and install it without pacman, but I have not tried that yet. I would advise against that since unofficial octave builds are not going to help our octave users that much on this particular platform and may turn out to be a black hole sucking up a lot of your time. Instead, I think it would be better in the long-run to help get an official octave package running for this platform as I have outlined above. Alan __________________________ Alan W. Irwin Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |