bug#70841: Upgrade-Shepherd-Services Error when adding wayland support to gdm

[Josselin Poiret via Bug reports for GNU Guix]

Hi,

not emma via Bug reports for GNU Guix  writes:

> guix system: error: error parsing derivation
> `/gnu/store/4xz1998qw8niax3pi0lsbwxfl7dfrpil-
>
> upgrade-shepherd-services
>
> .drv':
> expected string `Derive(['

This looks like a store integrity issue, you might want to repair it
using `guix gc --verify=contents,repair`.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#69284: guix pull is not reproducible

[Josselin Poiret via Bug reports for GNU Guix]

Hi Andrew,

Andrew Tropin via Bug reports for GNU Guix  writes:

> I don't think that hash of the profile depends on the building process
> itself.  And it seems on the same system it returns the same result on
> consequent rebuilds.  It seems something leaks from the environment.

Yes, it's rather that the .drv themselves are not reproducible
apparently.  Can you compare the derivations building the guixes in the
different profiles?  You can look at them using first `guix gc
--derivers` on the profile and then analyzing the .drv manually.  I
remember seeing the same thing, but I don't really remember anything
conclusive.

One thing I can say is that Guix generates the .drv dynamically by
looking at the check-out.  If the checkout is somehow tainted (as it has
often happened, maybe because of libgit2?), the .drv can end up being
different.  If you retry by first resetting the Guix checkouts in
~/.cache/guix/checkouts/ to a pristine state, do you still get a
discrepancy?

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#69487: Regression regarding guix shell and its "pure" flag?

[Josselin Poiret via Bug reports for GNU Guix]

Hi André

André A. Gomes  writes:

> Hi Guix,
>
> Take a package that you have installed in the default profile, say
> "which".  Then notice that when issuing "guix shell --pure" followed by
> "which which" replies that the command can't be found.  On the other
> hand, when starting the environment via "guix shell", the command can be
> found.
>
> If my memory isn't tricking me, the "pure" flag used to behave
> differently.  It simply started the shell with a clean env, but it still
> exposed the packages from the default profile.  Am I missing something
> or is this a regression?

No, this is `--pure` working as expected, the other behavior you
describe would be considered a bug.  Maybe you used to have the default
profile loaded through .bashrc, even though this is discouraged exactly
for that reason?

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#69319: Unbootable, unfixable system

[Josselin Poiret via Bug reports for GNU Guix]

Hi Nathan,

Nathan Dehnel  writes:

> This config results in grub rescue "unknown filesystem  btrfs rootfs>" when I try to boot it. I have verified that all the
> device uuids are correct, and the bootloader, mapped-devices, and
> file-systems sections are identical in form to my other system which
> boots fine. i can mount the boot partition and unlock and mount the
> root partition manually, so they're not broken. I have no idea why
> it's not working. My guess is that reconfigure is broken inside a
> chroot somehow.

I see you're using LUKS.  Is it LUKS1 or LUKS2?  LUKS2 unfortunately
doesn't work at present, because we're still on Grub 2.06.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#69125: python-trio transient test failures

[Josselin Poiret via Bug reports for GNU Guix]

Hi Oleg,

Sharlatan Hellseher  writes:

> Maybe it's time to update it or disable some shaky tests.
>
> WDYT?

I agree, I was looking into this on core-updates but didn't want to
commit to updating this as it also needs some dependency upgrades.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#69127: guix pull bug

[Josselin Poiret via Bug reports for GNU Guix]

Hi Ryan
Ryan Barber  writes:

> guix pull requested I send over this bug report. fresh debian bookworm
> install as a vm in google cloud. guix installed via apt. vm has minimal
> specs - 1gb ram, single core, which might be the issue.

That's most likely it, `guix pull` requires quite a lot of RAM
unfortunately.  It's something everyone would like to fix but it
requires a non-trivial amount of work that no-one has committed to for
now :(

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#69125: python-trio transient test failures

[Josselin Poiret via Bug reports for GNU Guix]

Hi everyone,

python-trio sometimes exhibits test failures, as in the following

--8<---cut here---start->8---
=== FAILURES ===
 test_wait_reapable_fails[open_process] 
[gw15] linux -- Python 3.10.7 
/gnu/store/375350pi1l1izgnx6dnsqmg4xjyprx8q-python-wrapper-3.10.7/bin/python

background_process = 

@pytest.mark.skipif(not posix, reason="POSIX specific")
@background_process_param
async def test_wait_reapable_fails(background_process):
>   old_sigchld = signal.signal(signal.SIGCHLD, signal.SIG_IGN)

trio/tests/test_subprocess.py:449: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

signalnum = , handler = 

@_wraps(_signal.signal)
def signal(signalnum, handler):
>   handler = _signal.signal(_enum_to_int(signalnum), _enum_to_int(handler))
E   ValueError: signal only works in main thread of the main interpreter

/gnu/store/91wasjkmy50p8fq0rf9jby80mnmq1fxr-python-3.10.7/lib/python3.10/signal.py:56:
 ValueError
___ test_wait_reapable_fails[run_process in nursery] ___
[gw15] linux -- Python 3.10.7 
/gnu/store/375350pi1l1izgnx6dnsqmg4xjyprx8q-python-wrapper-3.10.7/bin/python

background_process = 

@pytest.mark.skipif(not posix, reason="POSIX specific")
@background_process_param
async def test_wait_reapable_fails(background_process):
>   old_sigchld = signal.signal(signal.SIGCHLD, signal.SIG_IGN)

trio/tests/test_subprocess.py:449: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

signalnum = , handler = 

@_wraps(_signal.signal)
def signal(signalnum, handler):
>   handler = _signal.signal(_enum_to_int(signalnum), _enum_to_int(handler))
E   ValueError: signal only works in main thread of the main interpreter

/gnu/store/91wasjkmy50p8fq0rf9jby80mnmq1fxr-python-3.10.7/lib/python3.10/signal.py:56:
 ValueError
=== short test summary info 
FAILED trio/tests/test_subprocess.py::test_wait_reapable_fails[open_process]
FAILED trio/tests/test_subprocess.py::test_wait_reapable_fails[run_process in 
nursery]
== 2 failed, 371 passed, 17 skipped in 3.82s ===
--8<---cut here---end--->8---

Note that I am on Linux 6.8-rc3 currently.  Can anyone reproduce?

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#43049: Add the ability to install Guix System offline

[Josselin Poiret via Bug reports for GNU Guix]

Hi Giovanni,

Giovanni Biscuolo  writes:

>> However, we also implemented the `current-guix` hack that basically uses
>> a guix checkout at the current guix version as the source for the guix
>> package.
>
> So, since some commit, now the guix version used to build the target
> system image is the one checked-out by the person/agent running the
> install image build script: did I understand it correctly?

Yes.

>> In both cases though, we shouldn't see any differences in other
>> package's derivations…
>
> Does this mean you consider possible to pre-populate the /gnu/store
> install system (the one started using the install image) with a substet
> of substitutes possibly needed in the target system?

I think it's already meant to be the case, see the comment in
gnu/system/install.scm about keeping a reference to the bare bones os's
closure.  It wouldn't contain all graphical stuff either, but I think
there's also some trouble with grafts that forces users to still
download substitutes.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#43049: guix installation why internet connection required?

[Josselin Poiret via Bug reports for GNU Guix]

Hi Giovanni,

Giovanni Biscuolo  writes:

> Sorry I don't understand the problem, could you expand please?
>
> The guix (and daemon) versione are those of the channel used when
> creating the install .iso image; booting the 1.40 installer we get a
> "guix version" and "guix describe" value of 989a391...

Not exactly, to include Guix inside the installer image, it somehow
needs to refer to itself.  The way it used to be done was by using the
`guix` package, which necessarily is older than the current commit.
However, we also implemented the `current-guix` hack that basically uses
a guix checkout at the current guix version as the source for the guix
package.  In both cases though, we shouldn't see any differences in
other package's derivations…

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#68874: error while loading shared libraries: /gnu/store/...-guile-3.0.9/lib/libguile-3.0.so.1: file too short

[Josselin Poiret via Bug reports for GNU Guix]

Hi Simon,

Simon Tournier  writes:

> --8<---cut here---start->8---
> $ /tmp/new/bin/guix describe
> /gnu/store/vqkjfl6ds3vdvig2x5pkvvzkc3wivrp0-guile-wrapper/bin/guile: error 
> while loading shared libraries: 
> /gnu/store/1gd9nsy4cps8fnrd1avkc9l01l7ywiai-guile-3.0.9/lib/libguile-3.0.so.1:
>  file too short
> --8<---cut here---end--->8---

File too short sounds like store corruption, can you check whether that
file is empty?  Maybe try gc'ing it and retrying?

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#68834: Bug report, as requested by the software.

[Josselin Poiret via Bug reports for GNU Guix]

Hi Randy,

"Randy Farmer"  writes:

> ERROR: In procedure %resolve-variable:
> error: go-github-com-tdewolff-minify-v2: unbound variable

This should have been fixed by c4687f5437ad89a7e87deed1933b60f6eac83176.
Can you retry a new guix pull?

Closing for now, if you still encounter the same issue, please let us know.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#68835: Resolving package inheritance issue

[Josselin Poiret via Bug reports for GNU Guix]

Hi Oleg,

Sharlatan Hellseher  writes:

> Long story short, how to resolve package inheritance which would not
> break CI ;-) ?
>
> [...]
>
> My rational was to keep golang module in (gnu packages golang-web) and
> the new inherited package providing executable in (gnu packages web)
> which introduced the regression.

Please see "(guix) Cyclic Module Dependencies" in the manual, it
contains some explanations around this kind of issue.

I'd suggest not separating inherited packages in different modules.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#68747: Extending postgresql-role-service-type as shown in manual leads to crash

[Josselin Poiret via Bug reports for GNU Guix]

Hi Maxim,

I guess this is not explained that well, but the service-extension
snippet is supposed to go under the (extensions ...) field of a
 record.  If you want to extend this in your system
config, you want (simple-service ...) instead, with e.g.

--8<---cut here---start->8---
(simple-service 'alice-role postgresql-role-service-type
(postgresql-role
 (name "alice")
 (create-database? #t)))
--8<---cut here---end--->8---

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#68760: I guess I found a bug in "guix pull" ?

[Josselin Poiret via Bug reports for GNU Guix]

Hi,

jbranso--- via Bug reports for GNU Guix  writes:

>  message: "error parsing derivation 
> `/gnu/store/3nppfdxy9vgg9ls6qi8j8pkzw2khi98h-git-minimal-2.41.0.drv': 
> expected string `Derive(['"
>  status: 1
> guix pull: error: You found a bug: the program 
> '/gnu/store/m9z876jpmpbslc6qaikbp9fk5dv01y3n-compute-guix-derivation'

Looks like the elusive "empty drv" bug (maybe caused by fs corruption?).
Can you `guix gc -D` that drv and retry?

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#68811: build hash inconsistency

[Josselin Poiret via Bug reports for GNU Guix]

Hi Zacchaeus,

Can you try the same, but this time with the --no-grafts option?  That
could be a source of issues.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#68483: Qutebrowser QT platform plugin could not be initialized

[Josselin Poiret via Bug reports for GNU Guix]

Hi chris, 

chris  writes:

> Related to https://issues.guix.gnu.org/67289#7
>
> Here is the qutebrowser 3 process shell output. Would anyone recommend a 
> solution?
> ```
> $ qutebrowser
> 20:40:33 WARNING: Could not find the Qt platform plugin "wayland" in ""

Have you installed qt-wayland?  Are you setting QT_QPA_PLATFORM
anywhere?

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#68413: Ungexp doesn't work on deep lists

[Josselin Poiret via Bug reports for GNU Guix]

Hi Ludo,

Ludovic Courtès  writes:

> Actually, what bug are we talking about?  It seems to work for me with
> this example:
>
> --8<---cut here---start->8---
> scheme@(guile-user)> (define packages `(("coreutils" ,coreutils) ("make" 
> ,gnu-make)))
> scheme@(guile-user)> ,build (scheme-file "foo" #~(begin '#$packages))
> building /gnu/store/lq9gvbilv0y2nph00zxk6bn3lvcgdxqq-foo.drv...
> $7 = "/gnu/store/9ryh6v80jvjv3kwx0q782h26h9gbaclj-foo"
> scheme@(guile-user)> (call-with-input-file $7 get-string-all)
> $8 = "(begin (quote ((\"coreutils\" 
> \"/gnu/store/mppp9hwxizx9g9pikwcvvshb2ffxyq7p-coreutils-9.1\") (\"make\" 
> \"/gnu/store/9fadhs5qmwl5x7f669a0v39b3ryrmmf1-make-4.3\""
> --8<---cut here---end--->8---
>
> One of the design decisions for gexps was to ensure that substituting a
> file-like object by its file name would be O(1) in most cases.
>
> Substitution in lists as in the example above is supported, but
> primarily for backward compatibility.  It should be avoided when
> possible because it’s inefficient: ‘gexp->sexp’ needs to traverse the
> whole list/tree in search of potential candidates.

Notice that OP's example uses `(("thing" . ,package)), ie. lists of
pairs and not lists of lists, as in your case!

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#68340: coreutils-mesboot-9.1 failed

[Josselin Poiret via Bug reports for GNU Guix]

Hi Jing,

Jing Luo via Bug reports for GNU Guix  writes:

> building 
> /gnu/store/9dspz8w4i6c9wkdskirv4rj6lmsgp54c-coreutils-mesboot-9.1.drv...
> | 'build' phasebuilder for 
> `/gnu/store/9dspz8w4i6c9wkdskirv4rj6lmsgp54c-coreutils-mesboot-9.1.drv' 
> failed with exit code 1
> build of 
> /gnu/store/9dspz8w4i6c9wkdskirv4rj6lmsgp54c-coreutils-mesboot-9.1.drv failed
> View build log at 
> '/var/log/guix/drvs/9d/spz8w4i6c9wkdskirv4rj6lmsgp54c-coreutils-mesboot-9.1.drv.gz'.

Can you also include the relevant failing part of
/var/log/guix/drvs/9d/spz8w4i6c9wkdskirv4rj6lmsgp54c-coreutils-mesboot-9.1.drv.gz?

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#68359: Can't pull my channel because of getaddrinfo -8 error

[Josselin Poiret via Bug reports for GNU Guix]

Hi,

"ShinyZero0"  writes:

> Here is my channel i'm trying to pull and keep getting that "SERVICE not
> supported for `ai_socktype'" error
>
> ```
> (channel
>  (name 'zero)
>  (url "https://codeberg.org/shinyzero0/guix-packages.git";)
>  (commit
>   "1eacb7d9e2eb96c9d45b96af006b069e443c9ebc"))
> ```
>
> the full log is
>
> ```
> (repl-version 0 1 1)
> (exception getaddrinfo-error (value -8))
> ```

Isn't that rather related to Codeberg being DDoS'd yesterday?  Can you
retry now?

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#68413: Ungexp doesn't work on deep lists

[Josselin Poiret via Bug reports for GNU Guix]

Hi Justin,

Justin Veilleux  writes:

>> (define packages
>> (list
>>  (cons "coreutils" coreutils)
>>  (cons "make" gnu-make)
>>  ...))
>>
>> #~(for-each
>>(lambda (f)
>>  ... do-something)
>>'#$packages)
>
> If I send a patch to "fix" this, will it be usefull or is there a reason
> for this behavior?

I think IMO that it's a bug, but it's also quite tricky to properly
traverse deep structures like this.  The bug comes from the fact that in
gexp->sexp, we traverse lists by matching the reference with (refs ...),
but that doesn't match if the reference is a pair instead.  Then, it
tries to match with ($  (? self-quoting? x)), which does
match since self-quoting? apparently returns #t on a pair, whether or
not its constituents are also self-quoting.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#68059: Mismatching defconfig options

[Josselin Poiret via Bug reports for GNU Guix]

Hi Lars,

Lars Rustand  writes:

> This issue can be closed.

You can close issues by replying to -d...@debbugs.gnu.org instead of
@, as I'm doing here.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#68032: Bug-Report : Guix

[Josselin Poiret via Bug reports for GNU Guix]

Hi Emanuele,

Emanuele Rodo via Bug reports for GNU Guix  writes:

> ice-9/boot-9.scm:3329:6: In procedure resolve-interface:
> no code for module (gnu packages ed)
> guix pull: error: You found a bug: the program 
> '/gnu/store/krgipw72bxa0m5p52p3frdbkfpbxdyhx-compute-guix-derivation'
> failed to compute the derivation for Guix (version: 
> "2a66a96634b33667a45f4493a37eef48033b7287"; system: "x86_64-linux";
> host version: ""; pull-version: 1).
> Please report the COMPLETE output above by email to .

I think this was recently resolved, can you try again?  I can only guess
your mail reached us now because it had to go through the manual
moderation queue (as is the case for everyone's first email to the
list).

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#67800: File guix-publish.service missing on foreign distro installations

[Josselin Poiret via Bug reports for GNU Guix]

Hi Philippe,

Philippe SWARTVAGHER  writes:

> Hello,
>
> I'm running Guix on a foreign distro, Debian, with systemd. I installed 
> Guix with the shell installer script.
>
> The documentation 
> https://guix.gnu.org/manual/en/html_node/Invoking-guix-publish.html 
> mentions (at the bottom) that I can execute the following command to 
> enable the Guix Publish service:
>
> ln -s ~root/.guix-profile/lib/systemd/system/guix-publish.service 
> /etc/systemd/system/
>
> However, the file 
> ~root/.guix-profile/lib/systemd/system/guix-publish.service does not 
> exist (actually, ~/root/.guix-profile doesn't exist).

As a temporary workaround, you can install the `guix` package in the
root's profile.

The problem stems from the fact that the `guix pull`-built guix doesn't
include many extras that the Makefile-built guix has, like that file.
Maybe we should include it in the `guix pull` build, so that it is
easily available and updated?

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#67806: guix pull error

[Josselin Poiret via Bug reports for GNU Guix]

Hi Qingyun,

qy.tao--- via Bug reports for GNU Guix  writes:

>   1. &store-protocol-error:
>   message: 
> "`/gnu/store/5kj8lyybjrdl7xd0fx9g9vzkz8sklqsy-guix-1.4.0/bin/guix substitute' 
> died unexpectedly"
>   status: 1

This seems to be a transient substitute error, can you retry?

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#68059: Mismatching defconfig options

[Josselin Poiret via Bug reports for GNU Guix]

Hi Lars,

Lars Rustand  writes:

> I'm having trouble building a custom kernel with an included
> defconfig. The kernel builds correctly with the included defconfig if I
> do it manually, but when I try to build it through Guix I get an error
> about Mismatching configurations in .config and
> arch/arm64/configs/guix_defconfig.

Could you post the exact error that you get?

> Since it builds correctly manually I am sure that the defconfig does in
> fact work, and it does not have any mismatching configuration. So it
> must be something that Guix adds/changes in the defconfig that makes it
> stop working. How can I prevent Guix from modifying the defconfig that I
> tell it to use?

Guix doesn't modify the defconfig you give it, it just moves it to
guix_defconfig.  However, it then tries to verify that the defconfig was
properly applied, which is completely Guix-specific and might be the
thing that doesn't work properly.

> Here is the relevant part of my package definition:
>
> --8<---cut here---start->8---
> (let ((linux-package
>(customize-linux
> #:name name
> #:linux linux
> #:defconfig
> "pinephone_pro_defconfig"
> #:extra-version "arm64-pinephone-pro"
> #:source (origin (method url-fetch)
>  (uri (linux-pinephone-urls version))
>  (sha256 (base32 hash)))
> --8<---cut here---end--->8---

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#67956: bug

[Josselin Poiret via Bug reports for GNU Guix]

Hi Sebastian,

Sebastian Boccardi  writes:

> host version: "1.2.0"; pull-version: 1).

Where is your Guix daemon from?  It seems fairly ancient at this point
(a couple of years old) and should be upgraded.  It might not be the
cause of the problem but that might be a good thing to do first.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#66786: Failed to install

[Josselin Poiret via Bug reports for GNU Guix]

Hi,

You can close the issue yourself by cc'ing n-d...@debbugs.gnu.org,
where  is the bug number, as I've done here.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#66866: aarch64 system cross compilation + pinebook pro image broken?

[Josselin Poiret via Bug reports for GNU Guix]

Hi dan,

dan  writes:

> with git bisect i found after this commit the cross-compilation 
> couldn't work anymore:

Could you post some more details about what you mean by "couldn't work"?
What exactly is failing, and with what logs?

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#66864: emacs-build-system builds .eln-files with mismatching path-hashes

[Josselin Poiret via Bug reports for GNU Guix]

Hi,

Liliana Marie Prikler  writes:

> Am Donnerstag, dem 02.11.2023 um 08:13 + schrieb Mekeor Melire:
>> 
>> 2023-11-01 15:16 liliana.prik...@gmail.com:
>> 
>> > I think Emacs might be calculating its own hash at runtime 
>> > rather than baking in the value at build time.
>> 
>> Exactly. That's what I was trying to express.
> I'm not sure whether this is reproducible.  On my system
>   $ guix build emacs-dash --with-input=emacs-minimal=emacs
>   /gnu/store/zr16hd25338imljqxxfsf07smbfv3wxd-emacs-dash-2.19.1
>   $ ls 
> /gnu/store/zr16hd25338imljqxxfsf07smbfv3wxd-emacs-dash-2.19.1/lib/emacs/native-site-lisp
>   29.1-e9e5c1ce
>   $ emacs --batch --eval='(message "%s" comp-abi-hash)'
>   e9e5c1ce
> Looks like everything's alright?

It's the .eln file itself that has the hash of the .el's path in its
name.  That's computed by `comp-el-to-eln-filename`.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#66786: Failed to install

[Josselin Poiret via Bug reports for GNU Guix]

Hi Caleb,

Caleb Herbert  writes:

> On Sat, 2023-10-28 at 11:05 +0200, Josselin Poiret wrote:
>> Was this using the 1.4 installer or the latest one?  If it was the
>> former, can you please try with latest?  
>
> Done. Same error.

Not exactly, this time it's a

--8<---cut here---start->8---
guix substitute: error: TLS error in procedure
'write_to_session_record_port': Error in the push function.
--8<---cut here---end--->8---

Not sure what the issue is though, maybe someone else has a better idea?
These kinds of errors are usually transient, so you might have better
luck retrying with a manual install and pushing through when doing the
`guix system init` as a workaround for now.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#66786: Failed to install

[Josselin Poiret via Bug reports for GNU Guix]

Hi Caleb,

Caleb Herbert  writes:

> The dump was uploaded as installer-dump-c4fd6109. Please report it by
> email to bug-guix@gnu.org.

Was this using the 1.4 installer or the latest one?  If it was the
former, can you please try with latest?  I can spot a "write_wait_fd:
unimplemented" exception, which IIRC was fixed after the 1.4 release.
In any case, it was a transient error so you might want to retry
anyways.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#66746: LUKS password prompt invisible, prompts twice

[Josselin Poiret via Bug reports for GNU Guix]

Hi Caleb,

Caleb Herbert  writes:

> Hardware: ThinkPad X200
> Firmware: Libreboot 2016
> OS: Guix System
>
> Expected behavior:
> Password prompt. Enter LUKS passphrase. Log into computer.
>
> Actual behavior:
> Password prompt. Enter LUKS passphrase. Select boot option from GRUB menu. 
> Hangs, no password prompt. Enter passphrase (again) anyway: Boots normally.

I think this is a combination of two things: first, we currently need to
unlock the drive once for GRUB, and then once when Linux boots, hence
the two password prompts.  This is a known limitation, but the usual
workaround of adding a keyfile to the initrd wouldn't work in our case
for security reasons: the keyfile would end up in the store and be
world-readable, a disaster.

Regarding the second prompt being invisible, I think it might be related
to the framebuffer initialization for Libreboot since there have been
lots of reports about this.  I don't know anything myself, but maybe
someone else could chime in?

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#66461: [PATCH] guix: import: opam: Handle list of licenses.

[Josselin Poiret via Bug reports for GNU Guix]

From: Josselin Poiret 

* guix/import/opam.scm (opam->guix-package): Handle lists of licenses.
---
Hello Simon,

Here's a quick fix.

Best,
Josselin

 guix/import/opam.scm | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/guix/import/opam.scm b/guix/import/opam.scm
index e67146e593..86e82cde59 100644
--- a/guix/import/opam.scm
+++ b/guix/import/opam.scm
@@ -379,8 +379,10 @@ (define* (opam->guix-package name #:key (repo '("opam")) 
version #:allow-other-k
   (synopsis ,(metadata-ref opam-content "synopsis"))
   (description ,(and=> (metadata-ref opam-content "description")
beautify-description))
-  (license ,(spdx-string->license
- (metadata-ref opam-content "license"
+  (license ,(match (metadata-ref opam-content "license")
+  ((('string-pat strs) ...)
+   `(list ,@(map spdx-string->license strs)))
+  ((? string? str) (spdx-string->license str)
(filter
  (lambda (name)
(not (member name '("dune" "jbuilder"

base-commit: d2923babf3ac44cb6faa88317f77c98f3016820d
-- 
2.41.0

bug#65889: texlive-acronyms is missing dependencies

[Josselin Poiret via Bug reports for GNU Guix]

Hi Nicolas,

Nicolas Goaziou  writes:

> We use dependencies specified in TeX Live itself (as in "texlive.tlpdb"
> file), for sanity reasons. There are 4000+ packages; I think it is not
> reasonable to grep through their output to find the unspecified
> dependencies. It will also be terrible when using some updater, now this
> tool can remove propagated inputs.

Couldn't we report those missing dependencies upstream then?

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#65889: texlive-acronyms is missing dependencies

[Josselin Poiret via Bug reports for GNU Guix]

Hi Nicolas,

Nicolas Goaziou  writes:

> We use dependencies specified in TeX Live itself (as in "texlive.tlpdb"
> file), for sanity reasons. There are 4000+ packages; I think it is not
> reasonable to grep through their output to find the unspecified
> dependencies. It will also be terrible when using some updater, now this
> tool can remove propagated inputs.

Couldn't we report those missing dependencies upstream then?

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#65804: Bug report: "You found a bug"

[Josselin Poiret via Bug reports for GNU Guix]

Hi Lasse,

Lasse Schlör  writes:

> As requested by Guix, I am reporting the bug with this email.
>
> I assume this bug happened upon a temporary loss of the internet connection. 
> Running the command anew continued fetching/downloading just fine.

Seems to be the case, yes.  Closing.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#65769: greetd-wlgreet-sway-session result is blinking cursor

[Josselin Poiret via Bug reports for GNU Guix]

Hi chris,

chris  writes:

> Josselin sent this message intended for the thread and I think they are okay 
> with re-pasting here,
>
>> Usually elogind is responsible (through a PAM module) for creating this 
>> runtime directory.  If you're not using elogind, you'll need to create this 
>> directory yourself somehow.  I don't really think this is a bug per-se, as 
>> running without elogind is advanced stuff and its consequences should be 
>> understood by the user.

oops, sorry for not replying to all (the cardinal sin of email conversation).

> I support any conclusion from Josselin and unmatched-paren and want to add 
> these observations,
>  * wlgreet *does require* the greeter lock file
>  * wlgreet *does not require* elogind/logind 
>  * not-advanced users like me may want to use wlgreet without elogind

I'd still like feedback from actual users of wlgreet, as I have not used
it myself.  I do believe the only way it could work is because something
takes care of creating the runtime directory.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#65759: Bug

[Josselin Poiret via Bug reports for GNU Guix]

Hi Sjors,

"Sjors Provoost"  writes:

> Hi Josselin,
>
> Restarting the command a few times it kept failing at different packages, but 
> eventually made it through just fine.

Glad it ended up working!  Maybe an issue of builds OOM'ing, if the
machine was already under some load?

> The building machine is indeed x86_64-linux, the Bitcoin projects uses cross 
> compilation to make binaries for macOS (and requires you to download the SDK 
> and run a script to extract some stuff from it).

That's nice to know, thanks!

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#65759: Bug

[Josselin Poiret via Bug reports for GNU Guix]

Oops, forgot to close.  Feel free to re-open if something was missing.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#65725: Acknowledgement (guix pull fails on riscv64)

[Josselin Poiret via Bug reports for GNU Guix]

Hi,

much.effort283--- via Bug reports for GNU Guix 
writes:

> Since openssl is already bumped from "1.1.1l" to a version that has
> the bug fixed in the development branch, I presume this will be fixed
> once the next guix release (1.5) is out?

`guix pull` should pull the latest available commit on master, and so it
should use the newer openssl version there.  Can you retry, after rm'ing
.cache/guix/checkouts?  If it still mentions 1.1.1l, we might have a bug
in `guix pull`.

> In the meantime, I wonder if there is a workaround I can apply. I
> tried compiling from source, but that seems to fail as well:

Unfortunately, the latest source requires a patched po4a that was added
very recently.  I don't know if you can confidently build all of Guix
locally without the doc, I haven't inspected the Makefile too closely.

Sorry I couldn't be of much help.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#65769: wlgreet-sway-session

[Josselin Poiret via Bug reports for GNU Guix]

Hi chris,

chris  writes:

> This directory for the greeter user does not exist in the system /run/user/986

Do you use elogind?

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#65759: Bug

[Josselin Poiret via Bug reports for GNU Guix]

Hi Sjors,

Sjors Provoost  writes:

> $ HOSTS='x86_64-apple-darwin arm64-apple-darwin' ./contrib/guix/guix-build || 
> echo -e "\a"

Guix doesn't support apple-darwin as a system.  I don't know how the
bitcoin project does it, but you probably want to report this to them
instead.  I don't see anything immediately wrong with the log here as
well.

> guix time-machine: error: You found a bug: the program 
> '/gnu/store/6is1k9037hzkbjgwrc1zs6v5z26i23ly-compute-guix-derivation'
> failed to compute the derivation for Guix (version:
> "160f78a4d92205df986ed9efcce7d3aac188cb24"; system: "x86_64-linux";

It seems that guix believes it is building on x86_64-linux.  I don't
know if this is a bug or feature, you'll have to see with the bitcoin
project.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#65720: Guile-Git-managed checkouts grow way too much

[Josselin Poiret via Bug reports for GNU Guix]

Hi Ludo,

Ludovic Courtès  writes:

> Surely you’d agree that it would suck though: depending on two Git
> implementations because one doesn’t have a proper API and the other one
> lacks a bunch of features.

Right, although I wouldn't necessarily say that the former doesn't have
a proper API, but rather that it has a Unix-oriented API.  That leads to
performance issues on e.g. Windows but on Linux I'm not sure there's
much of a difference.

> It would also be pretty bad for closure size:
>
> --8<---cut here---start->8---
> $ guix size guile-git | tail -1
> total: 106.6 MiB
> $ guix size guile-git git-minimal | tail -1
> total: 169.8 MiB
> --8<---cut here---end--->8---
>
> It’s also not clear concretely how we’d add that dependency.  Try
> invoking ‘git’ from $PATH and print a warning if it doesn’t work?
> But then, what about applications like Cuirass and hpcguix-web?
>
> Tricky, tricky.

We could consider replacing the guile-git dependency with another
library built directly on top of git-minimal, and have this be a
dependency of Guix.  Not ideal though, and not really scalable either:
we can't just add every VCS as direct dependencies.

From what I've seen, people are now scaling back on their use of
libgit2 because of the impedence mismatch and are resorting more and
more to git plumbing.  From a pragmatic point of view, I'd prefer the
latter, since it is more stable and feature-complete.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#65720: Guile-Git-managed checkouts grow way too much

[Josselin Poiret via Bug reports for GNU Guix]

Hi Ludo,

Ludovic Courtès  writes:

> My inclination for the short term would be to work around this
> limitation by (1) finding a heuristic to determine is a checkout has
> likely accumulated too much cruft, and (2) considering such checkouts as
> expired (thereby forcing a re-clone) or running ‘git gc’ on them if
> ‘git’ is available.

I think using the git binary instead of libgit2 as a workaround is a
good idea.  We can consider building it directly as well, so that people
who don't have it in their profiles can still benefit from it.  We could
even consider using git commands in most places and using libgit2 only
where we really need the tight coupling.  IIUC, libgit2 is eternally
trying to catch up to git and often performs in a counter-intuitive way
(I expect the various bugs with stale deleted files in checkouts to be
caused by this).  Maybe it could also let us use bare repository and
directly extract the refs we want without having to mess with checkouts?

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#65523: package `guile@3.0.9' has an invalid input: ("_" #)

[Josselin Poiret via Bug reports for GNU Guix]

Hi Paul,

Paul Alesius  writes:

> In the source code directory of Guix, when trying to build a package from
> gnu/packages/python-xyz.scm, it fails with the following error:
>
> guix build: error:
> /storage/src/guix/guix-gnu/guix/build-system/gnu.scm:146:8: package
> `guile@3.0.9' has an invalid input: ("_" #)

Usually, if you see `#` anywhere in an error,
that means that something that used to be just a variable was turned
into a macro, but the other modules using it weren't recompiled
(reminder that macro expansion happens at compilation time).  This
happens because Guile doesn't have any dependency tracking!  You can
work around this by recompiling all files containing a reference to
pkg-config, I usually do `grep -Rl pkg-config --include '*.go' . | xargs
rm`, followed by `make`.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#65549: Issue during "guix pull"

[Josselin Poiret via Bug reports for GNU Guix]

Hi Philip,

Philip Kaludercic  writes:

> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> ERROR:
>   1. &http-get-error:
>   uri: #< scheme: https userinfo: #f host: "ci.guix.gnu.org" port: 
> #f path: "/nar/lzip/i4c6yd0n7yhw2qi5217z62zb9n023dk7-automake-1.16.5" query: 
> #f fragment: #f>
>   code: 504
>   reason: "Gateway Time-out"

It looks like you have connectivity issues with ci.guix.gnu.org.  You
might want to retry, or enable other mirrors for substitutes instead,
since ci.guix.gnu.org blocks some territories (not because of Guix
policy, but rather because of where the server is hosted).

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#65461: Cannot compile any Rust projects

[Josselin Poiret via Bug reports for GNU Guix]

Hi everyone,

Josselin Poiret  writes:

> Hi everyone,
>
> Hilton Chain  writes:
>
>> Cc-ing Josselin since they have sent a patch to #63258.
>>
>> Hi Josselin, what's the current state of the patch?  Can you resend it
>> to guix-patches to trigger the build process?
>
> Huh, completely forgot about this.  The patch should still be ready, and
> I don't expect it to cause any problems.  I can have a look and maybe
> merge this afternoon.

Pushed as 6c447ababfb11581a75cff8281e96f701e216692.

A sample hello world should now build with cargo with `guix shell -C
rust rust-cargo gcc-toolchain`.  This is a workaround until we add the
librt.a to the gcc package proper.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#63258: [PATCH] gnu: gcc-toolchain: Add empty librt.a.

[Josselin Poiret via Bug reports for GNU Guix]

Hi everyone,

Josselin Poiret  writes:

> From: Josselin Poiret 
>
> * gnu/packages/commencememnt.scm (make-gcc-toolchain): Add empty librt.a.
> * gnu/packages/base.scm (gcc): Add a warning regarding the missing librt.a.

Pushed as 6c447ababfb11581a75cff8281e96f701e216692.

This does not fully fix this bug though, since the gcc package still
doesn't provide it.  It will incur a world rebuild if we also do that,
so that should be kept for core-updates.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#64593: ‘guix system image’ fails to create image while invoking ‘grub-bios-setup’

[Josselin Poiret via Bug reports for GNU Guix]

Hi,

Pushed d57cab764122af69d52d8cc9c843456044e5d7bc that adds mbr-image-type
and sets it as default.

LMKWYT, closing tentatively.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#57493: [EXT] Re: bug#57493: should allow for customizing home directory permission bits

[Josselin Poiret via Bug reports for GNU Guix]

Hi Dave,

Pushed as e9a5eebc785cb843034b38c5c5a6dd10904bdf2a.

Thanks for your contribution!  Closing.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#62448: [PATCH] doc: Note that `guix shell` should contain base language packages.

[Josselin Poiret via Bug reports for GNU Guix]

Hi everyone,

Simon Tournier  writes:

> Nitpick: Missing double space for sentences.
>
> Otherwise, LGTM.

Pushed as 9f68a2a9c41166ec5ac24c082bcd96c433dd2ede.

Closing.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#65461: Cannot compile any Rust projects

[Josselin Poiret via Bug reports for GNU Guix]

Hi Jonas,

Jonas via Bug reports for GNU Guix  writes:

> Hi! Compiling any Rust projects with cargo/rustc gives me:
>
> error: linking with 
> `/gnu/store/5lqhcv91ijy82p92ac6g5xw48l0lwwz4-gcc-11.3.0/bin/gcc` failed: 
> exit status: 1

Please make sure you add simple reproducers to your bug reports so that
people can check that the bug does get resolved by proposed patches.  I
can't reproduce this with a simple `rustc hello.rs` where `hello.rs` is
the simplest hello world I could find.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#65508: Displaying qt applications on wayland using qtwayland is complicated

[Josselin Poiret via Bug reports for GNU Guix]

Hi Morgan,

Morgan Smith  writes:

> Well if I understand how "guix size" works, then adding qtwayland would only
> add 30 or 80 MiB, which in my opinion isn't a lot.  My vote is on just adding
> qtwayland to all wayland packages (at the cost of a full qt rebuild).

Just dropping by to say that I agree with this!

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#65461: Cannot compile any Rust projects

[Josselin Poiret via Bug reports for GNU Guix]

Hi everyone,

Hilton Chain  writes:

> Cc-ing Josselin since they have sent a patch to #63258.
>
> Hi Josselin, what's the current state of the patch?  Can you resend it
> to guix-patches to trigger the build process?

Huh, completely forgot about this.  The patch should still be ready, and
I don't expect it to cause any problems.  I can have a look and maybe
merge this afternoon.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#65472: texlive split packages are missing isodate.sty, wallpaper.sty, and dashrule.sty

[Josselin Poiret via Bug reports for GNU Guix]

Hi,

"Dr. Arne Babenhauserheide"  writes:

> guix shell --pure texlive-scheme-medium test
>
> ! LaTeX Error: File `isodate.sty' not found.
> ! LaTeX Error: File `wallpaper.sty' not found.
> ! LaTeX Error: File `dashrule.sty' not found.

The medium texlive scheme does not contain these packages upstream
either I believe.  Guix doesn't have them packaged, but a quick `guix
shell subversion -- guix import texlive isodate` should do it :) I
usually use manifests for all my tex needs, and add uncontributed
packages there, although with the latest texlive update it seems most of
them have been added to Guix proper.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#65417: i686-linux installation medium on Pentium II fails on boot

[Josselin Poiret via Bug reports for GNU Guix]

Hi Skylar,

"Skylar \"The Cobra\" Widulski" via Bug reports for GNU Guix
 writes:

> I've got an old Pentium II machine that I want to install Guix on. 
> Booting up the i686-linux installation medium, I'm dropped into a guile 
> REPL with this output visible on the 640x480 rectangle because NeoMagic 
> framebuffer seems unsupported:
>
> setting up setuid programs in '/run/setuid-programs'...
> populating /etc from /gnu/store/lzcvl2y4qsj6fkkq4g42a3zyqj9rsxlr-etc...
> creating /etc/machine-id...
> /gnu/store/0iapawfss4xnxls622g23qpk4mwb9ihp-glibc-2.33/lib/libc.so.6: 
> CPU ISA level is lower than required
> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> ERROR:
>1. &invoke-error:
>program: 
> "/gnu/store/j87mrzkw32dc03j9yxf2nxddn8621m1c-dbus-1.12.20/bin/dbus-uuidgen"
>arguments: ("--ensure=/etc/machine-id")
>exit-status: 127
>term-signal: #f
>stop-signal: #f
>
> Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
> GNU Guile 3.0.7
>
>
> It seems that there is an issue with the P6 (i686) microarchitecture 
> used in the Pentium II, even though the image is labelled i686. I'm not 
> sure what problem glibc would have with it.
> Explanations? Possible solutions?

There apparently was a bug with the ISA stamping that glibc used that
didn't take the -march option into account properly.  Since it was
noticed quite quickly after release, I think it should have been fixed
in subsequent versions (although I haven't really looked deep enough
into it).  In the meantime, you can try building a new installation
image using an existing Guix (CI doesn't build i686 images for latest).

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#65412: Guix installer failed to install

[Josselin Poiret via Bug reports for GNU Guix]

Hi Bruno,

Bruno Haible  writes:
>
> The problem is not so much that it failed, but that the warning
> message does not sufficiently describe the cause:
>   * I understand the figure of 6 GB: that's the expected size for
> a GUI environment with MATE.
>   * But I don't understand the figure of 1 GB.
> - Is /mnt a RAM disk (the VM has 2 GB of RAM), or did the installer fail
>   to mount /mnt?
> - Or is /mnt overloaded to the swap partition (which has 1 GB in my 
> config)?
> - Or is /mnt the 10 GB partition of my disk, and the downloaded binaries
>   already filled 9 GB of it?
> If I knew this, I would know what to do to fix the problem: Add more RAM?
> Partition differently? Use a larger main partition?

My guess is that, because a Guix system init installs some stuff in
steps, one of these steps ended up requiring too much space, that would
be bullet point 3 above.  You can check that it's not 1 or 2 by, once
you reproduce this bug, going to tty3 (using ctrl+alt+f3), and typing
`lsblk` to check which partition is mounted where.  In the meantime, I
would probably recommend adding some space for /.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#65281: GUIX Installer Error - installer-dump-15d44843

[Josselin Poiret via Bug reports for GNU Guix]

Hi,

The error here is the write_wait_fd unimplemented while substituting,
reported also in #61642 for example.  From what I understand this should
be fixed now that we have a more recent guile-gnutls.  Are you using the
1.4.0 installer?  If so, can you try the latest one instead and see if
the problem still arises?

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#65225: [PATCH] environment: Build the profile for the requested system.

[Josselin Poiret via Bug reports for GNU Guix]

Hi everyone,

Actually, let me add a big erratum, since it appears I misread the
intention of gexp->derivation (and realized 2 minutes after writing the
previous email).

Josselin Poiret  writes:
> --8<---cut here---start->8---
> (mlet* %store-monad ( ;; The following binding forces '%current-system' and
>  ;; '%current-target-system' to be looked up at >>=
>  ;; time.
>  (graft?(set-grafting graft?))
>
>  (system -> (or system (%current-system)))
>  (target -> (if (eq? target 'current)
> (%current-target-system)
> target))
>  ...)
>   ...)
> --8<---cut here---end--->8---
>
> Well, the issue here is that such an mlet starts by translating the
> graft? binding into a >>= call, which ends up putting the rest of the
> translation into a function call that will *not* be called until the
> monadic value is run.  That means that the system and target bindings
> afterwards are *not* looked up at call time but at monadic run time!

This is actually what the comment above hints at, I misunderstood its
meaning.  It seems that this piece of code used to be (before 2015)

--8<---cut here---start->8---
(mlet* %store-monad ( ;; The following binding forces '%current-system' and
 ;; '%current-target-system' to be looked up at >>=
 ;; time.
 (unused(return #f)

 (system -> (or system (%current-system)))
 (target -> (if (eq? target 'current)
(%current-target-system)
target))
 ...)
  ...)
--8<---cut here---end--->8---

probably at a time when (current-system) didn't exist.  In turn, this
means that gexp->derivation intentionally delays getting the current
system to monadic run time.  Thus, we probably need to pass an optional
#:system argument to the hooks that they can forward to
gexp->derivation to fix this “properly”

> IMO, this is way too complicated to keep in mind at all times, and there
> are bugs lurking under the surface absolutely everywhere, waiting for a
> corner case to be uncovered.

My comment still stands.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#65225: [PATCH] environment: Build the profile for the requested system.

[Josselin Poiret via Bug reports for GNU Guix]

Hi Tobias,

Tobias Geerinckx-Rice  writes:

> Previously, ‘--system=’ did not affect profile hooks, meaning that all
> packages would be built for both the host and requested systems.
>
> * guix/scripts/environment.scm (guix-environment*): Parameterize
> %current-system to match the requested ‘--system=’.
>
> Reported by ekaitz in #guix.
> ---
>  guix/scripts/environment.scm | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/guix/scripts/environment.scm b/guix/scripts/environment.scm
> index 9712389842..27f7e53549 100644
> --- a/guix/scripts/environment.scm
> +++ b/guix/scripts/environment.scm
> @@ -1146,7 +1146,8 @@ (define (guix-environment* opts)
>(warning (G_ "no packages specified; creating an empty 
> environment~%")))
>  
>  ;; Use the bootstrap Guile when requested.
> -(parameterize ((%graft? (assoc-ref opts 'graft?))
> +(parameterize ((%current-system system)
> +   (%graft? (assoc-ref opts 'graft?))
> (%guile-for-build
>  (and store-needed?
>   (package-derivation
>
> base-commit: 9e71d4fd6b3893ae87cb079b57d7a8fe6e9e7914
> -- 
> 2.41.0

So, I've looked into this deeper because this fix didn't seem satisfying
to me: it suggests that the implementation of profile-derivation itself
is wrong, and I wanted to fix it instead.  Here's what I uncovered:

%current-system (applies mutatis mutandis to %current-target-system)
is a Guile parameter.  That means that it is accessed through a function
call, and its values really depends on where that function call occurs.
Now, this interacts with the store monad in a cumbersome way: monadic
values in this case are functions (lambda (store) ...) returning two
values, the actual output and the store.  These functions are run only
at the run-with-store call.

Now, there are two non-equivalent ways of getting the current system in
a monadic context.  You can either do

(mlet ((system -> (%current-system))
  ...)

or

(mlet ((system (current-system))
  ...)

The former directly evaluates (%current-system), while the latter only
evaluates (%current-system) when the monadic value is run!

What does this mean for our case here?  Well, the problem lies with how
the hooks are lowered: they use (gexp->derivation ...) without the
optional #:system keyword.  This looks up the current system at call
time with the mlet -> construct, so everything should be okay, right?
Well, the hooks are run through a mapm/accumulate-builds call, which
puts everything in a monadic value, effectively delaying the look-up
until monadic run time.

--8<---cut here---start->8---
(mlet* %store-monad (...
 (extras (if (null? (manifest-entries manifest))
 (return '())
 (mapm/accumulate-builds (lambda (hook)
   (hook manifest))
 hooks
 ...)
--8<---cut here---end--->8---

At this point, I thought: “Well, I could just parameterize
%current-system inside the (lambda (hook) ...), and all would be well,
right?  Well, it didn't seem to work and I was pretty confused by it.  I
tested a bit and noticed that actually, contrary to what was intended
(there even is a comment in gexp-derivation about it), gexp-derivation
looks up the system at monadic run time!  It looks like this:

--8<---cut here---start->8---
(mlet* %store-monad ( ;; The following binding forces '%current-system' and
 ;; '%current-target-system' to be looked up at >>=
 ;; time.
 (graft?(set-grafting graft?))

 (system -> (or system (%current-system)))
 (target -> (if (eq? target 'current)
(%current-target-system)
target))
 ...)
  ...)
--8<---cut here---end--->8---

Well, the issue here is that such an mlet starts by translating the
graft? binding into a >>= call, which ends up putting the rest of the
translation into a function call that will *not* be called until the
monadic value is run.  That means that the system and target bindings
afterwards are *not* looked up at call time but at monadic run time!
And sure enough, moving the (graft? ...) binding after the (target ->
...) one does solve this!

IMO, this is way too complicated to keep in mind at all times, and there
are bugs lurking under the surface absolutely everywhere, waiting for a
corner case to be uncovered.

I'll send a new patch once I've fixed and tested this further.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#65177: udevd error with lvm-raid array leading to race condition with luks

[Josselin Poiret via Bug reports for GNU Guix]

Hi Adrien,

Adrien 'neox' Bourmault  writes:

>Aug  9 11:40:27 localhost vmunix: [7.525877] udevd[515]: failed 
> to execute '/usr/bin/systemd-run' '/usr/bin/systemd-run --no-block 
> --property DefaultDependencies=no --unit lvm-activate-HOMERAID 
> /gnu/store/hffkn63zx2zjadawrkxpnr486frc9n74-lvm2-2.03.21/sbin/lvm 
> vgchange -aay --autoactivation event HOMERAID': No such file or directory

Since lvm2 2.03.14, the included udev rules use systemd-run to run
vgchange and activate the volume group.  lvm2 was updated recently from
2.03.11 to 2.03.21, then 2.03.22 (cc'ing tobias), and probably started
exhibiting this behavior then.  I think we can probably remove the
indirection through systemd-run and directly run vgchange.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#64593: ‘guix system image’ fails to create image while invoking ‘grub-bios-setup’

[Josselin Poiret via Bug reports for GNU Guix]

Hi everyone,

Ludovic Courtès  writes:

> I guess my confusion stems from the fact that the default image type
> changed to EFI recently (right?).

No, the image type had always been efi-raw iirc, just that efi images
now use GPT partitioning, and BIOS booting on GPT drives need an extra
BIOS partition to store the bootloader which used to be stored in empty
space after the MBR headers.  There really wasn't anything EFI at all
about the efi image type before though imo…

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#64999: Acknowledgement (emacs-next: emacs-29.1 fails to native-compile libraries, giving a runtime error that ctri.o and other files can't be found)

[Josselin Poiret via Bug reports for GNU Guix]

Hi Adam,

Adam Porter  writes:

> OTOH, if anyone knows why the transformation option failed in that way, 
> it might be helpful to solve it if possible, so users could use the 
> option to install future releases without having to modify the package 
> definition.  (AFAIK, I was able to do that for various Emacs 28 versions 
> without this problem, so I wonder if something's changed.)

It's probably because emacs is missing the
emacs-native-comp-driver-options.patch patch of emacs-next.  Package
transformations can't and won't replace the manual work of packaging new
versions, so I think it is unreasonable to expect emacs 28's package
definition to work with emacs 29.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#64760: [PATCH 2/3] tests: store-roots: Initial gc-roots should be empty.

[Josselin Poiret via Bug reports for GNU Guix]

Hi everyone,

Janneke Nieuwenhuizen  writes:

> Just a headsup that this change breaks the store-roots test on the hurd
> for me.

Thanks for the feedback Janneke.  It seems that there is some left-over
state that can mess with this state's result: I was initially surprised
that the /profiles directory could appear in the gc roots, but that's
because it is symlinked under /gcroots, not because it is itself
searched for gc roots.

In any case, the /gcroots directory along with the /gcroots/profiles
symlink is created when a connection is made to the daemon, which is not
the case here yet.  However, a connection might have been opened before
for the same state dir (which depends on the PID of
build-aux/test-env.in).  It might also depend on whether the clean-up of
the state directory made by `trap` worked and whether PIDs get re-used
quickly on the specific kernel.  I think this is all too unreliable
here (I have one such example of a leftover PID state dir in my tree, so
it might happen more often than not).

In any case, if this test is only here to check if gc-roots doesn't
error out, we could return #t at the end to only fish for errors.  WDYT?

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#64593: [PATCH] image: Add mbr-raw-image-type and use by default.

[Josselin Poiret via Bug reports for GNU Guix]

From: Josselin Poiret 

* gnu/system/image.scm (mbr-disk-image, mbr-raw-image-type): New variables.
* guix/scripts/system.scm (%default-options): Use mbr-raw-image-type by
default.
---

How about this for now?  I think the bootloader/image-type situation is not
clear, but at least this keeps the behavior of the previous default option.

 gnu/system/image.scm| 16 
 guix/scripts/system.scm |  2 +-
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/gnu/system/image.scm b/gnu/system/image.scm
index 841e7e0c7e..92e659753e 100644
--- a/gnu/system/image.scm
+++ b/gnu/system/image.scm
@@ -76,6 +76,7 @@ (define-module (gnu system image)
 esp32-partition
 root-partition
 
+mbr-disk-image
 efi-disk-image
 iso9660-image
 docker-image
@@ -84,6 +85,7 @@ (define-module (gnu system image)
 raw-with-offset-disk-image
 
 image-with-os
+mbr-raw-image-type
 efi-raw-image-type
 efi32-raw-image-type
 qcow2-image-type
@@ -145,6 +147,15 @@ (define root-partition
(flags '(boot))
(initializer (gexp initialize-root-partition
 
+(define mbr-disk-image
+  (image-without-os
+   (format 'disk-image)
+   (partition-table-type 'mbr)
+   (partitions
+(list (partition
+   (inherit root-partition)
+   (offset root-offset))
+
 (define efi-disk-image
   (image-without-os
(format 'disk-image)
@@ -201,6 +212,11 @@ (define-syntax-rule (image-with-os base-image os)
(inherit base-image)
(operating-system os)))
 
+(define mbr-raw-image-type
+  (image-type
+   (name 'mbr-raw)
+   (constructor (cut image-with-os mbr-disk-image <>
+
 (define efi-raw-image-type
   (image-type
(name 'efi-raw)
diff --git a/guix/scripts/system.scm b/guix/scripts/system.scm
index d7163dd3eb..95c68a5f33 100644
--- a/guix/scripts/system.scm
+++ b/guix/scripts/system.scm
@@ -1168,7 +1168,7 @@ (define %default-options
 (debug . 0)
 (verbosity . #f)  ;default
 (validate-reconfigure . ,ensure-forward-reconfigure)
-(image-type . efi-raw)
+(image-type . mbr-raw)
 (image-size . guess)
 (install-bootloader? . #t)
 (label . #f)

base-commit: c7e45139faa27b60f2c7d0a4bc140f9793d97d47
-- 
2.41.0

bug#64881: [translation] M-x texinfo-all-menus-update breaks translated cookbook

[Josselin Poiret via Bug reports for GNU Guix]

Hi everyone,

"pelzflorian (Florian Pelz)"  writes:

> IIUC 'make as-derivation' uses the files from the guix directory, but
> 'guix pull' uses the files from a repo checkout and was not / cannot be
> broken by stray files.

`make as-derivation` uses #:select? git? to restrict to only files
that are checked out in git.  It doesn't try to get the contents of HEAD
though, the working directory's state is used instead.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#64783: Build of texlive-font-maps fails

[Josselin Poiret via Bug reports for GNU Guix]

Hi Isaac,

Isaac van Bakel  writes:

> I had the same issue, with a pretty minimal manifest:
>
>
> (use-modules (gnu packages))
> (use-package-modules tex)
>
> (packages->manifest (list texlive texlive-amsmath texlive-txfonts))
>
>
> Based on the suggestion that the missing files are propagated by 
> texlive-bin, I added that to the manifest and found that the build 
> succeeded. So is the issue that texlive is not propagating 
> texlive-scripts correctly?

The `texlive` package contains the whole monolothic texlive
distribution, and is different from the newer modular one.  You probably
want `texlive-bin` instead.  `texlive-scheme-basic` is a meta-package
propagating a basic set of tex packages that you might need.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#64760: [PATCH 3/3] tests: texlive: Remove texlive-texworks from propagated-inputs.

[Josselin Poiret via Bug reports for GNU Guix]

From: Josselin Poiret 

* tests/texlive.scm ("texlive->guix-package, meta-package"): Remove
texlive-texworks from expected propagated-inputs, as it is now ignored by
texlive->guix-package.
---
 tests/texlive.scm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/texlive.scm b/tests/texlive.scm
index 98461f7e51..b8b1d5c6d6 100644
--- a/tests/texlive.scm
+++ b/tests/texlive.scm
@@ -542,7 +542,7 @@ (define %fake-tlpdb
('arguments
 ('list '#:builder ('gexp ('mkdir ('ungexp 'output)
('propagated-inputs
-('list 'texlive-collection-basic 'texlive-texworks))
+('list 'texlive-collection-basic))
('home-page "https://www.tug.org/texlive/";)
('synopsis (? string?))
('description (? string?))
-- 
2.40.1

bug#64760: [PATCH 1/3] tests: packages: Set system for expected result of package->bag.

[Josselin Poiret via Bug reports for GNU Guix]

From: Josselin Poiret 

* tests/packages.scm ("package->bag"): Parameterize the expected result by the
system used to lower the package to a bag.
---
 tests/packages.scm | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/tests/packages.scm b/tests/packages.scm
index 2b7ab01f7d..2b4f9f8e90 100644
--- a/tests/packages.scm
+++ b/tests/packages.scm
@@ -1277,8 +1277,9 @@ (define compressors '(("gzip"  . "gz")
 ;;   #:guile guile
 
 (test-equal "package->bag"
-  `("foo86-hurd" #f (,(package-source gnu-make))
-(,(canonical-package glibc)) (,(canonical-package coreutils)))
+  (parameterize ((%current-system "foo86-hurd"))
+`("foo86-hurd" #f (,(package-source gnu-make))
+  (,(canonical-package glibc)) (,(canonical-package coreutils
   (let ((bag (package->bag gnu-make "foo86-hurd")))
 (list (bag-system bag) (bag-target bag)
   (assoc-ref (bag-build-inputs bag) "source")

base-commit: 182be30fb1a8b847c30492462ec22c08ec7a9849
-- 
2.40.1

bug#64760: [PATCH 2/3] tests: store-roots: Initial gc-roots should be empty.

[Josselin Poiret via Bug reports for GNU Guix]

From: Josselin Poiret 

* tests/store-roots.scm ("gc-roots, initial"): Set expected result to empty.
Also do not error out if /profiles doesn't exist.
---
 tests/store-roots.scm | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/tests/store-roots.scm b/tests/store-roots.scm
index 9877987a65..d82a29e313 100644
--- a/tests/store-roots.scm
+++ b/tests/store-roots.scm
@@ -31,10 +31,11 @@ (define %store #f)
 (test-begin "store-roots")
 
 (test-equal "gc-roots, initial"
-  (list (string-append %state-directory "/profiles"))
+  '()
   (begin
 ;; 'gc-roots' should gracefully handle lack of that directory.
-(delete-file-recursively (string-append %state-directory "/profiles"))
+(false-if-exception
+ (delete-file-recursively (string-append %state-directory "/profiles")))
 (gc-roots)))
 
 ;; The 'open-connection' call below gets guix-daemon to create
-- 
2.40.1

bug#64760: make check fails on 182be30fb1a8b847c30492462ec22c08ec7a9849

[Josselin Poiret via Bug reports for GNU Guix]

Hi Janneke,

Janneke Nieuwenhuizen  writes:

> Hi,
>
> Make check gives three failures for me on current master
>
> FAIL: tests/packages (package->bag)
> FAIL: tests/store-roots  (gc-roots, initial)  
> FAIL: tests/texlive  (texlive->guix-package, meta-package)
>
> using this snippet.

I have local fixes for all of them, but I am not 100% sure about the
gc-roots one.  Ludo, WDYT?  Also, guix-shell fails on the fdes test
locally for me, probably because I'm using zsh.  All should be fine in
the package though.

Best,

Josselin Poiret


signature.asc
Description: PGP signature

bug#64593: ‘guix system image’ fails to create image while invoking ‘grub-bios-setup’

[Josselin Poiret via Bug reports for GNU Guix]

Hi Sergey,

Sergey Trofimov  writes:

> shouldn't it be `(bootloader grub-efi-bootloader)` if you're 
> building a `efi-raw` image?
> With efi grub it builds and boots just fine, as I've tested before 
> submitting the patch.

I think I agree with you that you should expect efi images to use efi
bootloaders.  The efi-raw image name is a bit misleading I would argue,
since the image type doesn't decide what bootloader is used, and using a
BIOS bootloader with an efi image seems a bit weird.  The fact that it's
used as the default image type is a bit troubling though, so we could
add a new default image type that uses MBR, so that BIOS bootloaders
work with it.

WDYT Ludo?

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#64593: ‘guix system image’ fails to create image while invoking ‘grub-bios-setup’

[Josselin Poiret via Bug reports for GNU Guix]

Hi Ludo,

Ludovic Courtès  writes:

> The culprit might be 209204e23b39af09e0ea92540b6fa00a60e6a0ae, from
> .
>
> Josselin, Sergey, WDYT?

Apologies!  Our install-grub-disk-image doesn't really support GPT
right, now but this is easy to fix (I've successfully booted your
example with a local change).  However, for this to work we need to have
a BIOS Boot partition instead of the ESP that's defined for efi images.
We have two options here, either add a new image type that has that
instead of the ESP (which means duplicating a bunch of them...), or make
the partition of efi-raw change depending on the bootloader, which would
need some refactoring.  I'm not a big fan of either options though :)

WDYT?
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#64505: bug report

[Josselin Poiret via Bug reports for GNU Guix]

Hi,

Josselin Poiret  writes:

> You seem to have a quite old version of Guix, along with Guile 2.x, and
> there raise-exception doesn't exist, but it is indirectly being used
> when building Guix.
>
> You can either try to pull in small increments (I think 1.1 -> 1.2 ->
> 1.3 -> master should do it) for now, but we should also fix this use of
> raise-exception: it should be `raise` from srfi-34/35 instead.

I've pushed a fix for this as d17879cd0dec60ea7490632910257890f207d6cb.

Preemptively closing, feel free to re-open if this doesn't work.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#64309: Python dlopen()s musl libc

[Josselin Poiret via Bug reports for GNU Guix]

Hi Lars,

Lars-Dominik Braun  writes:

> I think the problem is bigger than usercustomize. Any custom PYTHONPATH
> also slips through and causes this issue, as well as any custom
> GUIX_PYTHONPATH, because the executable wrapper appends it (think nested
> `guix shell` invokations with different versions of a library for
> an example where this could go wrong).
>
> Guix-managed Python packages (libraries nor applications) should
> generally not pick up dependencies from random paths – only those
> from their package description, so we can keep Guix’ promise of being
> self-contained.
>
> I have experimented with customizing Python’s importing mechanism
> through a custom MetaPathFinder. It works by adding a __guix_pythonpath__
> variable to every Python package’s __init__.py file and modifying the
> module loader’s search path accordingly if such a variable exists. It
> would provide exactly that guarantee, but it’s just a PoC at this
> point – see attached file.

Woah, looks like a neat solution.  Do you think it would scale for all
our Python packages without manual intervention?  If so, this would
definitely be the way forward.

> Apart from that I don’t see a good short-term solution right now. It’s
> just how Python works.

I mostly agree with you, but for this rather common case of having also
a usercustomize it would be nice to circumvent it.  In general, I don't
think we ever want a Guix-produced Python script to load the
usercustomize, hence my suggestion.  The other case of PYTHONPATH is
also annoying but can be tamed by modifying the env variable
temporarily.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#64309: Python dlopen()s musl libc

[Josselin Poiret via Bug reports for GNU Guix]

Hi Athena,

Athena Martin  writes:

> $ guix shell python-neovim-remote python -- python3
 sys.path
> ['', 
> '/gnu/store/dy3xh053ahkhrp2jamggq8cpsyvp8mg0-python-3.10.7/lib/python310.zip',
>  '/gnu/store/dy3xh053ahkhrp2jamggq8cpsyvp8mg0-python-3.10.7/lib/python3.10', 
> '/gnu/store/dy3xh053ahkhrp2jamggq8cpsyvp8mg0-python-3.10.7/lib/python3.10/lib-dynload',
>  '/home/alm/.local/lib/python3.10/site-packages', 
> '/gnu/store/ll75wx2cvm1dbbxjr095lcs1653q2zz1-profile/lib/python3.10/site-packages',
>  
> '/gnu/store/dy3xh053ahkhrp2jamggq8cpsyvp8mg0-python-3.10.7/lib/python3.10/site-packages']
>
> (It's not from the environment:)
>
> $ guix shell python-neovim-remote python --pure -- python3
 sys.path
> ['', 
> '/gnu/store/dy3xh053ahkhrp2jamggq8cpsyvp8mg0-python-3.10.7/lib/python310.zip',
>  '/gnu/store/dy3xh053ahkhrp2jamggq8cpsyvp8mg0-python-3.10.7/lib/python3.10', 
> '/gnu/store/dy3xh053ahkhrp2jamggq8cpsyvp8mg0-python-3.10.7/lib/python3.10/lib-dynload',
>  '/home/alm/.local/lib/python3.10/site-packages', 
> '/gnu/store/ll75wx2cvm1dbbxjr095lcs1653q2zz1-profile/lib/python3.10/site-packages',
>  
> '/gnu/store/dy3xh053ahkhrp2jamggq8cpsyvp8mg0-python-3.10.7/lib/python3.10/site-packages']
 os.environ
> environ({'HOME': '/home/alm', 'LOGNAME': 'alm', 'PAGER': 'less', 'DISPLAY': 
> ':0', 'USER': 'alm', 'TERM': 'xterm-256color', 'PATH': 
> '/gnu/store/ll75wx2cvm1dbbxjr095lcs1653q2zz1-profile/bin', 'GUIX_PYTHONPATH': 
> '/gnu/store/ll75wx2cvm1dbbxjr095lcs1653q2zz1-profile/lib/python3.10/site-packages',
>  'GUIX_ENVIRONMENT': '/gnu/store/ll75wx2cvm1dbbxjr095lcs1653q2zz1-profile'})

So, looks like the default Python behavior is to load the usercustomize
after the sitecustomize [1], which leads to exactly the behavior you're
experiencing.  I don't know what we should do here, maybe pass `-s` to
the shebang line of Python to disable loading the usercustomize?  That
would probably be a world-rebuild though.  CC'ing the Python team to see
what they think.

[1] https://docs.python.org/3/library/site.html

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#64309: Python dlopen()s musl libc

[Josselin Poiret via Bug reports for GNU Guix]

Hi Athena,

So it's not the LD_DEBUG output that hold a clue, but rather the Python
traceback.

Athena Martin  writes:

>   File 
> "/gnu/store/dsgxdqs620pp284bfm1drbsjqpb36i4n-python-neovim-remote-2.5.1/bin/.nvr-real",
>  line 4, in 
> import nvr.nvr as mod
>   File "/home/alm/.local/lib/python3.10/site-packages/nvr/__init__.py", line 
> 1, in 
> from .nvr import main
>   File "/home/alm/.local/lib/python3.10/site-packages/nvr/nvr.py", line 34, 
> in 
> import psutil
>   File "/home/alm/.local/lib/python3.10/site-packages/psutil/__init__.py", 
> line 102, in 
> from . import _pslinux as _psplatform
>   File "/home/alm/.local/lib/python3.10/site-packages/psutil/_pslinux.py", 
> line 26, in 
> from . import _psutil_linux as cext
> ImportError: libc.musl-x86_64.so.1: cannot open shared object file: No such 
> file or directory

The nvr package in ~/.local seems to be used instead of a Guix package.
That locally installed nvr package expects to use the host's libc, but
since the python interpreter being used has a fixed RPATH and system
search path it won't find it.

.nvr-real should definitely be using the Python code inside the store, I
wonder why that isn't being done.  Maybe our sitecustomize.py is
misbehaving?  Can you do `guix shell python-neovim-remote python --
python3` then type `import sys.path; sys.path`?

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#64505: bug report

[Josselin Poiret via Bug reports for GNU Guix]

Hi Jean-Christophe,

Jean-Christophe Haessig  writes:

> In ./guix/platform.scm:
> 139:6  2 (lookup-platform-by-target-or-system "x86_64-linux")
> In ice-9/boot-9.scm:
> 829:9  1 (catch srfi-34 # ./guix/platform.scm:139:6 ()> # ?)
> In ./guix/platform.scm:
> 129:2  0 (lookup-platform-by-target "x86_64-linux")
>
> ./guix/platform.scm:129:2: In procedure lookup-platform-by-target:
> error: raise-exception: unbound variable
> guix pull: error: You found a bug: the program
> '/gnu/store/cb56v1p47byd2ars5xbgkw26f3iq41sj-compute-guix-derivation'
> failed to compute the derivation for Guix (version:
> "961ffca1c75141cbb351d143b22b673638e9659d"; system: "x86_64-linux";
> host version: "1.1.0"; pull-version: 1).
> Please report the COMPLETE output above by email to .

You seem to have a quite old version of Guix, along with Guile 2.x, and
there raise-exception doesn't exist, but it is indirectly being used
when building Guix.

You can either try to pull in small increments (I think 1.1 -> 1.2 ->
1.3 -> master should do it) for now, but we should also fix this use of
raise-exception: it should be `raise` from srfi-34/35 instead.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#64309: Python dlopen()s musl libc

[Josselin Poiret via Bug reports for GNU Guix]

Hi Athena,

Athena Martin via Bug reports for GNU Guix  writes:

> On an Alpine Linux Edge host, I reproduce with:
>
> $ guix install python-neovim-remote
> $ nvr
>
> It's possible that there's some quirk of my specific environment.
>
> (I'm currently in the process of switching to Guix System so I may not
> be able to reproduce this forever.)

Can you do `LD_DEBUG=libs nvr` so that we get a log of what ld's trying
to load?

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#64073: libvirtd requires restart to function

[Josselin Poiret via Bug reports for GNU Guix]

Hi Christian,

Josselin Poiret  writes:

> Great!  Thanks for going the extra mile testing this, I didn't know how
> familiar you were with the Guix development process.  We could also
> advertise the simpler `guix time-machine` with the branches from [1],
> although processing the new patch is not instantaneous (and I don't
> think bug reports are scanned for patches).
>
> In any case, I'll try to push it ASAP with some other changes!

Pushed as 612399df3edcbe4d1b1da784bd23440398d27454, closing.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#64223: I just have a install error and make a dump `installer-dump-719ceb08` :)

[Josselin Poiret via Bug reports for GNU Guix]

Hi,

"yhm" via Bug reports for GNU Guix  writes:

> It failed as "build of /gnu/store/...-gtk-4.8.1.drv failed"   Secured 
> by Skiff Mail.  

The only thing I can gather from that dump is that there was not enough
space left on a device, and I assume the device you were installing on.

HTH,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#64193: greetd-wlgreet-session dont working

[Josselin Poiret via Bug reports for GNU Guix]

Hi Yurii,

Yurii  writes:

> I tryed to use wlgreet with dwl-guile
> guix system reconfigure error:
> (greetd-terminal-configuration (terminal-vt "1") (terminal-switch #t)
> (default-session-command (greetd-wlgreet-session (command (file-append
> dwl-guile "/bin/dwl-guile"): invalid field specifier
>
> config:
> (greetd-terminal-configuration
>   (terminal-vt "1")
>   (terminal-switch #t)
>   (default-session-command
> (greetd-wlgreet-session
> (command (file-append dwl-guile "/bin/dwl-guile")

This is only a very small snippet of your configuration, can you please
post your entire configuration file, possibly redacting personal
information you wouldn't like sharing?

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#64196: Can't boot due to discrepancy between reconfigure and init

[Josselin Poiret via Bug reports for GNU Guix]

Hi,

Csepp  writes:
>> I don't think there is, the biggest difference is that `guix system
>> init` will copy stuff into the target store and initialize the basic
>> directories for Guix, whereas reconfigure will just build everything in
>> the current store.
>>
>> Best,
>
> I mean, that's the theory, but either Guix or GRUB seems to get the
> incorrect UUID from *somewhere*.

You can manually check that the generated grub.cfg file contains the
expected UUID after the reconfigure, it should be in
/boot/grub/grub.cfg.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#64200: Netsurf very frequently freezes when editing text (Harfbuzz issue?)

[Josselin Poiret via Bug reports for GNU Guix]

Hi Csepp,

Csepp  writes:

> Like the title says.  It never happens when just browsing, but happens
> very frequently (like a minute after starting to type) when editing
> text, at least on Brutaldon, but maybe on other sites too.
>
> I noticed that our Harfbuzz package is two entire major releases behind.
> Maybe there are bugfixes in the latest one that we could use?
>
> I tried building it but it froze up my laptop for some reason (rather
> strange, even if it runs out of memory it should just be killed by
> earlyoom) so I haven't attempted to test this theory yet.
>
> Is there any particular reason Harfbuzz wasn't covered by the last
> core-updates?  If it turns out to be a bug in it, what would be the best
> way to proceed?

core-updates was lagging behind, and while merging you don't want to
introduce potential sources of issues.  This could maybe go into the
graphics updates along with mesa, if John thinks it's appropriate.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#64196: Can't boot due to discrepancy between reconfigure and init

[Josselin Poiret via Bug reports for GNU Guix]

Hi Csepp,

Csepp  writes:

> I'm trying to move my installation from /dev/sda to /dev/sdb, I created
> the file system and changed the bootloader config in my operating-system
> definition to point to /dev/sdb and the file-system to use the correct
> UUID (previously it was using a label).
> First I tried to simply reconfigure my running system and then taking a
> BTRFS snapshot and copying that over the /dev/sdb1, but that failed.

Any reason you didn't try in the reverse order?  This seems prone to error.

> The exact error was GRUB not being able to find a file system with a
> given UUID, which matched the UUID of /dev/sda1.  This error happened
> before GRUB loaded any of its modules, so I was dropped into a rescue
> shell.
> I thought this might be related to subvolumes, maybe I originally used
> the wrong config and the updated config was written to a different
> subvolume and GRUB doesn't recognize the default subvolume ID option on
> the BTRFS partition.
> I think this is a fairly critical error.

This is too fuzzy to be actionable, but if you manage to reproduce
reliably then I would gladly take a look at it.

> The error doesn't manifest when I run guix system init with the same
> config, so there is some (possibly un(der)documented) difference between
> guix system reconfigure and guix system init that makes the former rely
> on the state of the running system in a way that doesn't take into
> account the new configuration.

I don't think there is, the biggest difference is that `guix system
init` will copy stuff into the target store and initialize the basic
directories for Guix, whereas reconfigure will just build everything in
the current store.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#64073: libvirtd requires restart to function

[Josselin Poiret via Bug reports for GNU Guix]

Hi Christian,

Christian Miller via Bug reports for GNU Guix  writes:

> I tested your patch and it works.  With the patch virt-manager does instantly 
> connect without any manual interference.
>
> Since this is the first time I did this, just to be sure I did everything 
> correctly, I list how I tested it.
>
> I cloned the git repository
> I created a file called libvirtd.patch with your contents
> git apply libvirtd.patch
> guix shell -D guix --pure
> ./bootstrap
> ./configure --localstatedir=/var
> make
> make check (had 2 errors, authenticate and something else)
> after that I executed "sudo -E ./pre-inst-env guix system reconfigure 
> ~/guix/system.cm"
> I rebooted the system and launched virt-manager which directly connected.

Great!  Thanks for going the extra mile testing this, I didn't know how
familiar you were with the Guix development process.  We could also
advertise the simpler `guix time-machine` with the branches from [1],
although processing the new patch is not instantaneous (and I don't
think bug reports are scanned for patches).

In any case, I'll try to push it ASAP with some other changes!

[1] https://git.guix-patches.cbaines.net/guix-patches

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#64059: Sudden unexplained error during guix pull: "channel dependency has an invalid introduction field"

[Josselin Poiret via Bug reports for GNU Guix]

Hi Ning,

"N. Y."  writes:

> The error is "channel dependency has an invalid introduction field," but
> the introduction fields of my custom channels have the same form as those I
> use for GNU guix and nonguix channels which I can pull without errors; and
> the channel introductions and GPG fingerprints are unchanged from the last
> time I was able to pull successfully (I have the channels.scm file under
> version control).

I've purposefully added this new error to warn users that their
.guix-channel's introduction forms were erroneous.  Previously, they
were silently being dropped.  The formats in a channels.scm file and in
the .guix-channel file are *not* the same!  Please see "(guix) Declaring
Channel Dependencies" for an example of the format.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#64073: [PATCH] services: libvirt: Add requirement on dbus.

[Josselin Poiret via Bug reports for GNU Guix]

From: Josselin Poiret 

* gnu/services/virtualization.scm (libvirt-shepherd-service): Add requirement
on dbus.
---
 gnu/services/virtualization.scm | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gnu/services/virtualization.scm b/gnu/services/virtualization.scm
index 880557915c..506f5a7ab6 100644
--- a/gnu/services/virtualization.scm
+++ b/gnu/services/virtualization.scm
@@ -478,6 +478,7 @@ (define (libvirt-shepherd-service config)
 (list (shepherd-service
(documentation "Run the libvirt daemon.")
(provision '(libvirtd))
+   (requirement '(dbus-system))
(start #~(make-forkexec-constructor
  (list (string-append #$libvirt "/sbin/libvirtd")
"-f" #$config-file
-- 
2.40.1

bug#64073: libvirtd requires restart to function

[Josselin Poiret via Bug reports for GNU Guix]

Hi Christian,

Christian Miller via Bug reports for GNU Guix  writes:

> Hi,
>
> there is not an error message upon starting it but by stopping it:
> Jun 14 23:52:18 localhost shepherd[1]: Stopping service libvirtd... 
> Jun 14 23:52:18 localhost libvirtd: 157: error : virGDBusGetSystemBus:99 : 
> internal error: Unable to get system bus connection: Could not connect: No 
> such file or directory 

Seems that dbus is needed for libvirt, but it is not listed as a
requirement for the shepherd service.  I don't use libvirt, but would
you be able to test the following patch?

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#64112: greetd-wlgreet-session doesn't source .bash_profile

[Josselin Poiret via Bug reports for GNU Guix]

Hi,

"ytc" via Bug reports for GNU Guix  writes:

> Hello everyone.
>
> I've noticed that when I started a Wayland session with a
> greetd-terminal whose default-session-command is
> greetd-wlgreet-sway-session or greetd-wlgreet-session, enviromental
> variables set in .bash_profile doesn't seem to be set.
>
> I don't know if this is a bug or feature but it doesn't seem right to
> me.  I would be glad if you handle it.

greetd sources ~/.profile and /etc/profile [1], even though it is not
documented.  You should probably use that instead of the bash-specific
.bash_profile which is *only* meant for bash login shells.

[1] 
https://git.sr.ht/~kennylevinsen/greetd/tree/3608fc9494e3b98c673292f9e2a7589cc6686d38/item/greetd/src/session/worker.rs#L202

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#64106: `modify-services` no longer affects multiple instances of the same service

[Josselin Poiret via Bug reports for GNU Guix]

merge 64106 63921
thankyou

Hi David,

"David Wilson"  writes:

> Hi Guix!
>
> Recently there was a change to the behavior of `modify-services` that adds 
> logic to check for any unused clauses so that an exception can be raised to 
> alert the user of this case.
>
> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=181951207339508789b28ba7cb914f983319920f
>
> It seems that the new logic has a bug that prevents a used clause from being 
> executed on more than one instance of a compatible service in a single 
> execution of `modify-services`.  Here's a new test case for 
> `gnu/tests/services.scm` that exhibits the issue:

This was intended, but was probably not a good idea.  I'll look into how
we could revert this while keeping the main idea of the change.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#63902: System containers with --network won't start "In procedure canonicalize-path: No such file or directory"

[Josselin Poiret via Bug reports for GNU Guix]

Hi,

e...@beaver-labs.com writes:

> ERROR: In procedure canonicalize-path:
> In procedure canonicalize-path: No such file or directory

This bug should have been fixed by
181951207339508789b28ba7cb914f983319920f, can you `guix pull` to update
guix and retry?

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#63904: Can't setuid programs to anybody but root

[Josselin Poiret via Bug reports for GNU Guix]

Hi everyone,

You might want to have a look at [1], which should resolve this.  I've
held off on reviewing it for quite a bit but have talked on IRC recently
with bjc about it.  With this approach, while cleaner, we'll need to
identify which services rely on the setuid binaries being present, as
well as ensure they're up before any interaction with the user is
possible.

[1] https://issues.guix.gnu.org/62726

HTH,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#63728: GHC cannot find lrt

[Josselin Poiret via Bug reports for GNU Guix]

Hi everyone,

Mekeor Melire  writes:

> Hm. Alternatively, we could just fix gcc-toolchain (so that it 
> includes rt). But maintainers (understandably) hesitate because 
> this will trigger a world rebuild.

Yet another alternative would be to patch GHC to not include `-lrt` in
its flags.  Yet another big rebuild though!  The proper fix in the
meantime is as you mentioned: add ghc-toolchain to contain everything
that's needed.  I find it weird though, since I've never had to do
anything of the sort when building Agda locally since the core-updates
merge though.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#63394: guix pack and proot

[Josselin Poiret via Bug reports for GNU Guix]

Hi André,

André A. Gomes  writes:

> Hi Guix,
>
> I acknowledge the answers provided, but I'd like to emphasize that guix
> pack won't run if proot is broken.  This is a critical issue and a
> temporary solution is simple enough: disable the tests for the current
> proot version packaged.

As I mentioned above, disabling the tests is not a solution here, since
one of the tests failing is *actually* indicative of a regression in
PRoot, and we should not ignore it.  Specifically, it seems the
interaction between pthreads and current working directory sandboxing
isn't working IIRC.  I haven't heard back from upstream, I might have a
look at some point but I have no familiarity whatsoever with its
codebase (and I guess it's using some nasty tricks that will take some
time to understand).

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#20255: 'search-paths' should respect both user and system profile.

[Josselin Poiret via Bug reports for GNU Guix]

Hi Maxim,

Maxim Cournoyer  writes:

> Just to make sure, remove what exactly?

Remove the bit in /etc/profile that loads the user's profile, if it is
indeed supposed to be loaded by the user's own ~/.zprofile or
~/.bash_profile.  At least, I don't know if there is a general agreement
on what should be done in /etc/profile vs. the user's own config.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#20255: 'search-paths' should respect both user and system profile.

[Josselin Poiret via Bug reports for GNU Guix]

Hi,

宋文武 via Bug reports for GNU Guix  writes:

> Hello, commit 40310efde9b4a4f2cf98081d6cd10f843685ebb6 fix this by merge
> search-paths from multiple profiles by `guix package --search-paths`, in
> ~/.bashrc and ~/.zprofile (skeletons, so existed systems need manual
> update).  
>
>
> Close now!

I just checked and zsh does load /etc/profile by default on login, and
on guix system that also loads the user's profile by default.  Should we
remove this so that profiles are only loaded once?

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#63427: gdk-pixbuf unable to recognize image formats (JPG, PNG, etc.)

[Josselin Poiret via Bug reports for GNU Guix]

Hi Nathan,

Nathan Dehnel  writes:

> Gtk:ERROR:gtkiconhelper.c:494:
> ensure_surface_for_gicon: assertion
> failed (error == NULL): Failed to load
> /run/current-system/profile/share/icons/Adwaita/16x16/status/image-missing.png:
> Unrecognized image file format (gdk-pixbuf-error-quark, 3)
> Bail out! Gtk:ERROR:gtkiconhelper.c:494:ensure_surface_for_gicon:
> assertion failed (error == NULL): Failed to load
> /run/current-system/profile/share/icons/Adwaita/16x16/status/image-missing.png:
> Unrecognized image file format (gdk-pixbuf-error-quark, 3)
>
> This is breaking various apps like viewnior, xfce4-power-manager,
> causing firefox to crash when opening the file picker, making app
> icons not appear, etc.

So, GDK Pixbuf has a dynamic loader mechanism, where additional formats
can be added via additional loaders, which are usually all installed in
the same directory.  In Guix, this means that we need to point GDK
Pixbuf to a list of loaders to use that is dependent on what is
installed (there's no easy way to record this per-package, embed it
inside of it and then use that only there like with the ld cache).  For
that, we use the environment variable GDK_PIXBUF_MODULE_FILE, which is a
search-path for the package gdk-pixbuf, meaning that it is set only if
gdk-pixbuf is installed in your profile.

Now, if we had packaged everything properly, all the applications you
mention should *propagate* gdk-pixbuf and not just list it as an input,
so that it always gets installed to the profile as well, but that's not
the case!  The reason it doesn't happen for other users is because they
have some applications which pull in gdk-pixbuf inside the profile!  So
we should fix this and propagate gdk-pixbuf everywhere (something which
I'm not too much a fan of, but alas).

In the meantime, you can manually install gdk-pixbuf to your profile,
log-out and log-in and it should hopefully work.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#63426: hikari 2.3.3 build failure

[Josselin Poiret via Bug reports for GNU Guix]

Hi,

"bdju" via Bug reports for GNU Guix  writes:

> guix (GNU Guix) e0c35d1578c10a8fe27c8372f3a8bb5dd88b01b8
> guix system
> hikari build log attached

I tried to look into it before the core-updates merge, but it seems that
hikari is not maintained anymore, so I don't expect it to work with
newer wlroots.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#63414: Evaluation comparison on cuirass

[Josselin Poiret via Bug reports for GNU Guix]

Hi Andreas,

Andreas Enge  writes:

> When working on a branch and deciding whether to merge it, we need a way
> of comparing its status with that of the master branch. As far as I can see,
> there is currently no way in cuirass to compare arbitrary evaluations and
> get a list (or a dashboard) of builds that fail in one, but not the other.
>
> Andreas

I guess that this is one of the features that the Build Coordinator was
built for (and it is pretty damn good at this).  Maybe we could start
considering whether it makes sense to duplicate effort on Cuirass and
the Build Coordinator?  I don't know how "production-ready" the build
coordinator is, compared to Cuirass?  Maybe we could target getting the
Build Coordinator up to feature parity with Cuirass so that it may be
used on a wider scale?  If this is something we want to focus on, we
could create a team around it and set clear goals, which would probably
lessen the burden that's on Chris currently.

I understand that Cuirass is general enough to support much more than
Guix, but the coordinator is a wonderful piece of software and our
workflows might be outgrowing it.

WDYT?

-- 
Josselin Poiret


signature.asc
Description: PGP signature