Re: core-updates, next release, and all that
On 01/09/16 05:33, Ricardo Wurmus wrote: Ben Woodcroftwrites: On 28/07/16 19:31, Andreas Enge wrote: Hello, the main failures that remain on x86 are related to the gmime problem fixed in master. So I merged master once again and will start another evaluation of core-updates. Probably we are done then. There is a little problem with some source that cannot be downloaded: http://hydra.gnu.org:3000/build/1327453 If this has not been fixed in master yet, maybe the bioinformatics people would like to have a look. Fixed in 'f2e791750'. This was another case of BioConductor deleting out of date sources, and more encouragement to move to SVN as discussed previously. https://lists.gnu.org/archive/html/guix-devel/2016-06/msg00683.html Yeah, I really feel guilty each time I tell people here that Guix helps with reproducibility — and then I remember Bioconductor and have to add a footnote… It isn't so bad with content addressed mirrors now of course, this was a special case with hydra itself going down. I have already rewritten a Bioconductor package locally to test this. It shouldn’t take very long to move to SVN, but I just haven’t found the time so far. Maybe after the recursive importer is merged I’ll be able to make time to adjust the importer and existing Bioconductor packages. Excellent. ben
Re: core-updates, next release, and all that
Ben Woodcroftwrites: > On 28/07/16 19:31, Andreas Enge wrote: >> Hello, >> >> the main failures that remain on x86 are related to the gmime problem fixed >> in master. So I merged master once again and will start another evaluation >> of core-updates. Probably we are done then. >> >> There is a little problem with some source that cannot be downloaded: >> http://hydra.gnu.org:3000/build/1327453 >> If this has not been fixed in master yet, maybe the bioinformatics people >> would like to have a look. > > Fixed in 'f2e791750'. This was another case of BioConductor deleting out > of date sources, and more encouragement to move to SVN as discussed > previously. > https://lists.gnu.org/archive/html/guix-devel/2016-06/msg00683.html Yeah, I really feel guilty each time I tell people here that Guix helps with reproducibility — and then I remember Bioconductor and have to add a footnote… I have already rewritten a Bioconductor package locally to test this. It shouldn’t take very long to move to SVN, but I just haven’t found the time so far. Maybe after the recursive importer is merged I’ll be able to make time to adjust the importer and existing Bioconductor packages. ~~ Ricardo
Re: core-updates, next release, and all that
On 28/07/16 20:34, Andreas Enge wrote: On Thu, Jul 28, 2016 at 08:21:03PM +1000, Ben Woodcroft wrote: Fixed in 'f2e791750'. This was another case of BioConductor deleting out of date sources, and more encouragement to move to SVN as discussed previously. https://lists.gnu.org/archive/html/guix-devel/2016-06/msg00683.html Great, thanks! I cherry-picked into core-updates, hoping that git will be intelligent enough to not complain when we merge back core-updates into master. There was a number of further bioconductor updates. I pushed these to core-updates, and I'll soon push them to master as well. Would you mind starting another evaluation please? Thanks, ben
Re: core-updates, next release, and all that
On Thu, Jul 28, 2016 at 08:21:03PM +1000, Ben Woodcroft wrote: > Fixed in 'f2e791750'. This was another case of BioConductor deleting out of > date sources, and more encouragement to move to SVN as discussed previously. > https://lists.gnu.org/archive/html/guix-devel/2016-06/msg00683.html Great, thanks! I cherry-picked into core-updates, hoping that git will be intelligent enough to not complain when we merge back core-updates into master. Andreas
Re: core-updates, next release, and all that
On 28/07/16 19:31, Andreas Enge wrote: Hello, the main failures that remain on x86 are related to the gmime problem fixed in master. So I merged master once again and will start another evaluation of core-updates. Probably we are done then. There is a little problem with some source that cannot be downloaded: http://hydra.gnu.org:3000/build/1327453 If this has not been fixed in master yet, maybe the bioinformatics people would like to have a look. Fixed in 'f2e791750'. This was another case of BioConductor deleting out of date sources, and more encouragement to move to SVN as discussed previously. https://lists.gnu.org/archive/html/guix-devel/2016-06/msg00683.html Thanks for the alert and other efforts. ben
Re: core-updates, next release, and all that
Hello, the main failures that remain on x86 are related to the gmime problem fixed in master. So I merged master once again and will start another evaluation of core-updates. Probably we are done then. There is a little problem with some source that cannot be downloaded: http://hydra.gnu.org:3000/build/1327453 If this has not been fixed in master yet, maybe the bioinformatics people would like to have a look. Thanks! Andreas
Re: core-updates, next release, and all that
On Thu, Jul 28, 2016 at 10:24:25AM +0200, Andreas Enge wrote: > In fact, this seems to require the same number of rebuilds. Does changing the > arguments field not imply that the derivation will be considered different > also for other architectures? Now, I am wrong - a problem with the reloading of my webpage! I turned the computer off yesterday, turned it on again today, and then icecat showed the same pages as yesterday without reloading them! Andreas
Re: core-updates, next release, and all that
On Thu, Jul 28, 2016 at 01:10:27AM +0200, Ludovic Courtès wrote: > I pushed something along these lines as > 8b732bf6d93ad2cb529c3c5f886efe2625c5fb72, and also canceled the previous > evaluation builds and started a new evaluation. In fact, this seems to require the same number of rebuilds. Does changing the arguments field not imply that the derivation will be considered different also for other architectures? Andreas
Re: core-updates, next release, and all that
On Thu, Jul 28, 2016 at 01:10:27AM +0200, Ludovic Courtès wrote: > I pushed something along these lines as > 8b732bf6d93ad2cb529c3c5f886efe2625c5fb72, and also canceled the previous > evaluation builds and started a new evaluation. Great, thanks! Andreas
Re: core-updates, next release, and all that
l...@gnu.org (Ludovic Courtès) skribis: > Andreas Engeskribis: > >> On Wed, Jul 27, 2016 at 06:27:12PM +0200, Andreas Enge wrote: >>> Indeed. After disabling this one test, the package builds on my mips >>> machine. >>> I pushed and will start a new evaluation of core-updates. >> >> Drawback: This essentially recompiles all of core-updates. > > Not OK. > >> If we consider mips64el as a "release critical" architecture in Debian >> parlance, I would say we have no choice. Otherwise, we could also >> revert my commit and merge core-updates now. > > What about reverting, and instead modifying in a mips64el conditional? > As in: > > (arguments > `(#:phases (modify-phases %standard-phases > ,@(if (string-prefix? "mips64el" (%current-system)) >'((add-before 'check 'disable-the-thing …)) >'()) > …))) I pushed something along these lines as 8b732bf6d93ad2cb529c3c5f886efe2625c5fb72, and also canceled the previous evaluation builds and started a new evaluation. Hopefully that will allow us to merge core-updates more quickly! Ludo’.
Re: core-updates, next release, and all that
Andreas Engeskribis: > On Wed, Jul 27, 2016 at 06:27:12PM +0200, Andreas Enge wrote: >> Indeed. After disabling this one test, the package builds on my mips machine. >> I pushed and will start a new evaluation of core-updates. > > Drawback: This essentially recompiles all of core-updates. Not OK. > If we consider mips64el as a "release critical" architecture in Debian > parlance, I would say we have no choice. Otherwise, we could also > revert my commit and merge core-updates now. What about reverting, and instead modifying in a mips64el conditional? As in: (arguments `(#:phases (modify-phases %standard-phases ,@(if (string-prefix? "mips64el" (%current-system)) '((add-before 'check 'disable-the-thing …)) '()) …))) Ludo’.
Re: core-updates, next release, and all that
On Wed, Jul 27, 2016 at 06:27:12PM +0200, Andreas Enge wrote: > Indeed. After disabling this one test, the package builds on my mips machine. > I pushed and will start a new evaluation of core-updates. Drawback: This essentially recompiles all of core-updates. If we consider mips64el as a "release critical" architecture in Debian parlance, I would say we have no choice. Otherwise, we could also revert my commit and merge core-updates now. Andreas
Re: core-updates, next release, and all that
On Wed, Jul 27, 2016 at 12:44:36PM +0200, Andreas Enge wrote: > Probably it is less the update and rather the fact that we enable most > tests now. 6 of them are disabled because they fail ;-); so unless there > is opposition, I will disable a 7-th test, and we might be set. Indeed. After disabling this one test, the package builds on my mips machine. I pushed and will start a new evaluation of core-updates. Andreas
Re: core-updates, next release, and all that
On Tue, Jul 26, 2016 at 11:36:59PM +0200, Andreas Enge wrote: > another big failure: The python update from 2.7.10 to 2.7.11 breaks on mips; > there is one more test failing now (besides the already disabled ones): > test_ctypes. Probably it is less the update and rather the fact that we enable most tests now. 6 of them are disabled because they fail ;-); so unless there is opposition, I will disable a 7-th test, and we might be set. Andreas
Re: core-updates, next release, and all that
Hi all, another big failure: The python update from 2.7.10 to 2.7.11 breaks on mips; there is one more test failing now (besides the already disabled ones): test_ctypes. Andreas
Re: core-updates, next release, and all that
Andreas Engeskribis: > On Sun, Jul 24, 2016 at 12:59:22PM -0400, Leo Famulari wrote: >> So strange. Could the source code have been corrupted while unpacking? >> Can anyone replicate this locally, so they can use --keep-failed? > > Yes, but I still cannot make anything of it. > > The build phase boils down to >cd /tmp/guix-build-lpsolve-5.5.2.0.drv-0/lp_solve_5.5/lpsolve55 >bash ccc > where the latter command eventually runs >gcc -s -c -I.. -I../shared -I../bfp -I../bfp/bfp_LUSOL > -I../bfp/bfp_LUSOL/LUSOL -I../colamd -O3 $def $NOISNAN -DYY_NEVER_INTERACTIVE > -DPARSER_LP -DINVERSE_ACTIVE=INVERSE_LUSOL -DRoleIsExternalInvEngine > ../lp_MDO.c ../shared/commonlib.c ../shared/mmio.c ../shared/myblas.c > ../ini.c ../fortify.c ../colamd/colamd.c ../lp_rlp.c ../lp_crash.c > ../bfp/bfp_LUSOL/lp_LUSOL.c ../bfp/bfp_LUSOL/LUSOL/lusol.c ../lp_Hash.c > ../lp_lib.c ../lp_wlp.c ../lp_matrix.c ../lp_mipbb.c ../lp_MPS.c > ../lp_params.c ../lp_presolve.c ../lp_price.c ../lp_pricePSE.c ../lp_report.c > ../lp_scale.c ../lp_simplex.c ../lp_SOS.c ../lp_utils.c ../yacc_read.c > > When I source the environment variables of the build, then gcc-4.9 is used, > and the error message is printed. When I just install gcc-toolchain@5, it > passes. But I do not think that the compiler version makes a difference. > > The offending lines are > #ifndef FALSE > #define FALSE0 > #define TRUE 1 > #endif > which looks perfectly good. When I remove them, then the compiler complains > that FALSE is not defined. Fixed in commit 5dbfbef7292a43029b17e89d682d9e24703d5cd2. (The problem was a wrong ‘isnan’ feature test, leading to -DNOISNAN, leading to “#define isnan(x) FALSE”, so the ‘isnan’ declaration in was turned into “extern int FALSE __attribute__ ((__nothrow__ , __leaf__)) __attribute__ ((__const__));”…) Ludo’.
Re: core-updates, next release, and all that
Hello Leo, replying personally, since I am getting embarrassed... On Mon, Jul 25, 2016 at 08:40:56PM +0200, Andreas Enge wrote: > I had the impression that the new wxwidgets url did not appear, since the > build still fails on hydra. Now I see that the url is there, and the failure > on hydra is probably just cached because the hash did not change. I will > download it manually there and restart the failing builds. I was again mistaken, the URL is not there. I think I did a "git pull" in core-updates, then a "git merge master", which was probably not up to date. Now I redid a "git merge origin/master", and things look much better :-) I will push and evaluate again. Andreas
Re: core-updates, next release, and all that
On Mon, Jul 25, 2016 at 12:30:03PM -0400, Leo Famulari wrote: > What went wrong? I had the impression that the new wxwidgets url did not appear, since the build still fails on hydra. Now I see that the url is there, and the failure on hydra is probably just cached because the hash did not change. I will download it manually there and restart the failing builds. Andreas
Re: core-updates, next release, and all that
On Mon, Jul 25, 2016 at 09:51:49AM +0200, Andreas Enge wrote: > On Sun, Jul 24, 2016 at 06:48:13PM +0200, Andreas Enge wrote: > > It worked out and did not take that long after all. I pushed the fix, merged > > master into core-updates > > This does not seem to have worked out. I will let someone more git-savvy > do it next time, maybe after someone more C-savvy has been able to solve > the lpsolve build failure... Sorry, What went wrong?
Re: core-updates, next release, and all that
Andreas Engeskribis: > On Sun, Jul 24, 2016 at 06:04:39PM +0200, Andreas Enge wrote: >> Right now, I am trying to disable parallel builds; so far >> things look good, I think we are beyond the previous point of failure. >> But of course this would not be a very pleasant solution, given the build >> time of the package... > > It worked out and did not take that long after all. I pushed the fix, merged > master into core-updates and started a new evaluation. Awesome, thanks! Ludo’.
Re: core-updates, next release, and all that
On Sun, Jul 24, 2016 at 06:48:13PM +0200, Andreas Enge wrote: > It worked out and did not take that long after all. I pushed the fix, merged > master into core-updates This does not seem to have worked out. I will let someone more git-savvy do it next time, maybe after someone more C-savvy has been able to solve the lpsolve build failure... Sorry, Andreas
Re: core-updates, next release, and all that
On Sun, Jul 24, 2016 at 12:59:22PM -0400, Leo Famulari wrote: > So strange. Could the source code have been corrupted while unpacking? > Can anyone replicate this locally, so they can use --keep-failed? Yes, but I still cannot make anything of it. The build phase boils down to cd /tmp/guix-build-lpsolve-5.5.2.0.drv-0/lp_solve_5.5/lpsolve55 bash ccc where the latter command eventually runs gcc -s -c -I.. -I../shared -I../bfp -I../bfp/bfp_LUSOL -I../bfp/bfp_LUSOL/LUSOL -I../colamd -O3 $def $NOISNAN -DYY_NEVER_INTERACTIVE -DPARSER_LP -DINVERSE_ACTIVE=INVERSE_LUSOL -DRoleIsExternalInvEngine ../lp_MDO.c ../shared/commonlib.c ../shared/mmio.c ../shared/myblas.c ../ini.c ../fortify.c ../colamd/colamd.c ../lp_rlp.c ../lp_crash.c ../bfp/bfp_LUSOL/lp_LUSOL.c ../bfp/bfp_LUSOL/LUSOL/lusol.c ../lp_Hash.c ../lp_lib.c ../lp_wlp.c ../lp_matrix.c ../lp_mipbb.c ../lp_MPS.c ../lp_params.c ../lp_presolve.c ../lp_price.c ../lp_pricePSE.c ../lp_report.c ../lp_scale.c ../lp_simplex.c ../lp_SOS.c ../lp_utils.c ../yacc_read.c When I source the environment variables of the build, then gcc-4.9 is used, and the error message is printed. When I just install gcc-toolchain@5, it passes. But I do not think that the compiler version makes a difference. The offending lines are #ifndef FALSE #define FALSE0 #define TRUE 1 #endif which looks perfectly good. When I remove them, then the compiler complains that FALSE is not defined. Andreas
Re: core-updates, next release, and all that
On Sat, Jul 23, 2016 at 01:22:42PM +0200, Andreas Enge wrote: > On Sat, Jul 23, 2016 at 12:39:31PM +0200, Ludovic Courtès wrote: > > It could be a parallel-build issue. > > I added "#:parallel-build? #f", but to no avail. There are tons of strange > error messages like: > In file included from ../lp_MDO.c:22:0: > ../shared/commonlib.h:88:24: error: expected identifier or ‘(’ before numeric > constant >#define FALSE0 > ^ > In file included from ../lp_crash.c:21:0: > ../shared/commonlib.h:88:24: error: expected identifier or ‘(’ before numeric > constant >#define FALSE0 > ... > ar: creating bin/ux64/liblpsolve55.a > ar: lp_MDO.o: No such file or directory > ranlib: 'bin/ux64/liblpsolve55.a': No such file > ... So strange. Could the source code have been corrupted while unpacking? Can anyone replicate this locally, so they can use --keep-failed?
Re: core-updates, next release, and all that
On Sun, Jul 24, 2016 at 06:04:39PM +0200, Andreas Enge wrote: > Right now, I am trying to disable parallel builds; so far > things look good, I think we are beyond the previous point of failure. > But of course this would not be a very pleasant solution, given the build > time of the package... It worked out and did not take that long after all. I pushed the fix, merged master into core-updates and started a new evaluation. After that, I noticed another show-stopper: libreoffice depends on lpsolve, which does not build in core-updates, as discussed before. Andreas
Re: core-updates, next release, and all that
Hello, the current main blocker for a merge I identified in core-updates is that icecat does not build any more, while the same version builds in master. I just updated to 38.8.0-gnu2 in master, but this still does not build in core-updates. Right now, I am trying to disable parallel builds; so far things look good, I think we are beyond the previous point of failure. But of course this would not be a very pleasant solution, given the build time of the package... Andreas
Re: core-updates, next release, and all that
On Sat, Jul 23, 2016 at 12:39:31PM +0200, Ludovic Courtès wrote: > It could be a parallel-build issue. I added "#:parallel-build? #f", but to no avail. There are tons of strange error messages like: In file included from ../lp_MDO.c:22:0: ../shared/commonlib.h:88:24: error: expected identifier or ‘(’ before numeric constant #define FALSE0 ^ In file included from ../lp_crash.c:21:0: ../shared/commonlib.h:88:24: error: expected identifier or ‘(’ before numeric constant #define FALSE0 ... ar: creating bin/ux64/liblpsolve55.a ar: lp_MDO.o: No such file or directory ranlib: 'bin/ux64/liblpsolve55.a': No such file ... So compilation fails, and then installation also cannot succeed... Andreas
Re: core-updates, next release, and all that
Leo Famulariskribis: > On Fri, Jul 22, 2016 at 10:59:38PM +0200, Ludovic Courtès wrote: >> lpsolve https://hydra.gnu.org/build/1248528 > > From the failing build log: > > In unknown file: >?: 0 [copy-file "lpsolve55/bin/ux64/liblpsolve55.a" ...] > > ERROR: In procedure copy-file: > ERROR: In procedure copy-file: No such file or directory Means either the source or the target directory is missing. > It's strange, because lpsolve is the same package on master and > core-updates, and I can build it from master. Did (copy-file) change? > Could there be some issue with the underlying operating system? It could be a parallel-build issue. Ludo’.
Re: core-updates, next release, and all that
While building vlc libepoxy is in the graph, and this fails on its own, adding one problem to get vlc to testbuild on core-updates. I've seen someone fix something similar this this week but I don't know how. libepoxy is also outdated, newest release is https://github.com/anholt/libepoxy/archive/v1.3.1.tar.gz so I'll try with updating first. Found valid signature for /gnu/store/6m6p3mg9apv3gdfv95cwlbi6k6a1mz54-libepoxy-1.2 From https://mirror.hydra.gnu.org/nar/6m6p3mg9apv3gdfv95cwlbi6k6a1mz54-libepoxy-1.2 Downloading 6m6p3m…-libepoxy-1.2 (2.7MiB installed)... libepoxy-1.2 342KiB/s 00:01 | 373KiB transferred @ substituter-failed /gnu/store/6m6p3mg9apv3gdfv95cwlbi6k6a1mz54-libepoxy-1.2 0 hash mismatch in downloaded path `/gnu/store/6m6p3mg9apv3gdfv95cwlbi6k6a1mz54-libepoxy-1.2': expected 27b06d547ac45ab865e5cd27ccbf3654eba156d4563c0a0868466fdd2e383e8a, got 72fd010c7341668648ffe7e0c9839c2ba2dfe18f998b86cc7e4e0fd218bf5c06 @ substituter-started /gnu/store/zijrd8769sgfxqhq92b9219dhpl76va5-ftgl-2.1.3-rc5 /gnu/store/vw26xsn24jmrijn939fjjk50m5i4hfq3-guix-0.10.0-0.e901/libexec/guix/substitute killing process 23614 guix build: error: build failed: some substitutes for the outputs of derivation `/gnu/store/vwhxvdfwwm7phx9ysd6nr115bwlki56z-qtbase-5.6.1-1.drv' failed (usually happens due to networking issues); try `--fallback' to build derivation from source ng0@shadowwalker ~/src/guix/guix-curl$ ./pre-inst-env guix build libepoxy The following file will be downloaded: /gnu/store/6m6p3mg9apv3gdfv95cwlbi6k6a1mz54-libepoxy-1.2 @ substituter-started /gnu/store/6m6p3mg9apv3gdfv95cwlbi6k6a1mz54-libepoxy-1.2 /gnu/store/vw26xsn24jmrijn939fjjk50m5i4hfq3-guix-0.10.0-0.e901/libexec/guix/substitute Found valid signature for /gnu/store/6m6p3mg9apv3gdfv95cwlbi6k6a1mz54-libepoxy-1.2 From https://mirror.hydra.gnu.org/nar/6m6p3mg9apv3gdfv95cwlbi6k6a1mz54-libepoxy-1.2 Downloading 6m6p3m…-libepoxy-1.2 (2.7MiB installed)... libepoxy-1.2 1.2MiB/s 00:00 | 373KiB transferred @ substituter-failed /gnu/store/6m6p3mg9apv3gdfv95cwlbi6k6a1mz54-libepoxy-1.2 0 hash mismatch in downloaded path `/gnu/store/6m6p3mg9apv3gdfv95cwlbi6k6a1mz54-libepoxy-1.2': expected 27b06d547ac45ab865e5cd27ccbf3654eba156d4563c0a0868466fdd2e383e8a, got 72fd010c7341668648ffe7e0c9839c2ba2dfe18f998b86cc7e4e0fd218bf5c06 guix build: error: build failed: some substitutes for the outputs of derivation `/gnu/store/x2x0ydbc66rm3a3r3n1n6qdhcfw1ixlv-libepoxy-1.2.drv' failed (usually happens due to networking issues); try `--fallback' to build derivation from source -- ♥Ⓐ ng0 – http://we.make.ritual.n0.is NFor non-prism friendly talk find me on http://www.psyced.org SecuShare – http://secushare.org
Re: core-updates, next release, and all that
On Fri, Jul 22, 2016 at 07:00:43PM -0400, Leo Famulari wrote: > Done. I also wrote a description of the conflicts I resolved in the > commit message. I think this is useful, since I've had difficulty > learning this information about other merges in the past. Thank you! I just launched a new evaluation. Andreas
Re: core-updates, next release, and all that
On Sat, Jul 23, 2016 at 12:06:49AM +0200, Andreas Enge wrote: > Hello Leo, > > some of the failures are due to missing sourceforge tarballs. I think > we should merge master into core-updates and start a new evaluation. Done. I also wrote a description of the conflicts I resolved in the commit message. I think this is useful, since I've had difficulty learning this information about other merges in the past.
Re: core-updates, next release, and all that
On Fri, Jul 22, 2016 at 10:46:16PM +, ng0 wrote: > I still have the gnupg updates sitting here. Sorry that it took a > bit longer, I had to figure out problems and solutions with > another system and project. > > >gnupg-2.1.14 requires libgcrypt >= 1.7.0 [0] and libgpg-error >= 1.24. > >Those are both core packages. > > Now that we are nearing completion of core, should I just wait or > base them on -next? The gnupg updates will require rebuilding almost everything. Right now, we are trying to finish building a few final things. I think we should put the gnupg updates on -next.
Re: core-updates, next release, and all that
Andreas Engewrites: > Hello Leo, > > some of the failures are due to missing sourceforge tarballs. I think > we should merge master into core-updates and start a new evaluation. > > Andreas > > I still have the gnupg updates sitting here. Sorry that it took a bit longer, I had to figure out problems and solutions with another system and project. >gnupg-2.1.14 requires libgcrypt >= 1.7.0 [0] and libgpg-error >= 1.24. >Those are both core packages. Now that we are nearing completion of core, should I just wait or base them on -next? -- ♥Ⓐ ng0 – http://we.make.ritual.n0.is For non-prism friendly talk find me on http://www.psyced.org SecuShare – http://secushare.org
Re: core-updates, next release, and all that
On Sat, Jul 23, 2016 at 12:06:49AM +0200, Andreas Enge wrote: > some of the failures are due to missing sourceforge tarballs. I think > we should merge master into core-updates and start a new evaluation. Okay, I will try the merge now.
Re: core-updates, next release, and all that
Hello Leo, some of the failures are due to missing sourceforge tarballs. I think we should merge master into core-updates and start a new evaluation. Andreas
Re: core-updates, next release, and all that
On Fri, Jul 22, 2016 at 10:59:38PM +0200, Ludovic Courtès wrote: > polkit https://hydra.gnu.org/build/1287623 If I'm reading the Hydra web page correctly, this is a consequence of the failure of mozjs-17 and a cached failure of the Shepherd.
Re: core-updates, next release, and all that
On Fri, Jul 22, 2016 at 10:59:38PM +0200, Ludovic Courtès wrote: > lpsolve https://hydra.gnu.org/build/1248528 >From the failing build log: In unknown file: ?: 0 [copy-file "lpsolve55/bin/ux64/liblpsolve55.a" ...] ERROR: In procedure copy-file: ERROR: In procedure copy-file: No such file or directory It's strange, because lpsolve is the same package on master and core-updates, and I can build it from master. Did (copy-file) change? Could there be some issue with the underlying operating system? Or am I misreading the backtrace?
Re: core-updates, next release, and all that
On Fri, Jul 22, 2016 at 10:59:38PM +0200, Ludovic Courtès wrote: > Critical things: > > mozjs https://hydra.gnu.org/build/1291842 Disabling parallel-builds worked for mozjs-24, which failed the same way, so I pushed a similar change for mozjs-17.
core-updates, next release, and all that
Hello Guix! Time passes and we still have that ‘core-updates’ branch waiting to be healed and merged. It seems to be doing mostly OK: https://hydra.gnu.org/jobset/gnu/core-updates with ~90 packages failing compared to master: https://hydra.gnu.org/eval/109012?compare=master Critical things: mozjs https://hydra.gnu.org/build/1291842 icecat https://hydra.gnu.org/build/1307245 polkit https://hydra.gnu.org/build/1287623 lpsolve https://hydra.gnu.org/build/1248528 … Leaf packages: lilypond https://hydra.gnu.org/build/1304657 unison https://hydra.gnu.org/build/1305618 node https://hydra.gnu.org/build/1306274 vlc https://hydra.gnu.org/build/1304871 … 턞 Join us now, 텞 fix the packages, you’ll be happy, hacker! :-) I think we should release 0.10.1 soon after that given all the improvements and packages we’ve accumulated. What do people think? Ludo’.