Re: a new lilypond build failure
Jan Nieuwenhuizen wrote: Well, it's a dangerous thing. Among other things, their version numbers might collide badly with the official Debian ones. Best it should have different package names to prevent this sort of thing from happening. Whe have this on our website, I think that Anthoy Fok provided this recipe We could also just copy your ./debian stuff and change the name to lilypond-snapshot and lilypond-2.6-snapshot or something? then again, who actually uses these recipes? We have spec files for Fedora, Mandrake and SUSE, and only the Fedora one gets regular maintenance, because I use it to build the RPM myself. Perhaps it's better to put them into a separate packaging CVS repo. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: a new lilypond build failure
Jan Nieuwenhuizen [EMAIL PROTECTED] writes: Well, it's a dangerous thing. Among other things, their version numbers might collide badly with the official Debian ones. Best it should have different package names to prevent this sort of thing from happening. Whe have this on our website, I think that Anthoy Fok provided this recipe The build scripts are in the subdirectory codedebian//code; you can make the .deb by doing tar xzf lilypond-x.y.z.tar.gz cd lilypond-x.y.z dpkg-checkbuilddeps # print missing build dependencies # apt-get install ... # install any missing packages dch -p -v x.y.z.local.1 Local build. debuild We could also just copy your ./debian stuff and change the name to lilypond-snapshot and lilypond-2.6-snapshot or something? Yes, that is a safer recipe. If you copy my ./debian code, that's ok, but still, I'd rather it didn't land inside the standard tarball but lived separately. Also, there will be necessary version skew: I make my change only after you release the tarball. Since the virtue of this is for users who are using the CVS archive (and I do see the point of that) how about leaving it in the CVS, but not packaging it into the tarball? That seems like the best of both worlds. Thomas ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: a new lilypond build failure
Jan Nieuwenhuizen [EMAIL PROTECTED] writes: Ok; they were once used for processing the texinfo docs, right? They are still used for producing the PDF documentatation, so there is still a build dependency on tetex. Also, tetex is great for making documents with lilypond snippets, but this does not make tetex a dependency (now that we dropped it). Ah, yes, we get that from mftrace anyway, since mftrace depends on tetex-bin in Debian. :) You say that the TeX backend is no longer supported (!). Why is this? TeX used to be our easy way out to produce output. In the 2.5 series, we managed to use pango to make the half-baken PS backend fully operational. Supporting tex output is a lot of work, and it probably has just one user. I used to use it a lot. Ah well. :) Thomas ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: a new lilypond build failure
Han-Wen Nienhuys writes: Perhaps it's better to put them into a separate packaging CVS repo. Yes, let's just [re]move them all. The mingw/cygwin stuff is already in the installer repo. Jan. -- Jan Nieuwenhuizen [EMAIL PROTECTED] | 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: a new lilypond build failure
Han-Wen Nienhuys writes: then again, who actually uses these recipes? Now I remember, we used to have debian repackagers of development releases for debian stable and debian unstable. Anyway, what I'd really like to do is to build debs of any software that I need which is not in Debian (mostly new releases or CVS), and install in a writable ~/.unionfs overlay of /. For that to work, we not only need an efficient unionfs that works with fuse (or a unionfs translator for the Hurd), but also an up to date ./debian directory in every software package that I need. I was thinking of doing our part with LilyPond, but the idea is not really taking off. Jan. -- Jan Nieuwenhuizen [EMAIL PROTECTED] | 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
