bug#61967: guix pack error with python packages

[Josselin Poiret via Bug reports for GNU Guix]

Hi Cayetano,

Cayetano Santos via Bug reports for GNU Guix  writes:

> Hello guix,
>
>   I’m trying to deploy a test set of python packages to a remote server,
>   using the following guix pack command (latest guix, as for now)
>
> guix pack -R --compression=xz --save-provenance \
> -S /.guix-profile/bin=bin -S /.guix-profile/share=share \
> -S /.guix-profile/etc=etc -S /.guix-profile/lib=lib \
> -S /.guix-profile/include=include
>
>   The resulting file.tar.xz is sent to the server with
>
> scp file.tar.xz server:/dir1/dir2/.

This is most likely [1], which hasn't been fixed yet but I have a patch
to that effect.  The problem is that it would cause a lot of rebuilds so
I haven't sent it yet, I'll send it after the core-updates merge.

[1] https://issues.guix.gnu.org/53258
mid: 67e7d225-f824-b691-7125-6b37abef8...@felsoci.sk

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#61809: (gnu home services xdg): Wrong value for $XDG_STATE_HOME

[Bruno Victal]

Hi Philip,

Can you test the patches in ?


Cheers,
Bruno

bug#61986: Installing qemu-binfmt with support for emulating the host architecture breaks everything

[J. Sims]

Hey y'all,

I recently setup virtualization on my Guix machine (both libvirt and qemu, for 
different purposes). While configuring libvirt (via virt-manager), I got a bit 
confused about how to make things work and also installed qemu-binfmt for 
x86_64, the host architecture. Upon my next reboot, however, I reached a 
fully-booted TTY and was unable to do anything else. GDM was not launching, and 
if I attempted to login to the TTY itself, I was greeted by an error message 
like the following:

"cannot execute /gnu/store/path-to-something/bin/thing: Too many layers of 
symlinks"

After some misadventures, I have finally narrowed down that the cause of this 
issue was having x86_64 in the list of qemu-binfmt-configuration platforms 
while running on x86_64. I assume that including the host architecture in the 
list of platforms for qemu-binfmt will do this regardless of architecture, but 
cannot currently test this.

Here's what I believe to be a minimum reproducible example for x86_64:

```
(operating-system
 ...
 (services (cons*
 (service qemu-binfmt-service-type
  (qemu-binfmt-configuration
(platforms (lookup-qemu-platforms "x86_64"
   ...)
 ...)
```

Good luck,
Juli

bug#61987: 'current-guix' uses configure flags of Git checkout

[Winter via Bug reports for GNU Guix]

Hi,

Given the following commands from a fresh checkout (after the keyring branch 
has been fetched and 'guix git authenticate' has been run):

./bootstrap
./configure --localstatedir=/var --sysconfdir=/hi/guix
make
./pre-inst-env guix system image -t iso9660 gnu/system/install.scm

Booting the resulting ISO will result in the installer running a Guix instance 
that has a sysconfdir of '/hi/guix', which can be checked by looking at the 
contents of '/run/current-system/profile/share/guile/site/3.0/guix/config.scm':

(define-public %sysconfidr "/hi/guix")

This is caused because the installer uses 'current-guix', and it seemingly does 
not reconfigure the build (likely due to the use of 'channel-build-system').

Thanks,
Winter

bug#61469: Xfce window snapping broke with latest upgrade

[Nathan Dehnel]

Turns out the setting for this is called "tiling" in xfce, not
"snapping". So I was able to re-enable it. This can probably be
closed.

On Mon, Feb 13, 2023 at 12:22 AM 宋文武  wrote:
>
> Nathan Dehnel  writes:
>
> > Latest guix pull and reconfigure caused window snapping to stop
> > working in XFCE. I have tried toggling it off and on a few times in
> > the settings.
> > Current generation: ccf742f120452acf587d16e40adea570d15169c4
> > Previous generation: 658c09333da095edf6e1b3c5e351a7bfa3c87354
> Hello, it does works for me here.
>
> Note that only snapping up upon the default pannel will prevent it
> moving future.  For other directions, if you drag too much, the window
> will escape the snap and move to another workspace...

bug#55639: time-machine back in 2020: weird error

[Nicolò Balzarotti]

Hi, I think I'm experiencing the same issue.
I need opencv 3.4, found a commit with it 
(63856931dbe1e72311b472347331ce1c16b0de0b)


On two machines
> guix describe:
 guix eb87d2c

> guix describe:
 guix 59b102c

guix time-machine --commit=63856931dbe1e72311b472347331ce1c16b0de0b -- 
build opencv


Computing Guix derivation for 'x86_64-linux'... Backtrace:
  5-(primitive-load 
"/gnu/store/d5llsvv8g1idnm87q7cs4r5a4s0…")

In ice-9/eval.scm:
   155:9 4 (_ _)
   159:9 3 (_ #(#(#(#(#(#(#(#(#(#(#(…) …) …) …) …) …) …) 
…) …) …) …))
  173:47 2 (_ #(#(#(#(#(#(#(#(#(#(#(…) …) …) …) …) …) …) 
…) …) …) …))

In ./guix/self.scm:
   914:4 1 (guix-derivation "/gnu/store/hp2afllp9vsp4kmr67nrhr8ig…" 
…)

   885:2 0 (guile-for-build "3.0")

./guix/self.scm:885:2: In procedure guile-for-build:
Throw to key `match-error' with args `("match" "no matching pattern" 
"3.0")'.
guix time-machine: error: You found a bug: the program 
'/gnu/store/d5llsvv8g1idnm87q7cs4r5a4s0kxyap-compute-guix-derivation'
failed to compute the derivation for Guix (version: 
"63856931dbe1e72311b472347331ce1c16b0de0b"; system: "x86_64-linux";
host version: "59b102cab9d66ba0c561ed9ed8df04f9fc340bd2"; pull-version: 
1).

Please report it by email to .


Same happens with --no-grafts, on both machines.

Any idea on what is causing it?

Thanks!

bug#61469: Xfce window snapping broke with latest upgrade

[宋文武 via Bug reports for GNU Guix]

Nathan Dehnel  writes:

> Turns out the setting for this is called "tiling" in xfce, not
> "snapping". So I was able to re-enable it. This can probably be
> closed.

Cool!  Close now, thank you!

bug#61987: 'current-guix' uses configure flags of Git checkout

[Winter via Bug reports for GNU Guix]

I've tried to dig deeper into this, but am stumped by an issue: editing 
'build-aux/build-self.scm' isn't actually doing anything.

After applying this diff, the status message still prints out when running 
'./pre-inst-env guix build -e "((@ (gnu packages package-management) 
current-guix))"':

diff --git a/build-aux/build-self.scm b/build-aux/build-self.scm
index 02822a2ee8..607a7ac0cd 100644
--- a/build-aux/build-self.scm
+++ b/build-aux/build-self.scm
@@ -461,8 +461,6 @@ files."
(logior major minor))
   "none")
   node))
-(format (current-error-port) "Computing Guix derivation for '~a'...  "
-system)

 ;; Wait for a connection on SOCK and proxy build output so it can be
 ;; processed according to the settings currently in effect (build

However, (guix channels) is definitely reading build-self, as changing the path 
it reads it from to a nonexistent path causes the build to throw, as expected.

The same goes for if I edit any module except for some values in (guix config) 
-- 'current-guix' never gets rebuilt.

I'd appreciate any help in figuring this out.

Thanks,
Winter