Re: gub targets + binary packages
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 needed? Do I need to install some > compatibility libraries? (A quick search suggested that they have been > dropped some years ago, but I may be missing something) > If the answer is "copy the libc from GUB" (which is not in the > tarball), I'd expect bad things to happen with two libc from different > "vendors" (BSD vs GNU) that are probably ABI- and possibly API- > incompatible. I thought I would be able to find in the archives which compatibility libraries commonly available in FreeBSD are needed, but I couldn't find anything precise. This should be documented; if it's too much of a hassle to figure out, it may be a good reason to drop FreeBSD targets. Best, John
Re: What is holding up 2.20 release?
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 https://lists.gnu.org/archive/html/lilypond-devel/2019-02/msg00080.html Although they fix a bug in a very special case, IMVHO they do not sound really critical but fall more in the cleanup category. Note that if cherry-picking commits from issue 5481 is approved, then the changes brought by these commits will need to be slightly reworked or some or all commits for issue 5471 (at least 5471/1 for the additional optional argument of sane_putenv and probably also 5471/2) will have to be cherry-picked too. About the general cherry-picking process, I'm happy to provide occasional GUB build test on it – I just launched it for dev/hahnjo/stable-2.20. Best, John
Re: gub targets + binary packages
On Fri, 2019-10-18 at 11:00 +0200, Jonas Hahnfeld via lilypond-devel wrote: > (I didn't bother with > freebsd because the binaries don't work AFAICT.) Do these binaries don't work only because the matching (old) version of C stdlib for LilyPond GUB package is not installed on your FreeBSD (this is a common issue reported several times on this list), or is there some deeper issue? > Is there a maintainer for gub who could take a look at my Pull > Requests > on GitHub? > https://github.com/gperciva/gub/pulls/hahnjo I'm no longer responsive quickly enough to effectively 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
Re: gub build succeeds
On Sat, 2019-11-02 at 13:47 +0100, Werner LEMBERG wrote: > As the title says: A complete gub build succeeds again on my > GNU/Linux > openSUSE platform if I apply > > https://github.com/gperciva/gub/pull/70 > > to gub's master branch. Great! I also had success with this patch 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
Re: lilypond does not work with Mac OS 10.15 (Catalina)
On Sat, 2019-10-12 at 01:21 -0400, Eric Benson wrote: > gcc8 doesn’t build in MacPorts on Catalina, at least it didn’t build for me > on Thursday. There was a MacPorts release on Friday, but I haven’t tried it > yet. Maybe the problem has been fixed. I never got lilypond to build with > gcc8 because I couldn’t build gcc8. I just modified the Portfile so it used > gcc9 instead. As far as I know, there’s no reason to think that lilypond > would have a dependency on any particular version of gcc, or even on gcc at > all. Unless there has been relevant changes related to 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
Re: gub targets + binary packages
Hi Jonas, On Fri, 2019-10-18 at 11:00 +0200, Jonas Hahnfeld via lilypond-devel wrote: > Is there a maintainer for gub who could take a look at my Pull > Requests > on GitHub? > https://github.com/gperciva/gub/pulls/hahnjo Thanks for this work, I'll examine your PRs too this week-end, 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
Re: Can GUB-build stable/2.20 [was Re: Still cannot build GUB with stable/2.20 branch]
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 puzzled by the news items history, and also by the difference in the order of items between the short list on the home page and the news page. This may be intentional, though. On the Git branches side, the name stable/test didn't make its purpose obvious from its name, even if I can understand it if we think about how hard we have fought for months with building binaries; should you routinely merge stable/test into stable/2.20, or is this up to David? I'm asking this mostly for preparing an update in the CG. Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Can GUB-build stable/2.20 [was Re: Still cannot build GUB with stable/2.20 branch]
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 concerned about? If you alternatively use such a branch with the same name for builds of stable and development releases, then it's worth being concerned about deleting that branch after each use; if instead you use different temporary branches for these two kinds of releases, then you only have to care that the temporary branch head is a parent of the head of the base branch you're considering when starting a release process. > An alternative would be simply to treat release/unstable as > temporary? > Delete it after each GUB build and recreate before. I follow > Garaham's old > practice of simply following the instructions on the CG to the > letter, so we > would need to add these steps in. Exactly, this is what I detailed below in my previous email. Before I submit a patch to the CG, I'd like to make you validate these details by practice at least once. > So - to summarise - you're suggesting not building from stable/2.20 > but from > a new (temporary) branch, and therefore updating the new branch > rather than > pushing any changes to release/2.20 before a build? That sounds > very > sensible. This is not a new idea, it's exactly how I suppose you've been doing for releases in the development branch. > > Oh, and I suppose we keep using 2.19 major/minor version on > > stable/2.20 > > branch at the moment. > > Yes - I think my failure to do that broke the links on the website. What kind of breakage do you mean? There was some breakage because of coexistence of 2.19 and 2.21 active branches, which wasn't supported in the website build (issue 5477), but which has been fixed, and which may not be a consequence of your actions for rolling a release. Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Can GUB-build stable/2.20 [was Re: Still cannot build GUB with stable/2.20 branch]
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 testing based system PureOS) and a couple of commands for partial cleaning: rm -rf uploads rm -rf target/*/*/*lilypond* Differently from my previous setup with Ubuntu 16.04, I don't experience any crash on odcctools partial rebuild, but I cannot set LILYPOND_REPO_URL with a local Git repo (i.e. with a "file:" URL) without GUB complaining about unknown VC system, so I use SSH on loopback. > It would also help me > immensely if you could post a set of instructions (like the ones for > development builds in the CG at > http://lilypond.org/doc/v2.19/Documentation/contributor/minor-release-checklist). > > When doing builds from stable, I confuse myself over updating VERSION > and > ensuring I push to the right branch at the right time. A set of easy > to > follow instructions would remove this barrier to updating the online > version > of Lily. I'm not completely happy with the current set of instructions on page "Minor release checklist", even for a release from master branch: merging master into an existing release/unstable branch may import undesired changes from the latter branch. IMHO it would be better to use a _temporary_ branch for release work, i.e. simply branch out from master (not merging anything else), then use it for release work, then merge it into master, and finally delete the "release" branch. This would help building a set of instructions that works almost identically for both stable and master branches. In either case, the general idea of the workflow is 1. branching out from main git branch, either by creating a branch named "release/unstable" — a more generic name like "release/current" would do — or by setting LILYPOND_REPO_URL to a local git clone; 2. doing the updates described in the CG, building, checking, uploading, tagging; 3. merging release branch back to the main branch; 4. only in case you created a new branch in 1: deleting this branch. In practice, assuming BASE_BRANCH is either stable/x.y or master, and you have fully merged previous release work to the relevant staging or stable branch, and you don't use a local branch named "release/current" for other purposes, replace the first set of commands on that CG page "Minor release checklist" with git fetch git push origin :release/current git checkout -B release/current origin/BASE_BRANCH make -C $LILYPOND_BUILD_DIR po-replace mv $LILYPOND_BUILD_DIR/po/lilypond.pot po/ gedit Documentation/web/news-new.itexi Documentation/web/news-old.itexi gedit Documentation/web/news-headlines.itexi gedit VERSION gedit ly/Wel*.ly In step 3 on that page, always in section Pre-release, the "push" command reads instead: git push origin release/current and in step 6, in any case make LILYPOND_BRANCH=release/current lilypond In instructions in section Actual release, use release/current instead of release/unstable: make lilypond-upload \ LILYPOND_REPO_URL=git://git.sv.gnu.org/lilypond.git \ LILYPOND_BRANCH=release/current Instead of the commands stated in Post release, let BASE_BRANCH_STAGING be staging if BASE_BRANCH is master, BASE_BRANCH otherwise, and do git fetch git checkout release/current git merge origin/BASE_BRANCH_STAGING gedit VERSION git commit -m "Release: bump VERSION." VERSION git push origin release/current:BASE_BRANCH_STAGING git push origin :release/current Apart my little knowledge of GUB and the release scripts, what I don't get in all this process is at which stage the git tag is created. Oh, and I suppose we keep using 2.19 major/minor version on stable/2.20 branch at the moment. Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Still cannot build GUB with stable/2.20 branch
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 > http://lilypond.org/doc/v2.19/Documentation/contributor/minor-release-checklist). > > When doing builds from stable, I confuse myself over updating VERSION > and ensuring I push to the right branch at the right time. A set of > easy to follow instructions would remove this barrier to updating the > online version of Lily. Phil, I'm struggling with regtests comparison, because I left generated files with version 2.21.0 in uploads/. I'll hopefully see a success after that cleanup, then will let you know and propose instructions for releasing from stable/2.20 branch. Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Still cannot build GUB with stable/2.20 branch
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 situation. I came back too late to be aware enough to provide a good answer to this, but it seems to me that it's been an accumulation of GUB and build issues and possibly also changes in build environments that made building binaries too fragile. > I cherry-picked those commits now but have no idea what I am actually > doing here. These build system issues have already been reviewed for submission; do you mean we lack policy regarding backporting changes in the build system to stable branch? > Our current distribution of workers and implied or assumed > responsibilities does not seem to be in good shape currently. We > should get this to converge to a better state if we can. Sure. There have been several developers recently involved in GUB and the build system, so now it's time to seize the fruit of this work (as we say in French) to roll releases again, possibly without slowing down too much on GUB work! That said, convergence may take some more time. Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Still cannot build GUB with stable/2.20 branch
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 stable/2.20 branch fails on lilypond-test, because etex is wrongly called. Are there good objections to backporting to stable/2.20 branch the three commits above, to fix this known issue? Now I can build GUB from scratch in only 4 to 5 hours, so I'd like to test GUB changes on the two branches which are going to be used for the next releases. Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: CG - Minor updates to 3.4.9 - Commit access (issue 566540043 by pkxgnugi...@runbox.com)
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):
https://codereview.appspot.com/566540043/diff/566530044/Documentation/contributor/source-code.itexi#newcode2217
Documentation/contributor/source-code.itexi:2217: @warning{Never push
directly to master always push to staging. See
It sounds to me that something is missing between "master" and "always",
at least some punctuation like a comma or a semi-colon.
https://codereview.appspot.com/566540043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCHES - Countdown for March 3rd
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 minutes ago. I'll come back tonight after work and setting up new hardware to update the issue tracker. Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Do not build PDFs from the website Texinfo sources (issue 363930043 by john.mander...@gmail.com)
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 > I uploaded a new patchset using NOT_WEBSITE_TEXINFO_MANUALS: https://codereview.appspot.com/363930043/#ps20001 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB progress?
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 LilyPond after a so long break (issues tracking moved to Sourceforge, website building...). John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Do not build PDFs from the website Texinfo sources (issue 363930043 by john.mander...@gmail.com)
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 > > = $(filter-out > > web,$(TEXINFO_MANUALS)) > > LGTM except this variable name. Could you invent a different one? > > 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 Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Do not build PDFs from the website Texinfo sources (issue 363930043 by john.mander...@gmail.com)
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 "TEXINFO_MANUALS_WITHOUT_WEB"? John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB progress?
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 > > should finally be applied. I think they are uncontroversial – or > is > there any other reason that prevents application? I got no reply from my last comment on #59, so I went for closing it. I merged all others from #53 to #62. I'm not as certain for #61 and #62 as for others, but I observed no regression with them and nobody else commented. There are also old open pull requests left, do you have some clue on them? > Alternatively, please give me (and Knut) write access to the GUB > repository so that we can do it by ourselves. IIUC only Graham can do this. If relying on Phil, me and others with write access to gperciva/gub appears to be an issue, you or Knut or me could fork this repository. > * A new development release should be done `officially' ASAP. Even > if > it doesn't work OK on all platforms yet, it would serve the > majority > of users and developers. Are you available to make a build for release? This would also help validating PRs #61 and #62, if you haven't tested them already. I'm fine with attempting a development release, except that - I need to send a developer with access to lilypond.org the binaries and docs, or be granted access; - it'll delay a little more my work on upgrading Python in GUB to 2.7. Your request raises another issue: would we release 2.21.0, or 2.19.83, or both (building 2.19.83 from stable/2.20 branch being a Release Candidate for 2.20)? Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: C++ cleanup : get rid of some compilation warnings (issue 353880043 by v.villen...@gmail.com)
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: x86_64-linux-gnu
> Configured with: ../src/configure -v --with-pkgversion='Ubuntu 8.2.0-
> 21ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs --
> enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --
> prefix=/usr --with-gcc-major-version-only --program-suffix=-8 --
> program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-
> build-id --libexecdir=/usr/lib --without-included-gettext --enable-
> threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --
> enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-
> time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object
> --disable-vtable-verify --enable-libmpx --enable-plugin --enable-
> default-pie --with-system-zlib --with-target-system-zlib --enable-
> objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686
> --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --
> with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-
> driver --enable-checking=release --build=x86_64-linux-gnu --
> host=x86_64-linux-gnu --target=x86_64-linux-gnu
> Thread model: posix
> gcc version 8.2.0 (Ubuntu 8.2.0-21ubuntu1)
>
> Huh. No idea.
On my build host g++ --verbose says
Using built-in specs.
COLLECT_GCC=/usr/bin/g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap --enable-
languages=c,c++,fortran,objc,obj-c++,ada,go,lto --prefix=/usr --
mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bu
gzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --
enable-checking=release --enable-multilib --with-system-zlib --enable-
__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-gcc-major-version-only --with-linker-
hash-style=gnu --enable-plugin --enable-initfini-array --with-isl --
enable-libmpx --enable-offload-targets=nvptx-none --without-cuda-driver
--enable-gnu-indirect-function --enable-cet --with-tune=generic --with-
arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 8.2.1 20181215 (Red Hat 8.2.1-6) (GCC)
I did "git diff --word-diff --no-index" to compare our configurations;
at first glance I didn't see anything meaningful w.r.t that warning,
which is not surprising given my newbie level in C/C++.
I also attached the output of "gcc -dumpspecs".
Best,
John*asm:
%{m16|m32:--32} %{m16|m32|mx32:;:--64} %{mx32:--x32}
%{msse2avx:%{!mavx:-msse2avx}}
*asm_debug:
%{%:debug-level-gt(0):%{gstabs*:--gstabs}%{!gstabs*:%{g*:--gdwarf2}}}
%{fdebug-prefix-map=*:--debug-prefix-map %*}
*asm_final:
%{gsplit-dwarf:
objcopy --extract-dwo %{c:%{o*:%*}%{!o*:%b%O}}%{!c:%U%O}
%{c:%{o*:%:replace-extension(%{o*:%*} .dwo)}%{!o*:%b.dwo}}%{!c:%b.dwo}
objcopy --strip-dwo %{c:%{o*:%*}%{!o*:%b%O}}%{!c:%U%O} }
*asm_options:
%{-target-help:%:print-asm-header()} %{v} %{w:-W} %{I*}
%{gz|gz=zlib:--compress-debug-sections=zlib}
%{gz=none:--compress-debug-sections=none}
%{gz=zlib-gnu:--compress-debug-sections=zlib-gnu} %a %Y %{c:%W{o*}%{!o*:-o
%w%b%O}}%{!c:-o %d%w%u%O}
*invoke_as:
%{!fwpa*: %{fcompare-debug=*|fdump-final-insns=*:%:compare-debug-dump-opt()}
%{!S:-o %|.s |
as %(asm_options) %m.s %A } }
*cpp:
%{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT}
*cpp_options:
%(cpp_unique_options) %1 %{m*} %{std*} %{W**} %{w}
%{f*} %{g*:%{%:debug-level-gt(0):%{g*}
%{!fno-working-directory:-fworking-directory}}} %{O*} %{undef}
%{save-temps*:-fpch-preprocess}
*cpp_debug_options:
%{d*}
*cpp_unique_options:
%{!Q:-quiet} %{nostdinc*} %{C} %{CC} %{v} %{I**} %{P} %I %{MD:-MD
%{!o:%b.d}%{o*:%.d%*}} %{MMD:-MMD %{!o:%b.d}%{o*:%.d%*}} %{M} %{MM} %{MF*}
%{MG} %{MP} %{MQ*} %{MT*} %{!E:%{!M:%{!MM:%{!MT:%{!MQ:%{MD|MMD:%{o*:-MQ
%*}}} %{remap} %{g3|ggdb3|gstabs3|gxcoff3|gvms3:-dD}
%{!iplugindir*:%{fplugin*:%:find-plugindir()}} %{H} %C %{D***} %{i*} %Z %i
%{E|M|MM:%W{o*}}
*trad_capable_cpp:
cc1 -E %{traditional|traditional-cpp:-traditional-cpp}
*cc1:
%{!mandroid|tno-android-cc:%(cc1_cpu) %{profile:-p};:%(cc1_cpu) %{profile:-p}
%{!mglibc:%{!muclibc:%{!mbionic: -mbionic}}}
%{!fno-pic:%{!fno-PIC:%{!fpic:%{!fPIC: -fPIC}
*cc1_options:
%{pg:%{fomit-frame-pointer:%e-pg and -fomit-frame-pointer are incompatible}}
%{!iplugindir*:%{fplugin*:%:find-plugindir()}} %1 %{!Q:-quiet}
%{!dumpbase:-dumpbase %B} %{d*} %{m*} %{aux-info*}
%{fcompare-debug-second:%:compare-debug-auxbase-opt(%b)}
%{!fcompare-debug-second:%{c|S:%{o*:-auxbase-strip %*}%{!o*:-auxbase
%b}}}%{!c:%{!S:-auxbase %b}} %{g*} %{O*} %{W**} %{w}
%{std*}
Re: Re[2]: Please test gub
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 website Texinfo sources Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list """ I didn't find any web page or hint in that email header for subscribing to this list, so I suppose you'll do it for me, won't you? Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: C++ cleanup : get rid of some compilation warnings (issue 353880043 by v.villen...@gmail.com)
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 > ^~ > page-turn-page-breaking.cc: In instantiation of 'bool is_break(T*) > [with > T = Prob]': > 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] FWIW I get this warning as well (building on Fedora 29 with GCC 8.2.1). Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Please test gub
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 (login john-mandereau) on SourceForge so I can upload a patch using the expected workflow? Thanks, John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Update of texinfo.tex, and cherry-picks in stable/2.20
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 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Update of texinfo.tex, and cherry-picks in stable/2.20
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 request for stable/2.20: 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 Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Please test gub
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 this. > Excellent news! Moderately bad news are that last Thursday the video card of my main computer stopped working, so I spent some time finding a compromise for new hardware and ordering it, and in the meantime figuring out how to ssh into my now headless computer from an Asus eeePC, the latter which has a working display but is of little use for testing GUB LilyPond build. I finally got this temporary setup working tonight. Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Please test gub
Hi Federico, > I've already tested this setup on Debian 9, Ubuntu 16.04, Fedora 29 > (with gcc-7) and reported the errors. Did you manage to get tools::guile to build with Fedora 29 plus GCC 7? On my system with a similar setup (Fedora 29 + GCC 7.4.0 installed locally and configured with 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
Re: Please test gub
> With this setup: > - PRs 53-60 (including update to PR 59 on January 27) applied to GUB, > - Ubuntu 14.05 LTS amd64, ran in a chroot from Fedora 29, > - an Intel Core 2 Duo E8500 at 3.16GHz > > I had a build of LilyPond binaries, tests and docs without error in > about 8 hours, with master branch; I got also the same with > stable/2.20 > branch plus a couple of additional commits: I tested the resulting Mingw binary on a MS Windows 10 Home machine I managed to put the hands on: lilypond-windows.exe (which opens the shipped editor with the welcome text file) hangs, convert-ly.py is OK, lilypond.exe is slow at the start. I might have screwed up something during the build... With another succesful build with that same LilyPond branch (dev/jm- stable-2.20), but GUB master plus PRs 53 to 57, 58 without Python wrapper, and 60 to 62, I got a better working Mingw (which may not be related with the difference in GUB sources): lilypond-windows.exe works normally, convert-ly and lilypond work well, but just like on the other build, the encoding of console messages in French in cmd.exe window is screwed, with UTF-8 accented characters displayed as if they 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
Re: Relocation
> > Maybe I didn't get that you might have designed #6 not for > > relocation of LilyPond itself, but for its dependencies (GS, > > Fontconfig, Guile...). > > Exactly. OK, this point is probably obvious in the larger context of the documentation or by looking at the 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
Re: Please test gub
On February 11, 2019 10:27 +0100, Knut Petersen wrote: > We definitely want a tools::python-2-7, and this does not seem to be > too complicated. On top of gub pull requests 53-60 we could use this > python-2-7.py in gub/specs: Yes, building Python 2.7 for target tools is easy, the hard part of Python upgrade in GUB is cross-compiling it. > For python 2.4.5 we use a lot of patches, most of those do not apply > to 2.7.15. Do we still need the logic provided by those patches in > python 2.7.15? Yes, a large portion of it. > Even if we reach a point that allows us to compile python 2.7.15 for > all target platforms: We need people to test and debug the new > installers. Of course, and the hardest target is Mingw (MS-Windows). > To me it's pretty obvious that we need to provide a working guile 1.8 > together with lilypond. But do we really need to provide python? Yes, unless you ship binary packages without lilypond-book, convert-ly, midi2ly and other Python scripts, or you ask users to configure these before usage. > I tend to believe that the simplest, most resource-saving and most > future-proof solution is to stop shipping python with lilypond > installers and to simply instruct the users how to install python on > the supported platforms. This would make using Python scripts on some targets much harder, especially MS Windows. Generally, shipping almost all dependencies in precompiled binaries lowers the barrier 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
Re: Relocation
Le samedi 09 février 2019 à 20:56 +0100, Werner LEMBERG a écrit : > attached are two images that show my planned documentation of > lilypond's binary relocation. What I'm interested in are comments to > the relocation algorithm. If we can find an agreement, I'm going to > fix lilypond to follow it.[*] Is there a good reason for looking for $INSTALLER_PREFIX subdirectories (#2) before examining whether LILYPOND_DATADIR and LILYPOND_LOCALEDIR are already set in the environment (#4 and #5)? I'd rather do this in the opposite order and put #4 and #5 (as "Use VAR_FOODIR as LilyPond FOO directory) just after #1, and execute #2 only if LILYPOND_DATADIR environment variable is unset. I'm not sure of the semantics of #3: does "relocation is disabled, and a compile-time value for data directory is used" imply exiting after this, skipping all the other items? I'd rather put #3 after #6, with condition "if LilyPond's data directory is still not set", so that possible overrides defined in #6 can be applied. Maybe I didn't get that you might have designed #6 not for relocation of LilyPond itself, but for its dependencies (GS, Fontconfig, Guile...). I also have a minor concern with $INSTALLER_PREFIX/etc/relocate: could we use a less generic path to avoid any clash with other packages in $INSTALLER_PREFIX? Something like $INSTALLER_PREFIX/etc/lilypond- relocate or $INSTALLER_PREFIX/etc/lilypond/relocate. > Right now, lilypond's behaviour 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
Re: Please test gub
Le vendredi 08 février 2019 à 22:19 +0100, Werner LEMBERG a écrit : > > - addition of texinfo/txi-pt.tex from Texinfo sources, as > Portuguese > > translation has been added and I don't have Texinfo installed in > GUB > > host system; > > ??? What exactly needs Portuguese? Lilypond doesn't, AFAICS. In stable/2.20 here's a translation of the website in this language, and a PDF of the website is built and even shipped in the documentation tarball and the website, e.g. look at the end of the file list on http://lilypond.org/doc/v2.19/Documentation/ Is there some practical usage of web*.pdf documents, or shall we prevent their building? BTW I'm surprised to see that the doc compiled for offline usage is uploaded to lilypond.org instead of the doc to be served online with content negotiation; I must have missed something about this during my several years long LilyPond hibernation. > Yeah, it would be nice to know whether this is a Python issue that > can > be corrected by using a newer version, or whether a gub programming > error. I'm almost certain GUB Python code runs under Python installation of the OS, and Ubuntu 14.05 with available updates applied I used for GUB provides 2.7.6. I think it's a programming error, but I doubt this non- clean build issue has a higher priority than other items like Python update in GUB. BTW it was me the guy who proposed to work on this, and I've completed nearly 3/4 of the migration of 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
Re: Please test gub
Hi Knut, hi folks, On Mon 2019-01-28 13:53 +0100, Knut Petersen wrote: > Please report success / fails with os / version / cpu info. With this setup: - PRs 53-60 (including update to PR 59 on January 27) applied to GUB, - Ubuntu 14.05 LTS amd64, ran in a chroot from Fedora 29, - an Intel Core 2 Duo E8500 at 3.16GHz I had a build of LilyPond binaries, tests and docs without error in about 8 hours, with master branch; I got also the same with stable/2.20 branch plus a couple of additional commits: - addition of texinfo/txi-pt.tex from Texinfo sources, as Portuguese translation has been added and I don't have Texinfo installed in GUB host system; - update of texinfo.tex (not necessary, but I did it together with txi- pt.tex addition) - application of Masamichi Hosoda patch for issue 5463; - backport from master of "Add `TEX` environemnt variable for texi2pdf". I pushed the resulting branch to dev/jm-stable-2.20 so you may review this. I succesfully tested Linux-64 bit binary built from LilyPond master branch on my Fedora 29 system, on a medium-sized sample. As for documentation, the text in UTF-8 sample in Snippets is well rendered in LilyPond output, but non-Latin1 text is not rendered in ly code quotation in PDF format (this text is also screwed in last 2.19 release, whereas in 2.18 last release only Latin-1 and Cyrillic text is rendered in ly source). I've had some trouble doing non clean GUB builds, namely a Python KeyError with "odcctools-doc". 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). Best -- John Mandereau ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Please test gub
Hi Harm, Le mardi 29 janvier 2019 à 23:47 +0100, Thomas Morley a écrit : > Doing > $ chromium-browser gub/uploads/webdoc/v2.21.0/index.html > None of the tested links seem to work. > > But for > $ chromium-browser gub/uploads/localdoc/v2.21.0/index.html > all links seem to work. > > No clue whether this is expected behaviour or not ... In order to test contents of gub/uploads/webdoc, you need to serve it with a webserver with content negotiation. This is merely FYI; I don't suggest spending much energy on testing this particular output (webdoc) of GUB; 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
Re: I cannot run make check since Issue 5450: relocate.cc: Introduce new command `set?'
Hi Knut,
On Wednesday 2019/01/23 12:54 +0100, Knut Petersen wrote:
> fatal error: failed files: "65/lily-bab68f98.ly"
>
> So lilypond fails because gs failed to convert 65/lily-bab68f98.ly.
I reproduced the same error with PRs 53-60 merged on Ubuntu 14.04.
[...]
> Summary up to now:
> ===
>
> We build linux-64::lilypond-test, but target/linux-
> 64/root/usr/bin/../bin/gs fails during it's initialization because it
> does not look for shared libraries in target/linux-64/root/usr/lib
> and uses system libraries instead.
I agree with your analysis until this point.
> Look at PATH and LD_* variables passed to lilypond and gs
> =
>
> In both TRACE/TP.26267 an TRACE/TP.26268 we have proper PATH and
> GS_LIBRARY_DIR entries in the environment ...
>
>
> PATH=/home/knut/sources/gub/target/tools/root/usr/bin:/home/knut/sour
> ces/gub/target/linux-64/root/usr/bin:$PATH
> LD_LIBRARY_PATH=/home/knut/sources/gub/target/tools/root/usr/lib:/hom
> e/knut/sources/gub/target/linux-
> 64/root/usr/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}
>
> Interesting.
>
>
> According to that PATH we should have executed
> target/tools/root/usr/bin/gs and not target/linux-
> 64/root/usr/bin/../bin/gs. Well, it seems lilypond does not look for
> a gs in PATH but executes ../bin/gs relative to the directory where
> its own executable is located. I'll have to verify that in the
> sources lates. And obviously LD_LIBRARY_PATH is not obeyed.
> What a mess.
What you quoted is probably not the actual LD_LIBRARY_PATH, but a
portion of compile_command environment variable set by GUB (see a
portion of strace log attached); even if it was, we'd be in serious
trouble, because it would mean shell variable substitution has not been
made, and as far as I understand, there is no shell involved in GS
invocation from LilyPond.
Note that I was misled just like you at first sight (and also at n-th
sight for several n's), until I saw the override of LD_LIBRARY_PATH in
tools::python wrapper you added in pull request #58. Immediately below
is the quote of my comment on gub/specs/python.py(211).
This override of LD_LIBRARY_PATH breaks lilypond-test, as tools:python
is used in lilypond-book call, 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}
instead.
Best
--
John Mandereau
execve("/home/gub/NewGub/gub/target/linux-64/root/usr/bin/../bin/gs", ["gs", "-q", "-dNOSAFER", "-dEPSCrop", "-dCompatibilityLevel=1.4", "-dNOPAUSE", "-dBATCH", "-r1200", "-sDEVICE=pdfwrite", "-dAutoRotatePages=/None", "-dPrinted=false", "-sOutputFile=./65/lily-bab68f98.pdf", "-c.setpdfwrite", "-f./65/lily-bab68f98.eps"], ["tools_root=/home/gub/NewGub/gub/target/tools/root", "compile_command=ulimit -m 1048576 && ulimit -d 1048576 && ulimit -v 3145728 && LILYPOND_EXTERNAL_BINARY=/home/gub/NewGub/gub/target/linux-64/root/usr/bin/lilypond PATH=/home/gub/NewGub/gub/target/tools/root/usr/bin:/home/gub/NewGub/gub/target/linux-64/root/usr/bin:$PATH MALLOC_CHECK_=2 LD_LIBRARY_PATH=/home/gub/NewGub/gub/target/tools/root/usr/lib:/home/gub/NewGub/gub/target/linux-64/root/usr/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH} GS_FONTPATH=/home/gub/NewGub/gub/target/linux-64/root/usr/share/ghostscript/9.21/fonts:/home/gub/NewGub/gub/target/linux-64/root/usr/share/gs/fonts GS_LIB=/home/gub/NewGub/gub/target/linux-64/root/usr/share/ghostscript/9.21/Resource/Init:/home/gub/NewGub/gub/target/linux-64/root/usr/share/ghostscript/9.21/Resource FONTCONFIG_FILE=/home/gub/NewGub/gub/target/linux-64/root/usr/etc/fonts-gub/fonts.conf FONTCONFIG_PATH=/home/gub/NewGub/gub/target/tools/root/usr/etc/fonts-gub make -j4 CPU_COUNT=2 MISSING_OPTIONAL=dblatex test", "LIBRARY_PATH=", "install_flags_destdir_broken= bindir=/home/gub/NewGub/gub/target/linux-64/install/lilypond-test-2.21.0-root/usr/bin aclocaldir=/home/gub/NewGub/gub/target/linux-64/install/lilypond-test-2.21.0-root/usr/share/aclocal datadir=/home/gub/NewGub/gub/target/linux-64/install/lilypond-test-2.21.0-root/usr/share exec_prefix=/home/gub/NewGub/gub/target/linux-64/install/lilypond-test-2.21.0-root/usr gcc_tooldir=/home/gub/NewGub/gub/target/linux-64/install/lilypond-test-2.21.0-root/usr includedir=/home/gub/NewGub/gub/target/linux-64/install/lilypond-test-2.21.0-root/usr/include infodir=/home/gub/NewGub/gub/target/linux-64/install/lilypond-test-2.21.0-root/usr/share/info libdir=/home/gub/NewGub/gub
Re: I cannot run make check since Issue 5450: relocate.cc: Introduce new command `set?'
Hi Knut, On Sun 2019-01-20 11:17 +0100, Knut Petersen wrote: > # Now build stable > > knut@golem:~/sources/gub> time make LILYPOND_BRANCH=stable/2.20 > lilypond > > # Unfortunately that fails with [...] > mkdir /home/knut/sources/gub/uploads/webtest/v2.21.0- > 1/compare-v2.19.81-1/v2.19.81-1 > v2.19.81-1/rest-positioning.ly -> > /home/knut/sources/gub/uploads/webtest/v2.21.0-1/compare-v2.19.81- > 1/v2.19.81-1/rest-positioning.ly > v2.21.0-1/rest-positioning.ly -> > /home/knut/sources/gub/uploads/webtest/v2.21.0-1/compare-v2.19.81- > 1/v2.21.0-1/rest-positioning.ly > invoking gs -sDEVICE=png16m -dGraphicsAlphaBits=4 > -dTextAlphaBits=4 -slilypond-datadir=v2.19.81- > 1/share/lilypond/current -r101 -dAutoRotatePages=/None > -sOutputFile=/home/knut/sources/gub/uploads/webtest/v2.21.0- > 1/compare-v2.19.81-1/v2.19.81-1/rest-positioning.png -dNOSAFER > -dEPSCrop -q > -dNOPAUSE v2.19.81-1/rest-positioning.eps -c quit [...] >File "/home/knut/sources/gub/target/linux-64/src/lilypond- > git.sv.gnu.org--lilypond.git-stable-2.20/scripts/build/output- > distance.py", line 1349, in ? This looks strange: why some paths are named 2.21.0 while you are supposed to build branch stable/2.20? I'll give a try at building stable/2.20. > BTW: I think it's time to merge pull requests #53, #54, #55, #56 and > #57. FWIW I had 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 too much a newbie in GUB to take initiative to commit without approval. Best -- John Mandereau ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: gub: I can now completely build lilypond
Le samedi 19 janvier 2019 à 09:19 +0100, Federico Bruni a écrit : > I did not succeed with GUB in Ubuntu 14.04 last November, but that > was > before the patches from Werner and Knut. I might give it a try > again. > If it works, I may create a new container that anybody could use to > run > GUB. If you struggle at it, I can tell more about my detailed setup (packages set etc.). In a longer term perspective, it's desirable to be able to build GUB on more recent distributions, as Werner and Knut have been investigating. > If you and Werner managed to build the installers, why don't you get > in > touch with Phil to make a new release? I'm certainly available to upload binaries and docs built from GUB, but I'm still not available enough to take the responsability to check thoroughly the correctness of the build and do other release work. My hardware and network are also not ideal (it takes around 8 hours for building from scratch, I haven't tried a non fresh build yet, and my connection is the 4G mobile network, so I could upload a full set of GUB build up to twice a week). I hope building with GUB and rolling a release can be done by distinct 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://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: gub: I can now completely build lilypond
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", so please ignore that claim about "older revisions" of PRs. I've started rebuilding with PRs 53, 54, 55, 56, after having deleted directory target/. Best -- John Mandereau ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: patches for python in gub
On 2019-01-16 20:49 +0100, Werner LEMBERG wrote: > OK, thanks for letting us know. Fortunately, the situation seems to > have become better, so perhaps adding support for the most recent > python version is trivial now. Do you mean that there are hints that let you say patches for cross- compiling would be likely accepted upstream? Or do you rather mean some of the changes of theses patches have been already made upstream, as it seemed to me when I started looking into these? So far I haven't got far enough to get a patchset that looks coherent and applies cleanly, when 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
Re: gub: I can now completely build lilypond
Hi Werner, hi folks, Le lundi 07 janvier 2019 à 08:10 +0100, Werner LEMBERG wrote: > using gub pull requests > > https://github.com/gperciva/gub/pull/53 > https://github.com/gperciva/gub/pull/54 > > together with > > https://sourceforge.net/p/testlilyissues/issues/5456/ > > allows me to successfully run gub's `make lilypond' on my machine, > including regression tests and documentation! This means that > a lilypond build is no longer bound to a certain architecture, user, > or top-level directory. As soon as issue #5456 is in git master you > can test this :-) I succeeded in 'make lilypond' with a very conservative setup: Ubuntu 14.04, installed with package updates in a VM but then ran in a chroot jail from my main Fedora distro, GUB installed in /home/gub/NewGub, applied hints documented in Issue 5384. I merged GUB PRs 53 and 54 (with respective revisions c410c4b and d1c9a24, which are older than current ones), and built LilyPond revision 15180ceadcb53113ccfe092a2882dd855c102693 (from master branch). My computer is not that fast and I don't want to let it run without my supervision (I changed the power supply two weeks ago after the original one broke after a decade of good service, and I'm not sure I'll make it to upgrade from my old Core 2 Duo before next year), so I can't test GUB build every day, but I consider providing efforts to upgrade Python in GUB to 2.7. I saw from other messages than there are issues with 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-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Lilypond-auto] Patchy report
Il giorno mar, 13/11/2012 alle 23.32 +, grenoui...@lilynet.net ha scritto: 22:58:02 (UTC) Begin LilyPond compile, previous commit at f0cd2f7e65a3af000a6001298fd820dda85f6d7a 22:58:20 Merged staging, now at: f0cd2f7e65a3af000a6001298fd820dda85f6d7a 22:58:22 Success:sudo -u lilybuild ./autogen.sh --noconfigure 22:59:00 Success:sudo -u lilybuild /home/lilybuild/staging/configure --disable-optimising 22:59:09 Success:sudo -u lilybuild nice make clean 23:16:11 Success:sudo -u lilybuild nice make -j2 CPU_COUNT=2 ANTI_ALIAS_FACTOR=1 23:32:10 *** FAILED BUILD *** sudo -u lilybuild nice make test -j2 CPU_COUNT=2 ANTI_ALIAS_FACTOR=1 Previous good commit: bacfb43c79623bf26bd59187a6d8e7ea1b9557e2 Current broken commit: f0cd2f7e65a3af000a6001298fd820dda85f6d7a 23:32:10 *** FAILED STEP *** merge from staging Failed runner: sudo -u lilybuild nice make test -j2 CPU_COUNT=2 ANTI_ALIAS_FACTOR=1 See the log file log-staging-nice-make-test--j2-CPU_COUNT=2-ANTI_ALIAS_FACTOR=1.txt 23:32:10 Traceback (most recent call last): File /home/jmandereau/lilypond-extra/patches/compile_lilypond_test/__init__.py, line 523, in handle_staging self.build (issue_id=issue_id) File /home/jmandereau/lilypond-extra/patches/compile_lilypond_test/__init__.py, line 323, in build issue_id) File /home/jmandereau/lilypond-extra/patches/compile_lilypond_test/__init__.py, line 266, in runner raise FailedCommand (Failed runner: %s\nSee the log file %s % (command, this_logfilename)) FailedCommand: Failed runner: sudo -u lilybuild nice make test -j2 CPU_COUNT=2 ANTI_ALIAS_FACTOR=1 See the log file log-staging-nice-make-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-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16.1
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 2.17.6 versus 2.16.0. Grenouille is sending daily reports of failed builds. The message is not informative enough. Do you know what's happening? I looked at the log each time and did not understand what happened for several days, until I realized just now that one of the meanings of the signal 24 that killed LilyPond is XCPU (CPU time limit exceeded), so I raised CPU time limit a bit (from 10 minutes to 15). Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Lilypond-auto] Patchy report
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 commit at c7a3623a056891d48b13fe14fd6ee042ac666822 21:58:27 Merged staging, now at: c7a3623a056891d48b13fe14fd6ee042ac666822 21:58:29 Success:sudo -u lilybuild ./autogen.sh --noconfigure 21:59:05 Success:sudo -u lilybuild /home/lilybuild/staging/configure --disable-optimising 21:59:15 Success:sudo -u lilybuild nice make clean 22:16:12 Success:sudo -u lilybuild nice make -j2 CPU_COUNT=2 ANTI_ALIAS_FACTOR=1 22:38:05 Success:sudo -u lilybuild nice make test -j2 CPU_COUNT=2 ANTI_ALIAS_FACTOR=1 00:33:31 *** FAILED BUILD *** sudo -u lilybuild nice make doc -j2 CPU_COUNT=2 ANTI_ALIAS_FACTOR=1 Previous good commit: 6addf21b5bc485d30e63bf2f04d371c10b902cdb Current broken commit: c7a3623a056891d48b13fe14fd6ee042ac666822 00:33:31 *** FAILED STEP *** merge from staging Failed runner: sudo -u lilybuild nice make doc -j2 CPU_COUNT=2 ANTI_ALIAS_FACTOR=1 See the log file log-staging-nice-make-doc--j2-CPU_COUNT=2-ANTI_ALIAS_FACTOR=1.txt 00:33:31 Traceback (most recent call last): File /home/jmandereau/lilypond-extra/patches/compile_lilypond_test/__init__.py, line 523, in handle_staging self.build (issue_id=issue_id) File /home/jmandereau/lilypond-extra/patches/compile_lilypond_test/__init__.py, line 328, in build issue_id) File /home/jmandereau/lilypond-extra/patches/compile_lilypond_test/__init__.py, line 266, in runner raise FailedCommand (Failed runner: %s\nSee the log file %s % (command, this_logfilename)) FailedCommand: Failed runner: sudo -u lilybuild nice make doc -j2 CPU_COUNT=2 ANTI_ALIAS_FACTOR=1 See the log file log-staging-nice-make-doc--j2-CPU_COUNT=2-ANTI_ALIAS_FACTOR=1.txt $ tail /opt/buildroot-sid/home/lilybuild/lilypond-log/log-staging-nice-make-doc--j2-CPU_COUNT\=2-ANTI_ALIAS_FACTOR\=1.txt Please see /home/lilybuild/build-staging/out/lybook-db/snippet-names--155810202.log make[3]: *** [out-www/essay.texi] Error 1 make[3]: Leaving directory `/home/lilybuild/build-staging/Documentation/de' make[2]: *** [WWW-1] Error 2 make[2]: Leaving directory `/home/lilybuild/build-staging/Documentation' make[1]: *** [WWW-1] Error 2 make[1]: Leaving directory `/home/lilybuild/build-staging' make: *** [doc-stage-1] Error 2 jmandereau@srv-lilypond:~$ tail -n50 /opt/buildroot-sid/home/lilybuild/build-staging/out/lybook-db/snippet-names--155810202.log Forking into jobs: (28679 28678) logfile lilypond-multi-run-1.log (exit 1): Processing `/home/lilybuild/build-staging/out/lybook-db/e2/lily-19b5eb79.ly' Parsing... Interpreting music.../home/lilybuild/build-staging/out/share/lilypond/current/scm/music-functions.scm:1599:18: In expression (ly:context-property context (quote keySignature)): /home/lilybuild/build-staging/out/share/lilypond/current/scm/music-functions.scm:1599:18: Unbound variable: ly:context-property logfile lilypond-multi-run-0.log (exit 1): Processing `/home/lilybuild/build-staging/out/lybook-db/6a/lily-e9632604.ly' Parsing... Interpreting music.../home/lilybuild/build-staging/out/share/lilypond/current/scm/music-functions.scm:1599:18: In expression (ly:context-property context (quote keySignature)): /home/lilybuild/build-staging/out/share/lilypond/current/scm/music-functions.scm:1599:18: Unbound variable: ly:context-property fatal error: 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
Re: [Lilypond-auto] Patchy report
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 commit at c7a3623a056891d48b13fe14fd6ee042ac666822 21:58:27 Merged staging, now at: c7a3623a056891d48b13fe14fd6ee042ac666822 21:58:29 Success:sudo -u lilybuild ./autogen.sh --noconfigure 21:59:05 Success:sudo -u lilybuild /home/lilybuild/staging/configure --disable-optimising 21:59:15 Success:sudo -u lilybuild nice make clean 22:16:12 Success:sudo -u lilybuild nice make -j2 CPU_COUNT=2 ANTI_ALIAS_FACTOR=1 22:38:05 Success:sudo -u lilybuild nice make test -j2 CPU_COUNT=2 ANTI_ALIAS_FACTOR=1 00:33:31 *** FAILED BUILD *** sudo -u lilybuild nice make doc -j2 CPU_COUNT=2 ANTI_ALIAS_FACTOR=1 Previous good commit: 6addf21b5bc485d30e63bf2f04d371c10b902cdb That's several weeks ago. Indeed, this is crazy, because you can see on lilypond-auto list that Patchy successfully built the same Git committish c7a3623a056891d48b13fe14fd6ee042ac666822 one day ago. indicates that it has not changed at all in the (considerable) time span involved. Either your build system, your version of Patchy, or your hardware is broken. This could be well a hardware problem (again). The system administrator of the MSHPN may propose a replacement computer this month or in November. John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patchy email from PhilH
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 Success:../configure --disable-optimising Success:nice make clean -j9 CPU_COUNT=9 -s Success:nice make -j9 CPU_COUNT=9 -s Success:nice make test -j9 CPU_COUNT=9 -s *** FAILED BUILD *** nice make doc -j9 CPU_COUNT=9 -s Previous good commit: 4ed5d7710416aff0a9e68f0d751b4e15c30fdf92 Current broken commit: c9d806f28ab690c3f210e14153c6bd31d506588e This email looks like you're using an old revision of Patchy; in case it doesn't include convenience/safety checks before pushing to master (introduced in commit 054d8101e7bcd54bc8db40092b617bb8b2220b84), please update. Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Outdated help2man; avoiding needing to build help2man.pl
Il giorno gio, 13/09/2012 alle 14.51 -0700, Don Armstrong ha scritto: In stepmake/stepmake/help2man-rules.make, I ran across the following: [snip] While it's correct, you can trivially work around this problem by changing #!@PERL@ -w to #!@PERL@ -w #! perl -w in scripts/build/help2man.pl, and then calling it with perl -x help2man.pl instead of just perl help2man.pl. Thanks for the hint, but with our makefiles scripts/build/out/help2man is called as an executable and has @PERL@ substituted with the perl binary found by configure script, so we actually don't care. The comments you quoted may be some leftover from the time help2man.pl was invoked with perl, foo.py invoked with python, etc. We prefer to build all the scripts so they use the binaries provided by configure run. Also, the version of help2man.pl distributed is quite seriously outdated, and doesn't properly escape - in its output. [The Debian package will be patched to call a more recent version of help2man; it'd probably also be nice to have real manpages for these programs too, but it's at least a start.] Indeed, we have not updated it for a decade, I've entered a report with a patch 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/lilypond-devel
Re: GOP2-5 - GLISS discussions
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, if any, will go to lilypond-devel. Anybody with a serious proposal must be familiar with the Extending manual, must write up a formal proposal, will be subjected to multiple rounds of questioning, etc. I think it’s also time to consider splitting the language in a manner similar to TeX and LaTeX. Namely, the current language could remain (almost?) unchanged, while an additional layer (ly2? lz? ly++ ?) could provide an easier way to write music, which would then be translated into ly for normal compiling. This could resolve a great deal of friction between people who want more “syntactic sugar” and those who want less sugar (or at least, no more than current). Why splitting the language instead of just extending it? Could that additional layer (ly2/ly++/lyz/whatever) be just a set of .ly/.scm files that get loaded on top of the main ones, like we have now with makam.ly or gregorian.ly, or if it's not feasible replace default init.ly with an alternative init file? I mean, having a so different pre-processed language that it would require a new parser and a new lexer would make maintenance and error reporting of music languages (the ly++ preprocessed one, ly and scheme) harder, for a possibly limited gain, whereas the ongoing work of David on the parser brings more power to the user without the cost of an extra language. ** Motivation Before stabilizing the syntax, I think we should have a discussion about possible changes. Many people would like to talk about the ly language (regardless of whether that involves the parser, lexer, naming of functions and keywords and pitches, etc). Whether “possible changes” means a “1% chance” or a “0.1% chance” is irrelevant at present. The goal is to share ideas. If you don’t like fluff discussions that will probably go nowhere, don’t read those emails. I don’t know how to make this more clear. We want to have free discussions, with no expectations of anything being implemented. If this doesn’t seem appealing to you, there is no need to panic. Some people enjoy singing in choirs; other people enjoy playing in rock bands; other people listen to electronica. There is no need to complain about other people’s leisure activities just because you don’t enjoy those activities. I'm busy again in life as usual and my time for LilyPond dropped again, but I want to get something done anyway (maintaining Patchy, put some effort in GUB, routinely fix little bits of the build system...); so, even if I'm in a quite different situation from David, I can euphemistically say too I've been distracted by syntax discussions. I may not understand more than the average reader of this list technically developed replies from David to recent language changes proposals, but I found it irritating that discussion went on ignoring his replies. If I had the authority for this, I would recommend to define the problems well and try to understand the parser a bit better to avoid long fluffy threads and have instead productive discussion (i.e. each proposal end up with some patch or dies after a few messages); however, the passion that the ly language raises makes it somewhat unlikely, so if fluff about language can't be avoided I vote for a separate list, having the bad feeling that, seconding opinions already exrepssed by others on this list, a significant amount of time and energy may be wasted on that quacks list, that may be better spent learning about lily internals, the parser or whatever else. What I just wrote might sound condescending, but I have no particular knowledge on LilyPond parser myself, it partly explains why I haven't take part in recent discussions about syntax and language, and it is motivated by spending energies in the project in an efficient way. ** The ly language There’s some ambiguity in the term syntax (at least, some people might understand that word in different ways. So I’m coining a new term: the ly language. This refers to anything that takes place inside a ly file. the ly language is certainly a better term than syntax in some contexts of discussion (such as the names of the reserved words and predefined functions), especially as no hard line can be drawn between syntax and semantics of the ly language. ** Mailing list I suggest that we discuss possible modifications to the ly language to syntax on a new lilypond-quacks mailing list. These ideas are not formal proposals, and will not be acted upon. In exchange, nobody on that email list will complain about technically infeasible ideas, wasting developer’s time, having to defend the parser, or anything like that. That list will welcome all members – there
Re: Broken time signature glyphs?
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 timesig44-emmentaler16 http://lilypond.1069038.n5.nabble.com/file/n133112/timesig44-emmentaler16.png timesig44-emmentaler20 http://lilypond.1069038.n5.nabble.com/file/n133112/timesig44-emmentaler20.png This is kind of a known issue, encountered on different glyphs on older LilyPond versions: http://code.google.com/p/lilypond/issues/detail?id=1683 This has been fixed by requiring Fontforge 20110222 or newer in LilyPond 2.17.2 (see http://code.google.com/p/lilypond/issues/detail?id=1637 ), so you probably want to upgrade Fontforge above the requirement of LilyPond 2.16.0. David, could we bump Fontforge minimum version to 20110222 for the next 2.16 release as well? Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Broken time signature glyphs?
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 236559061d0c32fcbe39492dcb444e41f2804145 Author: Janek Warchoł janek.lilyp...@gmail.com Date: Mon Aug 27 11:00:24 2012 +0200 Bump Fontforge version requirement (issue 1637) ? John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Broken time signature glyphs?
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 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Git translation branch policy change: merge with and from stable/2.16
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 started this thread stated it clearly: From now on, translation branch at the repository on Savannah should no longer be merged with master and into staging; instead, it should be merged with stable/2.16. but now I have a request. The translation branch is still in 'stable' status. I think it should be kept so for a while, i.e. not to merge master into translation until a new 2.16.x stable is released. I believe this is the path to go because no translation/stable branch has been created, therefore if we want to sync our translations to master, we have no way of knowing what to translate and what not to. Creating a translation/stable branch is easy, but I don't know how translators would be comfortable with switching between two branches for translation work (maybe I wouldn't if I worked on translations myself). After next 2.16.x, we can merge master into translation and go on with translation of development branch. Right? You mean 2.16.1, don't you? The probable frequence of 2.16 releases makes this sound like a good idea. As we have already merged stable/2.16 into staging/master, we can do it again right after 2.16.1, and just after that merge translation with staging and from master. John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Minor release checklist
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 checkout displays modified files, you might want to run git reset --hard before continuing. I'm 99.9% sure I'm correct here, but just to be _really_ sure. This doesn't have to be on the GUB machine, right? It can be any machine with push ability, because GUB will pull the changed files before doing the build. If this is true, OK if I update the CG? If you ask GUB to build a given branch, it will fetch it from Savannah, so you're correct. Best J ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Minor release checklist
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 want to update origin/release/unstable, it's saner to create a local branch that tracks origin/release/unstable, which git checkout release/unstable will do for you if you have a recent enough git (if you don't and don't have a release/unstable branch already, you'll probably get an error anyway). In any case, if you already have a local branch release/unstable, check it out, set it to track origin/release/unstable (IIRC there's some subcommand of git remote for doing this), then pull. Following that with git merge origin and I get fatal: 'origin' is not a commit. I guess this works with some older Git version, but no longer does, or you need to have the remote origin have a HEAD, you may find details about this in man gitrevisions... frankly I have no good clue, I'd just do git merge origin/master instead. I presume the intention of the merge is to get release/unstable to the same point as master? Yes. Strikes me we should not _require_ a release/unstable branch on the machine where the updates are being done. What's the problem with creating a new local branch to track a remote one? Creating branches is cheap, isn't it? Could someone tell me the syntax to merge master into a branch in detached head state? Why do you want to complicate things with a detached head? (I'll update the CG once I've run it through parrot-fashion). Great! Best J ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Grenouille is giving false reg tests
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 have always appeared on Grenouille, so they should be ignored. Of course, regtests comparisons crippled with so much errors not related to the tested patch are quite cumbersome to examine. I really want to give testers like you the ability to upload regtests comparions to Grenouille, but as I'm moving to Italy and I was in a hurry for other tasks I've had no time for LilyPond in the past ten days except reading the long threads about syntax and working on adding debugging hooks to GUB. I hope to have some time for hacking Patchy on Sunday. Cheers, John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Trying to work out at what point patchy fails during make test
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 snippet-map-892580628.ly 84/lily-0f7c4871.ly aa/lily-4858d0b7.ly 0f/lily-cdc1d94e.ly 8b/lily-ee7f7e54.ly 53/lily-64dfb2d0.ly b2/lily-1922a761.ly de/lily-4483657e.ly 3c/lily-14a6ed53.ly ae/lily-838f2675.ly ... [lots more lines like this] b0/lily-7821c23e.ly 68/lily-12d29b6a.ly dc/lily-5d81e32b.ly 8a/lily-3250e012.ly At the end of such a file I sometimes see something like Error: failed files: () which is not very informative. Next time I reproduce it, I'll try to see where this information is generated, so we really get the input filename(s) of the failed file(s). Now I can find all of those *.ly files but which one can I assume is the problematic one of this list? The first one or the second one or could it be any in between. That is does the list get appended to before each test? You can grep for '(?!programming )error:' (Python syntax) the 'xx/lily-.log' files for the .ly files in the list in the snippet-names-y.ly reported by lilypond-book, but this might give false positives in case not all errors cause a non-zero exit status (I doubt any non-programming error causes a zero exit status, but I wouldn't put my hand to cut on this as we say in French). This used to be a bit easier IIRC to find the offending file, but that may be me out of Patchy practice. Patchy could help by grepping the logs and output tails or excerpts of these. This is not the most urgent Patchy improvement to be done, but I had already thought of it so it is on my TODO. Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: gerrit - does it allow writing commits using a web interface?
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 interface that allows to create new commits using only a web browser? I've looked into this, and I think Gerrit doesn't have this feature, which would belong more to something like a wiki than to a code review tool. The reason i'm so concerned about this is simple: it would enable hordes of LilyPond users (;-)) to participate in Lily development. The following situation happened to me several times: a user had a problem, i've explained how to fix it (or simply sent a link to appropriate section in manuals), and i asked how could we improve the manuals so that you had found this information easier/understood it better?. Unfortunately, the responses are usually too vague to be turned to a patch on the spot, and i don't have time to think about them myself (and it doesn't make sense to ask the user to install Lilydev and learn how to make a patch just for this). With a web interface, this would become massively simpler. Also, Graham's catchphrase patches appreciated would become much more powerful :) This might be useful for documentation work, including translations, for a workflow such as the past GDP (Grand Documentation Project): editors using such tools would still be mentored by Git- and Texinfo-savvy people, but mentors would play with Git branches and possibly Gerrit issues instead of exchanging individual files by hand. That said, I have found no existing program for doing this, so this would require quite a bit of work (which I estimate as the overall amount of work that has been put in Patchy) for writing a program for managing changes done by a web code editor such as CodeMirror http://codemirror.net with Git branches, including a feature to submit work on Gerrit. As for LilyPond code, I second David's reply: the quality that submitted patches should have requires a level of technical skills and motivation such that installing LilyDev or generally setting up a development environment for LilyPond should not be a significant barrier. Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Grenouille is giving false reg tests
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 pointless at the moment. As I won't know if this is a real problem or not. I don't know about well-informed thoughts on this issue of undead objects; you hit it too from time to time, but IIRC when you rerun the tests you have enough luck to not hit it again, or in some cases it really seems these errors are not related to the tested patch. I'd suggest turning it off for now and I'll continue to test patches manually. Agreed, done. Cheers, John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Removes echoed information from make doc (issue 6496074)
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
Re: Patchy report
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 - master 201be86..e593c62 translation - translation 21:58:59 Merged staging, now at:e15e0d22810063b79da891bbf472ecc39d09c02c 21:59:01Success:sudo -u lilybuild ./autogen.sh --noconfigure 21:59:37Success:sudo -u lilybuild /home/lilybuild/staging/configure --disable-optimising 21:59:47Success:sudo -u lilybuild nice make clean 22:00:30 *** FAILED BUILD *** sudo -u lilybuild nice make -j2 CPU_COUNT=2 ANTI_ALIAS_FACTOR=1 Previous good commit: 66a7c3e925cbc1a34eaad04f80d4bc42ad9834ac Current broken commit: e15e0d22810063b79da891bbf472ecc39d09c02c 22:00:30 *** FAILED STEP *** merge from staging Failed runner: sudo -u lilybuild nice make -j2 CPU_COUNT=2 ANTI_ALIAS_FACTOR=1 See the log file log-staging-nice-make--j2-CPU_COUNT=2-ANTI_ALIAS_FACTOR=1.txt 22:00:31 Traceback (most recent call last): File /home/jmandereau/lilypond-extra/patches/compile_lilypond_test/__init_ This is a GCC segfault with GCC 4.4.7-2 (Debian unstable). On the contrary, the crash of make doc this morning on translation branch comes from an error in the Czech doc Texinfo source. Grenouille currently seems to be wrong too often to be useful. Do you have a way of checking the integrity of its RAM? I contacted the administrator for checking this, if I need to be physically present there we won't be able to check this before Monday. John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Grenouille broken leg [was Re: Patchy report]
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, previous commit at e6073c719af153e80ba9f31ed96040a3782a180a 13:58:11 Another instance (PID 29635) is already running. 14:28:18 Another instance (PID 29635) is already running. 14:58:26 Another instance (PID 29635) is already running. 15:29:06 Merged staging, now at: e6073c719af153e80ba9f31ed96040a3782a180a 15:29:09 Success: sudo -u lilybuild ./autogen.sh --noconfigure 15:29:49 Success: sudo -u lilybuild /home/lilybuild/staging/configure --disable-optimising 15:29:59 Success: sudo -u lilybuild nice make clean 15:45:29 Success: sudo -u lilybuild nice make -j2 CPU_COUNT=2 ANTI_ALIAS_FACTOR=1 16:07:21 Success: sudo -u lilybuild nice make test -j2 CPU_COUNT=2 ANTI_ALIAS_FACTOR=1 16:39:54 *** FAILED BUILD *** sudo -u lilybuild nice make doc -j2 CPU_COUNT=2 ANTI_ALIAS_FACTOR=1 Previous good commit: 30f457de4178d3e049336aaf50afe17b3b3a1135 Current broken commit: e6073c719af153e80ba9f31ed96040a3782a180a Don't know what the problem was, but I ran test-patchy-staging to find out, and all was well. As of now, master==staging. When I read that message, the log had already been overwritten by next Patchy run, but from the timestamps it might well be a crash of LilyPond in doc build caused by some hardware memory inconsistency: this month Grenouille have encountered at least two GCC segfaults, one or two segfaults, some weird typechecking error, an almost uncountable number of parsed objects should be dead warnings... I'll see with Mike and the MSH admin what we can do, I hope we can find a solution without buying much or any hardware (making Grenouille run with only one of the two 1 GB RAM devices, getting in donation a second-hand but well-running computer suitable as a server possibly putting just a new hard disk on it...), as I think LilyPond users and developers would preferably spend money in funding development by humans. Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Lilypond-auto] Issue 2790 in lilypond: Patch: bar-line interface part 2/2
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 available at http://grenouille.lilynet.net/patches-tests/2790/test-results 02:56:55 (UTC) Begin LilyPond compile, previous commit at ecf25f33aa4c02efda0694280e956c147f5006ae 02:57:02 Another instance (PID 16669) is already running. 03:27:19 Merged master, now at: ecf25f33aa4c02efda0694280e956c147f5006ae 03:27:21 Success:sudo -u lilybuild ./autogen.sh --noconfigure 03:27:47 Success:sudo -u lilybuild /home/lilybuild/master/configure --disable-optimising 03:27:57 Success:sudo -u lilybuild nice make clean 03:43:41 Success:sudo -u lilybuild nice make -j2 CPU_COUNT=2 ANTI_ALIAS_FACTOR=1 04:05:21 Success:sudo -u lilybuild nice make test-baseline -j2 CPU_COUNT=2 ANTI_ALIAS_FACTOR=1 04:05:30 Issue 2790: Patch: bar-line interface part 2/2 04:05:30 Issue 2790: Testing patch issue6498052_8001_diff 04:05:31 Success:sudo -u lilybuild git apply --index /home/jmandereau/lily-test-patches/issue6498052_8001.diff 04:05:33 Success:sudo -u lilybuild ./autogen.sh --noconfigure 04:05:59 Success:sudo -u lilybuild /home/lilybuild/master/configure --disable-optimising 04:06:05 Success:sudo -u lilybuild nice make clean 04:21:50 Success:sudo -u lilybuild nice make -j2 CPU_COUNT=2 ANTI_ALIAS_FACTOR=1 04:46:06 Success:sudo -u lilybuild nice make check -j2 CPU_COUNT=2 ANTI_ALIAS_FACTOR=1 I don't understand why grenouille finds a lot of differences for volta brackets, whereas my test results show only some minor changes in bar-lines.ly and bar-line-segno.ly (apart from output-distance.ly, of course). I retested your patch (not the one you submitted yesterday afternoon, but the one before), and found a lot of differences as well, which by the way are very similar to the test results of last patch by James and these by Grenouille. If really you saw (or see again) only minor changes in only two tests whereas test results from James or Grenouille show a lot, could you double-check that you baselined with the correct revision of the sources? Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: automated computing tasks for lilypond
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 gmail account. You need to write gmail account name (full email address) on first line, and the password on second line, in a file ~/.lilypond-project-hosting-login, then do chmod 700 ~/.lilypond-project-hosting-login We have two of config files. lilypond-patchy-config and .msmtp-patchy (used by patchy staging). I sent you a sample config file, if the instructions work for you too I'll add them to the CG. Is the manual running of Patchy/staging twice a day the frequency you aim at in production phase too? not especially, I could run it every hour if you wanted? It takes about 20 minutes to do a full merge. It's glad IMO running every two hours is frequent enough, running every hour wouldn't bring much more and so would not be worth stressing the hardware more. Of course, the build is done only when new commits appear in staging, so in fact you'd have to see whether setting it to run every hour would not make it run much more frequently in practice. I used to run it every 6 hours, but because I didn't have any email notifications to watch it from work, I was a bit hesitant to do so. This is understandable. More than having email notifications of every single run, I can recommend you to set build_user in compiling section to have a bit more security, which is not really needed to lilypond-patchy-staging, but is good to have for patches tests, see instructions in the commit message of 6e5acb57aa83bd9287afe3cbfa9b67a56cf405be: https://github.com/gperciva/lilypond-extra/commit/6e5acb57aa83bd9287afe3cbfa9b67a56cf405be The last paragraph is a bit unclear (lilybuild should read builduser BTW): even on a non-server setup, you must add gituser to the group of builduser, which is easily done by appending gituser to the group definition of builduser in /etc/group, and you must make sure that the parent directory BUILD_PARENT of build_dir configuration setting has rwx permissions for both gituser and builduser, which may be achieved with chown builduser:builduser BUILD_PARENT chmod 775 BUILD_PARENT Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fw: [Lilypond-auto] Issue 2547 in lilypond: Fix documentation of making footnotes work via tweak.
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 definitely looks bad?
This is not only overkill, this is of course utterly maoingly broken and
not intended, I was simply pointing out this behaviour, without
approving it. I'll see ASAP how to check the date of last patch.
We could, but I think there's a difference between people who work
slow/infrequently vs. abandoned patches. I mean, Mike's skyline
patch and Ian's guile 2.0 work have probably both seen periods of
not being changed for 2 months, but both are still being worked
on.
I don't think that we should automatically declare patches to be
abandoned.
A different story goes for large changes like Mike's skyline patch and
Ian's guile 2.0 work and for smaller contributions, or contributions;
for the former, I agree that the issues should not be set to
Patch-abandoned.
In that case, I would expect the patch author (who should be much
more familiar with his work than any automated script) to manually
set it to Patch-new. Failing that, any other developer could set
patch-new to trigger a new test if the discussion suggests that
the previous test results are not correct.
It's not the problem of triggering a new test, it's the problem of
making test results available to all eyes, regardless of any human
judgement. As James uploads tests results increasingly often, and tests
run more reliably on his computer than on Grenouille, I consider giving
SFTP access on Grenouille to Patchy regular testers so they can upload
tests results, and add a hook in Patchy to do this seamlessly.
Sure, but again I think that we can/should rely on humans manually
saying let's get a new set of test results for this.
Again, the problem is not getting a new set of test results, but getting
one set of test results that is available online. What about creating a
new label category like Patchtest={todo,pass,fail}, where todo would
be set either when uploading a new patch or requesting a new tests run,
pass and fail would be set only if a regtest-comparison is put
online (and Grenouille would not set fail until we have fixed the
cause of its repeated crashes), which could be set with little or no
human intervention? This would require no change in current Patch-*
labels semantics, which Patchy would have less to interpret.
Best,
John
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fw: [Lilypond-auto] Issue 2547 in lilypond: Fix documentation of making footnotes work via tweak.
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 such. People like James can build new test results quite quickly, have them automatically uploaded to Grenouille, and Grenouille can then server them to reviewers. That bypasses the dyndns questions, while still allowing faster (and distributed!) generation of test results. I'm a bit afraid of the extra bandwidth this will use, but we probably have no other solution for the next days (or more... as long as Grenouille has these too frequent crashes), and it's up to me to make Patchy not bloat up too much all tests results with so many log files :-p I still think that this can be handled by the existing Patch-new system. Just allow Grenouille to accept uploads, and forbid Patchy test-patches from changing the status to Patch-review unless it has successfully uploaded to Grenouille. It could work. Given my other ongoing tasks, I think it'll take between three days and a week to get this new workflow running. Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patchy report
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 between patches tests, so with the build speed of Grenouille this issue may well have make this issue apparent in some case. Perhaps you are taking wrong shortcuts, I have taken care in trying to deal with this, but there might be a bug. Patchy is supposed to verify whether the test-baseline is up to date by computing the SHA1 sum of the git committish of current master (test-patches.py pulls just after having downloaded patches) plus the contents of all files in out-test-baseline directories. Perhaps the file names should be added in this checksum? or are mixing up in-place and out-of-place builds All builds in Patchy are done from a bare git repository, nobody builds LilyPond manually in the chroot where Patchy runs, and now Patchy does completely out-of-source builds. or storing your test-baseline in a different place you read it from again? out-test-baselines are never moved away and back by Patchy, so if you don't simulteneously change the build directory in the configuration file and move that build directory manually accordingly, that doesn't happen. Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reduces langdefs.py warnings in doc build (issue 6487046)
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 correctly. I've run a full make/make doc/make test with this change and would like to push directly to staging - given that it was John's suggestion, he knows what he's talking about, and it works and it's a further step in reducing the cruft from make doc. Any objections? Go ahead. Thanks, John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fw: [Lilypond-auto] Issue 2547 in lilypond: Fix documentation of making footnotes work via tweak.
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 the logs that sometimes get included in reg test files might be significant. I can change Patchy so that it compresses the show-XXX tree in a xz file, send it to Grenouille via SFTP, then Grenouille unpacks it and makes it available on its web site; you'd get a warning or you'd have to confirm explicitly uploads larger than a fixed thresold. If it sounds good to you, I'll go add this feature to Patchy, so that as little manual intervention as necessary will be needed. John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: automated computing tasks for lilypond
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 it could be useful for you then I'll add it to the CG. You could also send me your msmtp config file, privately and without the username and password, with hints on what your SMTP server expects (authentication method, TLS/SSL option...) I'll run patchy manually when I get up in the morning (about 7 hours from now-ish) and then will run it manually when I get back from work tomorrow evening and hopefully have more time to work out the kinks with this email business. Is the manual running of Patchy/staging twice a day the frequency you aim at in production phase too? Ideally it should run at least four times a day in the presence of new commits in staging, but even if you run it just twice a day this frees up to 7 hours of CPU time on Grenouille, which helps a lot; in such a setup, I've reenabled Patchy/staging on Grenouille to run at noonish and midnightish, which is good for updating the docs online, and in a near future providing the test baseline for subsequent patches test in case the build of staging results in a merge into master. Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fw: [Lilypond-auto] Issue 2547 in lilypond: Fix documentation of making footnotes work via tweak.
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 this?), and the recent comments should have been accompanied by a status change to Started. John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fw: [Lilypond-auto] Issue 2547 in lilypond: Fix documentation of making footnotes work via tweak.
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=2q=Patch=needs_worksort=-modifiedcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified With the query Patchy currently uses in a server setup Patch=new,review,needs_work,countdown status:New,Accepted,Started modified-after:today-30 every new comment on those issues with old patches will trigger a test. IMHO all issues that have not changed since 2 months and have Patch-needs_work should be labeled Patch-abandoned, could we add a script for this? That said, I think that Patchy should check the date of each patch and not test any patch older than 30 days (based on Rietveld data or the date of the comment with the link to Rietveld in the issue tracker), with possibly an option to bypass this check. That said, I don't think that Grenouille should be testing Patch-needs_work. I do, because from time to time false negatives happen, i.e. Patch-needs_work might be set unproperly, so IMHO some test comparison should be put online anyway so that other people can double-check more easily; the numerous false negatives and tons of parsed objects should be dead warnings probably caused unreliable memory from Grenouille don't always help with this, but in some cases they may do. Only Patch-new really needs testing, with the possible addition of some new item like Patch-needs_help. I intially added Patch-countdown to test more patches that anyway had not seen regtests comparison put online before, and could remove it now, but I'd like to keep looking for Patch-review, to bring the plus of putting regtests comparison online. Best J ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: automated computing tasks for lilypond
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 system to track which patches have been tested locally is going to test a lot of issues, it announced that it is going to test 21 issues (!). I should find a way to allow human intervention during a test session to remove some patches from the queue, enable the docs build for others, etc... Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: automated computing tasks for lilypond
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 Patchy select the targets to build according to which files the patch touches (the documentation would need to be built quite often then, as for example every change in a .scm or .cc file would trigger a recompilation of the docs, OTOH make test would not run for changes in documentation-only files, IIRC like the ones in Documentation/). Ideally changes in makefiles would even trigger a test of other targets (dist, install install-doc, ...). John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: automated computing tasks for lilypond
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 reduces black bars and even David's lexer/parser change and I did capture a couple of 'passes tests but fails make doc' problems. So by the time they get in to staging the creases were ironed out. I fully agree that running the doc build has been worthwhile for some patches, and will likely continue to be so. also does a normal 'make' always capture fat-finger texinfo typos? It catches all mine, but I cannot be sure it would in every case. Indeed, no; some errors in Texinfo input are ignored or handled gracefully by makeinfo/texi2html (in particular they ignore any TeX code), whereas TeX may barf on them. Best J ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB patch
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 get removed before committing this.
John, is this correct?
If you don't include the touch all manual pages in your commit, GUB
build of tools::texinfo shall fail for every system, whether help2man is
available system-wide or not, as in this case Texinfo build does not
look for binaries in /usr/bin, at least not help2man.
If you find touching files like in this patch too ugly, a proper
solution is to add a GUB spec file for help2man (with a dependency on
Perl IIRC, which IIRC is already built in tools GUB target) and add its
dependency in Texinfo spec file.
Best,
John
From faa7fadcdea789287e4a8e7ef0b7eccfbf29a790 Mon Sep 17 00:00:00 2001
From: administrator administrator@administrator-OptiPlex-760.(none)
Date: Tue, 28 Aug 2012 18:18:30 +0200
Subject: [PATCH] Work around a bashism/optimism breaking dash in texi2dvi
shellscript
---
gub/specs/texinfo.py | 10 ++
patches/texinfo-texi2dvi-4.13a.patch | 20
2 files changed, 30 insertions(+)
create mode 100644 patches/texinfo-texi2dvi-4.13a.patch
diff --git a/gub/specs/texinfo.py b/gub/specs/texinfo.py
index 746d8a3..e8e33f0 100644
--- a/gub/specs/texinfo.py
+++ b/gub/specs/texinfo.py
@@ -2,7 +2,17 @@ from gub import tools
class Texinfo__tools (tools.AutoBuild):
source = 'http://ftp.gnu.org/pub/gnu/texinfo/texinfo-4.13a.tar.gz'
+patches = [
+'texinfo-texi2dvi-4.13a.patch',
+]
def patch (self):
tools.AutoBuild.patch (self)
# Drop ncurses dependency
self.file_sub ([(' info ',' ')], '%(srcdir)s/Makefile.in')
+def autoupdate (self):
+# We don't want to rebuild Texinfo man pages
+#
+tools.AutoBuild.autoupdate (self)
+self.system ('''
+cd %(srcdir)s touch doc/*.1
+''')
diff --git a/patches/texinfo-texi2dvi-4.13a.patch b/patches/texinfo-texi2dvi-4.13a.patch
new file mode 100644
index 000..37cff3e
--- /dev/null
+++ b/patches/texinfo-texi2dvi-4.13a.patch
@@ -0,0 +1,20 @@
+diff --git a/util/texi2dvi b/util/texi2dvi
+index 18b2214..7e5855a 100644
+--- a/util/texi2dvi
b/util/texi2dvi
+@@ -129,12 +129,13 @@
+ }
+ test_local
+ test $foo = bar
+-) || local () {
++) || eval '
++local () {
+ case $1 in
+ *=*) eval $1;;
+ esac
+ }
+-
++'
+
+ # cd_orig
+ # ---
--
1.7.9.5
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Stub for ly to xml export using engravers
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 a starting point from current Lily code. BTW writing an exporter (be it to xml or other) would be a good excuse for starting documenting this in Extending manual. John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: successful GUB build on my LilyDev (2.6)
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 waltrop branch is no longer useful. Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: successful GUB build on my LilyDev (2.6)
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 instead, with the hope that the 64bit host kernel causes no trouble with GUB build. That said, you might want to try building GUB directly on your 64bit system with the latest and greatest GUB on master, which includes some recent fixes, and report any build problems you encounter. John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: dblatex and Error: cannot import name TexModule
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 list... Build the listings... XSLT stylesheets DocBook - LaTeX 2e (0.3.4-1) === Build suffix-lyxml.pdf A possible reason for transformation failure is invalid DocBook (as reported by xmllint) Which program or input does the invalid DocBook come from? Error: cannot import name TexModule make[4]: *** [out-www/suffix-lyxml.pdf] Error 1 make[4]: Leaving directory `/home/fede/lilypond-git/input/regression/lilypond-book' make[3]: *** [WWW-1] Error 2 make[3]: Leaving directory `/home/fede/lilypond-git/input/regression' make[2]: *** [WWW-1] Error 2 make[2]: Leaving directory `/home/fede/lilypond-git/input' make[1]: *** [WWW-1] Error 2 make[1]: Leaving directory `/home/fede/lilypond-git' make: *** [doc-stage-1] Error 2 I have dblatex-0.3-4.fc17 installed on my regular laptop, and 0.3.4-1 (same version as yours) on Grenouille with Debian unstable, and I didn't ever hit such build error. On Grenouille with Debian unstable, dblatex 0.3.4-1 package explicitly requires Python 2.6 or 2.7, are you sure there isn't a mismatch on your system with Python, or a compatibility issue some other xml-related dependency of dblatex? Best J ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Add support for Cyrillic in Texinfo/TeX (issue 6492045)
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 support for Cyrillic in Texinfo/TeX This is a follow-up of Rietveld Issue 6459081. Please review this at http://codereview.appspot.com/6492045/ Affected files: M Documentation/common-macros.itexi A Documentation/cyrillic.itexi M configure.in ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: After many changes to Patchy - problems on testing (for me anyway)
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 changes in Patchy behaviour, but one of the ones you just reported was necessary, see below. 1. Usually when I run ./test-patchy.py it grinds through all the new patches and creates a 'show-regtest' file that I can then view. Since the latest change, this file is not created Whether with latest Patchy git revision on master or with the previous one you were using until yesterday, I got these show-regtests-.sh created under ~/lilypond-auto-compile-results/ If the new Patchy no longer creates such scripts, could you check in the logs in ~/lilypond-auto-compile-results/ whether Patchy crashed at a stage before getting to create this script? 2. I also noticed that while I usually have a $LILYPOND_GIT/Build dir on my system - I and I think Patchy have always built 'out of tree' - I now not only had a ../build/.. but a ../build-build/.. dir Yes, now Patchy builds not only out of the source tree, but also outside of the root of the source tree. This is what allowed to make Patchy pass for me on issue 2719, whereas on previous Patchy setup with a build directory as a subdirectory it would fail. So what you saw is an expected feature. 3. Because of #1 and #2 above I did a ctrl-C on patchy to kill the rest of the tests - there is no point in just doing a 'make' if I cannot check 'make test' - You could, even without the generated shell script it should create some show- directory, but now under the same directory than the one that contains build/and build-build/ (BTW you might want to consider to have lily-autobuild instead of build in the configuration file, to avoid name confusion between build/ and build-build/). and after than I couldn't restart patchy as it said another instance was still in use. I realise that ctrl-C is not a nice way to go, but usually in the past I could just re-run it and it would seem to tidy-up after itself or before itself (depending on your point of view) now I cannot run ./test-patchy.py. I did try to find a 'lock' type file but was unsuccessful. To remove the locks, you should remove the line setting lock_pid in ~/.lilypond-patchy-cache and do cd $LILYPOND_GIT git branch -D test-master-lock What I am doing for now (because it is simpler for me) is to roll back to a previous snapshot of my LilyDev image I use, as I cannot remember where git was before I did a git pull on ../patchy/patches/. git reflog can tell you this. However older Patchy versions break on patches like the one in issue 2719. I'll try to get the patch tests out before I go to work today, and I can answer any questions you might have during the day but won't be able to test anything until I get back tonight. If you can't run the newest Patchy because of bugs or configuration issues or new puzzling undocumented behaviour, let's just sort them all out, I'm available all the day long for this until tomorrow 17:00 CET. Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB on the python-db problem
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 /usr/include/*db*3,4*/db.h, which is entirely broken: it should ask GCC if it can find db.h (and/or look at the include flags); we are cross compiling and it entirely ignores that option. This holds for all of the extension modules that are checked here. It would be nice if we could add %(system_prefix)s for where it looks for all extensions; on the other hand: trusting GUB's dependencies and patching Setup.dist is OK too. 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 Great, so I'm pushing this patch to Waltrop. BTW without this patch in (just because I didn't push it), Graham succesfully built stable/2.16 again with GUB branch Waltrop on his box at Glasgow used for all recent LilyPond releases, which might give a hint for fast-forwarding GUB master with Waltrop branch. Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Check for Fontforge with enable-double (1637) (issue 6484062)
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 just use grep. I just was not able to remember whether plain grep needs ? or \? in its patterns and was too lazy to look it up. After having run the test in issue 1683 and reread the report and comments of this issue (1637), there is no evidence that we need to check whether Fontforge was built with --enable-double or -longdouble, so let's only bump fontforge version requirement (posted as another Rietveld issue, before having noticed that a patch doing this had already been posted by Graham), so this work on grep invocation hopefully will be useful in another context. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Run fixcc + astyle2.02.1 (issue 6477062)
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 lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB on the python-db problem
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 rebuild with this. If you feel like this change should get pushed, do it or ask it us :-) Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: web: added tunefl to easier editing (issue 6486067)
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's features using a convinient Typo: convinient - convenient http://codereview.appspot.com/6486067/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Brain surgery on the make system
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 file in them. Good idea. As a bonus, some support for creating these .gitignore files could be added in Documentation/GNUmakefile:new-lang target. Cheers, John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reduces langdefs.py warnings in doc build (issue 6487046)
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 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 warnings are harmless outside Documentation/?? http://lilypond.org/~graham/gop/gop_9.html - By default, no other output will be displayed on the console. These warnings are pointless - they always occur and require no fix. They can confuse new contributors. So we should get rid of them. OK, so let's fix them. 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-dir)/Documentation/po out=www messages I tried building po before Docs but there seemed to be a dependency. I'll have another look. I wonder which dependency you missed; in a source tree cleaned with git clean -f -d -x, I successfully did ./autogen.sh make -C Documentation/po out=www messages make link-tree make -C python make -C scripts then (with console output) $ out/bin/lilypond-book --version 2.17.0 [lilydev@freemousse lilypond]$ LYDOC_LOCALEDIR=bla out/bin/lilypond-book --version langdefs.py: warning: lilypond-doc gettext domain not found. 2.17.0 [lilydev@freemousse lilypond]$ LYDOC_LOCALEDIR=Documentation/po/out-www out/bin/lilypond-book --version 2.17.0 python/ and scripts/ are expected to have built before make doc is called, but Documentation/po:(out=www)messages doesn't even need those. It doesn't disable it in all cases. lilypond-book is called many times in a doc build (e.g. for regtests). This only disables it for the build of the manuals. But then why should we keep this warning for the regtests only (I get some in regtests doc build on Grenouille)? Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Stub for ly to xml export using engravers
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 iterators play in this game. So, here's a stub for possibly starting a ly2xml converter with this approach. Best, John ly2xml-engravers.ly Description: Binary data ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patch t o quieten bibtex
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 mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reduces langdefs.py warnings in doc build (issue 6487046)
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 this error: /home/phil/lilypond-git/./Documentation/po/GNUmakefile:28: warning: overriding commands for target `po-update' /home/phil/lilypond-git/stepmake/stepmake/podir-targets.make:14: warning: ignoring old commands for target `po-update' make[1]: warning: jobserver unavailable: using -j1. Add `+' to parent make rule. /home/phil/lilypond-git/./Documentation/po/GNUmakefile:28: warning: overriding commands for target `po-update' /home/phil/lilypond-git/stepmake/stepmake/podir-targets.make:14: warning: ignoring old commands for target `po-update' make[1]: warning: jobserver unavailable: using -j1. Add `+' to parent make rule. You should use $(MAKE) instead of make, then the jobserver unavailable should not appear any more. The overriding warnings are an issue with the design of Documentation/po/GNUmakefile, all the makefiles for gettext stuff need to be refactored, but I postpone this to after the merge of stepmake/stepmake/ and make/ (for which I've already uploaded a patch, but need to add support in Patchy to get and test Gerrit changes, see https://grenouille.lilynet.net/gerrit/#/c/1/ ) Best J ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reduces langdefs.py warnings in doc build (issue 6487046)
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 patch was applied as-is, the regtests would be built without the .mo files already present. Best J ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reduces langdefs.py warnings in doc build (issue 6487046)
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 this is a signe of a design defect; for instance the defect (which comes from my introduction of POs for translations in the first place) is not building LYDOC_LOCALEDIR early enough in the build process; so switching the build order of these two big trees just for having a few .mo files built or hiding a warning about them not being built is not a good motivation IMHO, and might have unwanted effects in the build process (look, it took us two days of fiddling and testing to fix GUB build for releasing 2.17.0 and end up with small fixes in lilypond:3772b2c7d022122eb9c791bd4a32178e76b97014 and gub:15a6a8dee8f5aa8040baf678f4ed00031c4cf6a9). http://codereview.appspot.com/6487046/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Lilypond-auto] Patchy email
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:../configure --disable-optimising 09:24:24Success:nice make clean 09:25:34Success:nice make -j7 CPU_COUNT=7 09:27:51Success:nice make test -j7 CPU_COUNT=7 09:44:13Success:nice make doc -j7 CPU_COUNT=7 09:44:17 *** FAILED STEP *** merge from staging Command '['git', 'log', '-1', 'origin/HEAD..test-staging']' returned non-zero exit status 128 fatal: ambiguous argument 'origin/HEAD..test-staging': unknown revision or path not in the working tree. Use '--' to separate paths from revisions I suppose that your $LILYPOND_GIT git repository has fetch settings that differ from ours, so you got this error, and in addition I guess that master and HEAD should always be equal on Savannah LilyPond git repo. Could please you help me with verifying the first guess by answering the following? 1) What does cd $LILYPOND_GIT git rev-parse origin/HEAD say? 2) What does the [remote origin] section of $LILYPOND_GIT/.git/config contain? 3) What does lilypond-patchy-staging say (complete console output) if you replace line 334 of patches/compile_lilypond_test/__init__.py origin_head = remote_branch_name (HEAD) with origin_head = remote_branch_name (master) ? (In case after the change lilypond-patchy-staging says No new commits, clear the value of last_known_good_build in [staging] section of ~/.lilypond-patchy-config and rerun lilypond-patchy-staging). Thanks, John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Many changes to Patchy
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 the contrary, please complain by replying to this message, or send a report on this list. Among the new features, which you can have a glance at in the git log: * optionally build the docs when testing patches (in the section [compiling], set the option patch_test_build_docs to yes, and if you remember to clean out test results often or have a TB of free space, you can set patch_test_copy_docs to yes too), * limit resources used by the build; for adjusting settings in [self_limits] and [runner_limits] configuration sections, see http://docs.python.org/library/resource.html and man setrlimit, * more configurable email notifications. Hopefully enjoy! Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Check for Fontforge with enable-double (1637) (issue 6484062)
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. grep and egrep/grep -e flag are redundant, why not just have grep -q -e instead? http://codereview.appspot.com/6484062/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB dist-check failure
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 in commannd
outputs ùight also be a cause of this breakage... I'm reworking lines 43
and 54 of GNUmakefile.in to get rid of bashisms and quoting command
outputs, and will submit an issue ASAP after having checked make dist.
John
- Graham
git
--git-dir=/main/src/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/.git
show HEAD | head -100 out/RELEASE-COMMIT
make[5]: Leaving directory
`/main/src/gub/target/linux-x86/build/lilypond-git.sv.gnu.org--lilypond.git-release-unstable'
cd
/main/src/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable
git ls-files
/main/src/gub/target/linux-x86/build/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/.gitfilelist
/bin/sh: Syntax error: word unexpected (expecting then)
make[4]: *** [dist] Error 2
make[4]: Leaving directory
`/main/src/gub/target/linux-x86/build/lilypond-git.sv.gnu.org--lilypond.git-release-unstable'
Traceback (most recent call last):
File test-lily/dist-check.py, line 137, in module
main ()
File test-lily/dist-check.py, line 129, in main
system ('cd %(builddir)s/ make DOCUMENTATION=yes dist' %
locals ())
File test-lily/dist-check.py, line 56, in system
raise Exception ('failed')
Exception: failed
make[3]: *** [unlocked-dist-check] Error 1
make[3]: Leaving directory `/main/src/gub'
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB dist-check failure
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 weeks ago), and it purposely avoided the next release, so it shouldn't qualify at a last-minute change... well, TBH it's kind of last-minute given the current frequency of releases. Here's a tentative fix: http://codereview.appspot.com/6484047 John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make test
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 comparisons: http://lilypond.org/doc/v2.15/Documentation/contributor/verify-regression-tests http://lilypond.org/doc/v2.15/Documentation/contributor/regtest-comparison I think the latter is probably more accurate. I think it would be best to delete one and point to the other? +1 I've also been benchmarking. For example, I know that make CPU_COUNT=9 test is _much_ faster than make test, but the make -j9 test isn't worth doing - most of the time is spent building the single regtest document, which lilypond parallelises much better than make. I have had errors using -jX so am slightly suspicious of that option. I would like to add the best way to parallelise the test process to the CG. Which problems have you had with make -jX test? They should be identified and fixed: they are a probable symptom of missing dependencies in the makefiles, that don't show up often because by chance Make calls commands in a correct order. I've also been looking at how output-distance works. Does anyone now understand what this actually does? From following the code, it looks to me like it doesn't actually compare images - it compares the .signature files, and if there's a difference over the threshold, it creates an image of the original and changed file, and then makes a ghost version of the change to overlay on the original. Does this seem correct. Worth documenting? Dropping a little paragraph is a good idea, but IMHO it's not worth documenting it in details, for which interested people should look directly at the code. Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patchy switches for forcing make doc don't seem to work
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 could do. Why not, but don't do this without adding make doc-clean at the right places, i.e. right after having applied each patch. Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Use directory-local variables to establish some coding styles in Emacs (issue 6460109)
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 that case, nobody will have his Emacs' behavior get silently changed from under him to obey LilyPond coding standards while inside of LilyPond source directories. It may also be feasible to add a lengthy explanation to the CG that on sufficiently new Emacs versions, the coding standards might be obeyed automatically on some points. Writing a treatise of that kind is quite beyond the scope of the original patch. Analyzing the effect of reformatting the whole Scheme directory with Emacs' default Scheme indentation, whether or not using tabs, is also wildly outside of the scope of the patch. I don't see myself in a position to deal with the can of worms opened by this patch in a reasonable manner. Neither am I, and probably it's not a so good idea to force Emacs settings without the knowing it... an explanation in the CG that tells the contributor to generate herself the .dir-locals.el, and adding this file to .gitignore, could be a better way to go. Graham, what do you think? John ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
