CM 1.1 git question
Graham et al, In the instructions for getting the source code, why not just use git-clone? Is there a difference? The currently suggested method of remote-add + checkout produces a bunch of warnings (below). Andrew and...@obi-wan:~$ mkdir lilypond-web and...@obi-wan:~$ cd lilypond-web and...@obi-wan:~/lilypond-web$ git init-db Initialized empty Git repository in /home/andrew/lilypond-web/.git/ and...@obi-wan:~/lilypond-web$ git remote add -f -t web -m web origin git://git.sv.gnu.org/lilypond.git/ Updating origin warning: no common commits remote: Counting objects: 12367, done. remote: Compressing objects: 100% (3257/3257), done. remote: Total 12367 (delta 9143), reused 12249 (delta 9065) Receiving objects: 100% (12367/12367), 11.39 MiB | 313 KiB/s, done. Resolving deltas: 100% (9143/9143), done. >From git://git.sv.gnu.org/lilypond * [new branch] web-> origin/web and...@obi-wan:~/lilypond-web$ git checkout -b web origin/web warning: You appear to be on a branch yet to be born. warning: Forcing checkout of origin/web. Branch web set up to track remote branch refs/remotes/origin/web. Switched to a new branch "web" ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Building GUB3
Hi Jan, On Mon, Feb 16, 2009 at 11:19:32AM +0100, Jan Nieuwenhuizen wrote: > iOn zo, 2009-02-15 at 19:13 -0800, Patrick McCarty wrote: > > > 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]. 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'. 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. Thanks, Patrick /home/pnorcks/git/gub/target/mingw/build/guile-1.8.6/libguile ./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/ /home/pnorcks/git/gub/target/mingw/root/usr/cross/bin /home/pnorcks/git/gub/target/tools/root/usr/bin ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: What's up with the Frogs?
Here's a patch for the FIXME DOING SOMETHING part.
Jon
On Sun, Feb 15, 2009 at 4:34 PM, Valentin Villenave
wrote:
> 2009/2/15 Graham Percival :
> > You can hopefully figure out what the FIXME DOING SOMETHING means,
> > and then write a patch to fix the CG on this issue. If not, bug
> > Valentin.
>
> Yes.
>
> > Valentin, please introduce him to Sebastiano and ask Seba to make
> > his account an editor.
>
> Aye aye, but I'll still need his username first.
>
> Regards,
> Valentin
>
--
Jonathan Kulp
http://www.jonathankulp.com
--- Documentation/devel/lsr-work.itexi 2009-02-01 22:32:27.0 -0600
+++ Documentation/devel/lsr-workB.itexi 2009-02-16 12:56:16.0 -0600
@@ -40,10 +40,11 @@
@node Approving snippets
@section Approving snippets
-The main task of LSR editors are approving snippets. Log in to
-...@uref{http://lsr.dsi.unimi.it/, LSR} and find a list of unapproved
-snippets by
-FIXME DOING SOMETHING.
+The main task of LSR editors is approving snippets. To find a list of
+unapproved snippets, log into @uref{http://lsr.dsi.unimi.it/, LSR} and
+and select "NO" from the dropdown menu to the right of the word
+"Approved" at the bottom of the interface, then click "enable
+filter."
Check each snippet:
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patch for ja doc and two Questions
On Sat, Feb 14, 2009 at 03:04:55AM +0100, John Mandereau wrote: > Sawada wrote: >> In that sub subsection, there is a command as following: >> nice make LILYPOND_EXTERNAL_BINARY=/path/to/bin/lilypond web >> >> I wonder "nice" is not needed, though it is harmless. >> > "nice" is not needed, that's a Grahamism, Yes, I'm a very "nice" person. ;) > but I think it's not a problem if it remains there, I'd expect > people who run this command with no knoweledge of nice comand to > do "man nice" :-) Basically, it came down to this: if somebody doesn't know what they're doing, then they would probably rather have the 45-minute doc build be low-priority (so they can still use mail or browse the web or whatever), rather than high-priority. I can't think of any instance where anybody without serious unix knowledge[1] would *want* a long build to take priority over other things, so I made the copy&paste command match that. [1] Sure, somebody running a build-box server for multiple open-source projects might want the lilypond build to be higher priority than a complete freebsd build... but that's a pretty special case, and the persons involved would have sufficient unix knowledge to remove or modify the nice command. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Building GUB3
On Mon, Feb 16, 2009 at 10:53 AM, Jan Nieuwenhuizen wrote: >> 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. I just deleted target and download and am restarting my build here. I´ll let you know until where it gets -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ 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 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
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
