Re: GUB success?
OK - the issue causing the fail was the lack of a regtest tarball, which I knew how to fix. There were a couple of other problems, but I have definitely now successfully run GUB and got installation media. More details to follow. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB success?
- Original Message - From: "Graham Percival" To: "Phil Holmes" Cc: "Devel" Sent: Sunday, March 11, 2012 4:31 PM Subject: Re: GUB success? On Sun, Mar 11, 2012 at 04:19:24PM -, Phil Holmes wrote: - Original Message - From: "Graham Percival" To: "Phil Holmes" Cc: "Devel" Sent: Sunday, March 11, 2012 3:30 PM Subject: Re: GUB success? >On Sun, Mar 11, 2012 at 03:10:41PM -, Phil Holmes wrote: >Are you sure you mean lilydev 1.1 and not 1.2 ? That's what's written on the DVD you sent me. I use that for convenience. ok. Remind me to send you another dvd once lilydev 2 is out. gub.log is not very verbose, and is attached. Can't see anything wrong. I assume that running make lilypond now shouldn't take as long? I can't spot anything myself, either. What do you have in uploads/ ? rien. And yes, running "make lilypond" again shouldn't take a long time. I sometimes run those commands again if I think I've missed seeing an error, so it's worth a shot. Now trying this. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB success?
On Sun, Mar 11, 2012 at 04:19:24PM -, Phil Holmes wrote: > - Original Message - From: "Graham Percival" > > To: "Phil Holmes" > Cc: "Devel" > Sent: Sunday, March 11, 2012 3:30 PM > Subject: Re: GUB success? > > >On Sun, Mar 11, 2012 at 03:10:41PM -, Phil Holmes wrote: > >Are you sure you mean lilydev 1.1 and not 1.2 ? > > That's what's written on the DVD you sent me. I use that for convenience. ok. Remind me to send you another dvd once lilydev 2 is out. > gub.log is not very verbose, and is attached. Can't see anything > wrong. I assume that running make lilypond now shouldn't take as > long? I can't spot anything myself, either. What do you have in uploads/ ? And yes, running "make lilypond" again shouldn't take a long time. I sometimes run those commands again if I think I've missed seeing an error, so it's worth a shot. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB success?
- Original Message - From: "Graham Percival" To: "Phil Holmes" Cc: "Devel" Sent: Sunday, March 11, 2012 3:30 PM Subject: Re: GUB success? On Sun, Mar 11, 2012 at 03:10:41PM -, Phil Holmes wrote: I think I have GUB running properly. I gave up trying to get it working on 64-bit Ubuntu and created a new VirtualBox VM with lilydev 1.1 as the OS. Are you sure you mean lilydev 1.1 and not 1.2 ? That's what's written on the DVD you sent me. I use that for convenience. I have documented what I did for later, but basically I ran make bootstrap, make and make lilypond. I think that'll try to build master. To build release/unstable -- which should be more reliable, since that's what built the latest official devel release -- use: make LILYPOND_BRANCH=release/unstable lilypond OK. For now master is OK - just trying to get it working. It's handy with master - you can check the version number to guarantee it's a new exe. The last command ended with building package: darwin-x86::lilypond *** Stage: download (lilypond, darwin-x86) *** Stage: untar (lilypond, darwin-x86) *** Stage: patch (lilypond, darwin-x86) *** Stage: autoupdate (lilypond, darwin-x86) *** Stage: configure (lilypond, darwin-x86) *** Stage: compile (lilypond, darwin-x86) *** Stage: install (lilypond, darwin-x86) *** Stage: package (lilypond, darwin-x86) *** Stage: clean (lilypond, darwin-x86) *** Stage: pkg_install (lilypond, darwin-x86) done make[1]: *** wait: No child processes. Stop. make: *** [lilypond] Error 2 gub@gub-virtualbox:~/gub$ Doesn't look right. It should end with lilypond-doc. Although I can't see an error on the terminal output. Take a look in log/gub.log ? Also look in uploads/ ; you should see all the binaries, plus webtest (regression comparisons), plus documentation, plus source tarball, in there. - Graham gub.log is not very verbose, and is attached. Can't see anything wrong. I assume that running make lilypond now shouldn't take as long? -- Phil Holmes gub.log Description: Binary data ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB success?
Phil Holmes wrote Sunday, March 11, 2012 3:10 PM I think I have GUB running properly. I gave up trying to get it working on 64-bit Ubuntu and created a new VirtualBox VM with lilydev 1.1 as the OS. Congratulations! One of the select few! Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB success?
On Sun, Mar 11, 2012 at 03:10:41PM -, Phil Holmes wrote: > I think I have GUB running properly. I gave up trying to get it > working on 64-bit Ubuntu and created a new VirtualBox VM with > lilydev 1.1 as the OS. Are you sure you mean lilydev 1.1 and not 1.2 ? > I have documented what I did for later, but > basically I ran make bootstrap, make and make lilypond. I think that'll try to build master. To build release/unstable -- which should be more reliable, since that's what built the latest official devel release -- use: make LILYPOND_BRANCH=release/unstable lilypond > The last command ended with > building package: darwin-x86::lilypond > *** Stage: download (lilypond, darwin-x86) > *** Stage: untar (lilypond, darwin-x86) > *** Stage: patch (lilypond, darwin-x86) > *** Stage: autoupdate (lilypond, darwin-x86) > *** Stage: configure (lilypond, darwin-x86) > *** Stage: compile (lilypond, darwin-x86) > *** Stage: install (lilypond, darwin-x86) > *** Stage: package (lilypond, darwin-x86) > *** Stage: clean (lilypond, darwin-x86) > *** Stage: pkg_install (lilypond, darwin-x86) > > done > make[1]: *** wait: No child processes. Stop. > make: *** [lilypond] Error 2 > gub@gub-virtualbox:~/gub$ Doesn't look right. It should end with lilypond-doc. > Although I can't see an error on the terminal output. Take a look in log/gub.log ? Also look in uploads/ ; you should see all the binaries, plus webtest (regression comparisons), plus documentation, plus source tarball, in there. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
GUB success?
I think I have GUB running properly. I gave up trying to get it working on 64-bit Ubuntu and created a new VirtualBox VM with lilydev 1.1 as the OS. After a number of lengthy false starts (lesson 1: when it's running, don't interrupt it) I've just completed a build. I have documented what I did for later, but basically I ran make bootstrap, make and make lilypond. The last command ended with building package: darwin-x86::lilypond *** Stage: download (lilypond, darwin-x86) *** Stage: untar (lilypond, darwin-x86) *** Stage: patch (lilypond, darwin-x86) *** Stage: autoupdate (lilypond, darwin-x86) *** Stage: configure (lilypond, darwin-x86) *** Stage: compile (lilypond, darwin-x86) *** Stage: install (lilypond, darwin-x86) *** Stage: package (lilypond, darwin-x86) *** Stage: clean (lilypond, darwin-x86) *** Stage: pkg_install (lilypond, darwin-x86) done make[1]: *** wait: No child processes. Stop. make: *** [lilypond] Error 2 gub@gub-virtualbox:~/gub$ Although I can't see an error on the terminal output. I think it may simply be something like a minor locking problem much earlier in the build. FWIW, on my quick machine, this took somewhat over 4 hours (compared with make ib lilypond build, which takes 1 minute 5 seconds). I've definitely got a usable windows executable. I can't find the install packages - is there another command to run, or a secret place to look? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB success.
Erik Sandberg wrote: Hi, Now gub works here (on my IA32 partition), so I can commit code again. I couldn't easily force a rebuild. If I have a patch I want to test, what should I do? I applied the patch to downloads/lilypond-HEAD, but I couldn't find a good way to force make or make linux to rebuild (the only way I could find was rm -r target/). Hello, The current version of GUB supports building from GIT repositories. To test this, change vc_type to 'git' in specs/lilypond.py -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen LilyPond Software Design -- Code for Music Notation http://www.lilypond-design.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB success.
Erik Sandberg wrote: Strangely, this didn't happen when building in 32-bit mode. The problem seems to be that Apple's implementation of ranlib assumes 32-bit architecture for some optimizations, so the lib doesn't work with platforms where sizeof(char*)>4. I don't know what to do about this. Is it possible to turn off all mac support in make bootstrap? sure, just override PLATFORMS. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen LilyPond Software Design -- Code for Music Notation http://www.lilypond-design.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB success.
On Saturday 26 August 2006 21:51, Erik Sandberg wrote: > On Saturday 26 August 2006 01:07, Han-Wen Nienhuys wrote: > > Erik Sandberg wrote: > - I could temporarily fix the above problem, but now there's a failure in > the compilation of odcctools: > *** Stage: compile (odcctools) > [...] > gcc -Wall -Wno-import -DHAVE_CONFIG_H -D__LITTLE_ENDIAN__=1 > -D_MACH_I386_THREAD_STATUS_FPSTATE_LEGACY_FIELD_NAMES_ > -D_ARCHITECTURE_I386_FPU_FPSTATE_LEGACY_FIELD_NAMES_ -DSTDC_HEADERS > -I..//include > -I/home/erik/lily/64gub/gubtest/target/darwin-ppc/src/odcctools-20060413/in >clude -include > /home/erik/lily/64gub/gubtest/target/darwin-ppc/src/odcctools-20060413/incl >ude/extern.h > -I/home/erik/lily/64gub/gubtest/target/darwin-ppc/src/odcctools-20060413/in >clude/foreign -g -O2 -fno-builtin-round -fno-builtin-trunc -c -o > writeout.o > /home/erik/lily/64gub/gubtest/target/darwin-ppc/src/odcctools-20060413/libs >tuff/writeout.c > /home/erik/lily/64gub/gubtest/target/darwin-ppc/src/odcctools-20060413/libs >tuff/writeout.c: In function ‘writeout’: > /home/erik/lily/64gub/gubtest/target/darwin-ppc/src/odcctools-20060413/libs >tuff/writeout.c:131: warning: dereferencing type-punned pointer will break > strict-aliasing rules > /home/erik/lily/64gub/gubtest/target/darwin-ppc/src/odcctools-20060413/libs >tuff/writeout.c:264: warning: cast from pointer to integer of different size > /home/erik/lily/64gub/gubtest/target/darwin-ppc/src/odcctools-20060413/libs >tuff/writeout.c: In function ‘writeout_to_mem’: > /home/erik/lily/64gub/gubtest/target/darwin-ppc/src/odcctools-20060413/libs >tuff/writeout.c:382: warning: dereferencing type-punned pointer will break > strict-aliasing rules > /home/erik/lily/64gub/gubtest/target/darwin-ppc/src/odcctools-20060413/libs >tuff/writeout.c: In function ‘make_table_of_contents’: > /home/erik/lily/64gub/gubtest/target/darwin-ppc/src/odcctools-20060413/libs >tuff/writeout.c:1021: error: ‘union ’ has no member named > ‘ran_name’ > [...] > > Strangely, this didn't happen when building in 32-bit mode. The problem seems to be that Apple's implementation of ranlib assumes 32-bit architecture for some optimizations, so the lib doesn't work with platforms where sizeof(char*)>4. I don't know what to do about this. Is it possible to turn off all mac support in make bootstrap? -- Erik ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB success.
On Saturday 26 August 2006 01:07, Han-Wen Nienhuys wrote: > Erik Sandberg wrote: > > Hi, > > > > Now gub works here (on my IA32 partition), so I can commit code again. > > > > I couldn't easily force a rebuild. If I have a patch I want to test, what > > should I do? I applied the patch to downloads/lilypond-HEAD, but I > > couldn't find a good way to force make or make linux to rebuild (the only > > way I could find was rm -r target/). > > The best way is to change downloads/lilypond-HEADS/.cvs-checksum. > > That file is a checksum of all CVS/Entries files, and if it's changed, > GUB assumes it has to rebuild the thing. OK, thanks. I'm having a different problem now: I'm trying to get GUB to work in x86-64. I'm facing two problems, which both happen during make bootstrap: - I tried to insert a patch in patches/ to make guile build, but I don't understand how to have it applied: I added a line in specs/guile.py which imitated the one for guile-reloc.patch, but neither guile-reloc.patch nor guile-x86_64 was applied before guile was built, hence the build failed. - I could temporarily fix the above problem, but now there's a failure in the compilation of odcctools: *** Stage: compile (odcctools) [...] gcc -Wall -Wno-import -DHAVE_CONFIG_H -D__LITTLE_ENDIAN__=1 -D_MACH_I386_THREAD_STATUS_FPSTATE_LEGACY_FIELD_NAMES_ -D_ARCHITECTURE_I386_FPU_FPSTATE_LEGACY_FIELD_NAMES_ -DSTDC_HEADERS -I..//include -I/home/erik/lily/64gub/gubtest/target/darwin-ppc/src/odcctools-20060413/include -include /home/erik/lily/64gub/gubtest/target/darwin-ppc/src/odcctools-20060413/include/extern.h -I/home/erik/lily/64gub/gubtest/target/darwin-ppc/src/odcctools-20060413/include/foreign -g -O2 -fno-builtin-round -fno-builtin-trunc -c -o writeout.o /home/erik/lily/64gub/gubtest/target/darwin-ppc/src/odcctools-20060413/libstuff/writeout.c /home/erik/lily/64gub/gubtest/target/darwin-ppc/src/odcctools-20060413/libstuff/writeout.c: In function ‘writeout’: /home/erik/lily/64gub/gubtest/target/darwin-ppc/src/odcctools-20060413/libstuff/writeout.c:131: warning: dereferencing type-punned pointer will break strict-aliasing rules /home/erik/lily/64gub/gubtest/target/darwin-ppc/src/odcctools-20060413/libstuff/writeout.c:264: warning: cast from pointer to integer of different size /home/erik/lily/64gub/gubtest/target/darwin-ppc/src/odcctools-20060413/libstuff/writeout.c: In function ‘writeout_to_mem’: /home/erik/lily/64gub/gubtest/target/darwin-ppc/src/odcctools-20060413/libstuff/writeout.c:382: warning: dereferencing type-punned pointer will break strict-aliasing rules /home/erik/lily/64gub/gubtest/target/darwin-ppc/src/odcctools-20060413/libstuff/writeout.c: In function ‘make_table_of_contents’: /home/erik/lily/64gub/gubtest/target/darwin-ppc/src/odcctools-20060413/libstuff/writeout.c:1021: error: ‘union ’ has no member named ‘ran_name’ [...] Strangely, this didn't happen when building in 32-bit mode. > It would be nice if there were a less ad-hoc way of dealing with this. > Perhaps we could build GUB from a git repo of lilypond instead? Hm. For the moment, it would be sufficient for me if I just could tell gub to use the lily source from some given directory, using an environment variable or something. (i.e.: cd gub; export GUB_LILY_SRC=/home/erik/lily/lily-work-in-progress/ ; make linux ; make doc) Hm, perhaps I can already do this by substituting download/lilypond-HEAD/ with a symlink to the desired source. Using git would be a good solution too. It would also be an excuse for me to get started with git in my development (which presumably is a lot better than my current playing around with diff'n'patch) -- Erik ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB success.
Erik Sandberg wrote: Hi, Now gub works here (on my IA32 partition), so I can commit code again. I couldn't easily force a rebuild. If I have a patch I want to test, what should I do? I applied the patch to downloads/lilypond-HEAD, but I couldn't find a good way to force make or make linux to rebuild (the only way I could find was rm -r target/). The best way is to change downloads/lilypond-HEADS/.cvs-checksum. That file is a checksum of all CVS/Entries files, and if it's changed, GUB assumes it has to rebuild the thing. It would be nice if there were a less ad-hoc way of dealing with this. Perhaps we could build GUB from a git repo of lilypond instead? -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen LilyPond Software Design -- Code for Music Notation http://www.lilypond-design.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
GUB success.
Hi, Now gub works here (on my IA32 partition), so I can commit code again. I couldn't easily force a rebuild. If I have a patch I want to test, what should I do? I applied the patch to downloads/lilypond-HEAD, but I couldn't find a good way to force make or make linux to rebuild (the only way I could find was rm -r target/). -- Erik ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: notifications of GUB success?
On 8/24/06, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote: Hmmm, I'm not sure this is a good idea. Although it checks each release only once, it does run hourly, so this will generate a huge amount of email. Perhaps it would be better to only send a message when the status goes back from "failed" to "success". Yes, sounds sensible. It could also be good to let the autotester create a current-status webpage which it uploads to some static location, whenever it has finished (with fail or success). Would that be doable within the gub framework? -- Erik ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: notifications of GUB success?
Erik Sandberg wrote: Hi, Whenever the GUB autotester has failed and someone committed something new, I only want to update to the new revision if it is not broken. Would it be possible to add a brief "GUB autotester succeeded" message, similar to the current failure notice, which the autotester spits out whenever it succeeds? Hmmm, I'm not sure this is a good idea. Although it checks each release only once, it does run hourly, so this will generate a huge amount of email. Perhaps it would be better to only send a message when the status goes back from "failed" to "success". The source code is in test-gub.py inside the gub repository. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen LilyPond Software Design -- Code for Music Notation http://www.lilypond-design.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
notifications of GUB success?
Hi, Whenever the GUB autotester has failed and someone committed something new, I only want to update to the new revision if it is not broken. Would it be possible to add a brief "GUB autotester succeeded" message, similar to the current failure notice, which the autotester spits out whenever it succeeds? Erik ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
