bug#50026: Specify a pull-request in --with-branch package transformations

[Ludovic Courtès]

Hi!

Philippe SWARTVAGHER  skribis:

> guix build chameleon --with-branch=chameleon=merge-requests/262/head
>
> ```
>
> (with 262 being the pull-request I'm interested in) However, this fails:
>
> ```
>
> guix build: erreur : impossible de récupérer la branche «
> merge-requests/262/head » depuis
> https://gitlab.inria.fr/solverstack/chameleon : cannot locate
> remote-tracking branch 'origin/merge-requests/262/head'
> ```
>
> While commands stated in the documentation work well:
>
> ```bash
>
> git clone https://gitlab.inria.fr/solverstack/chameleon && cd chameleon
>
> git fetch origin merge-requests/262/head:mr-262
>
> git checkout mr-262

Any idea what makes this branches “special” from a Git viewpoint?

Guix uses libgit2 (via Guile-Git); perhaps there’s a feature here that
libgit2 doesn’t support, or perhaps there’s an additional step to make
to make those branches visible?

Thanks,
Ludo’.

bug#50441: Wrong build directory number shown in environment-variables file

[Ludovic Courtès]

Hi,

Christine Lemmer-Webber  skribis:

> Tobias Geerinckx-Rice  writes:

[...]

>>> #+BEGIN_SRC sh
>>> export TEMP=\
>>> "/tmp/guix-build-u-boot-mnt-reform2-2021.06.drv-0"
>>
>> Part of the build environment isolation/reproducibility is that
>> processes inside it always see a build directory ending in ‘-0’, 
>> regardless of the file name on the host system.
>>
>> Kind regards,
>>
>> T G-R
>>
>> [[End of PGP Signed Part]]
>
> This makes sense in general, though I wonder if when using --keep-failed
> if environment-variables should dump out something different, since
> that file is around for debugging, and sourcing it might set up the
> wrong paths I guess?  What do you think?

There’s no good solution I’m afraid.  Directory names within the build
environment must be fixed to ensure reproducibility, as Tobias writes;
yet, the daemon shouldn’t overwrite directories that happen to already
exist in the “real” /tmp.

Thanks,
Ludo’.

bug#50026: Specify a pull-request in --with-branch package transformations

[zimoun]

Hi,

On Tue, 14 Sep 2021 at 09:43, Ludovic Courtès  wrote:
> Philippe SWARTVAGHER  skribis:
>
>> guix build chameleon --with-branch=chameleon=merge-requests/262/head
>> guix build: erreur : impossible de récupérer la branche «
>> merge-requests/262/head » depuis
>> https://gitlab.inria.fr/solverstack/chameleon : cannot locate
>> remote-tracking branch 'origin/merge-requests/262/head'
>> ```
>>
>> While commands stated in the documentation work well:
>>
>> ```bash
>>
>> git clone https://gitlab.inria.fr/solverstack/chameleon && cd chameleon
>> git fetch origin merge-requests/262/head

> Any idea what makes this branches “special” from a Git viewpoint?

I do not know but the branch is not listed after a fresh clone:

--8<---cut here---start->8---
$ git clone https://gitlab.inria.fr/solverstack/chameleon
$ cd chameleon
$ git branch -av
* master   be19cc46 Merge branch 'fix-warning' into 'master'
  remotes/origin/HEAD  -> origin/master
  remotes/origin/masterbe19cc46 Merge branch 'fix-warning' into 'master'
  remotes/origin/release-0.9.2 d2b4cab3 Fix artifact
  remotes/origin/release-1.0.0 da81c248 Update ChangeLog
  remotes/origin/release-1.1.0 4db899ca Merge branch 'next_release' into 
'master'
--8<---cut here---end--->8---

So I guess the GitLab Merge Requests are “special” branches.  Well, I do not 
know
if checking the API makes sense ;-)

   


All the best,
simon

bug#50568: Missing source code

[Ludovic Courtès]

Hi,

Maxime Devos  skribis:

> The Wayback Machine has some copies of software at https://www.atromatic.net:

Thanks, they’re now all in store on berlin.

It’s kinda ironic that it’s the Wayback Machine that’s saving us here…
I wonder if there’s a way to construct generic web.archive.org URLs that
we could use as a fallback in (guix build download)?

Thanks,
Ludo’.

bug#50568: Missing source code

[Ludovic Courtès]

Tobias Geerinckx-Rice  skribis:

> Tobias Geerinckx-Rice via Bug reports for GNU Guix 写道：
>> /gnu/store/prbkg6vldsh1688fsigr33g4s8qla7rl-propeller-gcc-b4f45a4725e0b6d0af59e594c4e3e35ca4105867-checkout.drv
>
> FTR, I don't think this one's actually down.

Oops, indeed, this one’s available.

Thanks,
Ludo’.

bug#50567: [core-updates-frozen] icedtea-6 fails to build.

[Ludovic Courtès]

Hi Guillaume,

Guillaume Le Vaillant  skribis:

> I'm trying to get icedtea-6 to build on the core-updates-frozen branch.
> I fixed a few C/C++ related issues,

Thanks for fixing those!  After 
Julien mentioned on IRC that using an older GCC allowed us to work
around those C++ issues, but your approach looks nicer to me.

> but then I get this error:
>
> Preload failed: checksum of class list was incorrect.
> make: *** [Makefile:2746: stamps/add-archive-ecj.stamp] Error 1

Woow, never seen that.  Julien, Ricardo, does that ring a bell?

Java is the main stumbling block on core-updates-frozen; making
progress!

Thanks,
Ludo’.

bug#50568: Missing source code

[zimoun]

Hi,

On Tue, 14 Sept 2021 at 10:40, Ludovic Courtès  wrote:

> Thanks, they’re now all in store on berlin.

Do we do the usual trick to save them on SWH?

> It’s kinda ironic that it’s the Wayback Machine that’s saving us here…
> I wonder if there’s a way to construct generic web.archive.org URLs that
> we could use as a fallback in (guix build download)?

That would help, I guess. :-)

Cheers,
simon

bug#50568: Missing source code

[pelzflorian (Florian Pelz)]

On Tue, Sep 14, 2021 at 10:38:55AM +0200, Ludovic Courtès wrote:
> Hi,
> 
> Maxime Devos  skribis:
> 
> > The Wayback Machine has some copies of software at 
> > https://www.atromatic.net:
> 
> Thanks, they’re now all in store on berlin.
> 
> It’s kinda ironic that it’s the Wayback Machine that’s saving us here…
> I wonder if there’s a way to construct generic web.archive.org URLs that
> we could use as a fallback in (guix build download)?

AFAIK Just replace the date in

On Mon, Sep 13, 2021 at 03:49:05PM +0200, Maxime Devos wrote:
> https://web.archive.org/web/20161204140455/https://www.astromatic.net/download/stuff/stuff-1.26.0.tar.gz

by the current time.

Regards,
Florian

bug#50523: /etc/timezone should probably have a final newline

[Ludovic Courtès]

Hi,

meedst...@teknik.io skribis:

> This is either an R or Guix bug, but from the discussion at 
> https://community.rstudio.com/t/incomplete-final-line-found-whats-the-big-deal/56536,
>  I infer that files should generally end in a newline anyway.
>
> My bug: every time I start R, I get the following warning, which is 
> unpleasant.
>
> Warning message:
> In readLines("/etc/timezone") :
>   incomplete final line found on '/etc/timezone'

Fixed in 580984f2417853379d98ea927fd95c0f0fbe2c97, thanks!

Ludo’.

bug#50501: packages->manifest can lose the desired package output

[Ludovic Courtès]

Hi,

Liliana Marie Prikler  skribis:

> Am Freitag, den 10.09.2021, 12:34 +0300 schrieb Efraim Flashner:
>> I've been fighting my manifest to try to get "git" and "git:send-
>> email" both included, while using package transformations. For the
>> sake of brevity, here's a stripped down version of my manifest:
>> 
>> (packages->manifest
>>   (map specification->package+output
>> '("git" "git:send-email")))
>> 
>> Here's what I learned from some experimentation:
>> 
>> (cmd)scheme@(guile-user)> (specification->package+output "git:send-
>> email")
>> $14 = #> 7f730e918320>
>> $15 = "send-email"
>> (ins)scheme@(guile-user)> (list (specification->package+output
>> "git:send-email"))
>> $16 = (#> 7f730e918320>)
>> (ins)scheme@(guile-user)> (list (specification->package+output
>> "git"))
>> $17 = (#> 7f730e918320>)
>> 
>> Meanwhile, (specifications->manifest '("git" "git:send-email")) does
>> actually return a manifest with both the "out" and the "send-email"
>> outputs of git.
>> 
>> (package->manifest-entry (specification->package+output "git:send-
>> email"))
>> returns a manifest entry for "git:out" and
>> (package->manifest-entry git "send-email") returns a manifest entry
>> for
>> "git:send-email".
> I think for this use of specification->package+output you need to
> compose it with list like (compose list specification->package+output). 
> The reason you observe this behaviours is that specification-
>>package+output returns multiple values, whereas package->manifest-
> entry expects a single value which is either a package or a list of the
> form (package "output").

Yes, and Guile truncates multiple-value returns by default:

--8<---cut here---start->8---
scheme@(guile-user)> (list (values 1 2))
$7 = (1)
scheme@(guile-user)> (+ (values 1 2) 2)
$8 = 3
--8<---cut here---end--->8---

Ludo’.

bug#43130: mailutils-3.10 test phase

[zimoun]

Hi,

On Mon, 05 Jul 2021 at 10:56, zimoun  wrote:
> On Sun, 13 Dec 2020 at 15:37, Leo Famulari  wrote:
>> On Mon, Aug 31, 2020 at 01:18:32PM +0600, Vladimir K wrote:
>
>>> ## - ##
>>> ## Test results. ##
>>> ## - ##
>>>
>>> 2 tests were successful.
>>> 1 test was skipped.
>>>
>>> command "make" "check" failed with status 2
>>
>> Hm, I don't see where it failed?
>>
>> The package appears to build successfully now. Are you still having
>> trouble with it?
>
> Using Guix 3694c0d, it builds fine on x86_64 and
>
>   guix build --no-grafts --system=i686-linux mailutils
>
> also builds fine.  What is your arch?  Do you still have the issue?

After 10 weeks asking moreinfo, I am closing.  Feel free to reopen if I
miss a point.


All the best,
simon

bug#28554: teeworlds not starting

[zimoun]

Hi,

On Mon, 05 Jul 2021 at 13:21, zimoun  wrote:
> On Fri, 22 Sep 2017 at 15:19, mray  wrote:
>> Running guix on ubuntu 17.04 teeworlds does not start.
>>
>> $ teeworlds
>> [59c505a6][engine]: running on unix-linux-amd64
>
> [...]
>
>> [59c505a6][client]: starting...
>> libGL error: No matching fbConfigs or visuals found
>> libGL error: failed to load driver: swrast
>> X Error of failed request:  BadValue (integer parameter out of range for
>> operation)
>>   Major opcode of failed request:  154 (GLX)
>>   Minor opcode of failed request:  3 (X_GLXCreateContext)
>>   Value in failed request:  0x0
>>   Serial number of failed request:  32
>>   Current serial number in output stream:  33
>
> It works using Guix 3694c0d on the top of (default) Ubuntu.  Which kind
> of hardware do you have?

No more info after 10 weeks, so closing.  Feel free to reopen if I miss
a point.

All the best,
simon

bug#25752: go incremental builds broken

[zimoun]

Hi,

On Fri, 18 Dec 2020 at 16:31, Leo Famulari  wrote:
> On Fri, Dec 18, 2020 at 09:00:14PM +0100, zimoun wrote:
>> I suspect closing this bug had been forgotten.  If yes, feel free to
>> close it.  Otherwise, I do not understand what is the next actionable
>> step.
>
> I don't think this bug has been fixed, although I have not checked.
> Currently, Go incremental builds and library re-use is not functional in
> Guix, unless I missed a new development.

What is the status of this bug?  Since I am not using Go at all, it is
hard for me to have a reproducer.  Is it possible to provide a
reproducer?  Thanks.

Cheers,
simon

PS: I asked the same thing 13 weeks ago.  Therefore, without any answer
and giving this bug is really old not so much commented, I propose to
close it.

bug#50580: GDM doesn't start

[Maxime Devos]

Hi,

The GDM service doesn't start anymore.  To test, you can use the attached
xorg-repro.tmpl (guix system vm xorg-repro.tml && run the resulting script).
QEMU will start, and it will start booting, but nothing graphical will start.
If you switch to the last virtual terminal, you will see

[date] localhost shepherd[1]: Respawning xorg-server.
[date] localhost shepherd[1]: Service host-name has been started.
[date] localhost shepherd[1]: Service xorg-server has been started.
[date] localhost shepherd[1]: Respawning xorg-server.
[date] localhost shepherd[1]: Service host-name has been started.
[date] localhost shepherd[1]: Service xorg-server has been started.
[date] localhost shepherd[1]: Respawning xorg-server.
[date] localhost shepherd[1]: Service host-name has been started.
[date] localhost shepherd[1]: Service xorg-server has been started.
[date] localhost shepherd[1]: Respawning xorg-server.
[date] localhost shepherd[1]: Service host-name has been started.
[date] localhost shepherd[1]: Service xorg-server has been started.
[date] localhost shepherd[1]: Respawning xorg-server.
[date] localhost shepherd[1]: Service host-name has been started.
[date] localhost shepherd[1]: Service xorg-server has been started.
[date] localhost shepherd[1]: Respawning xorg-server.
[date]
localhost shepherd[1]: Service host-name has been started.
[date] localhost shepherd[1]: Service xorg-server has been started.
[date] localhost shepherd[1]:   (Respawning too fast.)

GDM used to work for me with commit 75a3413b4e5c1f7443eb944a36ff364f4c4085f4,
but was broken with e9b87da1c3000c53cf9dbf5e737aa4d6546bd909.  To be bisected?

Greetings,
Maxime.

(xorg-repro.templ is based on the vm-image.tmpl configuration)
;; This is an operating system configuration for a VM image.
;; Modify it as you see fit and instantiate the changes by running:
;;
;;   guix system reconfigure /etc/config.scm
;;

(use-modules (gnu) (guix) (srfi srfi-1))
(use-service-modules desktop mcron networking spice ssh xorg)
(use-package-modules bootloaders certs fonts nvi
 package-management wget xorg)

(define vm-image-motd (plain-file "motd" "
\x1b[1;37mThis is the GNU system.  Welcome!\x1b[0m

This instance of Guix is a template for virtualized environments.
You can reconfigure the whole system by adjusting /etc/config.scm
and running:

  guix system reconfigure /etc/config.scm

Run '\x1b[1;37minfo guix\x1b[0m' to browse documentation.

\x1b[1;33mConsider setting a password for the 'root' and 'guest' \
accounts.\x1b[0m
"))

;;; XXX: Xfce does not implement what is needed for the SPICE dynamic
;;; resolution to work (see:
;;; https://gitlab.xfce.org/xfce/xfce4-settings/-/issues/142).  Workaround it
;;; by manually invoking xrandr every second.
#;
(define auto-update-resolution-crutch
  #~(job '(next-second)
 (lambda ()
   (setenv "DISPLAY" ":0.0")
   (setenv "XAUTHORITY" "/home/guest/.Xauthority")
   (execl (string-append #$xrandr "/bin/xrandr") "xrandr" "-s" "0"))
 #:user "guest"))

(operating-system
  (host-name "gnu")
  (timezone "Etc/UTC")
  (locale "en_US.utf8")
  (keyboard-layout (keyboard-layout "us" "altgr-intl"))

  ;; Label for the GRUB boot menu.
  (label (string-append "GNU Guix " (package-version guix)))

  (firmware '())

  ;; Below we assume /dev/vda is the VM's hard disk.
  ;; Adjust as needed.
  (bootloader (bootloader-configuration
   (bootloader grub-bootloader)
   (targets '("/dev/vda"))
   (terminal-outputs '(console
  (file-systems (cons (file-system
(mount-point "/")
(device "/dev/vda1")
(type "ext4"))
  %base-file-systems))

  (users (cons (user-account
(name "guest")
(comment "GNU Guix Live")
(password "") ;no password
(group "users")
(supplementary-groups '("wheel" "netdev"
"audio" "video")))
   %base-user-accounts))

  ;; Our /etc/sudoers file.  Since 'guest' initially has an empty password,
  ;; allow for password-less sudo.
  (sudoers-file (plain-file "sudoers" "\
root ALL=(ALL) ALL
%wheel ALL=NOPASSWD: ALL\n"))

  (services
   (append (list (service xfce-desktop-service-type)

 ;; Uncomment the line below to add an SSH server.
 ;;(service openssh-service-type)

 ;; Add support for the SPICE protocol, which enables dynamic
 ;; resizing of the guest screen resolution, clipboard
 ;; integration with the host, etc.
 ;;(service spice-vdagent-service-type)

 ;;(simple-service 'cron-jobs mcron-service-type
 ;;(list auto-update-resolution-crutch))

 ;; Use the DHCP client service rather than NetworkManager.
 (service dhcp-client-s

bug#47630: Improve guix manual installation docs

[zimoun]

Hi,

On Tue, 17 Aug 2021 at 23:28, zimoun  wrote:
> On Thu, 15 Jul 2021 at 12:56, bo0od  wrote:
>>> Could you propose a concrete wording solving
>>> the issues you see
>>
>> Not really because english is not my mother tongue so there going to be 
>> errors
>> in grammars, choosing of words..etc so better to be written by someone who 
>> has
>> better english than me.
>>
>> But for the commands to go on step by step i can give that with little text
>> and any webadmin can pick it up and arrange it accordingly.
>>
>> If guix documentation built on wikimedia it would be much easier because i 
>> can
>> register and upload my changes and can be reviewed and updated, But using
>> email for this is not the best way to achieve it but what to do..
>
> Maybe you could provide what you find missing and where in the manual,
> with little text.  It should be a good start for pointing what and how
> to improve.

I plan to close this report if there is no concrete patch attached.
Because personally I do not see what could be done.

All the best,
simon

bug#42091: mesa-20.0.8 fails during testing: preprocessor error: syntax error, unexpected end of file

[zimoun]

Hi,

On Mon, 05 Jul 2021 at 12:51, zimoun  wrote:

> Thanks for the report and sorry for the delay.
>
> The package ’mesa’ is now at 20.2.4 using Guix 3694c0d.  The package
> builds and the substitute is available.
>
> How is it going for you?

After 10 weeks asking moreinfo, I am closing.  Feel free to reopen if I
miss something.

All the best,
simon

bug#50264: ca-certificate-bundle fails to build

[Ludovic Courtès]

Hi,

Lars-Dominik Braun  skribis:

> Failure:
> /gnu/store/kxkxji6m101ylgpa82jmxvmy5szpvk1k-ca-certificate-bundle.drv
> /gnu/store/wahy9p8985vbcibwwjk3p73hxh82f90v-ca-certificate-bundle-builder
>
> Success:
> /gnu/store/rx6pqcpgwcyl6spfi8acgjzksrpqhac1-ca-certificate-bundle.drv
> /gnu/store/wahy9p8985vbcibwwjk3p73hxh82f90v-ca-certificate-bundle-builder
>
> (Yes, exactly the same builder input hash. I double-checked.)

As discussed on IRC, I stumbled upon this bug while running:

  ./pre-inst-env guix system vm gnu/system/examples/desktop.tmpl

on commit 580984f2417853379d98ea927fd95c0f0fbe2c97.

The first attempt downloaded lots of substitutes and produced, as in
your case, a broken ca-certificate-bundle.drv: the ‘-builder’ script is
correct, but there are only ~80 derivation inputs instead of ~230.

The second run right after that produced the correct
ca-certificate-bundle.drv: same ‘-builder’ script, but all the
derivation inputs were there, including glibc-utf8-locales.drv.

I’ve tried to reproduce it running GC during or before the command, to
no avail so far.  If someone has an easy and reliable way to reproduce
it, please share!

I don’t have a good hypothesis so far as to where things go wrong…

Ludo’.

bug#44187: [PATCH 0/3] Fall back to Software Heritage (SWH) for Git clones

[Ludovic Courtès]

Hello,

zimoun  skribis:

> Cool!  However, the patch does not apply on the top of 53f54d4aa2.
> That's why the option '--base' of "git format-patch" is really helpful. ;-)

Ah!  It should apply on top of ff613c2b68aac539262822490448e637d8f315ba.

If not, I can rebase it and send an updated patch (I’ve been fiddling
with code in this area lately…).

Thanks,
Ludo’.

bug#50557: Unable to access remote logs

[Ludovic Courtès]

Salut Mathieu,

Mathieu Othacehe  skribis:

>> Mathieu, can you think of a way we could address this?  Maybe Cuirass
>> could handle those /log URLs since it already has build log URLs anyway?
>
> I fixed it with 60190401ce4ccc890629ec3cb22a84a8ab8c2645 in Cuirass and
> abaf1392287d50a7225cdb3e3f3f8b82b827c7db in maintenance.
>
> I now have:
>
> mathieu@meije ~$ guix build emacs --log-file --no-grafts
> https://ci.guix.gnu.org/log/g24hw5dv5k89wqs83457xmjbd56whkab-emacs-27.2

That was quick, thanks a lot!

Ludo’.

bug#25667: Status? store refs in ~/.config/xfce4

[zimoun]

Hi Efraim,

On Tue, 05 May 2020 at 09:10, Efraim Flashner  wrote:
> On Mon, May 04, 2020 at 10:30:11PM +0200, Thomas Danckaert wrote:
>> I switched to gnome shortly after that, but I see Efraim has already
>> answered and the issue is still there.
>
> Looking at the list again, I think what happened was special care needs
> to be taken adding programs to the quick launch bar at the bottom of the
> screen. As for the background images, I'm guessing that each time xfce
> launches, if the references to the previous images are gone then it adds
> a new one. If that's the case then the background images are fixing
> themselves and the shortcuts face the same 'buyer beware' as any other
> shortcut created.

Thanks for the explanations.  I miss what is the next action to fix the
issue.  What could it be done?

Cheers,
simon

bug#24028: Linux-libre kernel does not build deterministically

[zimoun]

Hi,

On Fri, 09 Oct 2020 at 17:17, Maxim Cournoyer  wrote:
> l...@gnu.org (Ludovic Courtès) writes:
>
>> As of version 4.6.4, Linux-libre does not build reproducibly:
>>
>> $ guix challenge linux-libre
>> /gnu/store/wkdnd1dcgljr0jxmd3li8j0qsr2zwrci-linux-libre-4.6.4 contents 
>> differ:
>>   local hash: 1py214sd42qcq8l429m4zf4aibp8rl68kpkrzqi1nn65vnbxsx11
>>   
>> https://hydra.gnu.org/nar/wkdnd1dcgljr0jxmd3li8j0qsr2zwrci-linux-libre-4.6.4:
>> 19hsdsjy5i9nfc1g28s074znzimzhylgkdpwz435j301sn9pxxp9
>> $ wget -q -O -
>> https://hydra.gnu.org/nar/wkdnd1dcgljr0jxmd3li8j0qsr2zwrci-linux-libre-4.6.4
>> | bunzip2 | guix archive -x t
>> $ diff -ur --no-dereference 
>> /gnu/store/wkdnd1dcgljr0jxmd3li8j0qsr2zwrci-linux-libre-4.6.4 /tmp/t
>> Binary files 
>> /gnu/store/wkdnd1dcgljr0jxmd3li8j0qsr2zwrci-linux-libre-4.6.4/bzImage and 
>> /tmp/t/bzImage differ
>>
>> Apparently people are working on it:
>> .
>
> I just tested with linux-libre 5.8.10, and it still suffers from
> reproducibility problems, but only for one file:
>
> diff -r 
> /gnu/store/jc1dydmax5sdfljpi5mq5dhq9wdr92xy-linux-libre-5.8.10{,-check}
> Binary files 
> /gnu/store/jc1dydmax5sdfljpi5mq5dhq9wdr92xy-linux-libre-5.8.10/bzImage and 
> /gnu/store/jc1dydmax5sdfljpi5mq5dhq9wdr92xy-linux-libre-5.8.10-check/bzImage 
> differ

Still the same issue with 5.13.15.

diff -r --no-dereference 
/gnu/store/y9r7physjpa23znb7r6rg38wpmxrkp0s-linux-libre-5.13.15{,-check}
Binary files 
/gnu/store/y9r7physjpa23znb7r6rg38wpmxrkp0s-linux-libre-5.13.15/bzImage and 
/gnu/store/y9r7physjpa23znb7r6rg38wpmxrkp0s-linux-libre-5.13.15-check/bzImage 
differ


All the best,
simon

bug#25415: MySQL "server has gone away" when reloading database dump due to "max_allowed_packet" default

[zimoun]

Hi,

Sorry for the delay about this old bug#25415 [1].

1: 

On Fri, 13 Jan 2017 at 10:29, Ben Sturmfels  wrote:
> On 13/01/17 01:22, Ludovic Courtès wrote:
>
>>> Could it be worth setting max_allowed_packet to 16M in Guix's
>>> `mysql-configuration-file` function for consistency with Debian?
>>
>> Definitely.  I would add a ‘max-allowed-packet’ field in
>>  in (gnu services databases) and make sure it’s
>> honored.
>>
>> Would you like to give it a try?
>
> Sure, I'll give it a shot!
>
> It looks as though the MariaDB source comes with a settings file for
> Debian that includes max-allowed-packet=16M:
>
>   mariadb-XX.XX.XX/debian/additions/my.cnf
>
> Would you recommend adding just max-allowed-packet, or would it be worth
> applying all these settings in this file?

Well, anything that suits you. :-)  Could you send a patch if it is
relevant?

All the best,
simon

bug#31789: nss-mdns test is failing

[Clément Lassieur]

Hello Sarah, thank you for taking care of these old bugs!

I can't replicate this one either.  Closing.

Clément

On Mon, Sep 13, 2021, at 9:43 AM, Sarah Morgensen wrote:
> Hello,
> 
> Thanks for the report.  Apologies that it's taken two years (!) for a
> response.  I can not replicate this; does this still occur for you?
> 
> Clément Lassieur  writes:
> 
> > nss-mdns test is failing.  Here is the output:
> >
> >  Starting test avahi
> > Group begin: avahi
> > Test begin:
> >   test-name: "wait for services"
> >   source-file: 
> > "/gnu/store/b5gvmlh78s40xvxq73dpdqr7sv0skhmy-nss-mdns-builder"
> >   source-line: 1
> >   source-form: (test-assert "wait for services" (marionette-eval (quote 
> > (begin (use-modules (gnu services herd)) (start-service (quote nscd)) (let 
> > ((sock (socket PF_UNIX SOCK_STREAM 0))) (let try () (catch (quote 
> > system-error) (lambda () (connect sock AF_UNIX "/var/run/nscd/socket") 
> > (close-port sock) (format #t "nscd is ready~%")) (lambda args (format #t 
> > "waiting for nscd...~%") (usleep 50) (try) (start-service (quote 
> > avahi-daemon)) (start-service (quote networking)) #t)) marionette))
> > Test end:
> >   result-kind: pass
> >   actual-value: #t
> > Test begin:
> >   test-name: "avahi-resolve-host-name"
> >   source-file: 
> > "/gnu/store/b5gvmlh78s40xvxq73dpdqr7sv0skhmy-nss-mdns-builder"
> >   source-line: 1
> >   source-form: (test-equal "avahi-resolve-host-name" 0 (marionette-eval 
> > (quote (system* "/run/current-system/profile/bin/avahi-resolve-host-name" 
> > "-v" "komputilo.local")) marionette))
> > Test end:
> >   result-kind: pass
> >   actual-value: 0
> >   expected-value: 0
> > Test begin:
> >   test-name: "avahi-browse"
> >   source-file: 
> > "/gnu/store/b5gvmlh78s40xvxq73dpdqr7sv0skhmy-nss-mdns-builder"
> >   source-line: 1
> >   source-form: (test-equal "avahi-browse" 0 (marionette-eval (quote 
> > (system* "avahi-browse" "-avt")) marionette))
> > Test end:
> >   result-kind: pass
> >   actual-value: 0
> >   expected-value: 0
> > Test begin:
> >   test-name: "getaddrinfo .local"
> >   source-file: 
> > "/gnu/store/b5gvmlh78s40xvxq73dpdqr7sv0skhmy-nss-mdns-builder"
> >   source-line: 1
> >   source-form: (test-assert "getaddrinfo .local" (match (marionette-eval 
> > (quote (getaddrinfo "komputilo.local")) marionette) (((? vector? addrinfos) 
> > ..1) (pk (quote getaddrinfo) addrinfos) (and (any (lambda (ai) (= AF_INET 
> > (addrinfo:fam ai))) addrinfos) (any (lambda (ai) (= AF_INET6 (addrinfo:fam 
> > ai))) addrinfos)
> > Test end:
> >   result-kind: fail
> >   actual-value: #f
> >   actual-error: (match-error "match" "no matching pattern" #f)
> > Test begin:
> >   test-name: "gethostbyname .local"
> >   source-file: 
> > "/gnu/store/b5gvmlh78s40xvxq73dpdqr7sv0skhmy-nss-mdns-builder"
> >   source-line: 1
> >   source-form: (test-assert "gethostbyname .local" (match (pk (quote 
> > gethostbyname) (marionette-eval (quote (gethostbyname "komputilo.local")) 
> > marionette)) ((? vector? result) (and (string=? (hostent:name result) 
> > "komputilo.local") (= (hostent:addrtype result) AF_INET)
> > Test end:
> >   result-kind: fail
> >   actual-value: #f
> >   actual-error: (match-error "match" "no matching pattern" #f)
> > Group end: avahi
> > # of expected passes  3
> > # of unexpected failures  2
> 
> --
> Sarah
> 

bug#25667: Status? store refs in ~/.config/xfce4

[Efraim Flashner]

On September 14, 2021 11:37:10 AM UTC, zimoun  wrote:
>Hi Efraim,
>
>On Tue, 05 May 2020 at 09:10, Efraim Flashner  wrote:
>> On Mon, May 04, 2020 at 10:30:11PM +0200, Thomas Danckaert wrote:
>>> I switched to gnome shortly after that, but I see Efraim has already
>>> answered and the issue is still there.
>>
>> Looking at the list again, I think what happened was special care needs
>> to be taken adding programs to the quick launch bar at the bottom of the
>> screen. As for the background images, I'm guessing that each time xfce
>> launches, if the references to the previous images are gone then it adds
>> a new one. If that's the case then the background images are fixing
>> themselves and the shortcuts face the same 'buyer beware' as any other
>> shortcut created.
>
>Thanks for the explanations.  I miss what is the next action to fix the
>issue.  What could it be done?
>
>Cheers,
>simon

I forgot all about this issue. Given that I haven't really seen it pop up on 
IRC I think I'd close it as "won't fix". I can't see good things coming from 
reaching into people's home directories. Maybe if there's some default 
applications those could be patched in the xfce package to make sure it doesn't 
bite those who don't have that folder yet.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

bug#47630: Improve guix manual installation docs

[bo0od]

Fix the documentation as steps works for the end user as if he follow it 
1 by 1 copy/paste (similar to nix docs as example), Otherwise current 
steps in the docs just junk to the end user. (you dont expect users to 
know and finish steps themselves)


zimoun:

Hi,

On Tue, 17 Aug 2021 at 23:28, zimoun  wrote:

On Thu, 15 Jul 2021 at 12:56, bo0od  wrote:

Could you propose a concrete wording solving
the issues you see


Not really because english is not my mother tongue so there going to be errors
in grammars, choosing of words..etc so better to be written by someone who has
better english than me.

But for the commands to go on step by step i can give that with little text
and any webadmin can pick it up and arrange it accordingly.

If guix documentation built on wikimedia it would be much easier because i can
register and upload my changes and can be reviewed and updated, But using
email for this is not the best way to achieve it but what to do..


Maybe you could provide what you find missing and where in the manual,
with little text.  It should be a good start for pointing what and how
to improve.


I plan to close this report if there is no concrete patch attached.
Because personally I do not see what could be done.

All the best,
simon

bug#47630: Improve guix manual installation docs

[zimoun]

Hi,

On Tue, 14 Sept 2021 at 16:51, bo0od  wrote:

> Fix the documentation as steps works for the end user as if he follow it
> 1 by 1 copy/paste (similar to nix docs as example), Otherwise current
> steps in the docs just junk to the end user. (you dont expect users to
> know and finish steps themselves)

I proposed you to write down these steps as a starting point for
improving the manual to turn it into a patch (for the Manual or the
Cookbook); this is actionable.  Otherwise say « improve this part of
the manual » is not constructive; this is not actionable.  I (and
probably others) do not see what could be improved in this area so it
appears to me hard to improve something that I do not know what. :-)

Last, the manual says:

This option requires familiarity with GNU/Linux, with the shell,
and with common administration tools. If you think this is not
for you, consider using the guided graphical installer.



Therefore, it appears to me expected that this section provides only
command hints and not one by one step to complete all the process.
Other said, I expect that user who does not know how to fully complete
will run the Graphical Installer.  Does Nix have a Graphical
Installer?


All the best,
simon

bug#50264: ca-certificate-bundle fails to build

[Leo Famulari]

On Tue, Sep 14, 2021 at 03:08:19PM +0200, Ludovic Courtès wrote:
> Hi,
> 
> Lars-Dominik Braun  skribis:
> 
> > Failure:
> > /gnu/store/kxkxji6m101ylgpa82jmxvmy5szpvk1k-ca-certificate-bundle.drv
> > /gnu/store/wahy9p8985vbcibwwjk3p73hxh82f90v-ca-certificate-bundle-builder
> >
> > Success:
> > /gnu/store/rx6pqcpgwcyl6spfi8acgjzksrpqhac1-ca-certificate-bundle.drv
> > /gnu/store/wahy9p8985vbcibwwjk3p73hxh82f90v-ca-certificate-bundle-builder
> >
> > (Yes, exactly the same builder input hash. I double-checked.)
> 
> As discussed on IRC, I stumbled upon this bug while running:
> 
>   ./pre-inst-env guix system vm gnu/system/examples/desktop.tmpl
> 
> on commit 580984f2417853379d98ea927fd95c0f0fbe2c97.
> 
> The first attempt downloaded lots of substitutes and produced, as in
> your case, a broken ca-certificate-bundle.drv: the ‘-builder’ script is
> correct, but there are only ~80 derivation inputs instead of ~230.
> 
> The second run right after that produced the correct
> ca-certificate-bundle.drv: same ‘-builder’ script, but all the
> derivation inputs were there, including glibc-utf8-locales.drv.
> 
> I’ve tried to reproduce it running GC during or before the command, to
> no avail so far.  If someone has an easy and reliable way to reproduce
> it, please share!
> 
> I don’t have a good hypothesis so far as to where things go wrong…

I wonder if the problem began after the introduction of
bordeaux.guix.gnu.org, and if everyone who experiences the bug is using
both substitute servers.

I can't imagine what the actual problem is, but it does sound like the
dependency graph has somehow diverged...

bug#50587: MySQL not reproducible

[zimoun]

Hi,

Using Guix 53f54d4, the package ’mysql’ is not reproducible:

--8<---cut here---start->8---
$ diff -r --no-dereference 
/gnu/store/wm96qznqwrjangxf14blmsgzc9i4hmgl-mysql-5.7.33{,-check}
diff -r --no-dereference 
/gnu/store/wm96qznqwrjangxf14blmsgzc9i4hmgl-mysql-5.7.33/share/mysql/docs/INFO_BIN
 
/gnu/store/wm96qznqwrjangxf14blmsgzc9i4hmgl-mysql-5.7.33-check/share/mysql/docs/INFO_BIN
2c2
< Build was run at 2021-04-19 07:19:52 on host 'unknown'
---
> Build was run at 2021-09-14 15:57:25 on host 'unknown'
4c4
< Build was done on  Linux-5.10.16-gnu using x86_64
---
> Build was done on  Linux-5.4.0-26-generic using x86_64
28c28
< DEB_CHANGELOG_TIMESTAMP:STRING=Mon, 19 Apr 2021 07:16:23 +
---
> DEB_CHANGELOG_TIMESTAMP:STRING=Tue, 14 Sep 2021 15:55:17 +
--8<---cut here---end--->8---


All the best,
simon

bug#23045: mysql_config missing references to sed and gawk

[zimoun]

Hi,

On Thu, 17 Mar 2016 at 15:52, "Thompson, David"  
wrote:
> The mysql_config binary in the mysql package needs sed and gawk to be
> on $PATH in order to run.  Instead, it should be patched to hardcode
> the store paths to sed and gawk.

Indeed, it is still the case with Guix 53f54d4:

--8<---cut here---start->8---
$ guix environment --ad-hoc mysql -C
[env]$ mysql_config
/gnu/store/babgwy3cvv851ddx7npvh9ick3fs0fgc-profile/bin/mysql_config: line 87: 
sed: command not found
/gnu/store/babgwy3cvv851ddx7npvh9ick3fs0fgc-profile/bin/mysql_config: line 95: 
sed: command not found
/gnu/store/babgwy3cvv851ddx7npvh9ick3fs0fgc-profile/bin/mysql_config: line 99: 
sed: command not found
/gnu/store/babgwy3cvv851ddx7npvh9ick3fs0fgc-profile/bin/mysql_config: line 131: 
cat: command not found
--8<---cut here---end--->8---

or another example:

--8<---cut here---start->8---
$ cat $GUIX_ENVIRONMENT/bin/mysql_config | grep awk
file=`ls -l $file | awk '{ print $NF }'`
--8<---cut here---end--->8---

and the package definition of ’mysql’ reads:

--8<---cut here---start->8---
(native-inputs
 `(("bison" ,bison)
   ("perl" ,perl)
   ("pkg-config" ,pkg-config)))
(inputs
 `(("boost" ,boost-for-mysql)
   ("libaio" ,libaio)
   ("libtirpc" ,libtirpc)
   ("ncurses" ,ncurses)
   ("openssl" ,openssl)
   ("rpcsvc-proto" ,rpcsvc-proto) ; rpcgen
   ("zlib" ,zlib)))
--8<---cut here---end--->8---

To make it works, the packages ’coreutils’, ’sed’ and ’gawk’ should be
propagated.  Right?

Could you comment on patch#50586 [1]?  It should fix the issue.

1: 

All the best,
simon

bug#27310: Enlightenment: Wallpaper Settings are unable to import custom pictures

[zimoun]

Hi,

On Sat, 10 Jun 2017 at 14:33, ng0  wrote:
> In 'wallpaper settings' in Enlightenment trying to use a custom picture
> (with 'Use Theme Wallpaper' unchecked)
> as wallpaper currently produces this error message:

What is the status of this old bug#27310 [1]?  Is someone reproducing?
Or can someone provide more info?

Thanks,
simon

1: 

bug#50567: [core-updates-frozen] icedtea-6 fails to build.

[Guillaume Le Vaillant]

Ludovic Courtès  skribis:

> Hi Guillaume,
>
> Guillaume Le Vaillant  skribis:
>
>> I'm trying to get icedtea-6 to build on the core-updates-frozen branch.
>> I fixed a few C/C++ related issues,
>
> Thanks for fixing those!  After 
> Julien mentioned on IRC that using an older GCC allowed us to work
> around those C++ issues, but your approach looks nicer to me.
>
>> but then I get this error:
>>
>> Preload failed: checksum of class list was incorrect.
>> make: *** [Makefile:2746: stamps/add-archive-ecj.stamp] Error 1
>
> Woow, never seen that.  Julien, Ricardo, does that ring a bell?
>
> Java is the main stumbling block on core-updates-frozen; making
> progress!
>
> Thanks,
> Ludo’.

It looks like the checksum failure is caused by the miscompilation of
a multiplication in the function computing the checksum.
I added a workaround to the other fixes in
f8cff361245cc0c546211ff51100cbaf869d15eb, which makes the build succeed.


signature.asc
Description: PGP signature

bug#27447: pelican-quickstart produces files with store path shebangs

[zimoun]

Hi Mark,

On Thu, 14 Jan 2021 at 18:00, Mark H Weaver  wrote:
> zimoun  writes:

>> --8<---cut here---start->8---
>> $ guix environment -C --ad-hoc pelican coreutils grep
>> [env]$ mkdir foo && cd foo && ls -l
>> total 0
>>
>> [env]$ pelican-quickstart
>> Welcome to pelican-quickstart v4.2.0.
>>
>> This script will help you create a new Pelican-based website.
>>
>> Please answer the following questions so this script can generate the files
>> needed by Pelican.
>>
>>
>>> Where do you want to create your new web site? [.]
>>> What will be the title of this web site? Foo
>>> Who will be the author of this web site? zimoun
>>> What will be the default language of this web site? [en]
>>> Do you want to specify a URL prefix? e.g., https://example.com   (Y/n) n
>>> Do you want to enable article pagination? (Y/n) n
>>> What is your time zone? [Europe/Paris]
>>> Do you want to generate a tasks.py/Makefile to automate generation and 
>>> publishing? (Y/n) y
>>> Do you want to upload your website using FTP? (y/N) N
>>> Do you want to upload your website using SSH? (y/N) N
>>> Do you want to upload your website using Dropbox? (y/N) N
>>> Do you want to upload your website using S3? (y/N) N
>>> Do you want to upload your website using Rackspace Cloud Files? (y/N) N
>>> Do you want to upload your website using GitHub Pages? (y/N) N
>> Done. Your new project is available at /tmp/bar
>>
>> [env]$ ls
>> Makefile  content  output  pelicanconf.py  publishconf.py  tasks.py
>>
>> [env]$ egrep -nr "store"
>> pelicanconf.py:1:#!/gnu/store/h8jw9qhyfp6fm6nb3cgh4335qhr31wfz-python-wrapper-3.8.2/bin/python
>> publishconf.py:1:#!/gnu/store/h8jw9qhyfp6fm6nb3cgh4335qhr31wfz-python-wrapper-3.8.2/bin/python
>> --8<---cut here---end--->8---
>>
>> Why is it a bug?
>
> It's a bug because these absolute file names will cease to exist after
> the next 'core-updates' merge happens, and more precisely after the
> older system generations (or user profiles) are deleted and 'guix gc'
> subsequently deletes these obsolete store items.
>
> At that point, maybe things will break.  I think that would need to be
> investigated before dismissing this bug report.

I still miss why it is a bug.  The script ’pelican-quickstart’ is an
*helper* to generate this configuration file ’pelicancon.py’.
Therefore, the user should review it, IMHO.

Let consider this scenario:

1. guix install pelican
2. pelican-quickstart
3. guix pull
4. guix upgrade
5. guix gc

At step #2, the generated configuration file is in agreement with the
Python interpreter.  Then, I agree that this Python could be gone after
the GC.

However, there is no guarantee that the generated configuration file at
step #2 still works with the potentially upgraded Pelican version (step
#4); independently of the shebang issue we are speaking.

Somehow, it is the responsibility of the user to maintain their
configuration file across the Pelican versions.

Well, considering my previous words [1],

Why does embed store paths in configuration files is an issue?
Pelican is a Python application which therefore requires a
Python interpreter.  Running ’pelican’ against another Python VM
than the one it was built seems a bad idea.

And if the point is run “pelican-quickstart” with one Pelican
version built against one Python VM, and then reuse these
generated config files with another Pelican version built
against another Python VM, in this use-case, the bug is upstream
because it embeds absolute path which does not respect PEP 394
[2].

I still think the bug is upstream.  Anyway.  The point is to resolve
and close this report. ;-)

First, I am not sure Pelican is a lot run by Guix users.  The version
4.2.0 seems from Oct. 2019 and the last upstream version is 4.6 from
March 2021.  Running,

  $ ./pre-inst-env guix refresh -u pelican
  $ ./pre-inst-env guix environment -C --ad-hoc pelican \
-- pelican-quickstart

does not fix the issue. (Maybe I will submit the resulting update,
separately.)


Second, do we patch Pelican to remove?  If yes, these absolute file
names in the generated configuration file should be replaced by what?


Cheers,
simon

1: 
2: 

bug#50592: Can't guix system init with grub-efi-bootloader from system that boots using grub-bootloader

[Zacchaeus Scheffer]

Hi Guix!

I'm trying to install guix to a new drive using my main machine which boots
using grub-bootloader (legacy bios).  I want to put grub-efi-bootloader
(EFI) on the new drive install (for use on another computer).  However, the
install fails when running grub-install.  The full output at the end is:

copying to '/mnt/jake'...
populating '/mnt/jake'...
guix system: error:
'/gnu/store/w8v5d1i6xfqlpj78w89jg1x7f8dchh4k-grub-efi-2.06/sbin/grub-install
--boot-directory /mnt/jake/boot --bootloader-id=Guix --efi-directory
/boot/efi' exited with status 1; output follows:


/gnu/store/w8v5d1i6xfqlpj78w89jg1x7f8dchh4k-grub-efi-2.06/sbin/grub-install:
error:
/gnu/store/w8v5d1i6xfqlpj78w89jg1x7f8dchh4k-grub-efi-2.06/lib/grub/i386-pc/modinfo.sh
doesn't exist. Please specify --target or --directory.

I'm not sure if the fact that I'm currently booted in legacy bios mode is
important, but the problem persists after a guix pull && guix
system reconfigure, and I doubt grub-efi is broken for everyone.

Thanks,
zacchae

bug#50591: GuixOS graphical installation bug

[allen diaz]

Hello,
The irc told me to file a bug here.
I tried installing guix via the graphical installer on my librebooted x200 
thinkpad.
  Currently it has Linux mint installed which contains 3 partitions (the only 
iso I had on hand when librebooting).  For some reason mint added an efi 
partition despite my machine not using efi but that’s what’s there.  
  I used both the latest release installer and the latest version from the gnu 
guix website.  The actual bug was that when I clicked on partition, whether 
manual or otherwise, it returned me all the way the beginning of the ncurses 
menu. This happened on both isos.
  I’m okay with partitioning my own disk if needed, I just don’t know guile 
enough to make my own config file yet so I’m trying to avoid the initial 
writing.
Cheers
crazychicken

bug#50592: Acknowledgement (Can't guix system init with grub-efi-bootloader from system that boots using grub-bootloader)

[Zacchaeus Scheffer]

I should probably give some more details.  Here is the bootloader config
I'm using

 (bootloader
  (bootloader-configuration
   (bootloader grub-efi-bootloader)
   (targets (list "/boot/efi"))
   (keyboard-layout keyboard-layout)))

My mounts look like:
/dev/mapper/jake /mnt/jake # with -o subvol=guix
/dev/mapper/jake /mnt/jake/swap # with -o subvol=swap
/dev/sdb2 /mnt/jake/boot/efi

I've been using the same system config without problem, and just changed
the bootloader config to the above

-zacchaeus

On Tue, Sep 14, 2021 at 6:34 PM GNU bug Tracking System <
help-debb...@gnu.org> wrote:

> Thank you for filing a new bug report with debbugs.gnu.org.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  bug-guix@gnu.org
>
> If you wish to submit further information on this problem, please
> send it to 50...@debbugs.gnu.org.
>
> Please do not send mail to help-debb...@gnu.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 50592: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=50592
> GNU Bug Tracking System
> Contact help-debb...@gnu.org with problems
>

bug#50566: [core-updates-frozen] Grub fails to decrypt LUKS partition (cryptomount not found)

[Jonathan Brielmaier]

I went ahead and did a trick Tobias (nckx) told me in IRC. I booted a
Guix installer from an USB stick and hit 'c' (command line) in its GRUB
menu. Then I gave in the following commands:

```
insmod luks
cryptomount (hd1,gpt2)
Enter passphrase ...:
set root=(crypto0)
configfile /boot/grub/grub.cfg
```

I can then choose between the Guix system generations: 1x
core-updates-frozen and 3x master. The latter did worked before my
reconfigure on c-u-f.

But non of them really worked. I have to enter the LUKS password a
second time and then shepherd fails to start all the services. The cpu
fan blows a bit loud:
```
failed to start service 'file-systems'
failed to start service 'file-system-/boot/efi'
failed to start service 'user-processes'
[...]
```

An Alt+SysReq+E (SIGTERM all apart INIT) gives:
```
shepherd[1]: Service udev has been disabled.
shepherd[1]: Respawning libvirtd.
shepherd[1]: Service libvirtd has been started.
```

And some audit log message. Can audit break the boot?

Has anyone an idea how to find out why those services start to fail? How
to obtain logs?

~Jonathan

bug#50595: Faliure in guix import go

[Stephen Paul Weber]

$ guix import go -r bdd.fi/x/runitor

guix import: warning: Failed to import package "bdd.fi/x/runitor".
reason: ("struct-vtable" "Wrong type argument in position 1 (expecting struct): 
~S" (#f) (#f)).


signature.asc
Description: PGP signature

bug#50596: Cannot get guix copy to work...

[Stephen Paul Weber]

$ guix copy --to=SERVER package

guix copy: sending 72 store items (203 MiB) to 'SERVER'...
guix copy: error: corrupt input while restoring archive from #


This is what I get no matter what package I try to send.  Any idea what could be
going wrong?


signature.asc
Description: PGP signature

bug#50595: Failure in guix import go

[Stephen Paul Weber]

Getting a similar failure here:

$ guix import go github.com/cncf/udpa/go/

following redirection to 
`https://proxy.golang.org/github.com/cncf/udpa/go/@v/list'...
following redirection to 
`https://proxy.golang.org/github.com/cncf/udpa/go/@latest'...
following redirection to 
`https://proxy.golang.org/github.com/cncf/udpa/go/@v/v0.0.0-20210322005330-6414d713912e.mod'...
guix import: warning: Failed to import package "github.com/cncf/udpa/go/".
reason: ("vector-ref" "Wrong type argument in position 1 (expecting vector): 
~S" (#f) (#f)).
guix import: error: failed to download meta-data for module 
'github.com/cncf/udpa/go/'


signature.asc
Description: PGP signature

bug#31403: Font installed in non-default profile doesn't appear.

[Maxim Cournoyer]

Hi!

Sarah Morgensen  writes:

> Maxim Cournoyer  writes:
> George Clemmer (2018-05-08 20:04 -0400) wrote:
>
>> In a "headless" vm-image (sysi29.scm, attached), "font-dejavu" installed
>> by manifest (attached) into the "empty" default profile ...
>>
>> 'guix package -m manifest'
>>
>> ... appears in the emacs 'M-x menu-set-font' choice box. But it doesn't
>> appear with the same manifest installed in the "foo" profile ...
>>
>> Assuming you run Emacs in that foo profile and don't see the font,
>> that's probably because XDG_DATA_DIRS is unset in that other profile.
>> glib is one of the package setting that variable.
>>
>> I'm merging this bug with 22138, which would fix the root cause.
>
> Will this be fixed by #50358?  If so, could you close this when that is
> merged?

The above statement turned out to be untrue at the time; fontconfig used
to not honor XDG_DATA_DIRS.  That's now the case with the newest
fontconfig release, if XDG_DATA_DIRS is set (which probably won't -- due
to 22138), Emacs should be able to discover fonts in a different profile
than the user or system profiles.

Maxim

bug#50597: different fixed-output when using ’--with-source’ transformation

[zimoun]

Hi,

If the package source tarball is provided to ’--with-source’, then the
hash differs.  I would expect a fixed point.

Let investigate:

--8<---cut here---start->8---
$ guix build hello@2.10 
--with-source=hello=https://ftpmirror.gnu.org/gnu/hello/hello-2.10.tar.gz
/gnu/store/zfwhbbknkhxi3yqmp0qgh1l1crljgbm6-hello-2.10

$ guix build hello@2.10 
/gnu/store/a462kby1q51ndvxdv3b6p0rsixxrgx1h-hello-2.10
--8<---cut here---end--->8---

Where https://ftpmirror.gnu.org/gnu/hello/hello-2.10.tar.gz is an
official mirror.  I expect the same store item.

Why are they different?  It is because the derivations are different.
The first call contains the source tarball as an “input”; that’s fine.
The second call contains the source tarball as a derivation; again
that’s fine.  The corresponding first and second derivations are:

--8<---cut here---start->8---
Derive
([("out","/gnu/store/zfwhbbknkhxi3yqmp0qgh1l1crljgbm6-hello-2.10","","")]
 
,[("/gnu/store/101ny738l311p4fm3cas7jgnkzagjv6a-module-import-compiled.drv",["out"])

[...]

   ,("/gnu/store/z4s27gwacbw8f38andfsh21r8v330dag-xz-5.2.4.drv",["out"])]
 ,["/gnu/store/8a0wry8cvr405ha8d8bpjyzj5dzghigd-module-import",
 "/gnu/store/chariqd6k0sli3s7vcl4q3al0crirz5v-hello-2.10.tar.gz",
 "/gnu/store/rndq9g8877l29ha41dvsl3aj1z0gw0ng-hello-2.10-guile-builder"]

[...]

--8<---cut here---end--->8---

and

--8<---cut here---start->8---
Derive
([("out","/gnu/store/a462kby1q51ndvxdv3b6p0rsixxrgx1h-hello-2.10","","")]
 
,[("/gnu/store/101ny738l311p4fm3cas7jgnkzagjv6a-module-import-compiled.drv",["out"])
   
,("/gnu/store/1a7xfcqcxj0pqi4f81x1agcxa46v2bbm-hello-2.10.tar.gz.drv",["out"])

[...]

   ,("/gnu/store/z4s27gwacbw8f38andfsh21r8v330dag-xz-5.2.4.drv",["out"])]
 ,["/gnu/store/8a0wry8cvr405ha8d8bpjyzj5dzghigd-module-import",
 "/gnu/store/kql8b2hbsabcmany4m3hfm3wzdiymliy-hello-2.10-guile-builder"]

[...]

--8<---cut here---end--->8---

Therefore, I understand why the two store items have different hashes.
Although, it should be better that the derivations would be the same;
another story. :-)


What puzzled me are the corresponding ’guile-builder’s:

--8<---cut here---start->8---
  (define %build-inputs
(quote
 (("source" . 
"/gnu/store/chariqd6k0sli3s7vcl4q3al0crirz5v-hello-2.10.tar.gz")
--8<---cut here---end--->8---

and

--8<---cut here---start->8---
  (define %build-inputs
(quote
 (("source" . 
"/gnu/store/hbdalsf5lpf01x4dcknwx6xbn6n5km6k-hello-2.10.tar.gz")
--8<---cut here---end--->8---

but these 2 items have the same hash:

--8<---cut here---start->8---
$ guix hash /gnu/store/chariqd6k0sli3s7vcl4q3al0crirz5v-hello-2.10.tar.gz
0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i

$ guix hash /gnu/store/hbdalsf5lpf01x4dcknwx6xbn6n5km6k-hello-2.10.tar.gz
0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i
--8<---cut here---end--->8---

Why?  It is fixed-output so I was expecting the same thing.  And the
same as:

--8<---cut here---start->8---
$ guix download https://ftpmirror.gnu.org/gnu/hello/hello-2.10.tar.gz

Starting download of /tmp/guix-file.qkhxkp
>From https://ftpmirror.gnu.org/gnu/hello/hello-2.10.tar.gz...
following redirection to 
`https://mirrors.sarata.com/gnu/hello/hello-2.10.tar.gz'...
 …10.tar.gz  709KiB   549KiB/s 00:01 
[##]
100.0%
/gnu/store/hbdalsf5lpf01x4dcknwx6xbn6n5km6k-hello-2.10.tar.gz
0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i
--8<---cut here---end--->8---

Why the store item of source tarball is it different when applying the
transformation?

Maxime provided a clue [1].

All the best,
simon

1: 

bug#50264: ca-certificate-bundle fails to build

[Lars-Dominik Braun]

Hi Leo,

> I wonder if the problem began after the introduction of
> bordeaux.guix.gnu.org, and if everyone who experiences the bug is using
> both substitute servers.
I started the Guix daemon with only the CI substitute server enabled
explicitly, disabled local discovery, ran a `guix gc` and tried again. It
still fails with exactly the same issue.

Lars