On Mon, 2019-11-04 at 10:38 +0100, Jonas Hahnfeld wrote:
> To be honest I don't know because the binaries don't even start to
> execute due to not having the correct libc. So what's the expected
> procedure here? There is no libc in the installation tarball, is there
> some documentation on what's
On Mon, 2019-11-18 at 19:29 +0100, Jonas Hahnfeld wrote:
> Sure, but does it fix an issue that makes it "critical" enough to add
> the new relocation code fairly late in the process?
For the discussion that motivated these changes, see
ly accept GUB pull
requests; I'd have added nothing more than a remark that lilypond-
ancient was a GUB setup for building ancient LilyPond versions on
recent systems; given the amount on work to build current versions, I
can understand it's been removed.
Best
--
John Mandereau
atch for building GUB on PureOS
(Debian 10 derivative), for both master and stable/2.20, the former
built from scratch and the latter after having moved uploads directory
and "rm -rf target/*/*/*lilypond*".
Best
--
John Mandereau
C++ in LLVM since one
year ago, LilyPond depends on GCC or equivalent, see the thread
starting at
https://lists.gnu.org/archive/html/lilypond-devel/2018-11/msg00019.html
Best
--
John Mandereau
testing
them on PureOS (a Debian 10 Buster derivative).
Best
--
John Mandereau
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On Fri, 2019-03-22 at 13:41 +, Phil Holmes wrote:
> The website is now also updated - I had previously forgotten that I
> would
> need to update news and VERSION etc. in staging and master. This has
> to be
> done because the website is built from master automatically.
Great!
I'm a bit
On Wed, 2019-03-20 at 12:53 +, Phil Holmes wrote:
> I understand this would be possible if someone puched a change to
> release/unstable without it going through staging/master. However,
> in the
> life of LilyPond I don't think it has ever happened. so may not be
> worth
> being too
On Tue, 2019-03-19 at 11:20 +, Phil Holmes wrote:
> John,
>
> Please let me/the list know if you're successful.
I completed a non-clean GUB build with stable/2.20 branch, in 1h07min,
done after a successful GUB build of master branch (4h05min, on a
laptop with Intel Core i7-7500U and Debian
On Tue, 2019-03-19 at 11:20 +, Phil Holmes wrote:
> Please let me/the list know if you're successful. It would also help
> me immensely if you could post a set of instructions (like the ones
> for development builds in the CG at
>
On Tue, 2019-03-19 at 00:00 +0100, David Kastrup wrote:
> The currently rather long persisting release-less state is quite a
> nuisance and I have problems understanding what stopped our releases
> from working when they did work previously and I am not aware of
> things particularly breaking this
Hi folks,
I already asked almost one month ago if we could we cherry-pick the
following commits from master:
88633ac Issue 5469/2: Add `TEX` environemnt variable for texi2pdf
e757c64 Issue 5469/1: Tweak wrapped lines
002382c Issue 5463: Fix dblatex uses xetex backend
Without them, GUB build on
This looks good to me, except a phrasing nitpick.
https://codereview.appspot.com/566540043/diff/566530044/Documentation/contributor/source-code.itexi
File Documentation/contributor/source-code.itexi (right):
Hi folks,
On Sun, 2019-03-03 at 16:01 +, James Lowe wrote:
>
> Push:
>
> 5477 Broken links in website pages - john-mandereau
> https://sourceforge.net/p/testlilyissues/issues/5477
> http://codereview.appspot.com/361790043
Sorry for the delay, I pushed it a couple of
Le dim. 24 févr. 2019 à 23:09, John Mandereau a
écrit :
> > What about "TEXINFO_MANUALS_WITHOUT_WEB"?
>
> To make the contest a little bit more interesting, what about the
> following ones?
>
> NON_WEBSITE_TEXINFO_MANUALS
> TEXINFO_MANUALS_WITHOUT_WEBSITE
Werner LEMBERG wrote:
> Yes, I could try to generate the packages and upload them to a given
> place. However, I've never done a lilypond release before, so any
> guidance would be helpful.
I hope the guidance from our Contributors' Guide is as good for this as
it has been for me to get back to
Le dimanche 24 février 2019 à 21:04 +0100, John Mandereau a écrit :
> Werner LEMBERG wrote:
> > https://codereview.appspot.com/363930043/diff/1/Documentation/GNUma
> > ke
> > file#newcode54
> > Documentation/GNUmakefile:54: TEXINFO_MANUALS_BUT_WEB
> > = $(fil
Werner LEMBERG wrote:
> https://codereview.appspot.com/363930043/diff/1/Documentation/GNUmake
> file#newcode54
> Documentation/GNUmakefile:54: TEXINFO_MANUALS_BUT_WEB
> = $(filter-out
> web,$(TEXINFO_MANUALS))
> LGTM except this variable name. Could you invent a different one?
What about
Werner LEMBERG wrote:
> we had some good progress with GUB. However, in the last few weeks
> the development stalled, which is not good. I thus propose the
> following.
>
> * The pull requests as described in
>
> https://lists.gnu.org/archive/html/lilypond-devel/2019-01/msg0022
> 1.html
>
David Kastrup wrote:
> Huh. Maybe the Ubuntu compilation of gcc/g++ disabled some warnings?
>
> g++ --verbose
> Using built-in specs.
> COLLECT_GCC=g++
> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
> OFFLOAD_TARGET_NAMES=nvptx-none
> OFFLOAD_TARGET_DEFAULT=1
> Target:
On February 21 2019 18:07 +, Trevor wrote:
> Added with Developer privileges. Welcome!
Thanks Trevor; at the end of the issue creation, an auto-generated
email bounced with
"""
Your mail to 'Testlilyissues-auto' with the subject
[testlilyissues:issues] #5482 Do not build PDFs from the
v.villen...@gmail.com wrote:
> page-turn-page-breaking.cc: In instantiation of 'bool is_break(T*)
> [with
> T = Grob]':
> page-turn-page-breaking.cc:50:54: required from here
> page-turn-page-breaking.cc:38:3: warning: operation on '*0' may be
> undefined [-Wsequence-point]
> if (turnable
>
Le mer. 20 févr. 2019 à 00:26, John Mandereau a
écrit :
> It's certainly possible, it must boil down to filtering out web from
> TEXI_FILES or TEXINFO_MANUALS, and give this to PDF_FILES definition in
> the makefiles. I'm testing a patch for this.
>
Could somebody please add me
Werner LEMBERG wrote:
> Obviously, I don't have objections :-)
OK, upon guidelines recalled by David, I did this only for staging
branch for now, after a succesful clean make, 'make doc' and glances at
the Essay and Notation manual in PDF.
Best,
John
Hi folks,
As suggested by Werner on February 8th in "Please test GUB" thread, we
should update tex/texinfo.tex in our sources from Texinfo git repo. Is
there any objection to applying this change on both staging and
stable/2.20 branches without the usual review process?
I also have another
Werner LEMBERG wrote:
> Yes, I think we should prevent that, if possible – they are indeed of
> no practical use.
It's certainly possible, it must boil down to filtering out web from
TEXI_FILES or TEXINFO_MANUALS, and give this to PDF_FILES definition in
the makefiles. I'm testing a patch for
Ccache), I get the same error as with
system's GCC (8.2.1), error you've already reported.
Best
--
John Mandereau
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
were
interpreted in Latin-1.
FWIW I used as a test input
https://www.mutopiaproject.org/cgibin/piece-info.cgi?id=2240
with application of convert-ly.
Best
--
John Mandereau
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
code. With this in mind, the last
revised algorithm you sent looks good to me.
Best
--
John Mandereau
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
r for potential users who are not
comfortable with handling complex software dependencies.
Best
--
John Mandereau
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
our is quite
> erratic and has some bugs...
You allude to many issues we had with GUB builds, don't you?
Best
--
John Mandereau
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
a big patch for cross-building Python
2.7; lots of tests of Python scripts in binaries may be necessary when
this is ready to be built.
Best
--
John Mandereau
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
.
I'll do other builds from scratch, testing newer pull requests on top
of #53-60, and will also make an attempt on Fedora 29 plus local
install of GCC 7 (with GCC 8 shipped with this distro, tools:guile GUB
build fails, and it seems hard to fix).
testing binaries, "localdoc", and examining regresssion tests
comparison, with several branches (master and stable/2.20) have
certainly a higher priority.
Best
--
John Mandereau
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
and linux-(arch)::gs needs a different
directory in LD_LIBRARY_PATH, namely target/linux-64/root/usr/lib.
I haven't investigated when and why such a wrapper would be necessary,
but if it is, it might be saner to define
LD_LIBRARY_PATH=%(system_prefix)s/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}
inste
ad success on Ubuntu 14.04 with GUB master branch merged with
PRs #53, #54, #55, #56 and LilyPond revision 17c0c744 from master
branch. What are the commonly agreed criteria for merging GUB pull
requests? FTR I have write access on gperciva/gub, but I'm still
people, so my little available time can
be spent on upgrading Python in GUB, which is now for me a challenge as
great as hacking the build system a decade ago.
Best
--
John Mandereau
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://
On Sat 2019-01-19 00:01 +0100, John Mandereau wrote:
> I merged GUB PRs 53 and 54 (with respective revisions c410c4b and
> d1c9a24, which are older than current ones)
I didn't realize Github lists commits of a pull request in
chronological order, the opposite of "git log",
n I reach this stage I'll issue a patch or a
Git branch.
Best
--
John Mandereau
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
th build attempts on Fedora, so I'd rather keep that
conservative setup at the moment and help with issues on the side of
the target, and Python seems to be first on the list.
Greetings
--
John Mandereau
___
lilypond-devel mailing list
lilypond-d
-test--j2-CPU_COUNT=2-ANTI_ALIAS_FACTOR=1.txt
FWIW that time it was a random segfault on some reg test; as the build
passed last time, I won't investigate that crash by looking at LilyPond
code.
--
John Mandereau john.mander...@gmail.com
___
lilypond
Il giorno sab, 10/11/2012 alle 14.35 +0100, Francisco Vila ha scritto:
2012/11/9 Phil Holmes em...@philholmes.net:
I've just built 2.16.1 and will be uploading it later this evening. All
seems OK except I tried to create a regtest comparison versus 2.16.0 and
instead got a comparison of
: Children (1 0) exited with errors.
--
John Mandereau john.mander...@gmail.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Il giorno mar, 09/10/2012 alle 09.57 +0200, David Kastrup ha scritto:
John Mandereau john.mander...@gmail.com writes:
Hi,
I quote some of the logs below...
Il giorno mar, 09/10/2012 alle 00.33 +, grenoui...@lilynet.net ha
scritto:
21:58:01 (UTC) Begin LilyPond compile, previous
Il giorno ven, 05/10/2012 alle 08.11 -0700, philehol...@googlemail.com
ha scritto:
Begin LilyPond compile, commit: 4ed5d7710416aff0a9e68f0d751b4e15c30fdf92
Merged staging, now at: c9d806f28ab690c3f210e14153c6bd31d506588e
Success:./autogen.sh --noconfigure
showing the update to latest release:
http://code.google.com/p/lilypond/issues/detail?id=2850
Thanks for the report
--
John Mandereau john.mander...@gmail.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo
Il giorno gio, 13/09/2012 alle 23.13 -0700, Graham Percival ha scritto:
http://lilypond.org/~graham/gop/gop_6.html
** Summary
We’ve gone over the same arguments a number of times, so let’s try
to resolve them. Fluff will go on a new mailing lilypond-quacks
mailing list. Serious proposals,
Hi Dominik,
Il giorno mar, 18/09/2012 alle 04.38 -0700, ornello ha scritto:
timesig22-emmentaler16
http://lilypond.1069038.n5.nabble.com/file/n133112/timesig22-emmentaler16.png
timesig22-emmentaler20
http://lilypond.1069038.n5.nabble.com/file/n133112/timesig22-emmentaler20.png
Il giorno mar, 18/09/2012 alle 14.11 +0200, David Kastrup ha scritto:
John Mandereau john.mander...@gmail.com writes:
David, could we bump Fontforge minimum version to 20110222 for the next
2.16 release as well?
How would that have to be done?
By cherry-picking
Le mardi 18 septembre 2012 à 18:50 +0100, James a écrit :
On 18 September 2012 13:55, ornello dominik.hoer...@fun.de wrote:
What about simply increasing the fontforge version check number in the
configure script?
It already is isn't it?
Not in stable/2.16.
John
Il giorno gio, 13/09/2012 alle 10.44 +0200, Francisco Vila ha scritto:
2012/9/8 Francisco Vila paconet@gmail.com:
Hi John,
as things are today, can we keep doing the usual merges of
translation--staging and master--translation?
I still had no response,
I think the message that
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 you
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 objects
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
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
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
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 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 master
Il giorno mar, 28/08/2012 alle 19.00 +0100, Phil Holmes ha scritto:
- Original Message -
From: grenoui...@lilynet.net
To: lilypond-a...@gnu.org
Cc: lilypond-devel@gnu.org
Sent: Tuesday, August 28, 2012 5:39 PM
Subject: Patchy report
13:58:03 (UTC) Begin LilyPond compile,
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 results are
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 saying yes,
this patch
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 as
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
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
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 but
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,
if
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
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:
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
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
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
likely
2012/8/27 Han-Wen Nienhuys hanw...@gmail.com:
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
2012/8/28 Jan Nieuwenhuizen jann...@gnu.org:
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
2012/8/28 Phil Holmes m...@philholmes.net:
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
2012/8/27 Federico Bruni fedel...@gmail.com:
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
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
Hi James,
2012/8/27 James pkx1...@gmail.com:
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
Hi Jan,
2012/8/27 Jan Nieuwenhuizen jann...@gnu.org:
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
2012/8/27 d...@gnu.org:
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
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
2012/8/27 Jan Nieuwenhuizen jann...@gnu.org:
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
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
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 d...@gnu.org:
One stupid way to keep those directories is to place an empty .gitignore
2012/8/27 Phil Holmes m...@philholmes.net:
- Original Message - From: john.mander...@gmail.com
To: philehol...@googlemail.com; gra...@percival-music.ca;
reinhold.kainho...@gmail.com
Cc: re...@codereview-hr.appspotmail.com; lilypond-devel@gnu.org
Sent: Monday, August 27, 2012 3:37 PM
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
2012/8/27 Phil Holmes em...@philholmes.net:
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
2012/8/27 Phil Holmes m...@philholmes.net:
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
2012/8/27 Phil Holmes m...@philholmes.net:
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
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
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:18Success:
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
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 21|egrep -q -e '-L?D\.?$';
then
It seems that egrep vs.
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... Spaces
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
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
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
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
1 - 100 of 1439 matches
Mail list logo
