bug#36819: Installer boot problems on UEFI

[lukasbf]

Hello everyone,
I found a bug on the Guix installer.
GuixSD Installer freezes my UEFI-only PC, image was successfully verified over 
gpg.
I have a Trekstor Surfbook A13B running Parabola (so other installers/distros 
work fine)
Installer works on other PCs, so the installer is not corrupt.

I would love to help to get it working.


Lukas ​

bug#36786: Warn of AMD GPUs unusable with Guix System

[pelzflorian (Florian Pelz)]

On Fri, Jul 26, 2019 at 05:56:23PM +0200, Ludovic Courtès wrote:
> "pelzflorian (Florian Pelz)"  skribis:
> > While my patch before addresses AMD-specific tweaks in the manual
> > under Hardware Considerations, it is not enough if on the *download
> > page* Guix is claimed to run on “an i686, x86_64, ARMv7, or AArch64
> > machine“ without saying linux-libre *on some hardware, is not
> > supported* and referencing the Hardware Considerations section and
> > h-node, I think.
> 
> Well, ‘Limitations’ and ‘Hardware Considerations’ are the first sections
> one see when following ‘Installation Instructions’ at
> .  We can always move things one level
> higher, but eventually everything ends up at the top level.  :-)
> 

I would rather see a more prominent link to the manual and h-node
where on the downloads page it says “runs on i686, x86_64, ARM”,
because I suppose many people do not read the manual until they know
they need to, and instead expect things to just work, especially now
that there’s a graphical installer.



> > >From e88ee68c09266e1d09d24ff0d1b6ec6a4708841b Mon Sep 17 00:00:00 2001
> > From: Florian Pelz 
> > Date: Wed, 24 Jul 2019 23:02:21 +0200
> > Subject: [PATCH] doc: Mention AMD Radeon workaround when TTYs are not 
> > redrawn.
> > 
> > * doc/guix.texi (Hardware Considerations): Describe workaround.
> 
> […]
> 
> I think this doesn’t fit well here: the previous paragraphs are about
> RYF, h-node.org, and the more general issue.
> 
> Like Ricardo wrote, since this is not Guix-specific, it would be great
> if we could link to other resources on this topic.  Are you aware of any
> such on-line resource?
> 
> If there’s no such thing, then we should definitely add this
> information, but perhaps we should move the paragraph a bit higher (next
> to Wifi), and possibly turn Wifi into an item of this list.  WDYT?
>

Yes, I agree this is not a good place in the manual.  However, I
thought of it more as a list of hardware-specific *and* Guix-specific
tweaks.  Note that the patch does not mention Xorg not working on some
AMD GPUs (h-node is the place for that, even though currently it does
not yet list many AMD Radeons), instead the patch is about
hardware-specific tweaks that can be made.  For example, a
recommendation of thinkfan for Thinkpads could be placed in such a
section too (once there is a Guix service for thinkfan; I do not know
how important thinkfan is and do not own a Thinkpad, it is just an
example).  The Arch wiki for example has articles on various specific
kinds of hardware.

Regards,
Florian

bug#36777: Guix Inferiors: Curious incorrect derivation output bug

[Carl Dong]

Hi all,

I did some more digging, and have included a git-bisect log, the -info-dir.drv,
and -info-dir-builder here:

https://gist.github.com/dongcarl/0a305badf20c9b5cfae738147ca416af

Please let me know if I can provide more information.

Cheers,
Carl Dong
cont...@carldong.me
"I fight for the users"

‐‐‐ Original Message ‐‐‐
On Friday, July 26, 2019 7:50 AM, Ludovic Courtès  wrote:

> Hello Carl,
>
> Carl Dong cont...@carldong.me skribis:
>
> > I have my manifest.scm here:
> > https://github.com/dongcarl/bitcoin/blob/2019-06-guix-channels-and-inferiors/contrib/guix/manifest.scm,
> > and it references the aforementioned Guix channel.
>
> This one appears to work for me (I interrupted it before it was done
> compiling all the toolchains, though.)
>
> > What I expect to happen is that now when I change my default profile's Guix
> > version by 'guix pull'ing, it won't affect the environment that's generated 
> > by
> > the manifest.scm. I've tested this with differing versions of Guix as my 
> > default
> > profile, and this seems to work with 
> > 7304d5623ab5cc35289cb1535cbd0d8a37691fac
> > and 7f1c69f5d32bee6b8b6b902a9ce445e04aa9d07d being my default profile. 
> > However,
> > I tried an older version b6dc08393e6a8313b88ce422fc3c1e4e9c0efc6f, and got 
> > the
> > following error:
>
> When I put b6dc08393e6a8313b88ce422fc3c1e4e9c0efc6f in .guix-channel and
> use that as my channel, it also works fine (well, I commented out the
> toolchains as well.)
>
> > guix environment: error: derivation 
> > `/gnu/store/r641vpqc9rfjhljf7rzfzwmkmpa642ls-info-dir.drv' has incorrect 
> > output `/gnu/store/q9hkdidycz3wq28xxgjq47bzx5s39k52-info-dir', should be 
> > `/gnu/store/z5hh2nl0h58b9f6hdxfwm00gjyxfcc3n-info-dir'
> >
>
> That definitely looks like a bug.
>
> Could you send the faulty info-dir.drv file?
>
> Thanks,
> Ludo’.

bug#36817: Guix Download Fails When SSL_CERT_DIR is a Colon-Separated Path

[Katherine Cox-Buday]

I was receiving X.509 certificate errors when attempting to run `guix
download`. After investigating, I found that it was because my
`SSL_CERT_DIR` environmental variable had two paths separated by a
colon. The two paths were actually the same. After removing the second
path, `guix download` began working again.

Wondering how the duplicate paths came to be, I discovered that
`${GUIX_PROFILE}/etc/profile` had two exports defined for
`SSL_CERT_DIR`. I discovered this was because I had both openssl and
libressl installed (if memory serves, I needed openssl for some
development task that relied on an idiosyncrasy of openssl). Removing
openssl removed the duplicate entry.

I think there may be two bugs:

1. `guix download` needs to respect colon-separated paths.
2. The profile mechanics in Guix should probably have some way to check
   if they're redefining the same thing before placing things in `etc/profile`.

Thank you to everyone for all of your hard work, and for Guix.

-- 
Katherine

bug#36816: gcc-toolchain 9.1.0 can't link even a tiny simple C program

[Danny Milosavljevic]

Hmm,

$ guix environment --ad-hoc gcc-toolchain

makes it work in there.

Maybe I forgot to actually reboot?  brb...


pgpzq41JHNgos.pgp
Description: Digitale Signatur von OpenPGP

bug#36813: 'lower-gexp' does not respect 'system' or 'target' keywords

[Jakob L. Kreuze]

Apologies, I should clarify -- the Guile for the S-Expression appears to be 
fine, but the Guile referenced in the shebang of the ungexp'd program-file does 
not reflect the system.

On July 26, 2019 11:37:20 AM EDT, "Jakob L. Kreuze" 
 wrote:
>Could you please try to reproduce using the example I provided? The
>derivation itself is handled appropriately, but its references are not.
>
>On July 26, 2019 11:28:11 AM EDT, "Ludovic Courtès" 
>wrote:
>>zerodaysford...@sdf.lonestar.org (Jakob L. Kreuze) skribis:
>>
>>> Changing it to the following:
>>>
>>> #+BEGIN_SRC scheme
>>> (lower-gexp exp
>>> #:system "i686-linux"
>>> #:target "i686-unknown-linux-gnu"
>>> #:guile-for-build #f)
>>> #+END_SRC
>>>
>>> The Guile used is still a 64-bit LSB executable.
>>
>>I can’t reproduce it on current ‘master’:
>>
>>--8<---cut here---start->8---
>>scheme@(guile-user)> ,run-in-store (lower-gexp #~(+ 2 3)
>>#:guile-for-build #f #:system "mips64el-linux")
>>$6 = #< sexp: (+ 2 3) inputs: () sources: () guile:
>>#< drv: #>/gnu/store/jsnihqsz6nxwv88pr41i2y3403f959cf-guile-2.2.4.drv =>
>>/gnu/store/n2570pg8cahc8k9iqrg5qngyzf6j0xzr-guile-2.2.4-debug
>>/gnu/store/j9a8dx25cj045yl5l32ajkkjf92ib3y1-guile-2.2.4 46e3230>
>>sub-derivations: ("out")> load-path: () load-compiled-path: ()>
>>scheme@(guile-user)> (derivation-system (derivation-input-derivation
>>(lowered-gexp-guile $6)))
>>$7 = "mips64el-linux"
>>--8<---cut here---end--->8---
>>
>>Not even when cross-compiling (BTW, #:target probably doesn’t make
>>sense
>>above, since it’s cross-compiling from i686 to i686):
>>
>>--8<---cut here---start->8---
>>scheme@(guile-user)> ,run-in-store (lower-gexp #~(+ 2 3)
>>#:guile-for-build #f #:system "mips64el-linux" #:target "i586-pc-gnu")
>>$8 = #< sexp: (+ 2 3) inputs: () sources: () guile:
>>#< drv: #>/gnu/store/jsnihqsz6nxwv88pr41i2y3403f959cf-guile-2.2.4.drv =>
>>/gnu/store/n2570pg8cahc8k9iqrg5qngyzf6j0xzr-guile-2.2.4-debug
>>/gnu/store/j9a8dx25cj045yl5l32ajkkjf92ib3y1-guile-2.2.4 46e3230>
>>sub-derivations: ("out")> load-path: () load-compiled-path: ()>
>>scheme@(guile-user)> (derivation-system (derivation-input-derivation
>>(lowered-gexp-guile $8)))
>>$9 = "mips64el-linux"
>>--8<---cut here---end--->8---
>>
>>Am I missing something?
>>
>>Thanks,
>>Ludo’.
>
>-- 
>Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

bug#36813: 'lower-gexp' does not respect 'system' or 'target' keywords

[Jakob L. Kreuze]

Could you please try to reproduce using the example I provided? The derivation 
itself is handled appropriately, but its references are not.

On July 26, 2019 11:28:11 AM EDT, "Ludovic Courtès"  wrote:
>zerodaysford...@sdf.lonestar.org (Jakob L. Kreuze) skribis:
>
>> Changing it to the following:
>>
>> #+BEGIN_SRC scheme
>> (lower-gexp exp
>> #:system "i686-linux"
>> #:target "i686-unknown-linux-gnu"
>> #:guile-for-build #f)
>> #+END_SRC
>>
>> The Guile used is still a 64-bit LSB executable.
>
>I can’t reproduce it on current ‘master’:
>
>--8<---cut here---start->8---
>scheme@(guile-user)> ,run-in-store (lower-gexp #~(+ 2 3)
>#:guile-for-build #f #:system "mips64el-linux")
>$6 = #< sexp: (+ 2 3) inputs: () sources: () guile:
>#< drv: #/gnu/store/jsnihqsz6nxwv88pr41i2y3403f959cf-guile-2.2.4.drv =>
>/gnu/store/n2570pg8cahc8k9iqrg5qngyzf6j0xzr-guile-2.2.4-debug
>/gnu/store/j9a8dx25cj045yl5l32ajkkjf92ib3y1-guile-2.2.4 46e3230>
>sub-derivations: ("out")> load-path: () load-compiled-path: ()>
>scheme@(guile-user)> (derivation-system (derivation-input-derivation
>(lowered-gexp-guile $6)))
>$7 = "mips64el-linux"
>--8<---cut here---end--->8---
>
>Not even when cross-compiling (BTW, #:target probably doesn’t make
>sense
>above, since it’s cross-compiling from i686 to i686):
>
>--8<---cut here---start->8---
>scheme@(guile-user)> ,run-in-store (lower-gexp #~(+ 2 3)
>#:guile-for-build #f #:system "mips64el-linux" #:target "i586-pc-gnu")
>$8 = #< sexp: (+ 2 3) inputs: () sources: () guile:
>#< drv: #/gnu/store/jsnihqsz6nxwv88pr41i2y3403f959cf-guile-2.2.4.drv =>
>/gnu/store/n2570pg8cahc8k9iqrg5qngyzf6j0xzr-guile-2.2.4-debug
>/gnu/store/j9a8dx25cj045yl5l32ajkkjf92ib3y1-guile-2.2.4 46e3230>
>sub-derivations: ("out")> load-path: () load-compiled-path: ()>
>scheme@(guile-user)> (derivation-system (derivation-input-derivation
>(lowered-gexp-guile $8)))
>$9 = "mips64el-linux"
>--8<---cut here---end--->8---
>
>Am I missing something?
>
>Thanks,
>Ludo’.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

bug#36786: Warn of AMD GPUs unusable with Guix System

[Ludovic Courtès]

Hi Florian,

"pelzflorian (Florian Pelz)"  skribis:

> On Fri, Jul 26, 2019 at 01:04:40AM +0200, Ludovic Courtès wrote:
>> What about adding a few words under “Hardware Considerations”?

Oops, I hadn’t seen your patch when I replied.

> While my patch before addresses AMD-specific tweaks in the manual
> under Hardware Considerations, it is not enough if on the *download
> page* Guix is claimed to run on “an i686, x86_64, ARMv7, or AArch64
> machine“ without saying linux-libre *on some hardware, is not
> supported* and referencing the Hardware Considerations section and
> h-node, I think.

Well, ‘Limitations’ and ‘Hardware Considerations’ are the first sections
one see when following ‘Installation Instructions’ at
.  We can always move things one level
higher, but eventually everything ends up at the top level.  :-)

> >From e88ee68c09266e1d09d24ff0d1b6ec6a4708841b Mon Sep 17 00:00:00 2001
> From: Florian Pelz 
> Date: Wed, 24 Jul 2019 23:02:21 +0200
> Subject: [PATCH] doc: Mention AMD Radeon workaround when TTYs are not redrawn.
> 
> * doc/guix.texi (Hardware Considerations): Describe workaround.

[…]

> +Some hardware requires specific tweaks to work better with Guix System.  The
> +following is an incomplete list of known workarounds:
> +
> +@itemize
> +@item
> +Some @emph{AMD Radeon} graphics cards stop redrawing the virtual console TTYs
> +when booting because of an error with Kernel Mode Setting.  The problem
> +disappears when blacklisting the kernel module for the driver.  To do so, you
> +can add @code{modprobe.blacklist=radeon} to the Linux-libre kernel flags,
> +either for only one boot by pressing the @kbd{e} key in the GRUB bootloader
> +and adding this kernel flag to the end of the @code{linux} command-line, or
> +permanently by changing the @code{kernel-arguments} field in your
> +@code{operating-system} declaration, e.g.:
> +
> +@example
> +(kernel-arguments '("quiet" "modprobe.blacklist=radeon"))
> +@end example
> +@end itemize

I think this doesn’t fit well here: the previous paragraphs are about
RYF, h-node.org, and the more general issue.

Like Ricardo wrote, since this is not Guix-specific, it would be great
if we could link to other resources on this topic.  Are you aware of any
such on-line resource?

If there’s no such thing, then we should definitely add this
information, but perhaps we should move the paragraph a bit higher (next
to Wifi), and possibly turn Wifi into an item of this list.  WDYT?

Thanks,
Ludo’.

bug#36813: 'lower-gexp' does not respect 'system' or 'target' keywords

[Ludovic Courtès]

zerodaysford...@sdf.lonestar.org (Jakob L. Kreuze) skribis:

> Changing it to the following:
>
> #+BEGIN_SRC scheme
> (lower-gexp exp
> #:system "i686-linux"
> #:target "i686-unknown-linux-gnu"
> #:guile-for-build #f)
> #+END_SRC
>
> The Guile used is still a 64-bit LSB executable.

I can’t reproduce it on current ‘master’:

--8<---cut here---start->8---
scheme@(guile-user)> ,run-in-store (lower-gexp #~(+ 2 3) #:guile-for-build #f 
#:system "mips64el-linux")
$6 = #< sexp: (+ 2 3) inputs: () sources: () guile: 
#< drv: # 
/gnu/store/n2570pg8cahc8k9iqrg5qngyzf6j0xzr-guile-2.2.4-debug 
/gnu/store/j9a8dx25cj045yl5l32ajkkjf92ib3y1-guile-2.2.4 46e3230> 
sub-derivations: ("out")> load-path: () load-compiled-path: ()>
scheme@(guile-user)> (derivation-system (derivation-input-derivation 
(lowered-gexp-guile $6)))
$7 = "mips64el-linux"
--8<---cut here---end--->8---

Not even when cross-compiling (BTW, #:target probably doesn’t make sense
above, since it’s cross-compiling from i686 to i686):

--8<---cut here---start->8---
scheme@(guile-user)> ,run-in-store (lower-gexp #~(+ 2 3) #:guile-for-build #f 
#:system "mips64el-linux" #:target "i586-pc-gnu")
$8 = #< sexp: (+ 2 3) inputs: () sources: () guile: 
#< drv: # 
/gnu/store/n2570pg8cahc8k9iqrg5qngyzf6j0xzr-guile-2.2.4-debug 
/gnu/store/j9a8dx25cj045yl5l32ajkkjf92ib3y1-guile-2.2.4 46e3230> 
sub-derivations: ("out")> load-path: () load-compiled-path: ()>
scheme@(guile-user)> (derivation-system (derivation-input-derivation 
(lowered-gexp-guile $8)))
$9 = "mips64el-linux"
--8<---cut here---end--->8---

Am I missing something?

Thanks,
Ludo’.

bug#36816: gcc-toolchain 9.1.0 can't link even a tiny simple C program

[Danny Milosavljevic]

Hi,

so I've got a new drive and installed Guix (from the iso from the homepage) on 
it.

Then I ran guix pull.

Then I installed gcc-toolchain and tried to compile the following program:

int main() {
return 42;
}

using

  gcc a.c

but I get:

ld: cannot find crt1.o: No such file or directory
ld: cannot find crti.o: No such file or directory

I tried rebooting, to no avail.

It used to work.

FWIW, I restored my $HOME from backup, but I think the per-user profiles are in
/var/guix/profiles/per-user, and I didn't restore anything in /var.


pgp1qYV6ddms9.pgp
Description: Digitale Signatur von OpenPGP

bug#33656: Hard locks on boot (uefi system) via usb

[Keno Goertz]

I think I just encountered the same bug today. I got stuck at some
completely irrelevant kernel message in the boot screen. Couldn't
switch to TTY, nada. I worked around it by adding

> modprobe.blacklist=amdgpu

To the kernel parameters in grub. But the graphical installer still
didn't work because the resolution wasn't right, so I also had to add

> vga=792

Now, I can see the installer. I hope this resolves the issue for you,
too. I also think that these kernel parameters should be included by
default, because

1) amdgpu does not work without binary blobs AFAIK, so it can just be
blacklisted
2) vga=792 corresponds to 1024×768x24, which is supported by pretty
much any screen I've ever encountered. I'm not sure what happens when
the screen doesn't support the resolution specified in the vga kernel
parameter, but I think it just falls back to the standard, so it
shouldn't do any harm

bug#36813: 'lower-gexp' does not respect 'system' or 'target' keywords

[Jakob L. Kreuze]

Hi Ludo,

Ludovic Courtès  writes:

> Note: #:target must be a “GNU triplet” like “arm-linux-gnueabihf”, not
> a system type like “i686-linux”.

Thanks, is 'nix-system->gnu-triplet' the suggested way of obtaining the
triplet for a system?

> That’s because the Guile used here comes from the #:guile-for-build
> parameter.
>
> So the caller is responsible for doing the right thing here.  In fact,
> if you do:
>
>   (lower-gexp exp #:system whatever #:guile-for-build #f)
>
> it will automatically take care of computing the right Guile for this
> system.  For consistency, I don’t think we should change the default,
> though.
>
> WDYT?

Changing it to the following:

#+BEGIN_SRC scheme
(lower-gexp exp
#:system "i686-linux"
#:target "i686-unknown-linux-gnu"
#:guile-for-build #f)
#+END_SRC

The Guile used is still a 64-bit LSB executable. Similarly, the
 that's ungexp'd has a profile containing x86_64
executables.

jakob@Epsilon ~ $ readlink 
/gnu/store/6z5hdxjr8db4qm4d578lly3l87mlgkpv-system/profile/bin/* | xargs file
/gnu/store/5s2nib1lrd2101bbrivcl17kjx1mspw6-coreutils-8.30/bin/[:   
  ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, 
interpreter 
/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/ld-linux-x86-64.so.2,
 for GNU/Linux 2.6.32, not stripped
/gnu/store/9y5cvqnincp2ax5kxyv43zr7gdd89vs2-man-db-2.8.5/bin/apropos:   
  symbolic link to whatis
/gnu/store/lm3i15cvw4ybsnf2lsam5nj76kqbjg2k-libtasn1-4.13/bin/asn1Coding:   
  ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, 
interpreter 
/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/ld-linux-x86-64.so.2,
 for GNU/Linux 2.6.32, not stripped
/gnu/store/lm3i15cvw4ybsnf2lsam5nj76kqbjg2k-libtasn1-4.13/bin/asn1Decoding: 
  ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, 
interpreter 
/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/ld-linux-x86-64.so.2,
 for GNU/Linux 2.6.32, not stripped
/gnu/store/lm3i15cvw4ybsnf2lsam5nj76kqbjg2k-libtasn1-4.13/bin/asn1Parser:   
  ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, 
interpreter 
/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/ld-linux-x86-64.so.2,
 for GNU/Linux 2.6.32, not stripped
...

Regards,
Jakob

bug#36371: guix build --with-git-reference=…

[Ludovic Courtès]

Hello!

Ludovic Courtès  skribis:

> $ guix build guile-gcrypt --with-commit=guile-gcrypt=v1.0.0
> updating checkout of 'https://notabug.org/cwebber/guile-gcrypt.git'...
> guix build: error: cannot fetch commit v1.0.0 from 
> https://notabug.org/cwebber/guile-gcrypt.git: unable to parse OID - contains 
> invalid characters
>
> Internally, that uses the ‘git-checkout’ record type defined in (guix
> git).
>
> What I would propose is to change ‘git-checkout-compiler’ so that it can
> determine with a simple heuristic like that of (@@ (guix swh) commit-id?)
> whether the string denotes a commit ID or a tag.

Done in 177fecb57c0c9e15249bf6a49244c9dc6eb8439c.

Thanks,
Ludo’.

bug#36813: 'lower-gexp' does not respect 'system' or 'target' keywords

[Ludovic Courtès]

Hello Jakob,

zerodaysford...@sdf.lonestar.org (Jakob L. Kreuze) skribis:

> I believe there is an issue with 'lower-gexp'. Running the following
> snippet to lower a G-Expression for "i686-linux" yields output that
> references store paths built for x86_64. In this case, the Guile
> interpreter used is an x86_64 binary.
>
> #+BEGIN_SRC scheme
> (define (display-exp exp)
>   (mlet* %store-monad ((lowered (lower-gexp exp
> #:system "i686-linux"
> #:target "i686-linux"))
>(to-build -> (cons (lowered-gexp-guile lowered)
>   (lowered-gexp-inputs lowered)))
>(_ (built-derivations to-build)))
> (return (format #t "~a~%" (lowered-gexp-sexp lowered)
>
> (with-store store
>   (run-with-store store
> (display-exp #~(primitive-load #$(switch-system-program %system)
> #+END_SRC

Note: #:target must be a “GNU triplet” like “arm-linux-gnueabihf”, not a
system type like “i686-linux”.

> jakob@Epsilon ~ $ guile ~/test.scm 
> (primitive-load 
> /gnu/store/v7v1b7375j9j82dvfycv56v36nv5jq3y-switch-to-system.scm)
> jakob@Epsilon ~ $ cat 
> /gnu/store/v7v1b7375j9j82dvfycv56v36nv5jq3y-switch-to-system.scm
> #!/gnu/store/9alic3caqhay3h8mx4iihpmyj6ymqpcx-guile-2.2.4/bin/guile 
> --no-auto-compile
> !#
> ...
> jakob@Epsilon ~ $ file 
> /gnu/store/9alic3caqhay3h8mx4iihpmyj6ymqpcx-guile-2.2.4/bin/guile
> /gnu/store/9alic3caqhay3h8mx4iihpmyj6ymqpcx-guile-2.2.4/bin/guile: ELF 64-bit 
> LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter 
> /gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/ld-linux-x86-64.so.2,
>  for GNU/Linux 2.6.32, not stripped

That’s because the Guile used here comes from the #:guile-for-build
parameter.

So the caller is responsible for doing the right thing here.  In fact,
if you do:

  (lower-gexp exp #:system whatever #:guile-for-build #f)

it will automatically take care of computing the right Guile for this
system.  For consistency, I don’t think we should change the default,
though.

WDYT?

Thanks,
Ludo’.

bug#36785: Impossible to pull on foreign distro

[Ludovic Courtès]

Hi Julien,

Julien Lepiller  skribis:

> Le 26 juillet 2019 01:03:08 GMT+02:00, "Ludovic Courtès"  a 
> écrit :

[...]

>>;; In 0.15.0+ we'd create ~/.config/guix/current-[0-9]*-link symlinks. 
>>Move
>>  ;; them to %PROFILE-DIRECTORY.
>>  (unless (string=? %profile-directory
>>  (dirname (canonicalize-profile %user-profile-directory)))
>>(migrate-generations %user-profile-directory %profile-directory))

[...]

> Could there be some veird interaction between sudo and these 
> %profile-directory and %user-profile-directory variables?

Indeed.  I added ‘pk’ calls to print ‘%profile-directory’ and
(canonicalize-profile %user-profile-directory), and here’s what I see
with ‘sudo’:

--8<---cut here---start->8---
$ sudo -E ./pre-inst-env guix pull

;;; (pd "/var/guix/profiles/per-user/root")

;;; (upd "/home/ludo/.config/guix/current")
Migrating profile generations to '/var/guix/profiles/per-user/root'...
guix pull: error: symlink: Dosiero jam ekzistas: 
"/var/guix/profiles/per-user/root/current-guix"
--8<---cut here---end--->8---

‘%user-profile-directory’ is computed as a function of $HOME, which is
unchanged when using ‘sudo’, whereas ‘%profile-directory’ is computed as
a function of $USER.

I think $HOME should always prevail over the home directory defined in
/etc/passwd, so think we should not change the way
‘%user-profile-directory’ is computed.

We could do this:

--- a/guix/profiles.scm
+++ b/guix/profiles.scm
@@ -1721,7 +1721,8 @@ because the NUMBER is zero.)"
 
 (define %profile-directory
   (string-append %state-directory "/profiles/"
- (or (and=> (or (getenv "USER")
+ (or (and=> (or (getenv "SUDO_USER")
+(getenv "USER")
 (getenv "LOGNAME"))
 (cut string-append "per-user/" <>))
  "default")))

… but then ‘sudo guix pull’ won’t update root’s guix at all.

Otherwise I’m thinking of this gross hack:

diff --git a/guix/scripts/pull.scm b/guix/scripts/pull.scm
index 54bbaddf30..8d8a8aa889 100644
--- a/guix/scripts/pull.scm
+++ b/guix/scripts/pull.scm
@@ -293,8 +293,9 @@ true, display what would be built without actually building it."
 
   ;; In 0.15.0+ we'd create ~/.config/guix/current-[0-9]*-link symlinks.  Move
   ;; them to %PROFILE-DIRECTORY.
-  (unless (string=? %profile-directory
-(dirname (canonicalize-profile %user-profile-directory)))
+  (unless (or (getenv "SUDO_USER")
+  (string=? (pk 'pd %profile-directory)
+(dirname (pk 'upd (canonicalize-profile %user-profile-directory)
 (migrate-generations %user-profile-directory %profile-directory))
 
   ;; Make sure ~/.config/guix/current points to /var/guix/profiles/….

I think it’s acceptable because that’s “throw away” code anyway, and
it’s not supposed to be triggered these days.

Thoughts?

Ludo’.

bug#36777: Guix Inferiors: Curious incorrect derivation output bug

[Ludovic Courtès]

Hello Carl,

Carl Dong  skribis:

> I have my manifest.scm here:
> https://github.com/dongcarl/bitcoin/blob/2019-06-guix-channels-and-inferiors/contrib/guix/manifest.scm,
> and it references the aforementioned Guix channel.

This one appears to work for me (I interrupted it before it was done
compiling all the toolchains, though.)

> What I expect to happen is that now when I change my default profile's Guix
> version by 'guix pull'ing, it won't affect the environment that's generated by
> the manifest.scm. I've tested this with differing versions of Guix as my 
> default
> profile, and this seems to work with 7304d5623ab5cc35289cb1535cbd0d8a37691fac
> and 7f1c69f5d32bee6b8b6b902a9ce445e04aa9d07d being my default profile. 
> However,
> I tried an older version b6dc08393e6a8313b88ce422fc3c1e4e9c0efc6f, and got the
> following error:

When I put b6dc08393e6a8313b88ce422fc3c1e4e9c0efc6f in .guix-channel and
use that as my channel, it also works fine (well, I commented out the
toolchains as well.)

> ```
> guix environment: error: derivation 
> `/gnu/store/r641vpqc9rfjhljf7rzfzwmkmpa642ls-info-dir.drv' has incorrect 
> output `/gnu/store/q9hkdidycz3wq28xxgjq47bzx5s39k52-info-dir', should be 
> `/gnu/store/z5hh2nl0h58b9f6hdxfwm00gjyxfcc3n-info-dir'
> ```

That definitely looks like a bug.

Could you send the faulty info-dir.drv file?

Thanks,
Ludo’.

bug#36785: Impossible to pull on foreign distro

[Julien Lepiller]

Le 26 juillet 2019 01:03:08 GMT+02:00, "Ludovic Courtès"  a écrit 
:
>Hi Julien,
>
>Julien Lepiller  skribis:
>
>> I gave a small tutorial to someone today, where we installed guix on
>top of a foreign distro. We used the script and everything went
>smoothly, and after finding out that we were going to build php (we
>were trying to define a VM that would serve one of their services), we
>tried to run guix pull:
>>
>> sudo guix pull —commit=…
>>
>> However the command failed immediately with:
>>
>> Migrating profile generations to
>'/var/guix/profiles/per-user/root'...
>> Guix pull: error: symlink: File exists:
>"/var/guix/profiles/per-user/root/current-guix"
>>
>> Indeed, the file exists and everything looks good. Why does guix try
>to migrate a profile that's already good?
>>
>> I was able to work around that situation, but it's not great for our
>users.
>
>I’m guessing the machine had remnants of a previous Guix installation,
>no?  See:
>
>;; In 0.15.0+ we'd create ~/.config/guix/current-[0-9]*-link symlinks. 
>Move
>  ;; them to %PROFILE-DIRECTORY.
>  (unless (string=? %profile-directory
>  (dirname (canonicalize-profile %user-profile-directory)))
>(migrate-generations %user-profile-directory %profile-directory))
>
>Ludo’.

Not at all, this was the first install on that machine. The OS was even 
installed recently, so there can't be any remnant of the 0.15 era :). 
Installation went smoothly and /root/.config/guix/current was already a symlink 
to /var/guix/profiles/per-user/root. We ran guix pull as user just before and 
it worked perfectly well (with the message about migrating, although 
~/.config/guix/current didn't exist).

Could there be some veird interaction between sudo and these %profile-directory 
and %user-profile-directory variables?