Re: gub3 binaries, please test
Op donderdag 01-01-2009 om 18:32 uur [tijdzone -0200], schreef Han-Wen Nienhuys: > mismatch somewhere. Interestingly, if I run > > [lily...@haring glibc-core-2.3]$ pwd > /home/lilydev/vc/gub3/target/linux-x86/build/glibc-core-2.3 > [lily...@haring glibc-core-2.3]$ ls > ls: libc.so.6: version `GLIBC_2.4' not found (required by ls) > ls: libc.so.6: version `GLIBC_2.4' not found (required by > /lib/libselinux.so.1) > ls: libc.so.6: version `GLIBC_2.8' not found (required by > /lib/libselinux.so.1) > ls: libc.so.6: version `GLIBC_2.4' not found (required by /lib/libcap.so.2) > ls: libc.so.6: version `GLIBC_2.8' not found (required by /lib/libcap.so.2) > ls: libc.so.6: version `GLIBC_2.4' not found (required by /lib/libacl.so.1) > ls: libc.so.6: version `GLIBC_2.4' not found (required by /lib/libattr.so.1) > > perhaps there is some library version mismatch going on somewhere? Your ls that's linked to glibc >= 2.4 is trying to use GUB's glibc 2.3 What if you remove . from LD_LIBRARY_PATH ? Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: gub3 LDFLAGS error
Op donderdag 01-01-2009 om 13:46 uur [tijdzone -0800], schreef Graham Percival: > Yes, but I see that there's still some LD_LIBRARY_PATH in > gub/tools.py from the online git version -- lines 31 and 69. I see, you also removed the one at line 31 before. I was thinking Rainold was OK with leaving this one in place http://lists.gnu.org/archive/html/lilypond-devel/2008-12/msg00438.html I'll have a look. If we can remove this line-31 one in tools, that just might fix John & Han-Wen's fp problem too. Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: gub3 FP exception
Op donderdag 01-01-2009 om 17:54 uur [tijdzone -0200], schreef Han-Wen Nienhuys: > I'm toying with gub3 (on Fedora 10), but the compile halts at glibc-core, > > CPP='i686-linux-gcc -E -x c-header' > /home/lilydev/vc/gub3/target/linux-x86/build/glibc-core-2.3/elf/ld-linux > .so.2 --library-path > /home/lilydev/vc/gub3/target/linux-x86/build/glibc-core-2.3:/home/lilydev/vc/gub3/target/ > linux-x86/build/glibc-core-2.3/math:/home/lilydev/vc/gub3/target/linux-x86/build/glibc-core-2.3/elf:/home/lily > dev/vc/gub3/target/linux-x86/build/glibc-core-2.3/dlfcn:/home/lilydev/vc/gub3/target/linux-x86/build/glibc-cor > e-2.3/nss:/home/lilydev/vc/gub3/target/linux-x86/build/glibc-core-2.3/nis:/home/lilydev/vc/gub3/target/linux-x > 86/build/glibc-core-2.3/rt:/home/lilydev/vc/gub3/target/linux-x86/build/glibc-core-2.3/resolv:/home/lilydev/vc > /gub3/target/linux-x86/build/glibc-core-2.3/crypt:/home/lilydev/vc/gub3/target/linux-x86/build/glibc-core-2.3/ > linuxthreads > /home/lilydev/vc/gub3/target/linux-x86/build/glibc-core-2.3/sunrpc/rpcgen > -Y ../scripts -c rpcsvc > /bootparam_prot.x -o > /home/lilydev/vc/gub3/target/linux-x86/build/glibc-core-2.3/sunrpc/xbootparam_prot.T > make[2]: *** > [/home/lilydev/vc/gub3/target/linux-x86/build/glibc-core-2.3/sunrpc/xbootparam_prot.stmp] > Exceção > de ponto flutuante > make[2]: Saindo do diretório > `/home/lilydev/vc/gub3/target/linux-x86/src/glibc-core-2.3/sunrpc' > make[1]: ** [sunrpc/install-lib] Erro 2 > make[1]: Saindo do diretório > `/home/lilydev/vc/gub3/target/linux-x86/src/glibc-core-2.3' > make: ** [install-lib-all] Erro 2 > > > [floating point exception] > > Curiously, this is inside the install phase. Gub2 gets past > glibc-core without problems. Any ideas? I saw that gub3 relative to > gub2 has a install.patch, but it does not look related to me. Can you try if you get the FP when running the rpcgen command manually? See http://lists.gnu.org/archive/html/lilypond-devel/2008-11/msg00175.html You could play with LD_LIBRARY_PATH a bit then [or even ask gdb what's going on...] John's report flabergasted me too, but I can't reproduce it. Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: SCons support in LilyPond
Op vrijdag 02-01-2009 om 22:53 uur [tijdzone +0100], schreef John Mandereau: Hi John, > Have you any plan for maintaining Scons support in LilyPond? > The Python > code hasn't been updated to be compatible with Python 2.6/3.0, No. > and it > calls scripts in stepmake/bin or buildscripts that have been removed > several years ago. Ouch. And here I was hoping someone would see the beauty of scons and junk our stepmake cruft ;-) > If we have no interest in maintaining this, I > propose to remove it (SConscript files and buildscripts/builder.py), in > order to avoid confusion for people who discover the sources or > maintainers like me who update Python code and makefiles. Sure. Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: SCons support in LilyPond
Op zondag 04-01-2009 om 00:39 uur [tijdzone +0100], schreef John Mandereau: > I'm afraid it is too late to resurrect SCons, or too early if you > prefer. Yes, quite possibly. SCons has been the new great promising end all solution for Make for a few years too many, maybe. Having said that, past summer had a grand gsoc project to add autoconf/automake compatibility, which can be used to drop much custom hacked-up stuff from the lilypond SConstruct. > I remember a number of packages used a so-called revolutionary > program named SCons, I no longer encounter it. Maybe it's superior to > stepmake system, but we recently consolidated the makefiles enough (e.g. > support for -j make flag, cleaning up documentation compilation) so that > we can concentrate on other problems. Yes, and that's valuable too. SCons is still making progress, possibly in a few years time... > I will include this removal in the patch that splits stuff in > buildscripts. Ok. Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: gub3 LDFLAGS error
Op donderdag 01-01-2009 om 13:46 uur [tijdzone -0800], schreef Graham Percival: > Yes, but I see that there's still some LD_LIBRARY_PATH in > gub/tools.py from the online git version -- lines 31 and 69. Removing this works for a clean build of mingw:: and linux-64::lilypond on linux-64, so I've pushed this change. We'll have to see if it works for all other platforms and openoffice too... Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: SCons support in LilyPond
Op zaterdag 03-01-2009 om 11:58 uur [tijdzone -0800], schreef Graham Percival: > I had great success converting another project to cmake last Aug, > but this isn't anything I'd attempt with my current situation. I > might propose it for 2.15 or 2.17 (next fall or sometime next > year), though. Hmm. Two years ago I had great success converting a cmake project to autotools. Maybe things have changed, but at the time some of my reasons to drop cmake were * used a home-grown MACRO language, which * was mostly undocumented (half-baken proprietary documentation in hardcopy was available) and buggy * had nasty differences between builtin (c-made) and user-built macros * had error prone dependency generation, one of the (at least) two reasons for * often leaving the build tree in a broken state after ^C * generates makefiles (adding an evil level of caching; one of the reasons for us to reject automake) that easily go stale (unlike automake: often unnoticed) * mostly ignored common unix standards (not to mention GNU standards that LilyPond must provide) (clean/install/prefix/DESTDIR) * had no provision for package-config to find libraries, but * used /usr/bin/find (instead of gcc-based tests) to guess/find libraries * used hard-coded /usr to start the search, making * cross compiling (instead of mostly automagic: autotools) next to impossible, and would also * barf when multiple versions of libraries are present below /usr Have things changed? Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: copyright year update script issue
Op woensdag 07-01-2009 om 06:13 uur [tijdzone +0100], schreef Werner LEMBERG: > can you add a list of exceptions to your copyright year update script? > Some files like the mf2pt1 stuff are contributed and should stay > as-is. Why is this necessary? I think the whole copyright header is nonsense, as everything is automatically copyrighted by the author unless she adds a header stating otherwise; this is why we don't follow the GNU advise of 1996,1997,1998... etc but simply do 1996--2009 I thought that every year the software was released inneeds to be added to the (c) list, and as we release lilypond every year. Possibly an extra condition is that it has been changed since the last year it had been published, but do we really want to check that, and why? > I've fixed that manually in the git I'm not sure we really want different years than --2009, Han-Wen? > , but an automatic process > would be better. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: copyright year update script issue
Op woensdag 07-01-2009 om 10:27 uur [tijdzone +0100], schreef Werner LEMBERG: > Well, I think it is a kind of courteousy to leave `external' files > unchanged. Additionally, it simplifies updating. Okay... I just reread http://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html and while it says: just update every file, it does have an exception for "copied files" from other packages. I still don't truly understand; a copied file is a fork and therefore quite change-prone, whenever that happens the year may have to be updated. > Other files like > texinfo.tex should also stay as-is, without updating the copyright > year (which your script hasn't done BTW). Do you have a list of files to exclude? While we're at it, why don't we stop being so smart and different and just expand the years to 1996,1997,1998 etc, and/or replace the current headers with standard GNU GPL license notifications? Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.12.1 for cygwin?
Op zaterdag 10-01-2009 om 08:31 uur [tijdzone +0100], schreef Frédéric Bron: > Hi, is there a chance that we have a 2.12.1 release for cygwin? Yes, if you point your setup.exe to http://lilypond.org/cygwin/ and install guile-1.8.5 and lilypond-2.12.1 and tell me everything is OK, I'll have them uploaded. Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: copyright year update script issue
Op donderdag 08-01-2009 om 00:50 uur [tijdzone +0100], schreef Francisco Vila: > ~$ lilypond -v > GNU LilyPond 2.12.1 > > Copyright (c) 1996--2008 by > Han-Wen Nienhuys > Jan Nieuwenhuizen > and others. > > This is done in main.cc, I once changed it manually and it is now > outdated again, That's because it just turned 2009! > is this automatically updated by other means? Short answer: Try git pull ;-) Long answer: there is a copyright year in almost every file. Because people started changing copyright years in an ad-hoc fasion here and there, I put my naive every-file update commands in a script called grand-replace.sh. And executed the script. That's what Werner was complaining about^H^H^H^H^H^H^H^H^H noticing, sort of. Greetings, Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.12.1 for cygwin?
Op maandag 12-01-2009 om 10:39 uur [tijdzone +0100], schreef Frédéric Bron: > 2009/1/12 Jan Nieuwenhuizen : > > Yes, if you point your setup.exe to > > > >http://lilypond.org/cygwin/ > > > > and install guile-1.8.5 and lilypond-2.12.1 and tell me everything is > > OK, I'll have them uploaded. > > unable to get http://lilypond.org/cygwin//setup.ini.sig from > <http://lilypond.org/cygwin/> Google tells me it's probably easiest to ask you to use the new -X/--no-verify command line option to setup.exe. I'll have a look later if/how I can produce the .sig. Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: gub3 build fail: fonts
Op woensdag 31-12-2008 om 15:43 uur [tijdzone +0100], schreef Jan Nieuwenhuizen: > IWBN to do this ABI=32 think automagically (and from bin/gub or > gub/settings.py or gub/linux.py or something.) I've added a check to gub/settings.py; this may work nor or it may be necessary to add ABI=32 to configure_command or makeflags () in gmp.py Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: rsync for docs?
Op donderdag 15-01-2009 om 22:17 uur [tijdzone +0800], schreef Graham Percival: Hi Graham, > Why did you add an rsync dependency for the docs? For uploading > the docs, I'd understand, but for simply building them...? make web-install (and also make test) uses rsync. I found out trying to build the package for openSUSE. Greetings, Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Distribution updates and documentation woes
Hi, After 2.12 I decided to do my small round checking of distributions again (should we add something like this to release tasks?). Fedora already has 2.12 (yay!), while Debian and Ubuntu already had 2.12 wishlist bugs filed (great!), but none of the major distributions manages to provide proper images in the Info docs. Time for action! Debian http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=511676 2.12 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=511773 no images in Info docs Ubuntu https://bugs.launchpad.net/ubuntu/+source/lilypond/+bug/312544 2.12 https://bugs.launchpad.net/ubuntu/+source/lilypond/+bug/317067 no images in Info docs openSUSE https://bugzilla.novell.com/show_bug.cgi?id=466437 2.12, docs as unbuilt texinfo sources [but also: GPL 2 or later, extremely terse description, stale list of Authors, non-optimized build, etc.] Fedora Fedora is a special case, it uses our prebuilt documentation ball, so no simple patch can be provided. I think we need to fix this, other distributions may also go this way of using our pre-built doco. How to fix images in Info docs for Fedora? - distribute lilypond-info-man.tar.bz2 alongside documentation ball? - roll info (and man?) docs into documentation ball + How? docbal currently is rooted at ./Documentation, info would need to be moved to/unpacked at ../../info . - suggest make web, make web-install + adding of symlink See http://ftp.nluug.nl/pub/os/Linux/distr/fedora/linux/development/source/SRPMS/lilypond-doc-2.12.1-1.fc11.src.rpm IWBN if a fedora user would file the wishlist/bug once we settle on a fix. LilyPond.org And last but not least: what about our own documentation builds? Info docs are missing here altogether! Should we include info docs and re-root the documentation ball to look like share/doc/lilypond/Documentation/* share/info/dir share/info/* and/or provide a shar archive to extract the documentation into a proper place? Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Distribution updates and documentation woes
Op vrijdag 16-01-2009 om 10:01 uur [tijdzone +0100], schreef John Mandereau: Hi John, [snip all good stuff] > >share/doc/lilypond/Documentation/* > >share/info/dir > >share/info/* > > I'm for this too. Unless somebody wants to it right now, I'll have time to > do it next Wednesday. I'm looking into this for GUB3 and I can just insert the changes into gub2 (which is almost identical here) when it works. Lily's make web-install currently does most of the work already. Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
gub3 glibc FPE problem [was: gub3 binaries, please test]
Op donderdag 01-01-2009 om 18:32 uur [tijdzone -0200], schreef Han-Wen Nienhuys: > I am seeing this too, and it is reproducible. Since it is an FP > during the install stage, I would suspect some kind of low-level > mismatch somewhere. In an effort to push gub3 forward I just built up till gmp in a freshly debootstrapped lenny-x86 kvm (ie: 32 bit OS on 64 bit hw, this is where the problem was, right?). With latest gub3 I cannot reproduce this, so either it's fixed, or it is something system. What system is showing this problem? Here's some of my information, possibly playing with the system's gcc, binutils (or glibc, scary?) can help shed some light. Jan. dpkg -l binutils gcc g++ libc6 linux-image-2.6.* ii binutils2.18.1~cvs20080103-7The GNU assembler, linker and binary utilities ii g++ 4:4.3.2-2 The GNU C++ compiler ii gcc 4:4.3.2-2 The GNU C compiler ii libc6 2.7-18 GNU C Library: Shared libraries ii linux-image-2.6.26-1-6862.6.26-13 Linux 2.6.26 image on PPro/Celeron/PII/PIII/P4 13:40:13 jann...@debian:~/vc/gub/gub $ uname -a Linux debian 2.6.26-1-686 #1 SMP Sat Jan 10 18:29:31 UTC 2009 i686 GNU/Linux 13:40:33 jann...@debian:~/vc/gub/gub $ lsb_release -a No LSB modules are available. Distributor ID: Debian Description:Debian GNU/Linux 5.0 (lenny) Release:5.0 Codename: lenny 13:40:38 jann...@debian:~/vc/gub/gub -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: gub3 FP exception
Op zaterdag 17-01-2009 om 21:03 uur [tijdzone -0200], schreef Han-Wen Nienhuys: > trying a manual > > $ make DESTDIR=/tmp/foobar installp > why does DESTDIR not work on glibc-core? glibc (traditionally) uses install_root (an noone ever fixed this). Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.12.1 for cygwin?
Op maandag 12-01-2009 om 10:53 uur [tijdzone +0100], schreef Jan Nieuwenhuizen: > Google tells me it's probably easiest to ask you to use the new > -X/--no-verify command line option to setup.exe. Does this work, can I upload to Cygwin? Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: gub3 FP exception
Op maandag 19-01-2009 om 12:08 uur [tijdzone -0200], schreef Han-Wen
Nienhuys:
> OK thanks. For reasons I do not understand, issuing a
Yes, well: UTSL! See gub/specs/glibc-core.py:
def install_command (self):
return (glibc.Glibc.install_command (self)
.replace (' install ', ' install-lib-all install-headers ')
# avoid -lgcc_eh, which gcc-core does not have
+ ' gnulib=-lgcc')
HTH, Jan.
> PATH=/home/lilydev/vc/gub3/target/linux-x86/root/usr/cross/bin/:$PATH
> make install_root=/tmp/isr install
>
> triggers a compile of iconv, which ends in
>
>
> c_eh `i686-linux-gcc --print-file-name=crtend.o`
> /home/lilydev/vc/gub3/target/linux-x86/build/glibc-core-2.3/csu/crtn.o
> /home/lilydev/vc/gub3/target/linux-x86/root/usr/cross/bin/i686-linux-ld:
> cannot find -lgcc_eh
> collect2: ld returned 1 exit status
> make[2]: ***
> [/home/lilydev/vc/gub3/target/linux-x86/build/glibc-core-2.3/iconv/iconv_prog]
> Error 1
>
>
> There is no libgcc_eh in the gub3 directory,
>
> find /home/lilydev/vc/gub3/target/linux-x86/root/ -name libgcc'*'
> =>
>
> /home/lilydev/vc/gub3/target/linux-x86/root/usr/cross/lib/gcc/i686-linux/4.1.1/libgcc.a
>
>
> I do have libgcc_eh in gub2, and in /usr/lib/
>
> [lily...@haring glibc-core-2.3]$ locate
> libgcc_eh/home/lilydev/vc/gub/target/darwin-ppc/root/usr/cross/lib/gcc/powerpc-apple-darwin7/4.1.1/libgcc_eh.a
> /home/lilydev/vc/gub/target/darwin-x86/root/usr/cross/lib/gcc/i686-apple-darwin8/4.2.3/libgcc_eh.a
> /home/lilydev/vc/gub/target/freebsd-64/root/usr/cross/lib/gcc/x86_64-freebsd6/4.1.2/libgcc_eh.a
> /home/lilydev/vc/gub/target/freebsd-x86/root/usr/cross/lib/gcc/i686-freebsd4/4.1.2/libgcc_eh.a
> /home/lilydev/vc/gub/target/linux-64/root/usr/lib/libgcc_eh.a
> /home/lilydev/vc/gub/target/linux-ppc/root/usr/lib/libgcc_eh.a
> /home/lilydev/vc/gub/target/linux-x86/root/usr/lib/libgcc_eh.a
> /home/lilytest/gub/target/linux-x86/system/usr/cross/lib/gcc/i686-linux/4.1.1/libgcc_eh.a
> /usr/lib/gcc/i386-redhat-linux/4.3.2/libgcc_eh.a
>
>
>
> On Mon, Jan 19, 2009 at 7:45 AM, Jan Nieuwenhuizen
> wrote:
> > Op zaterdag 17-01-2009 om 21:03 uur [tijdzone -0200], schreef Han-Wen
> > Nienhuys:
> >
> >> trying a manual
> >>
> >> $ make DESTDIR=/tmp/foobar installp
> >
> >> why does DESTDIR not work on glibc-core?
> >
> > glibc (traditionally) uses install_root (an noone ever fixed this).
> >
> > Jan.
> >
> > --
> > Jan Nieuwenhuizen | GNU LilyPond - The music typesetter
> > http://www.xs4all.nl/~jantien | http://www.lilypond.org
> >
> >
>
>
>
--
Jan Nieuwenhuizen | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien | http://www.lilypond.org
--
Jan Nieuwenhuizen | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien | http://www.lilypond.org
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: gub3 FP exception
Op dinsdag 20-01-2009 om 11:03 uur [tijdzone -0200], schreef Han-Wen Nienhuys: > I've added a TODO; I am a little bit suspicious, because the install > triggers a slew of compiles. Ok, moved to makeflags (), works for me. > > Btw, how about #lilyp...@freenode? > > I don't spend that much time that that would be worthwhile. For quick > questions and urgent matters I'm logged into my Google Talk during day > (and work) time. Ah, but that's much less easy to ignore than irc ;-) Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
people seen whohas yet?
universehttp://packages.ubuntu.com/hardy/lilypond-doc Ubuntu lilypond-doc 2.10.33-2.2build1 universehttp://packages.ubuntu.com/intrepid/lilypond-doc Ubuntu lilypond-doc 2.12.1-0ubuntu1 universehttp://packages.ubuntu.com/jaunty/lilypond-doc FreeBSD lilypond 2.11.65_1 print http://www.freebsd.org/cgi/pds.cgi?ports/print/lilypond openSUSElilypond 2.10.33 suse/oss http://packages.opensuse-community.org/packageinfo.jsp?checksum=b0728ed5fc3489f0a23644d341da6df229d46c8e&distro=openSUSE_111 openSUSElilypond-documentation2.10.33 suse/oss http://packages.opensuse-community.org/packageinfo.jsp?checksum=eb1fa3a342ff9362f277e8594a7f2be044ba2451&distro=openSUSE_111 openSUSElilypond-kde4 0.2 j-engel/ope http://packages.opensuse-community.org/packageinfo.jsp?checksum=4c8a7126ce44efd83415124d1aba77a8daa30c09&distro=openSUSE_111 openSUSElilypond 2.12.1 openSUSE http://packages.opensuse-community.org/packageinfo.jsp?checksum=1153ef263284823fe3ddf27637cfb8f226b5ca83&distro=openSUSE_111 openSUSElilypond-debuginfo2.12.1 openSUSE http://packages.opensuse-community.org/packageinfo.jsp?checksum=f16f92c174329f2394afdac596cc1ecf3aad20c6&distro=openSUSE_111 openSUSElilypond-debugsource 2.12.1 openSUSE http://packages.opensuse-community.org/packageinfo.jsp?checksum=c76821c7170ac8c996e813a9c2754d1d5aac9b57&distro=openSUSE_111 openSUSElilypond-documentation2.12.1 openSUSE http://packages.opensuse-community.org/packageinfo.jsp?checksum=a8e369e3cf11222534503e467223ee8625b10385&distro=openSUSE_111 Source Mage lilypond 2.10.33 test Source Mage lilypond 2.10.33 stable Gentoo lilypond 2.12.1 http://gentoo-portage.com/media-sound/lilypond Gentoo lilypond 2.11.65 http://gentoo-portage.com/media-sound/lilypond Gentoo lilypond 2.11.64 http://gentoo-portage.com/media-sound/lilypond Gentoo lilypond 2.11.63 http://gentoo-portage.com/media-sound/lilypond Gentoo lilypond 2.11.58 http://gentoo-portage.com/media-sound/lilypond Gentoo lilypond 2.11.56 http://gentoo-portage.com/media-sound/lilypond Gentoo lilypond 2.11.52 http://gentoo-portage.com/media-sound/lilypond Gentoo lilypond 2.11.51 http://gentoo-portage.com/media-sound/lilypond Gentoo lilypond 2.11.50 http://gentoo-portage.com/media-sound/lilypond Gentoo lilypond 2.10.33 http://gentoo-portage.com/media-sound/lilypond Gentoo lilycomp 1.0.2-r1 http://gentoo-portage.com/media-sound/lilycomp Gentoo ec-fonts-mftraced 1.0.8 http://gentoo-portage.com/media-fonts/ec-fonts-mftraced Fedora lilypond 2.11.57-14.3M 30-10-2008 Fedora lilypond-doc 2.11.57-1 59M 30-10-2008 OpenBSD lilypond 2.10.33p1 http://www.openbsd.org/4.4_packages/i386/lilypond-2.10.33p1.tgz-long.html OpenBSD lilypond-docs 2.10.33 http://www.openbsd.org/4.4_packages/i386/lilypond-docs-2.10.33.tgz-long.html 09:57:32 jann...@heerbeest:~ $ -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: people seen whohas yet?
Op vrijdag 30-01-2009 om 10:58 uur [tijdzone +0100], schreef Francisco Vila: > Interesting. Who has whohas? (Seriously. I think Ubuntu doesnt, for example) Sure it does, but you need [to pull it from] Jaunty. 11:03:01 jann...@heerbeest:~ $ whohas whohas Archwhohas0.22-1 unsupported http://aur.archlinux.org/packages.php?ID=21580 NetBSD whohas0.22 misc http://pkgsrc.se/misc/whohas Ubuntu whohas0.22-1 universehttp://packages.ubuntu.com/jaunty/whohas Source Mage whohas0.22 test Source Mage whohas0.21 stable openSUSEwhohas0.22 helions8/op http://packages.opensuse-community.org/packageinfo.jsp?checksum=17bc534f4e189800f225989299117336540dd370&distro=openSUSE_111 11:04:30 jann...@heerbeest:~ $ -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: OT: Some git statistics
Op maandag 02-02-2009 om 19:39 uur [tijdzone +0100], schreef Francisco Vila: > 2009/2/2 Han-Wen Nienhuys : > > Fred is what Jan used to call himself on his home machine. > > Impossible. Was he the one and only committer for 6+ years? Fred was me when I populated the history of our CVS using tarball releases and patches, using a cheesy script. The first six years we used tarball releases and mailing patches. We usually had a pattern like [hanwen]: lilypond-0.0.60.tar.gz [jan]:lilypond-0.0.60.jcn.diff.gz -> mail to hanwen [hanwen]: lilypond-0.0.60.hwn1.diff.gz -> hanwen's hacks + jcn1 -> mail to jan OR [hanwen]: lilypond.0.0.60.hwn1.diff.gz -> mail to jan [jan]:lilypond-0.0.60.jcn2.diff.gz -> includes .hwn1 -> mail to hanwen until we got to .jcn/.hwn 3/4/5 and Han-Wen made a new release. This then included patches sent to the list by Mats [.mb], Werner [.wl] and others. See also http://repo.or.cz/w/lilypond.git?a=blob;f=Documentation/misc/CHANGES-0.0;h=f936254a1f7a92f043954bae0689c52375b3b2f1;hb=HEAD It would be nice but hardly doable to make a much better history, as most of the intermediate releases and patches have been lost [I think]. Not all intermediate patches had good changelog entries. Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Good luck, Valentin
Op woensdag 04-02-2009 om 10:41 uur [tijdzone +0100], schreef Valentin Villenave: > > Wow! This is a major work! It must be the largest LilyPond score > > ever! I compiled the full score last night to peruse, and it looks > > awesome. The pdf file is 6.65 Mb! > > Thanks a lot, but this is nothing compared to Nicolas' work :-) > (I haven't had a chance to have a look at Kieren's works either, but > I'm sure it's quite impressive too.) Wouldn't it be nice to reference some of these great works from lilypond.org? [I guess it's a bit late for a concert announcement for The Foreign Affair'] Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Building GUB3
Op zondag 08-02-2009 om 01:06 uur [tijdzone +0100], schreef Reinhold Kainhofer: > > Attached is the relevant part of config.log. *interesting* > That's the same problem I encountered a while ago (see the discussion > December > 12-16). Removing LD_LIBRARY_PATH from the build files fixed it. I'm not sure > if that has any side-effects, though. .. ...but, all generic LD_LIBRARY_PATH settings have been removed from GUB head. Patrick, does your system have a /usr/lib/libltdl.so.3 ? Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Building GUB3
Op zondag 08-02-2009 om 11:22 uur [tijdzone -0800], schreef Patrick McCarty: > No, I have > /usr/lib/libltdl.so.7 Ah, good. Lots has been going on and I could reproduce this problem. Could you try gub3 HEAD, you'll get a full rebuild... Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Building GUB3
On ma, 2009-02-09 at 17:06 -0800, Patrick McCarty wrote: Hi Patrick, > The Guile problem appears to be fixed, but now gmp fails in the > configure stage for the linux-64 target. configure:3847: x86_64-linux-gcc -m32 -O2 -fomit-frame-pointer conftest.c >&5 /home/pnorcks/git/gub/target/linux-64/root/usr/cross/bin/x86_64-linux-ld: skipping incompatible /home/pnorcks/git/gub/target/linux-64/root/usr/lib/../lib/libgcc.a when searching for -lgcc /home/pnorcks/git/gub/target/linux-64/root/usr/cross/bin/x86_64-linux-ld: skipping incompatible /home/pnorcks/git/gub/target/linux-64/root/usr/lib/libgcc.a when searching for -lgcc /home/pnorcks/git/gub/target/linux-64/root/usr/cross/bin/x86_64-linux-ld: cannot find -lgcc So, gcc -m32 is trying to link to a 64 bit library. That does not work. I see that ABI=32, so I assume that you run a 32 bit OS on 64 bit hardware? And are cross building lilypond for linux-64? It looks as if the ABI=32 fix breaks that. Could you try latest HEAD, there's an attempted fix for that. > Additionally, I needed the attached patch, which fixes a URL. Applied, thanks! Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Building GUB3
On wo, 2009-02-11 at 11:22 -0800, Patrick McCarty wrote: > Hmm. I'm running a 32-bit OS and have 32-bit hardware. But gmp > compiled successfully after your fix though. Interesting. What's the output of cat /proc/cpuinfo? > Now GUB halts at tools::libjpeg. Attached is the end of my build.log. Interesting bug. ltconfig is trying to use `tools' for the host system, that does not work :-) This is the ugly result of adding an update_libtool () to target.py combined with multiple inheritance. Ugh. So, apart from not updating libtool here, I've now also fixed the target architecture, platform etc when building tools; makes much more sense. Oh, I've push a whole slew of fixes that will trigger a grand rebuild... Thanks, Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: which fontforge version?
On wo, 2009-02-11 at 22:25 +0100, Matthias Kilian wrote: Hi Matthias, > while working on an update of the openbsd port of lilypond, i see > lots of fontforge whinings like this one: > Internal Error in accidentals.flat.arrowdown: monotonic is both needed and > unneeded. Indeed, these glyphs were recently added and seem to have issues. Max, what's the status on this? > What (hopefully newer) version fontforge is typically used for lilypond? Nope, we use 20080927 too. > And: does anyone using fontforge-20080927 on other operating systems > running into those errors? I see them in my logs too. Thanks for bringing this up, Greetings, Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: which fontforge version?
On wo, 2009-02-11 at 22:41 +0100, Werner LEMBERG wrote: > I'm currently using a CVS version dated 2009-Jan-23, and I don't get a > single warning. Great, I'll update GUB then. Greetings, Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Building GUB3
On do, 2009-02-12 at 22:27 +0100, John Mandereau wrote:
Hi John,
> I tried building GUB again yesterday. The fix for libjpeg works for me,
> but I get the error in the attached log.
> I made
>
> make -f lilypond.make bootstrap
>
> on a Fedora 9 x86_64 box (I used to simply "make -f lilypond.make", but
> it looked like it didn't build all dependencies for building
> LilyPond itself a few weeks ago.)
A couple of dependencies are moved to the lilypond-doc package.
In gub/specs/cross/binutils.py I have commented-out a fix for
this by prepending 'FIXME_breaks_on_some_linuxes_'
def FIXME_breaks_on_some_linuxes_install (self):
# please document why this should be removed?
cross.AutoBuild.install (self)
self.system ('rm %(install_prefix)s%(cross_dir)s/lib/libiberty.a')
It seems that on some systems binutils *and* gcc build libiberty, on
other systems only gcc does. It looks like we need this fix but it
must be allowed to fail...
self.system ('rm %(install_prefix)s%(cross_dir)s/lib/libiberty.a',
ignore_errors=True)
Jan.
--
Jan Nieuwenhuizen | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien | http://www.lilypond.org
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
dist-check error: Documentation/ja not distributed
Hi, GUB gives me the errors below. Jan. file from VC not distributed: lilypond-2.12.1/Documentation/ja/GNUmakefile file from VC not distributed: lilypond-2.12.1/Documentation/ja/user/GNUmakefile file from VC not distributed: lilypond-2.12.1/Documentation/ja/user/fundamental.itely file from VC not distributed: lilypond-2.12.1/Documentation/ja/user/introduction.itely file from VC not distributed: lilypond-2.12.1/Documentation/ja/user/lilypond-learning.tely file from VC not distributed: lilypond-2.12.1/Documentation/ja/user/preface.itely file from VC not distributed: lilypond-2.12.1/Documentation/ja/user/scheme-tutorial.itely file from VC not distributed: lilypond-2.12.1/Documentation/ja/user/templates.itely file from VC not distributed: lilypond-2.12.1/Documentation/ja/user/tutorial.itely file from VC not distributed: lilypond-2.12.1/Documentation/ja/user/tweaks.itely file from VC not distributed: lilypond-2.12.1/Documentation/ja/user/working.itely -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: dist-check error: Documentation/ja not distributed
On vr, 2009-02-13 at 17:18 -0200, Han-Wen Nienhuys wrote: > Can you update your lily release? I released 2.12.2 a while ago. Oops, thanks. At least it works well, my local.make ;-) Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Building GUB3
On wo, 2009-02-11 at 20:48 -0800, Patrick McCarty wrote: Hi Patrick, > Okay, now it halts at mingw::guile. Everything is fine up until then. > Here is the tail end of build.log. Okay. So seems that guile >= 1.8.4 has some import/export problems with static libraries /bin/sh ../libtool --tag=CC --mode=link i686-mingw32-gcc -mms-bitfields -g -O2 -Wall -Wmissing-prototypes -Wl,-rpath -Wl,\$ORIGIN/../lib -o guile.exe guile-guile.o libguile.la -lregex -lgmp -lws2_32 -lm -lltdl libtool: link: i686-mingw32-gcc -mms-bitfields -g -O2 -Wall -Wmissing-prototypes -Wl,-rpath -Wl,\$ORIGIN/../lib -o .libs/guile.exe guile-guile.o ./.libs/libguile.a -lintl -lregex -lgmp -lws2_32 -lltdl guile-guile.o: In function `main': /home/pnorcks/git/gub/target/mingw/src/guile-1.8.6/libguile/guile.c:70: undefined reference to `__imp__scm_c_argv0_relocation' /home/pnorcks/git/gub/target/mingw/src/guile-1.8.6/libguile/guile.c:72: undefined reference to `__imp__scm_boot_guile' guile-guile.o: In function `inner_main': /home/pnorcks/git/gub/target/mingw/src/guile-1.8.6/libguile/guile.c:55: undefined reference to `__imp__gdb_options' and has been reported with suggested fix http://lists.gnu.org/archive/html/bug-guile/2008-05/msg00016.html but it hasn't made it into the stable branch so it seems. Anyway, we're not interested in that, because we want to build shared libraries; and that's what happens on my box. In your logs, I see /bin/sh ../libtool --tag=CC --mode=link i686-mingw32-gcc -mms-bitfields -g -O2 -Wall -Wmissing-prototypes -lintl -version-info 20:0:3 -export-dynamic -no-undefined -Wl,-rpath -Wl,\$ORIGIN/../lib -o libguile.la -rpath /usr/lib libguile_la [..] *** Warning: linker path does not have real file for library -lintl. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libintl but no candidates were found. (...for file magic test) *** Warning: linker path does not have real file for library -lregex. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libregex but no candidates were found. (...for file magic test) *** Warning: linker path does not have real file for library -lgmp. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libgmp and none of the candidates passed a file format test *** using a file magic. Last file checked: /usr/lib//libgmp.so.3.4.4 which causes the shared library to fail. In my log I have the very same libtool link command, but it results in Creating library file: .libs/libguile.dll.a libtool: link: ( cd ".libs" && rm -f "libguile.la" && ln -s "../libguile.la" "libguile.la" ) so the question is: why is your libintl (and other libs) not found by libtool. Do you have target/mingw/root/usr/lib/libintl.la target/mingw/root/usr/bin/libintl-8.dll and does the libintl.la make sense? It is annoying that libtool mentions checking /usr/lib/libgmp.so; it should not be looking there. You could look if you can make any sense of running the libtool link command with -x /bin/sh -x ../libtool IWBN if GUB were to disallow libtool to read from /usr. [..] I finally cooked-up a patch for that, it took a bit more work than I imagined. With latest GUB3 you can do LIBRESTRICT=open:stat bin/gub mingw::guile # or mingw::lilypond This will disallow libtool to read from or stat in /, so this should (from target/mingw/log/build.log) give us a clue why libtool reads from /usr/lib on your machine. Oh, this will trigger a full rebuild ;-) Greetings, Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Building GUB3
On do, 2009-02-12 at 22:27 +0100, John Mandereau wrote: Hi John, > I tried building GUB again yesterday. The fix for libjpeg works for me, > but I get the error in the attached log. Ah, you reported something like this before... A fixlet for this is in HEAD (full rebuild ahead). Greetings, Jan -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Building GUB3
On za, 2009-02-14 at 02:59 +0100, John Mandereau wrote:
Hi John,
> I have a (proably simple) problem with current HEAD for building
> librestrict, which may be trivial
> but which I couldn't fix quickly myself:
Tried a couple of things but could not reproduce this.
What's the command you issued? Can you try removing the
root and any librestrict/make packages:
rm -rf target/tools/root
rm target/tools/packages/{make,librestrict}*
Jan.
--
Jan Nieuwenhuizen | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien | http://www.lilypond.org
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Building GUB3
On zo, 2009-02-15 at 00:29 +0100, John Mandereau wrote: > I get the error I reported when running > > rm -rf target > make -f lilypond.make bootstrap Interesting, that works for me. What's your python version? Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Building GUB3
On za, 2009-02-14 at 13:42 -0800, Patrick McCarty wrote: Hi Patrick, > I decided to start completely from scratch with `make lilypond' to see > if I could reproduce the current libtool issue, but I ran into some > other problems. I will revisit this issue soon. > > The problem I am having is that fontconfig, ghostscript, guile, and > lilypond are not downloaded! Directories such as > downloads/fontconfig, downloads/lilypond, etc. are not even created at > the start of the build process. Yeah, I broke GIT downloads, Han-Wen fixed this yesterday night. > This is resulting is all sorts of ugly errors like the following: > > /bin/sh: line 0: cd: /home/pnorcks/git/gub/downloads/lilypond: No such > file or directory > read_pipe failed: cd /home/pnorcks/git/gub/downloads/lilypond && git show > git.sv.gnu.org/lilypond.git/master:VERSION This code tries to look at the actual versions of the downloaded git repositories. Before any build ord download happens, all python code is executed and build commands are checksummed. The first time however, no downloaded tree is available. This is expected but should be harmless; a fix would be nice but is so easy, I imagine. Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Building GUB3
On zo, 2009-02-15 at 03:00 -0800, Patrick McCarty wrote: > In the download stage, everything downloads fine except for guile; > guile is immediately skipped over after the `*** Stage: download > (guile, tools)' line is printed. See 1-build.log. Is guile supposed > to download at this stage? No, only after GIT has been built and installed. But, download () was removed as a stage. This should be fixed in HEAD. Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Building GUB3
On zo, 2009-02-15 at 19:05 +0100, John Mandereau wrote: > 2.5.1. I hope it's easy to install a newer Python in $HOME if it's > needed to build GUB. GUB *should* work with 2.4 or newer. This is weird. Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Building GUB3
On zo, 2009-02-15 at 19:58 +0100, Jan Nieuwenhuizen wrote:
> GUB *should* work with 2.4 or newer. This is weird.
Does the attached patch help?
Jan.
--
Jan Nieuwenhuizen | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien | http://www.lilypond.org
diff --git a/gub/specs/librestrict.py b/gub/specs/librestrict.py
index c657931..48c0da3 100644
--- a/gub/specs/librestrict.py
+++ b/gub/specs/librestrict.py
@@ -3,7 +3,7 @@ import os
from gub import tools
from gub import misc
-class Librestrict__tools (tools.MakeBuild):
+class Librestrict_make__tools (tools.MakeBuild):
source = 'url://host/librestrict-1.9a.tar.gz'
def librestrict_flavours (self):
return list (sorted (os.environ.get ('LIBRESTRICT',
@@ -39,7 +39,7 @@ class Librestrict__tools (tools.MakeBuild):
def LD_PRELOAD (self):
return ''
-class Librestrict_nomake__tools (Librestrict__tools):
+class Librestrict_nomake__tools (Librestrict_make__tools):
def compile_command (self):
# URG, must *not* have U __stack_chk_fail@@GLIBC_2.4
# because glibc-[core-]2.3 will not install with LD_PRELOAD
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Building GUB3
On zo, 2009-02-15 at 12:03 -0800, Patrick McCarty wrote: Hi Patrick, > Thanks! It looks like Guile has downloaded, but now I get the > following traceback: > I am unsure how to fix this. I am running Python 2.6.1. git pull ;-) Although it will print lots of warnings/errors to the console. This is a >= 2.6 issue, the right fix seems to be a bit of work. Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Building GUB3
iOn zo, 2009-02-15 at 19:13 -0800, Patrick McCarty wrote: Hi Patrick, > Those files exist, and libintl.la looks correct. It is not executable > (755) like all of the other .la files I see, but this does not seem to > make a difference; compilation still fails. Ok. I figure that libtool reads from /usr first, or possibly another library is missing in your gub build root [or a combination of that]. > >/bin/sh -x ../libtool > > I cannot figure out how to do this. Is there an easy way to do this > with GUB? Edit gub/specs/guile.py:Guile__mingw remove the prepending X def Xmakeflags (self): # hack for (only) running libtool under dash-librestrict. return (Guile.makeflags (self) + ''' 'LIBTOOL=%(tools_prefix)s/bin/dash $(top_builddir)/libtool' ''') and change to ''' 'LIBTOOL=/bin/bash -x $(top_builddir)/libtool' ''' You'll have to run without LIBRESTRICT=open:stat > >LIBRESTRICT=open:stat bin/gub mingw::guile # or mingw::lilypond > > Starting fresh, this halts at tools::tar. Attached are relevant > sections of build.log and config.log. Ah, my restrict-stat.c hack broke your stat function. Ouch. I had the impression that Han-Wen also ran 32 bits and it worked there. Otherwise I hope he can give some insight/fixes :-) Han-Wen? Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Building GUB3
On ma, 2009-02-16 at 01:11 +0100, John Mandereau wrote:
> Jan Nieuwenhuizen a écrit :
> > Does the attached patch help?
> It doesn't, I get exactly the same error :-(
Thanks for trying... I'm a bit at loss how to fix this without being
able to reproduce it. I can think of one other thing to try,
otherwise I hope that Han-Wen has an idea?
>From the logs it is clear that the librestrict.py is being read,
but the appropriate class is not found.
It almost looks like
a python-2.5.1 (or possibly ever a race-) problem. What if you
add at the bottom of gub/specs/librestrict.py
Librestrict_open__tools = Librestrict__tools
> I hope the attached full output from the terminal may give a hint. What
> I don't get is that during first GUB invocation
> ("python bin/gub --platform=tools git"), a lot of packages in tools are
> built, then a new invocation
> (python bin/gub --platform=tools ...") explictly calls building of
> librestrict-open, make and a lot of other packages.
> Why not doing only one GUB invocation from the makefile?
Yes, that's where we're going. This bootstrap idea is from the old
days that gub could not handle cross-target dependencies. Also
it's playing safe: first build GIT, then the other tools, then
the cross compilers, then the rest.
Jan.
--
Jan Nieuwenhuizen | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien | http://www.lilypond.org
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Building GUB3
On ma, 2009-02-16 at 11:19 +0100, Jan Nieuwenhuizen wrote: Hi Patrick, > > >LIBRESTRICT=open:stat bin/gub mingw::guile # or mingw::lilypond > > > > Starting fresh, this halts at tools::tar. Attached are relevant > > sections of build.log and config.log. > > Ah, my restrict-stat.c hack broke your stat function. Ouch. I had > the impression that Han-Wen also ran 32 bits and it worked there. > Otherwise I hope he can give some insight/fixes :-) Han-Wen? This is getting uglier than I hoped. I verified your xstat problem on an i386 box and made it work there, pulling some xstat_conv () from glibc. Can you have another go at LIBRESTRICT=open:stat bin/gub mingw::guile Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Building GUB3
On ma, 2009-02-16 at 16:39 -0800, Patrick McCarty wrote: Hi Patrick, > Using LIBRESTRICT=open:stat no longer breaks the build for me. But > the output of build.log does not seem to provide any useful > information, besides `dash' being used instead of `sh'. Great. I don't understand it does not break when looking in /lib and /usr/lib, though. (..) Ah, dash has a test builtin. That figures. This fix will take some time to test before I can push... > The build.log for the `/bin/bash -x' trial shows the search path used > by libtool. See the attached log for the search order. I left out > the contents of my PATH, which were searched through last. Okay. Below is my sys_lib_search_path_spec, notice the target/mingw/root/usr/lib bit. What does yours (target/mingw/root/usr/lib/libtool) look like? Jan. # Compile-time system search path for libraries. sys_lib_search_path_spec="/home/janneke/vc/gub/target/mingw/root/usr/cross/lib/gcc/i686-mingw32/4.1.1/ /usr/lib/gcc/i686-mingw32/4.1.1/ /home/janneke/vc/gub/target/mingw/root/usr/cross/lib/gcc/i686-mingw32/4.1.1/../../../../i686-mingw32/lib/i686-mingw32/4.1.1/ /home/janneke/vc/gub/target/mingw/root/usr/cross/lib/gcc/i686-mingw32/4.1.1/../../../../i686-mingw32/lib/ /home/janneke/vc/gub/target/mingw/root/usr/lib/i686-mingw32/4.1.1/ /home/janneke/vc/gub/target/mingw/root/usr/lib/" -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Building GUB3
On di, 2009-02-17 at 01:58 -0800, Patrick McCarty wrote: Hi Patrick, > I managed to find a temporary workaround by adding > $HOME/git/gub/target/mingw/root/usr/lib to my PATH. Then libtool > found the .la files (and the .a file in the case of ws2_32), and > mingw::guile built successfully. Great. Wow, that's ugly though; this means probably that the build can also be broken by adding a wrong directory to PATH. Hmm. > It seems strange that libtool does not include > target/mingw/root/usr/lib in its search path on my machine (but it > does on yours). Yes, see my other mail... I really want to hunt this one down... > With that workaround, I can now build LilyPond for all target > platforms except for darwin-x86. GUB fails at darwin-x86::gmp. See > the attached config.log. Okay, this is prolly what Han-Wen was talking about, a linux-x86 on 64 bits hardware problem. Should be fixed, thanks! Greetings, Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Building GUB3
On di, 2009-02-17 at 13:55 -0800, Patrick McCarty wrote:
Hi Patrick,
> With the latest HEAD, gmp fails at configure for both darwin-x86 and
> darwin-ppc. The ppc build was successful for me before your last
> commit "Do not set ABI ...".
Okay, reverted. Together with Han-Wen's
2852b2e... Apply patch to GMP to include gmpn_{add,sub}_c in the library.
that should fix gmp.
Jan.
--
Jan Nieuwenhuizen | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien | http://www.lilypond.org
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Building GUB3
On di, 2009-02-17 at 10:40 -0800, Patrick McCarty wrote:
Hi Patrick,
> # Compile-time system search path for libraries.
> sys_lib_search_path_spec=" =./i686-pc-linux-gnu/4.3.3/ ./
> /usr/lib/gcc/i686-pc-linux-gnu/4.3.3/ /usr/lib/gcc/i686-pc-linux-gnu/4.3.3/
> /usr/lib/gcc/i686-pc-linux-gnu/4.3.3/../../../../i686-pc-linux-gnu/lib/i686-pc-linux-gnu/4.3.3/
> /usr/lib/gcc/i686-pc-linux-gnu/4.3.3/../../../../i686-pc-linux-gnu/lib/
> /usr/lib/gcc/i686-pc-linux-gnu/4.3.3/../../../i686-pc-linux-gnu/4.3.3/
> /usr/lib/gcc/i686-pc-linux-gnu/4.3.3/../../../ /lib/i686-pc-linux-gnu/4.3.3/
> /lib/ /usr/lib/i686-pc-linux-gnu/4.3.3/ /usr/lib/"
Ah, well that's totally bogus. It should be filled by this command
in libtools' configure
mingw* | cegcc*)
# MinGW DLLs use traditional 'lib' prefix
soname_spec='${libname}`echo ${release} | $SED -e
's/[.]/-/g'`${versuffix}${shared_ext}'
sys_lib_search_path_spec=`$CC -print-search-dirs | $GREP "^libraries:" |
$SED -e "s/^libraries://" -e "s,=/,/,g"`
Where CC should be i686-mingw32-gcc
Aussuming that
target/mingw/root/usr/cross/bin/i686-mingw32-gcc -print-search-dirs | grep
^libraries
prints something sane (ie, starting with target/mingw/root/usr/lib and
no i686-pc-linux-gnu elements in it), could you try running libtool's
configure with -x and see how this sys_lib_search_path_spec gets set?
In gub/specs/libtool.py, in class Libtool add a configure_command
function:
def configure_command (self):
return (' bin/bash +x '
+ target.AutoBuild.configure_command (self))
Jan.
--
Jan Nieuwenhuizen | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien | http://www.lilypond.org
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: gub3 progress
On di, 2009-02-17 at 23:10 -0300, Han-Wen Nienhuys wrote: > Working platforms: linux-x86, mingw, linux-ppc, linux-64, > freebsd-x86, darwin-x86, darwin-ppc. > > Still failing: freebsd-64: Great! Just fyi, with GUB3 HEAD, freebsd-64 still builds for me http://lilypond.org/~janneke/freebsd-64-binutils.log [Hmm, should we add git-commitishes and time stamps to log?] Question is if that's good or bad, GUB builds giving different results (ok/fail) when moving between jaunty-64bit and (I presume?) fedora 32bit. Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Re: Building GUB3
On wo, 2009-02-18 at 11:41 +0100, John Mandereau wrote: Hi John, > I needed the attached patch (error log attached too) to succesfully > complete "make -f lilypond.make bootstrap". Thanks, applied. It puzzles me that on darwin libiberty is installed in lib64... Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GUB3] How should Guile and Flex be built?
On wo, 2009-02-18 at 11:48 +0100, John Mandereau wrote: > After a successful bootstraping stage, I tried "make -f lilypond.make" > and "make -f lilypond.make installers"; both failed with the attached log. Weird. Dependencies seem to be failing utterly. But how? Han-Wen, any great ideas? > In bootstraping, Flex and Guile are built for target "tools", which I > find strange, whereas they are not built for each target platform. I > also miss Python building. What are the recommended commands to build > these three depencdencies before attempting at building Lily binaries? You did what is recommended. bin/gub however tells you exactly what it is going to do in its 'must rebuild' line, eg $ LIBRESTRICT=open:stat nice bin/gub --keep mingw::lilypond calculating dependencies must rebuild[mingw]: glib pango pthreads-w32 python urw-fonts lilypad tools::icoutils linux-x86::cross/binutils linux-x86::cross/gcc-core linux-x86::glibc-core linux-x86::cross/gcc linux-x86::glibc tools::scons tools::nsis lilypond [..] the target that librestrict gets is [PLATFORM::]lilypond, which is exactly what lilypond.make will do. If you need, you can look-up the dependencies in gub/specs/lilypond.py: _get_build_dependencies (), and see what's installed already by doing bin/gpkg -p mingw list Hmm, come to think of it, you had *another* problem with dependencies, the librestrict-open thing... How hard is it for you to install another python and try that? Does fedora carry python2.4 or python2.6 (or even python3) packages that you can install alongside your 2.5.1, for example. Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GUB3] How should Guile and Flex be built?
On wo, 2009-02-18 at 14:55 +0100, Jan Nieuwenhuizen wrote: Hi John, > How hard is it for you to install another python and try that? > Does fedora carry python2.4 or python2.6 (or even python3) packages > that you can install alongside your 2.5.1, for example. Just to be sure we're not chasing ghosts, can you (in gub) rm -f $(find gub -name '*pyc') Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Building GUB3
On wo, 2009-02-18 at 17:58 -0800, Patrick McCarty wrote: Hi Patrick, > I have looked into this. Initially, CC is equivalent to > "i686-mingw32-gcc", but at line 19478 of libtool's configure, its > value is "gfortran". Same at line 22451. Nice catch. Workaround in HEAD. Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Building GUB3
On do, 2009-02-19 at 13:41 -0800, Patrick McCarty wrote: Hi Patrick, > Bumping gmp to 4.2.4 for darwin-x86, and removing the patch and > configure_command (), fixed the darwin-x86 build for me. Ok, great. Do you have a patch? Han-Wen, can you verify and apply? Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Why is it _still_ so freaking hard to get info with images?
Op maandag 09-03-2009 om 13:18 uur [tijdzone +0100], schreef David Kastrup: Hi David, > For images in the INFO docs to work, do > > make out=www install-info > > and read the extra instructions. ...because you're missing this info: > make[2]: Leaving directory `/lisa/lilypond/Documentation/user' So the command would be make -C Documentation/user out=www install-info prefix=... the prefix option is not necessary if you're installing where you told configure you'd be installing. > And sure enough: the installed tree contains no info files with images. Similarly, to get images with info, do make -C Documentation/user out=www info > What point is there in complaining that Linux distributions tend to omit > the images when there is no working Makefile target that would get them > there, and when the instructions that the Makefile gives out don't even > work? Good points, everything should be fixed. Improvements could be * add toplevel info and install-info targets that redirect to Documentation/user * make info with images automagically (using these targets) when doing a toplevel make web [there is really no point in *not* making info docs without images when the images are already built for the web docs. the only reason for supporting info without images, is for 'install-info' to work when web-doc tools are not installed/available] [better not:* fix the documentation command to suggest -C Doc../user] Any takers? Next thing is that I wrote patches[1,2] for yelp to display images in info docs, but yelp seems to be dead[3] (or at least not very eager to take them). Jan. [1] http://lilypond.org/blog/janneke/software/info-image/yelp-info-image.diff [2] http://lilypond.org/blog/janneke/software/info-image/yelp-info-image-and-notes.diff [3] https://bugzilla.gnome.org/show_bug.cgi?id=568209 -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Why is it _still_ so freaking hard to get info with images?
Op maandag 09-03-2009 om 11:26 uur [tijdzone -0600], schreef Carl D. Sorensen: Hi Carl, > "Shaun is notoriously bad at watching bugzilla. Do feel free to nag him on > IRC about outstanding patches." > > Have you tried following this advice? Wow, thanks! I just did, it seems these may go in, but gnome/yelp is in 2.26 code freeze now; and apparently they don't use release branches. Greetings, Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GUB3] How should Guile and Flex be built?
Op donderdag 12-03-2009 om 10:43 uur [tijdzone +0100], schreef John Mandereau: Hi John, > I compiled Python 2.6.1 and installed it in my home, setting > LD_LIBRARY_PATH to /home/lilydev. So, does that help? > Nope, and Python 3 may not be a resonable option right now, as this > probably needs some work. It should not, I have tested gub with python3 a while ago. There may be some new smallish issues. > I did, and a clean build failed on odcctools. Log tail attached. So, what does config.log say, why can't gcc make executables? Greetings, Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Why is it _still_ so freaking hard to get info with images?
Op vrijdag 13-03-2009 om 09:50 uur [tijdzone +0100], schreef John Mandereau: Hi John, > ..and input/lsr too. I added toplevel info and intall-info target. Great. > This is already what is done, except that the relative symlink from > prefix/share/info was wrong ;-) Ah, oh. I see that we now always build info with images and make people work hard to not do that. Good. > Oh, I didn't know yelp could display images Yelp displays the gnome user docs, they're full of dialog pictures. The info page browser hardly does/did any formatting, though. Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Why is it _still_ so freaking hard to get info with images?
Op zaterdag 14-03-2009 om 15:31 uur [tijdzone +0100], schreef David Kastrup: > If compiling Lilypond from source with default > settings means not getting the full docs, this is what all major > distributions will distribute So what we need to change is for make [all|default] to also make web. We should also have a target for building a minimal running lilypond -- without the docs. This is actually what the SCons build did, everything on default, scons minimal would only build binaries, python, and fonts. Your point about README/INSTALL is more difficult to tackle. While I agree it would be nice to have those file available at toplevel-- just as they are in the distributed tarballs--it is a pain (not to say stupid) to have generated files in GIT. What we possibly could do, is have README and INSTALL be symlinks in GIT to the readme/install texi sources. The problems with fixing a build system is that it is a major time sink without any obvious benefits, very hard to get right (for a big project like lilypond) and with a number of conflicting constraints (speed vs correctness, etc.) and it's a very personal thing, everyone wants something else, wants to use the build system they already know very well (from work or wherever), doesn't care so much about speed, or correctness, or cross-building or using yet another undocumented language or out of tree builds or building in other ide's or... Unless maybe you use the full standard autotools suite, which *everyone* hates to work with. Han-Wen and I spent far too much time with the stepmake system, which we failed to get into GNU make or grow into a succesful separate project (now, 10 years later there's finally a somewhat similar effort in http://code.google.com/p/quagmire ). I started a SCons build system a couple of years ago, which is much easier to write (no m4+auto*+makefile+shell+external tools messiness), *much* smaller in LOC, debug (you can just insert python statements to print anything about the state of the build and dependencies), fix and maintain but noone else put any effort in that and it bitrotted and was dropped recently. We never commited to it because "the old system worked" and the scons build took 4 seconds to determine the build was up to date. Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GUB3] How should Guile and Flex be built?
Op vrijdag 13-03-2009 om 13:26 uur [tijdzone +0100], schreef John Mandereau: > Not at all: I set PLATFORMS=linux-64 to avoid choking on odcctools > compilation, and dependencies fail for both > Python versions I have tested (2.5 shipped with Fedora 9, and > self-compiled 2.6.1). A clean build (after > "rm -rf target" and "find gub -name '*.pyc' |xargs rm -f") with Python 3 > is currently running, it's not in good shape: > flex and bison are built in tools, which I find snaky. In the log file, probably target/linux-64/log/build.log (possibly target/tools/log/build.log), you can see why a package is being rebuilt. Use less and search for mismatch, it shows the diff between the checksum from the previous build on disk, and the checksum as calculated for a fresh build. > > So, what does config.log say, why can't gcc make executables? > > > I copied the head and the tail of config.log below. Having > /home/lilydev/git/newgub/target/linux-x86/root/usr/cross/i686-linux/bin > and other directories for linux-x86 xcompile look wrong to me. Why? odcctools must be/is being compiled using the x86 toolchain. Hah, but inadvertently a restriction-lifting has been removed after gcc's statting of /usr was fixed. Fixlet in GIT head. Greetings, Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: good news for my PhD
Op donderdag 19-03-2009 om 21:35 uur [tijdzone +0800], schreef Graham Percival: > Fascinating! Yes, I also remember to have heard such works were "public domain" > clear that there is no **domestic** copyright protection ... may just have been a confusion about the importance of the rumour that there is life beyond the US borders ;-) Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: odd configure error
Op donderdag 26-03-2009 om 21:06 uur [tijdzone +0800], schreef Graham Percival: > > GIT from git.sv.gnu.org > > git clone git://git.sv.gnu.org/lilypond.git > > This does not set up easy pulling or pushing in the future, and > generally assumes that people know how to use git > > To get the main source code and documentation, > > mkdir lilypond; cd lilypond > > git init-db > > git remote add -f -t master -m master origin > > git://git.sv.gnu.org/lilypond.git/ > > git checkout -b master origin/master > > After approximately four hours of discussion between git experts > and non-experts, we decided that this is the best sequence of > commands for most contributors. Well, this is utterly ridiculous IMNSHO. I would suggest to * fix the main lilypond repo so that git clone "just works", or * ask on g...@vger.kernel.org what else we're doing wrong, or * fix git so that git clone "just works" If all of these fail, and git clone is *supposed* to be utterly unusable, I suggest to look seriously into switching to bazaar or hg. Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: odd configure error
Op vrijdag 27-03-2009 om 22:11 uur [tijdzone +0800], schreef Graham Percival: > Now, according to Patrick, "git clone" works for the main branch. That's my experience, at least with git 1.6. > Another question is whether it makes sense to keep web/ as a > branch in the main lilypond git. I mean, if we're storing gub/ in > a separate project, why not stick web/ there as well. I vote to move web to its own repository, ie, have one repository per code base/project. Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: doc build broken
Op zaterdag 28-03-2009 om 16:22 uur [tijdzone -0300], schreef Han-Wen Nienhuys: > In gub3, the doc build seems broken. 'make all', completes > successfuly, but I am left with > > [lily...@haring gub3]$ ls uploads/webdoc/ > v2.13.0 > [lily...@haring gub3]$ > > > while I have built 2.13.1 binaries. This breaks the upload script > that expects to see a uploads/webdoc/VERSION directory. Are you building binaries and doc from the same branch? I think this version number is created by lily's build system from VERSION? Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anybody feel like patching away -Wno-long-double?
Op zondag 29-03-2009 om 16:28 uur [tijdzone +0800], schreef Graham Percival: > Jan, could you add the patch to GUB git? Done. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB cross/gcc compile fail
Op zondag 29-03-2009 om 12:19 uur [tijdzone -0300], schreef Han-Wen Nienhuys: > > *** buffer overflow detected ***: > Looks like you have some sort of buffer overflow detection enabled. Is > there a way to switch it off? Alternatively, you cann look into > updating odcctools (updating those tools is usually hairy though.) That might be -fno-stack-protector, look at librestrict.py or librestrict/GNUmakefile for how to turn that off. Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: GUB: Add pointer to Help web page to Windows installer
Op dinsdag 24-03-2009 om 16:29 uur [tijdzone -0600], schreef Carl D. Sorensen: > Would you be willing to apply the patch, do GUB build Done. > , and point me to a download of the Mingw version so I can test it? We'll have to see what is sooner, my build or Han-Wens ;-) Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LilyPond Architecture explanation
Op maandag 30-03-2009 om 06:34 uur [tijdzone -0600], schreef Carl D. Sorensen: > <http://kainhofer.com/~lilypond/Documentation/devel/contrib-guide/Overview-o > f-LilyPond-architecture.html#Overview-of-LilyPond-architecture> Great! Make that http://kainhofer.com/~lilypond/Documentation/devel/contrib-guide/Overview-of-LilyPond-architecture.html#Overview-of-LilyPond-architecture> your mailer inserted a newline. Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: tab characters in the source code
Op dinsdag 07-04-2009 om 15:28 uur [tijdzone -0600], schreef Carl D. Sorensen: > LilyPond programming standards call for no tabs in the files. Not so. http://www.gnu.org/prep/standards/html_node/index.html Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: tab characters in the source code
Op donderdag 09-04-2009 om 01:04 uur [tijdzone -0300], schreef Han-Wen Nienhuys: > I don't think it is a standard, but I would not mind making it a standard. Yes, I agree we should first make it a standard. It is is very annoying if every project uses its own set of petty deviations. Any takers for sending a patch to emacs-devel? Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: tab characters in the source code
Op donderdag 09-04-2009 om 09:53 uur [tijdzone +0100], schreef Anthony W. Youngman: > Someone else will know more than me, but I think the linux kernel > standards What a good idea! But wait, maybe we can start or join join some kind of "linux software group" and use their standards? Only softwares that are also given away for free would be allowed to join. I like animals, can someone think of a funny animal to name this group? How about a zebra? We could then maybe sponsor that group to create a programmer's editor --that would be something that everyone needs? We could make it automatically format the program code so that it adheres to that standard while you type. It could also have a function to reformat existing code, we could call that "indent-region" and bind it to M-C-\ . Then maybe we could even write a script to check all code once in a while, possibly by using that editor too, and call the script scripts/auxiliar/fixcc.py ? > >Han-Wen > >(being trained to avoid tabs during daytime) Or we could just do whatever Han-Wen's current employer happens to prefer. That may be more practical, and easier for Han-Wen too. Greetings, Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: tab characters in the source code
Op donderdag 09-04-2009 om 20:01 uur [tijdzone +0800], schreef Graham Percival: > See, I was with you until this point. Tying code indentation to a > particular editor is... not ideal. No, but that's why I propose to first start our Zebra group and figure out coding standards. It's about time we got some, no? However, I think it would be stupid if we created a programmer's editor and then *not* have it default to our coding standards? Now how do we prevent that in some far away future, people will have forgotten this and propose to deviate from the Zebra standard? I suggest to prefix all names in our softwares in our to be prefixed with "ZEBRA/". For example: ZEBRA/LilyPond. That will surely work! People are curious by nature. This prefix which will lead them to zebra.org! We could also host our mailing lists at zebra.org, it will be impossible to miss that hint? > I must say, however, that I'm quite proud that my sarcasm is > infecting other lilypond developers. ;) Rest assured, also the source of this sarcasm will be lost in history ;-) Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: tab characters in the source code
Op donderdag 09-04-2009 om 22:14 uur [tijdzone +0800], schreef Graham Percival: > Oh, certainly. But I think it would *also* be stupid to create a > programmer's edit, when vim is already perfect. :P True. Let's just keep manually formatting everything. I mean, people's tastes differ for a reason. This has the additional advantage that the programmer implementing a piece of code can leave her signature more easily, by using ever so slightly indentation variations. Others will then know to stay away from code sections that they do not 'own', so to say. > By the way, I *always* prefix LilyPond by an animal name when I > introduce it in my published papers. :) Good. Just picking a random animal for now -- until we settle for zebra -- should work. > Nah; Valentin will keep the legend of the Grumpy Developer alive > in times to come. Long after humanity has colonized distant > stars, schoolchildren will be reading about the epic flamewars > involving Achilles, Trojan Horses, and whether or not we should > move all the CUTTLEFISH/LilyPond documentation into a wiki. Brilliant! Let's define the MOOSE/coding standards in an Opera! Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB3 at the lilypond-installer stage
Op woensdag 15-04-2009 om 00:06 uur [tijdzone -0700], schreef Patrick
McCarty:
Hi Patrick,
> > ('tar -t -z -f
> > "/home/pnorcks/git/gub/target/linux-x86/packages/libtool-runtime-2.2.6.a.linux-x86.gup"',)
> > {}
> > invoking tar -C
> > /home/pnorcks/git/gub/target/linux-x86/installer/lilypond-git.sv.gnu.org--lilypond.git-master
> > -p -x -z -f
> > /home/pnorcks/git/gub/target/linux-x86/packages/libtool-runtime-2.2.6.a.linux-x86.gup
> > /home/pnorcks/git/gub/target/tools/root/usr/bin/tar: tried to open () file
> > /home/pnorcks/git/gub/.
> > allowed:
> > /home/pnorcks/git/gub/target
> > /tmp
> > /dev/null
> >
> > gzip: stdout: Broken pipe
> > Command barfed: tar -C
> > /home/pnorcks/git/gub/target/linux-x86/installer/lilypond-git.sv.gnu.org--lilypond.git-master
> > -p -x -z -f
> > /home/pnorcks/git/gub/target/linux-x86/packages/libtool-runtime-2.2.6.a.linux-x86.gup
>
> Does anyone have any ideas about this?
I haven't! ;-)
> The errors look like they involve librestrict. Is this the case?
Yes, that's the case. It looks like "your" tools/root/usr/bin/tar
tries to access the CWD. I'm not sure why it would do that as
* it should -C change directory to target/installer/...,
I see no reason for . to exist, be writable, much less
to be open()ed
* "my" tools/root/usr/bin/tar does not seem to do this,
so librestrict does not kick in.
We should try to figure out why "your" tar reads CWD, ie, git/gub/.
Jan.
--
Jan Nieuwenhuizen | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien | http://www.lilypond.org
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB3: M4 not accurately recognized?
Op woensdag 15-04-2009 om 00:51 uur [tijdzone -0700], schreef Patrick McCarty: Hi Patrick, > I am trying to build a mingw LilyPond installer, but I am running into > a problem at the tools::bison configure stage. > > It seems that the GUB-installed M4 is not being recognized as GNU M4 > >= 1.4. The end of the config.log: Interesting. So, *both* of your M4's are not recognized. Building tools::bison using either /bin/m4 or tools::m4 works for me. You should check the relevant config.log snippet and investigate why configure's check fails. Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB3 at the lilypond-installer stage
Op donderdag 16-04-2009 om 13:10 uur [tijdzone +0200], schreef Jan Nieuwenhuizen: >* it should -C change directory to target/installer/..., > I see no reason for . to exist, be writable, much less > to be open()ed >* "my" tools/root/usr/bin/tar does not seem to do this, > so librestrict does not kick in. > > We should try to figure out why "your" tar reads CWD, ie, git/gub/. What does target/tools/root/usr/bin/tar --help say? You are not perchance using busybox's tar command? Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB3 at the lilypond-installer stage
Op vrijdag 17-04-2009 om 00:29 uur [tijdzone -0700], schreef Patrick McCarty: Hi Patrick, > I just tried doing a fresh build with > > $ bin/gub tools::bison && bin/gub tools::flex && bin/gub > mingw::lilypond-installer > > and I get two configure errors for linux-x86::cross/binutils. I'm > just attaching the one for configure-binutils; configure-gas also > failed with the same error message. Hmm, you seem to be getting the weirdest of errors. I cannot reproduce this. What kind of system are you running? Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond & wikipedia
Op maandag 02-02-2009 om 02:21 uur [tijdzone +0100], schreef Johannes Schindelin: > > > Tim Starling, one of the main wikipeda software developers, says: > > > > > > My understanding is that > > > > > > a) safe mode is not secure, being trivially DoS-able by short > > > infinite loop scripts > > > > As it currently stands, yes. > > > > > b) safe mode will not work for many of the free scores available on > > > the web > I think that was part of the bad research Tim did that really upset me. Yes. So if we get > > Assign two Frogs to the task: > > - one person ensures that lilypond input without **any** scheme > > will always end in a reasonable amount of time. > > - one person modifies --safe. I'm sure that we can whitelist a > > few more commands (IIRC changing the paper size is not "safe"). > > But we'll certainly need to remove much of the more basic stuff. we should probably mention on the wikipedia page that these concerns are being worked on. Why doesn't WikiPedia come to us with questions or bug reports? Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB3 at the lilypond-installer stage
Op dinsdag 21-04-2009 om 21:38 uur [tijdzone -0700], schreef Patrick
McCarty:
Hi Patrick,
> I ran the command that is failing through strace, and the output is
> attached.
>
> Line 65 looks like the place tar open()s the CWD. My system tar (GNU
> tar 1.22) also opens the CWD at this point, running the same command.
So this gets more interesting all the time. I ran my tar through
strace, and it also opens CWD. Running tar manually
$ LD_PRELOAD=target/tools/root/usr/lib/librestrict.so
target/tools/root/usr/bin/tar -C ~/tmp/x -p -xzf
target/tools/packages/make-3.81.tools.gup
/home/janneke/vc/gub/target/tools/root/usr/bin/tar: tried to open () file
/home/janneke/vc/gub/.
allowed:
/home/janneke/vc/gub/target
/tmp
/dev/null
Afgebroken (core dumped)
fails. I'm attaching a patch that you can try as workaround. Now it
puzzles me why tar does *not* fail in GUB for me. It should. Hmm.
Jan.
--
Jan Nieuwenhuizen | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien | http://www.lilypond.org
diff --git a/gub/gup.py b/gub/gup.py
index 89df0cc..ba584c5 100644
--- a/gub/gup.py
+++ b/gub/gup.py
@@ -111,7 +111,9 @@ class FileManager:
raise Exception ('abort')
loggedos.system (logging.default_logger,
- 'tar -C %(root)s -p -x%(_z)s%(_v)s -f %(ball)s'
+ # cd %(root)s to avoid open(2) of cwd, see
+ # http://lists.gnu.org/archive/html/lilypond-devel/2009-03/msg00304.html
+ 'cd %(root)s && tar -C %(root)s -p -x%(_z)s%(_v)s -f %(ball)s'
% locals ())
self._package_file_db[name] = '\n'.join (lst)
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB3 at the lilypond-installer stage
Op woensdag 22-04-2009 om 14:48 uur [tijdzone +0200], schreef Jan Nieuwenhuizen: Hi Patrick, > fails. I'm attaching a patch that you can try as workaround. Now it > puzzles me why tar does *not* fail in GUB for me. It should. Hmm. Interesting, if I use the command below to print the current librestrict setting in gub/gup.py 'echo " * LD_PRELOAD=$LD_PRELOAD" && echo && cd %(root)s && tar -C %(root)s -p -x%(_z)s%(_v)s -f %(ball)s' and re-install, say, make, then LD_PRELOAD is unset for me bin/gup -p tools remove make bin/gub tools::make [...] invoking echo " * LD_PRELOAD=$LD_PRELOAD" && echo && cd /home/janneke/vc/gub/target/tools/root && tar -C /home/janneke/vc/gub/target/tools/root -p -x -z -f /home/janneke/vc/gub/target/tools/packages/make-3.81.tools.gup * LD_PRELOAD= LD_PRELOAD is set when by gub/build.py. When running gub/buildrunner.py's pkg_install (), I don't see how it can be set by gub. I don't expect you have LD_PRELOAD set to librestrict.so when invoking gub? Also, when I do LD_PRELOAD=$(pwd)/target/tools/root/usr/lib/librestrict.so bin/gub tools::make the LD_PRELOAD is printed invoking echo " * LD_PRELOAD=$LD_PRELOAD" && tar -C /home/janneke/vc/gub/target/tools/root -p -x -z -f /home/janneke/vc/gub/target/tools/packages/make-3.81.tools.gup **** * LD_PRELOAD=/home/janneke/vc/gub/target/tools/root/usr/lib/librestrict.so but tar still succeeds. Hmm. Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Markup commands \left-brace and \right-brace
Op donderdag 23-04-2009 om 07:19 uur [tijdzone +0200], schreef Werner LEMBERG: > I'm not a good lisp programmer, but isn't the standard method for > searching like that to not use a loop but recursive calls? I don't really care about that, but it would be nice to split-out the (find-brace lambda to a generic function. That is, instead of having a comment like this ;; binary search based on y-extent of brace stencil with a specific binary-search algorithm implemented for finding a brace, it would be nice to have something like ;; one binary-search to rule/find them all (define (binary-search min max getter target-value) ...) (find-brace (binary-search 0 575 get-y-from-brace size) Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB3 at the lilypond-installer stage
Op woensdag 22-04-2009 om 21:07 uur [tijdzone -0700], schreef Patrick McCarty: Hi Patrick, > Your latest fixes on master work for me. > > I can now build all of the installers except for darwin-*. Attached > is the log for darwin-x86. Yes, this is a quite similar thing. While it's nice that it builds for you, I would like to get rid of the other workaround rather than add yet another one. Can you help to find out why librestrict kicks in? * add an " echo LD_PRELOAD=$LD_PRELOAD" statement in gub/installer.py (just after the #FIXME: ask TarBall or so) * double check LD_PRELOAD is unset in your shell/when invoking gub * ?? Also, doing LD_PRELOAD= tar ... would be a nicer workaround than the extra cd ... && Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Renaming targets
Op vrijdag 24-04-2009 om 10:31 uur [tijdzone +0200], schreef John Mandereau: > > web -> doc > ...and here's a patch for GUB3. Thanks, please ping me when this is in lilypond master? Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: /news
Op woensdag 27-05-2009 om 21:25 uur [tijdzone +0800], schreef Graham Percival: > Yes, I expected it to. Apparently it doesn't (I'm at the airport > with local friends, so I don't want to investigate right now). > Could you suggest something? I suggest (fixed) # note: for broken browsers (should we keep them? RedirectMatch ^(..*/)(authors)(.[.a-z]*html)?$ $1AUTHORS$3 RedirectMatch ^(..*/)(news)(.[.a-z]*html)?$ $1NEWS$3 [snip] # invariant toplevel entry points RedirectMatch ^/authors /doc/Documentation/topdocs/AUTHORS RedirectMatch ^/news/doc/Documentation/topdocs/NEWS Is our .htaccess updated automagically, I don't think so! Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter Avatar®: http://AvatarAcademy.nl| http://lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: /news
Op donderdag 28-05-2009 om 00:49 uur [tijdzone +0800], schreef Graham Percival: > > > Is our .htaccess updated automagically, I don't think so! > > > > Apparently it does, it works now. > > That's surprising! No, that was me. .htaccess is not updated automagically. Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter Avatar®: http://AvatarAcademy.nl| http://lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: web shortcut
Op vrijdag 29-05-2009 om 13:09 uur [tijdzone +0200], schreef Francisco Vila: > Hello, here is another web nitpick. > instead. I'm afraid I do not know how to fix this on the htaccess file. Me neither, but look at Documentation/index.html: I found this file is generated by scripts/build/www_post.py can someone *please* have www_post.py insert an autogenerated marker there (and any others we missed?) like we do with most every generated files? Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter Avatar®: http://AvatarAcademy.nl| http://lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB on kainhofer: still cross/gcc
Op zaterdag 30-05-2009 om 22:46 uur [tijdzone -0700], schreef Graham
Percival:
> Who has successfully built GUB?
Me!
:-)
> def compile_command (self):
> os.putenv('CFLAGS', '-fno-stack-protector ')
> return (cross.AutoBuild.compile_command (self))
> to the class Gcc (cross.AutoBuild), but that also failed.
FWIW, I'd very much avoid juggling with the environment from python,
and try to keep changes as local as you can.
> Any more tips? I'd really like to get this working so I can make
> releases.
I'd try something like
diff --git a/gub/specs/darwin/odcctools.py b/gub/specs/darwin/odcctools.py
index ee953c0..1d24944 100644
--- a/gub/specs/darwin/odcctools.py
+++ b/gub/specs/darwin/odcctools.py
@@ -62,3 +62,8 @@ cd %(install_prefix)s%(cross_dir)s/bin && ln
%(toolchain_prefix)sstrip ../%(targ
def install (self):
cross.AutoBuild.install (self)
self.install_librestrict_stat_helpers ()
+
+class Odcctools__darwin__ppc (Odcctools):
+def configure_command (self):
+return (Odcctools.configure_command (self)
++ ' CFLAGS=-fno-stack-protector')
but if this works, you'd have to add a test (probably to
to odcctool's configure) if gcc groks -fno-stack-protector.
Jan.
--
Jan Nieuwenhuizen | GNU LilyPond - The music typesetter
Avatar®: http://AvatarAcademy.nl| http://lilypond.org
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB on kainhofer: still cross/gcc
Op zaterdag 30-05-2009 om 22:46 uur [tijdzone -0700], schreef Graham Percival: > Any more tips? I'd really like to get this working so I can make > releases. Oh, you can also try to not waste your hardware resources and confuse softwary by just installing 64 bits ;-) Can you build everything else now, besides darwin-ppc, otherwise I'd suggest dropping that arch locally and try to do a full build on all other archs. Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter Avatar®: http://AvatarAcademy.nl| http://lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB on kainhofer: still cross/gcc
Op zondag 31-05-2009 om 22:49 uur [tijdzone -0700], schreef Graham Percival: > Anybody else? Particularly on ubuntu systems? FWIW, I'm doing GUB builds on ubuntu. > None of the other places I put -fno-stack-protector had any > effect, so I was just trying everything. :( Yeah, I know that mode. Sometimes it works, but what always helps best is to really look what's going on. > No change; still the same error message. I also tried adding a > similar section to gub/specs/darwin/gcc.py (changing it to >return (gcc.Gcc.configure_command... > but it still failed. For example, it looks to me from the log as if RANLIB fails with a stack overflow problem. First, make sure if this is the ranlib from odcctools and not the ranlib on your system (eg, /usr/bin/ranlib). Then, make sure -fno-stack-protector is added to the ranlib compile (and -fno-stack-protector is actually the right switch -- google may help). > I'm really surprised that gcc would be the finicky; I would have > thought that a compiler would be as easy to compile as possible, > and the people working on gcc should have more experience with > compiling than anybody else in the world. :) No, as it stands, Han-Wen and I have the most cross build experience in the world ;-) Pretty soon now, you're also on that list. Even openSUSE/openoffice.org is looking at GUB now :-) Greetings, Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter Avatar®: http://AvatarAcademy.nl| http://lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB on kainhofer: still cross/gcc
Op maandag 01-06-2009 om 05:23 uur [tijdzone -0700], schreef Graham Percival: > I'm not convinced that GUB even knows which file to use; the build > commands contain "-O2 -g -g -O2 -O2 -O2 -g -g -O2". Surely only > one "-O2 -g" matters? Yes, this has little to do with GUB. In an autotools build system, flags are passed to the compiler by means of what ./configure --help advises. CFLAGS=' ... ' ./configure most always works. > Judging from that CompilerFlags page on the ubuntu wiki, I want to > add "CPPFLAGS=" to one of those files. Okay, oops. So, do something like diff --git a/gub/specs/darwin/odcctools.py b/gub/specs/darwin/odcctools.py index ee953c0..9a15a07 100644 --- a/gub/specs/darwin/odcctools.py +++ b/gub/specs/darwin/odcctools.py @@ -62,3 +62,8 @@ cd %(install_prefix)s%(cross_dir)s/bin && ln %(toolchain_prefix)sstrip ../%(targ def install (self): cross.AutoBuild.install (self) self.install_librestrict_stat_helpers () + +class Odcctools__darwin__ppc (Odcctools): +def configure_command (self): +return (Odcctools.configure_command (self) ++ ' CFLAGS=-D_FORTIFY_SOURCE=0') possibly use CPPFLAGS=, but depending on how ./configure.in is made that may or may not work. Make sure this gets to the command line and check for any gcc _FORTIFY_SOURCE redefined warnings :-) Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter Avatar®: http://AvatarAcademy.nl| http://lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB on kainhofer: still cross/gcc
Op dinsdag 02-06-2009 om 03:05 uur [tijdzone -0700], schreef Graham Percival: > Anyway, with this patch, the darwin-x86::cross/gcc build > succeedes: Great. I've just pushed this, with an extra if: if self.build_bits == '32' and self.build_hardware_bits == '64': to narrow down the change even more. Greetings, Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter Avatar®: http://AvatarAcademy.nl| http://lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Cron 404 report
Op donderdag 28-05-2009 om 05:25 uur [tijdzone +0200], schreef Jan Nieuwenhuizen: > popularity page >[referrer]... > > 180 /web/favicon.ico > 175 /web/favicon.gif Should we be adding a copy of favicon.ico to web/? > 170 /doc/v2.12/Documentation/user/lilypond/Tutorial.html Why is this, ideas? Greetings, Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter Avatar®: http://AvatarAcademy.nl| http://lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: savannah back up. - please push
Op dinsdag 02-06-2009 om 10:16 uur [tijdzone -0300], schreef Han-Wen Nienhuys: > Can someone push a more recent version? I think there were changes > after that. Also, if anyone made changes on other branches besides > master, please push them again (I am thinking of GDP and the frogs, in > particular). It seems we're now back @ May28. However, I just (intentionally) deleted the gub branch (again). Gub lives at http://github.com/janneke/gub/tree/master Would this be a nice moment to split off web into its own repository? Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter Avatar®: http://AvatarAcademy.nl| http://lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Cron 404 report
Op dinsdag 02-06-2009 om 12:59 uur [tijdzone +0200], schreef Francisco Vila: > > Should we be adding a copy of favicon.ico to web/? > > We have not any references to favicon. Pages in either directory show > correcly their url icon, so it does not have sense to make pages on > web/ explicitly point to ../favicon.ico, only to avoid the 404. Why not, 404 -- bad, right? > Where does it come from? Good question. Here's a sequence 197.red-83-39-248.dynamicip.rima-tde.net - - [02/Jun/2009:12:43:04 +0200] "GET /web/ HTTP/1.1" 200 3094 "-" "Mozilla/5.0 (X11; U; Linux i686; es-ES; rv:1.9.0.10) Gecko/2009042523 Ubuntu/8.10 (intrepid) Firefox/3.0.10" 88.red-83-37-164.dynamicip.rima-tde.net.12823124393561330 197.red-83-39-248.dynamicip.rima-tde.net - - [02/Jun/2009:12:43:04 +0200] "GET /web/newweb.css HTTP/1.1" 200 1033 "http://lilypond.org/web/"; "Mozilla/5.0 (X11; U; Linux i686; es-ES; rv:1.9.0.10) Gecko/2009042523 Ubuntu/8.10 (intrepid) Firefox/3.0.10" 88.red-83-37-164.dynamicip.rima-tde.net.12823124393561330 197.red-83-39-248.dynamicip.rima-tde.net - - [02/Jun/2009:12:43:04 +0200] "GET /web/images/shortcut.png HTTP/1.1" 200 308 "-" "Mozilla/5.0 (X11; U; Linux i686; es-ES; rv:1.9.0.10) Gecko/2009042523 Ubuntu/8.10 (intrepid) Firefox/3.0.10" 88.red-83-37-164.dynamicip.rima-tde.net.12823124393561330 197.red-83-39-248.dynamicip.rima-tde.net - - [02/Jun/2009:12:43:05 +0200] "GET /web/images/monet-fragment.jpeg HTTP/1.1" 200 6117 "http://lilypond.org/web/"; "Mozilla/5.0 (X11; U; Linux i686; es-ES; rv:1.9.0.10) Gecko/2009042523 Ubuntu/8.10 (intrepid) Firefox/3.0.10" 88.red-83-37-164.dynamicip.rima-tde.net.12823124393561330 197.red-83-39-248.dynamicip.rima-tde.net - - [02/Jun/2009:12:43:09 +0200] "GET /web/favicon.ico HTTP/1.1" 404 290 "-" "Mozilla/5.0 (X11; U; Linux i686; es-ES; rv:1.9.0.10) Gecko/2009042523 Ubuntu/8.10 (intrepid) Firefox/3.0.10" 88.red-83-37-164.dynamicip.rima-tde.net.12823124393561330 So, firefox 3.0.10 does this when getting web/index[.es.html?] > A line in .htaccess makes the redirect for > > ^/tutorial > > to > > /doc/Documentation/user/lilypond/Tutorial.html > > BUT lilypond.org/tutorial leads correctly to the chapter 2. (?) Yeah, fixed this in the mean time. :-) NOT in our git copy, though. Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter Avatar®: http://AvatarAcademy.nl| http://lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB on kainhofer: still cross/gcc
Op dinsdag 02-06-2009 om 07:02 uur [tijdzone -0700], schreef Graham Percival: > On Tue, Jun 02, 2009 at 12:28:29PM +0200, Jan Nieuwenhuizen wrote: > > Op dinsdag 02-06-2009 om 03:05 uur [tijdzone -0700], schreef Graham > > Percival: > > > > > Anyway, with this patch, the darwin-x86::cross/gcc build > > > succeedes: > > > > Great. I've just pushed this, with an extra if: > > > > if self.build_bits == '32' and self.build_hardware_bits == '64': > > > > to narrow down the change even more. > > Two problems: > 1) this affects darwin-x86, not darwin-ppc. (at least, I haven't > tested darwin-ppc, only darwin-x86). Interesting. I missed that bit. Your original report is about ppc, right? http://lists.gnu.org/archive/html/lilypond-devel/2009-03/msg00356.html > AttributeError: 'Odcctools__darwin__x86' object has no attribute > 'build_bits' Ah, that should prolly be self.settings. I'll wait a bit until x86/ppc is cleared up. Jan. -- > > Jan Nieuwenhuizen | GNU LilyPond - The music typesetter > Avatar®: http://AvatarAcademy.nl| http://lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: savannah back up. - please push
Op dinsdag 02-06-2009 om 07:48 uur [tijdzone -0700], schreef Graham > I'm a bit unhappy about personally-named repos like /janneke/. Me too. I had no idea that creating a public oss repo on github is done below the user's account. Please create github.com/gub as a fork of /janneke/gub and I'll let /janneke/gub die. Greetings, Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter Avatar®: http://AvatarAcademy.nl| http://lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB on kainhofer: still cross/gcc
Op woensdag 03-06-2009 om 04:06 uur [tijdzone -0700], schreef Graham Percival: > Ok, it works with self.settings, and it's required for darwin__ppc > and darwin__x86. I'm not certain if you'd rather put one code > block into the main odcctools class, or add subclasses for both > __ppc and __x86. Thanks, update pushed. Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter Avatar®: http://AvatarAcademy.nl| http://lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
wikipedia...
Hi there, Triggered by recent wikipedia messages, I had a peek at our http://en.wikipedia.org/wiki/Lilypond page and found it still has the weird (long and not very impressive) fire breathers example. Why the .ly at all, better show impressive output and move .ly example to a LilyPond_Language page? Also, there are some pieces by Han-Wen from 2006 on the talk page http://en.wikipedia.org/wiki/Talk:GNU_LilyPond quotes below. Can someone other than Han-wen or me take care of this? Possibly it's no wonder that wikipedia doesn't use lilypond, considering that our article on wikipedia is so bad? Greetings, Jan. Hi, I take issue with While it has achieved this, the quality of output from competing commercial packages has improved since the inception of the LilyPond project so that they are now comparable because it implies that LilyPond can be considered "done" from a typographical POV (which it isn't, IMO). Furthermore, "comparable" is a vague statement: mosquitos and elephants are comparable, and the result of the comparison is that the elefant is bigger. Esthetics aren't well defined, but most printout of Finale and Sibelius still (we're speaking 2006) looks made with a computer. I think I am not the right person to edit the page itself, though. Han-Wen (LilyPond Author). and also I don't own licenses to either Finale or Sibelius, so I can't provide you with any specific samples, but I've seen both in action. I think that pointing out weaknesses of other packages should not be done on the LilyPond page, but rather on the pages of said packages. I think it's better to point out what sets apart Lily, as this is more informative and more objective, eg * optical scaling for font: depending on staff size, the design of the font is altered slightly. (This is a Feature that Knuth's Comupter Modern font is well known for too): note heads become rounder, and lines heavier. * Optical spacing (see the essay), where stem directions are taken into account for spacing subsequent notes. Note that this is something different from the inaccurately named Optical (tm) Spacing feature of Sibelius. * Proportional spacing, where allotted space is exactly equal to durations. No other packages support this out of the box. (you need a recent 2.7 lily, though) * Ledger lines that never collide, but are shortened in tight situations. * Stem directions on the center follow the directions of surrounding notes. (recent 2.7) Also, in general, LilyPond does much better on automatically avoiding collisions for ties, slurs, articulation marks, nested tuplets, etc.. For example, if you add an arpeggio to a chord in Finale, Finale just parks it on top of the accidentals, you have to manually tweak things to look ok. Han-Wen Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter Avatar®: http://AvatarAcademy.nl| http://lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
