Re: Please test gub

[Alexander Kobel]

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.  It's strange that only the
> > compilation of guile is affected by the problem, but I consider this a
> > pure coincidence.  IOW, this should be added to the gub documentation,
> > as a special preparation step for some LLVM/binutils combinations.
>
> I agree.

I have no idea regarding that issue and trust your assessment.

> > > - 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 python2? Does every python 2.x installation really 
> contain a python2 executable?

Not sure, but according to PEP 394, they "should". The PEP dates back to 
2011, so I'd assume that all systems have a corresponding alias by now, 
and only the default `python` is different.

(IIUC, Gentoo follows Arch's example, see the bottom of 
https://wiki.gentoo.org/wiki/Python; do we have any Gentoo users here?)

Of course, Arch obviously disregards the PEP's first recommendation 
(python should point to python2), so it's perfectly fair to consider 
this entirely Arch's / Gentoo's fault. However, one of the good reasons 
Archers state to follow the explicit python2 / python3 spelling (and 
having python3 as default) is that python2 will see it's end of 
maintenance at the end of this year, and they plan to stop distributing 
python2 as a first-class citizen in the core repositories more or less 
immediately (it will still be easily available via community repos 
though). So following all of the PEP, you'd end up with a system that 
has python3, but neither python nor python2. Perhaps that's harsh, but 
it's a reasonable decision given that official support ends.

In the rationale, the PEP says

"As some of the former distributions did not provide a python2 command 
by default, there was previously no way for Python 2 code (or any code 
that invokes the Python 2 interpreter directly rather than via 
sys.executable) to reliably run on all Unix-like systems without 
modification, as the python command would invoke the wrong interpreter 
version on some systems, and the python2 command would fail completely 
on others."

so this might not be *entirely* smooth.
https://mail.python.org/pipermail/python-dev/2011-March/108491.html 
mentions Debian, Slack and BSDs; but AFAIK, all of those follow the PEP 
these days.

> I think we also would need to change some lilypond files ...

FWIW, this is what is done in the Arch packaging process:

  for file in $(find . -name '*.py' -print); do
    sed -i 's_^#!.*/usr/bin/python_#!/usr/bin/python2_' $file
    sed -i 's_^#!.*/usr/bin/env.*python_#!/usr/bin/env python2_' $file
  done

  sed -i 's|GUILE_CFLAGS=.*|GUILE_CFLAGS="`pkg-config --cflags 
guile-1.8`"|' configure
  sed -i 's|GUILE_LDFLAGS=.*|GUILE_LDFLAGS="`pkg-config --libs 
guile-1.8`"|' configure

plus a patch regarding fontsizes; not sure what this is about:

https://git.archlinux.org/svntogit/community.git/tree/trunk/lilyfontsize.patch?h=packages/lilypond


It might be worth testing whether applying this patch upstream breaks 
anything for someone else; but of course, that's from an Arch user's 
perspective...


Cheers,
Alex

smime.p7s
Description: S/MIME Cryptographic Signature