Hello,
On 19/02/2020 19:52, David Kastrup wrote:
pkx1...@posteo.net writes:
Hello and sorry I am late to the table on this - been a busy week for me.
On 19/02/2020 08:10, Jonas Hahnfeld wrote:
Am Dienstag, den 18.02.2020, 14:19 +0100 schrieb David Kastrup:
James <
pkx1...@posteo.net
writes
Here are the relevant parts of a correspondence between me and David.
> > "We have a situation where catering to several versions of Pango has
> > proven tricky to the degree of tripping you up."
> >
> > I think you see this patch as a proof that there is something
> > inherently tricky about work
Jonas Hahnfeld writes:
> Am Donnerstag, den 20.02.2020, 20:21 +0100 schrieb David Kastrup:
>> Jonas Hahnfeld writes:
>>
>> > Am Mittwoch, den 19.02.2020, 17:30 +0100 schrieb David Kastrup:
>> > > David Kastrup <
>> > > d...@gnu.org
>> > >
>> > > Moved this to dev/pango branch for now so that w
Am Donnerstag, den 20.02.2020, 20:21 +0100 schrieb David Kastrup:
> Jonas Hahnfeld <
> hah...@hahnjo.de
> > writes:
>
> > Am Mittwoch, den 19.02.2020, 17:30 +0100 schrieb David Kastrup:
> > > David Kastrup <
> > > d...@gnu.org
> > >
> > > > writes:
> > > > Han-Wen Nienhuys <
> > > > hanw...@gmail
Jonas Hahnfeld writes:
> Am Mittwoch, den 19.02.2020, 17:30 +0100 schrieb David Kastrup:
>> David Kastrup <
>> d...@gnu.org
>> > writes:
>>
>> > Han-Wen Nienhuys <
>> > hanw...@gmail.com
>> > > writes:
>> >
>> > > On Wed, Feb 19, 2020 at 9:19 AM Han-Wen Nienhuys <
>> > > hanw...@gmail.com
>> >
Am Mittwoch, den 19.02.2020, 17:30 +0100 schrieb David Kastrup:
> David Kastrup <
> d...@gnu.org
> > writes:
>
> > Han-Wen Nienhuys <
> > hanw...@gmail.com
> > > writes:
> >
> > > On Wed, Feb 19, 2020 at 9:19 AM Han-Wen Nienhuys <
> > > hanw...@gmail.com
> > > > wrote:
> > >
> > > > > +// Necess
pkx1...@posteo.net writes:
> Hello and sorry I am late to the table on this - been a busy week for me.
>
> On 19/02/2020 08:10, Jonas Hahnfeld wrote:
>> Am Dienstag, den 18.02.2020, 14:19 +0100 schrieb David Kastrup:
>>> James <
>>> pkx1...@posteo.net
writes:
Actually if you look on the
Hello and sorry I am late to the table on this - been a busy week for me.
On 19/02/2020 08:10, Jonas Hahnfeld wrote:
Am Dienstag, den 18.02.2020, 14:19 +0100 schrieb David Kastrup:
James <
pkx1...@posteo.net
writes:
Actually if you look on the tracker you'll see that I wrote
'Passes make, mak
David Kastrup writes:
> Han-Wen Nienhuys writes:
>
>> On Wed, Feb 19, 2020 at 9:19 AM Han-Wen Nienhuys wrote:
>>
>>>
+// Necessary for supporting pango_context_new() and
+// pango_context_set_font_map() in Pango < 1.22
+#define PANGO_ENABLE_BACKEND
+
>>>
>>> ..
>>
>>> I
Han-Wen Nienhuys writes:
>> > I think it's easier if we give up on intelligence here, and just
>> > recommend ccache.
>>
>> That does not seem like much of a help for the problem case at hand.
>
>
> Autoconf tries to leave the config.h alone, using content based checks.
>
> I assume it does this
On Wed, Feb 19, 2020 at 11:06 AM David Kastrup wrote:
> Han-Wen Nienhuys writes:
>
> > On Wed, Feb 19, 2020 at 10:03 AM David Kastrup wrote:
> >
> >>
> >> > So the dependency isn't correctly satisfied and we would always run it
> >> > from then on, effectively slowing down our build system. An
Han-Wen Nienhuys writes:
> On Wed, Feb 19, 2020 at 9:19 AM Han-Wen Nienhuys wrote:
>
>>
>>> +// Necessary for supporting pango_context_new() and
>>> +// pango_context_set_font_map() in Pango < 1.22
>>> +#define PANGO_ENABLE_BACKEND
>>> +
>>>
>>
>> ..
>
>> I'm preparing a docker image for my lily
Han-Wen Nienhuys writes:
> On Wed, Feb 19, 2020 at 10:03 AM David Kastrup wrote:
>
>>
>> > So the dependency isn't correctly satisfied and we would always run it
>> > from then on, effectively slowing down our build system. And that is
>> > why I don't want to deal with this kind of issues - th
On Wed, Feb 19, 2020 at 9:19 AM Han-Wen Nienhuys wrote:
>
>> +// Necessary for supporting pango_context_new() and
>> +// pango_context_set_font_map() in Pango < 1.22
>> +#define PANGO_ENABLE_BACKEND
>> +
>>
>
> ..
> I'm preparing a docker image for my lilypond-ci scripts that lets me check
> for
On Wed, Feb 19, 2020 at 10:03 AM David Kastrup wrote:
>
> > So the dependency isn't correctly satisfied and we would always run it
> > from then on, effectively slowing down our build system. And that is
> > why I don't want to deal with this kind of issues - this should come
> > with the build
Jonas Hahnfeld writes:
> Am Mittwoch, den 19.02.2020, 09:34 +0100 schrieb David Kastrup:
>> Jonas Hahnfeld <
>> hah...@hahnjo.de
>> > writes:
>>
>> > Am Dienstag, den 18.02.2020, 14:19 +0100 schrieb David Kastrup:
>> > > The procedure for a patch would be
>> > >
>> > > git apply --index .di
Am Mittwoch, den 19.02.2020, 09:34 +0100 schrieb David Kastrup:
> Jonas Hahnfeld <
> hah...@hahnjo.de
> > writes:
>
> > Am Dienstag, den 18.02.2020, 14:19 +0100 schrieb David Kastrup:
> > > The procedure for a patch would be
> > >
> > > git apply --index .diff
> > > ./autogen.sh --noconf
> >
Lukas-Fabian Moser writes:
> Le mer. 19 févr. 2020 à 09:08, David Kastrup a écrit :
>
> Color me curious: why would you try building staging? The whole point
>> of the staging system was to avoid breakage for developers. Only patchy
>> processes are supposed to care about staging.
>>
>
> Maste
Jonas Hahnfeld writes:
> Am Dienstag, den 18.02.2020, 14:19 +0100 schrieb David Kastrup:
>>
>> The procedure for a patch would be
>>
>> git apply --index .diff
>> ./autogen.sh --noconf
>> cd build
>> ../configure --enable-checking # and/or other desired options
>> make clean test-clean doc
Le mer. 19 févr. 2020 à 09:08, David Kastrup a écrit :
Color me curious: why would you try building staging? The whole point
> of the staging system was to avoid breakage for developers. Only patchy
> processes are supposed to care about staging.
>
Master didn't compile, and I tried staging ne
On Wed, Feb 19, 2020 at 12:51 AM David Kastrup wrote:
>
> >> Can you provide me with some recipe to reproduce the problem? Can you
> tell
> >> me what distribution you use? I could use Docker to recreate your setup.
> >
> > Just current Ubuntu eoan.
>
> The following patch makes the commit you pu
Am Dienstag, den 18.02.2020, 14:19 +0100 schrieb David Kastrup:
> James <
> pkx1...@posteo.net
> > writes:
> > Actually if you look on the tracker you'll see that I wrote
> >
> > 'Passes make, make test-baseline, and a full make doc.'
> >
> > This is probably my fault misunderstanding what can an
uite a while since I last pulled & compiled, so I was not very much
> surprised when make didn't succeed - I was halfway into trying to
> bisect to find out just when in the last few months it stopped working
> on my system when David's staging-broken alert arrived.)
rised when make didn't succeed - I was halfway into trying to bisect
to find out just when in the last few months it stopped working on my
system when David's staging-broken alert arrived.)
My system is a down-to-earth Mint 19.3.
Lukas
David Kastrup writes:
> Han-Wen Nienhuys writes:
>
>> On Tue, Feb 18, 2020 at 11:08 PM David Kastrup wrote:
>>
>>> Han-Wen Nienhuys writes:
>>>
>>> > This surprises me greatly. I just checked
>>> > out b16c3d14f3d1f10aa919e70107e6103c67a9aa01 which is what I pushed this
>>> > morning, and I c
Han-Wen Nienhuys writes:
> On Tue, Feb 18, 2020 at 11:08 PM David Kastrup wrote:
>
>> Han-Wen Nienhuys writes:
>>
>> > This surprises me greatly. I just checked
>> > out b16c3d14f3d1f10aa919e70107e6103c67a9aa01 which is what I pushed this
>> > morning, and I can execute
>> >
>> > ./autogen.sh
On Tue, Feb 18, 2020 at 11:08 PM David Kastrup wrote:
> Han-Wen Nienhuys writes:
>
> > This surprises me greatly. I just checked
> > out b16c3d14f3d1f10aa919e70107e6103c67a9aa01 which is what I pushed this
> > morning, and I can execute
> >
> > ./autogen.sh ; make -j4
> >
> > just fine. In fac
Han-Wen Nienhuys writes:
> This surprises me greatly. I just checked
> out b16c3d14f3d1f10aa919e70107e6103c67a9aa01 which is what I pushed this
> morning, and I can execute
>
> ./autogen.sh ; make -j4
>
> just fine. In fact, I actually did test this before pushing this morning.
>
> Could it be
I double checked, and it compiles at
b16c3d14f3d1f10aa919e70107e6103c67a9aa01 without error in a clean directory
as well.
Could you provide instructions how I can reproduce this build breakage?
thanks,
On Tue, Feb 18, 2020 at 10:56 PM Han-Wen Nienhuys wrote:
> This surprises me greatly. I just
This surprises me greatly. I just checked
out b16c3d14f3d1f10aa919e70107e6103c67a9aa01 which is what I pushed this
morning, and I can execute
./autogen.sh ; make -j4
just fine. In fact, I actually did test this before pushing this morning.
Could it be that you forgot to run autogen.sh ?
On T
James writes:
> Hello,
>
> On 18.02.2020 11:59, David Kastrup wrote:
>> David Kastrup writes:
>>
>>> Hi, staging does not compile anymore.
>>> Making lily/out/keyword.o < cc
>>> Making lily/out/simple-spacer-scheme.o < cc
>>> Making lily/out/episema-engraver.o < cc
>>> Making lily/out/lyric-ext
Hello,
On 18.02.2020 11:59, David Kastrup wrote:
David Kastrup writes:
Hi, staging does not compile anymore.
Making lily/out/keyword.o < cc
Making lily/out/simple-spacer-scheme.o < cc
Making lily/out/episema-engraver.o < cc
Making lily/out/lyric-extender.o < cc
Making lily/out/includable-lex
David Kastrup writes:
> Hi, staging does not compile anymore.
>
> Making lily/out/keyword.o < cc
> Making lily/out/simple-spacer-scheme.o < cc
> Making lily/out/episema-engraver.o < cc
> Making lily/out/lyric-extender.o < cc
> Making lily/out/includable-lexer.o < cc
> Making lily/out/timing-trans
Hi, staging does not compile anymore.
Making lily/out/keyword.o < cc
Making lily/out/simple-spacer-scheme.o < cc
Making lily/out/episema-engraver.o < cc
Making lily/out/lyric-extender.o < cc
Making lily/out/includable-lexer.o < cc
Making lily/out/timing-translator.o < cc
Making lily/out/pango-fo
2017-03-26 13:30 GMT+02:00 David Kastrup :
> Thomas Morley writes:
>
>> 2017-03-26 11:11 GMT+02:00 David Kastrup :
>>> Thomas Morley writes:
>>>
2017-03-26 10:06 GMT+02:00 David Kastrup :
> Backing out that patch from staging, and taking a further look.
How to proceed?
>>>
Thomas Morley writes:
> 2017-03-26 11:11 GMT+02:00 David Kastrup :
>> Thomas Morley writes:
>>
>>> 2017-03-26 10:06 GMT+02:00 David Kastrup :
>>>
Backing out that patch from staging, and taking a further look.
>>>
>>> How to proceed?
>>> Upload a fixed patch for review?
>>
>> Probably.
>
>
2017-03-26 11:11 GMT+02:00 David Kastrup :
> Thomas Morley writes:
>
>> 2017-03-26 10:06 GMT+02:00 David Kastrup :
>>
>>> Backing out that patch from staging, and taking a further look.
>>
>> How to proceed?
>> Upload a fixed patch for review?
>
> Probably.
Meanwhile I tried to upload a fixed pat
On Sun, 26 Mar 2017 10:53:19 +0200
Thomas Morley wrote:
> 2017-03-26 10:06 GMT+02:00 David Kastrup :
> > Thomas Morley writes:
> >
> >> 2017-03-26 0:48 GMT+01:00 James :
> >>> Hello
> >>>
> >>> After 5099 was pushed I am now seeing problems with basic
> >>> 'make'.
> >
> >>
> >> accident
Thomas Morley writes:
> 2017-03-26 10:06 GMT+02:00 David Kastrup :
>
>> Backing out that patch from staging, and taking a further look.
>
> How to proceed?
> Upload a fixed patch for review?
Probably.
> I'm terribly sorry for the additional work for you and James,
Not much work in my case. Ju
Thomas Morley writes:
> Sorry, for empty mail, misclicked.
> Obviously I need more coffee ...
>
> 2017-03-26 10:17 GMT+02:00 David Kastrup :
>> Thomas Morley writes:
>>
>>> accidently I permanently deleted the branch where the patch for issue
>>> 5099 was.
>>
>> That would be a rather difficult
Am 26. März 2017 10:59:03 MESZ schrieb Thomas Morley :
>Sorry, for empty mail, misclicked.
>Obviously I need more coffee ...
>
Yep.
"Sometimes I make me a coffee in the morning - but usually coffee makes *me*.
___
lilypond-devel mailing list
lilypond-
Sorry, for empty mail, misclicked.
Obviously I need more coffee ...
2017-03-26 10:17 GMT+02:00 David Kastrup :
> Thomas Morley writes:
>
>> accidently I permanently deleted the branch where the patch for issue
>> 5099 was.
>
> That would be a rather difficult feat (you don't do things like that
>
2017-03-26 10:06 GMT+02:00 David Kastrup :
> Thomas Morley writes:
>
>> 2017-03-26 0:48 GMT+01:00 James :
>>> Hello
>>>
>>> After 5099 was pushed I am now seeing problems with basic 'make'.
>
>>
>> accidently I permanently deleted the branch where the patch for issue 5099
>> was.
>> But I had it
2017-03-26 10:17 GMT+02:00 David Kastrup :
> Thomas Morley writes:
>
>> accidently I permanently deleted the branch where the patch for issue
>> 5099 was.
>
> That would be a rather difficult feat (you don't do things like that
> "accidentally" with Git since you have to work very hard to do them,
Thomas Morley writes:
> accidently I permanently deleted the branch where the patch for issue
> 5099 was.
That would be a rather difficult feat (you don't do things like that
"accidentally" with Git since you have to work very hard to do them,
with a set of very explicit commands unless you are
Thomas Morley writes:
> 2017-03-26 0:48 GMT+01:00 James :
>> Hello
>>
>> After 5099 was pushed I am now seeing problems with basic 'make'.
>
> accidently I permanently deleted the branch where the patch for issue 5099
> was.
> But I had it as git-formated patch, so I reapplied it to a new branc
2017-03-26 0:48 GMT+01:00 James :
> Hello
>
> After 5099 was pushed I am now seeing problems with basic 'make'.
>
> --snip--
>
> og level set to 287
> Relocation: is absolute:
> argv0=/tmp/build-lilypond-autobuild/out/bin/lilypond
> PATH=/tmp/build-lilypond-autobuild/out/bin (prepend) Setting PATH
Hello
After 5099 was pushed I am now seeing problems with basic 'make'.
--snip--
og level set to 287
Relocation: is absolute:
argv0=/tmp/build-lilypond-autobuild/out/bin/lilypond
PATH=/tmp/build-lilypond-autobuild/out/bin (prepend) Setting PATH
to
/tmp/build-lilypond-autobuild/out/bin:/tmp/buil
On Wed, Jan 11, 2017 at 10:44 AM, David Nalesnik
wrote:
> On Wed, Jan 11, 2017 at 10:25 AM, Trevor Daniels wrote:
>>
>> David Nalesnik wrote Wednesday, January 11, 2017 3:22 PM
>>
>>
>>> Ok, so I will probably do
>>>
>>> git revert HEAD
>>>
>>> in my staging branch
>>>
>>> and push it to origin/s
On Wed, Jan 11, 2017 at 1:52 PM, David Kastrup wrote:
> David Nalesnik writes:
>
>> On Wed, Jan 11, 2017 at 12:31 PM, David Kastrup wrote:
>>>
>>> It's nicer to _remove_ the patch from staging instead of adding the
>>> revert on top. However, that requires more skills. I can offer to do
>>> th
David Nalesnik writes:
> On Wed, Jan 11, 2017 at 12:31 PM, David Kastrup wrote:
>>
>> It's nicer to _remove_ the patch from staging instead of adding the
>> revert on top. However, that requires more skills. I can offer to do
>> this, but you'll still need to remove the patch on your side befo
On Wed, Jan 11, 2017 at 12:31 PM, David Kastrup wrote:
> David Nalesnik writes:
>
>> On Wed, Jan 11, 2017 at 10:25 AM, Trevor Daniels wrote:
>>>
>>> David Nalesnik wrote Wednesday, January 11, 2017 3:22 PM
>>>
>>>
Ok, so I will probably do
git revert HEAD
in my staging b
David Nalesnik writes:
> On Wed, Jan 11, 2017 at 10:25 AM, Trevor Daniels wrote:
>>
>> David Nalesnik wrote Wednesday, January 11, 2017 3:22 PM
>>
>>
>>> Ok, so I will probably do
>>>
>>> git revert HEAD
>>>
>>> in my staging branch
>>>
>>> and push it to origin/staging.
>>>
>>> ---
>>>
>>>
James writes:
> Hello,
>
> The snippet 'using-marklines-in-a-frenched-score.ly' in the recent
> makelsr commit
>
> http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=5fd7d7d19803c8b1cfac6324381c86dcc057a433
>
> contains a malformed TexInfo command
>
> @{Markdown}
>
> Which breaks make
On Wed, Jan 11, 2017 at 10:59 AM, James wrote:
> Hello,
>
>
>
> On 11/01/17 16:44, David Nalesnik wrote:
>>
>> On Wed, Jan 11, 2017 at 10:25 AM, Trevor Daniels
>> wrote:
>>>
>>> David Nalesnik wrote Wednesday, January 11, 2017 3:22 PM
>>>
>>>
Ok, so I will probably do
git revert HE
Hello,
On 11/01/17 16:44, David Nalesnik wrote:
On Wed, Jan 11, 2017 at 10:25 AM, Trevor Daniels wrote:
David Nalesnik wrote Wednesday, January 11, 2017 3:22 PM
Ok, so I will probably do
git revert HEAD
in my staging branch
and push it to origin/staging.
---
I won't attempt to cle
On Wed, Jan 11, 2017 at 10:25 AM, Trevor Daniels wrote:
>
> David Nalesnik wrote Wednesday, January 11, 2017 3:22 PM
>
>
>> Ok, so I will probably do
>>
>> git revert HEAD
>>
>> in my staging branch
>>
>> and push it to origin/staging.
>>
>> ---
>>
>> I won't attempt to clear the LSR queue in
David Nalesnik wrote Wednesday, January 11, 2017 3:22 PM
> Ok, so I will probably do
>
> git revert HEAD
>
> in my staging branch
>
> and push it to origin/staging.
>
> ---
>
> I won't attempt to clear the LSR queue in preparation for my patch
> update (as I did) by running makelsr.py a
On Wed, Jan 11, 2017 at 9:00 AM, James wrote:
> David
>
>
>
> On 11/01/17 14:31, David Nalesnik wrote:
>>
>> On Wed, Jan 11, 2017 at 8:26 AM, David Nalesnik
>> wrote:
>>>
>>> On Wed, Jan 11, 2017 at 5:19 AM, James wrote:
Hello,
The snippet 'using-marklines-in-a-frenched-score
David
On 11/01/17 14:31, David Nalesnik wrote:
On Wed, Jan 11, 2017 at 8:26 AM, David Nalesnik
wrote:
On Wed, Jan 11, 2017 at 5:19 AM, James wrote:
Hello,
The snippet 'using-marklines-in-a-frenched-score.ly' in the recent makelsr
commit
http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a
On Wed, Jan 11, 2017 at 8:26 AM, David Nalesnik
wrote:
> On Wed, Jan 11, 2017 at 5:19 AM, James wrote:
>> Hello,
>>
>> The snippet 'using-marklines-in-a-frenched-score.ly' in the recent makelsr
>> commit
>>
>> http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=5fd7d7d19803c8b1cfac63243
On Wed, Jan 11, 2017 at 5:19 AM, James wrote:
> Hello,
>
> The snippet 'using-marklines-in-a-frenched-score.ly' in the recent makelsr
> commit
>
> http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=5fd7d7d19803c8b1cfac6324381c86dcc057a433
>
> contains a malformed TexInfo command
>
> @{M
Hello,
The snippet 'using-marklines-in-a-frenched-score.ly' in the recent
makelsr commit
http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=5fd7d7d19803c8b1cfac6324381c86dcc057a433
contains a malformed TexInfo command
@{Markdown}
Which breaks make doc and so cannot be merged into
2013/5/8 David Kastrup :
> James writes:
>
>> Hello,
>>
>> While trying to merge Staging just now, it fails on make
>
>> 405: 2* (let* ((file-name (%search-load-path x))) (ly:debug "[~A"
>> file-name) ...)
>> 409: 3* [primitive-load-path
>> "/tmp/build-lilypond-autobuild/out/share/lilypond/curre
James writes:
> Hello,
>
> While trying to merge Staging just now, it fails on make
> 405: 2* (let* ((file-name (%search-load-path x))) (ly:debug "[~A"
> file-name) ...)
> 409: 3* [primitive-load-path
> "/tmp/build-lilypond-autobuild/out/share/lilypond/current/scm/define-grobs.scm"]
> In
> /tm
Hello,
While trying to merge Staging just now, it fails on make
--snip--
[/tmp/build-lilypond-autobuild/out/share/lilypond/current/scm/define-woodwind-diagrams.scm]
[/tmp/build-lilypond-autobuild/out/share/lilypond/current/scm/display-woodwind-diagrams.scm]
[/tmp/build-lilypond-autobuild/out/sha
Le 10/03/2013 08:00, David Kastrup disait :
David Kastrup writes:
Removed that commit from staging. It should be fixed in the
translation branch.
I mean: it is currently broken in the translation branch and should get
fixed in the translation branch before trying the merge again.
Now fix
David Kastrup writes:
> Removed that commit fron staging. It should be fixed in the
> translation branch.
I mean: it is currently broken in the translation branch and should get
fixed in the translation branch before trying the merge again.
--
David Kastrup
_
James writes:
> Hello
>
> On 9 March 2013 21:44, James wrote:
>
> I'll take a look and see if I can see what it is.
>
>
> James
>
> It's in the French Translations
>
> La propriété @code{tupletSpannerDuration} spécifie la longueur voulue
> de
> chaque crochet. Avec elle, vous
Hello
On 9 March 2013 21:44, James wrote:
> I'll take a look and see if I can see what it is.
>
> James
>
It's in the French Translations
--snip--
l.10 commande @cod
@code{\tuplet}. < HERE!
?
./c2/lily-10413738.texidocfr:10: Emergency stop.
l.10 commande @cod
I'll take a look and see if I can see what it is.
James
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Mike
On 8 January 2012 12:48, m...@apollinemike.com wrote:
> Hey all,
>
> On my lilybuntu box, I am consistently getting a doc fail from current master
> on this file. The problem is the embedded post script. It seems like it's a
> ghostscript error:
I'm not getting this. My make doc is stil
Mike
On 8 January 2012 12:48, m...@apollinemike.com wrote:
> Hey all,
>
> On my lilybuntu box, I am consistently getting a doc fail from current master
> on this file. The problem is the embedded post script. It seems like it's a
> ghostscript error:
>
> Invoking `gs -dSAFER -dDEVICEWIDTHPOIN
Hello,
On 8 January 2012 13:07, James wrote:
> Mike
>
> On 8 January 2012 12:48, m...@apollinemike.com wrote:
>> Hey all,
>>
>> On my lilybuntu box, I am consistently getting a doc fail from current
>> master on this file. The problem is the embedded post script. It seems
>> like it's a ghos
Mike
On 8 January 2012 12:48, m...@apollinemike.com wrote:
> Hey all,
>
> On my lilybuntu box, I am consistently getting a doc fail from current master
> on this file. The problem is the embedded post script. It seems like it's a
> ghostscript error:
>
> Invoking `gs -dSAFER -dDEVICEWIDTHPOIN
Hey all,
On my lilybuntu box, I am consistently getting a doc fail from current master
on this file. The problem is the embedded post script. It seems like it's a
ghostscript error:
Invoking `gs -dSAFER -dDEVICEWIDTHPOINTS=595.28 -dDEVICEHEIGHTPOINTS=841.89
-dCompatibilityLevel=1.4 -dNOPAUSE
On Jan 7, 2012, at 5:23 AM, Graham Percival wrote:
> I've branched current staging -- unfortunately *after* removing
> two patches which seemed to break stuff -- to staging-broken-jan7.
> I picked one patch, Mike's non-negativity check, to put into the
> new staging on the
I've branched current staging -- unfortunately *after* removing
two patches which seemed to break stuff -- to staging-broken-jan7.
I picked one patch, Mike's non-negativity check, to put into the
new staging on the theory that it was the least likely to be
breaking stuff.
If somebod
On Fri, Jan 06, 2012 at 04:38:05PM +, Ian Hulin wrote:
> On 06/01/12 12:38, Graham Percival wrote:
> > I see **tons** of messages like
> > Defined "column-markup" function in #
> > which doesn't look like it should exist in production code. It's
> > certainly not helpful when trying to debug
On 06/01/12 12:38, Graham Percival wrote:
> hmm, I think I forgot to do something while reconfiguring my
> desktop. Anyway, make doc fails.
>
> I see **tons** of messages like
> Defined "column-markup" function in #
> which doesn't look like it should exist in production code. It's
> certainly
Graham Percival writes:
> hmm, I think I forgot to do something while reconfiguring my
> desktop. Anyway, make doc fails.
>
> I see **tons** of messages like
> Defined "column-markup" function in #
> which doesn't look like it should exist in production code. It's
> certainly not helpful when
Graham,
On 6 January 2012 12:38, Graham Percival wrote:
> hmm, I think I forgot to do something while reconfiguring my
> desktop. Anyway, make doc fails.
I did a full make doc this morning from staging just after my two
pushed patches and had no problems.
So anything in
3 hours ago Mike S
hmm, I think I forgot to do something while reconfiguring my
desktop. Anyway, make doc fails.
I see **tons** of messages like
Defined "column-markup" function in #
which doesn't look like it should exist in production code. It's
certainly not helpful when trying to debug doc build failures.
S
ent
> master (or current staging) and staging-broken-dec23 ?
Sure, as long as new commits interfere...
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On Sat, Dec 24, 2011 at 11:07:59PM +0100, David Kastrup wrote:
> git log another..branch
>
> Of course, things that have been cherry-picked already are still listed.
Can't that be avoided by looking at the difference between current
master (or current staging) and staging-broken-d
7;t you ask google "git list of commits on one branch but
> not another" yourself?
git log another..branch
Of course, things that have been cherry-picked already are still listed.
My original listing was
git log --oneline --decorate release/2.15.23-1..origin/staging-broken-dec-
On Sat, Dec 24, 2011 at 05:13:29PM +0100, David Kastrup wrote:
> Graham Percival writes:
>
> > Patchy is running every 6 hours at the moment (GMT / 6), and
> > there's no rush to get another release out, so let's just put
> > stuff into staging gradually.
>
> to see about a day's worth of develo
On Sat, Dec 24, 2011 at 07:16:47PM +0100, m...@apollinemike.com wrote:
> On Dec 24, 2011, at 1:43 AM, Graham Percival wrote:
>
> > Patchy is running every 6 hours at the moment (GMT / 6), and
> > there's no rush to get another release out, so let's just put
> > stuff into staging gradually.
>
> C
On Dec 24, 2011, at 1:43 AM, Graham Percival wrote:
> Hey all,
>
> In order to remove the blockage to development, I've made a copy
> of the previous staging branch: it's now called
> staging-broken-dec23. I've replaced staging with
> master+release/unstable,
Graham Percival writes:
> Patchy is running every 6 hours at the moment (GMT / 6), and
> there's no rush to get another release out, so let's just put
> stuff into staging gradually.
Actually, doing
git log --oneline --decorate release/2.15.23-1..origin/staging-broken-dec-
Graham Percival writes:
> Hey all,
>
> In order to remove the blockage to development, I've made a copy
> of the previous staging branch: it's now called
> staging-broken-dec23. I've replaced staging with
> master+release/unstable, and Patchy is testing tha
Hey all,
In order to remove the blockage to development, I've made a copy
of the previous staging branch: it's now called
staging-broken-dec23. I've replaced staging with
master+release/unstable, and Patchy is testing that right now.
Once that's been accepted to master, p
92 matches
Mail list logo
