Re: core-updates, next release, and all that

[Ben Woodcroft]

On 01/09/16 05:33, Ricardo Wurmus wrote:

Ben Woodcroft  writes:


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

[Ricardo Wurmus]

Ben Woodcroft  writes:

> 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

[Ben Woodcroft]

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

[Andreas Enge]

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

[Ben Woodcroft]

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

[Andreas Enge]

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

[Andreas Enge]

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

[Andreas Enge]

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

[Andreas Enge]

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

[Ludovic Courtès]

l...@gnu.org (Ludovic Courtès) skribis:

> Andreas Enge  skribis:
>
>> 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

[Ludovic Courtès]

Andreas Enge  skribis:

> 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

[Andreas Enge]

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

[Andreas Enge]

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

[Andreas Enge]

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

[Andreas Enge]

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

[Ludovic Courtès]

Andreas Enge  skribis:

> 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

[Andreas Enge]

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

[Andreas Enge]

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

[Leo Famulari]

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

[Ludovic Courtès]

Andreas Enge  skribis:

> 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

[Andreas Enge]

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

[Andreas Enge]

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

[Leo Famulari]

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

[Andreas Enge]

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

[Andreas Enge]

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

[Andreas Enge]

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

[Ludovic Courtès]

Leo Famulari  skribis:

> 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

[ng0]

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

[Andreas Enge]

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

[Leo Famulari]

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

[Leo Famulari]

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

[ng0]

Andreas Enge  writes:

> 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

[Leo Famulari]

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

[Andreas Enge]

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

[Leo Famulari]

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

[Leo Famulari]

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

[Leo Famulari]

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.