Re: [PATCH] Replace static bash in grafted glibc.

[Ludovic Courtès]

Ricardo Wurmus  skribis:

> Ricardo Wurmus  writes:
>
>> Hi Ludo,
>>
>>> Ricardo Wurmus  skribis:
>>>
 I’d like to push this to master in a couple of hours, unless there are
 objections.
>>>
>>> Go for it, thanks a lot!
>>
>> Pushed to master with commit c4fb2b9f4.  Thanks for helping me
>> understand this problem!
>
> Commit c4fb2b9f4 (the changes to commencement) seems to have broken
> Guix.  On some derivations we now get “Uncaught Exception:” and nothing
> else.  Reverting that one commit lets the problem disappear.

We’re tracking progress on this one here:

  https://bugs.gnu.org/30820

Grafting may be broken in many cases, so we’ll have to rebuild and merge
‘core-updates’ sooner than we thought.

Ludo’.

Re: PYTHONPATH issue analysis - part 3

[Ludovic Courtès]

Hello,

Ricardo Wurmus  skribis:

> The problem might be that we are using PYTHONPATH at all.  On other
> distributions this is usually not required and thus doesn’t cause any
> problems.

It’s not required because Python modules live at a fixed location, no?

How does pip deal with that?  I suppose it needs to modify the search
path somehow.

> As outlined in my first email in this thread, our use of PYTHONPATH in
> wrappers seems to not have the desired effect in the presence of
> incompatible packages that are *later* in the PYTHONPATH.
>
> We also have problems when PYTHONPATH includes modules for both Python 2
> and 3, which happens automatically when these modules are installed into
> the same Guix profile.  Since merely installing packages for different
> Python versions is not a problem on traditional distros (on my Fedora
> workstation I have site-packages directories for 4 different versions of
> Python) I think we should do better here.

I agree, though I must say that if PYTHONPATH is not up to the task, I’m
not sure what can be done on our side.

Thanks,
Ludo’.

Re: installing python 2 and python 3 in the same profile

[Ludovic Courtès]

Hi,

Konrad Hinsen  skribis:

> On 14/03/2018 12:39, Hartmut Goebel wrote:
>> Am 13.03.2018 um 22:52 schrieb Ludovic Courtès:
>>>2. Use different package names when we know things can be
>>>   parallel-installed: “python2” vs. “python” (I’m talking about the
>>>   package name, not its version string.)  That’s what distros usually
>>>   do, and I think it’s good enough.
>>
>> I'd prefer this.
>
> That sounds like a good basis. But perhaps "python" for Python 2 and
> "python3" for Python 3 would make more sense, since those are the
> names of the executables.

Yes. OTOH we use the “python2-” prefix for 2.x packages and “python-”
for 3.x packages.

At any rate, that’s a change we should do now in ‘core-updates’.

Ricardo?

> This does of course raise the question of how this will evolve in the
> long run, but since so many bad decisions were already taken, I am not
> trying to guess what will happen. For now, the upstream recommendation
> remains to use "python" and "python3" to distinguish the
> executables. But what will happen in 2020? The Python community might
> be tempted to change the naming to mark the end of Python 2 support,
> but that would be at the price of another round of breaking
> everybody's scripts.

Not our business I’d say.  :-)

Ludo’.

Re: installing python 2 and python 3 in the same profile

[Konrad Hinsen]

Ludovic Courtès  writes:

> Yes. OTOH we use the “python2-” prefix for 2.x packages and “python-”
> for 3.x packages.

Indeed. What a mess!

>> This does of course raise the question of how this will evolve in the
>> long run, but since so many bad decisions were already taken, I am not
...

> Not our business I’d say.  :-)

Right now, no. But we might one day have to decide how to respect
upstream recommendations that change over time, if that change has a
potentially undesirable impact on Guix users.

Konrad.

Re: Help needed: Unable to run Guix after installation

[Leo Famulari]

On Tue, Mar 13, 2018 at 01:55:28AM +0530, Aakanksha Jain wrote:
> I have completed the GNU Guix installation using this script
> https://git.savannah.gnu.org/cgit/guix.git/tree/etc/guix-install.sh
> 
> But while trying to run hello package, I get following error(image attached)

The error message is this:

guix package: error: build failed: the group `guixbuild' specificed in
`build-users-group' does not exist

What operating system are you using? I had the same problem on Debian.

> Someone on irc suggested installing nscd package. But its still not working.

How did you install the nscd package?

> What can be the resolve for this?

I think it is another case of . The
workaround is to install and use nscd, or to edit '/etc/nsswitch.conf',
as described here:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30298#17


signature.asc
Description: PGP signature

New branch for users of RHEL 6

[Ricardo Wurmus]

Hi all,

to address problems with running Guix-built software on RHEL 6 due to
the low kernel version it reports, I have forked the “core-updates”
branch containing the glibc patch and pushed it as “rhel6” to the Guix
repository on Savannah.

The build farm at berlin.guixsd.org is currently building that branch
for the x86_64 architecture.  If you are stuck on a RHEL 6 system (or a
derivate such as CentOS 6) and you see the error “FATAL: kernel too old”
when running software, you can run “guix pull --branch=rhel6” to use the
patched version instead.  The “master” branch does not have a sufficient
fix for all instances where the kernel version is a problem, and it will
only gain the fix once the “core-updates” branch is merged.

The “rhel6” branch is still being built and it may take a couple of days
before all packages have successfully been built and berlin can provide
binary substitutes.

Changes to the “master” branch will be merged into the “rhel6” branch
for some time until “core-updates” can be merged into “master”.  At that
time the “rhel6” branch will be deleted and users can switch back to
“master”.

--
Ricardo

Re: PYTHONPATH issue explanation

[Hartmut Goebel]

Hi,

given the ongoing discussion around Python show that my explanation was
not good enough. I'll try to summarize and give more background.

With regard to Python, guix currently has a major issue, which my
proposals are addressing. There are other issues (like naming the
executables, the "wrapper" script", etc.) which are not addressed here.

When installing Python and some Python packages (e.g. python-simplejson)
in guix, the python interpreter will be linked to
GUIX_PROFILE/bin/pythonX.Y and the packages' files are linked into
GUIX_PROFILE/lib/python-X.Y/site-packages/…, which is perfectly okay.

This python interpreter does not find the site-packages in GUIX_PROFILE
since site-packages are search relative to "sys.base_prefix" (which is
the same as "sys.prefix" except in virtual environments).
"sys.base_prefix" is determined based on the executable's path (argv[0])
by resolving all symlinks.

The python interpreter assumes "site-packages" to be relative to "where
python is installed" - called "sys.base_prefix" (which is the same as
"sys.prefix" except in virtual environments). "sys.base_prefix" is
determined based on the executable's path (argv[0]) by resolving all
symlinks. For Guix this means: "sys.base_prefix" will always point to
/gnu/store/…-python-X.Y, not to GUIX_PROFILE. Thus the site-packages
installed into the guix profile will not be found.

This is why we currently (mis-) use PYTHONPATH: To make the
site-packages installed into the guix profile available.

Using PYTHONPATH for this woes since there is only one PYTHONPATH
variable for all versions of python. This is designed by upstream.

Additionally: When using PYTHONPATH the site-packages are added to the
search path ("sys.path") *in front* of the python standard library,
while they are expected to be added *behind*.

Part 3 of my analysis lists three solutions for this, where only number
2 and 3 are "good choices".

no. 2
suggests using a mechanism already implemented in python: Setting
"PYTHONHOME" will make the interpreter to use this as "sys.base_prefix"
unconditionally. Again there is only one PYTHONHOME variable for all
versions of python (designed by upstream). We could work around this
easily (while keeping upstream compatibility) by using
GUIX-PYTHONHOME-X.Y, to be evaluated just after PYTHONHOME.

This would be easy to implement using Guix's "search-path" capabilities
and a small patch to the python interpreter.

The drawback is: This is implemented using an environment variable,
which might not give the expected results in all cases. E.g. running
/gnu/store/…-profile/bin/python will not load the site-packages of that
profile. Also there might be issues implementing virtual environments.
(Thinking about this, I'm quite sure there will. Ouch!)

no.3
suggests changing the way the python interpreter is resolving symlinks
when searching for "sys.base_prefix". The idea is to stop "at the profile".

The hard part of this is to determine "at the profile". Also this needs
a larger patch. But if we manage to implement this, it would be perfect.
I could contribute a draft for this implemented in Python. The
C-implementation needs to be done by some C programmer.

Which way should we go?

-- 
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

omvf firmware

[Efraim Flashner]

I succesfully built ovmf firmware for aarch64 on my aarch64 board.
Currently it builds for x86_64 and i686 on %intel platforms only. I
think it's best to create a make-ovmf-firmware procedure to build the
firmware for x86_64/i686/aarch64/armhf, but there's not a clear
cross-grade path from our current x86_64 & i686 package to x86_64 or
i686.

The two other options I've thought of are adding aarch64 and armhf
support to our current package, which would balloon the native-inputs
with cross compilers, or leave the current package and add 1 or 2 new
pacakges, but then I feel like that's almost back to my original intent
of creating a procedure and 4 packages.

Suggestions? Comments?

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Re: PYTHONPATH issue analysis - part 3

[Hartmut Goebel]

Am 14.03.2018 um 08:49 schrieb Pjotr Prins:
> On Tue, Mar 13, 2018 at 11:02:03PM +0100, Hartmut Goebel wrote:
>> Am 13.03.2018 um 22:44 schrieb Pjotr Prins:
>>> Another problem is that it does not cover special cases where, for
>>> example you compile Python with SSL and without. You don't want them
>>> to share user installed libs.
>> Upstream does not handle this case, so I do not see a need to handle
>> this in guix. If we find a way, this would be find. But prior to solving
>> the optional we should solve the compulsory :-)
>   https://github.com/python/cpython/blob/master/configure#L1543
>
> and there are many other options which define the behaviour of the
> interpreter. We don't use them in GNU Guix, but it does not mean we
> should not think about it/allow it.

Now I understand you point: If there are two variants of e.g Python 3.5
available, but there is only one GUIX-PYTHONHOME-3.5 variable, this will
intermix the environments again.

You are right!

Adding the hash would indeed be a good solution :-)

-- 
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: omvf firmware

[ng0]

Efraim Flashner transcribed 2.0K bytes:
> I succesfully built ovmf firmware for aarch64 on my aarch64 board.
> Currently it builds for x86_64 and i686 on %intel platforms only. I
> think it's best to create a make-ovmf-firmware procedure to build the
> firmware for x86_64/i686/aarch64/armhf, but there's not a clear
> cross-grade path from our current x86_64 & i686 package to x86_64 or
> i686.
> 
> The two other options I've thought of are adding aarch64 and armhf
> support to our current package, which would balloon the native-inputs
> with cross compilers, or leave the current package and add 1 or 2 new
> pacakges, but then I feel like that's almost back to my original intent
> of creating a procedure and 4 packages.
> 
> Suggestions? Comments?

I don't know omvf. Does it involve kernel space modules? I've started
experimenting with a path to a generalized kernel-module support (which
needs the "source" we currently throw away of the kernel, etc).

Or what this firmware like?

> -- 
> Efraim Flashner  אפרים פלשנר
> GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
> Confidentiality cannot be guaranteed on emails sent or received unencrypted



-- 
A88C8ADD129828D7EAC02E52E22F9BBFEE348588
https://n0.is

Re: omvf firmware

[Efraim Flashner]

On Thu, Mar 15, 2018 at 08:29:37PM +, ng0 wrote:
> Efraim Flashner transcribed 2.0K bytes:
> > I succesfully built ovmf firmware for aarch64 on my aarch64 board.
> > Currently it builds for x86_64 and i686 on %intel platforms only. I
> > think it's best to create a make-ovmf-firmware procedure to build the
> > firmware for x86_64/i686/aarch64/armhf, but there's not a clear
> > cross-grade path from our current x86_64 & i686 package to x86_64 or
> > i686.
> > 
> > The two other options I've thought of are adding aarch64 and armhf
> > support to our current package, which would balloon the native-inputs
> > with cross compilers, or leave the current package and add 1 or 2 new
> > pacakges, but then I feel like that's almost back to my original intent
> > of creating a procedure and 4 packages.
> > 
> > Suggestions? Comments?
> 
> I don't know omvf. Does it involve kernel space modules? I've started
> experimenting with a path to a generalized kernel-module support (which
> needs the "source" we currently throw away of the kernel, etc).
> 
> Or what this firmware like?
> 

to quote Debian:
Open Virtual Machine Firmware is a build of EDK II for 64-bit x86 virtual
machines. It includes full support for UEFI, including Secure Boot, allowing
use of UEFI in place of a traditional BIOS in your VM.

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature