GNU bug report logs - #15194
hop FTBFS

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 15194 in the body.
You can then email your comments to 15194 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Mark H Weaver <mhw <at> netris.org>
To: bug-guix <at> gnu.org
Subject: hop FTBFS
Date: Mon, 26 Aug 2013 17:39:54 -0400

Using guix from git 5d9cd70721aa8256f333f76c76cecc6593b6b293, hop fails
to build from source.  Here's the tail of the make transcript:

--8<---------------cut here---------------start------------->8---
bigloo -O2 -fsharing -Wall -wslots -L /tmp/nix-build-hop-2.4.0.drv-0/hop-2.4.0/lib -srfi enable-threads -srfi enable-avahi -cc gcc -copt "-O3  -I/nix/store/l4389c6kqs5x339ai7rah7ywaxm97hcs-bigloo-4.0b/lib/bigloo/4.0b" -srfi hop-dynamic  -copt -fPIC -L /tmp/nix-build-hop-2.4.0.drv-0/hop-2.4.0/lib -unsafe -safee -c xml.scm -o o/xml.o

File "xml.scm", line 859, character 33481:
#	  (let ((js-attr (xml-attribute-encode (xml-tilde->statement obj))))
#	                 ^
*** ERROR:xml-tilde->attribute
Unbound variable -- xml-attribute-encode

File "xml.scm", line 646, character 24544:
#		    (let ((a (xml-attribute-encode attr)))
#		             ^
*** ERROR:xml-write-attribute1293
Unbound variable -- xml-attribute-encode

File "xml.scm", line 650, character 24709:
#	  (display (xml-attribute-encode attr) p)))
#	           ^
*** ERROR:xml-write-attribute1293
Unbound variable -- xml-attribute-encode
3 errors occured, ending ...
make[1]: *** [o/xml.o] Error 255
make[1]: Leaving directory `/tmp/nix-build-hop-2.4.0.drv-0/hop-2.4.0/runtime'
make: *** [lib] Error 2
--8<---------------cut here---------------end--------------->8---

Message #8 received at 15194 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Mark H Weaver <mhw <at> netris.org>
Cc: 15194 <at> debbugs.gnu.org
Subject: Re: bug#15194: hop FTBFS
Date: Tue, 27 Aug 2013 10:27:25 +0200

Mark H Weaver <mhw <at> netris.org> skribis:

> Using guix from git 5d9cd70721aa8256f333f76c76cecc6593b6b293, hop fails
> to build from source.  Here's the tail of the make transcript:
>
> bigloo -O2 -fsharing -Wall -wslots -L /tmp/nix-build-hop-2.4.0.drv-0/hop-2.4.0/lib -srfi enable-threads -srfi enable-avahi -cc gcc -copt "-O3  -I/nix/store/l4389c6kqs5x339ai7rah7ywaxm97hcs-bigloo-4.0b/lib/bigloo/4.0b" -srfi hop-dynamic  -copt -fPIC -L /tmp/nix-build-hop-2.4.0.drv-0/hop-2.4.0/lib -unsafe -safee -c xml.scm -o o/xml.o
>
> File "xml.scm", line 859, character 33481:
> #	  (let ((js-attr (xml-attribute-encode (xml-tilde->statement obj))))
> #	                 ^
> *** ERROR:xml-tilde->attribute
> Unbound variable -- xml-attribute-encode
>
> File "xml.scm", line 646, character 24544:
> #		    (let ((a (xml-attribute-encode attr)))
> #		             ^
> *** ERROR:xml-write-attribute1293
> Unbound variable -- xml-attribute-encode
>
> File "xml.scm", line 650, character 24709:
> #	  (display (xml-attribute-encode attr) p)))
> #	           ^
> *** ERROR:xml-write-attribute1293
> Unbound variable -- xml-attribute-encode
> 3 errors occured, ending ...

Yes, that’s a consequence of the Bigloo upgrade
(e858326a0f8574e98336046752a4bf786a2c1d0a).  It turns out Hop & Bigloo
have to be upgraded in lockstep.  I believe a new Hop version is around
the corner, so I’m tempted to just wait for that.

WDYT?

Ludo’.

Message #11 received at 15194 <at> debbugs.gnu.org (full text, mbox):

From: Mark H Weaver <mhw <at> netris.org>
To: ludo <at> gnu.org (Ludovic Courtès)
Cc: 15194 <at> debbugs.gnu.org
Subject: Re: bug#15194: hop FTBFS
Date: Tue, 27 Aug 2013 10:54:35 -0400

ludo <at> gnu.org (Ludovic Courtès) writes:

> It turns out Hop & Bigloo have to be upgraded in lockstep.  I believe
> a new Hop version is around the corner, so I’m tempted to just wait
> for that.
>
> WDYT?

I think we should find a solution that doesn't lead to the 'hop' build
being broken every time 'bigloo' is upgraded before 'hop'.

An obvious solution would be to keep two versions of 'bigloo': the
latest release, and the release that corresponds to the latest release
of 'hop'.  Hopefully these would be the same most of the time.

What do you think?

      Mark

Message #14 received at 15194 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Mark H Weaver <mhw <at> netris.org>
Cc: 15194 <at> debbugs.gnu.org
Subject: Re: bug#15194: hop FTBFS
Date: Tue, 27 Aug 2013 17:18:20 +0200

Mark H Weaver <mhw <at> netris.org> skribis:

> ludo <at> gnu.org (Ludovic Courtès) writes:
>
>> It turns out Hop & Bigloo have to be upgraded in lockstep.  I believe
>> a new Hop version is around the corner, so I’m tempted to just wait
>> for that.
>>
>> WDYT?
>
> I think we should find a solution that doesn't lead to the 'hop' build
> being broken every time 'bigloo' is upgraded before 'hop'.
>
> An obvious solution would be to keep two versions of 'bigloo': the
> latest release, and the release that corresponds to the latest release
> of 'hop'.  Hopefully these would be the same most of the time.

Yes, that sounds like a plan.  And hopefully the “old” Bigloo would just
differ by its ‘version’ and ‘source’ fields, which is easily handled.

Would you like to propose a patch?

Thanks,
Ludo’.

Message #17 received at 15194 <at> debbugs.gnu.org (full text, mbox):

From: Mark H Weaver <mhw <at> netris.org>
To: ludo <at> gnu.org (Ludovic Courtès)
Cc: 15194 <at> debbugs.gnu.org
Subject: Re: bug#15194: hop FTBFS
Date: Thu, 29 Aug 2013 21:35:54 -0400

ludo <at> gnu.org (Ludovic Courtès) writes:

> Mark H Weaver <mhw <at> netris.org> skribis:
>
>> ludo <at> gnu.org (Ludovic Courtès) writes:
>>
>>> It turns out Hop & Bigloo have to be upgraded in lockstep.  I believe
>>> a new Hop version is around the corner, so I’m tempted to just wait
>>> for that.
>>>
>>> WDYT?
>>
>> I think we should find a solution that doesn't lead to the 'hop' build
>> being broken every time 'bigloo' is upgraded before 'hop'.
>>
>> An obvious solution would be to keep two versions of 'bigloo': the
>> latest release, and the release that corresponds to the latest release
>> of 'hop'.  Hopefully these would be the same most of the time.
>
> Yes, that sounds like a plan.  And hopefully the “old” Bigloo would just
> differ by its ‘version’ and ‘source’ fields, which is easily handled.
>
> Would you like to propose a patch?

I don't actually use 'bigloo' or 'hop' myself, and right now I have my
hands full with a lot of pending work for Guile, so I'd prefer to let
someone else take care of this.  I only know about this problem because
I've been building as many Guix packages as possible, for testing
purposes.

     Regards,
       Mark

Message #22 received at 15194-done <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Mark H Weaver <mhw <at> netris.org>
Cc: 15194-done <at> debbugs.gnu.org
Subject: Re: bug#15194: hop FTBFS
Date: Fri, 30 Aug 2013 14:19:46 +0200

Mark H Weaver <mhw <at> netris.org> skribis:

> ludo <at> gnu.org (Ludovic Courtès) writes:
>
>> Mark H Weaver <mhw <at> netris.org> skribis:
>>
>>> ludo <at> gnu.org (Ludovic Courtès) writes:
>>>
>>>> It turns out Hop & Bigloo have to be upgraded in lockstep.  I believe
>>>> a new Hop version is around the corner, so I’m tempted to just wait
>>>> for that.
>>>>
>>>> WDYT?
>>>
>>> I think we should find a solution that doesn't lead to the 'hop' build
>>> being broken every time 'bigloo' is upgraded before 'hop'.
>>>
>>> An obvious solution would be to keep two versions of 'bigloo': the
>>> latest release, and the release that corresponds to the latest release
>>> of 'hop'.  Hopefully these would be the same most of the time.
>>
>> Yes, that sounds like a plan.  And hopefully the “old” Bigloo would just
>> differ by its ‘version’ and ‘source’ fields, which is easily handled.
>>
>> Would you like to propose a patch?
>
> I don't actually use 'bigloo' or 'hop' myself, and right now I have my
> hands full with a lot of pending work for Guile, so I'd prefer to let
> someone else take care of this.

Message received.  ;-)

I used by super powers to fix it in ffc1074.

Thanks!

Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.