Il giorno sab, 04/08/2012 alle 00.39 +0200, John Mandereau ha scritto:
> I kindly ask a review of
> the four commits on top of master that are in dev/jmandereau branch on
> Savannah git repo.
Sorry, I forgot to attach the patches, but better is telling how to get
them from Git: first
Hi Phil,
Le samedi 04 août 2012 à 14:02 +0100, Phil Holmes a écrit :
> Hi John - is this patch designed to fix problems like:
>
> http://lists.gnu.org/archive/html/lilypond-devel/2011-11/msg00360.html
Yes, exactly; the commit that adresses this issue is among the four top
commits in dev/jmanderea
Hi Han-Wen,
Thanks for these comments, I'll submit another patch as soon as I get
back to my faster laptop to retest changes extensively.
Le samedi 04 août 2012 à 12:00 -0300, Han-Wen Nienhuys a écrit :
> * is there a need for vc-clean at all? People can just git clone the
> repo when they want to
Hi guys,
Sorry to flood -devel with many Patchy failures, but we're still at an
early stage of experimenting concurrent runs of Patchy-staging, ones
on-demand made on fast machines, and ones made on Grenouille that take
hours but (hopefully) runs every 8 hours [1] without human intervention.
Previ
Le samedi 04 août 2012 à 16:44 +0100, Phil Holmes a écrit :
> The step after I checkout your branch failed with this as the last few
> lines:
>
> touch ./out/share/lilypond/current/lilypond-force
> make --no-builtin-rules out=www clean
> make[1]: Entering directory `/media/IntelSSD/lilypond/lilyp
Le lundi 06 août 2012 à 10:48 +0200, David Kastrup a écrit :
> This should actually be more diverse. Before pushing the new
> test-staging, Patchy should redo git fetch.
>
> It should then check that
>
> git log -1 origin/staging..test-staging
>
> has _empty_ output If this is _not_ the ca
[adding on -devel]
Le lundi 06 août 2012 à 12:12 +0200, John Mandereau a écrit :
> I guess the state where you brought StepMake made it a potential
> competitor to Automake (but not Autoconf); I have never used Automake,
> but after having read a bit about it (comments on the web, wikiped
Le lundi 06 août 2012 à 14:08 +0100, Graham Percival a écrit :
> They have a 0.9.8.6 release candidate 1 -- from 2010 Oct 26. That
> doesn't inspire confidence. Is there a more up-to-date website
> for recent development
Nope.
> , or is this now unsupported software?
It's not developed very a
Le lundi 06 août 2012 à 13:32 +0200, David Kastrup a écrit :
> And zero exit status (no error): it is conceivable that origin/staging
> has just been deleted (which only is necessary if you want to drop some
> commits from it) and not yet replaced by something else, in which case
> this command wil
Le lundi 06 août 2012 à 21:00 +0200, Francisco Vila a écrit :
> Dear Grenouille: after merging translation into staging I failed at
> compiling lilypond, but I rm-rf'd regression/ and lily/ , reset hard,
> and all went well.
Dear Paco,
Please, always test a merge translation and staging with a *c
Le lundi 06 août 2012 à 21:59 +, grenoui...@lilynet.net a écrit :
> 18:34:15 (UTC) Begin LilyPond compile, previous commit at
> 952705000581a13836e6a733df04511e93c5
> 18:34:26 Merged staging, now at: 952705000581a13836e6a733df04511e93c5
> 18:34:28 Success:
Le mardi 07 août 2012 à 01:49 +, grenoui...@lilynet.net a écrit :
> 22:24:01 (UTC) Begin LilyPond compile, previous commit at
> aee96a7ae52324a75ea735d172d2ef028802c860
> 22:24:14 Merged translation, now at: 952705000581a13836e6a733df04511e93c5
> 22:24:17 Success:
Le samedi 04 août 2012 à 17:40 +0200, David Kastrup a écrit :
> > * is there a need for vc-clean at all? People can just git clone the
> > repo when they want to have a clean tree.
>
> git clean -f -X
To remove direoctories, this should be
git clean -f -d -X
--
John
__
Hi guys,
I'll be offline from this morning 10.30 CET for a few days (I go to the
countryside without Internet access), I'm attaching uncommitted changes
to Patchy made on Grenouille; this is a total mess, changes should be
split up in several commits, and some code rewrite might not hurt, I'll
tak
Le lundi 06 août 2012 à 16:49 +0200, Jan Nieuwenhuizen a écrit :
> I agree, and such scoping happens to be supported by GNU Make, although
> I have rarely seen it being used. Consider attached example and see
> node Pattern-specific and node Target-specific in the doc.
Ah yes, I'm sure we already
Il giorno sab, 04/08/2012 alle 16.44 +0100, Phil Holmes ha scritto:
> FWIW it also failed on the lines
>
> $LILYPOND_GIT/configure
>
> for reasons I don't understand, but must be something to do with bash.
> Replacing the variable with the actual path worked.
Maybe it's because there's a tilde
Il giorno mar, 07/08/2012 alle 18.04 +0100, Graham Percival ha scritto:
> On Tue, Aug 07, 2012 at 06:57:17PM +0200, John Mandereau wrote:
> > Maybe it's because there's a tilde '~' in LILYPOND_GIT that is not
> > expanded, when I submit next iteration of the pat
Il giorno sab, 04/08/2012 alle 00.39 +0200, John Mandereau ha scritto:
> 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 ['
Le dimanche 05 août 2012 à 13:57 +, lilyp...@googlecode.com a
écrit :
> Comment #20 on issue 2673 by gra...@percival-music.ca: Volta improvements
> http://code.google.com/p/lilypond/issues/detail?id=2673
[snip]
> (BTW, with the Paris server, it would be easy to put the regtest comparison
> fo
ee/make.log && \
make ${MAKE_FLAGS} test &>$HOME/lily-new-intree/make-test.log && \
make ${MAKE_FLAGS} doc &>$HOME/lily-new-intree/make-doc.log && \
make install &>$HOME/lily-new-intree/make-install.log && \
make install-doc &>$HOME/lily-new-i
Le dimanche 12 août 2012 à 14:16 +0100, Graham Percival a écrit :
> Actually, there's an unforseen problem: the website can only
> advertise VERSION_STABLE and VERSION_DEVEL. STABLE is obviously
> 2.14.2 until 2.16.0 is out. If we want testing for the
> pre-releases (which we obviously do), then
Le dimanche 12 août 2012 à 21:07 +0100, Graham Percival a écrit :
> I don't think so. People can get 2.14 from the "old releases" if
> they want.
Oh right.
> I think that automatic patch tests are /far/ more important than
> having multiple release versions on the website.
Agreed, it's also m
Le vendredi 10 août 2012 à 13:25 +0200, Reinhold Kainhofer a écrit :
> I let a cronjob build origin/master from scratch every night at 01:30 am
> CEST (UTC+2) and upload the docs to my server.
So your setup makes a clean build like Patchy, with the difference that
Patchy actually builds staging, t
Le dimanche 12 août 2012 à 23:03 +0200, David Kastrup a écrit :
> > because I'd like to submit fixes for issues 2366 and 2529 and get them
> > committed in stable/2.16 branch.
>
> 2366 (update THANKS) is obviously ok.
Up to source tarball rolling (make dist), in this case it was easy:
http://cod
Le dimanche 12 août 2012 à 14:48 +0200, David Kastrup a écrit :
> Documentation improvements are still admissable, documentation rewrites
> not necessarily as we want to avoid significant changes between the
> English documentation and reasonably well-maintained translations. I
> have no clear vie
I haven't built (well, a "make all" is going to test this change with
"makeinfo --info", but even only this takes ages on an Intel Atom), but
LGTM. (FWIW I checked that all occurences have been dealt with in
Pitches and Rhythms with
git grep subheading Documentation/notation/*
.)
http://coderevi
Le lundi 13 août 2012 à 10:55 +0200, David Kastrup a écrit :
> I haven't really tracked translations so far, so my own level of
> suitability here is pretty close to zero, modulo non-task-specific
> computer expertise (which some people deem sufficient for making me
> useful for Windows support, a
Reviewers: Graham Percival, dak,
Message:
On 2012/08/13 09:32:10, dak wrote:
You have taken the path of removing THANKS altogether if I understand
correctly.
Yes, as I was away from development during late 2.13 and almost all of
2.15 series, I'm not the best person to update THANKS in case we
Dear users of Patchy,
I have pushed a lot of changes, especially to staging/master branch, it
would be good if you could pull from lilypond-extra:master to test them:
https://github.com/gperciva/lilypond-extra/commit/054d8101e7bcd54bc8db40092b617bb8b2220b84
I have already tested these features w
Le mardi 14 août 2012 à 13:58 +0100, James a écrit :
> The last two checkins break something.
>
> --snip--
> line 184, in make_directories
> run ("git branch -f test-%s %s/master" % (branch_name,
> remote_branch_name ("master")))
> File "/home/james/patchy/patches/compile_lilypond_test/__ini
Il giorno lun, 13/08/2012 alle 16.21 +0200, David Kastrup ha scritto:
> If I handled it, I would try cherry-picking and praying. If your
> proposal is in your comfort zone, I'd not mind letting you handle it.
> However, I am not sure that the typical translator will understand what
> is expected o
must be done from scratch in a build
directory separate from source tree. I take over from this task and
will give notice if I have difficulty doing so frequently enough (say,
twice a week). Merging translation and stable/2.16 should be done with
the same care.
Best,
John M
Hi Mike,
Le vendredi 17 août 2012 à 13:20 -0400, m...@mikesolomon.org a écrit :
> I'm running the regtests and I think a while loop may not be exiting. Is
> there any way to see in which file LilyPond hangs on the loop?
ps w -H |less
or if the build is not a child of the shell you're using
ps
Hi Francisco,
Il giorno sab, 18/08/2012 alle 23.56 +0200, Francisco Vila ha scritto:
> and allright. I have many pendant tasks as a plain translator; if I
> need something more than pushing to translation to be done, I'll say.
If your pendant tasks had master branch as upstream, you should be fine
Hi Mike,
Il giorno sab, 18/08/2012 alle 19.38 -0400, m...@mikesolomon.org ha
scritto:
> In the Mac OS X build I did of the LilyPond source LilyPond cannot
> find the Century fonts.
Did configure or "make all" failed? Which error message did you get?
If it's configure, can you double check that yo
Il giorno dom, 19/08/2012 alle 16.02 +, gra...@percival-music.ca ha
scritto:
> Could you add a script (either shell or python) which applies this
> formatting to all scheme files in the repository? I'd like to see how
> that changes the scheme files.
You can try running (after having applied
Il giorno dom, 19/08/2012 alle 22.34 +0200, David Kastrup ha scritto:
> John Mandereau writes:
> > emacs -batch scm/*.scm --eval '(progn (delete-trailing-whitespace)
> > (indent-region (point-min) (point-max) nil) (untabify (point-min)
> > (point-max)) (save-buffer
Il giorno dom, 19/08/2012 alle 21.57 +0100, Ian Hulin ha scritto:
> Hi John and David,
> If you take this on, John, or if David decides to revisit this, can
> you add something like this to the detailed description of the issue:
>
> "This patch adds a new file dir-locals.el to the root directory o
Il giorno dom, 19/08/2012 alle 18.06 +0100, Graham Percival ha scritto:
> I think that Ian's confusion is understandable. Files inside
> elisp/*.el are mostly not intended for developers. At least,
> stuff like elisp/lilypond-mode.el seems to be aimed directly at
> end-users, not developers.
>
>
Il giorno dom, 19/08/2012 alle 20.28 -0400, m...@mikesolomon.org ha
scritto:
> Nothing to do with iosnoop, but I did some snooping in the code base and I
> can't figure out why LilyPond wouldn't raise an error if it doesn't find a
> font. In all-font-metrics.cc, there is:
[snip]
> So it must f
Il giorno lun, 20/08/2012 alle 00.39 +0200, David Kastrup ha scritto:
> The only reasonable way to address the amount and kind of concerns
> voiced here is not to apply the patch. Instead, one should likely
> explain in CG how to use M-x add-dir-local-variable RET to achieve its
> equivalent. In
Reviewers: ,
Message:
Note: these two new files (.dir-locals.el from David Kastrup and
fixscm.sh from me) actually operate independently, see
http://lists.gnu.org/archive/html/lilypond-devel/2012-08/msg00450.html
and so they may be applied independently one from the other; if both are
applied, t
Il giorno lun, 20/08/2012 alle 08.28 +0200, David Kastrup ha scritto:
> The possibly contentious case is when the user has put up an independent
> .dir-local.el file. Git will complain before overwriting that without
> confirmation, so you'll get warning (not for git reset --hard or similar
> thou
Il giorno lun, 20/08/2012 alle 10.11 +, d...@gnu.org ha scritto:
> http://codereview.appspot.com/6450162/diff/1/scripts/auxiliar/fixscm.sh
> File scripts/auxiliar/fixscm.sh (right):
>
> http://codereview.appspot.com/6450162/diff/1/scripts/auxiliar/fixscm.sh#newcode15
> scripts/auxiliar/fixscm.
Il giorno lun, 20/08/2012 alle 12.49 +0200, David Kastrup ha scritto:
> Sigh. I have _never_ been proposing indent-tabs-mode in scheme-mode,
> and most certainly my patch proposal was _quite_ the opposite, with the
> _opposite_ effect.
>
> Please don't further spread that myth.
>
> It is not my
Hi James,
Il giorno lun, 20/08/2012 alle 10.40 +0100, James ha scritto:
> I am not able to work out how to force patchy during a test-patches.py
> to also make doc as well as the test and test-baseline.
>
> I don't have access to my machine I run patchy on at the moment - it
> is at home and I am
Il giorno lun, 20/08/2012 alle 13.53 +0100, James ha scritto:
> On 20 August 2012 13:09, John Mandereau wrote:
> > If you mean the BUILD_ALL_DOCS switch in the core code of the builder
> > (patches/compile_lilypond_test/__init__.py),
>
> Yes I was.
The ability to run &
Il giorno lun, 20/08/2012 alle 15.53 +0100, James ha scritto:
> What might be more convenient - depending on the approach - is to be
> able to arbitrarily run ./test-patchy.py at a tracker issue regardless
> of patch status and build the doc based on it.
This was added in
commit cbd969135e8ec8c08f
Il giorno lun, 20/08/2012 alle 16.59 +0100, James ha scritto:
> Would it be 'easier' to copy test-patches (so to speak) and rename it
> to make-doc-patches and then we have a third command - test-* accept-*
> make-doc-* - and I could run
>
> make-doc-patches 2345
This could be easier for you call
I've never got so far than this time, as I've managed to complete
make bootstrap
make -f lilypond.make bootstrap
at the price of ugly kludgy operations, so I thought a report would be
of some interest for GUB hackers.
After this, any attempt to build LilyPond with GUB failed at configure,
with a
Sorry for the delay Phil, I had missed this message.
Le mercredi 08 août 2012 à 09:59 +0100, Phil Holmes a écrit :
> I've been looking at how the regression test comparison works. The first
> thing I find is that we have 2 effectively duplicate, but different, pages
> on running regtest comparis
Le mardi 21 août 2012 à 13:05 -0400, Julien Rioux a écrit :
> On line #431, change quick_make=True to quick_make=False and you will be
> doing a `make doc' (in addition to `make check' and everything).
>
> A command-line switch would be much better, but for the time being this
> is something you
Le mercredi 22 août 2012 à 18:43 +0100, Graham Percival a écrit :
> Presumably the script was tested with bash, but was being run with
> sh or dash? or something like that?
I tested "make dist" succesfully on my system, but without being sure if
sh on my distro would behave as bash or not... Spa
Le mercredi 22 août 2012 à 20:20 +0200, David Kastrup a écrit :
> And people wonder why I am queasy about taking last-minute build-system
> changes into the stable branch.
The change that introduced this breakage (tracker issue 2719) has been
put for review on Rietveld on August 7th (more than two
Hi James,
> 09:24:02 (UTC) Begin LilyPond compile, previous commit at
> d14e4770b85b3cacc647e45b9ebfe59cc085753f
> 09:24:07 Merged staging, now at:
> d14e4770b85b3cacc647e45b9ebfe59cc085753f
> 09:24:08Success:./autogen.sh --noconfigure
> 09:24:18Succes
Hi guys,
After lots of testing, debugging, and commits editions cycles, I've
pushed many changes to Patchy in lilypond-extra master branch. Most
changes regard Patchy on a server and patches testing.
These changes are expected to make existing Patchy setups work at
least as well as before; on th
LGTM except one nitpick (see comment).
http://codereview.appspot.com/6484062/diff/1/configure.in
File configure.in (right):
http://codereview.appspot.com/6484062/diff/1/configure.in#newcode174
configure.in:174: if $FONTFORGE --version 2>&1|egrep -q -e '-L?D\.?$';
then
It seems that egrep vs. gr
Hi James,
2012/8/27 James :
> I tried to use these changes this morning - there were 3 patches all
> at new - while it all ran as normal there were a couple of things I
> noticed that I'd like a clarification (in case I misunderstood the
> other explanations).
I tried to minimize the changes in Pa
Hi Jan,
2012/8/27 Jan Nieuwenhuizen :
> It appears that the fix we made in your branch for DB is correct.
> Have a look at target/tools/src/python-2.4.5/setup.py:527
>
> db_setup_debug = False # verbose debug prints from this script?
>
> and below...
>
> Setup.py looks for /usr/include/*d
2012/8/27 :
> On 2012/08/27 09:04:46, dak wrote:
>> You are confusing grep -E with grep -e. -e just says that the next
>> word is the regular expression to look for rather than an option, and it is
>> required since the regular expression starts with dash itself.
>
>
> Actually, one should just u
LGTM
(to enlighten the potential bias that made me say LGTM, as I looked at
all changes in the patch but I'm not fluent at all in C++, I also have
astyle 2.02.1 on Fedora 17 :-p)
http://codereview.appspot.com/6477062/
___
lilypond-devel mailing list
l
2012/8/27 Jan Nieuwenhuizen :
> Also, did you see Joe's mail about anydbm? I misread his mail earlier,
> of course he is using /usr/bin/python [that's needed for bootstrapping]
> so we probably want what he suggests: in gub/2/db.py only have
>
> import anydbm as db
I'm trying to rebuild with
http://codereview.appspot.com/6486067/diff/1/Documentation/web/introduction.itexi
File Documentation/web/introduction.itexi (right):
http://codereview.appspot.com/6486067/diff/1/Documentation/web/introduction.itexi#newcode1067
Documentation/web/introduction.itexi:1067: to try out all the program
I don't see the point of hiding/getting rid of these warnings, when
1) for now these warnings are harmless outside Documentation/??
2) if you want to get rid of the cause of the warning it should require
not more than adding at the beginning of
generic-targets.make:doc-stage-1
make -C $(top-build
Hi Phil,
I hoped that missing directories would be supported, and saw those
warnings too but thought they were harmless and didn't bother. Adding
dummy files is the easiest solution.
2012/8/27 David Kastrup :
> One stupid way to keep those directories is to place an empty .gitignore
> file in th
2012/8/27 Phil Holmes :
> - Original Message - From:
> To: ; ;
>
> Cc: ;
> Sent: Monday, August 27, 2012 3:37 PM
> Subject: Re: Reduces langdefs.py warnings in doc build (issue 6487046)
>
>
>
>> I don't see the point of hiding/getting rid of these warnings, when
>> 1) for now these warni
After some discussion on developing a ly to xml export program, I
thought that the using engravers to plug such a converter to ly input
at a processing stage that would avoid parsing ly files and allow to
get any ly file converted, provided that (from advice from Mike) you
take into account how the
2012/8/27 Phil Holmes :
> If you can put a patch to do this on staging, I'd be more than happy.
> Thanks.
OK, will do, likely tonight.
> In the old days, we would have needed to remember to update GUB's file list,
> but you've fixed that?
As Graham has managed to build with GUB sources freshly
2012/8/27 Phil Holmes :
> Anyone object if I push a patch that adds -q to the call to bib2texi direct
> to staging?
As long as any error of bib2texi can still be found in some log file,
I have no objection.
Best
J
___
lilypond-devel mailing list
lilypo
2012/8/27 Phil Holmes :
> I've updated generic-targets as you suggest, to this:
>
>
> doc-stage-1:
> make -C $(top-build-dir)/Documentation/po out=www messages
> $(MAKE) -C $(depth)/scripts/build out=
> $(MAKE) out=www WWW-1
>
> It builds the .mo files, as you were intending, but I get this error:
2012/8/27 Phil Holmes :
> With my patch, on my machine, I don't get warnings for the regtests, because
> they're built after the docs (and therefore after the .mo files are
> created).
You should not rely on this in general: when documentation-dir
variable is empty, and if your patch was applied a
http://codereview.appspot.com/6487046/diff/1/GNUmakefile.in
File GNUmakefile.in (right):
http://codereview.appspot.com/6487046/diff/1/GNUmakefile.in#newcode12
GNUmakefile.in:12: input
Switching the build order of subdirectories here should not be relevant
for solving the issue, if you need it th
2012/8/27 Han-Wen Nienhuys :
> Note that you can plug into the music event stream directly. That will
> give you an overview of all events.
This sounds a nice idea, but I don't know how to do this, I started
(re)reading Erik Sandberg's thesis and then guess it'll be easy to dig
out a starting poin
2012/8/28 Jan Nieuwenhuizen :
> Have a look at Graham's waltrop branch, it contains a number of fixes
> and will see more soon [until we switch back to master, of course].
When Graham managed to rebuild stable/2.16 with waltrop branch, he
merged it into master, so checking out that waltrop branch
2012/8/28 Phil Holmes :
> Yes - "it" is Gub. I might try getting it working on 64 bit once I've
> bedded down regularly running it in the VM.
Running GUB inside a VM must slow it down a lot, you might want to
build by chrooting into the mounted partition(s) that the VM used
instead, with the hope
2012/8/27 Federico Bruni :
> I've stumbled again on this error while running make doc:
>
> http://lilypond-translations.3384276.n2.nabble.com/make-doc-error-cannot-import-name-TexModule-td7467314.html
>
> Here's the output:
>
> cd ./out-www && dblatex suffix-lyxml.xml
> Build the book set list...
>
Reviewers: lilypond-devel_gnu.org,
Message:
This is a new version of Werner's patch (Rietveld issue 6459081), with
no changes to cyrillic.itexi, a configure check added, and the inclusion
of cyrillic.itexi moved to common-macros.itexi so that translated
manuals include it too.
Description:
Add s
Hi Graham , James and LilyPond folks,
Il giorno mer, 29/08/2012 alle 13.26 +0100, Graham Percival ha scritto:
> John, could you disable staging-merge on Grenouille? that should
> free up some computing resources for the other tasks.
Done, I also just reenabled patches tests, which given the new s
Il giorno mer, 29/08/2012 alle 14.09 +0100, James ha scritto:
> Just an off-the-cuff suggestion. If we had a 'patch-new-doc' and a
> 'patch-new' label would that be useful and tell patchy if it sees the
> former to build doc as well?
This is a possible option. Another that I prefer is letting Pat
Il giorno mer, 29/08/2012 alle 14.28 +0100, James ha scritto:
> They did reduce significantly since Phil and I were able to run tests
> quickly. I often would run tests myself after the normal patchy tests
> simply because I knew a change was significant (like Mike's skyline
> for instance or Phils
Hi David,
Il giorno mer, 29/08/2012 alle 16.37 +0200, David Kastrup ha scritto:
> Hi, I just looked at the repository, and picked out the patch that was
> required for bypassing the bashism. However, I don't think that the
> "touch all manual pages" thing actually belongs in there and should
> lik
Il giorno mer, 29/08/2012 alle 22.52 +0100, James ha scritto:
> OK I have set up all the push access and done a test and it seems to
> work, I cannot yet get it to send the email.. hmm.. probably some
> silly typo somewhere.
Might a sample msmtp configuration file help? IIRC I sent one to Phil,
i
Il giorno gio, 30/08/2012 alle 08.57 +0100, Trevor Daniels ha scritto:
> I don't think the patch for this issue should have been tested.
> It has been marked 'patch-needs-work' since 29 May.
It should have been marked Patch-abandoned then (BTW isn't there an
script that is supposed to automate thi
Il giorno gio, 30/08/2012 alle 09.54 +0100, Graham Percival ha scritto:
> There's no script. Colin Campbell occasionally does it manually.
There's a non negligible number of old issues with Patch=needs-work:
http://code.google.com/p/lilypond/issues/list?can=2&q=Patch=needs_work&sort=-modified&col
Il giorno ven, 31/08/2012 alle 00.38 +0200, David Kastrup ha scritto:
> grenoui...@lilynet.net writes:
>
> > 21:58:01 (UTC) Begin LilyPond compile, previous commit at
> > e15e0d22810063b79da891bbf472ecc39d09c02c
> > 21:58:15 From git.savannah.gnu.org:/srv/git/lilypond
> >5d2bd06..e15e0d2 m
Il giorno mar, 28/08/2012 alle 19.00 +0100, Phil Holmes ha scritto:
> - Original Message -
> From:
> To:
> Cc:
> Sent: Tuesday, August 28, 2012 5:39 PM
> Subject: Patchy report
>
>
> > 13:58:03 (UTC) Begin LilyPond compile, previous commit at
> > e6073c719af153e80ba9f31ed96040a3782a1
Il giorno gio, 30/08/2012 alle 09.29 +0200, Marc Hohl ha scritto:
> Am 30.08.2012 06:46, schrieb lilyp...@googlecode.com:
> >
> > Comment #6 on issue 2790 by grenoui...@lilynet.net: Patch: bar-line
> > interface part 2/2
> > http://code.google.com/p/lilypond/issues/detail?id=2790#c6
> >
> > Build
Il giorno gio, 30/08/2012 alle 18.15 +0100, James ha scritto:
> Yes actually that would help. Also what would be useful in a similar
> vein would be what I need to configure where in my 'config' so that
> when I do accept or reject patchy.py I don't have to keep adding my
> user and password to the
Il giorno gio, 30/08/2012 alle 12.52 +0100, Graham Percival ha scritto:
> On Thu, Aug 30, 2012 at 11:38:51AM +0200, John Mandereau wrote:
> > every new comment on those issues with old patches will trigger a test.
>
> That's definitely overkill! What if I post a comment sayin
Il giorno ven, 31/08/2012 alle 13.21 +0100, Graham Percival ha scritto:
> That sounds good to me! If we treat Grenouille more like a web
> server than a workhorse, then I think it'll go smoother.
I would have preferred a workhorse, but in its current state it has
proven to be not so well usable a
Il giorno ven, 31/08/2012 alle 11.10 +0200, David Kastrup ha scritto:
> Some of the recent reports from Grenouille actually might suggest that
> it might be testing against an unrelated test-baseline.
Patchy currently doesn't check, and AFAIK has never checked, whether
master branch has changed be
Il giorno ven, 31/08/2012 alle 16.04 +0100, Phil Holmes ha scritto:
> I've just got back on this, and confirmed that adding
>
> $(MAKE) -C $(top-build-dir)/Documentation/po out=www messages
>
> to the top of the doc-stage-1 recipe gets rid of the warnings, so in fact it
> makes the build work co
Il giorno ven, 31/08/2012 alle 18.43 +0100, James ha scritto:
> I'll need to double check remember that I post links to zipped files.
> I never checked the size of the show- regtest dir that gets
> created. That might be larger although I cannot imagine that png files
> compress that much more
Hi James,
Il giorno mer, 05/09/2012 alle 23.13 +0100, James ha scritto:
> http://code.google.com/p/lilypond/issues/detail?id=2811
>
> Compare mine to its.
>
> You'll see programming errors - which seem to appear on all the other
> recent patch tests.
IIRC these programming errors about undead ob
Il giorno dom, 02/09/2012 alle 15.31 +0100, James ha scritto:
> I run ./test-patchy.py as normal.
[snip]
> If I look in the *.ly file corresponding to the log I get this:
>
> --snip--
> jlowe@jlowe26vm /tmp/show-2801/out$ more
> /tmp/show-2801/out/lybook-testdb/snippet-names-892580628.ly
>
> snip
Hi Janek,
Il giorno lun, 03/09/2012 alle 00.26 +0200, Janek Warchoł ha scritto:
> i remember that you are investigating whether we could be using Gerrit
> for Lily work. I may've asked this question already, but i don't
> remember whether there was a definitive answer: does gerrit have a web
> int
Il giorno gio, 06/09/2012 alle 10.39 +0100, James ha scritto:
> It's more than that, we really did have a few patches with
> 'programming error' messages from other developers, so while there is
> any doubt I end up having to redo the tests anyway, which kind of
> makes the reg test on Grenouille p
LGTM, but why is this Rietveld issue still open whereas the patch has
been pushed?
http://codereview.appspot.com/6496074/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Il giorno lun, 10/09/2012 alle 15.08 +0100, Phil Holmes ha scritto:
> On
> http://lilypond.org/doc/v2.17/Documentation/contributor/minor-release-checklist
>
> it says:
>
> "Switch to the release branch, get changes, prep release announcement. This
> requires a clean index and work tree. If the
Il giorno lun, 10/09/2012 alle 16.12 +0100, Phil Holmes ha scritto:
> Thanks, John. I'm following the CG to the letter, and type:
>
> git checkout origin/release/unstable
>
> This puts me into detached head state - presumably because I don't have a
> local branch called release/unstable.
If yo
701 - 800 of 1573 matches
Mail list logo
