bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

[Leo Le Bouter via Bug reports for GNU Guix]

For the record, I attached the failed build log for current core-
updates.

$ ./pre-inst-env guix describe
Git checkout:
  repository: /home/lle-bout/src/guix
  branch: core-updates
  commit: cc6cb6e80a42355147809b4830053a34d1563994

Build command:

$ ./pre-inst-env guix build --target=powerpc64le-linux-gnu bootstrap-
tarballs

The most important bit in the build log is:

configure: error: ***  The compiler must support -mabi=ieeelongdouble
and -mlongdouble simultaneously.

This particular error does not happen with the GCC 7.x and Glibc 2.31
combo.


bin0lTa7yArN4.bin
Description: application/bzip

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

[Leo Le Bouter via Bug reports for GNU Guix]

On Mon, 2020-12-14 at 23:24 +0100, Ludovic Courtès wrote:
> Yes, I think we could just cross-build those bootstrap binaries from
> current ‘master’ and be done with it, if it works for you.

Yes that would be awesome! The master branch just needs the patch from
bug  - I guess
considering it affects lots of packages it needs to be rewritten the
same way Efraim has rewritten their PowerPC 32-bits patch. I'll look
into that. Correct?

bug#45187: git download defaults to origin/master

[Kyle Meyer]

Ludovic Courtès writes:

>>  (define* (update-cached-checkout url
>>   #:key
>> - (ref '(branch . "master"))
>> + (ref '(symref . 
>> "refs/remotes/origin/HEAD"))
>>   recursive?
>>   (check-out? #t)
>>   starting-commit
>> @@ -395,7 +398,7 @@ (define* (latest-repository-commit store url
>> (log-port (%make-void-port "w"))
>> (cache-directory
>>  (%repository-cache-directory))
>> -   (ref '(branch . "master")))
>> +   (ref '(symref . 
>> "refs/remotes/origin/HEAD")))
>
> Do we really need to add “remotes/origin” in there?  Or is there a way
> to just say HEAD and later specify that we’re talking about the remote
> head, as is done fro branches?

Thanks for the feedback.  Sure, that sounds fine to me.  As far as I can
tell, in this context it'd make sense to assume HEAD should always be
the one under refs/remotes/origin.  (It really was a "quick check that
my suggestion to use the remote HEAD symref works" sort of patch :))

Another thing that doesn't feel suitable for the proper patch is the
introduction of the `symref' symbol...

> We also need to change the defaults in  & co., like Marius did.

...which didn't seem particularly nice to add as a field to
.

However, without the introduction of something like `symref', I'm not
spotting a straightforward way to deal with refs/remotes/origin/HEAD in
resolve-reference.

FWIW if we were to go in the direction Marius suggested, I believe the
main change needed on top of Marius's patch in order to use the remote
symref would be

diff --git a/guix/git.scm b/guix/git.scm
index 0c49859e42..5caf715916 100644
--- a/guix/git.scm
+++ b/guix/git.scm
@@ -313,9 +313,7 @@ (define* (update-cached-checkout url
   (('branch . branch)
`(branch . ,(if (string-prefix? "origin/" branch)
branch
-   (if (string=? "HEAD" branch)
-   branch
-   (string-append "origin/" branch)
+   (string-append "origin/" branch
   (_ ref)))
 
   (with-libgit2

bug#45193: Wrapper of Qt programs doesn't extend existing environment variable

[Zhu Zihao]

Mark H Weaver writes:

> I agree with your analysis.  Would you like to propose a patch and test
> it as thoroughly as you can?

I just saw a patch posted by somebody on debbugs.

https://issues.guix.gnu.org/45221

Maybe we can go there to improve his patch and we don't have to write it
from scratch.

-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao


signature.asc
Description: PGP signature

bug#45109: GNOME: unable to change alert "beep" sound since staging merge

[Mark H Weaver]

reopen 45109
thanks

Earlier, I wrote:
> I initially tried Marius's idea to revert the dconf update, which
> seemed to work, but now I find that I'm unable to reproduce the
> problem, even with my original post-staging-merge system where I first
> encountered it.

I spoke too soon.  Now the problem is happening again, after another
system upgrade and reboot.  I don't have time right now to investigate
further, but I'm reopening the bug.

 Thanks,
   Mark

bug#45166: Wrong locale settings for guix-daemon causes confusing error

[Ludovic Courtès]

Hi,

Marius Bakke  skribis:

> Ludovic Courtès  skriver:
>
>> Hi,
>>
>> Marius Bakke  skribis:
>>
>>> User sss2 reported on #guix[0] that running guix-daemon with an invalid
>>> locale causes the following error:
>>>
>>> # guix pull
>>> Updating channel 'guix' from Git repository at 
>>> 'https://git.savannah.gnu.org/git/guix.git'...
>>> Building from this channel:
>>>   guix  https://git.savannah.gnu.org/git/guix.git   77667e2
>>> Computing Guix derivation for 'x86_64-linux'... |
>>> guix pull: error: got unexpected path `hint: Consider installing the 
>>> `glibc-utf8-locales' or `glibc-locales' package and' from substituter
>>
>> How did they run the daemon?  The systemd unit file we provide normally
>> makes sure it runs with the right GUIX_LOCPATH and with a valid locale.
>
> It was a hand-written systemd unit file, hence the error.  My main
> concern is with this error message:
>
>   guix pull: error: got unexpected path `hint: Consider installing the 
> `glibc-utf8-locales' or `glibc-locales' package and' from substituter
>
> Previously, the daemon would continue in the face of wrong locale
> settings, but print lots of warnings, now it fails hard and early with
> this unhelpful message.
>
> If that is intended, can we catch it and provide a more actionable error
> message?

No, that must be a regression somewhere, but I’m not sure where.

Does it happen if you run say “guix build hello” and a substitute is
downloaded?  Or “guix build hello -S --no-substitutes”?

Thanks,
Ludo’.

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

[Ludovic Courtès]

Hi Leo,

Leo Le Bouter  skribis:

> It would be great to do that at least temporarily on master. It will
> not affect much since other architectures are bootstrapped already. We
> could also make it conditional. Reproducibility instructions will have
> to contain exact commit id and configuration for both GNU Guix System
> (x86_64-linux) and GNU Guix which can cross-compile.

Yes, I think we could just cross-build those bootstrap binaries from
current ‘master’ and be done with it, if it works for you.

Thanks,
Ludo’.

bug#45193: Wrapper of Qt programs doesn't extend existing environment variable

[Mark H Weaver]

Hi,

Zhu Zihao  writes:

> Reproduce steps:
>
>guix environment --ad-hoc qbittorrent && cat 
> $GUIX_ENVIRONMENT/bin/qbittorrent
>
>
> We can see the wrapper generated in qt-build-system doesn't extend
> existing environment variable. Instead, it overrides them.
>
> It was discussed in
> https://lists.gnu.org/archive/html/guix-devel/2019-12/msg00117.html one
> year ago. This's not a trivial issue because using input method in Qt
> program requires an qt plugin(XIM doesn't work here) which is managed by
> QT_PLUGIN_PATH.
>
> We should change following functions:
>
> 1. guix/build/qt-build-system.scm(wrap-all-programs)
> 2. guix/build/qt-utils.scm(wrap-qt-program)
>
> It's ideal to make wrap-all-programs use wrap-qt-program internally and
> we don't need to maintain two copy of wrap code.

I agree with your analysis.  Would you like to propose a patch and test
it as thoroughly as you can?

 Regards,
   Mark

bug#45239: [[info:guix#Submitting Patches]] mentions texlive-union

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Jorge,

Jorge P. de Morais Neto 写道：

OK, I am sorry for the noise.


As long as it's useful noise please generate as much or as little 
as you wish :-)


After some delay I pushed[0] which should avoid similar confusion 
in future.



And thank you for your work in GNU!


All the same,

T G-R

[0]: 
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=48cccf06ad84f96bb4fc839ab6f26525c7e8dae0


signature.asc
Description: PGP signature

bug#45239: [[info:guix#Submitting Patches]] mentions texlive-union

[Jorge P . de Morais Neto via Bug reports for GNU Guix]

Hi.

Em [2020-12-14 seg 18:41:15+0100], Tobias Geerinckx-Rice escreveu:

> Texlive-union is not a package object and cannot be installed on 
> the command line.
>
> It's defined[0] in (gnu packages tex) as a utility procedure for 
> use in writing packages, similar to sdl-union , which is why 
> it's mentioned there.

OK, I am sorry for the noise.  And thank you for your work in GNU!

Regards

-- 
- 
- If an email of mine arrives at your spam box, please notify me.
- Please adopt free/libre formats like PDF, ODF, Org, LaTeX, Opus, WebM and 7z.
- Free/libre software for Replicant, LineageOS and Android: https://f-droid.org
- [[https://www.gnu.org/philosophy/free-sw.html][What is free software?]]

bug#45239: [[info:guix#Submitting Patches]] mentions texlive-union

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Jorge!

Jorge P. de Morais Neto via Bug reports for GNU Guix 写道：
Hi.  The manual section [[info:guix#Submitting Patches]] 
mentions

package `texlive-union', which does not exist:


Texlive-union is not a package object and cannot be installed on 
the command line.


It's defined[0] in (gnu packages tex) as a utility procedure for 
use in writing packages, similar to sdl-union , which is why 
it's mentioned there.


Closing,

T G-R

[0]: 
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/tex.scm#n3408


signature.asc
Description: PGP signature

bug#45238: The section [[info:guix#Invoking guix package]] contradicts itself

[Jorge P. de Morais Neto]

Hi.  The last paragraph of [[info:guix#Invoking guix package]] says:

However, note that package transformations are lost when upgrading;
to preserve transformations across upgrades, you should define your
own package variant in a Guile module and add it to
‘GUIX_PACKAGE_PATH’ (*note Defining Packages::).

This contradicts the earlier information, in the same section, about
`guix package -u':

When upgrading, package transformations that were originally applied
when creating the profile are automatically re-applied (*note Package
Transformation Options::).

Regards

-- 
- 
- If an email of mine arrives at your spam box, please notify me.
- Please adopt free/libre formats like PDF, ODF, Org, LaTeX, Opus, WebM and 7z.
- Free/libre software for Replicant, LineageOS and Android: https://f-droid.org
- [[https://www.gnu.org/philosophy/free-sw.html][What is free software?]]

bug#45239: [[info:guix#Submitting Patches]] mentions texlive-union

[Jorge P. de Morais Neto]

Hi.  The manual section [[info:guix#Submitting Patches]] mentions
package `texlive-union', which does not exist:

$ guix search texlive-union
$

-- 
- 
- If an email of mine arrives at your spam box, please notify me.
- Please adopt free/libre formats like PDF, ODF, Org, LaTeX, Opus, WebM and 7z.
- Free/libre software for Replicant, LineageOS and Android: https://f-droid.org
- [[https://www.gnu.org/philosophy/free-sw.html][What is free software?]]

bug#45236: Xboard doesn't work.

[Pablo Ferreira]

Hey again!

Great job with the GNU Guix System 1.2.0. Really nice!

I think this is not about you but Xboard game is not working for so long, I
wait until update but is not coming. The app say some problem with the
engine, I did install chess (6.2.7) by the way.

Merry Christmas!

bug#43610: IceCat segfault

[Alex ter Weele]

raingloom  writes:

> On Fri, 2 Oct 2020 00:57:39 +0200
> raingloom  wrote:
>
> Well, what ended up working was deleting a bunch of file from the
> profile directory. No idea which deletion made it work and at this
> point I just wanna crawl back to Netsurf.
> Can't say I'd recommend this workaround to regular users, but if you
> can guess what those files are, you should be safe.

Thanks to raingloom, we know that deleting some parts of the profile can
work around the segfault. I set out to find the minimal part of my
profile that I could delete while still working around the
segfault.

All I had to delete was the line

user_pref("network.captive-portal-service.enabled", true);

from ~/.mozilla/icecat/$my-profile/prefs.js.

Methodology: I put my whole profile into a git repo, then deleted it file
by file with

for i in * ; do
rm $i
git commit -am "Remove $i"
done

then I used git bisect to find which file(s) had to be deleted before
icecat wouldn't segfault.

Once I had a set of files whose deletion avoided the segfault, I
minimized that set by "un"deleting them by git reverting the commits
that deleted them. Eventually I undeleted all the files in the set
except prefs.js.

I then bisected on the lines in prefs.js, this time manually. I found
that the deletion of just the network.captive-portal-service.enabled
pref is sufficient to avoid the segfault.

I tested this with icecat 78.4.0-guix0-preview1.

  $ guix describe
  Generation 318Nov 12 2020 07:36:51(current)
...
guix 07914de
  repository URL: https://git.savannah.gnu.org/git/guix.git
  branch: master
  commit: 07914def98ca0d148e3522466227304e45286786

bug#25719: "guix package -i" exception should be a normal error message

[zimoun]

Hi Danny
On Wed, 02 Dec 2020 at 14:35, Danny Milosavljevic  
wrote:

>> > substitute: 1727: 3 [%start-stack load-stack #> > ice-9/boot-9.scm:4047:10 ()>]
>> > substitute: 1732: 2 [#]
>> > substitute: In unknown file:
>> > substitute:?: 1 [primitive-load 
>> > "/gnu/store/175nlv448nk5kagwwl3zyy2w4726qfz6-guix-0.12.0-4.d9da/bin/.guix-real"]
>> > substitute: In guix/ui.scm:
>> > substitute: 1228: 0 [run-guix-command substitute "--query"]
>> > substitute: 
>> > substitute: guix/ui.scm:1228:8: In procedure run-guix-command:
>> > substitute: guix/ui.scm:1228:8: Throw to key `bad-response' with args 
>> > `("Bad Response-Line: ~s" (""))'.
>> >
>> > It might make sense to
>> >
>> > (a) convert that into a normal runtime error message and  
>> 
>> What do you mean?
>
> The above is an exception.
>
> In this case the download failed--and unfortunately that is a completely 
> normal
> thing on the internet.  Therefore, that is not something you'd use an 
> exception
> for.
>
> There is no added information that could help the user in the exception.
> For example it doesn't list the URL--the one thing that would actually help.

If I understand correctly, instead of the backtrace you would like a
message captured by the exception, right?

All the best,
simon

bug#37851: bug#25305: bug#37851: Grub installation only checks for encrypted /boot folder

[Ludovic Courtès]

Hi Miguel,

Miguel Ángel Arruga Vivas  skribis:

>>From 52993db19da43699ea96ea16ebb051b9652934f9 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Miguel=20=C3=81ngel=20Arruga=20Vivas?=
>  
> Date: Sun, 25 Oct 2020 16:31:17 +0100
> Subject: [PATCH v4 5/5] system: Allow separated /boot and encrypted root.
>
> * gnu/bootloader/grub.scm (grub-configuration-file): New parameter
> store-crypto-devices.
> [crypto-devices]: New helper function.
> [builder]: Use crypto-devices.
> * gnu/machine/ssh.scm (roll-back-managed-host): Use
> boot-parameters-store-crypto-devices to provide its contents to the
> bootloader configuration generation process.
> * gnu/tests/install.scm (%encrypted-root-not-boot-os,
> %encrypted-root-not-boot-os): New os declaration.
> (%encrypted-root-not-boot-installation-script): New script, whose contents
> were initially taken from %encrypted-root-installation-script.
> (%test-encrypted-root-not-boot-os): New test.
> * gnu/system.scm (define-module): Export
> operating-system-bootoader-crypto-devices and
> boot-parameters-store-crypto-devices.
> (): Add field store-crypto-devices.
> (read-boot-parameters): Parse store-crypto-devices field.
> [uuid-sexp->uuid]: New helper function extracted from
> device-sexp->device.
> (operating-system-bootloader-crypto-devices): New function.
> (operating-system-bootcfg): Use
> operating-system-bootloader-crypto-devices to provide its contents to
> the bootloader configuration generation process.
> (operating-system-boot-parameters): Add store-crypto-devices to the
> generated boot-parameters.
> (operating-system-boot-parameters-file): Likewise to the file with
> the serialized structure.
> * guix/scripts/system.scm (reinstall-bootloader): Use
> boot-parameters-store-crypto-devices to provide its contents to the
> bootloader configuration generation process.
> * tests/boot-parameters.scm (%default-store-crypto-devices): New
> variable.
> (%grub-boot-parameters, test-read-boot-parameters): Use
> %default-store-crypto-devices.
> (tests store-crypto-devices): New tests.
> ---
>  gnu/bootloader/grub.scm   |  21 +++-
>  gnu/machine/ssh.scm   |   3 ++
>  gnu/system.scm|  57 -
>  gnu/tests/install.scm | 103 ++
>  guix/scripts/system.scm   |   2 +
>  tests/boot-parameters.scm |  29 ++-
>  6 files changed, 210 insertions(+), 5 deletions(-)

Woohoo!

> --- a/gnu/bootloader/grub.scm
> +++ b/gnu/bootloader/grub.scm
> @@ -4,7 +4,7 @@
>  ;;; Copyright © 2017 Leo Famulari 
>  ;;; Copyright © 2017, 2020 Mathieu Othacehe 
>  ;;; Copyright © 2019, 2020 Jan (janneke) Nieuwenhuizen 
> -;;; Copyright © 2019 Miguel Ángel Arruga Vivas 
> +;;; Copyright © 2019, 2020 Miguel Ángel Arruga Vivas 
>  ;;; Copyright © 2020 Maxim Cournoyer 
>  ;;; Copyright © 2020 Stefan 
>  ;;;
> @@ -360,11 +360,14 @@ code."
>(locale #f)
>(system (%current-system))
>(old-entries '())
> +  (store-crypto-devices '())
>store-directory-prefix)
>"Return the GRUB configuration file corresponding to CONFIG, a
>   object, and where the store is available at
>  STORE-FS, a  object.  OLD-ENTRIES is taken to be a list of menu
>  entries corresponding to old generations of the system.
> +STORE-CRYPTO-DEVICES contain the UUIDs of the encrypted units that must
> +be unlocked to access the store contents.
>  STORE-DIRECTORY-PREFIX may be used to specify a store prefix, as is required
>  when booting a root file system on a Btrfs subvolume."
>(define all-entries
> @@ -412,6 +415,21 @@ menuentry ~s {
>(string-join (map string-join '#$modules)
> "\n  module " 'prefix))
>  
> +  (define (crypto-devices)
> +(define (crypto-device->cryptomount dev)
> +  (if (uuid? dev)
> +  #~(format port "cryptomount -u ~a~%"
> +;; cryptomount only accepts UUID without the hypen.
> +#$(string-delete #\- (uuid->string dev)))
> +  ;; Other type of devices aren't implemented.
> +  #~()))
> +(let ((devices (map crypto-device->cryptomount store-crypto-devices))
> +  ;; XXX: Add luks2 when grub 2.06 is packaged.
> +  (modules #~(format port "insmod luks~%")))
> +  (if (null? devices)
> +  devices
> +  (cons modules devices

What I don’t get is why we’re able to use an encrypted root right now
without emitting “cryptomount” GRUB commands?

> +  (store-crypto-devices
> +   (match (assq 'store rest)
> + (('store . store-data)
> +  (match (assq 'crypto-devices store-data)
> +(('crypto-devices devices)
> + (if (list? devices)
> + (map uuid-sexp->uuid devices)
> + (begin
> +   (warning (G_ "unrecognized crypto-device ~S at 

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

[Leo Le Bouter via Bug reports for GNU Guix]

On Mon, 2020-12-14 at 12:38 +0200, Efraim Flashner wrote:
> It looks like I mispoke, I meant gnu/packages/make-bootstrap.scm. If
> we
> change glibc-for-bootstrap to inherit glibc-2.31 then the rest of the
> bootstrap binaries should use that one and everything else will use
> the
> regular glibc.

It would be great to do that at least temporarily on master. It will
not affect much since other architectures are bootstrapped already. We
could also make it conditional. Reproducibility instructions will have
to contain exact commit id and configuration for both GNU Guix System
(x86_64-linux) and GNU Guix which can cross-compile.

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

[Efraim Flashner]

On Mon, Dec 14, 2020 at 11:34:35AM +0100, Leo Le Bouter wrote:
> On Mon, 2020-12-14 at 12:27 +0200, Efraim Flashner wrote:
> 
> > but I wouldn't count on
> > maintaining a separate glibc for powerpc64le vs the rest of the
> > architectures.
> 
> It doesnt need to be maintained, it only needs to work in one commit on
> master and then one uses time-machine to rebuild the bootstrap binaries
> if they wish to. The make-bootstrap code is already unmaintained for
> every architecture anyway since we never rebuild bootstrap binaries
> using later GNU Guix revisions ever.

It looks like I mispoke, I meant gnu/packages/make-bootstrap.scm. If we
change glibc-for-bootstrap to inherit glibc-2.31 then the rest of the
bootstrap binaries should use that one and everything else will use the
regular glibc.

> 
> > Do you have a preference big-endian vs little endian?
> 
> I'd like both but little endian has the widest eco-system support
> especially w.r.t. to Linux drivers. Many Linux drivers have endianness
> bugs (lack of endian-safe serialization for DMA..), it's such a plague
> that sticking to little endian is just better right now. One common
> example being mpt3sas and amdgpu drivers required in some
> configurations of the Talos II system.
> 

I remember you mentioning that.

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

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

[Leo Le Bouter via Bug reports for GNU Guix]

On Mon, 2020-12-14 at 12:27 +0200, Efraim Flashner wrote:

> but I wouldn't count on
> maintaining a separate glibc for powerpc64le vs the rest of the
> architectures.

It doesnt need to be maintained, it only needs to work in one commit on
master and then one uses time-machine to rebuild the bootstrap binaries
if they wish to. The make-bootstrap code is already unmaintained for
every architecture anyway since we never rebuild bootstrap binaries
using later GNU Guix revisions ever.

> Do you have a preference big-endian vs little endian?

I'd like both but little endian has the widest eco-system support
especially w.r.t. to Linux drivers. Many Linux drivers have endianness
bugs (lack of endian-safe serialization for DMA..), it's such a plague
that sticking to little endian is just better right now. One common
example being mpt3sas and amdgpu drivers required in some
configurations of the Talos II system.

bug#45166: Wrong locale settings for guix-daemon causes confusing error

[Marius Bakke]

Ludovic Courtès  skriver:

> Hi,
>
> Marius Bakke  skribis:
>
>> User sss2 reported on #guix[0] that running guix-daemon with an invalid
>> locale causes the following error:
>>
>> # guix pull
>> Updating channel 'guix' from Git repository at 
>> 'https://git.savannah.gnu.org/git/guix.git'...
>> Building from this channel:
>>   guix  https://git.savannah.gnu.org/git/guix.git   77667e2
>> Computing Guix derivation for 'x86_64-linux'... |
>> guix pull: error: got unexpected path `hint: Consider installing the 
>> `glibc-utf8-locales' or `glibc-locales' package and' from substituter
>
> How did they run the daemon?  The systemd unit file we provide normally
> makes sure it runs with the right GUIX_LOCPATH and with a valid locale.

It was a hand-written systemd unit file, hence the error.  My main
concern is with this error message:

  guix pull: error: got unexpected path `hint: Consider installing the 
`glibc-utf8-locales' or `glibc-locales' package and' from substituter

Previously, the daemon would continue in the face of wrong locale
settings, but print lots of warnings, now it fails hard and early with
this unhelpful message.

If that is intended, can we catch it and provide a more actionable error
message?


signature.asc
Description: PGP signature

bug#45187: git download defaults to origin/master

[Ludovic Courtès]

Hi,

Kyle Meyer  skribis:

> diff --git a/guix/git.scm b/guix/git.scm
> index ca77b9f54b..7320c0d6c8 100644
> --- a/guix/git.scm
> +++ b/guix/git.scm
> @@ -207,6 +207,9 @@ (define (resolve-reference repository ref)
> (let ((oid (reference-target
> (branch-lookup repository branch BRANCH-REMOTE
>   (object-lookup repository oid)))
> +  (('symref . symref)
> +   (let ((oid (reference-name->oid repository symref)))
> + (object-lookup repository oid)))
>(('commit . commit)
> (let ((len (string-length commit)))
>   ;; 'object-lookup-prefix' appeared in Guile-Git in Mar. 2018, so we
> @@ -320,7 +323,7 @@ (define (reference-available? repository ref)
>  
>  (define* (update-cached-checkout url
>   #:key
> - (ref '(branch . "master"))
> + (ref '(symref . "refs/remotes/origin/HEAD"))
>   recursive?
>   (check-out? #t)
>   starting-commit
> @@ -395,7 +398,7 @@ (define* (latest-repository-commit store url
> (log-port (%make-void-port "w"))
> (cache-directory
>  (%repository-cache-directory))
> -   (ref '(branch . "master")))
> +   (ref '(symref . 
> "refs/remotes/origin/HEAD")))

Do we really need to add “remotes/origin” in there?  Or is there a way
to just say HEAD and later specify that we’re talking about the remote
head, as is done fro branches?

We also need to change the defaults in  & co., like Marius did.

Thanks,
Ludo’.

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

[Efraim Flashner]

On Mon, Dec 14, 2020 at 10:22:43AM +0100, Leo Le Bouter wrote:
> Hello Chris, Ludo and Efraim,
> 
> In my experience, the bootstrap binaries are reproducible on
> powerpc64le-linux-gnu for a specific GNU Guix System and GNU Guix
> version and configuration. It's not perfect that the kernel version has
> to be pinned for reproducibility but it's better than nothing.
> 
> The issue with powerpc64le-linux-gnu on GNU Guix core-updates now is
> that it has been upgraded to Glibc 2.32 and there is other issues due
> to that. Glibc 2.31 is otherwise working well. I wish we could push
> changes to build bootstrap binaries to master where there is Glibc 2.31
> (and ensure the changes don't affect other architectures) and get this
> over with. 

It is possible to create a "perfect setup" by editing the package
definitions in gnu/packages/bootstrap to fix certain issues which are
needed to make bootstrap binaries actually work. I suppose it would be
possible to downgrade glibc in bootstrap.scm, but I wouldn't count on
maintaining a separate glibc for powerpc64le vs the rest of the
architectures.

Do you have a preference big-endian vs little endian?

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

bug#45187: git download defaults to origin/master

[Ludovic Courtès]

Hi!

Marius Bakke  skribis:

> I wonder if there was a specific reason to not use 'revparse-single',
> and instead mostly reinvent it with (resolve-reference ...).

It must have been ignorance on my side, but also the fact that something
like ‘revparse-single’ has to guess what it is you’re looking for (is
this string a commit ID? a tag name? a branch name?), whereas here we
can explicitly state what we want and thus reduce the search space and
ambiguity.

Does that make sense?

Ludo’.

bug#45166: Wrong locale settings for guix-daemon causes confusing error

[Ludovic Courtès]

Hi,

Marius Bakke  skribis:

> User sss2 reported on #guix[0] that running guix-daemon with an invalid
> locale causes the following error:
>
> # guix pull
> Updating channel 'guix' from Git repository at 
> 'https://git.savannah.gnu.org/git/guix.git'...
> Building from this channel:
>   guix  https://git.savannah.gnu.org/git/guix.git   77667e2
> Computing Guix derivation for 'x86_64-linux'... |
> guix pull: error: got unexpected path `hint: Consider installing the 
> `glibc-utf8-locales' or `glibc-locales' package and' from substituter

How did they run the daemon?  The systemd unit file we provide normally
makes sure it runs with the right GUIX_LOCPATH and with a valid locale.

Thanks,
Ludo’.

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

[Leo Le Bouter via Bug reports for GNU Guix]

Hello Chris, Ludo and Efraim,

In my experience, the bootstrap binaries are reproducible on
powerpc64le-linux-gnu for a specific GNU Guix System and GNU Guix
version and configuration. It's not perfect that the kernel version has
to be pinned for reproducibility but it's better than nothing.

The issue with powerpc64le-linux-gnu on GNU Guix core-updates now is
that it has been upgraded to Glibc 2.32 and there is other issues due
to that. Glibc 2.31 is otherwise working well. I wish we could push
changes to build bootstrap binaries to master where there is Glibc 2.31
(and ensure the changes don't affect other architectures) and get this
over with. 

Leo

bug#26247: Gettext introduces timestamps in .mo files

[Ludovic Courtès]

Hi Miguel,

Miguel Ángel Arruga Vivas  skribis:

> Ludovic Courtès  writes:
>
>> Julien Lepiller  skribis:
>>
>>> So it's not gettext itself, but our build system that generates the
>>> en@quote and en@boldquote files. Do we really need them? If so, we
>>> should find a way to generate them reproducibly.
>>
>> They’re generated automatically by the gettext Makefilery that we use,
>> so I don’t think there’s much we can do?
>
> The issue isn't on those files but on POT generation.  Currently
> xgettext doesn't honor SOURCE_DATE_EPOCH to fill POT-Creation-Date,
> which is used to fill PO-Revision-Date for auto-generated po files.
> These files are included into tarballs generated by make dist, therefore
> its date is already fixed, but they aren't present on our git tree---for
> obvious reasons.

OK.

> This bug has already been reported upstream[1] and probably I'll push it
> as soon as I have more test cases prepared and receive a brief review,
> but I can prepare a patch for previous versions if it's needed too.

[...]

> [1] https://savannah.gnu.org/bugs/?59658

Thanks for getting to the bottom of this and for preparing a patch
upstream!

In ‘core-updates’, we could either wait for the next Gettext release or
apply your patch in the meantime.

Ludo’.

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

[Ludovic Courtès]

Hi Chris,

Chris Marusich  skribis:

> It's been almost half a year now, and we're not really any closer to
> figuring out why the cross-built GCC bootstrap binary is
> non-reproducible.  It seems counter-productive to obsess about making
> this specific binary reproducible, although I wish it could be so.
>
> What do you think about using the bootstrap binaries we built half a
> year ago, and proceed with bootstrapping efforts?  To be totally honest,
> I'm feeling pretty exhausted by this bug, since I have spent so many
> days trying to unravel it, and I haven't made any significant progress.
> With no clear end in sight, I would really prefer to move on instead of
> blocking the entire bootstrapping effort on this reproducibility bug.
> The reproducibility of the bootstrap binaries is important, but simply
> having any bootstrap binaries at all is also important.  I think I have
> done my due diligence to try making them reproducible.  Most of them
> are, but I just can't figure out why GCC isn't.  I think it would be
> best to proceed with the binaries we have.

I didn’t follow the whole discussion nor did I try to investigate
myself, but thanks a lot for going to great lengths trying to identify
the issue; this is an impressive amount of work, and I can only share
your disappointment.

Given this effort, I agree that it may be best at this point to move on
and start with these non-reproducible binaries.  At least, the problem
is now documented.

> At this point, it might even make more sense to try bootstrapping for
> powerpc64le instead of powerpc64, since the rest of the world seems to
> be gravitating toward the little-endian variant on POWER9 hardware, and
> thus various programs out there are more likely to be better tested on
> powerpc64le than powerpc64.

Yes, my understanding is that other people, in particular Tobias Platen
and dftxbs3e, were looking at powerpc64le, so perhaps it’s a good idea
to concentrate on that one?

Anyhow, please let me know if/when bootstrap binaries should be uploaded
to ftp.gnu.org (with a signed message).  When updating bootstrap.scm to
refer to them, please include the commit ID used to build them in the
commit message.

Thanks,
Ludo’.

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

[Efraim Flashner]

On Sun, Dec 13, 2020 at 03:36:58PM -0800, Chris Marusich wrote:
> Hi,
> 
> I tried to do some experiments to see if this problem happens with the
> current GCC (version 10).
> 
> I built GCC 10 (not cross-compiling) on an x86_64 system using Guix with
> substitutes on Debian.  (I tried without substitutes, too, but some of
> the dependencies failed to be built for unrelated reasons.)  I then
> manually copied the /gnu/store and related files (except for the GCC 10
> output paths) from Debian onto a Fedora machine, and I rebuilt GCC 10
> there using Guix (again, not cross-compiling).  The output on Fedora was
> identical to that of Debian.  Of course, the configuration Guix uses to
> build GCC 10 is a bit different from the one used to (cross-)build the
> powerpc64-linux bootstrap GCC, but it's still an interesting data point.
> In particular, GCC 10's libstdc++.a was identical on Debian and Fedora,
> so I suppose maybe they've fixed that issue in the more recent versions.
> 
> I also tried to use Guix (the current version, from master branch - I
> ran guix pull today) to cross-build gcc-10 for the powerpc64-linux-gnu
> target on both Debian and Fedora x86_64 systems, starting from scratch
> with substitutes enabled:
> 
> guix build --target=powerpc64-linux-gnu -e '(@ (gnu packages gcc) gcc-10)'
> 
> On both Debian and Fedora, the build of gcc-10.2.0.drv failed with the
> following error:
> 
> checking for -fPIC -shared... yes
> configure: error: 
>Building GCC with plugin support requires a host that supports
>-fPIC, -shared, -ldl and -rdynamic.
> 
> This basically just means that we can't cross-build gcc-10 for
> powerpc64-linux-gnu out of the box on x86_64 with current Guix.  I was
> hoping that the builds would succeed, and I would be able to find out if
> cross-building gcc-10 in this way would create non-reproducible
> artifacts.  I was hoping maybe I could ask for help from the GCC
> community if that were the case.  But since it doesn't even build, the
> results of that experiment were not very useful.
> 
> It's been almost half a year now, and we're not really any closer to
> figuring out why the cross-built GCC bootstrap binary is
> non-reproducible.  It seems counter-productive to obsess about making
> this specific binary reproducible, although I wish it could be so.
> 
> What do you think about using the bootstrap binaries we built half a
> year ago, and proceed with bootstrapping efforts?  To be totally honest,
> I'm feeling pretty exhausted by this bug, since I have spent so many
> days trying to unravel it, and I haven't made any significant progress.
> With no clear end in sight, I would really prefer to move on instead of
> blocking the entire bootstrapping effort on this reproducibility bug.
> The reproducibility of the bootstrap binaries is important, but simply
> having any bootstrap binaries at all is also important.  I think I have
> done my due diligence to try making them reproducible.  Most of them
> are, but I just can't figure out why GCC isn't.  I think it would be
> best to proceed with the binaries we have.
> 
> Ludovic Courtès  writes:
> 
> > Hi Chris,
> >
> > Chris Marusich  skribis:
> >
> >> From e3d1778a86dfd171d59d91eb01417faaf63dfa17 Mon Sep 17 00:00:00 2001
> >> From: Chris Marusich 
> >> Date: Sat, 19 Sep 2020 14:25:43 -0700
> >> Subject: [PATCH] gnu: Disable libstdc++ in bootstrap GCC.
> >>
> >> Fixes part of: .
> >>
> >> * gnu/packages/make-bootstrap.scm (%gcc-static) [#:configure-flags]: Add
> >> --disable-libstdcxx to disable building the libstdc++-v3 directory.
> >
> > [...]
> >
> >> +   ;; In this GCC version, libstdc++.a is not 
> >> reproducible:
> >> +   ;; https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41669
> >> +   "--disable-libstdcxx"
> >
> > Does it have any effect with GCC > 4.7?  My understanding is that it
> > builds its libstdc++ no matter what.
> >
> > Also, if it’s just libstdc++.a that’s problematic (ordering issue in the
> > .a archive?), perhaps we can use --disable-shared?
> >
> > My 2¢ (I didn’t follow the whole discussion),
> > Ludo’.
> 
> Actually, --disable-shared is already present in the configure options.
> My understanding is that libstdc++.a is a statically linked library
> (perhaps I am mistaken...?), so I don't see why the presence or absence
> of --disable-shared would affect it.  I thought that option was just
> supposed to control whether or not to build shared libraries.
> 
> Efraim Flashner  writes:
> 
> > On Fri, Sep 25, 2020 at 11:52:48PM -0700, Chris Marusich wrote:
> >> Hi everyone,
> >> 
> >> Efraim Flashner  writes:
> >> 
> >> > Is this a file we actually need during the bootstrap process? Can we
> >> > "work around it" by just deleting it?
> 
> I've spent all of my spare Guix time trying to debug this
> reproducibility issue first, and half a year has passed without progress
> as a result.  I think we should use the bootstrap binaries we