bug#58333: Manual PDFs other than en and es fail to build

[Ricardo Wurmus]

Julien Lepiller  writes:

> You can push this fix directly to the repo, but please also fix it on
> weblate or it'll break again next time I update translations.

I pushed the fix and made a change in the German translation on weblate;
the change for the French translation had already been made on weblate.

-- 
Ricardo

bug#58375: Installer does not show what is being downloaded

[Julien Lepiller]

I installed Guix on a new drive, so I tried the installer from the latest 
image. After reviewing the system config, the installer goes to a black screen 
where guix output is shown. Although I can see messages about substitutes being 
updated, and how much will be downloaded, all download lines are replaced with 
a seemingly random number of dots:

substitute: mise à jour des substituts depuis «…»... 100.0 %
4.5 Mo seront téléchargés.
.
...
.
.
..

Maybe this is related to the translation?

bug#58374: GVFS depends on WebKitGTK via gnome-online-accounts

[Ludovic Courtès]

For a “system-level” package, GVFS has an unreasonable footprint:

--8<---cut here---start->8---
$ guix describe
Generation 230  Oct 03 2022 00:13:06(current)
  guix bb3b810
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: bb3b810167d9ff784770a848a6f86b0cfa9cdfd8
$ guix size gvfs
store item   totalself
/gnu/store/wdm2s2si8fqsrcd5xpc29ivmpkf20s8d-mesa-21.3.8411.6   
169.6   6.8%
/gnu/store/6pdzpmxg5afzss6dlivq8z84sfa31x22-llvm-11.0.0221.5   
149.5   6.0%
/gnu/store/069aq2v993kpc41yabp5b6vm4wb9jkhg-gcc-10.3.0 217.7   
145.8   5.9%
/gnu/store/9cbi3x1f0xqagpmdmjhc79acshyjkl6k-webkitgtk-2.36.7  1379.1   
127.0   5.1%
/gnu/store/a67q76vpbahf66y434pqs9c1gsj6x7ml-samba-4.16.4   491.8
93.7   3.8%
/gnu/store/492rrcrkgaq0csw1x09x6aj5kjz8xxrr-samba-4.15.3   489.4
90.1   3.6%
/gnu/store/drjnxy0jrxd084grrkyagrdkjsyv1afz-qtbase-5.15.2 1154.1
73.4   2.9%
/gnu/store/65i3nhcwmz0p8rqbg48gaavyky4g4hwk-python-3.9.9   155.3
63.7   2.6%
/gnu/store/p3hz5g4z1yzjq6bsbp7kqr9g0fmrmad8-mozjs-78.15.0  258.1
62.3   2.5%
/gnu/store/hy6abswwv4d89zp464fw52z65fkzr7h5-perl-5.34.0147.7
58.6   2.4%
/gnu/store/x3rwakc3z81hmgayxj5qh4a8flsj9hzw-mediasdk-22.4.4468.8
56.4   2.3%

[...]

total: 2492.4 MiB
--8<---cut here---end--->8---

The main issue is the dependency on webkitgtk:

--8<---cut here---start->8---
$ guix graph --path gvfs webkitgtk@2.36
gvfs@1.50.2
gnome-online-accounts@3.45.2
webkitgtk@2.36.7
$ guix gc --references $(guix build gnome-online-accounts)|grep webkit
/gnu/store/6zpcpnywcimmia84jkixnwfcl4chhz6k-webkitgtk-2.36.7
$ grep -r 6zpcpnywcimmia84jkixnwfcl4chhz6k $(guix build gnome-online-accounts)
grep: 
/gnu/store/dkqcdhcg8536h4ahwpkc3hv0xrrc8haj-gnome-online-accounts-3.45.2/lib/libgoa-backend-1.0.so.1.0.0:
 binary file matches
grep: 
/gnu/store/dkqcdhcg8536h4ahwpkc3hv0xrrc8haj-gnome-online-accounts-3.45.2/lib/goa-1.0/web-extensions/libgoawebextension.so:
 binary file matches
grep: 
/gnu/store/dkqcdhcg8536h4ahwpkc3hv0xrrc8haj-gnome-online-accounts-3.45.2/etc/ld.so.cache:
 binary file matches
$ ldd 
/gnu/store/dkqcdhcg8536h4ahwpkc3hv0xrrc8haj-gnome-online-accounts-3.45.2/lib/libgoa-backend-1.0.so.1.0.0
 |grep webkit
libjavascriptcoregtk-4.1.so.0 => 
/gnu/store/6zpcpnywcimmia84jkixnwfcl4chhz6k-webkitgtk-2.36.7/lib/libjavascriptcoregtk-4.1.so.0
 (0x7f228ec0)
libwebkit2gtk-4.1.so.0 => 
/gnu/store/6zpcpnywcimmia84jkixnwfcl4chhz6k-webkitgtk-2.36.7/lib/libwebkit2gtk-4.1.so.0
 (0x7f228a80)
$ ldd 
/gnu/store/dkqcdhcg8536h4ahwpkc3hv0xrrc8haj-gnome-online-accounts-3.45.2/lib/goa-1.0/web-extensions/libgoawebextension.so
 |grep webkit
libwebkit2gtk-4.1.so.0 => 
/gnu/store/6zpcpnywcimmia84jkixnwfcl4chhz6k-webkitgtk-2.36.7/lib/libwebkit2gtk-4.1.so.0
 (0x7f3a0a20)
libjavascriptcoregtk-4.1.so.0 => 
/gnu/store/6zpcpnywcimmia84jkixnwfcl4chhz6k-webkitgtk-2.36.7/lib/libjavascriptcoregtk-4.1.so.0
 (0x7f3a07c0)
--8<---cut here---end--->8---

One way to address it might be to build libgoa-backend and
libgoawebextension separately from the main libgoa.so, or to have them
in a separate output.

However, I’m not sure how libgoa-backend is supposed to be used.  It has
a .pc file, which suggests applications that need it explicitly link
against it (as opposed to having it dlopen’d), but I couldn’t find an
example.

Thoughts?

Ludo’.

bug#56322: Debbug 56322, Ruby packaging issues, ping?

[Remco van 't Veer]

Do the patches[1][2] need more work?


[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=56322#11
[2] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=56322#29

bug#58384: copy-build-system assumes that strip-flags, strip-directories is a S-exp, but it isn't.

[Maxime Devos]

(bug on core-updates, not master)


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#57046: Spanish documentation uses exclusive language

[pelzflorian (Florian Pelz)]

Closing because discussion has ceased and I’m not confident in anything
here.  I suggest Spanish translators remove the policy and translate new
strings as they see fit.

Regards,
Florian

bug#25327: cargo build-system should be able to filter out target.cfg(windows) dependencies

[Maxime Devos]

On 08-10-2022 16:15, zimoun wrote:

Hi,

On Thu, 24 Mar 2022 at 18:18, Nicolas Graves  wrote:


I might try to implement these changes, although I do not have enough
time and experience to do that quickly, neither enough horsepower to try
to rebuild everything after that. I included Maxime Devos in the
conversation, would it be possible to fork guix to develop this and try
to rebuild every rust package after that on a guix build farm ? Sorry,
haven't got in touch with guix developers yet, still imposter's
syndrome effect, but implementing this doesn't seem too hard. What would
I need to do to get going on that ?


Just to know what is the status of this bug#25327 [1]?  Well, I have not
followed closely some recent changes about Rust and Guix.  Maybe, some
patches are already around?


antioxidant-build-system (*) automatically ignores all dependencies it 
can't find (including Windows dependencies), and as such solves this.


(*) close to 100%, the main remaining problem is lack of support for 
workspaces; I'm currently looking for packaging a topological sorting 
algorithm but it depends on other unpackaged things etc.  Other problems 
should be rather minor.


Greetings,
Maxime.


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#30290: guix-daemon slows to a crawl when a substitute server is offline

[zimoun]

Hi Maxim,

On Wed, 23 Mar 2022 at 11:50, zimoun  wrote:
> On Wed, 18 Aug 2021 at 22:25, Maxim Cournoyer  
> wrote:

>> Extra note: the problems reported earlier (hang or backtrace instead of
>> graceful fallback to other substitute servers) also affect the scenario
>> where substitutes are fetched from uDNS discovered substitute servers (I
>> just tried).
>
> I guess this old bug [1] about the daemon hanging is still there, right?
>
> How such issue could be tackled?
>
> 1: 

What could be actionable for tackling this old bug?


Cheers,
simon

bug#37005: Add ability of modifying connection before full installation

[zimoun]

Hi installer team, :-)

Well, the question is: does you think it is doable to add some network
configuration (if it is not already the case) in the installer?

User could set some IP, DNS, Gateway and friends before or after network
checking or automatic configuration.

On Wed, 23 Dec 2020 at 12:29, zimoun  wrote:

> Since it seems impossible by current design of Qubes to switch to
> console and set by hand the network before starting the install process,
> instead of the fail and “try again” loop, you would like 3 fields where
> you can manually type the IP, DNS, Gateway and friends, right?

For context, it is bug#37005 [1].

1: 


Cheers,
simon

bug#58320: Hurd VM fails to boot on AMD EPYC (kvm-amd)

[Ludovic Courtès]

Hi Samuel,

Samuel Thibault  skribis:

> About the backtrace:
>
>> user space <
> 0x1000(bf24,0,0,1160b,0)
> 0x11627(bf9c,0,0,0,2)
> 0x11bb()
>
> That is quite surprising actually: in my ld.so there is nothing useful
> at 0x1000. Perhaps you can check what 0x11627 is all about?

Sure:

--8<---cut here---start->8---
$ addr2line -e  
/gnu/store/m8afvcgwmrfhvjpd7b0xllk8vv5isd6j-glibc-cross-i586-pc-gnu-2.33/lib/ld.so.1
 0x1000 0x11627 0x11bb
??:0
/tmp/guix-build-glibc-cross-i586-pc-gnu-2.33.drv-0/glibc-2.33/elf/dl-misc.c:333
:?
--8<---cut here---end--->8---

That’s ‘_dl_fatal_printf’ calling ‘_exit’; it’s trying to tell us
something.

I’ll try and rebuild the system with the debugging patches at
, to
get early ld.so output, for lack of a better solution…

>> Program Header:
>> LOAD off0x vaddr 0x paddr 0x align 2**12
>>  filesz 0x0dd8 memsz 0x0dd8 flags r--
>
> We don't have this section in the Debian glibc. It'd probably be useful
> to know what this is about.

Address 0 is for the ‘_begin’ symbol, passed by -Wl,-defsym:

--8<---cut here---start->8---
i586-pc-gnu-gcc   -nostdlib -nostartfiles -r -o 
/tmp/guix-build-glibc-cross-i586-pc-gnu-2.33.drv-0/build/elf/librtld.os 
'-Wl,-(' 
/tmp/guix-build-glibc-cross-i586-pc-gnu-2.33.drv-0/build/elf/dl-allobjs.os 
/tmp/guix-build-glibc-cross-i586-pc-gnu-2.33.drv-0/build/elf/rtld-libc.a -lgcc 
'-Wl,-)' \
  
-Wl,-Map,/tmp/guix-build-glibc-cross-i586-pc-gnu-2.33.drv-0/build/elf/librtld.os.map
i586-pc-gnu-gcc   -nostdlib -nostartfiles -shared -o 
/tmp/guix-build-glibc-cross-i586-pc-gnu-2.33.drv-0/build/elf/ld.so.new  
   \
  -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both -Wl,-z,defs   
\
  
/tmp/guix-build-glibc-cross-i586-pc-gnu-2.33.drv-0/build/elf/librtld.os 
-Wl,--version-script=/tmp/guix-build-glibc-cross-i586-pc-gnu-2.33.drv-0/build/ld.map
  \
  -Wl,-soname=ld.so.1   \
  -Wl,-defsym=_begin=0
i586-pc-gnu-readelf -s 
/tmp/guix-build-glibc-cross-i586-pc-gnu-2.33.drv-0/build/elf/ld.so.new \
  | gawk '($7 ~ /^UND(|EF)$/ && $1 != "0:" && $4 != "REGISTER") { print; p=1 } 
END { exit p != 0 }'
mv -f /tmp/guix-build-glibc-cross-i586-pc-gnu-2.33.drv-0/build/elf/ld.so.new 
/tmp/guix-build-glibc-cross-i586-pc-gnu-2.33.drv-0/build/elf/ld.so
--8<---cut here---end--->8---

And indeed:

--8<---cut here---start->8---
$ objdump -t  
/gnu/store/m8afvcgwmrfhvjpd7b0xllk8vv5isd6j-glibc-cross-i586-pc-gnu-2.33/lib/ld.so.1|grep
 _begin
 l   *ABS*    _begin
--8<---cut here---end--->8---

That ‘-Wl,-defsym=_begin=0’ flag was removed in glibc commit
6f043e0ee7e477f50a44024ed0cb579d5e3f511d (April 2022).

On darnassus it’s different but then it’s Debian’s glibc 2.35, natively
built, so I don’t what conclusions can be drawn:

--8<---cut here---start->8---
ludo@darnassus:~$ /lib/ld.so.1 --version
ld.so (Debian GLIBC 2.35-1) stable release version 2.35.
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
ludo@darnassus:~$ objdump -x /lib/ld.so.1 |head -40

/lib/ld.so.1: file format elf32-i386
/lib/ld.so.1
architecture: i386, flags 0x0150:
HAS_SYMS, DYNAMIC, D_PAGED
start address 0x0001cc40

Program Header:
LOAD off0x vaddr 0x paddr 0x align 2**12
 filesz 0x00038494 memsz 0x00038494 flags r-x
LOAD off0x00038c00 vaddr 0x00039c00 paddr 0x00039c00 align 2**12
 filesz 0x1ca8 memsz 0x1e34 flags rw-
 DYNAMIC off0x00039f24 vaddr 0x0003af24 paddr 0x0003af24 align 2**2
 filesz 0x00b8 memsz 0x00b8 flags rw-
NOTE off0x0114 vaddr 0x0114 paddr 0x0114 align 2**2
 filesz 0x0024 memsz 0x0024 flags r--
--8<---cut here---end--->8---

Thanks for your feedback!

Ludo’.

bug#58377: error when install guix system

[Josselin Poiret via Bug reports for GNU Guix]

Hi, 

"lizhongyou2...@126.com"  writes:

> as shown in the picture

I assume you're using the 1.3.0 installer ISO?  It is pretty old at this
point, and many improvements have been made since then.  Can you use the
latest ISO available at https://guix.gnu.org/en/download/latest/
instead?

Best,
-- 
Josselin Poiret

bug#37005: Add ability of modifying connection before full installation

[Josselin Poiret via Bug reports for GNU Guix]

Hello Simon,
zimoun  writes:

> Hi installer team, :-)
>
> Well, the question is: does you think it is doable to add some network
> configuration (if it is not already the case) in the installer?
>
> User could set some IP, DNS, Gateway and friends before or after network
> checking or automatic configuration.

That would be totally doable, we use connman in the installer through
its CLI and it has configuration options along those lines.  Although I
wish we could use guile-netlink instead, but that'd require a
non-trivial rewrite.  I'll have a look later to see if I can add that.

Best,
-- 
Josselin Poiret

bug#58366: Guix build fails on i686

[Denis 'GNUtoo' Carikli]

Hi,

After a guix pull it now builds fine again. I've tested it with guix
build -s i686-linux on x86_64 and guix build guix on i686.

So the bug can now be closed.

Denis.


pgp68OhkUF2Pp.pgp
Description: OpenPGP digital signature

bug#58384: copy-build-system assumes that strip-flags, strip-directories is a S-exp, but it isn't.

[Maxime Devos]

Hi,

In commit 
https://git.savannah.gnu.org/cgit/guix.git/commit/?h=core-updates=ccc2658e2a111590ec25e308946e47a24d357785, 
the default 'strip-flags' and 'strip-directories' argument were changed 
from a S-exp to %strip-flags and %strip-directories from (guix 
build-system gnu).


This is fine, except for copy-build doing (sexp->gexp ...) on those, 
even though %strip-flags etc. are G-exps, not S-exps, causing errors like



ice-9/read.scm:126:4: In procedure read-expr*:
/gnu/store/abb0wz0223bjsxkw9av768szz955m2xh-openjpeg-data-2021.09.26-builder:1:2504: Unknown 
# object: "#<"
builder for 
`/gnu/store/qbc93ywsbm3bwwiqn7h8fv124i1yqh53-openjpeg-data-2021.09.26.drv' 
failed with exit code 1
derivation 
'/gnu/store/qbc93ywsbm3bwwiqn7h8fv124i1yqh53-openjpeg-data-2021.09.26.drv' 
offloaded to '141.80.167.174' failed: build of 
`/gnu/store/qbc93ywsbm3bwwiqn7h8fv124i1yqh53-openjpeg-data-2021.09.26.drv' 
failed



Changing '(sexp->gexp strip-flags)' to 'strip-flags' and likewise for 
'strip-directories' should fix things (unverified).


Greetings,
Maxime.


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#58198: topological-sort does not sort topologically in case of diamonds

[Maxime Devos]

I found a solution: change the depth-first traversal to a breadth-first 
traversal -- it uses (pfds hamts) from guile-pfds instead of (guix 
sets)/(ice-9 vlist), so will need some small changes for use in Guix 
(unless the additional dependency is considered acceptable), but it 
should at least unblock the workspace implementation in antioxidant.


Greetings,
Maxime.
;;; GNU Guix --- Functional package management for GNU
;;; Copyright © 2019 Ludovic Courtès 
;;; Copyright © 2022 Maxime Devos 
;;;
;;; This file is part of GNU Guix.
;;;
;;; GNU Guix is free software; you can redistribute it and/or modify it
;;; under the terms of the GNU General Public License as published by
;;; the Free Software Foundation; either version 3 of the License, or (at
;;; your option) any later version.
;;;
;;; GNU Guix is distributed in the hope that it will be useful, but
;;; WITHOUT ANY WARRANTY; without even the implied warranty of
;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;;; GNU General Public License for more details.
;;;
;;; You should have received a copy of the GNU General Public License
;;; along with GNU Guix.  If not, see .

;; To be used by the implementation of workspaces.
;; Extracted from (guix import utils), and changed from (guix sets)
;; to a guile-pfds equivalent.
(define-module (topological-sort)
  #:export (topological-sort)
  #:use-module ((srfi srfi-69) #:select (hash))
  #:use-module ((ice-9 match) #:select (match))
  #:use-module (pfds hamts))

(define (topological-sort nodes
  node-dependencies
  node-name)
  "Perform a breadth-first traversal of the graph rooted at NODES, a list of
nodes, and return the list of nodes sorted in topological order.  Call
NODE-DEPENDENCIES to obtain the dependencies of a node, and NODE-NAME to
obtain a node's uniquely identifying \"key\"."
  ;; It is important to do a breadth-first traversal instead of a depth-first
  ;; traversal -- a simpler depth-first traversal has caused failures in the
  ;; past.
  (let loop ((unexpanded-nodes nodes)
	 (result '()) ; in reverse topological order
	 ;; Identical to 'result', except for using a different data
	 ;; structure.
	 (visited (make-hamt hash equal?)))
(if (null? unexpanded-nodes)
	(reverse result) ; done!
	(let inner-loop ((current-unexpanded-nodes unexpanded-nodes)
			 (later-unexpanded-nodes '())
			 (result result)
			 (visited visited))
	  (match current-unexpanded-nodes
	((first . current-unexpanded-nodes)
	 (if (hamt-ref visited (node-name first) #false)
		 ;; Already visisted, nothing to do!
		 (inner-loop current-unexpanded-nodes
			 later-unexpanded-nodes result visited)
		 ;; Expand 'first', putting dependencies in
		 ;; 'later-unexpanded-nodes'.
		 (inner-loop current-unexpanded-nodes
			 (append (node-dependencies first)
 later-unexpanded-nodes)
			 (cons first result)
			 (hamt-set visited (node-name first) #true
	(() ;; All nodes on the current level are expanded, descend!
	 (loop later-unexpanded-nodes result visited)))


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#25957: gitolite broken: created repositories keep references to /usr/bin for hooks

[zimoun]

Hi Dave,

On Thu, 06 Oct 2022 at 09:26, "Thompson, David"  
wrote:

> Some news: I have updated the gitolite package to use G-expressions.
> The package builds and the gitolite system test passes so I pushed
> that change to master a little while ago.  That patch has made the
> (hopefully) final step in this saga easier. The attached patch
> introduces a 'make-gitolite' procedure that can be used to add
> arbitrary packages to the wrappers for the gitolite and gitolite-shell
> programs.  The return value of this procedure can be used in the
> gitolite service configuration to enable the desired optional features
> like Redis or git-annex.  The base package inputs are unchanged and
> the gitolite system test still passes.

Thank you for working on this!  Neat.

Well, your proposal LGTM although I do not see the difference between
’make-gitolite’ and a simple ’inherent’ for building a package variant.
Yeah, this make-gitolite is probably more handy.

I do not have a strong opinion on the matter. :-)

Cheers,
simon

bug#28510: crash: guix build -S foo --with-source=bla

[zimoun]

Hi Jérémy,

On Fri, 07 Oct 2022 at 10:41, jer...@korwin-zmijowski.fr wrote:

> I feel not able to take decision about the proper way right now.
> So as a step forward I wrote a test to capture the behavior expected.
> Please have a look at it as it's the starting point for me.
> Next, I can implement the error handler, making the previous test to 
> pass.
> As the test checks the behaviour, it will let enough space to change 
> implementation later without invalitating the test.

Nice to start by the test! :-)

> (define-module (tests scripts build)
>   #:use-module (srfi srfi-64)
>   #:use-module (ice-9 exceptions)
>   #:use-module (guix scripts build)
>   #:use-module (srfi srfi-34))
>
> (test-begin "scripts")
>
> (define DUMMY_DEFINITION_PATH "/tmp/a.scm")
>
> (define (create-dummy-definition)
>   (call-with-output-file DUMMY_DEFINITION_PATH
> (lambda (port)
>   (format port
>   "(use-modules (gnu packages) (guix packages) (guix gexp)) 
> (package (inherit (specification->package \"hello\")) (source (local-file 
> \"a.scm\")))"
>
> (define (delete-dummy-definition)
>   (delete-file DUMMY_DEFINITION_PATH))
>
> (test-group-with-cleanup "build"
>
>   (create-dummy-definition)
>
>   (test-equal "package definition as only source"
> "/gnu/store/7mnkrg9bmybgyf1dn5n67di6ng6qvhkz-a.scm"
> (guard
> (ex
>  ((exception? ex) #f))
>   (guix-build "-f" DUMMY_DEFINITION_PATH "--source")))

Well, this test looks good to me.  However, I would lower what the
procedure under test.  For instance, package-source-derivation in
guix/packages.scm or show-derivation-outputs, as Josselin pointed [1].

1: 

>
>   (delete-dummy-definition))
>
> (test-end "scripts")


Cheers,
simon

bug#26247: Gettext introduces timestamps in .mo files

[zimoun]

Hi Miguel,

It is about an old patch [2] and on old message from Dec. 2020.

On Fri, 11 Dec 2020 at 14:26, Miguel Ángel Arruga Vivas  
wrote:

> 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.
>
> Best regards,
> Miguel
>
> [1] https://savannah.gnu.org/bugs/?59658

Are commits 4343ca8ba5b02c8fe09e5bd681abbc0440ab8b08 and following the
ones mentioned here?

Well, I am not sure to understand if it had been fixed upstream [1].


Cheers,
simon

2: 

bug#31977: clone tests fail on CentOS 7

[zimoun]

Hi Paul,

It is about this old bug#31977 [1].  Well, I have lost the status about
this and since I am using Debian with unprivileged_userns_clone, I am
not annoyed enough. ;-)

1: 


On Mon, 21 Dec 2020 at 15:29, Paul Garlick 
 wrote:

> It has been suggested that the feature itself should be tested, instead
> of relying on the /proc filesystem.  This could well be a better idea
> and I gather from the thread that this idea is being worked on.  I can
> test on CentOS when a new patch is available.

Is it still an issue for you?


Cheers,
simon

bug#36924: GDM, GNOME Shell, etc. break when there are stale caches

[Liliana Marie Prikler]

Am Samstag, dem 08.10.2022 um 16:47 +0200 schrieb zimoun:
> Hi,
> 
> On Thu, 23 Jun 2022 at 12:07, Ricardo Wurmus 
> wrote:
> 
> > > I am proposing to close if no objection.
> > 
> > I agree because it is not actionable as it is now.
> 
> Therefore, after some months without an objection, I am closing this
> old bug#36924 [1].  If I am missing a point, feel free to reopen.
The GDM one in fact got fixed by moving the cache to a tmpfs.

Cheers

bug#44903: Guix 1.2.0 installer 'auto-partition!' crash

[Josselin Poiret via Bug reports for GNU Guix]

Hi Maxim,

Maxim Cournoyer  writes:

> Mathieu, do you think this bug can still exist in 1.3.0 or our current
> snapshot installer images?  If not, we should close it, as it's gone
> stale and reported against 1.2.0.

Just my 2 cents: I think this issue was fixed with
0a74509a696671580c8a7dc768d26f414748bab5.  Sometimes, devices are so
small you can't even create a new partition table on them, and we used
to not detect this failure and instead return #f for the disk.  That or
ped_disk_new fails for some reason but I wouldn't know why without more
info.

Best,
-- 
Josselin Poiret

bug#58375: Installer does not show what is being downloaded

[Josselin Poiret via Bug reports for GNU Guix]

Hi Julien,

Julien Lepiller  writes:
> I installed Guix on a new drive, so I tried the installer from the latest 
> image. After reviewing the system config, the installer goes to a black 
> screen where guix output is shown. Although I can see messages about 
> substitutes being updated, and how much will be downloaded, all download 
> lines are replaced with a seemingly random number of dots:
>
> substitute: mise à jour des substituts depuis «…»... 100.0 %
> 4.5 Mo seront téléchargés.
> .
> ...
> .
> .
> ..
>
> Maybe this is related to the translation?

I agree that this does look pretty bad, but this is because we capture
the guix command output to a log file so that we're able to include it
in the installer dump if anything goes wrong.  Guix detects it's not
talking directly to a terminal and so doesn't try to use terminal
specific escape codes to display the download progress.  I don't know
how we could improve on that front though, since in general capturing
the guix command output helps with debugging issues.

Best,
-- 
Josselin Poiret

bug#25957: gitolite broken: created repositories keep references to /usr/bin for hooks

[Thompson, David]

On Sat, Oct 8, 2022 at 11:16 AM zimoun  wrote:
>
> Hi Dave,
>
> On Thu, 06 Oct 2022 at 09:26, "Thompson, David"  
> wrote:
>
> > Some news: I have updated the gitolite package to use G-expressions.
> > The package builds and the gitolite system test passes so I pushed
> > that change to master a little while ago.  That patch has made the
> > (hopefully) final step in this saga easier. The attached patch
> > introduces a 'make-gitolite' procedure that can be used to add
> > arbitrary packages to the wrappers for the gitolite and gitolite-shell
> > programs.  The return value of this procedure can be used in the
> > gitolite service configuration to enable the desired optional features
> > like Redis or git-annex.  The base package inputs are unchanged and
> > the gitolite system test still passes.
>
> Thank you for working on this!  Neat.
>
> Well, your proposal LGTM although I do not see the difference between
> ’make-gitolite’ and a simple ’inherent’ for building a package variant.
> Yeah, this make-gitolite is probably more handy.

The reason for the constructor is so that extra packages can be easily
added to the gexp that calls wrap-program.  It would be much harder to
modify the package in this way without a helper procedure.

- Dave

bug#36924: GDM, GNOME Shell, etc. break when there are stale caches

[zimoun]

Hi,

On Thu, 23 Jun 2022 at 12:07, Ricardo Wurmus  wrote:

>> I am proposing to close if no objection.
>
> I agree because it is not actionable as it is now.

Therefore, after some months without an objection, I am closing this old
bug#36924 [1].  If I am missing a point, feel free to reopen.

1: 

Cheers,
simon

bug#44848: Support partial downloads

[zimoun]

Hi,

On Tue, 24 Nov 2020 at 14:35, Julien Lepiller  wrote:

> I have written a patch for that some time ago, that oas never merged. See 
> https://issues.guix.gnu.org/39530 :)

Closing in favor of patch#39530 [1]; which needs review BTW. :-)


1: 

bug#48796: Guix on Debian 11 - Cant run or find applications from Guix

[zimoun]

Hi,

On Thu, 23 Jun 2022 at 10:20, zimoun  wrote:

> This report #48796 [1] is marked as moreinfo since some weeks.  Although
> I understand the need, but since I do not see what could be the next
> actionable step, I am in favor to close it.
>
> 1: 
>
> Therefore, if no objection and/or a clear next action, then I will close
> it in the coming weeks.

After waiting 3 months, closing.


Cheers,
simon

bug#25327: cargo build-system should be able to filter out target.cfg(windows) dependencies

[zimoun]

Hi,

On Thu, 24 Mar 2022 at 18:18, Nicolas Graves  wrote:

> I might try to implement these changes, although I do not have enough
> time and experience to do that quickly, neither enough horsepower to try
> to rebuild everything after that. I included Maxime Devos in the
> conversation, would it be possible to fork guix to develop this and try
> to rebuild every rust package after that on a guix build farm ? Sorry,
> haven't got in touch with guix developers yet, still imposter's
> syndrome effect, but implementing this doesn't seem too hard. What would
> I need to do to get going on that ?

Just to know what is the status of this bug#25327 [1]?  Well, I have not
followed closely some recent changes about Rust and Guix.  Maybe, some
patches are already around?

Cheers,
simon

1: 

bug#58333: Manual PDFs other than en and es fail to build

[pelzflorian (Florian Pelz)]

Ricardo Wurmus  writes:
> Julien Lepiller  writes:
>
>> You can push this fix directly to the repo, but please also fix it on
>> weblate or it'll break again next time I update translations.
>
> I pushed the fix and made a change in the German translation on weblate;
> the change for the French translation had already been made on weblate.

Thank you!

Regards,
Florian

bug#58352: guix@1.3.0-30.17134b9 test failures on i686

[Ludovic Courtès]

Ludovic Courtès  skribis:

> Now the ‘guix’ package needs to be updated.

Done in commit e49255ff18def1065f65194f679a1d07fd5a266e!

Ludo’.

bug#58290: guile ssh error on guix deploy

[Ludovic Courtès]

Hi!

Andrew Tropin  skribis:

> From time to time I get the following error, the only thing I change is
> IPv6 config in static-networking service.  Sometimes it fails, but after
> a few more attempts with the same config it deploys sucessfully.
>
> -*- mode: compilation; default-directory: "~/work/abcdw/trop.in/" -*-
> Compilation started at Tue Oct  4 14:19:46
>
> make -k deploy-pinky
> guix deploy ./guix/pinky.scm

[...]

> In guix/ssh.scm:
> 376:2  7 (send-files # _ # …)
> 222:5  6 (remote-run (begin (use-modules (guix) (srfi #) # #) …) #)
> In ssh/popen.scm:
>  64:4  5 (open-remote-pipe* _ "r+" _ . _)
> In unknown file:
>4 (channel-open-session #)
> In ice-9/boot-9.scm:
>   1685:16  3 (raise-exception _ #:continuable? _)
>   1683:16  2 (raise-exception _ #:continuable? _)
>   1685:16  1 (raise-exception _ #:continuable? _)
>   1685:16  0 (raise-exception _ #:continuable? _)
>
> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> Throw to key `guile-ssh-error' with args `("channel-open-session" "Channel 
> opening failure: channel 67 error (2) open failed" # (closed) 7f7d1af9e140> #f)'.

Are there any hints from sshd in the /var/log/messages of that machine
as to why the connection was closed?

Thanks,
Ludo’.

bug#58221: nautilus: Crashes loading KgxNautilus plugin twice (problems with NAUTILUS_EXTENSION_PATH)

[Jascha Geerds]

Am Sa, 1. Okt 2022, um 20:14, schrieb Tobias Geerinckx-Rice via Bug reports for 
GNU Guix:
> So it *still* fails to find tracker3 before segfaulting?  Possible.  
> Could be a missing substitution, or it falling back to some other 
> (search) path...

It seems like this issue is due to commit 
103d8229cbbd3baefe1f3b02bc2edff9c816b0bf where "gnome-terminal" is replaced by 
"gnome-console". There is some nautilus extension path stuff in the 
gnome-console derivation which I do not fully understand 
(cb2d5063a0353a3aa93d513979c8a7fc80db1460).

bug#58320: Hurd VM fails to boot on AMD EPYC (kvm-amd)

[Samuel Thibault]

Ludovic Courtès, le ven. 07 oct. 2022 00:10:15 +0200, a ecrit:
> Samuel Thibault  skribis:
> 
> > Ludovic Courtès, le jeu. 06 oct. 2022 15:14:13 +0200, a ecrit:
> >> such that it would stop on each trap, hopefully allowing me to see why
> >> exec is not starting.
> >
> > Also, better use exec.static to have static addresses.
> 
> Thanks for the hint.
> 
> Of course, the thing boots just fine on that machine when using
> ‘exec.static’.

Uh. At least you have a workaround :)

> So the issue might be somewhere in ld.so, or triggered by ld.so.
> Any debugging tricks here?

maybe for a start check with 

show map $map2

what is actually mapped, whether it's just ld.so, or also exec, etc.

Perhaps you can also try to run other programs than exec, like small
dumb programs.

Samuel

bug#58362: error when `guix pull'

[Tsing Hui]

I encountered an error while using the "guix pull" command with the 
following error message:





guix pull
hint: Consider installing the `glibc-utf8-locales' or `glibc-locales' 
package and

defining `GUIX_LOCPATH', along these lines:

 guix install glibc-utf8-locales
 export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale"

See the "Application Setup" section in the manual, for more info.

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    6e3dab4
Computing Guix derivation for 'x86_64-linux'... |
The following derivations will be built:
   /gnu/store/px7qqv39gf78da3s2ms0hs5p73vykcp1-profile.drv
/gnu/store/fj89fvxlh7a4p1h0fqylfa7mlxmx9c3d-inferior-script.scm.drv
   /gnu/store/zqk3hdg7xqvpzgli4wpka2kzbymjb48b-profile.drv
   /gnu/store/zyayf57vhrhll4h3x7wl70264yl15mj6-guix-6e3dab473.drv
/gnu/store/c4n9ychjch61g4clh1v0pdmknfk6q9gj-guix-6e3dab473-modules.drv
/gnu/store/c1zb3bqv9lfwlxjjxg2ispsrxxnqg3l2-guix-system-tests-modules.drv
/gnu/store/ygywhmyjlqazckpz6f1sgz545a15la14-guix-system-tests.drv
   /gnu/store/kdikfm9nsmnr1s89ixh5d3aqgrc42hvm-guix-daemon.drv
   /gnu/store/znwv0fzggs8lb597nals43pm5dny85lp-guix-command.drv
/gnu/store/kc8lwplm2zxrlp52blmsh9ijsski5sq5-guix-module-union.drv

building 
/gnu/store/ygywhmyjlqazckpz6f1sgz545a15la14-guix-system-tests.drv...
 47% [## ]builder for 
`/gnu/store/ygywhmyjlqazckpz6f1sgz545a15la14-guix-system-tests.drv' 
failed with exit code 1
build of 
/gnu/store/ygywhmyjlqazckpz6f1sgz545a15la14-guix-system-tests.drv failed
View build log at 
'/var/log/guix/drvs/yg/ywhmyjlqazckpz6f1sgz545a15la14-guix-system-tests.drv.bz2'.
cannot build derivation 
`/gnu/store/c1zb3bqv9lfwlxjjxg2ispsrxxnqg3l2-guix-system-tests-modules.drv': 
1 dependencies couldn't be built
cannot build derivation 
`/gnu/store/c4n9ychjch61g4clh1v0pdmknfk6q9gj-guix-6e3dab473-modules.drv': 
1 dependencies couldn't be built
cannot build derivation 
`/gnu/store/zyayf57vhrhll4h3x7wl70264yl15mj6-guix-6e3dab473.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/px7qqv39gf78da3s2ms0hs5p73vykcp1-profile.drv': 1 
dependencies couldn't be built
guix pull: error: build of 
`/gnu/store/px7qqv39gf78da3s2ms0hs5p73vykcp1-profile.drv' failed




and here is my system info:

Linux version 5.15.0-43-generic (buildd@lcy02-amd64-076) (gcc (Ubuntu 
11.2.0-19ubuntu1) 11.2.0, GNU ld (GNU Binutils for Ubuntu) 2.38) 
#46-Ubuntu SMP Tue Jul 12 10:30:17 UTC 2022





and my hardware infos:

tsinghui-ps
    description: Laptop
    product: MacBookAir7,1 (System SKU#)
    vendor: Apple Inc.
    version: 1.0
    serial: C02S70YHGFWN
    width: 64 bits
    capabilities: smbios-2.7 dmi-2.7 smp vsyscall32
    configuration: boot=normal chassis=laptop family=Mac sku=System 
SKU# uuid=c2b3d8e1-2d08-56a2-b1f2-ae01151e41e4

  *-core
   description: Motherboard
   product: Mac-9F18E312C5C2BF0B
   vendor: Apple Inc.
   physical id: 0
   version: MacBookAir7,1
   serial: C026316028YG90RAQ
   slot: Part Component
 *-cache:0
  description: L1 cache
  physical id: 0
  slot: L1 Cache
  size: 32KiB
  capacity: 32KiB
  capabilities: synchronous internal write-back data
  configuration: level=1
 *-cache:1
  description: L1 cache
  physical id: 1
  slot: L1 Cache
  size: 32KiB
  capacity: 32KiB
  capabilities: synchronous internal write-back instruction
  configuration: level=1
 *-cache:2
  description: L2 cache
  physical id: 2
  slot: L2 Cache
  size: 256KiB
  capacity: 256KiB
  capabilities: synchronous internal write-back unified
  configuration: level=2
 *-cache:3
  description: L3 cache
  physical id: 3
  slot: L3 Cache
  size: 3MiB
  capacity: 3MiB
  capabilities: synchronous internal write-back unified
  configuration: level=3
 *-cpu
  description: CPU
  product: Intel(R) Core(TM) i5-5250U CPU @ 1.60GHz
  vendor: Intel Corp.
  physical id: 4
  bus info: cpu@0
  version: 6.61.4
  slot: U3E1
  size: 2648MHz
  capacity: 2700MHz
  width: 64 bits
  clock: 25MHz
  capabilities: lm fpu fpu_exception wp vme de pse tsc msr pae 
mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr 
sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp x86-64 constant_tsc 
arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid 
aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg 
fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt 
tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch 
cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi 

bug#58320: Hurd VM fails to boot on AMD EPYC (kvm-amd)

[Samuel Thibault]

Ludovic Courtès, le jeu. 06 oct. 2022 15:14:13 +0200, a ecrit:
> such that it would stop on each trap, hopefully allowing me to see why
> exec is not starting.

Also, better use exec.static to have static addresses.

We use the dynamic version of exec "just because we can", but that makes
debugging difficult.

Samuel

bug#58320: Hurd VM fails to boot on AMD EPYC (kvm-amd)

[Samuel Thibault]

Ludovic Courtès, le ven. 07 oct. 2022 10:24:22 +0200, a ecrit:
> trap, eip 0xc10305c1  
>   
> Breakpoint at  task_terminate:  pushl   %ebp  
>   
> db> show all threads  
>   
> TASKTHREADS   
>   
>   0 gnumach (f5f7cf00): 7 threads:
>   
>   0 (f5f7be18) .W..N. 0xc11dac04  
>   
>   1 (f5f7bcd0) R..O..(idle_thread_continue)   
>   
>   2 (f5f7bb88) .W.ON.(reaper_thread_continue) 0xc12015d4  
>   
>   3 (f5f7ba40) .W.ON.(swapin_thread_continue) 0xc11f8e2c  
>   
>   4 (f5f7b8f8) .W.ON.(sched_thread_continue) 0
>   
>   5 (f5f7b7b0) .W.ON.(io_done_thread_continue) 0xc1201f74 
>   
>   6 (f5f7b668) .W.ON.(net_thread_continue) 0xc11db0a8 
>   
>   1 ext2fs (f5f7ce40): 6 threads: 
>   
>   0 (f5f7b520) .W.O.F(mach_msg_continue) 0
>   
>   1 (f5f7b290) .W.O..(mach_msg_receive_continue) 0
>   
>   2 (f5f7b148) .W.O..(mach_msg_receive_continue) 0
>   
>   3 (f5f7b000) .W.O..(mach_msg_continue) 0
>   
>   4 (f67d4e20) .W.O..(mach_msg_receive_continue) 0
>   
>   5 (f67d4cd8) .W.O..(mach_msg_continue) 0
>   
>   2 exec (f5f7cd80): (f5f7b3d8) R.
>   
> db> trace/t 0xf5f7b3d8
>   
> task_terminate(f625eb10,0,f5f7cd80,f5f7b3d8,c11da940) 
>   
> exception_try_task(1,1,bffefffc,,c1202b4c)+0x58   
>   
> exception(1,1,bffefffc,c10096da,f5957fbc)+0x7a
>   
> interrupted_pc(1,1,bffefffc,c102ce99,c1202b40)
>   
> trap_name(1,f5957f80,f5f73f4c,f5f73f58)   
>   
> vm_fault(f5f6ff30,bffef000,3,0,0,c1008ee4,f5f82550,fb7d9000)+0x74a
>   
> user_trap(f5f7a718)+0x2df 
>   
> > Page fault (14) at 0x1000 < 
> >   
> > user space <
> >   
> db> show map $map2
>   
> Map 0xf5f6ff30: name="exec", pmap=0xf5f71fa8,ref=1,nentries=5 
>   
> size=290816,resident:290816,wired=0   
>   
> version=14
>   
>  map entry 0xf625ec08: start=0x0, end=0x1000  
>   
>  prot=1/7/copy, object=0xf5f6a7d0, offset=0x0 
>   
>   Object 0xf5f6a7d0: size=0x1000, 1 references
>   
>   1 resident pages, 0 absent pages, 0 paging ops  
>   
>memory object=0x0 (offset=0x0),control=0x0, name=0xf5938968
>   
>uninitialized,temporary  internal,copy_strategy=0  
>   
>shadow=0x0 (offset=0x0),copy=0x0   
>   
>  map entry 0xf625ebb0: start=0x1000, end=0x26000  
>