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

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

Re: Please test gub

Werner LEMBERG writes: 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/

Re: Please test gub

>>> 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/ >> >> Thanks, but uh, oh – how

Re: Please test gub

> After getting everything downloaded, `time make lilypond` ran for > just under 3h30m. [...] Excellent! > Also, I have been exploring adding 64-bit macOS (Darwin) targets and > I am planning on sharing my findings thus far as soon as I have > finished writing them up. Great news, and thanks

Re: Please test gub

‐‐‐ Original Message ‐‐‐ On Monday, January 28, 2019 4:53 AM, Knut Petersen wrote: > Please report success / fails with os / version / cpu info. Knut, thank you for your coordination of efforts on GUB. After getting everything downloaded, `time make lilypond` ran for just under

Re: Please test gub

Il giorno gio 14 feb 2019 alle 12:33, Federico Bruni ha scritto: Il giorno lun 11 feb 2019 alle 23:42, John Mandereau ha scritto: 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

Re: Please test gub

Werner LEMBERG writes: >>> ??? 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

Re: Please test gub

>> ??? 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

Re: Please test gub

Hi Urs! Urs Liska reported a successful build on Ferdora 29 o January 30th on this list. Have a look at his email. Sorry, no, I built on Linux Mint 19 and Debian 9. Sorry, I put your name in the wrong line of my table. Knut ___ lilypond-devel

Re: Please test gub

Am 12. Februar 2019 00:10:54 MEZ schrieb Knut Petersen : >On 11.02.19 23:42, John Mandereau wrote: >> 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

Re: Please test gub

On 11.02.19 23:42, John Mandereau wrote: 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

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

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

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

Re: Please test gub

Jacques Menu writes: > Hello Knut, > >> Lukas thought of the following options >> >> 1) make musicxml2ly work again (by changing the Python version >> used, or by fixing the problems with 2.4), or >> 2) remove musicxml2ly from the distribution bundle, possibly >> 2a) without replacement,

Re: Please test gub

Hello Knut, > Lukas thought of the following options > > 1) make musicxml2ly work again (by changing the Python version used, or by > fixing the problems with 2.4), or > 2) remove musicxml2ly from the distribution bundle, possibly > 2a) without replacement, > 2b) replaced by xml2ly > >

Re: Please test gub

On 09.02.19 13:57, David Kastrup wrote: Lukas-Fabian Moser writes: For more than 10 years gub/specs/lilypond.py used /usr/bin/python. That means that during lilypond-test the system's python interpreter is used as the interpreter for the musicxml2ly script, not our own python in target/tools. 

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,

Re: Please test gub

On my system, your description matches: Current Master's musicxml2ly python script runs fine using my local python2 (2.7.15rc1) but has the error using 2.19.82's python2.4 (2.4.5). Given that nobody is really working on musicxml2ly, I strongly suggest that people start testing and using

Re: Please test gub

Lukas-Fabian Moser writes: >>> For more than 10 years gub/specs/lilypond.py used >>> /usr/bin/python. That means that during lilypond-test the system's >>> python interpreter is used as the interpreter for the musicxml2ly >>> script, not our own python in target/tools.  At some currently >>>

Re: Please test gub

For more than 10 years gub/specs/lilypond.py used /usr/bin/python. That means that during lilypond-test the system's python interpreter is used as the interpreter for the musicxml2ly script, not our own python in target/tools.  At some currently unknown point in time musicxml2ly became

Re: Please test gub

>> @Werner: Didn't you write something about updating python in gub? Well, someone (I forgot his name) offered to work on updating python to the latest 2.7.x version, which should make it easier to eventually migrate to python 3.x... > I assume you're referring to the situation that (e.g.)

Re: Please test gub

Hi, -- 5e44fec38f33997109bc85c099472b2736649fde is the first bad commit commit 5e44fec38f33997109bc85c099472b2736649fde Author: Frederic Gohier Date:   Thu May 10 11:12:44 2018 +0100     Fix

Re: Please test gub

Hi everybody, For more than 10 years gub/specs/lilypond.py used /usr/bin/python. That means that during lilypond-test the system's python interpreter is used as the interpreter for the musicxml2ly script, not our own python in target/tools.  At some currently unknown point in time

Re: Please test gub

Hi everybody! I think with the attached test-patch on top of the patch I already sent to you 'make lilypond' (not only bin/gub xxx::lilypond) should succeed after you put the newly created wrapper directory in front of PATH. I see; this wrapper directory is more convenient than asking the

Re: Please test gub

> - 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. > - update of texinfo.tex (not necessary, but I did it together with >

Re: Please test gub

On 08.02.19 14:12, Knut Petersen wrote: Hi everybody! Use /usr/bin/env python2? Does every python 2.x installation really contain a python2 executable? OSX 10.12 Sierra has python 2.7 but does not have a python2 executable.  Only python. At least this is the case on my machine.

Re: Please test gub

Hi everybody! Use /usr/bin/env python2? Does every python 2.x installation really contain a python2 executable? OSX 10.12 Sierra has python 2.7 but does not have a python2 executable.  Only python. At least this is the case on my machine. Gosh, didn't expect that. In that case,

Re: Please test gub

On 08.02.19 04:51, Carl Sorensen wrote: On 2/6/19, 3:42 PM, "lilypond-devel on behalf of Knut Petersen" wrote: >> - the need to make sure that `python` calls a python2 interpreter. > No idea how this could be solved elegantly. I guess it can't, so we > have again

Re: Please test gub

On 2/6/19, 3:42 PM, "lilypond-devel on behalf of Knut Petersen" wrote: >> - the need to make sure that `python` calls a python2 interpreter. > No idea how this could be solved elegantly. I guess it can't, so we > have again something to document... > Use /usr/bin/env

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

Re: Please test gub

Hi, On 06.02.19 23:31, Knut Petersen wrote: On 06.02.19 15:09, Werner LEMBERG wrote: That leaves the two problems of - LLVMgold.so in /usr/lib/bfd-plugins shadowing liblto_plugin.so    (I rm'ed LLVMgold.so there for the purpose of the above gub run.) This is definitely *not* a gub issue. 

Re: Please test gub

On 06.02.19 15:09, Werner LEMBERG wrote: That leaves the two problems of - LLVMgold.so in /usr/lib/bfd-plugins shadowing liblto_plugin.so (I rm'ed LLVMgold.so there for the purpose of the above gub run.) This is definitely *not* a gub issue. It's strange that only the compilation of guile

Re: Please test gub

> That leaves the two problems of > > - LLVMgold.so in /usr/lib/bfd-plugins shadowing liblto_plugin.so > (I rm'ed LLVMgold.so there for the purpose of the above gub run.) This is definitely *not* a gub issue. It's strange that only the compilation of guile is affected by the problem, but I

Re: Please test gub

Hi Knut, On 06.02.19 13:17, Knut Petersen wrote: Hi Alexander! Perfectly correct, your expectations are met. I hope that story of success continues ;-) it does. :-) Would you be so kind to test the attached patch? Sure. bin/gub --fresh linux-x86::lilypond linux-64::lilypond

Re: Please test gub

Il giorno mar 5 feb 2019 alle 9:20, Knut Petersen ha scritto: In case you wonder, on Arch both /lib and /lib64 are symlinked to /usr/lib; they also abandoned the distiction between /bin, /sbin, /usr/sbin and /usr/bin, and the former three are symlinked to the latter. Ok, that's an important

Re: Please test gub

Hi Alexander! Perfectly correct, your expectations are met. I hope that story of success continues ;-) Would you be so kind to test the attached patch? Knut >From 9b9751b2961514a80740899e344e502d0aafd756 Mon Sep 17 00:00:00 2001 From: Knut Petersen Date: Wed, 6 Feb 2019 12:55:59 +0100

Re: Please test gub

Hi, On 05.02.19 09:20, Knut Petersen wrote: Hi Alexander! In case you wonder, on Arch both /lib and /lib64 are symlinked to /usr/lib; they also abandoned the distiction between /bin, /sbin, /usr/sbin and /usr/bin, and the former three are symlinked to the latter. Ok, that's an important

Re: Please test gub

Hi Alexander! The file /usr/lib/ld-linux-x86-64.so.2 is used instead of the expected /home/akobel/gub/gub/target/linux-64/root/usr/lib/ld-linux-x86-64.so.2. Could you please execute     ls -l `find -L /lib* /usr /home/akobel/gub | grep ld-linux-x86-64.so.2` and mail me the result? Sure,

Re: Please test gub

On 05.02.19 08:40, Knut Petersen wrote: On 04.02.19 15:29, Alexander Kobel wrote: Remote debugging... Perfectly correct, here you are. Thanks. The file /usr/lib/ld-linux-x86-64.so.2 is used instead of the expected /home/akobel/gub/gub/target/linux-64/root/usr/lib/ld-linux-x86-64.so.2.

Re: Please test gub

On 04.02.19 15:29, Alexander Kobel wrote: Remote debugging... Perfectly correct, here you are. Thanks. The file /usr/lib/ld-linux-x86-64.so.2 is used instead of the expected /home/akobel/gub/gub/target/linux-64/root/usr/lib/ld-linux-x86-64.so.2. Could you please execute ls -l `find -L

Re: Please test gub

Hi Alexander! The argumens given are ok. As usual     mkdir -p STRACE     strace -v -f -ff -s 1 -o STRACE/TP bin/gub --fresh linux-64::guile will help to identify the problem. hm, that gives appx. 2 GB of traces, and I'm not sure which process' trace I should look at. Nothing

Re: Please test gub

Hi, On 02.02.19 10:27, Knut Petersen wrote: On 01.02.19 15:06, Alexander Kobel wrote: On 01.02.19 14:51, Alexander Kobel wrote: GUB-bing further down the road now... Hrmpf, back here sooner than I hoped. Guile barfed - see the attached log. libtool: link: x86_64-linux-gcc -g -O2 -Wall

Re: Please test gub

On 01.02.19 15:06, Alexander Kobel wrote: On 01.02.19 14:51, Alexander Kobel wrote: GUB-bing further down the road now... Hrmpf, back here sooner than I hoped. Guile barfed - see the attached log. libtool: link: x86_64-linux-gcc -g -O2 -Wall -Wmissing-prototypes -o .libs/guile guile-guile.o 

Re: Please test gub

On 01.02.19 14:51, Alexander Kobel wrote: GUB-bing further down the road now... Hrmpf, back here sooner than I hoped. Guile barfed - see the attached log. libtool: link: x86_64-linux-gcc -g -O2 -Wall -Wmissing-prototypes -o .libs/guile guile-guile.o ./.libs/libguile.so

Re: Please test gub

On 01.02.19 14:28, Knut Petersen wrote: I wonder if we really need libopenjpeg ...  Yes, we need jpeg ... but we also link against our own libjpeg, and we talk about tools::poppler. Note: libopenjpeg is (misnomed and) only required for JPEG 2000. Traditional JPEG is taken care of by libjpeg,

Re: Please test gub

On 01.02.19 14:09, Alexander Kobel wrote: is there an libopenjpeg1-devel package installed? If not: try to install and rerun gub ... yes and no - Arch follows the principle that the packages provide both runtimes and development requirements at the same time, so there is no separation as in,

Re: Please test gub

On 01.02.19 14:09, Alexander Kobel wrote: Hi, On 01.02.19 13:51, Knut Petersen wrote: On 31.01.19 16:04, Alexander Kobel wrote: and I can cleanly compile the recent poppler 0.73 with openjpeg2 backend from source, with a simple cmake + make. is there an libopenjpeg1-devel package

Re: Please test gub

Hi, On 01.02.19 13:51, Knut Petersen wrote: On 31.01.19 16:04, Alexander Kobel wrote: and I can cleanly compile the recent poppler 0.73 with openjpeg2 backend from source, with a simple cmake + make. is there an libopenjpeg1-devel package installed? If not: try to install and rerun gub

Re: Please test gub

On 31.01.19 16:04, Alexander Kobel wrote: and I can cleanly compile the recent poppler 0.73 with openjpeg2 backend from source, with a simple cmake + make. is there an libopenjpeg1-devel package installed? If not: try to install and rerun gub ... Knut

Re: Please test gub

On 31.01.19 15:43, Alexander Kobel wrote: Addendum: On 31.01.19 15:39, Alexander Kobel wrote: Whenever I can, I "correct" shebangs to python2 (without ever having looked up this PEP), and nobody ever complained that it breaks their workflow. That is to say: I've yet to encounter a system

Re: Please test gub

On 31.01.19 16:15, Karlin High wrote: On 1/31/2019 9:04 AM, Alexander Kobel wrote: BTW, can we actually add images in Lily? Encapsulated PostScript images are fair game with \epsfile I know I used that once, but I forget

Re: Please test gub

On 1/31/2019 9:04 AM, Alexander Kobel wrote: BTW, can we actually add images in Lily? Encapsulated PostScript images are fair game with \epsfile I know I used that once, but I forget which program I used to make the EPS

Re: Please test gub

Hi, On 31.01.19 13:25, Alexander Kobel wrote: Indeed, LLVMgold.so pops up in the trace. On my system, the symlink for liblto_plugin.so already exists, so I only had to remove (rename wasn't enough) LLVMgold.so. Building tools::guile succeeds after that modification; I'll test the further

Re: Please test gub

Addendum: On 31.01.19 15:39, Alexander Kobel wrote: Whenever I can, I "correct" shebangs to python2 (without ever having looked up this PEP), and nobody ever complained that it breaks their workflow. That is to say: I've yet to encounter a system where python points to python2.x, but at the

Re: Please test gub

Hi, On 31.01.19 15:21, David Kastrup wrote: Knut Petersen writes: On 31.01.19 08:43, Alexander Kobel wrote: Hi, fails on Arch Linux (up-to-date, Intel Core i5-3317U). First, all Python scripts seem to require Python2 (but python -> python3 is the default on Arch). I don't think that

Re: Please test gub

Knut Petersen writes: > On 31.01.19 08:43, Alexander Kobel wrote: >> Hi, >> >> fails on Arch Linux (up-to-date, Intel Core i5-3317U). >> >> First, all Python scripts seem to require Python2 (but python -> >> python3 is the default on Arch). I don't think that matches Python's own

Re: Please test gub

> On my system, the symlink for liblto_plugin.so already exists, so I > only had to remove (rename wasn't enough) LLVMgold.so. > > Building tools::guile succeeds after that modification; [...] OK! BTW, It took me some weeks to identify this very problem... > # pacman -Qo

Re: Please test gub

Hi, strace according to Knut's instructions is attached. On 31.01.19 12:54, Werner LEMBERG wrote: Apart from that minor buzz, `make lilypond` does a good chunk of work, but fails building tools::guile; log attached. I see. libtools segfauls. ../libtool: line 950: 23645 Segmentation

Re: Please test gub

>>../libtool: line 950: 23645 Segmentation fault  (core dumped) >>ar cru .libs/libguile.a [...] > > This is probably the same bug I've encountered on my openSUSE box. > Try to remove the file (or link) `/usr/lib/bfd-plugins/LLVMgold.so' > and replace it with the gcc variant

Re: Please test gub

>> Apart from that minor buzz, `make lilypond` does a good chunk of work, >> but fails building tools::guile; log attached. > > I see. libtools segfauls. >../libtool: line 950: 23645 Segmentation fault  (core dumped) >ar cru .libs/libguile.a [...] This is probably the same bug I've

Re: Please test gub

On 31.01.19 08:43, Alexander Kobel wrote: Hi, fails on Arch Linux (up-to-date, Intel Core i5-3317U). First, all Python scripts seem to require Python2 (but python -> python3 is the default on Arch). I placed a symlink to python -> python2 in a high-priority $PATH as a workaround, but it might

Re: Please test gub

Hi, fails on Arch Linux (up-to-date, Intel Core i5-3317U). First, all Python scripts seem to require Python2 (but python -> python3 is the default on Arch). I placed a symlink to python -> python2 in a high-priority $PATH as a workaround, but it might be a good idea to replace the shebang

Re: Please test gub

Am 30.01.19 um 12:14 schrieb Knut Petersen: Hi everybody! Thanks for testing. Here is a summary of the current status:    openSuSE Tumbleweed: Gub succeeds, but it is necessary to install gcc-7.    openSuSE Leaf 42.3:  Gub succeeds.    Ubuntu 18.04[.1]:    Gub succeeds. But. libc6-dev-i386

Re: Please test gub

Hi everybody! Thanks for testing. Here is a summary of the current status: openSuSE Tumbleweed: Gub succeeds, but it is necessary to install gcc-7. openSuSE Leaf 42.3:  Gub succeeds. Ubuntu 18.04[.1]:    Gub succeeds. But. libc6-dev-i386 must be installed. If

Re: Please test gub

On 30.01.19 10:46, Werner LEMBERG wrote: [...] getting identical checksums *for the doc bundle* is probably only possible if you have a gub installation containing a TeXLive package also. As time stamps are stored e.g. in pdf files we won't get constant checksums unless we do some special

Re: Please test gub

Am 29.01.19 um 14:58 schrieb Knut Petersen: On 29.01.19 14:30, Urs Liska wrote: Looks like 64-bit Ubuntu, like my main machine. With an earlier gub-version I had similiar problem, because of missing 32-bit libraries. I got further after installing: lib32ncurses5 lib32z1 I suspect that

Re: Please test gub

> The resulting installers all have SHA256 checksums different than the > ones from Urs Liska's Nextcloud share. Are you sure that the build refers to exactly the same lilypond git commit as Urs's installers? HEAD is continuously updated... > I don't know what's expected with that. It would

Re: Please test gub

On 1/29/2019 7:43 AM, Karlin High wrote: Off and running again for now Near as I can tell, the build succeeded. System specs given in an earlier post. I forgot to use the "time" command, so I don't know exactly how long it took. Going by logs, I'd say just under 10 hours. Next time, I'll

Re: Please test gub

Am Mi., 30. Jan. 2019 um 01:28 Uhr schrieb John Mandereau : > > 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

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

Re: Please test gub

Am Di., 29. Jan. 2019 um 23:08 Uhr schrieb Thomas Morley : > > Am Mo., 28. Jan. 2019 um 13:53 Uhr schrieb Knut Petersen > : > > > > Hi everybody! > > > > I created a branch in my gub repository that contains > > https://github.com/gperciva plus pull requests 53-60. Therefore it is > > pretty

Re: Please test gub

Am Mo., 28. Jan. 2019 um 13:53 Uhr schrieb Knut Petersen : > > Hi everybody! > > I created a branch in my gub repository that contains > https://github.com/gperciva plus pull requests 53-60. Therefore it is pretty > easy to test if that version of gub succeeds to build current lilypond master

Re: Please test gub

On Tue, Jan 29, 2019 at 8:25 AM Phil Holmes wrote: > > Could someone pint me to what I > need to do in order to get the gub git stash up to date and correct? Lots of things happening with GUB lately. Major discussion threads include: "I cannot run make check since Issue 5450: relocate.cc:

Re: Please test gub

[snip] Please note that I've been out of the country for the last 3 weeks or so and haven't been following all the gub threads. Could someone pint me to what I need to do in order to get the gub git stash up to date and correct? FWIW I did get gub running just before I went away by dint of

Re: Please test gub

On 29.01.19 14:30, Urs Liska wrote: Looks like 64-bit Ubuntu, like my main machine. With an earlier gub-version I had similiar problem, because of missing 32-bit libraries. I got further after installing: lib32ncurses5 lib32z1 I suspect that apt-get install libc6-dev-i386 fixes the

Re: Please test gub

Il giorno mar 29 gen 2019 alle 14:28, Knut Petersen ha scritto: On 29.01.19 11:56, Thomas Morley wrote: Am Di., 29. Jan. 2019 um 00:53 Uhr schrieb Karlin High mailto:karlinh...@gmail.com>>: On 1/28/2019 6:53 AM, Knut Petersen wrote: Please report success / fails with os / version / cpu

Re: Please test gub

Am 29.01.19 um 14:28 schrieb Knut Petersen: On 29.01.19 11:56, Thomas Morley wrote: Am Di., 29. Jan. 2019 um 00:53 Uhr schrieb Karlin High: On 1/28/2019 6:53 AM, Knut Petersen wrote: Please report success / fails with os / version / cpu info. I really like the simple instructions you

Re: Please test gub

On 1/28/2019 11:28 PM, Federico Bruni wrote: More likely a download went wrong and the tar.gz file is not really a tar.gz file. /Gerade da ist das Problem./ It turns out that my gateway antivirus (Untangle, ClamAV I think) doesn't like the odcctools file. The download had returned an HTML

Re: Please test gub

On 29.01.19 11:56, Thomas Morley wrote: Am Di., 29. Jan. 2019 um 00:53 Uhr schrieb Karlin High : On 1/28/2019 6:53 AM, Knut Petersen wrote: Please report success / fails with os / version / cpu info. I really like the simple instructions you posted, Knut. I wouldn't be testing Gub without

Re: Please test gub

Obviously filenames (STRACE/TP) will differ as they indicate the ID of the processes. Please send me those two files and target/darwin-ppc/log/odcctools.log. Which two files, the tar and gzip files in .../usr/bin? No, target/darwin-ppc/log/odcctools.log and the two files STRACE/TP

Re: Please test gub

Am Di., 29. Jan. 2019 um 00:53 Uhr schrieb Karlin High : > > On 1/28/2019 6:53 AM, Knut Petersen wrote: > > Please report success / fails with os / version / cpu info. > > I really like the simple instructions you posted, Knut. I wouldn't be > testing Gub without them. My setup doesn't like the >

Re: Please test gub

Hi Knut, as said I ran the GUB build on my Debian server as well. Am 29.01.19 um 08:11 schrieb Knut Petersen: On 29.01.19 00:53, Karlin High wrote: *** Failed target: darwin-ppc::odcctools gub.make:63: recipe for target 'packages' failed make[1]: *** [packages] Error 1 make[1]: Leaving

Re: Please test gub

Il giorno mar 29 gen 2019 alle 7:41, Urs Liska ha scritto: So what can I do to check whether make lilypond succeeded or failed? Good question. On Ubuntu 16.04... I just found out that I managed to build the packages on 23rd of January, despite the errors I reported last week: $ ls -lh

Re: Please test gub

Hi Knut, Am 29.01.19 um 10:02 schrieb Knut Petersen: Hi Urs! So what can I do to check whether make lilypond succeeded or failed? The last lines of the terminal output will look like: make -f lilypond.make update-versions To upload, run:     make lilypond-upload

Re: Please test gub

Hi Urs! So what can I do to check whether make lilypond succeeded or failed? The last lines of the terminal output will look like: make -f lilypond.make update-versions To upload, run:     make lilypond-upload LILYPOND_BRANCH=master

Re: Please test gub

Am 29.01.19 um 08:32 schrieb Werner LEMBERG: If we get more success reports, the resulting packages should be uploaded so that other people not running gub can test them. Developers can then have a look how to add support for 64bit binaries on MacOS and Windows. Especially the former is

Re: Please test gub

>> If we get more success reports, the resulting packages should be >> uploaded so that other people not running gub can test them. >> Developers can then have a look how to add support for 64bit >> binaries on MacOS and Windows. Especially the former is rather >> urgent... > > I can upload my

Re: Please test gub

Am 29.01.19 um 08:14 schrieb Werner LEMBERG: The overall end doesn't report a failure, but the last "rule" shows some problems, I should have mentioned this was the "nsis rule" If you reach this point you can be rather sure that everything was fine – at least for your build system, since it

Re: Please test gub

>> The overall end doesn't report a failure, but the last "rule" shows >> some problems, > > I should have mentioned this was the "nsis rule" If you reach this point you can be rather sure that everything was fine – at least for your build system, since it was used to run lilypond's tests to

Re: Please test gub

On 29.01.19 00:53, Karlin High wrote: On 1/28/2019 6:53 AM, Knut Petersen wrote: Please report success / fails with os / version / cpu info. I really like the simple instructions you posted, Knut. I wouldn't be testing Gub without them. My setup doesn't like the darwin-ppc::odcctools package

Re: Please test gub

Am 29.01.19 um 07:41 schrieb Urs Liska: The overall end doesn't report a failure, but the last "rule" shows some problems, I should have mentioned this was the "nsis rule" ___ lilypond-devel mailing list lilypond-devel@gnu.org

Re: Please test gub

Hi Knut, thank you for working on this, and - like Karlin - I wouldn't have tested without your straightforward recipe. But before going to bed I logged off, then logged in again in a terminal-only session and started the process. Am 28.01.19 um 13:53 schrieb Knut Petersen: Hi everybody!

Re: Please test gub

Il giorno mar 29 gen 2019 alle 0:53, Karlin High ha scritto: building package: darwin-ppc::odcctools *** Stage: download (odcctools, darwin-ppc) *** Stage: untar (odcctools, darwin-ppc) Command barfed: tar -C /home/karlin/knut-gub/gub/target/darwin-ppc/src/odcctools-278

Re: Please test gub

On 1/28/2019 6:53 AM, Knut Petersen wrote: Please report success / fails with os / version / cpu info. I really like the simple instructions you posted, Knut. I wouldn't be testing Gub without them. My setup doesn't like the darwin-ppc::odcctools package for some reason. Mystified why it's

Re: Please test gub

Hi James! I'd like to help here if I can. Thanks However at home I am on metered internet and it appears that after make lilypond it starts to download files? Can you tell me approximately how large the data that will be downloaded is - speed of download isn't an issue, just the amount.

Re: Please test gub

Hello, On 28/01/2019 12:53, Knut Petersen wrote: Hi everybody! I created a branch in my gub repository  that contains https://github.com/gperciva plus pull requests 53-60. Therefore it is pretty easy to test if that version of gub succeeds to build current lilypond master on your machine.

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. Yes, an additional commit (added yesterday) in pull request #58 should solve the problem with a failing gs Knut ___

Re: Please test gub

Il giorno lun 28 gen 2019 alle 13:53, Knut Petersen ha scritto: Hi everybody! I created a branch in my gub repository that contains plus pull requests 53-60. Therefore it is pretty easy to test if that version of gub succeeds to build current lilypond

  1   2   >