Hi guys,
Il giorno mar, 16/02/2010 alle 19.07 +0100, Francisco Vila ha scritto:
> I understand it. But to put it simple: I'm not smart enough to guess
> what did happen in such a complex commit, and that leads to nearly
> undoable translation updates. Others may be smarter than me, so it is
> ma
Il giorno mar, 16/02/2010 alle 15.23 +, Trevor Daniels ha scritto:
> The change seems to have started after commit
> c258b7788db8a717b4741f02d9f5cc52862338d4
> which was applied by John on Christmas Eve.
> As part of his tidying up, the option list is
> sorted in line 1236, which places the li
Neither can I. Sorry for top-posting but it seems this error is
unrelated to the one you reported:
error: cannot find description for property originalMiddleCPosition
(translation)
/home/lilydev/git/lily/master/out/share/lilypond/current/scm/lily.scm
make[1]: *** [out/internals.texi] Error 1
Ch
Il giorno gio, 18/02/2010 alle 11.59 -0800, Mark Polesky ha scritto:
> Okay to push?
The macro definition contains text in English that is visible in the
output, namely "Bugfixes", so I first thought it should be put in
macros.itexi, but news items are translated in very few (or no)
languages, so
Il giorno lun, 15/03/2010 alle 16.43 +, Graham Percival ha scritto:
> Issue 979 is currently blocked because a simple test case fails.
> Maybe that case has been fixed in waf's svn by now. If not, try
> asking the waf guy to fix it. I'm pretty certain he could fix it in
> 30 minutes or so, o
Il giorno lun, 15/03/2010 alle 22.55 +0100, Valentin Villenave ha
scritto:
> Where's the patch?
In the MIME part of the message starting with (in the email "source")
"""
Content-Type: text/x-patch; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
"""
This should be unde
Il giorno mar, 23/03/2010 alle 01.49 +, Graham Percival ha scritto
> Could somebody translate for the git-impaired?
>
> - if I have no non-pushed commits, do I need to do anything?
Yes: scrap out your existing Git repo and clone the new one. If you
have non-pushed commits, then save them in
Il giorno mar, 23/03/2010 alle 09.52 +0100, Francisco Vila ha scritto:
> No, no, yes. Anyway, recall that git is robust enough as to face a
> complete crash of savannah with no backups.
>
> In Git we trust,
I trust (read "I fear") the ability of at least one committer with push
access to Savanna
Il giorno mar, 23/03/2010 alle 11.54 +0100, Francisco Vila ha scritto:
> Mm, I've thought it twice (8 left) and what it comes to my mind is,
> what I push is what I've pulled if the change did not happen in
> between. Correct me if I'm wrong. What is the effect of pulling the
> new history onto t
Il giorno gio, 04/03/2010 alle 18.48 +, Graham Percival ha scritto:
> After hours of looking at the current translation python files and
> getting totally discouraged, I decided to start writing a new python
> file, web_post.py instead of www_post.py. This proved to be much
> simpler. I'm no
Il giorno mer, 31/03/2010 alle 11.01 +0100, Graham Percival ha scritto:
> Hmm, Francisco reported that the new website infrastructure was
> working a few weeks ago, without stripping the .html.
It doesn't work in its current state: the page
http://lilypond.org/people/graham/website/development.es
Il giorno mer, 31/03/2010 alle 12.16 +0100, Graham Percival ha scritto:
> Ah, I should remove that directory. The website is now in:
> http://lilypond.org/website/development.es.html
> Note that doc links are created from:
> scripts/auxiliary/create-weblinks-itexi.py
You mean scripts/build.
Il giorno mer, 31/03/2010 alle 19.31 +0100, Graham Percival ha scritto:
> On Wed, Mar 31, 2010 at 02:19:32PM +0200, John Mandereau wrote:
> > You mean scripts/build. Yay, yet another place for translating
> > strings :-P
>
> Not my problem.
You mean you don't care
Il giorno dom, 04/04/2010 alle 01.42 +0100, Graham Percival ha scritto:
> "make website" doesn't support being run multiple times. That's
> not an issue for lilypond.org, but it means that when you're
> testing things, you'll need to delete out-website/ from time to
> time.
Why not deleting out-
Il giorno dom, 04/04/2010 alle 17.20 +0200, Jan Nieuwenhuizen ha
scritto:
> just like -- see below -- news.itexi, also community.itexi
> has no dutch translation. These refs are also from the
> original english version -- same argument: should we mandate
> copies/ skeletons here?
>
> if so, iwbn
Il giorno sab, 10/04/2010 alle 14.32 +0200, Jan Nieuwenhuizen ha
scritto:
> And then there are comment entries from inline
> .ly file, such as
>
> #. Documentation/learning/tutorial.itely:256 (comment)
> msgid "c is 1 staff space up, so is the c above"
> msgstr ""
>
> #. Documentation/learning/tu
Hi Jan,
Il giorno sab, 10/04/2010 alle 20.19 +0200, Jan Nieuwenhuizen ha
scritto:
> Yesterday I fixed a texi2html node translation problem, skeleton
> files (untranslated files with most only @untranslated markers)
> are no longer necessary.
>
> I have fixed scripts/build/website_post.py and today
Il giorno lun, 19/04/2010 alle 19.54 +0100, Graham Percival ha scritto:
> It just occurred to me that providing an upgrade path would be
> very nice.
This could be handled by convert-ly, with an ordinary conversion rule,
or if anybody sees the requirement a rule that would be enabled only for
file
Il giorno dom, 12/09/2010 alle 11.45 -0700, Mark Polesky ha scritto:
> Is there a way to bypass the automatic "obscuring" of email
> addresses on any of the mailing list servers? Most texinfo
> patches end up mangled in the archives, and this is
> unfortunate; some good patches can become lost for
Hi Pavel,
Francisco has already replied to you while I was writing this, so the
reply about the node name issue w.r.t. cases in Czech is just a
rewording of his last reply.
Il giorno dom, 19/09/2010 alle 15.36 +0200, Pavel Fric ha scritto:
> I send the files in attachment. The .po file was sent a
Hi Pavel,
Le jeudi 23 septembre 2010 à 08:07 +0200, Pavel Fric a écrit :
> I have question on usage of case in @notation command
>
> Is it the same, as with @ref command - e. g. two commas, when there is
> need for usage of case?
No, @notation macro, defined in Documentation/common-macros.itexi,
Hi Graham,
Il giorno gio, 14/10/2010 alle 20.24 +0100, Graham Percival ha scritto:
> The best long-term option is to use a later version of gettext. The
> safest+laziest short-term solution is to get a
> libgnugetops-1.3.tar.bz2 that somebody downloaded as part of GUB
> within the past, oh, 6 mont
Besides the niptick, it looks good to me. I tested by building both
offline and online targets.
http://codereview.appspot.com/2520041/diff/1/python/auxiliar/postprocess_html.py
File python/auxiliar/postprocess_html.py (right):
http://codereview.appspot.com/2520041/diff/1/python/auxiliar/postpr
Il giorno dom, 17/10/2010 alle 18.28 +, percival.music...@gmail.com
ha scritto:
> On 2010/10/17 16:52:03, John Mandereau wrote:
> > python/auxiliar/postprocess_html.py:357: extra_depth = '../'
> > '../' is is not needed for translations, as output web pages
Il giorno dom, 17/10/2010 alle 21.22 +0200, John Mandereau ha scritto:
> BTW it should also be
> "manuals.it.html", not "development...". I'm commenting this in on
> Rietveld.
Please ignore this, I just didn't know what I wrote at that moment.
Sorry :-P
Il giorno dom, 17/10/2010 alle 20.38 +0100, Graham Percival ha scritto:
> The extra "../" is present in the docs, in the output of
> postprocess.html, if no attempt is made to rewrite the "return to doc
> index". I don't know if these exist in the docs previously (I suspect
> this is the case, tho
On 2010/10/17 21:14:11, Graham Percival wrote:
Here's another version. Note that the "extra depth" thing is now
added to the
*non*-translated version.
I have no clue why. I've spent 3 hours bashing against the build
process, and
that's enough for me.
CG 5.3 Debugging website and docs
Il giorno dom, 17/10/2010 alle 23.45 +0100, Graham Percival ha scritto:
> Eh? The patch only does stuff for the online target. That's what
> line 349 is supposed to do:
> if target == 'online':
Indeed, I'm really puzzled. I'm sure I looked at offline docs with your
second patch, but
AFAICT after a few hours of fiddling this issue is fixed, let's wait for
release to verify it (and not hopefully reopen it :-P). Let me know how
is current master. I've built and have checked both online and offline
targets, both split and big-page manuals, both docs in English and
Italian (so I'
Il giorno lun, 18/10/2010 alle 09.02 -0700, Patrick McCarty ha scritto:
> Yes, but unfortunately, LilyPond needs special sed treatment, since
> many substitutions are made *after* configure time. I will need to
> file a bug report...
>
> Specifically, I am looking for a way to make life easier wh
Il giorno lun, 18/10/2010 alle 09.20 -0700, Patrick McCarty ha scritto:
> On Mon, Oct 18, 2010 at 9:17 AM, John Mandereau
> wrote:
> > I don't understand the issue; can't you just set PYTHON=python2 when
> > calling configure, and in case you need some scripts
Il giorno lun, 25/10/2010 alle 15.24 +0200, Francisco Vila ha scritto:
> I can not extract the patch from lists.gnu.org, Gmane or Nabble.
> Either texinfo @commands are handled as hidden email addresses, or
> utf-8 codes mix with latin-1 ones, or both.
>
> Does anyone keep a copy of the message an
Il giorno sab, 11/12/2010 alle 12.02 +, Graham Percival ha scritto:
> Then you need to run
> ./autogen.sh
> in the *source* tree, followed by
> make distclean
> in the *source* tree.
FWIW, it's simpler and much faster to do two last steps with
./autogen.sh --noconfigure
in the *source* t
Il giorno mer, 15/12/2010 alle 11.15 -0700, Carl Sorensen ha scritto:
> Graham Percival wrote:
> > For a symptomatic treatment, this particular case could be checked
> > with
> > make test
> > instead of make doc. That'd be 5-10 minutes instead of an hour.
> > Not ideal by any means, but better
On 2011/01/01 00:47:54, Graham Percival wrote:
Please review.
LGTM, apart a nitpick: I prefer to create build directory outside git
tree, i.e. if foo/lily is my git repo, I build in foo/build, to avoid
build/ appear to git as an untracked file.
http://codereview.appspot.com/3823045/
_
Il giorno mar, 04/01/2011 alle 10.35 +, Graham Percival ha scritto:
> On Tue, Jan 04, 2011 at 09:58:46AM +, john.mander...@gmail.com wrote:
> > LGTM, apart a nitpick: I prefer to create build directory outside git
> > tree, i.e. if foo/lily is my git repo, I build in foo/build, to avoid
> >
Il giorno lun, 25/06/2012 alle 18.50 +0100, Phil Holmes ha scritto:
> And John M could no doubt help. It's a question of how much time they have
> to contribute.
If what we want to achieve is well enough specified, then I can offer to
go for it.
Cheers,
John
___
Il giorno lun, 25/06/2012 alle 12.31 +0100, Phil Holmes ha scritto:
> Yes, that directory exists. Good point. perhaps the best name would be
> /build/Documentation/snippet-src?
What about $(top-build-dir)/Documentation/snippets/out? (read
$(top-build-dir) as "build/" if you prefer)
> The same
Le mardi 26 juin 2012 à 08:06 +0100, Graham Percival a écrit :
> If you're going to rename stuff, I strongly suggest a bigger
> rename or you're asking for trouble. I suggest
> Documentation/lsr/ ? and Documentation/lsr/new/ ? and then the
> corresponding /build/ dirs will be created.
Regarding
Le mardi 26 juin 2012 à 10:17 +0100, Phil Holmes a écrit :
> We have 2 options:
>
> 1) Create $LILYPOND_GIT/Documentation/snippets as a straight copy-and-paste,
> which is very simple, but proliferates directories in git, and means that an
> update should mean deleting all the subdirectories of
Reviewers: Graham Percival,
Message:
I'm on submitting another patchset (later tonight).
http://codereview.appspot.com/6354044/diff/1/Documentation/contributor/administration.itexi
File Documentation/contributor/administration.itexi (right):
http://codereview.appspot.com/6354044/diff/1/Documen
Le mardi 26 juin 2012 à 13:39 +0100, Phil Holmes a écrit :
> It doesn't seem to make sense to me
> for it to run as part of make doc as well, since make is a required
> pre-cursor of make doc.
This doesn't seem to be true; think e.g. of
make LILYPOND_EXTERNAL_BINARY=lilypond doc
which AFAICT i
Le jeudi 28 juin 2012 à 13:13 +0100, Graham Percival a écrit :
> Yes, but git is still needed so that the LSR guy only needs to
> look at changes to the "unsafe" files. I think you already knew
> this, but I wanted to get this "on the record".
Sure, so the instructions related to this in makelsr
Il giorno gio, 28/06/2012 alle 15.14 +0200, John Mandereau ha scritto:
> > I'd assume that "snippets" should be a dependency of "doc". I
> > don't think it should be a dependency of "make", since programmers
> > won't want to recom
Please review:
http://codereview.appspot.com/6343055/
--
John Mandereau
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Hi,
Il giorno mar, 26/06/2012 alle 13.39 +0100, Phil Holmes ha scritto:
> Here's my summary of what I think needs to happen with the proposed
> management of the snippets:
>
> A tarball of snippets can be downloaded from
> http://lsr.dsi.unimi.it/download/. The tarball required is the one tagge
Il giorno ven, 29/06/2012 alle 11.00 +, gra...@percival-music.ca ha
scritto:
> LGTM, I think. I'm not completely certain what I'm reviewing here.
>
> I'm content to have this (whatever it is) go through, but in the future
> could you:
> - keep you changes in a separate git branch (locally)
>
Il giorno ven, 29/06/2012 alle 16.59 +0200, David Kastrup ha scritto:
> Well, if there are no other relevant feedbacks today, I am moving for
> the second date then (August 24th to 28th). It is a pity that we won't
> get everyone covered, but that's life. It doesn't preclude at least us
> two mee
Il giorno dom, 01/07/2012 alle 23.29 +0100, Graham Percival ha scritto:
> I'm not certain where we stand. Over the weekend, some patches
> were pushed (by accident?) to master. One (or more?) of those
> commits broke compiling, and were reverted. This fix was (or will
> be?) pushed to staging, a
Hello guys,
Sorry for having caused so much nuisance and having been offline in the
weekend :-(
I'm trying to resume on this issue, see below.
Il giorno sab, 30/06/2012 alle 16.59 +0100, Phil Holmes ha scritto:
> I think it's the first snippet that the build system tries to build with
> lilypon
Il giorno lun, 02/07/2012 alle 12.50 +0100, Phil Holmes ha scritto:
> It appears to kill the build system on a non-multi CPU make. See Mike's
> emails concerning screech-and-boink. I can replicate the problem with make,
> but if I run make -jX (X from 3 to 9) the build succeeds. Looks like
>
Il giorno lun, 02/07/2012 alle 05.47 +0200, Werner LEMBERG ha scritto:
> >> SUBDIRS = \
> >> python scripts \
> >
> > I'm a big fan of splitting lists into one entry per line; esp. if
> > you break at position 20 rather than 78.
>
> Yes! Of course, if you have a lot of small entries like
>
>
Il giorno mer, 04/07/2012 alle 10.31 +0100, Trevor Daniels ha scritto:
> I just made a mistake with git rebase and lost a branch I'd like to recover,
> but I don't know how or even if it is possible.
>
> Here's what I did.
>
> I checked out branch A
> then entered
>
> git rebase master
>
> Thi
Il giorno lun, 02/07/2012 alle 13.28 +0100, Phil Holmes ha scritto:
> From: "John Mandereau"
> > It succeeds (see attached log), and failure reports don't provide enough
> > details for me to investigate, so I'm stuck at this issue. Mike, David,
> > c
Il giorno lun, 09/07/2012 alle 13.20 +0100, Phil Holmes ha scritto:
> I sent a compressed logfile direct to you at 14:04 UTC on 2nd July. Could
> you check - it might have been classed as spam? I could put it on a website
> for you to grab if you want.
I had Gmail filters set up in a wrong way
Reviewers: lemzwerg,
Message:
On 2012/07/11 04:15:47, lemzwerg wrote:
http://codereview.appspot.com/6351083/diff/1/Documentation/contributor/lsr-work.itexi
File Documentation/contributor/lsr-work.itexi (right):
http://codereview.appspot.com/6351083/diff/1/Documentation/contributor/lsr-work.i
Reviewers: Graham Percival,
Message:
Hi Graham,
Thanks for the quick review, I'll upload another patch when I get
another review or at the earliest this week-end.
Please also note my comments on the bug tracker w.r.t. distribution of
lilypond.map and documentation.
http://codereview.appspot.c
nge, let's see what next Patchy run will tell. If you
have a better fix, please take over.
commit 3301083603577a891757ef798bae3db694cbcca0
Author: John Mandereau
Date: Tue Jul 17 21:56:42 2012 +0200
Quickly fix documentation build
diff --git a/Documentation/snippets/incipit.ly
b/Document
Il giorno mer, 18/07/2012 alle 00.52 +0200, David Kastrup ha scritto:
> The whole purpose of staging is that changes that should not get into
> master get _caught_ before they move into master (which is permanent).
> If you put "fixes" on _top_ of something bad in staging, the whole mess
> _will_ m
Il giorno mar, 17/07/2012 alle 22.13 +0200, David Kastrup ha scritto:
> It is not quite clear to me how the bug went through my tests, and why
> Patchy does not complain (apparently make doc does not compile the "new"
> snippets ?!?).
Not every change to every source file is checked by Patchy. In
Il giorno mer, 18/07/2012 alle 09.27 +0200, David Kastrup ha scritto:
> Well, now the accumulated mess in master is final, anyway. I have
> bumped staging to match it, so nothing is blocked anymore. I am not
> really interested in checking the consistency of all that since it
> consists of manual
Hi,
I'm trying to make match instructions in the CG to what makelsr script
does, in order to avoid future mess with Documentation/snippets/new, and
I see two good alternatives. Please give your motivated opinion, as I'm
not sure which one I prefer.
Note that in the case you change a single or a
Please review
http://codereview.appspot.com/6425045
I have tested with
make doc-clean
make clean
make -j3
which I believe is enough as the CG is plain Texinfo without LilyPond.
Cheers,
John
___
lilypond-devel mailing list
lilypond-devel@gnu.org
htt
Il giorno mer, 18/07/2012 alle 14.32 +0100, Phil Holmes ha scritto:
> From: "Graham Percival"
> Sent: Wednesday, July 18, 2012 2:18 PM
> > On Wed, Jul 18, 2012 at 03:08:55PM +0200, John Mandereau wrote:
> >> Note that in the case you change a single or a couple of
I tested makelsr without arguments. I kinda works, but I'd like the
snippet-list files to be updated when a tag is added or removed from a
snippet.
I'm working on a patch for this.
http://codereview.appspot.com/6416045/diff/4001/scripts/auxiliar/makelsr.py
File scripts/auxiliar/makelsr.py (rig
Il giorno mer, 18/07/2012 alle 20.39 +0100, Phil Holmes ha scritto:
> I pushed this about 30 seconds before your comments. TBH I think the best
> way of working is to put a patch up for comment, but push if you want -
> we're going to be the only people running the script, so we can keep
> upda
Il giorno mar, 17/07/2012 alle 06.32 +0100, Graham Percival ha scritto:
> http://lilypond.org/~graham/gop/gop_3.html
>
> *** Summary
>
> Let’s appoint David Kastrup as the “benevolent dictator” of the
> stable/2.16 git branch.
I approve all of this policy.
Best,
John
_
Il giorno mer, 18/07/2012 alle 14.18 +0100, Graham Percival ha scritto:
> On Wed, Jul 18, 2012 at 03:08:55PM +0200, John Mandereau wrote:
> > Note that in the case you change a single or a couple of snippets in
> > Documentation/snippets/new and don't want to update everythin
Reviewers: janek, dak,
Message:
Pushed to staging after moving the @warning as suggested.
http://codereview.appspot.com/6425045/diff/1/Documentation/contributor/administration.itexi
File Documentation/contributor/administration.itexi (right):
http://codereview.appspot.com/6425045/diff/1/Docume
On 2012/07/18 16:44:50, lemzwerg wrote:
This looks great! I don't have time right now to test it, but errors
will be
quite easily be caught :-) Thanks for fixing this.
I've uploaded a new patch that matches Git index and that integrated
suggestions from reviews, but comments like "Running d
It's OK as it is, but why the commented out text that refers to non-free
software cannot be deleted? If it's because we want to be able to find
a reference by looking at the source, Git history will tell.
http://codereview.appspot.com/6395049/
___
lil
On 2012/07/20 09:04:28, dak wrote:
On 2012/07/20 08:48:32, Graham Percival wrote:
> LGTM
I am somewhat concerned (meaning that I have no clue whatsoever, but a
queasy
feeling) about the implications for running/installing LilyPond in
various
directories. Will this do the right thing for t
Hi guys,
As you've noticed I no longer run lilypond-patchy-staging every 2 hours,
because I travelled and moved my computer I that was used to run it.
I've been trying to run it on MSH Paris Nord server, but as it builds
LilyPond in a Debian Sid install in a chroot and a Git repo which is a
local
Il giorno sab, 21/07/2012 alle 14.17 +0100, Phil Holmes ha scritto:
> I've run patchy staging a number of times, mostly selfishly to get patches
> into master to allow further work. I'd be happy to run it more often.
I don't remember of having seen email notifications of your runs,
though :-) M
Dear fellow developers,
I'm about to make lilypond-patchy-staging work on MSH Paris Nord server.
It is an old computer (Pentium 4 at 2 GHz, 2 GB of RAM),
so don't expect it to run much more than a slow but sure and regular
merger of staging into master, and possibly tester of patches and
translati
Il giorno lun, 23/07/2012 alle 19.25 +0200, David Kastrup ha scritto:
> Maybe running gerrit on it would be an option?
This sounds an excellent idea. My concern is which SMTP server to use
to handle the email sending load, as the MSH Paris Nord is a service
provider for Universities and Research
Il giorno lun, 23/07/2012 alle 20.42 +0100, Graham Percival ha scritto:
> On Mon, Jul 23, 2012 at 06:42:15PM +0200, John Mandereau wrote:
> > and we'd need A and DNS records for something like
> > builder.lilypond.org or builder.lilynet.net to make the machine
> >
Il giorno lun, 16/07/2012 alle 14.57 +0200, Federico Bruni ha scritto:
> info manuals are only in english?
> I can't see other languages in /usr/share/info
>
> both info and yelp show only the english version of the manual
> how can I see another language?
AFAIK there is no i18n design or support
2012/7/25 David Kastrup :
> Lilyfan writes:
>>> Message du 25/07/12 00:08
>>> De : "Trevor Daniels"
>>> A : "Graham Percival" , "John Mandereau"
>>> Copie à : "lilypond-devel"
>>> Objet : R
2012/7/23 John Mandereau :
> Il giorno lun, 23/07/2012 alle 19.25 +0200, David Kastrup ha scritto:
>> Maybe running gerrit on it would be an option?
>
> This sounds an excellent idea.
Wait, there has already been much discussion about patch review tools,
much of it happened when I
-- Forwarded message --
From: John Mandereau
Date: 2012/7/30
Subject: Re: Using MSH Paris Nord server
To: David Kastrup
2012/7/30 David Kastrup :
> Here is what I see as the required steps:
>
> a) get a gerrit server set up
> b) make test-patches.py deal with either
I wonder why Patchy has unconditionnally run configure with
--disable-optimising since last December or so.
I guess there used to be issues with optimisation for some GCC
versions. Could optimisations be enabled again now? Or better, could
we allow developers who run Patchy tune configure flags?
Sorry for duplicating a message again David, I'm bugged by an email
client I don't use often.
-- Forwarded message ------
From: John Mandereau
Date: 2012/7/30
Subject: Re: Patchy's configure flags
To: David Kastrup
2012/7/30 David Kastrup :
> The problem i
2012/7/30 Frédéric Bron :
>> I wanted to run regression tests and compare before and after a change.
>> However, I obtained the error given below after make -j8 CPU_COUNT=8 check
>>
>> I suspect this is because I am compiling with gcc/g++ 4.7.0 (coming
>> with Fedora 17) and its release notes say:
2012/7/30 Graham Percival :
> I'm not convinced that this is an advantage. I'd rather have one
> central place to look for patches and their status (currently
> google code, filtered by "has:Patch" and sorted based on patch
> status[1]). If "not bug fixes" patches aren't listed in the same
> plac
Il giorno mar, 31/07/2012 alle 09.45 +0100, Phil Holmes ha scritto:
> From:
> > 04:35:09 (UTC) Begin LilyPond compile, previous commit at
> > 1c980a9906a7ea01b9f99487e75580f7232f2491
> >
> > 04:35:11 Merged staging, now at: 1c980a9906a7ea01b9f99487e75580f7232f2491
> > 07:00:18 *** FAILED BUILD *
Il giorno lun, 30/07/2012 alle 15.21 +0100, Graham Percival ha scritto:
> Ok. I just want to emphasize that you could easily spend 20 hours
> setting this up, but then have the response be "no, we prefer the
> old system".
I got it :-P
> oh, logins just occurred to me. Can gerrit let people lo
When lilypond-patchy-staging.py a.k.a. Patchy succesfully builds on MSH
Paris Nord server, it now puts the docs on
http://194.254.171.80/lilypond-web/master/
This is intended for use by all developers and contributors; I'm not
sure whether it duplicates docs on kainhofer.com/~lilypond/, it depend
Il giorno mar, 31/07/2012 alle 16.27 +0100, Phil Holmes ha scritto:
> I'm assuming that changes to patchy will make this an "opt-in" option - I
> don't want to ftp megs of files from home whenever I run patchy...
Sure. BTW my changes don't add support for upload with
FTP/SSH/Rsync/whatever proto
Il giorno mar, 31/07/2012 alle 17.08 +0100, Graham Percival ha scritto:
> I suppose that something could go at the very bottom of that page,
> but it's kind-of full already. If we _do_ add anything like that,
> then we should thank GNU first and foremost, then google code,
> then rietveld, then ms
Il giorno mar, 31/07/2012 alle 12.12 +0200, John Mandereau ha scritto:
> I'm currently setting up the server with the default (OpenId), but I
> don't mind changing it if there are strong wishes for the other option.
Uh oh, OpenId login hits on the firewall (I haven't req
Il giorno mer, 01/08/2012 alle 15.21 +0200, David Kastrup ha scritto:
> Graham Percival writes:
> > On Wed, Aug 01, 2012 at 02:37:58PM +0200, David Kastrup wrote:
> >> If it is non-operative, it should be either made operative or removed.
> >> There is no point dragging it along as purely dead wei
I have nothing to say other than seconding comments from Graham.
http://codereview.appspot.com/6442068/diff/1/make/lysdoc-vars.make
File make/lysdoc-vars.make (left):
http://codereview.appspot.com/6442068/diff/1/make/lysdoc-vars.make#oldcode10
make/lysdoc-vars.make:10: LILYPOND_BOOK_FLAGS += --
Il giorno mer, 01/08/2012 alle 15.52 +0100, Graham Percival ha scritto:
> Regardless of the question of having a tuple of four values, it
> would be nice to support build numbers, i.e. 2.15.43-2:
> http://code.google.com/p/lilypond/issues/detail?id=977
>
> This definitely requires work in both lil
Il giorno mer, 01/08/2012 alle 19.26 +0200, David Kastrup ha scritto:
> Build numbers are not all that relevant for _us_ as far as I can tell.
> They distinguish different versions compiled from the _same_ canonical
> source (so they don't belong into our VERSION file at any rate).
> Changes may be
Il giorno mer, 01/08/2012 alle 18.08 +0100, Graham Percival ha scritto:
> Hmm. I can't answer this directly, but I'll pass along my
> considerations:
>
> - if you try to compile GUB on debian unstable (or any other
> recent distro), you will likely encounter odd compile failures.
> These are
Il giorno mar, 31/07/2012 alle 17.18 +0200, John Mandereau ha scritto:
> When lilypond-patchy-staging.py a.k.a. Patchy succesfully builds on MSH
> Paris Nord server, it now puts the docs on
>
> http://194.254.171.80/lilypond-web/master/
Update: thanks to Valentin, you can now (or
Il giorno mer, 01/08/2012 alle 20.51 +0100, Graham Percival ha scritto:
> I was particularly thinking of the download links and links to
> docs (on both the Downloads page and the Development page). That
> needs to do build number -> python -> texinfo macros -> html. But
> at least it's fully deb
Il giorno ven, 03/08/2012 alle 10.52 +0100, Graham Percival ha scritto:
> What about
> "acknowledgements" ? That node could go between Authors and
> Publications? (but unlike the old page of the same name, this
> page would only be for thanking non-developers/non-contributors)
This sounds good.
Hi guys,
I tried to submit commits in dev/jmandereau not in master to Rietveld
(git cl upload origin/master), but git-cl said just after I edited the
issue description
No output from ['git', 'show', 'aclocal.m4']
and exited. So below goes the issue description, that includes
instructions to tes
601 - 700 of 1573 matches
Mail list logo
