Re: Frescobaldi on MacOS 10.15 with MacPorts
> On 19 Oct 2019, at 19:53, Davide Liessi wrote:
>
> Dear Hans,
>
> Il giorno sab 19 ott 2019 alle ore 19:01 Hans Åberg
> ha scritto:
>> For some reason, MacPorts ‘port install frescobaldi-devel’ failed on MacOS
>> 10.15, and a ticket could not resolve it. So perhaps somebody here might
>> want giving it a try.
>
> I'm the maintainer of the frescobaldi{,-devel} ports and of its
> dependencies py-poppler-qt{4,5}.
> I have already committed a fix for your ticket
> https://trac.macports.org/ticket/59370 two days ago.
> Please update the port definitions, clean the failed port and try
> again to install frescobaldi-devel, i.e. run
>
> sudo port selfupdate
> sudo port clean py37-poppler-qt5
> sudo port install frescobaldi-devel
>
> (Cleaning the port should not be necessary, MacPorts should discard
> the previous build attempt since the port was changed, but cleaning it
> explicitly does no harm.)
It did not help.
> If the original problem persists, please report on the original ticket.
> If you encounter any other problems, please open corresponding tickets.
Instead I experienced further corruption, and decided to reinstall the whole of
MacPorts from scratch. I do not want to try it again.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Frescobaldi on MacOS 10.15 with MacPorts
Dear Hans,
Il giorno sab 19 ott 2019 alle ore 19:01 Hans Åberg
ha scritto:
> For some reason, MacPorts ‘port install frescobaldi-devel’ failed on MacOS
> 10.15, and a ticket could not resolve it. So perhaps somebody here might want
> giving it a try.
I'm the maintainer of the frescobaldi{,-devel} ports and of its
dependencies py-poppler-qt{4,5}.
I have already committed a fix for your ticket
https://trac.macports.org/ticket/59370 two days ago.
Please update the port definitions, clean the failed port and try
again to install frescobaldi-devel, i.e. run
sudo port selfupdate
sudo port clean py37-poppler-qt5
sudo port install frescobaldi-devel
(Cleaning the port should not be necessary, MacPorts should discard
the previous build attempt since the port was changed, but cleaning it
explicitly does no harm.)
If the original problem persists, please report on the original ticket.
If you encounter any other problems, please open corresponding tickets.
Best wishes.
Davide
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: macOS 64-bit
On Sat, Oct 19, 2019 at 11:33 AM Marnen Laibow-Koser wrote: [...] > I may try it there at some point, but right now I’m focusing on GUB > dependencies. I got Perl to build; right now I’m working with GNU file, > which isn’t finding libz1.2.3 in the right place. (Anyone know how to > massage the library flags to get this to work?) > Update: I managed to get all the generic *nix GUB dependencies building on the MacStadium box. Now I'm into the Darwin-specific ones...and of course it *assumes* that it's cross-compiling them, which causes some problems. Before I spend too much time looking aimlessly: does anyone know where in the GUB source code it figures out if it's cross-compiling? I think I may need to change the logic there, and I'm not sure where to find it. I'll find it eventually, of course, but if anyone can point me to the right place, it would make the process go faster. Best, -- Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Frescobaldi on MacOS 10.15 with MacPorts
For some reason, MacPorts ‘port install frescobaldi-devel’ failed on MacOS 10.15, and a ticket could not resolve it. So perhaps somebody here might want giving it a try. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: macOS 64-bit
> On 19 Oct 2019, at 17:30, Jahrme Risner wrote:
>
> On Thu, Oct 17, 2019 at 19:08, Marnen Laibow-Koser wrote:
>
>> Awesome, thanks; I’ll try it when I get a chance. I still want to get an
>> .app bundle built, but it’s good to know that the mdmg approach actually
>> works as advertised. :)
>
> If you would like to see for yourself how the MacPorts build works, I have
> included a script to automate the entire process. I haven’t tested it in the
> last couple weeks (currently I’m away from my Mac), but I’m not aware of
> anything that should have changed.
>
> I would actually be quite interested in how long it takes on the MacStadium
> image. I have also been toying with the idea of trying to get some automated
> builds created using Tavis CI, but haven’t had time what with a new job and
> moving, plus I think as it is now it might not fall into the allotted time
> for free builds.
As port knows how to use full paths, it suffices to use ${install_dir}/port to
selfupdate and mpkg on; then the export PATH seems unnecessary. In addition,
more than one selfupdate may be required. Otherwise, normally the local path
should be ahead of the system paths, making sure to override the typically
older system software.
> Script:
>
> #!/bin/sh
…
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: macOS 64-bit
On Sat, Oct 19, 2019 at 11:30 AM Jahrme Risner wrote: > On Thu, Oct 17, 2019 at 19:08, Marnen Laibow-Koser > wrote: > > Awesome, thanks; I’ll try it when I get a chance. I still want to get an > .app bundle built, but it’s good to know that the mdmg approach actually > works as advertised. :) > > If you would like to see for yourself how the MacPorts build works, I have > included a script to automate the entire process. I haven’t tested it in > the last couple weeks (currently I’m away from my Mac), but I’m not aware > of anything that should have changed. Good to know. Thanks. > > I would actually be quite interested in how long it takes on the > MacStadium image. > I may try it there at some point, but right now I’m focusing on GUB dependencies. I got Perl to build; right now I’m working with GNU file, which isn’t finding libz1.2.3 in the right place. (Anyone know how to massage the library flags to get this to work?) I have also been toying with the idea of trying to get some automated > builds created using Tavis CI, but haven’t had time what with a new job and > moving, plus I think as it is now it might not fall into the allotted time > for free builds. > That was my experience with the Travis instance I set up. It’s attached to the GitHub LilyPond mirror, and you can look at the build history. Best, -- Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org Sent from Gmail Mobile ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: macOS 64-bit
On Thu, Oct 17, 2019 at 19:08, Marnen Laibow-Koser wrote:
> Awesome, thanks; I’ll try it when I get a chance. I still want to get an .app
> bundle built, but it’s good to know that the mdmg approach actually works as
> advertised. :)
If you would like to see for yourself how the MacPorts build works, I have
included a script to automate the entire process. I haven’t tested it in the
last couple weeks (currently I’m away from my Mac), but I’m not aware of
anything that should have changed.
I would actually be quite interested in how long it takes on the MacStadium
image. I have also been toying with the idea of trying to get some automated
builds created using Tavis CI, but haven’t had time what with a new job and
moving, plus I think as it is now it might not fall into the allotted time for
free builds.
Script:
#!/bin/sh
ly_version=2.19.83
mp_version=2.6.1
install_dir=/opt/lilypond/${ly_version}
mp_url=https://distfiles.macports.org/MacPorts/MacPorts-${mp_version}.tar.bz2
##
# Download and install macports. #
##
export PATH=/bin:/sbin:/usr/bin:/usr/sbin
curl -L -s ${mp_url} | tar xf -
cd MacPorts-${mp_version}
./configure --without-startupitems --prefix=${install_dir}
--with-applications-dir=${install_dir}/Applications
make
sudo make install
#
# Build the metapackage (.mkpg) #
#
export PATH=/bin:/sbin:/usr/bin:/usr/sbin:${install_dir}/bin
sudo port -N selfupdate
sudo port -N mpkg lilypond-devel
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
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: Issue 5578: Add a button to flip between old and new regtest images (issue 566920043 by nine.fierce.ball...@gmail.com)
On 2019/10/19 06:08:51, lemzwerg wrote: Very nice, thanks! Thanks for all your reviewing time lately. Wouldn't it be better/more convenient/more compact to write the CSS stuff into the HTML file, too? The style is also used for the "details" files, e.g. http://faithful.be/tmp/test-results/input/regression/out-test/rest-dot-position.details.html So I think it makes more sense to leave it external. Otherwise I can imagine to provide `style.css` in the source tree, to be not generated at all. We could probably say the same for the JavaScript. Viewing things as they are, that's not a bad idea; however, there was a point during this task where I almost introduced differences in the CSS based on the --no-compare-images option. I decided I had more useful tasks to get on with, but I don't want to move the CSS to its own file and learn later that it wasn't well considered. https://codereview.appspot.com/566920043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCHES - Countdown for October 19th
Hello, Here is the current patch countdown list. The next countdown will be on October 21st. A quick synopsis of all patches currently in the review process can be found here: http://philholmes.net/lilypond/allura/ Push: 5574 freetype.cc: Fix compiler warnings. - Werner LEMBERG https://sourceforge.net/p/testlilyissues/issues/5574 http://codereview.appspot.com/573140043 5573 python: replace <> with != - masterodin https://sourceforge.net/p/testlilyissues/issues/5573 http://codereview.appspot.com/561060043 Countdown: 5576 make output-distance less verbose by default - Dan Eble https://sourceforge.net/p/testlilyissues/issues/5576 http://codereview.appspot.com/563120043 5575 Check additional names for guile-config - hahnjo https://sourceforge.net/p/testlilyissues/issues/5575 http://codereview.appspot.com/554890043 5572 Compile modified C++ files automatically before testing - Dan Eble https://sourceforge.net/p/testlilyissues/issues/5572 http://codereview.appspot.com/553080043 Review: No patches on Review at this time. New: 5580 Replace deprecated functions from string module - hahnjo https://sourceforge.net/p/testlilyissues/issues/5580 http://codereview.appspot.com/566920044 5579 fix stem tremolo on rests crash - Malte Meyn https://sourceforge.net/p/testlilyissues/issues/5579 http://codereview.appspot.com/563170043 5578 Add a button to flip between old and new regtest images - Dan Eble https://sourceforge.net/p/testlilyissues/issues/5578 http://codereview.appspot.com/566920043 5577 scripts/build: Remove unused scripts - hahnjo https://sourceforge.net/p/testlilyissues/issues/5577 http://codereview.appspot.com/551100044 *** Regards, James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 5578: Add a button to flip between old and new regtest images (issue 566920043 by nine.fierce.ball...@gmail.com)
Very nice, thanks!
https://codereview.appspot.com/566920043/diff/581180043/scripts/build/output-distance.py
File scripts/build/output-distance.py (right):
https://codereview.appspot.com/566920043/diff/581180043/scripts/build/output-distance.py#newcode1030
scripts/build/output-distance.py:1030: open_write_file (dest_dir +
'/style.css').write('''
Wouldn't it be better/more convenient/more compact to write the CSS
stuff into the HTML file, too? Otherwise I can imagine to provide
`style.css` in the source tree, to be not generated at all.
https://codereview.appspot.com/566920043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
