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 a
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
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
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, t
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 cann
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:3
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
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 c
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
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: T
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 O
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
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 disablin
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 mo
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
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
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
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.
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
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
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 bee
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-bui
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 ../
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
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 fa
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
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:
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
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 evalu
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 me
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
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 pro
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.
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
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.
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
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.
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 thing
38 matches
Mail list logo
