bug#67475: Close issue

[Csepp]

I don’t think your attempt worked, I added “-done” to the debbugs email address.

bug#64360: error: ghc-onetuple: unbound variable

[Csepp]

Csepp  writes:

> Csepp  writes:
>
>> Simon Tournier  writes:
>>
>>> Hi,
>>>
>>> Could you confirm on i686 native machine that you are able to reproduce
>>> the error with:
>>>
>>> $ guix time-machine --commit= 63660f0 -- shell yt-dlp
>>>
>>> ?
>>>
>>>
>>> On Fri, 30 Jun 2023 at 02:56, Csepp  wrote:
>>>
>>>> $ guix shell yt-dlp
>>>> Backtrace:
>>>> In srfi/srfi-1.scm:
>>>>586:17 19 (map1 (#< name: "yt-dlp" version: "202…>))
>>>> In guix/profiles.scm:
>>>>   1932:19 18 (_ _)
>>>> In guix/packages.scm:
>>>>   1371:17 17 (supported-package? # …)
>>>> In guix/memoization.scm:
>>>> 101:0 16 (_ # # …)
>>>> In guix/packages.scm:
>>>>   1349:39 15 (_)
>>>>   1611:16 14 (package->bag _ _ _ #:graft? _)
>>>>   1715:47 13 (thunk)
>>>> In gnu/packages/video.scm:
>>>>   2615:11 12 (native-inputs #)
>>>> In guix/packages.scm:
>>>>   1371:17 11 (supported-package? # …)
>>>> In guix/memoization.scm:
>>>> 101:0 10 (_ # # …)
>>>> In guix/packages.scm:
>>>>   1349:39  9 (_)
>>>>   1611:16  8 (package->bag _ _ _ #:graft? _)
>>>>   1712:48  7 (thunk)
>>>> In gnu/packages/haskell-xyz.scm:
>>>>   9121:35  6 (inputs #)
>>>> In guix/packages.scm:
>>>>   1424:32  5 (package-closure _ #:system _)
>>>>   1611:16  4 (package->bag _ _ _ #:graft? _)
>>>>   1712:48  3 (thunk)
>>>> In gnu/packages/haskell-web.scm:
>>>>943:18  2 (inputs #)
>>>> In ice-9/boot-9.scm:
>>>>   1685:16  1 (raise-exception _ #:continuable? _)
>>>>   1685:16  0 (raise-exception _ #:continuable? _)
>>>>
>>>> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
>>>> error: ghc-onetuple: unbound variable
>>>
>>>> Running guix search ghc-onetuple indeed does not turn anything up.
>>>> guix search ghc-aeson results in the same error halfway through
>>>> outputting the description for ghc-aeson.
>>>
>>> The package ghc-onetuple is defined.  As far I can read, it is as the
>>> same place since 49a320aaa6fb4c20d6b30c56c35a8c7ffceed822:
>>>
>>> AuthorDate: Sun Jan 15 10:09:44 2023 +0100
>>> CommitDate: Sun Feb 26 10:26:07 2023 +0100
>>>
>>> And in this report speaks elsewhere about
>>> 63660f0febb4aa0d5260791c82dfde15c0df4c79, which comes after:
>>>
>>> AuthorDate: Tue Jun 27 15:43:27 2023 -0400
>>> CommitDate: Tue Jun 27 15:43:27 2023 -0400
>>>
>>> For instance, see [1].  Therefore, I do not think the issue comes from
>>> that.  Running,
>>>
>>>   $ guix time-machine --commit= 63660f0 -- shell -s i686-linux yt-dlp
>>>
>>> I get the error:
>>>
>>> build of 
>>> /gnu/store/n2yl83p37j9mazjh58d5fxixjiq188px-ghc-base64-0.4.2.4.drv failed
>>>
>>> and the message reads:
>>>
>>> starting phase `check'
>>> running "runhaskell Setup.hs" with command "test" and parameters ()
>>> Running 1 test suites...
>>> Test suite tasty: RUNNING...
>>>
>>> Test suite tasty: FAIL
>>> Test suite logged to: dist/test/base64-0.4.2.4-tasty.log
>>> 0 of 1 test suites (0 of 1 test cases) passed.
>>> error: in phase 'check': uncaught exception:
>>> %exception #< program: "runhaskell" arguments: 
>>> ("-package-db=/tmp/guix-build-ghc-base64-0.4.2.4.drv-0/package.conf.d" 
>>> "Setup.hs" "test") exit-status: 1 term-signal: #f stop-signal: #f>
>>> phase `check' failed after 0.3 seconds
>>>
>>>
>>> 1:
>>> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/haskell-xyz.scm?id=63660f0febb4aa0d5260791c82dfde15c0df4c79#n15164
>>>
>>> Cheers,
>>> simon
>>
>> Got an error, but not the same one.
>>
>> ...
>> building 
>> /gnu/store/c7vzg80lankn28pmb53lhfclgw8xdnxk-inferior-script.scm.drv...
>> building package cache...
>> building profile with 1 package...
>> hint: Consider passing the `--check' option once to make sure your shell 
>> does not clobber environment variables.
>>
>> Backtrace:
>> In ice-9/boot-9.scm:
>>222:29 19 (map1 _)
>>222:29 

bug#64360: error: ghc-onetuple: unbound variable

[Csepp]

Csepp  writes:

> Simon Tournier  writes:
>
>> Hi,
>>
>> Could you confirm on i686 native machine that you are able to reproduce
>> the error with:
>>
>> $ guix time-machine --commit= 63660f0 -- shell yt-dlp
>>
>> ?
>>
>>
>> On Fri, 30 Jun 2023 at 02:56, Csepp  wrote:
>>
>>> $ guix shell yt-dlp
>>> Backtrace:
>>> In srfi/srfi-1.scm:
>>>586:17 19 (map1 (#< name: "yt-dlp" version: "202…>))
>>> In guix/profiles.scm:
>>>   1932:19 18 (_ _)
>>> In guix/packages.scm:
>>>   1371:17 17 (supported-package? # …)
>>> In guix/memoization.scm:
>>> 101:0 16 (_ # # …)
>>> In guix/packages.scm:
>>>   1349:39 15 (_)
>>>   1611:16 14 (package->bag _ _ _ #:graft? _)
>>>   1715:47 13 (thunk)
>>> In gnu/packages/video.scm:
>>>   2615:11 12 (native-inputs #)
>>> In guix/packages.scm:
>>>   1371:17 11 (supported-package? # …)
>>> In guix/memoization.scm:
>>> 101:0 10 (_ # # …)
>>> In guix/packages.scm:
>>>   1349:39  9 (_)
>>>   1611:16  8 (package->bag _ _ _ #:graft? _)
>>>   1712:48  7 (thunk)
>>> In gnu/packages/haskell-xyz.scm:
>>>   9121:35  6 (inputs #)
>>> In guix/packages.scm:
>>>   1424:32  5 (package-closure _ #:system _)
>>>   1611:16  4 (package->bag _ _ _ #:graft? _)
>>>   1712:48  3 (thunk)
>>> In gnu/packages/haskell-web.scm:
>>>943:18  2 (inputs #)
>>> In ice-9/boot-9.scm:
>>>   1685:16  1 (raise-exception _ #:continuable? _)
>>>   1685:16  0 (raise-exception _ #:continuable? _)
>>>
>>> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
>>> error: ghc-onetuple: unbound variable
>>
>>> Running guix search ghc-onetuple indeed does not turn anything up.
>>> guix search ghc-aeson results in the same error halfway through
>>> outputting the description for ghc-aeson.
>>
>> The package ghc-onetuple is defined.  As far I can read, it is as the
>> same place since 49a320aaa6fb4c20d6b30c56c35a8c7ffceed822:
>>
>> AuthorDate: Sun Jan 15 10:09:44 2023 +0100
>> CommitDate: Sun Feb 26 10:26:07 2023 +0100
>>
>> And in this report speaks elsewhere about
>> 63660f0febb4aa0d5260791c82dfde15c0df4c79, which comes after:
>>
>> AuthorDate: Tue Jun 27 15:43:27 2023 -0400
>> CommitDate: Tue Jun 27 15:43:27 2023 -0400
>>
>> For instance, see [1].  Therefore, I do not think the issue comes from
>> that.  Running,
>>
>>   $ guix time-machine --commit= 63660f0 -- shell -s i686-linux yt-dlp
>>
>> I get the error:
>>
>> build of 
>> /gnu/store/n2yl83p37j9mazjh58d5fxixjiq188px-ghc-base64-0.4.2.4.drv failed
>>
>> and the message reads:
>>
>> starting phase `check'
>> running "runhaskell Setup.hs" with command "test" and parameters ()
>> Running 1 test suites...
>> Test suite tasty: RUNNING...
>>
>> Test suite tasty: FAIL
>> Test suite logged to: dist/test/base64-0.4.2.4-tasty.log
>> 0 of 1 test suites (0 of 1 test cases) passed.
>> error: in phase 'check': uncaught exception:
>> %exception #< program: "runhaskell" arguments: 
>> ("-package-db=/tmp/guix-build-ghc-base64-0.4.2.4.drv-0/package.conf.d" 
>> "Setup.hs" "test") exit-status: 1 term-signal: #f stop-signal: #f>
>> phase `check' failed after 0.3 seconds
>>
>>
>> 1:
>> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/haskell-xyz.scm?id=63660f0febb4aa0d5260791c82dfde15c0df4c79#n15164
>>
>> Cheers,
>> simon
>
> Got an error, but not the same one.
>
> ...
> building 
> /gnu/store/c7vzg80lankn28pmb53lhfclgw8xdnxk-inferior-script.scm.drv...
> building package cache...
> building profile with 1 package...
> hint: Consider passing the `--check' option once to make sure your shell does 
> not clobber environment variables.
>
> Backtrace:
> In ice-9/boot-9.scm:
>222:29 19 (map1 _)
>222:29 18 (map1 _)
>222:29 17 (map1 _)
>222:29 16 (map1 _)
>222:29 15 (map1 _)
>222:29 14 (map1 _)
>222:29 13 (map1 _)
>222:29 12 (map1 _)
>222:17 11 (map1 (((gnu packages tex)) ((gnu packages xml)) ((…)) …))
>   3327:17 10 (resolve-interface (gnu packages tex) #:select _ #:hide …)
> In ice-9/threads.scm:
> 390:8  9 (_ _)
> In ice-9/boot-9.scm:
>   3253:13  8 (_)
> In ice-9/threads.scm:
> 390:8  7 (_ _)
> In 

bug#64360: error: ghc-onetuple: unbound variable

[Csepp]

Simon Tournier  writes:

> Hi,
>
> Could you confirm on i686 native machine that you are able to reproduce
> the error with:
>
> $ guix time-machine --commit= 63660f0 -- shell yt-dlp
>
> ?
>
>
> On Fri, 30 Jun 2023 at 02:56, Csepp  wrote:
>
>> $ guix shell yt-dlp
>> Backtrace:
>> In srfi/srfi-1.scm:
>>586:17 19 (map1 (#< name: "yt-dlp" version: "202…>))
>> In guix/profiles.scm:
>>   1932:19 18 (_ _)
>> In guix/packages.scm:
>>   1371:17 17 (supported-package? # …)
>> In guix/memoization.scm:
>> 101:0 16 (_ # # …)
>> In guix/packages.scm:
>>   1349:39 15 (_)
>>   1611:16 14 (package->bag _ _ _ #:graft? _)
>>   1715:47 13 (thunk)
>> In gnu/packages/video.scm:
>>   2615:11 12 (native-inputs #)
>> In guix/packages.scm:
>>   1371:17 11 (supported-package? # …)
>> In guix/memoization.scm:
>> 101:0 10 (_ # # …)
>> In guix/packages.scm:
>>   1349:39  9 (_)
>>   1611:16  8 (package->bag _ _ _ #:graft? _)
>>   1712:48  7 (thunk)
>> In gnu/packages/haskell-xyz.scm:
>>   9121:35  6 (inputs #)
>> In guix/packages.scm:
>>   1424:32  5 (package-closure _ #:system _)
>>   1611:16  4 (package->bag _ _ _ #:graft? _)
>>   1712:48  3 (thunk)
>> In gnu/packages/haskell-web.scm:
>>943:18  2 (inputs #)
>> In ice-9/boot-9.scm:
>>   1685:16  1 (raise-exception _ #:continuable? _)
>>   1685:16  0 (raise-exception _ #:continuable? _)
>>
>> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
>> error: ghc-onetuple: unbound variable
>
>> Running guix search ghc-onetuple indeed does not turn anything up.
>> guix search ghc-aeson results in the same error halfway through
>> outputting the description for ghc-aeson.
>
> The package ghc-onetuple is defined.  As far I can read, it is as the
> same place since 49a320aaa6fb4c20d6b30c56c35a8c7ffceed822:
>
> AuthorDate: Sun Jan 15 10:09:44 2023 +0100
> CommitDate: Sun Feb 26 10:26:07 2023 +0100
>
> And in this report speaks elsewhere about
> 63660f0febb4aa0d5260791c82dfde15c0df4c79, which comes after:
>
> AuthorDate: Tue Jun 27 15:43:27 2023 -0400
> CommitDate: Tue Jun 27 15:43:27 2023 -0400
>
> For instance, see [1].  Therefore, I do not think the issue comes from
> that.  Running,
>
>   $ guix time-machine --commit= 63660f0 -- shell -s i686-linux yt-dlp
>
> I get the error:
>
> build of 
> /gnu/store/n2yl83p37j9mazjh58d5fxixjiq188px-ghc-base64-0.4.2.4.drv failed
>
> and the message reads:
>
> starting phase `check'
> running "runhaskell Setup.hs" with command "test" and parameters ()
> Running 1 test suites...
> Test suite tasty: RUNNING...
>
> Test suite tasty: FAIL
> Test suite logged to: dist/test/base64-0.4.2.4-tasty.log
> 0 of 1 test suites (0 of 1 test cases) passed.
> error: in phase 'check': uncaught exception:
> %exception #< program: "runhaskell" arguments: 
> ("-package-db=/tmp/guix-build-ghc-base64-0.4.2.4.drv-0/package.conf.d" 
> "Setup.hs" "test") exit-status: 1 term-signal: #f stop-signal: #f>
> phase `check' failed after 0.3 seconds
>
>
> 1:
> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/haskell-xyz.scm?id=63660f0febb4aa0d5260791c82dfde15c0df4c79#n15164
>
> Cheers,
> simon

Got an error, but not the same one.

...
building /gnu/store/c7vzg80lankn28pmb53lhfclgw8xdnxk-inferior-script.scm.drv...
building package cache...
building profile with 1 package...
hint: Consider passing the `--check' option once to make sure your shell does 
not clobber environment variables.

Backtrace:
In ice-9/boot-9.scm:
   222:29 19 (map1 _)
   222:29 18 (map1 _)
   222:29 17 (map1 _)
   222:29 16 (map1 _)
   222:29 15 (map1 _)
   222:29 14 (map1 _)
   222:29 13 (map1 _)
   222:29 12 (map1 _)
   222:17 11 (map1 (((gnu packages tex)) ((gnu packages xml)) ((…)) …))
  3327:17 10 (resolve-interface (gnu packages tex) #:select _ #:hide …)
In ice-9/threads.scm:
390:8  9 (_ _)
In ice-9/boot-9.scm:
  3253:13  8 (_)
In ice-9/threads.scm:
390:8  7 (_ _)
In ice-9/boot-9.scm:
  3544:20  6 (_)
   2836:4  5 (save-module-excursion _)
  3564:26  4 (_)
In unknown file:
   3 (primitive-load-path "gnu/packages/tex" #)
In gnu/packages/tex.scm:
GC Warning: Failed to expand heap by 8388608 bytes
...repeats a bunch of times...
GC Warning: Failed to expand heap by 8388608 bytes
GC Warning: Failed to expand heap by 65536 bytes
GC Warning: Out of Memory! Heap size: 2498 MiB. Returning NULL!
Exception thrown while printing backtrace:
Out of memory

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
error: license:arphic-1999: unbound variable

bug#67130: Liferea/glib crash

[Csepp]

This happened after wakeup under seemingly high (IO) load when I clicked
on a link.  The window just disappeared.
I had dmesg --follow already open and this showed up:
[ 6158.088405] traps: WatchDogQueue[4000] trap int3 ip:7fd2425409cf 
sp:7fd1dd7fb620 error:0 in libglib-2.0.so.0.7200.3[7fd242504000+88000]

liferea:
/gnu/store/pbwp8fjiwy727hq6aafzwyvig57s9zmk-liferea-1.13.4
glib:
/gnu/store/znx6vjadh4az7fzxz7x649ki9qzqnjp3-glib-2.72.3
guix describe output:
Generation 223  Nov 02 2023 08:58:48(current)
  guix f534609
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: f5346094f0365a2c04ca00111ff06e17dac832e2
  raingloom b528a4a
repository URL: https://git.sr.ht/~raingloom/guix-packages
branch: master
commit: b528a4a906011efb52bc4db916408c5f12f387ec
  guix-science 25ce86c
repository URL: https://github.com/guix-science/guix-science.git
branch: master
commit: 25ce86cd74f38d7c17d1d90a8271758959702f43
  nonguix e14c0e2
repository URL: https://gitlab.com/nonguix/nonguix.git
branch: master
commit: e14c0e2184e01709472658b7a73e7c9e2461dce2

bug#39677: Evolution's inbox widget is blank

[Csepp]

Simon Tournier  writes:

> Hi,
>
> It is about this old bug#39677 [1].  Sorry for not noticing it before.
>
> 1: 
>
>
> On Tue, 18 Oct 2022 at 17:53, zimoun  wrote:
>> On Wed, 19 Feb 2020 at 15:20, raingloom  wrote:
>>
>>> I've been haunted by this for months, so it's high time I make a proper bug
>>> report.
>>>
>>> I wiped all Evolution related directories I could find in .cache, .config, 
>>> and
>>> .local, and reconfigured it from scratch, but that didn't help.
>>>
>>> When I open Evolution it prompts me for my password and pulls my emails
>>> without a problem, even shows a notification for them, but it doesn't
>>> display anything.
>>>
>>> It's not a font issue, because the scroll bar does not appear. There are no
>>> emails displayed at all. Double clicking on it should open a mail in a new
>>> window, but no window appears.
>>>
>>> I tried it in a VM that's a slight modification of my system, that had no
>>> problems.
>>> I also tried it in both i3wm and Gnome, but the results are identical.
>>>
>>> All I see in the log is this:
>>> ```
>>> (evolution:23706): GLib-GIO-WARNING **: 15:17:11.805: Your application did 
>>> not
>>> unregister from D-Bus before destruction. Consider using 
>>> g_application_run().
>>> ```
>>>
>>> I can send an strace log if necessary. The one I took was a bit long and
>>> didn't reveal much, but someone might have better luck.
>>>
>>> Any tips on where I should look?
>>>
>>> I suspect that it either doesn't play nice with some other package or that
>>> there is some state corruption I couldn't track down.
>>>
>>> For now I'll just use Geary for this account.
>>
>> Well, I am not an user of Evolution.  The question is: is it still an
>> issue for you?  If yes, are you running Guix on foreign distro?  Or Guix
>> System?
>
> Without any answer since 18 Oct 2022 (51 weeks, 6 days, 6 hours ago), I
> deduce it is not an issue anymore.  So I am going to close this issue
> soon.
>
> Cheers,
> simon

I haven't used Evolution for a long time, so if no one else reported
this, then hopefully it means it's no longer an issue.

bug#66651: How to pass i915.enable_guc=0 in config.scm to prevent a 'wedged' GPU?

[Csepp]

Hugo Buddelmeijer  writes:

> The i915 driver will try to load the GuC firmware, at least for Iris
> Xe chips. Loading the GuC firmware fails because it is non-free and
> deblobbed. As a result, some software, like sway, will not work.
>
> It is possible to manually pass the i915.enable_guc=0 kernel parameter
> at boot from grub. Then everything works as intended. However, it
> seems not possible to set this parameter from config.scm.
>
> So at the moment my system is not fully declarative, as I have to type
> in a kernel parameter at boot; does anyone perhaps have advice on how
> can this be done better?
> ...

You can use the kernel-arguments option in the operating-system config.
Untested:
(kernel-arguments (cons "i915.enable_guc=0" %default-kernel-arguments))
This should work, in theory.

I suspect that the sysctl thing doesn't work because it is done too late
in the boot process.

bug#61882: emacs-next-pgtk does not find emacs-org-roam, other path issues

[Csepp]

Maxim Cournoyer  writes:

> tags 61882 = moreinfo unreproducible
> quit
>
> Hi,
>
> Csepp  writes:
>
>> Maxim Cournoyer  writes:
>>
>>> Hi,
>>>
>>> Csepp  writes:
>>>
>>>> Maxim Cournoyer  writes:
>>>>
>>>>> tags 61882 +notabug
>>>>> quit
>>>>
>>>> I don't think notabug applies until we actually know the root
>>>> cause.
>>>
>>> Sadly I don't think there's anything actionable here until you can
>>> reproduce the problem and share the recipe with us, so I wanted to
>>> close
>>> the issue without it being marked as "resolved".
>>
>> Neither "resolved" nor "notabug" are applicable. If stalled incident
>> reports / issues are a problem, they should probably be marked as
>> stalled, or needinfo, for easy filtering. Marking it as notabug is
>> just
>> going to make the job of the next person harder when they search for
>> issues related to these symptoms.
>
> I don't think a bug as particular as 'my profile got corrupted'
> without
> any way to recreate it has much value; it's also the first time I've
> heard of such a report. That's why I'd prefer to treat it as an oddity
> and close it; if it reproduces (by you or others) let's reopen it,
> with
> fresh and clear information.
>
>> I appreciate all the work going into closing old issues, but I don't
>> think chasing a low open issue count should be a goal unto itself
>> See https://fvsch.com/stale-bots .
>
> To be clear, I wholly agree.  I've now tagged it as moreinfo and
> unreproducible.

It could be a file system bug, but while there are reports of BTRFS
being unstable in certain RAID modes, I would be very surprised if there
was a data corruption issue in the default single device mode.

My hunch is that Guix's profile update logic is not actually as atomic
as it's advertised and I interrupted it at the wrong moment.

bug#66553: Request to merge rust-team

[Csepp]

Efraim Flashner  writes:

> [[PGP Signed Part:Undecided]]
> IMO rust-team branch is ready to merge. We've updated rust to 1.70,
> librsvg to 2.56.4 and many new and updated packages. We've added a
> phase
> to the cargo-build-system to fail if it detects pre-built files and
> we've set the cargo-build-system to skip the test phase by default,
> allowing us to make sure that the packages have the correct inputs.
> With
> these changes I've gotten 100% of the packages built using the
> cargo-build-system to build successfully.
>
> We're looking forward to this merge so we can continue bumping the
> rust
> version, work on cross-compilation and try to reduce the number of
> packages which skip the build phase entirely.

Is the new build system still being worked on?

bug#58497: opam import doesn't work with ocaml_intrinsics among others

[Csepp]

Simon Tournier  writes:

> Hi,
>
> It is about bug#58497 [1], and I cannot reproduce.  I think the reported
> bug had been fixed.  I am in favor to close.  WDYT?
>
> 1: https://issues.guix.gnu.org/issue/58497
>
> On Thu, 13 Oct 2022 at 18:07, Csepp  wrote:
>
>> guix import opam ocaml_intrinsics
>> Backtrace:
>
> Using Guix 6113e05, I get:
>
> --8<---cut here---start->8---
> $ guix import opam ocaml_intrinsics
> (package
>   (name "ocaml-intrinsics")
>   (version "0.16.0")
>   (source no-source-information)
>   (build-system dune-build-system)
>   (propagated-inputs (list ocaml-dune-configurator))
>   (properties `((upstream-name . "ocaml_intrinsics")))
>   (home-page "https://github.com/janestreet/ocaml_intrinsics;)
>   (synopsis "Intrinsics")
>   (description
>"This package provides functions to invoke amd64 instructions (such as
> clz,popcnt,rdtsc,rdpmc) when available, or compatible software implementation 
> on
> other targets.")
>   (license license:expat))
> --8<---cut here---end--->8---
>
>
> Cheers,
> simon

Yup, seems to "work" now, although that no-source-information thing is
still pretty irritating, but it happens infrequently enough to not
matter too much.

bug#61882: emacs-next-pgtk does not find emacs-org-roam, other path issues

[Csepp]

Maxim Cournoyer  writes:

> Hi,
>
> Csepp  writes:
>
>> Maxim Cournoyer  writes:
>>
>>> tags 61882 +notabug
>>> quit
>>
>> I don't think notabug applies until we actually know the root cause.
>
> Sadly I don't think there's anything actionable here until you can
> reproduce the problem and share the recipe with us, so I wanted to close
> the issue without it being marked as "resolved".

Neither "resolved" nor "notabug" are applicable.  If stalled incident
reports / issues are a problem, they should probably be marked as
stalled, or needinfo, for easy filtering.  Marking it as notabug is just
going to make the job of the next person harder when they search for
issues related to these symptoms.

I appreciate all the work going into closing old issues, but I don't
think chasing a low open issue count should be a goal unto itself
See https://fvsch.com/stale-bots .

bug#61882: emacs-next-pgtk does not find emacs-org-roam, other path issues

[Csepp]

Maxim Cournoyer  writes:

> tags 61882 +notabug
> quit

I don't think notabug applies until we actually know the root cause.

> Hello,
>
> Csepp  writes:
>
>> (Jump forward a bit, this is a bit stream-of-consciousness-y, I
>> wrote
>> things down as I was debugging things. TLDR: profile got corrupted
>> somehow, it's not related to the packages themselves.)
>>
>> Certain packages like flatpak do not get installed in my main user
>> profile for some unknown reason.
>> So far they are:
>> * gallery-dl
>> * flatpak
>> * emacs-org-roam
>>
>> It has been happening for at least a month across several pulls.
>>
>> If I export a manifest and load it in either guix shell -m or guix
>> package -m to a different profile, bin/flatpak exists, if I do guix
>> package -m without a profile argument or with the profile set to the
>> default user profile, bin/flatpak is missing.
>>
>> The packages that are broken are always the same.
>>
>> If I create a manifest with only the broken packages, guix package
>> -I
>> reports exactly those packages, but when I look in
>> ~/.guix-profile/bin
>> it still has a bunch of other packages in it.
>>
>> So it seems the profile is frozen?  I have no idea how this could
>> happen.
>>
>> guix package --list-generations reports three generations, but there
>> is
>> only one generation in my home directory, called
>> .guix-profile-1-link.
>>
>> There is also a .guix-profile.lock, maybe that's related?
>> I see no lock for the other profile with the same manifest.
>>
>> Removed the lock, tried guix package -m again, still don't have
>> flatpak,
>> still only one generation symlink.
>>
>> Deleted all the symlinks, ran guix package -m, now it works.
>>
>> I'm gonna hold off on running the GC for a few days, if anyone has
>> an
>> idea of where the bug is and wants me to upload some files, I can do
>> it
>> until then.
>> For my own reference, this is the store item of the broken profile:
>> /gnu/store/0w3jxl95cchxn14zph3lmnqwmijf8971-profile
>
> Did you have any corruption at the FS level or something equally bad?
> Were you using a different Guix in between the 'guix package -m'
> attempts?  If the profile was in the cache, it wouldn't rebuild it,
> and you'd be stuck with your broken version.
>
> I'm closing this, as I we don't have much to push the
> investigation further, but if you have a more precise idea of what
> happened and ways to reproduce that do reopen.

I'm pretty sure I already went through these, but once again, to be sure:
- no there was no file system corruption as far as I could tell
- store was checked for corruption multiple times
- the issue persisted through multiple guix pulls
- only one profile was affected

bug#55136: keepassxc segfaults when merging databases

[Csepp]

Maxim Cournoyer  writes:

> Hello,
>
> raingloom  writes:
>
>> On Thu, 09 Jun 2022 23:42:35 -0400
>> Aurora  wrote:
>>
>>> Maxim Cournoyer  writes:
>>> >> Strange, I use keepassxc regularly for a long time now and I've
>>> >> never seen it crash. Though I don't do complex stuff such as
>>> >> merging databases, just retrieval of users and passwords and
>>> >> creation of new entries.  
>>> >
>>> > I also use it everyday, but I simply open an existing (dated)
>>> > database and edit entries to it/use it. It seems to crash often
>>> > when creating new databases for me.
>>> >
>>> > Maxim  
>>> 
>>> I just tested Guix's Keepassxc v2.7.1 at Guix revision
>>> 01596f40a994a2bb39dde5867ca66e9f7e9e67e0 for merging newly created
>>> databases (KDBX4) with and without conflicts in entries.
>>> 
>>> I experienced no crashes. Unless keepassxc or its dependencies
>>> changed
>>> by the time I tested it, I think that something else might be
>>> interacting.
>>> 
>>> - Aurora
>>
>> Might very well be an upstream bug, I'll try to build it with debug
>> symbols and see if I can reproduce it with the latest Guix commit.
>
> Any update?  Do newer versions work better for you?

Seems to work right now, I guess we can close it for now.

bug#66014: Unable to use UUIDs to construct RAID array in mapped-devices

[Csepp]

Ludovic Courtès  writes:

> Hi,
>
> Csepp  skribis:
>
>> Lars Rustand  writes:
>
> [...]
>
>>> But this one fails:
>>>
>>>   (mapped-devices
>>> (list
>>>   (mapped-device
>>> (source (list (uuid "a07c54da-eb61-4135-86b8-8791e863e46a") (uuid 
>>> "c40026af-ace9-47fc-9d3f-4b8d6a2219cb")))
>>> (target "/dev/md0")
>>> (type raid-device-mapping
>>>
>>> The error message I get is guix system: error: #< type: dce bv: 
>>> #vu8(160 124 84 218 235 97 65 53 134 184 135 145 232 99 228 106)>: invalid 
>>> G-expression input
>>>
>>> [[End of PGP Signed Part]]
>>
>> Would it be possible to use /dev/disk/by-uuid paths instead of uuid
>> objects for these?
>
> Depends: /dev/disk/by-uuid is populated by eudev, which is not running
> at the time initrd code runs; IOW it’s OK to use /dev/disk/by-uuid if
> and only if the mapped device is not “needed for boot”.
>
>> I think this big "typeof" based dynamic dispatch that we're using in
>> Scheme is erm, not very robust, to put it mildly.
>
> Yeah, it’s not great.  What would you suggest?
>
> Ludo’.

I guess MyPy-for-Guile is a bit out of scope for now, so the next best
way to catch these would be property based testing.
As for implementing them, can't we use Guile's generics, or model
something on Clojure's generics?  Something that lets client code add
implementations to an interface.  Although that might have some security
implications.

bug#66014: Unable to use UUIDs to construct RAID array in mapped-devices

[Csepp]

Lars Rustand  writes:

> [[PGP Signed Part:Undecided]]
> Setting up a RAID array using UUIDs does not work.
>
> The following mapped-devices block works:
>
>   (mapped-devices
> (list
>   (mapped-device
> (source (list "/dev/nvme0n1p2" "/dev/nvme1n1p3"))
> (target "/dev/md0")
> (type raid-device-mapping
>
> But this one fails:
>
>   (mapped-devices
> (list
>   (mapped-device
> (source (list (uuid "a07c54da-eb61-4135-86b8-8791e863e46a") (uuid 
> "c40026af-ace9-47fc-9d3f-4b8d6a2219cb")))
> (target "/dev/md0")
> (type raid-device-mapping
>
> The error message I get is guix system: error: #< type: dce bv: 
> #vu8(160 124 84 218 235 97 65 53 134 184 135 145 232 99 228 106)>: invalid 
> G-expression input
>
> [[End of PGP Signed Part]]

Would it be possible to use /dev/disk/by-uuid paths instead of uuid
objects for these?  I think this big "typeof" based dynamic dispatch
that we're using in Scheme is erm, not very robust, to put it mildly.

bug#65925: bluez or jack in the closure of python-ipython?

[Csepp]

Simon Tournier  writes:

> Hi,
>
> On Thu, 14 Sep 2023 at 10:11, Csepp  wrote:
>
>> Seem pretty self-explanatory:
>> matplotlib has a GUI frontend (or even multiple frontends), one of
>> them
>> is based on WxWidgets, which pulls in SDL2, and Guix doesn't split
>> SDL2
>> like some other distros do, so all its dependencies get pulled in.
>> In case you are not familiar with SDL(2), it's a portable "direct
>> media
>> layer", a library used for portable multimedia applications.
>
> So could you explain why bluez is not in the closure
> python-matplotlib?
>
> --8<---cut here---start->8---
> $ guix size python-matplotlib | grep '/gnu/store/' | cut -f1 -d' ' | cut -f2- 
> -d'-' | sort
> bash-minimal-5.1.16
> bash-static-5.1.16
> bzip2-1.0.8
> bzip2-1.0.8
> expat-2.5.0
> fontconfig-minimal-2.14.0
> font-dejavu-2.37
> freetype-2.13.0
> gcc-11.3.0-lib
> gdbm-1.23
> glibc-2.35
> libffi-3.4.4
> libpng-1.6.37
> libx11-1.8.1
> libxau-1.0.10
> libxcb-1.15
> libxdmcp-1.1.3
> libxft-2.3.4
> libxrender-0.9.10
> ncurses-6.2.20210619
> openssl-3.0.8
> python-3.10.7
> python-matplotlib-3.5.2
> qhull-2020.2
> readline-8.1.2
> sqlite-3.39.3
> tcl-8.6.12
> tk-8.6.12
> xz-5.2.8
> zlib-1.2.13
> --8<---cut here---end--->8---
>
> And then why it is in the closure of python-ipython?
>
> And as I pointed, bluez is not in the closure of any dependencies of
> python-ipython.
>
> Cheers,
> simon

Oh, bluez I have no idea about. :|
That is super weird.

bug#65925: bluez or jack in the closure of python-ipython?

[Csepp]

Simon Tournier  writes:

> Hi,
>
> IPython is a Python REPL and there is no direct dependencies on bluez or
> jack.  Why does it need unrelated tools as some Bluetooth or JACK audio?
>
> [...]
> Last, the chain of dependencies looks like:
>
> $ guix graph --path python-ipython bluez
> python-ipython@8.5.0
> python-matplotlib@3.5.2
> python-wxpython@4.2.0
> wxwidgets@3.2.2.1
> sdl2@2.26.2
> pulseaudio@16.1
> bluez@5.66
> [...]

Seem pretty self-explanatory:
matplotlib has a GUI frontend (or even multiple frontends), one of them
is based on WxWidgets, which pulls in SDL2, and Guix doesn't split SDL2
like some other distros do, so all its dependencies get pulled in.
In case you are not familiar with SDL(2), it's a portable "direct media
layer", a library used for portable multimedia applications.

bug#65890: VICE encounters illegal instruction

[Csepp]

Csepp  writes:

> trying to run a music disk, but even if I pass no parameter, I get the
> same error at the end
>
> % xplus4 TED-Vibes-2.d64:(
> Detecting ISA HardSID boards.
> Could not open '/dev/port'.
> Cannot get permission to access $300.
> Detecting PCI HardSID boards.
> No PCI HardSID boards found.
>  
> *** VICE Version 3.7.1 ***
>  
> Welcome to xplus4, the free portable PLUS4 Emulator.
>  
> Current VICE team members:
> Martin Pottendorfer, Marco van den Heuvel, Fabrizio Gennari, Groepaz, 
> Errol Smith, Ingo Korb, Olaf Seibert, Marcus Sutton, Kajtar Zsolt, AreaScout, 
> Bas Wassink, Michael C. Martin, Christopher Phillips, David Hogan, 
> Empathic Qubit, Roberto Muscedere, June Tate-Gans, Pablo Roldan.
>  
> This is free software with ABSOLUTELY NO WARRANTY.
> See the "About VICE" command for more info.
>  
> random seed was: 0x65004c19
> command line was: xplus4 TED-Vibes-2.d64
> Loading system file 
> `/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/PLUS4/kernal-318004-05.bin'.
> Loading system file 
> `/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/PLUS4/basic-318006-01.bin'.
> Loading system file 
> `/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/PLUS4/3plus1-317053-01.bin'.
> Loading system file 
> `/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/PLUS4/3plus1-317054-01.bin'.
> GTK3MOUSE: Status changed: 0 (disabled)
> Loading system file 
> `/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/PRINTER/mps803.bin'.
> Palette: Loading palette 
> `/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/PRINTER/mps803.vpl'.
> Loading system file 
> `/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/PRINTER/nl10.bin'.
> Palette: Loading palette 
> `/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/PRINTER/nl10.vpl'.
> NL10: Printer driver initialized.
> Palette: Loading palette 
> `/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/PRINTER/1520.vpl'.
> Loading system file 
> `/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/DRIVES/dos1540-325302+3-01.bin'.
> Loading system file 
> `/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/DRIVES/dos1541-325302-01+901229-05.bin'.
> Loading system file 
> `/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/DRIVES/dos1541ii-251968-03.bin'.
> Loading system file 
> `/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/DRIVES/dos1570-315090-01.bin'.
> Loading system file 
> `/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/DRIVES/dos1571-310654-05.bin'.
> Loading system file 
> `/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/DRIVES/dos1581-318045-02.bin'.
> DriveROM: Error - 2000 ROM image not found. Hardware-level 2000 emulation is 
> not available.
> DriveROM: Error - 4000 ROM image not found. Hardware-level 4000 emulation is 
> not available.
> DriveROM: Error - CMDHD ROM image not found. Hardware-level CMDHD emulation 
> is not available.
> Loading system file 
> `/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/DRIVES/dos1551-318008-01.bin'.
> Drive: Finished loading ROM images.
> Sound: Available sound devices: pulse alsa dummy fs dump wav voc iff aiff 
> soundmovie
> using GTK3 backend: OpenGL
> chip_name: TED
>  screen_size: 384 x 312
>  first/lastline: 0 x 0
>  gfx_size: 320 x 200
>  gfx_position: 32 x 59
>  first/last displayed line: 19 x 306
>  extra offscreen border left/right: 28 x 228
>  screen_display_wh: 0.00 x 0.00
>  canvas_physical_wh: 0 x 0
>  scalexy: 2 x 2
>  sizexy: 1 x 1
>  rmode: 1
>  aspect ratio: 1.037435
>  hstretch: 0
>  vstretch: 0
>  initializing with width, height: 704 x 574
> GLX version: 1.4
> Getting matching framebuffer configs
> Found 6 matching FB configs.
> Error - Failed to obtain an OpenGL 3.2 context, requesting a legacy context
>
> Obtained OpenGL 2.1 context
> Vendor: Intel
>   Renderer: Mesa Mobile Intel® GM45 Express Chipset (CTG)
>Version: 2.1 Mesa 23.1.4
> Legacy: yes
> Direct GLX rendering context obtained
> Swap control support. glXSwapIntervalMESA: 1 glXSwapIntervalEXT: 1 
> glXSwapIntervalSGI: 1
> Created render thread 0
> Render thread initialised
> Joystick: Linux joystick interface initialization...
> Joystick: Warning - Cannot open joystick device `/dev/input/js0'.
> Joystick: Warning - Cannot open joystick device `/dev/input/js1'.
> Joystick: Warning - Cannot open joystick device `/dev/input/js2'.
> Joystick: Warning - Cannot open joystick dev

bug#56567: [BUG] Gnome doesn't recognize applications path for flatpak

[Csepp]

Liliana Marie Prikler  writes:

> Am Sonntag, dem 17.07.2022 um 06:03 + schrieb Jacob Hrbek:
>> Why is making a user configuration saner in comparison to making it
>> work out of the box?
> Because in this instance "making it work out of the box" entails
> statefulness that most Guix users would typically like to avoid.  Plus,
> we are not talking about a very complicated setup here, it's one line
> of shell code to drop into your .bash_profile or similar:
>
> export
> $XDG_DATA_DIRS="$HOME/.local/share/flatpak/exports/share:$XDG_DATA_DIRS
> "
>
> Now granted, if you wanted to account for the fact that XDG_DATA_DIRS
> could be empty on some systems (some foreign distros rely on the
> implicit default), then you'd have to code around that, but that's
> again not within the scope of Guix System.

Since I am running into this same issue on Sway, *even though* I added
that line to my Zsh profile, I don't think the user config route is the
right one to recommend.
Editing environment variables certainly *seems* easy, but I consider
myself fairly adept at Linux and I could not tell you in what order they
are loaded, and clearly it matters, since j4-dmenu-desktop gets the
wrong variables when launched from Sway, but the right ones when
launched from a terminal.  Even though Sway was also run from a
terminal, via dbus-run-session.
So clearly there are a lot of moving parts, and a regular user who just
wants desktop apps to work should not be expected to manually edit these
files.

bug#65890: VICE encounters illegal instruction

[Csepp]

trying to run a music disk, but even if I pass no parameter, I get the
same error at the end

% xplus4 TED-Vibes-2.d64:(
Detecting ISA HardSID boards.
Could not open '/dev/port'.
Cannot get permission to access $300.
Detecting PCI HardSID boards.
No PCI HardSID boards found.
 
*** VICE Version 3.7.1 ***
 
Welcome to xplus4, the free portable PLUS4 Emulator.
 
Current VICE team members:
Martin Pottendorfer, Marco van den Heuvel, Fabrizio Gennari, Groepaz, 
Errol Smith, Ingo Korb, Olaf Seibert, Marcus Sutton, Kajtar Zsolt, AreaScout, 
Bas Wassink, Michael C. Martin, Christopher Phillips, David Hogan, 
Empathic Qubit, Roberto Muscedere, June Tate-Gans, Pablo Roldan.
 
This is free software with ABSOLUTELY NO WARRANTY.
See the "About VICE" command for more info.
 
random seed was: 0x65004c19
command line was: xplus4 TED-Vibes-2.d64
Loading system file 
`/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/PLUS4/kernal-318004-05.bin'.
Loading system file 
`/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/PLUS4/basic-318006-01.bin'.
Loading system file 
`/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/PLUS4/3plus1-317053-01.bin'.
Loading system file 
`/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/PLUS4/3plus1-317054-01.bin'.
GTK3MOUSE: Status changed: 0 (disabled)
Loading system file 
`/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/PRINTER/mps803.bin'.
Palette: Loading palette 
`/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/PRINTER/mps803.vpl'.
Loading system file 
`/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/PRINTER/nl10.bin'.
Palette: Loading palette 
`/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/PRINTER/nl10.vpl'.
NL10: Printer driver initialized.
Palette: Loading palette 
`/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/PRINTER/1520.vpl'.
Loading system file 
`/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/DRIVES/dos1540-325302+3-01.bin'.
Loading system file 
`/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/DRIVES/dos1541-325302-01+901229-05.bin'.
Loading system file 
`/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/DRIVES/dos1541ii-251968-03.bin'.
Loading system file 
`/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/DRIVES/dos1570-315090-01.bin'.
Loading system file 
`/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/DRIVES/dos1571-310654-05.bin'.
Loading system file 
`/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/DRIVES/dos1581-318045-02.bin'.
DriveROM: Error - 2000 ROM image not found. Hardware-level 2000 emulation is 
not available.
DriveROM: Error - 4000 ROM image not found. Hardware-level 4000 emulation is 
not available.
DriveROM: Error - CMDHD ROM image not found. Hardware-level CMDHD emulation is 
not available.
Loading system file 
`/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/DRIVES/dos1551-318008-01.bin'.
Drive: Finished loading ROM images.
Sound: Available sound devices: pulse alsa dummy fs dump wav voc iff aiff 
soundmovie
using GTK3 backend: OpenGL
chip_name: TED
 screen_size: 384 x 312
 first/lastline: 0 x 0
 gfx_size: 320 x 200
 gfx_position: 32 x 59
 first/last displayed line: 19 x 306
 extra offscreen border left/right: 28 x 228
 screen_display_wh: 0.00 x 0.00
 canvas_physical_wh: 0 x 0
 scalexy: 2 x 2
 sizexy: 1 x 1
 rmode: 1
 aspect ratio: 1.037435
 hstretch: 0
 vstretch: 0
 initializing with width, height: 704 x 574
GLX version: 1.4
Getting matching framebuffer configs
Found 6 matching FB configs.
Error - Failed to obtain an OpenGL 3.2 context, requesting a legacy context

Obtained OpenGL 2.1 context
  Vendor: Intel
Renderer: Mesa Mobile Intel® GM45 Express Chipset (CTG)
 Version: 2.1 Mesa 23.1.4
  Legacy: yes
Direct GLX rendering context obtained
Swap control support. glXSwapIntervalMESA: 1 glXSwapIntervalEXT: 1 
glXSwapIntervalSGI: 1
Created render thread 0
Render thread initialised
Joystick: Linux joystick interface initialization...
Joystick: Warning - Cannot open joystick device `/dev/input/js0'.
Joystick: Warning - Cannot open joystick device `/dev/input/js1'.
Joystick: Warning - Cannot open joystick device `/dev/input/js2'.
Joystick: Warning - Cannot open joystick device `/dev/input/js3'.
Joystick: Warning - Cannot open joystick device `/dev/input/js4'.
Joystick: Warning - Cannot open joystick device `/dev/input/js5'.
Joystick: Warning - Cannot open joystick device `/dev/input/js6'.
Joystick: Warning - Cannot open joystick device `/dev/input/js7'.
Loading keymap 
`/gnu/store/xl99j30yh624c4zzq3wzrkqv1v4zs9lm-vice-3.7.1/share/vice/PLUS4/gtk3_sym.vkm'.
HOTKEYS: Hotkeys: Initializing.
HOTKEYS: Hotkeys: Parsing PLUS4 hotkeys file:
HOTKEYS: Hotkeys: OK.
AUTOSTART: Autodetecting image type of `TED-Vibes-2.d64'.
AUTOSTART: 

bug#65391: People need to report failing builds even though we have ci.guix.gnu.org for that

[Csepp]

Simon Tournier  writes:

> Hi,
>
> On Mon, 11 Sept 2023 at 09:33, Csepp  wrote:
>
>> That is not a package problem but a Guix interface problem.  I have been
>> saying for a while that there needs to be an option to disable all
>> non-trivial local builds by default when you know your machine can't
>> handle them.
>
> IMHO, your proposal is orthogonal with the issue at hand: broken
> packages.  Other said, the issue is: how to deal with the set of
> packages that will not build and we already know it (since weeks,
> months or even years for some).
>
> My workstation can handle all the compilations that are required.  My
> laptop is able offload to it.  The issue about broken packages is not
> about the resources.  It is about burning resources for nothing.
>
> About the issue you are speaking about, we already had discussions in
> this direction -- you are not the only one saying "the fix needs to do
> X" for a while but please keep in mind that "talking does not cook the
> rice". ;-)  Well, maybe you could open a ticket with a concrete
> use-case.
>
> Cheers,
> simon

I was hoping to get some consensus on whether this is actually a
bug/feature that others consider worth tracking, so I kept discussion of
it mostly to guix-devel, but sure, I can make a proper issue for it.

bug#65391: People need to report failing builds even though we have ci.guix.gnu.org for that

[Csepp]

(changing the subject back to the intended one.  I think the fact that
someone replies to an automated acknowledgement email like once a week
says indicates that the emails are not communicating clearly what their
purpose is. anyways, on to the actual issue at hand.)

Simon Tournier  writes:

> Hi,
>
> On Tue, 29 Aug 2023 at 10:45, Maxim Cournoyer  
> wrote:
>
>> It's frustrating for users when a package is missing, but it's also
>> frustrating/inefficient for maintainers to stumble upon broken packages
>> when checking if an upgrade broke dependent packages (it takes time to
>> build them just to find out they fail, and researching they already
>> did), so a balance is needed.
>
> There is nothing worse as an user to have this experience:
>
> guix search foobar
>
> oh cool, foobar is there, let try it,
>
> guix shell foobar
>
> … wait …
> … stuff are building …
> … laptop is burning …
> … wait …
> Bang!
>
> Keeping broken packages is just annoyances.  Contributor are annoyed
> because as said by the paragraph above.  And user are annoyed as
> described just above.
>
> I am in favor to set a policy for removing then.
>
> The question is the way to detect them.  QA can do whatever we want but
> until people are helping Chris because, IMHO, Chris is already enough
> busy to keep stuff running, we probably need to keep our process simple
> enough in order to stay actionable and avoid some vacuum of “coulda,
> shoulda or woulda”.  For what my opinion is worth on that. :-)
>
> Cheers,
> simon

That is not a package problem but a Guix interface problem.  I have been
saying for a while that there needs to be an option to disable all
non-trivial local builds by default when you know your machine can't
handle them.
Alternatively the CI could record some basic resource utilization
information, so users could for example set a limit on RAM.  (Although
this gets tricky for parallel builds.)

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

[Csepp]

Simon Tournier  writes:

> Hi,
>
> On Fri, 08 Sep 2023 at 19:09, Ludovic Courtès  wrote:
>
 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?
>>>
>>> I think we can rely on something like,
>>>
>>> guix shell -C git-minimal -- git gc
>>
>> We’re talking about the implementation of a cache (meant to speed up
>> operations), that would actually fill said cache plus do a whole bunch
>> of expensive operations?  Nah.  :-)
>
> I do not think.  If I understand correctly, we need to run “git gc” at
> some point, therefore git-minimal needs to me around.  The question is
> how and when.
>
> Well, maybe I am missing what the bug is about.  For me, it is about
> running ‘git gc’ for cleaning the Git checkout cache, no?
>
>
> Solution #1.  Add git-minimal as inputs.  It increases the closure and
> the extra load (on average) is about the ratio between the rate of “guix
> pull” and the rate of the git-minimal changes.
>
> Assuming, that people are running “guix pull” once per week and say “git
> gc” is run after 50 pulls.  (These both number are totally arbitrary and
> based on my personal estimate).
>
> Data Service [1] tells:
>
> 2023-07-07 15:45:22 2023-09-08 21:22:08
> 2023-05-11 16:10:48 2023-07-07 14:21:45
> 2023-05-01 16:40:08 2023-05-11 14:36:16
> 2023-04-25 13:34:54 2023-05-01 15:19:55
> 2023-04-25 13:34:54 2023-09-08 21:22:08
> 2023-03-06 17:22:28 2023-04-25 12:27:33
> 2023-01-17 23:49:19 2023-03-06 16:48:43
> 2022-11-08 13:06:42 2023-01-17 15:11:47
> 2022-10-08 05:14:46 2022-11-08 09:56:31
> 2022-09-06 15:00:08 2022-10-08 04:15:43
> 2022-08-13 22:02:31 2022-09-06 12:58:52
> …
>
> It means that an user will download ~10 times git-minimal for nothing.
>
>
> Solution #2.  The one I am proposing. :-)  Download git-minimal only
> when Guix needs it for running “git gc”.  Yeah, there is probably a
> small overload with some operations.  But, I bet this overload is much
> smaller than the one of solution #1.
>
> Well, it depends on the number of times people are updating the cache vs
> the rate of change of git-minimal.
>
> For sure, if one updates 100 times per week the cache, having
> git-minimal as inputs is far better.  But I do not think that the
> regular usage on average. :-)
>
> That’s why I am proposing to have an option for turning off this “git
> gc“ operation.
>
> Well, we have lived since years without running ‘git gc’ so running it
> once per year on average is probably enough to keep the cache size
> reasonable.  And git-minimal is changing every month.
>
>
> Maybe, there is some solution #3. ;-)
>
> Cheers,
> simon
>
>
> 1: 
> https://data.guix.gnu.org/repository/1/branch/master/package/git-minimal/output-history

Please don't create another situation like with guix system roll-back,
where a crucial sysadmin operation doesn't work without network access.
Or at least make it configurable, so things that are likely to be needed
for future operations are pre-fetched.

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

[Csepp]

Ludovic Courtès  writes:

> Hello!
>
> Josselin Poiret  skribis:
>
>> 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.
>
> [...]
>
>> 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.
>
> I cannot imagine a viable implementation of things like ‘commit-closure’
> and ‘commit-relation’ from (guix git) done by shelling out to ‘git’.
> I’m quite confident this would be slow and brittle.
>
> It looks like there’s no option other than carrying the two
> implementations.
>
> ~~~
>
> Years ago, Andy Wingo sketched a plan for GNU hackers to implement Git
> in pure Scheme.  That was on April 1st though, so people mistakenly
> assumed it was a joke and the project was never carried out.
>
> I digress, but I wonder: is there not even a viable Haskell or OCaml
> implementation of Git?
>
> Thanks,
> Ludo’.

For sake of completeness:
There is an alternative implentation in C for Plan 9 that I've used and
is now mature enough that the 9front project switched to it from
Mercurial.
It might be possible to compile it with the plan9port compiler wrapper.

There is also a Git implementation in OCaml that some MirageOS
unikernels use to serve static content from a git repository.
Also the Irmin "database" is based on git and is written in OCaml.

bug#65808: (accidentally) removing and re-adding user not handled

[Csepp]

Sorry, kind of in a hurry, this might be rushed.
Short version: I accidentally commented out my user, reconfigured,
realized my mistake, rolled back (logging in was tricky, not sure what
made it work), had to add a password again with passwd, got new UID, had
to chown -R my $HOME, tried to guix pull --roll-back, but had to chown
my /var/run/guix/per-user thing too.

bug#65765:

[Csepp]

Sharlatan Hellseher  writes:

> Hi,
>
> May you provide the way how to reproduce it?
>
>> guix time-machine --no-channel-files 
>> --commit=6113e0529d61df7425f64e30a6bf77f7cfdfe5a5 -- build celluloid
>> /gnu/store/dps6ra33zfgpga7wig085p5k3bwdxqz2-celluloid-0.25

Hmm, can't reproduce it in a pure shell.  Might be related to one of my
environment variables.  Although it kind of doesn't matter because
thanks to GTK it might not even run on my machine.
https://github.com/celluloid-player/celluloid/issues/251#issuecomment-278534566

bug#65765: Celluloid is broken

[Csepp]

Guix commit: d6966b8 (5 days old)
Trying to run celluloid results in this error:
celluloid: ../stream/stream.c:416: stream_create_with_args: Assertion 
`args->url' failed.

both celluloid and mpv are up to date according to guix refresh

It doesn't matter what arguments celluloid gets, the result always seems
to be the same.

I thought it had tests turned off, but no, it looks like its testsuite
is just very incomplete, because it definitely should have caught this.

bug#65572: [PATCH v3] doc: Describe black screen issue when booting the installer.

[Csepp]

"pelzflorian (Florian Pelz)"  writes:

> Pushed as 2890114a708e3a54a14ceb762f0726b013ffdc85.
>
> Csepp  writes:
>> There was a thread about having a dedicated "safe video" option in the
>> GRUB menu, like a lot of distros do.  I still think we should do that
>
> Yes, I agree.  It would need a way to make a custom GRUB menu entry that
> refers to a Guix System generation, and adding that feature is
> complicated because it best worked for other non-GRUB bootloaders too.
> If it were added, “safe video” could be described in the same place.
>
> Regards,
> Florian

I think we should just handle a (nested?) (a-)list of operating-system
objects.  It would be useful for a lot of other use cases too.  I for
one would like to have the option to boot my Thinkpad with libre
software by default but have the ability to use drivers from The
Forbidden Channel when I bring it to campus and need wifi.
Or to be able to choose a noPAE kernel on old machines.  Or have both an
LTS kernel and the latest release, and maybe even a nightly build for
testing.

bug#65665: package-mapping with #:deep? #t doesn't get all the implicit inputs

[Csepp]

Ulf Herrman  writes:

> [[PGP Signed Part:Undecided]]
> #:deep? #t currently works by interposing a dummy build system that
> lowers the package to a bag using the original build system, then
> applies the supplied transformation to all of the bag's inputs, then
> returns a new bag with the new inputs.
>
> The problem with this approach is that it doesn't affect the bag
> arguments.  This means that packages passed in as arguments may still
> end up being used without being transformed.  Worse still, packages
> *not* passed in as arguments may end up being used *unless one is
> explicitly passed in as an argument*, as is the case with
> qt-build-system's #:qtbase argument.
>
> In short, the current approach of having the build-system lower
> procedure leave the arguments mostly unchanged and letting the
> bag->derivation procedure (the "bag builder") fill in lots of defaults
> means that there are implicit inputs that cannot be touched at the
> package level without adding special logic for every single build system
> that does something like this.
>
> I propose that we have the build system lower procedure (that is, the
> one that converts from package to bag) completely fill in the argument
> list with all defaults, and we modify build-system-with-package-mapping
> to transform all arguments that look like a package or a list of
> packages (or maybe even a tree containing packages).
>
> Many large-scale package transformations have their purpose defeated if
> even a single package slips through and has to be built or downloaded
> separately (e.g. "I wanted to use a more minimal version of P, and now I
> have both the original version of P *and* a more minimal version of P
> *and* a duplicate copy of a large portion of the package graph...").  In
> fact, in some situations, this could cause exponential growth of the
> number of packages, e.g. a transformation is applied to qtbase and its
> dependencies, but not to the implicit version and its dependencies, so
> now all the dependencies of qtbase are duplicated, and if this happens
> again at a higher level with something that depends on a package with
> qt-build-system, now there are four duplicate subgraphs, and so on.
>
> What do you think?
>
> - Ulf
>
> [[End of PGP Signed Part]]

Sounds like a good idea to me.

bug#65572: [PATCH v3] doc: Describe black screen issue when booting the installer.

[Csepp]

Florian Pelz  writes:

> With suggestions by Iku-Tulo Vilutar .
> Fixes .
>
> * doc/guix.texi (System Installation): Add suggestion when
> booting the installer fails with a black screen.
> ---
> changes:
>  - tell users to wait 10 minutes, not 2
>  - don't suggest video=uvesafb which is without effect
>  - more positive wording (don't give up just yet)
>
>  doc/guix.texi | 10 ++
>  1 file changed, 10 insertions(+)
>

There was a thread about having a dedicated "safe video" option in the
GRUB menu, like a lot of distros do.  I still think we should do that as
well, because having to edit the kernel boot arguments is much more
difficult, and because the user wouldn't have to go consult the manual
to know that there is such an option, it would be right in front of
them.
But of course documenting the workaround like this is the next best
thing.

bug#65391: People need to report failing builds even though we have ci.guix.gnu.org for that

[Csepp]

Maxime Devos  writes:

> [[PGP Signed Part:Undecided]]
> Op 23-08-2023 om 01:45 schreef Csepp:
>> I tried signing up to the CI mailing list and it immediately became
>> overwhelming.
>
> If the CI list was split in ‘broken’ and ‘fixed’, such that you have
> the option to only subscribe to ‘broken’, would that help?  A large
> fraction of messages is for fixed packages, which do not need to be
> acted upon.

Yup, that would be an improvement.  Or some way to group messages by
package.

>> One possible improvement I have been thinking about is making it easy
>> for users to filter CI output to the packages in their profile closure,
>> so for example they would get advance notice of any broken packages
>> *before* attempting to install them.
>
> I assume you meant s/install/update.
>
> How is this an improvement?  I mean, how does this make
>
> ‘People need to report failing builds even though we have
> ci.guix.gnu.org for that.’
>
> less true?
>
> Best regards,
> Maxime Devos.
>
> [2. OpenPGP public key --- application/pgp-keys; 
> OpenPGP_0x49E3EE22191725EE.asc]...
>
> [[End of PGP Signed Part]]

A user is more likely to be able and motivated to fix a package that
they are using.  Getting notifications as a stream is a recipe for alert
fatigue.  There needs to be a way to at the very least move actionable
alert to the top of the list and to deduplicate alerts.
TLDR: alert fatigue is bad and it should not be the casual contributor's
job to fight it on their own.  If its filtering and grouping is expected
to be done on the client side then there should be guides for setting
those filters up.
Personally, it already takes enough time for me to read the bug
discussions.

bug#65391: People need to report failing builds even though we have ci.guix.gnu.org for that

[Csepp]

Maxime Devos  writes:

> [[PGP Signed Part:Undecided]]
>
>
> Op 23-08-2023 om 01:45 schreef Csepp:
>> Also the CI UI could use some improvements.  I'm pretty sure I've
>> mentioned this before, but there is no easy way to find out which inputs
>> I need to fix to make a dependency failure disappear.  I think everyone
>> has better things to do than perform a linear search by hand.
>
> Go to the package of a failed build, e.g.
> <https://ci.guix.gnu.org/build/1840209/details>. The dependencies you
> need to fix are marked with a red cross or a red danger triangle. In
> case of a danger triangle, you need to look at the dependencies of the
> dependency, which you can visit via the hyperlink.
>
> I don't see any linear search here.
>
> Best regards,
> Maxime Devos.
>
> [2. OpenPGP public key --- application/pgp-keys; 
> OpenPGP_0x49E3EE22191725EE.asc]...
>
> [[End of PGP Signed Part]]

That is precisely what the linear search algorithm is.  I should not
have to look through the dependency tree to figure out if two package
failures have the same cause, or to know how many (possibly indirect)
dependencies of a package are failing.
As an example, pandoc often fails to build on i686, but when you look at
the CI page, you see that it was caused by several of its inputs
failing, all due to some of *their* dependencies.
Now, you could dig down on one branch of the dependency DAG and find one
failing package, but that doesn't *actually* answer the question: "what
packages do I need to fix to enable this one?", because it could have
multiple failing inputs instead of just one.  The only way to tell is to
look at each page, that means having to visually find each failing input
on the page, wait for their CI pages to load, and repeat the whole
process.
If your browser is not particularly fast or you aren't so quick at
navigating a webpage, this can take a while.
But for the CI server, generating this information would take less than
a second.
Maybe some people value their time so little that they are fine with
doing this the manual way, but personally I have better things to do.

bug#65391: People need to report failing builds even though we have ci.guix.gnu.org for that

[Csepp]

Simon Tournier  writes:

> Hi,
>
> On Wed, 23 Aug 2023 at 01:45, Csepp  wrote:
>
>> One possible improvement I have been thinking about is making it easy
>> for users to filter CI output to the packages in their profile closure,
>> so for example they would get advance notice of any broken packages
>> *before* attempting to install them.
>> Teams could also have their own filters.
>
> Maybe I am missing what you would like, from my understanding, that’s
> already possible using time-machine and weather.  For example,
>
>guix time-machine -- weather -m manifest.scm
>
> allow to know the status of the last commit.  What is missing is a clear
> return code for chaining.  For instance, see this proposal:
>
> subject: guix weather exit status?
> from: Leo Famulari 
> date: Thu, 08 Jul 2021 16:35:03 -0400
> message-id: id:yodhd7ffmovkj...@jasmine.lan
> https://yhetil.org/guix/yodhd7ffmovkj...@jasmine.lan
>
> However, I agree that the next step (find the log of the broken package)
> for teams is a bit convoluted.
>
> Cheers,
> simon

Thanks, I was not aware of this solution, but it also kind of isn't a
complete solution.
A pull is a quite costly operation, why should I have to perform one on
my netbook when what I'm trying to find out is which commit is actually
worth pulling to?

bug#65460: ghc/ghci are broken

[Csepp]

Jonas via Bug reports for GNU Guix  writes:

> Thanks! Adding gcc-toolchain to the profile fixed it, but shouldn't this 
> be automatically brought in by `guix install ghc`? This does still feels 
> like a bug to me, shouldn't gcc-toolchain be a part of ghcs native-inputs?
>
> sanoj@deimos ~/builds/hs-hello$ guix shell --container ghc -- ghc hello.hs
> Linking hello ...
>
> : error:
>      Warning: Couldn't figure out C compiler information!
>   Make sure you're using GNU gcc, or clang
> ghc: could not execute: gcc
>
> Den 8/23/23 07:14, skrev (:
>> Jonas via Bug reports for GNU Guix  writes:
>>> And compiling a hello-world program with ghc gives me:
>>>
>>> [1 of 1] Compiling Main ( hello.hs, hello.o )
>>>
>>> : error:
>>>       Warning: Couldn't figure out C compiler information!
>>>    Make sure you're using GNU gcc, or clang
>> At the risk of stating an obvious thing that you've probably already
>> tried; is `gcc-toolchain` available in the environment?
>>
>> -- (

I assume GHC can work with other toolchains, like Clang, so it's better
to be explicit about what you want to use.

bug#65391: People need to report failing builds even though we have ci.guix.gnu.org for that

[Csepp]

Maxime Devos  writes:

> [[PGP Signed Part:Undecided]]
> For example, naev used to work just fine, yet apparently it doesn't
> anymore: https://issues.guix.gnu.org/65390.
>
> Given that Guix has ci.guix.gnu.org, I would expect such new problems
> to be detected and resolved early, and it was detected by
> ci.guix.gnu.org, yet going by issues.guix.gnu.org it was never even
> investigated.
>
> (Yes, there is a delay, but that doesn't matter at all, as there's
> this dashboard .)
>
> Do people really need to report 33% of all jobs
> (https://ci.guix.gnu.org/eval/668365/dashboard) before those failures
> are taken seriously, instead of the ‘there don't seem to be that much
> more build failures from the core-updates/... merge, let's solve them
> later (i.e., never)’ that seems to be  status quo?
>
> Best regards,
> Maxime Devos
>
> [2. OpenPGP public key --- application/pgp-keys; 
> OpenPGP_0x49E3EE22191725EE.asc]...
>
> [[End of PGP Signed Part]]

I tried signing up to the CI mailing list and it immediately became
overwhelming.
Also the CI UI could use some improvements.  I'm pretty sure I've
mentioned this before, but there is no easy way to find out which inputs
I need to fix to make a dependency failure disappear.  I think everyone
has better things to do than perform a linear search by hand.
So I rely on my own installations for detecting errors, that way I at
least know that I don't get flooded with notifications for packages I
know nothing about.
One possible improvement I have been thinking about is making it easy
for users to filter CI output to the packages in their profile closure,
so for example they would get advance notice of any broken packages
*before* attempting to install them.
Teams could also have their own filters.

bug#65306: [shepherd] ntpd throws shepherd out of the loop

[Csepp]

Liliana Marie Prikler  writes:

> Hi Guix,
>
> I have a laptop that's a little stuck in the past… more accurately
> January of 2020 thanks to what I believe to be an empty CMOS battery. 
> As of recently (maybe it dates back longer, but I first experienced it
> two weeks ago and just now got to debugging it a little), Shepherd gets
> stuck at 100% CPU usage "early" on first boot.  I can prevent this
> issue by getting the system time "close enough" to the actual time
> before the NTP sync, but see the first sentence.  Not having a network
> connection also works, but that's somewhat unpractical.  Also, the high
> CPU usage still occurs if a sync is done later.  I have yet to
> encounter the bug post hibernation, but I also wish not to.  There
> doesn't appear to be anything particular interesting in the logs
> either.
>
> Cheers

This sounds like an issue with slow incremental system time updates,
although I don't understand why that would cause Shepherd to hang, but
maybe the NTP service is configured to only report itself as initialized
once it has finished synchronizing, which defeats the point of
incremental updating.
There is probably a config setting to tell ntpd to perform the update in
a single step, at least I know chrony has one.

ps.: don't wait until the battery starts leaking to replace it

bug#64981: GTK4 applications broken (missing libGLESv2)

[Csepp]

Liliana Marie Prikler  writes:

> tags 64981 moreinfo
> thanks
>
> Am Dienstag, dem 01.08.2023 um 00:06 +0200 schrieb Csepp:
>> for example:
>> $ transmission-gtk
>> Couldn't open libGLESv2.so.2: libGLESv2.so.2
>> 
>> I get the same error with Tuba.  It likely affects other
>> applications.
> I assume you are not using the gnome-desktop-service, are you?

Yup, I'm using Sway without a display manager.  Gnome was a memory hog.

> Neither transmission-gtk nor GTK4 appears to actually link against
> libGLES, so there's probably something arcane going on already.  Have
> you tried the usual debugging tools (GDB, strace)?
>
> Cheers 

Not yet, but I did now:

```
$ strace -e %file transmission-gtk |& grep libGL
:(
openat(AT_FDCWD, 
"/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/libGLX.so.1", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, 
"/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/libGLX.so.1", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, 
"/gnu/store/zisvdry6856i6z4iai62ff6l3anbdld8-mesa-23.0.3/lib/libGL.so.1", 
O_RDONLY|O_CLOEXEC) = 29
openat(AT_FDCWD, 
"/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/libGLESv2.so.2", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, 
"/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/libGLESv2.so.2", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
Couldn't open libGLESv2.so.2: libGLESv2.so.2: cannot open shared object file: 
No such file or directory
```

So it's not looking for it in Mesa, which is odd, isn't that where it's
supposed to be?  According to guix locate libGLESv2.so.2, it should be
in one of the Mesa packages.

Thanks for helping me look into this!  Gonna look a bit more into what's
going on...

bug#64981: GTK4 applications broken (missing libGLESv2)

[Csepp]

for example:
$ transmission-gtk
Couldn't open libGLESv2.so.2: libGLESv2.so.2

I get the same error with Tuba.  It likely affects other applications.

Guix commit: 182be30
System: x86_64

bug#64979: ghc-exceptions broken on i686 leads to lots of broken packages

[Csepp]

This came to my attention when trying to reconfigure my netbook, which
uses earlyoom, which requires Pandoc to build its docs.

http://ci.guix.gnu.org/build/1610832/details
http://ci.guix.gnu.org/build/1610832/log/raw

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

[Csepp]

Csepp  writes:

> Josselin Poiret  writes:
>
>> [[PGP Signed Part:Undecided]]
>> 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,
>
> I did, I think I already wrote that it wasn't coming from there, but
> I'll check again when I next try it.

This is still happening.  Couldn't figure out a decent way to transfer
my system with btrfs send.
I checked the generated bootloader installer script that gets run, it
seems to refer to the correct device, but somehow the UUID of the booted
partition still gets accessed.
I guess I'll have to strace it.

bug#64775: /run should be cleaned on boot

[Csepp]

Vagrant Cascadian  writes:

> [[PGP Signed Part:Undecided]]
> So, if there are files sitting around in /run, they do not get cleaned
> up unless it is something guix is already aware of
> (e.g. /run/setuid-programs).
>
> I noticed this when experimenting with:
>
>   https://issues.guix.gnu.org/61462
>   Add support for file capabilities(7)
>
> Even after a reboot, the leftovers from that experimental patchset were
> still present in /run...
>
> While I know that Guix does not really follow the FHS in most respects,
> maybe the intention of /run defined there should still be respected?
>
>   https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s15.html
>
>   3.15. /run : Run-time variable data
>   3.15.1. Purpose
>
>   This directory contains system information data describing the system
>   since it was booted. Files under this directory must be cleared
>   (removed or truncated as appropriate) at the beginning of the boot
>   process.
>   ...
>
> Many distros implement this by having /run on a tmpfs, but making sure
> to clean up /run at boot seems like a reasonable thing to do at the very
> least.
>
> I am not sure if it makes sense to do housecleaning of /run from guix
> system reconfigure ... as there may be legitimate uses for other
> processes to write there.
>
>
> live well,
>   vagrant
>
> [[End of PGP Signed Part]]

I vote for TMPFS, since that would also reduce flash wear.
Honestly I don't get why it's not already using TMPFS.

bug#64360: error: ghc-onetuple: unbound variable

[Csepp]

Ludovic Courtès  writes:

> Hi,
>
> Csepp  skribis:
>
>> Generation 22Jun 30 2023 01:27:38
>>   guix 63660f0
>> repository URL: https://git.savannah.gnu.org/git/guix.git
>> commit: 63660f0febb4aa0d5260791c82dfde15c0df4c79
>
> So is this the one for which ‘guix shell yt-dlp’ triggered the bug you
> initially reported?
>
> Ludo’.

Yup!

bug#64360: error: ghc-onetuple: unbound variable

[Csepp]

Csepp  writes:

> Ludovic Courtès  writes:
>
>> Hi,
>> n
>> Csepp  skribis:
>>
>>> Ludovic Courtès  writes:
>>>
>>>> Hi,
>>>>
>>>> Csepp  skribis:
>>>>
>>>>> I **finally** managed to finish a guix pull on my netbook by offloading
>>>>> it to my desktop machine, and I tried to build the latest yt-dlp, this
>>>>> is the error I got:
>>>>>
>>>>> ```
>>>>> $ guix shell yt-dlp
>>
>> [...]
>>
>>>>> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
>>>>> error: ghc-onetuple: unbound variable
>>>>> ```
>>>>
>>>> Could you share the output of ‘guix describe’?
>>
>> [...]
>>
>>> I'm not on that machine right now, but this is the guix time-machine
>>> invocation that I tried to reproduce it with:
>>>
>>> guix time-machine --system=i686-linux \
>>> --commit=e499cb2c12d7f1c6d2f004364c9cc7bdb7e38cd5 \
>>> --channels=$HOME/channels.scm -- time-machine --commit=63660f0febb \
>>> --channels=$HOME/channels.scm --system=i686-linux -- repl
>>
>> That’s quite different from the ‘guix shell yt-dlp’ we started with
>> though.  :-)
>>
>> Also, it very much depends on what ‘channels.scm’ contains.  ‘guix
>> time-machine’ does not support ‘--system’, but on x86_64-linux I get:
>>
>> --8<---cut here---start->8---
>> $ guix time-machine --commit=63660f0febb -- shell yt-dlp -- yt-dlp --version
>> 2023.06.22
>> --8<---cut here---end--->8---
>>
>> I ran out of disk space (and out of time :-)) while running:
>>
>>   guix time-machine --commit=63660f0febb -- shell \
>> --rebuild-cache -s i686-linux yt-dlp -- yt-dlp --version
>>
>> Anyway, it could be a problem with a channel other than ‘guix’, we can’t
>> tell so far.  Please let us know when you have the output of ‘guix
>> describe’ on that machine.
>>
>> Ludo’.
>
> I have no channels configured other than the default one using
> channel-with-substitutes-available, because it's a netbook we're talking
> about.
> On the x86_64 machine I was not using channel-with-substitues-available.

Here is the output of guix pull --list-generations.


generations.log
Description: all generations

bug#64360: error: ghc-onetuple: unbound variable

[Csepp]

Ludovic Courtès  writes:

> Hi,
> n
> Csepp  skribis:
>
>> Ludovic Courtès  writes:
>>
>>> Hi,
>>>
>>> Csepp  skribis:
>>>
>>>> I **finally** managed to finish a guix pull on my netbook by offloading
>>>> it to my desktop machine, and I tried to build the latest yt-dlp, this
>>>> is the error I got:
>>>>
>>>> ```
>>>> $ guix shell yt-dlp
>
> [...]
>
>>>> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
>>>> error: ghc-onetuple: unbound variable
>>>> ```
>>>
>>> Could you share the output of ‘guix describe’?
>
> [...]
>
>> I'm not on that machine right now, but this is the guix time-machine
>> invocation that I tried to reproduce it with:
>>
>> guix time-machine --system=i686-linux \
>> --commit=e499cb2c12d7f1c6d2f004364c9cc7bdb7e38cd5 \
>> --channels=$HOME/channels.scm -- time-machine --commit=63660f0febb \
>> --channels=$HOME/channels.scm --system=i686-linux -- repl
>
> That’s quite different from the ‘guix shell yt-dlp’ we started with
> though.  :-)
>
> Also, it very much depends on what ‘channels.scm’ contains.  ‘guix
> time-machine’ does not support ‘--system’, but on x86_64-linux I get:
>
> --8<---cut here---start->8---
> $ guix time-machine --commit=63660f0febb -- shell yt-dlp -- yt-dlp --version
> 2023.06.22
> --8<---cut here---end--->8---
>
> I ran out of disk space (and out of time :-)) while running:
>
>   guix time-machine --commit=63660f0febb -- shell \
> --rebuild-cache -s i686-linux yt-dlp -- yt-dlp --version
>
> Anyway, it could be a problem with a channel other than ‘guix’, we can’t
> tell so far.  Please let us know when you have the output of ‘guix
> describe’ on that machine.
>
> Ludo’.

I have no channels configured other than the default one using
channel-with-substitutes-available, because it's a netbook we're talking
about.
On the x86_64 machine I was not using channel-with-substitues-available.

bug#64360: error: ghc-onetuple: unbound variable

[Csepp]

Ludovic Courtès  writes:

> Hi,
>
> Csepp  skribis:
>
>> I **finally** managed to finish a guix pull on my netbook by offloading
>> it to my desktop machine, and I tried to build the latest yt-dlp, this
>> is the error I got:
>>
>> ```
>> $ guix shell yt-dlp
>> Backtrace:
>> In srfi/srfi-1.scm:
>>586:17 19 (map1 (#< name: "yt-dlp" version: "202…>))
>> In guix/profiles.scm:
>>   1932:19 18 (_ _)
>> In guix/packages.scm:
>>   1371:17 17 (supported-package? # …)
>> In guix/memoization.scm:
>> 101:0 16 (_ # # …)
>> In guix/packages.scm:
>>   1349:39 15 (_)
>>   1611:16 14 (package->bag _ _ _ #:graft? _)
>>   1715:47 13 (thunk)
>> In gnu/packages/video.scm:
>>   2615:11 12 (native-inputs #)
>> In guix/packages.scm:
>>   1371:17 11 (supported-package? # …)
>> In guix/memoization.scm:
>> 101:0 10 (_ # # …)
>> In guix/packages.scm:
>>   1349:39  9 (_)
>>   1611:16  8 (package->bag _ _ _ #:graft? _)
>>   1712:48  7 (thunk)
>> In gnu/packages/haskell-xyz.scm:
>>   9121:35  6 (inputs #)
>> In guix/packages.scm:
>>   1424:32  5 (package-closure _ #:system _)
>>   1611:16  4 (package->bag _ _ _ #:graft? _)
>>   1712:48  3 (thunk)
>> In gnu/packages/haskell-web.scm:
>>943:18  2 (inputs #)
>> In ice-9/boot-9.scm:
>>   1685:16  1 (raise-exception _ #:continuable? _)
>>   1685:16  0 (raise-exception _ #:continuable? _)
>>
>> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
>> error: ghc-onetuple: unbound variable
>> ```
>
> Could you share the output of ‘guix describe’?
>
> I can’t reproduce it here:
>
> --8<---cut here---start->8---
> $ guix describe
> Generation 268  Jun 26 2023 00:05:27(current)
>   guix 269cfe3
> repository URL: https://git.savannah.gnu.org/git/guix.git
> branch: master
> commit: 269cfe341f242c2b5f37774cb9b1e17d9aa68e2c
>   guile 896960d
> repository URL: https://git.savannah.gnu.org/git/guile.git
> branch: main
> commit: 896960dadeba7770ebbad97514ec6c4d7f18212d
>   shepherd d5ed516
> repository URL: https://git.savannah.gnu.org/git/shepherd.git
> branch: master
> commit: d5ed516e736ce473902cc86b5cf4f61f27ebb642
> $ guix shell yt-dlp -- yt-dlp --version
> 2023.06.22
> --8<---cut here---end--->8---
>
> TIA,
> Ludo’.

I'm not on that machine right now, but this is the guix time-machine
invocation that I tried to reproduce it with:

guix time-machine --system=i686-linux \
--commit=e499cb2c12d7f1c6d2f004364c9cc7bdb7e38cd5 \
--channels=$HOME/channels.scm -- time-machine --commit=63660f0febb \
--channels=$HOME/channels.scm --system=i686-linux -- repl

So e499cb2c12d7f1c6d2f004364c9cc7bdb7e38cd5 is the commit I was pulling
from and 63660f0febb is the one I was pulling.

Couldn't reproduce it on my x86_64 machine.

I tried clearing my Guile caches on the i686 machine but that didn't
change anything.
It also happens with a lot of other variables, so much so that guix repl
is also broken.

I have since reconfigured and rebooted the machine too, just to make
sure it wasn't a daemon issue, and that didn't help either.

bug#64350: python-wand-0.6.11 fails in check phase

[Csepp]

Thorsten Wilms  writes:

> Hi, python-wand 0.6.11 fails to install. I found this in the log:
>
> phase `add-install-to-path' succeeded after 0.0 seconds
> starting phase `wrap'
> find-files: 
> /gnu/store/8y1vnzs66bnfgiaxdxhmc7wd9ggkcpy6-python-wand-0.6.11/bin: No such 
> file or directory
> find-files: 
> /gnu/store/8y1vnzs66bnfgiaxdxhmc7wd9ggkcpy6-python-wand-0.6.11/sbin: No such 
> file or directory
> phase `wrap' succeeded after 0.0 seconds
> starting phase `check'
> error: in phase 'check': uncaught exception:
> unbound-variable #f "Unbound variable: ~S" (tests?) #f 
> phase `check' failed after 0.0 seconds
> Backtrace:
>   10 (primitive-load "/gnu/store/m7pmcj4czzw4pc40s6sfyahq8q9…")
> In guix/build/gnu-build-system.scm:
> 908:2  9 (gnu-build #:source _ #:outputs _ #:inputs _ #:phases . #)
> In ice-9/boot-9.scm:
>   1752:10  8 (with-exception-handler _ _ #:unwind? _ # _)
> In srfi/srfi-1.scm:
> 634:9  7 (for-each # …)
> In ice-9/boot-9.scm:
>   1752:10  6 (with-exception-handler _ _ #:unwind? _ # _)
> In guix/build/gnu-build-system.scm:
>929:23  5 (_)
> In ice-9/eval.scm:
>279:15  4 (_ #(#(#) (# # …)))
>223:20  3 (proc #(#(#) (# …)))
> In unknown file:
>2 (%resolve-variable (7 . tests?) #)
> In ice-9/boot-9.scm:
>   1685:16  1 (raise-exception _ #:continuable? _)
>   1685:16  0 (raise-exception _ #:continuable? _)
>
> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> Unbound variable: tests?

Sorry, don't have the time for a proper patch.
Replace this:
lambda _
with this
lambda* (#:keys tests? #:allow-other-keys)

Feel free to send it as a patch.

bug#64360: error: ghc-onetuple: unbound variable

[Csepp]

I **finally** managed to finish a guix pull on my netbook by offloading
it to my desktop machine, and I tried to build the latest yt-dlp, this
is the error I got:

```
$ guix shell yt-dlp
Backtrace:
In srfi/srfi-1.scm:
   586:17 19 (map1 (#< name: "yt-dlp" version: "202…>))
In guix/profiles.scm:
  1932:19 18 (_ _)
In guix/packages.scm:
  1371:17 17 (supported-package? # …)
In guix/memoization.scm:
101:0 16 (_ # # …)
In guix/packages.scm:
  1349:39 15 (_)
  1611:16 14 (package->bag _ _ _ #:graft? _)
  1715:47 13 (thunk)
In gnu/packages/video.scm:
  2615:11 12 (native-inputs #)
In guix/packages.scm:
  1371:17 11 (supported-package? # …)
In guix/memoization.scm:
101:0 10 (_ # # …)
In guix/packages.scm:
  1349:39  9 (_)
  1611:16  8 (package->bag _ _ _ #:graft? _)
  1712:48  7 (thunk)
In gnu/packages/haskell-xyz.scm:
  9121:35  6 (inputs #)
In guix/packages.scm:
  1424:32  5 (package-closure _ #:system _)
  1611:16  4 (package->bag _ _ _ #:graft? _)
  1712:48  3 (thunk)
In gnu/packages/haskell-web.scm:
   943:18  2 (inputs #)
In ice-9/boot-9.scm:
  1685:16  1 (raise-exception _ #:continuable? _)
  1685:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
error: ghc-onetuple: unbound variable
```

Running guix search ghc-onetuple indeed does not turn anything up.
guix search ghc-aeson results in the same error halfway through
outputting the description for ghc-aeson.

I guess someone didn't run make before they pushed their changes?

bug#54944: guix pull: computing Guix derivation takes forever

[Csepp]

akib via  writes:

> I've just installed Guix on a partition of my new HDD.  After the
> installation I logged in to my user account on a Linux console and
> executed 'guix pull'.  After that it pulled the repository and
> computed Guix derivation, but stuck while updating substitutes.  So I
> thought something is wrong and restarted the command.  Now the pull
> operation always stucks while computing Guix derivation.  There is no
> sign of activity according to top.

Is this maybe related to the CC'd bug?
There the freeze happens later, during the building phase for
packages-base, but it seems like the symtoms are the same.
Does this happen every time you try?
Could you get a backtrace with GDB?
I think the incantation was:
set logging on
thread apply all backtrace
quit

And then the output should be gdb.txt.

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

[Csepp]

John Kehayias  writes:

> Dear Csepp,
>
> On Thu, Jun 22, 2023 at 12:00 AM, Csepp wrote:
>
>>
>> So, I built Netsurf with --with-latest=harfbuzz, which also affected
>> GTK+ and a bunch of other packages along the way, and it worked on my
>> first attempt, just needed a stronger machine.
>> I copied over the resulting Netsurf to my laptop and have been using it
>> all day today, it seems to have shooed that bug away.
>> (Don't squash bugs, bugs are good for the ecosystem. They are only a
>> problem when they get inside your mainframe and cause a short. UwU)
>> BTW there was no log when it caused my system to hang.  I had to reboot
>> it with sysrq.  Probably a kernel bug?
>>
>> So it looks like Harfbuzz can be updated without any problem.
>
> Great, that's good to hear and a nontrivial test too! I'll await
> comments on this mesa+friends update branch and plan on including the
> harfbuzz update there. Stay tuned...
>
> John

Well, now the bug is back somehow???  I haven't updated anything since
then.  Didn't change fonts either.
Still happens in a Harfbuzz call.

bug#54944: guix pull hangs in guix-packages-base.drv even with offloading

[Csepp]

Csepp  writes:

> Csepp  writes:
>
>> Csepp  writes:
>>
>>> Maxim Cournoyer  writes:
>>>
>>>> Hi!
>>>>
>>>> raingloom  writes:
>>>>
>>>>> It's been at 67% on guix-packages-base for at least an hour now. The
>>>>> system itself is responsive and with the swap I gave it, it has more
>>>>> than enough memory. Htop shows three guile processes at the top of the
>>>>> list when sorted by CPU%, their states are S, D, D.
>>>>> Both CPUs are practically idling.
>>>>> This looks like some kind of lockup to me.
>>>>>
>>>>> Fresh install based on bare-bones example on a 32 bit netbook, but the
>>>>> install image used is the latest tagged version, since apparently there
>>>>> is no 32 bit option for edge.
>>>>>
>>>>> I also tried pulling using channel-with-substitutes, since I'm not too
>>>>> keen on locally building everything on such an old machine. Although
>>>>> Guix itself should frankly not take this long to build if we want to be
>>>>> competitive with other distros. Anyways, pulling with that in
>>>>> channels.scm gives a cert related error, so that's great, means old
>>>>> images can't easily be used for installation.
>>>>
>>>> Have you been able to reproduce this?  If so, could you share the commit
>>>> you are starting from and the CPU architecture, so that we may hopefully
>>>> reproduce too?
>>>>
>>>> Thanks,
>>>>
>>>> Maxim
>>>
>>> CPU architecture is x86, commit it happened on last time is 347733b.
>>> Other possibly relevant factors:
>>> * spinning rust storage
>>> * 1GB RAM
>>> * encrypted BTRFS root
>>> * 4GB (encrypted) swap
>>> * 128MB zswap
>>>
>>> The last was not there when I originally submitted the bug.
>>>
>>> The swap is relevant because if it's a timing issue it's very possible
>>> some part of the code assumes reads are almost instant, which is not
>>> true with swap, and delaying a read might be exposing a race condition.
>>
>> Happening again.
>> pulled to: 8320c0c
>> pulled from: 4501a50
>>
>> Same system.
>>
>> The system version is from november of last year due, because trying to
>> upgrade takes so damn long and often gets stuck on some package with no
>> substitute.
>> So... the situation is not great...
>
> The process status says sleep so it's probably hanging in a syscall?
> Maybe a kernel bug?

Happening again with offloading.
This is getting really annoying.
Offload machine is completely idle, there is a process Guile for
guix-packages-base-builder running on it, its in sleeping status.  Ran
for 17 minutes, now the time is not increasing.
I'm attaching a GDB backtrace of all the threads.

Thread 9 (Thread 0xe4affac0 (LWP 878) "guile"):
#0  0xf7fc6579 in __kernel_vsyscall ()
#1  0xf794685e in __lll_lock_wait () from 
target:/gnu/store/0hr9jpczkcgpgqkhf4q4868xd57h5a62-glibc-2.35/lib/libc.so.6
#2  0xf794d11a in pthread_mutex_lock@@GLIBC_2.0 () from 
target:/gnu/store/0hr9jpczkcgpgqkhf4q4868xd57h5a62-glibc-2.35/lib/libc.so.6
#3  0xf7f1095c in ?? () from 
target:/gnu/store/da6ikq281d235hvb1cil2ls3iq80ni2m-guile-3.0.9/lib/libguile-3.0.so.1
#4  0xf7f16f98 in scm_gensym () from 
target:/gnu/store/da6ikq281d235hvb1cil2ls3iq80ni2m-guile-3.0.9/lib/libguile-3.0.so.1
#5  0xf5d3a8ef in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 8 (Thread 0xe5497ac0 (LWP 877) "guile"):
#0  0xf7fc6579 in __kernel_vsyscall ()
#1  0xf794685e in __lll_lock_wait () from 
target:/gnu/store/0hr9jpczkcgpgqkhf4q4868xd57h5a62-glibc-2.35/lib/libc.so.6
#2  0xf794d11a in pthread_mutex_lock@@GLIBC_2.0 () from 
target:/gnu/store/0hr9jpczkcgpgqkhf4q4868xd57h5a62-glibc-2.35/lib/libc.so.6
#3  0xf7f1095c in ?? () from 
target:/gnu/store/da6ikq281d235hvb1cil2ls3iq80ni2m-guile-3.0.9/lib/libguile-3.0.so.1
#4  0xf7f16f98 in scm_gensym () from 
target:/gnu/store/da6ikq281d235hvb1cil2ls3iq80ni2m-guile-3.0.9/lib/libguile-3.0.so.1
#5  0xf5d3a8ef in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 7 (Thread 0xe5c98ac0 (LWP 876) "guile"):
#0  0xf7fc6579 in __kernel_vsyscall ()
#1  0xf794685e in __lll_lock_wait () from 
target:/gnu/store/0hr9jpczkcgpgqkhf4q4868xd57h5a62-glibc-2.35/lib/libc.so.6
#2  0xf794d11a in pthread_mutex_lock@@GLIBC_2.0 () from 
target:/gnu/store/0hr9jpczkcgpgqkhf4q4868xd57h5a62-glibc-2.35/lib/libc.so.6
#3  0xf7f1095c in ?? () from 
target:/gnu/store/da6ikq

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

[Csepp]

Josselin Poiret  writes:

> [[PGP Signed Part:Undecided]]
> 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,

I did, I think I already wrote that it wasn't coming from there, but
I'll check again when I next try it.

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

[Csepp]

Josselin Poiret  writes:

> [[PGP Signed Part:Undecided]]
> 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.

Since reconfigure overwrites /dev/sdb, I don't see how reversing the
order would fix things??
Maybe copying the file system over and *then* running init would make
sense.

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

I tried reproducing it, it seems to happen every time, but I can try to
create a more minimal test case.

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

I mean, that's the theory, but either Guix or GRUB seems to get the
incorrect UUID from *somewhere*.

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

[Csepp]

John Kehayias  writes:

> Hi Josselin and Csepp,
>
> On Wed, Jun 21, 2023 at 11:08 AM, Josselin Poiret wrote:
>
>> 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.
>>
>
> Likely that it was just overlooked, these things happen. Despite being
> two major releases behind, our version is less than a year old at
> least, so it wasn't completely forgotten :)
>
> I just tried a guix build harfbuzz --with-latest=harfbuzz and it
> worked, but I only built once and didn't try dependents. A quick look
> at the changelog shows mostly fixes and new API, doesn't look like
> anything immediately obvious as breaking, but this will affect ~9000
> packages.
>
> I do think this could be a more impactful change than the Mesa update
> but I say we put them all on a feature branch and see how the builds
> work out. If harfbuzz needs more work than it seems, we can just hold
> off on it and group it with the inevitable next Mesa update or some
> other related packages.
>
> How does that sound? I'll give it some days for comments on my
> previous message about a Mesa branch but the patches here are all
> trivial (so far...) so it would be nice to get builds started soon. My
> thoughts for Mesa were hopefully just a few days of checking builds
> and then merging, to keep it simple and straightforward. But we should
> group builds together rather than wasting resources.
>
> John
>
> PS: Csepp if you can reproduce the build failure and attach a log
> somewhere, that would be helpful. If newer harfbuzz is helpful but too
> drastic of a change everywhere, we could have a 'harfbuzz-next' to
> ease the transition.
>
> PPS: I'll bring this up elsewhere, but on a similar vein I noticed our
> freetype package is built without brotli support (anyone know why?).
> It is needed for the update to Godot 4. I'll raise the details on a
> forthcoming Godot patch.

So, I built Netsurf with --with-latest=harfbuzz, which also affected
GTK+ and a bunch of other packages along the way, and it worked on my
first attempt, just needed a stronger machine.
I copied over the resulting Netsurf to my laptop and have been using it
all day today, it seems to have shooed that bug away.
(Don't squash bugs, bugs are good for the ecosystem. They are only a
problem when they get inside your mainframe and cause a short. UwU)
BTW there was no log when it caused my system to hang.  I had to reboot
it with sysrq.  Probably a kernel bug?

So it looks like Harfbuzz can be updated without any problem.

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

[Csepp]

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?

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

[Csepp]

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

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.

Is this intended behaviour for some reason?

bug#64074: guix [COMMAND] --load-path does not check if path is valid

[Csepp]

Christian Miller via Bug reports for GNU Guix  writes:

> Hello,
>
> well in that case, if it is consistent with other GNU tools, it makes
> sense and this can be closed.  Though before closing, do you may have
> an example for invalid paths that could be useful?
>
> Best Regards
> Christian Miller

If I add ~/.local/bin to my $PATH and then delete that directory, I
don't want my shell to abort with an error.
I've also seen configure scripts add /usr/include, which doesn't exist
on Guix.

bug#53580: shepherd's architecture

[Csepp]

Ludovic Courtès  writes:

> Hi Attila,
>
> Attila Lendvai  skribis:
>
>> [forked from: bug#53580: /var/run/shepherd/socket is missing on an otherwise 
>> functional system]
>>
>>> So I think we’re mostly okay now. The one thing we could do is load
>>> the whole config file in a separate fiber, and maybe it’s fine to keep
>>> going even when there’s an error during config file evaluation?
>>>
>>> WDYT?
>>
>>
>> i think there's a fundamental issue to be resolved here, and
>> addressing that would implicitly resolve the entire class of issues
>> that this one belongs to.
>>
>> guile (shepherd) is run as the init process, and because of that it
>> may not exit or be respawn. but at the same time when we reconfigure
>> a guix system, then shepherd's config should not only be reloaded,
>> but its internal state merged with the new config, and potentially
>> even with an evolved shepherd codebase.
>
> Sorry to be direct: is there a concrete bug you’re reporting here?
>
>> i still lack a proper mental model of all this to succesfully
>> predict what will happen when i `guix system reconfigure` after i
>> `guix pull`-ed my service code, and/or changed the config of my
>> services.
>
> What happens is that ‘guix system reconfigure’ loads new services into
> the running shepherd.  New services simply get started; services for
> which a same-named service is already running instead get registered as
> a “replacement”, meaning that the new version of the service only gets
> started when the user explicitly runs ‘herd restart SERVICE’.
>
> Non-stop upgrades is ideal, but shepherd alone cannot do that.  For
> instance, nginx supports that, and no init system could implement that
> on its behalf.
>
> Ludo’.

Do services get a reference to their previously running version?
The Minix project was experimenting with supporting something like
supervisor trees for high uptime, and one way they were trying to
achieve that was by giving services the memory of their previous
version, so they could read their state and migrate it to their own
memory.

bug#63727: libffi propagation in glib versions causes issues

[Csepp]

Csepp  writes:

> guix upgrade: error: profile contains conflicting entries for libffi
> guix upgrade: error:   first entry: libffi@3.4.4 
> /gnu/store/w8b0l8hk6g0fahj4fvmc4qqm3cvaxnmv-libffi-3.4.4
> guix upgrade: error:... propagated from glib@2.72.3
> guix upgrade: error:... propagated from dconf@0.40.0
> guix upgrade: error:... propagated from eog@42.3
> guix upgrade: error:   second entry: libffi@3.3 
> /gnu/store/wgqhlc12qvlwiklam7hz2r311fdcqfim-libffi-3.3
> guix upgrade: error:... propagated from glib@2.70.2
> guix upgrade: error:... propagated from gdk-pixbuf@2.42.4
> guix upgrade: error:... propagated from libnotify@0.7.9
>
> Why do these need to be propagated?

This issue still persists, stopping me from being able to upgrade.
I also can't have both eog (Eye of GNOME) and the default glib
package installed, so just removing libnotify didn't help, and I'd
rather not play whack-a-mole with removing packages.

Some more insight into why there are multiple propagated versions of
libffi and glib would be greatly appreciated.

bug#63727: libffi propagation in glib versions causes issues

[Csepp]

guix upgrade: error: profile contains conflicting entries for libffi
guix upgrade: error:   first entry: libffi@3.4.4 
/gnu/store/w8b0l8hk6g0fahj4fvmc4qqm3cvaxnmv-libffi-3.4.4
guix upgrade: error:... propagated from glib@2.72.3
guix upgrade: error:... propagated from dconf@0.40.0
guix upgrade: error:... propagated from eog@42.3
guix upgrade: error:   second entry: libffi@3.3 
/gnu/store/wgqhlc12qvlwiklam7hz2r311fdcqfim-libffi-3.3
guix upgrade: error:... propagated from glib@2.70.2
guix upgrade: error:... propagated from gdk-pixbuf@2.42.4
guix upgrade: error:... propagated from libnotify@0.7.9

Why do these need to be propagated?

bug#55358: docker containers stopped when doing guix install or guix shell

[Csepp]

Remco van 't Veer  writes:

> Hi Maxim and Zimoun,
>
> 2023/02/09 13:26, Remco van 't Veer:
>
>> I think I know what is causing the issue.  Both the "standard" mysql and
>> postgres containers use user-id 999 to run the database service (this
>> seems like a common practice because the redis container is configured
>> similarly).  That user-id is also configured as guixbuilder01 so I guess
>> the guix daemon is killing those when processes when it finishes doing
>> builds.
>
> I found a solution / workaround for this problem by using
> "userns-remap".  This feature allows the remapping of uids and guids to
> different ranges.  I tried it by hacking the required files into my
> etc-directory and it works; guix no long kills my database containers.
>
> I'd like to add this feature to docker-service-type having a new
> configuration option named enable-userns-remap? which introduces a new
> user and group (both named dockremap) to do the remapping by adding some
> configurable number to the uids and guids of the running container.  In
> /etc/subuid and /etc/subgid it would look like:
>
>   dockremap:10:65536
>
> See https://docs.docker.com/engine/security/userns-remap/ for
> documentation about this.
>
> WDYT?
>
> Cheers,
> Remco

The rootless podman example that was shared a few months ago could be
relevant to this, since that also adds a subuid/subgid mapping.

bug#63530: Missing library in package procps

[Csepp]

Gabriel Wicki  writes:

> Hi
>
> Trying to upgrade a somewhat outdated system (from March 23) I noticed
> igt-gpu-tools failed to build.  Investigating a bit the build fails due
> to some "proc/readproc.h" include missing.  I think i managed to fix the
> failure in procps's Makefile, but testing the patched build results in a
> rather huge rebuild.  `guix refresh -l procps` results in 5328
> packages.  Are there any other approaches one could take to a) fix the
> broken package without b) triggering a world-rebuild?
>
> I'm not sure if this is an upstream bug and whether other packages are
> affected, neither do I know whether the other header files that aren't
> being copied to the install dir should be.
>
>
> Thanks for your input in advance!  I'll update this issue with a patch
> as soon as I manage to verify that my attempt actually works.
>
> gabber

You could test it as a graft, then dependents won't get rebuilt.  If the
public ABI exported by the package doesn't change, it Should Be Fine TM.

bug#63451: Guix pull not successful

[Csepp]

a  writes:

> first, i i ran guix pull and this happened. 
> i don't see anything in my kernel logs around this time
>
> λ ~ guix pull 
>[1259]
> Updating channel 'guix' from Git repository at 
> 'https://git.savannah.gnu.org/git/guix.git'...
> Authenticating channel 'guix', commits 9edb3f6 to d6f6b57 (667 new commits)...
> Building from this channel:
>   guix  https://git.savannah.gnu.org/git/guix.git   d6f6b57
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 
> 100.0%
> building 
> /gnu/store/kxhxsxmann4jv6z62z0ssh011sahk88k-compute-guix-derivation.drv...
> Computing Guix derivation for 'x86_64-linux'... /warning: 
> 'texlive-latex-tools' is deprecated, use 'texlive-tools' instead
> warning: 'texlive-latex-graphics' is deprecated, use 'texlive-graphics' 
> instead
> warning: 'texlive-generic-etexcmds' is deprecated, use 'texlive-etexcmds' 
> instead
> warning: 'texlive-generic-infwarerr' is deprecated, use 'texlive-infwarerr' 
> instead
> warning: 'texlive-latex-graphics' is deprecated, use 'texlive-graphics' 
> instead
> warning: 'texlive-latex-graphics' is deprecated, use 'texlive-graphics' 
> instead
> warning: 'texlive-generic-atbegshi' is deprecated, use 'texlive-atbegshi' 
> instead
> warning: 'texlive-latex-atveryend' is deprecated, use 'texlive-atveryend' 
> instead
> \Backtrace:
> In ice-9/boot-9.scm:
>222:29 19 (map1 (# (#) #) 
> # ?))
>222:29 18 (map1 (# (#) #) 
> (# ()))> # ?))
>222:17 17 (map1 (# 
> (# ?))
> In ice-9/psyntax.scm:
> Exception thrown while printing backtrace:
> Wrong type to apply: 129
>
> ice-9/boot-9.scm:3165:6: In procedure module-gensym:
> Invalid read access of chars of wide string: "m-1bcbf699e1749862-28a08"

This looks very weird, could you run a disk check and a guix store check
just to be safe?

bug#63050: "guix pull" requires graphical libraries

[Csepp]

Simon Tournier  writes:

> Hi,
>
> On ven., 05 mai 2023 at 15:21, Csepp  wrote:
>
>> Or just move it to a separate output or package?  That should really be
>> something done for all packages automatically tbh.  Alpine gets this right.
>
> Well, I do not think a separate output would be possible and we are not
> talking about the package named ’guix’ but about what is implemented by
> the module (guix self).
>
> Somehow, I agree that one direction would to make optional some
> features.  The current proposal for tackling this issue is the reduction
> of the closure by removing lix11 and libxrender as discussed in [1].
>
> 1: https://issues.guix.gnu.org/msgid/874jot19fd.fsf...@gnu.org
>
>
> Cheers,
> simon

It should be made possible IMHO.  It's nice that our packages come with
docs, including Guix, but they are often unnecessary.  If an output
won't work because guix-self is special, then maybe it could be moved to
a separate package.

bug#63050: "guix pull" requires graphical libraries

[Csepp]

Simon Tournier  writes:

> Hi,
>
> On Wed, 03 May 2023 at 21:33, Ludovic Courtès  wrote:
>
>>> Why does Guix require ’graphviz’ in the first place?
>>
>> It uses it to build images in the manual.
>
> Ah.  So we are dragging X11 libraries as libx11 for one or two figures
> in the manual. :-)
>
> Although that’s not exactly the same as “guix pull”,
>
> guix graph guix -t bag-emerged
>
> gives an idea.  Well, for example, there is a path from guix to ninja
> via graphviz.
>
> While I understand that the documentation is important, could we skip it
> for some architectures?

Or just move it to a separate output or package?  That should really be
something done for all packages automatically tbh.  Alpine gets this right.

bug#63287: guix copy error

[Csepp]

Any clue what might cause this?

% guix copy --from=bingobongo.local 
/gnu/store/4dqa1dh4vzfp4qkl704625m3riahnkiv-profile
retrieving 1 store item from 'bingobongo.local'...
Backtrace:
  14 (primitive-load "/home/raingloom/.config/guix/current/b…")
In guix/ui.scm:
   2300:7 13 (run-guix . _)
  2263:10 12 (run-guix-command _ . _)
In ice-9/boot-9.scm:
  1752:10 11 (with-exception-handler _ _ #:unwind? _ # _)
  1752:10 10 (with-exception-handler _ _ #:unwind? _ # _)
In guix/store.scm:
   659:37  9 (thunk)
   1298:8  8 (call-with-build-handler # …)
In guix/status.scm:
830:4  7 (call-with-status-report _ _)
In guix/scripts/copy.scm:
   104:22  6 (_)
In guix/ssh.scm:
   638:11  5 (retrieve-files* _ _ #:recursive? _ #:log-port _ # _)
In guix/store.scm:
  1719:22  4 (import-paths # #)
   729:14  3 (process-stderr _ _)
In guix/serialization.scm:
   122:12  2 (write-bytevector #vu8(0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 …) …)
In ice-9/boot-9.scm:
  1685:16  1 (raise-exception _ #:continuable? _)
  1685:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
In procedure modulo: Wrong type argument in position 1: #

bug#62984: Nautilus/File Roller cannot password encrypt for zip compression

[Csepp]

Maxim Cournoyer  writes:

> Hello,
>
> When selecting a file in Nautilus and clicking right-click ->
> Compress... and selected zip with password, attempting to proceed fails
> with the message "encryption not supported".
>
> The code path this supposedly uses is gnome-autoar, which itself uses
> libarchive.

AFAIK our libarchive is outdated, it's apparently also why Evince can't
open comics anymore.

bug#62985: [GNOME] MTP mounts in Nautilus doesn't work out of the box

[Csepp]

Maxim Cournoyer  writes:

> Hi,
>
> Connecting an Android phone via USB to a Guix System that has GNOME
> installed, and selecting the transfer mode to be USB/media, I'd expect
> it to appear in Nautilus, the same it does in other mainstream
> distributions.  Instead, nothing happens.
>
> In Fedora, for example, the device appears in the left panel of
> Nautilus, and a 'gvfsd-mtp' process starts running.  In Guix System,
> there's no 'gvfsd-mtp' process running, although a
> 'gvfs-mtp-volume-monitor' process is running.
>
> To be investigated.

I've also experienced this with plain USB block devices like some of my
microSD adapters.  No idea what causes it.  Sometimes it shows up in
Nautilus for a split second and then disappears.
Weirdly enough, running fdisk -l on the block device makes it show up in
Nautilus.

But it should be noted that our Nautilus version is behind by two versions.

bug#61882: profile is frozen / packages can't be installed

[Csepp]

(Jump forward a bit, this is a bit stream-of-consciousness-y, I wrote
things down as I was debugging things.  TLDR: profile got corrupted
somehow, it's not related to the packages themselves.)

Certain packages like flatpak do not get installed in my main user
profile for some unknown reason.
So far they are:
* gallery-dl
* flatpak
* emacs-org-roam

It has been happening for at least a month across several pulls.

If I export a manifest and load it in either guix shell -m or guix
package -m to a different profile, bin/flatpak exists, if I do guix
package -m without a profile argument or with the profile set to the
default user profile, bin/flatpak is missing.

The packages that are broken are always the same.

If I create a manifest with only the broken packages, guix package -I
reports exactly those packages, but when I look in ~/.guix-profile/bin
it still has a bunch of other packages in it.

So it seems the profile is frozen?  I have no idea how this could
happen.

guix package --list-generations reports three generations, but there is
only one generation in my home directory, called .guix-profile-1-link.

There is also a .guix-profile.lock, maybe that's related?
I see no lock for the other profile with the same manifest.

Removed the lock, tried guix package -m again, still don't have flatpak,
still only one generation symlink.

Deleted all the symlinks, ran guix package -m, now it works.

I'm gonna hold off on running the GC for a few days, if anyone has an
idea of where the bug is and wants me to upload some files, I can do it
until then.
For my own reference, this is the store item of the broken profile:
/gnu/store/0w3jxl95cchxn14zph3lmnqwmijf8971-profile

bug#62513: network-manager updated to unstable version?

[Csepp]

Maxim Cournoyer  writes:

> Hi John,
>
> John Kehayias  writes:
>
>> Hi Guix,
>>
>> (cc'ing Maxim as author of last few network-manager version updates.)
>>
>> I noticed a recent up date to network-manager to 1.43.4 (previously
>> 1.41.2 and 1.40.0) but can't find a record of that release. In their
>> docs there is no mention of anything newer than the 1.42 release [0,
>> 1] and they mention the even-numbered releases being the stable series
>> [2]. Indeed, Arch only has 1.42.4 in their repos [3]. I only see "dev"
>> tags for these 1.43 versions in their gitlab.
>>
>> Should we be on a 1.42.y version instead?
>
> The GNOME versioning scheme is a bit of a mess; they stopped using
> stable/unstable oven/odd release cycles since GNOME 40 I think, but left
> each of the components the luxury to keep using it, which NetworkManager
> appears to be doing.
>
> 'guix refresh -u' picked 1.43 and I didn't give it much of an thought.
> In general, I think it's OK to carry the "unstable" releases of GNOME
> components, which in my experience are usually stable :-).
>
>> I noticed this because the update to 1.43.4 has an issue with my
>> (wired) connection not resuming from sleep when previously it did. I
>> have to restart the service. I had some logs I can dig up, but in
>> discussing on IRC (no logs that day it seems) there was nothing out of
>> the ordinary and the shepherd service seemed normal.
>>
>> I've since reconfigured to a commit before the most recent version
>> change, namely 5174820753be045ba4fc7cc93da33f4e0b730bc3 and cannot
>> reproduce the issue so seems due to newer versions of network-manager
>> after 1.41.2 at least.
>>
>> Note that this may have been reported upstream [4], but I haven't
>> tested with the current stable release. So this may be a separate
>> (upstream) issue.
>
> So it seems that even if we used the "stable" 1.42.x release, we'd still
> have this problem.  It's been reported 4 days ago; I guess let's wait to
> see if a hotfix will be made, as that seems a serious issue.
>
> Otherwise, if many Guix users are affected and no hotfix is on the
> horizon, we could consider reverting back to our older version.
>
> Does that sound reasonable?

This also affects two of my recently reconfigured/upgraded machines.  My
guess is there are probably many others affected.

bug#62215: Cuirass search doesn't show exact matches first

[Csepp]

Tried looking up the CI status of GHC on i686-linux on Cuirass, gave up
after 3 pages of ghc-... packages.
Also tried the "name" field, as in name:ghc and name:ghc-9.2.5, but
neither worked.  Regex does not seem to be supported either, so "ghc$"
didn't work.

Cuirass should just use the same search rankings are "guix search" does
and prioritise exact matches.

bug#49775: can't type in Matrix ID in Nheko

[Csepp]

Michael Rohleder  writes:

> [[PGP Signed Part:Undecided]]
> Hi Raingloom!
>
> Thx for the bug-report!
>
> Is this still reproducable?
> And if so, is this on a foreign distro?

Seems to work now.

bug#61882: emacs-next-pgtk does not find emacs-org-roam, other path issues

[Csepp]

Liliana Marie Prikler  writes:

>> % ls ~/.guix-profile/share/emacs/site-lisp/
>> 
>> This does not print any org-roam directory.
> Which leads me to believe that
> $ ls /gnu/store/bxxjy8ydm62fr0bckxfrj27xnlvqbfmy-emacs-org-roam-2.2.2-
> 0.74422df/share/emacs/site-lisp
> does not report any such directory either.

It definitely reports it, I just didn't paste the result to save space.

I'll try running a repair when I get home, since FS corruption could
lead to any kind of weird behaviour, but I haven't had any corruption on
that machine ever, BTRFS has been pretty reliable for me.

Sorry for being so grumpy, I guess I should have highlighted the profile
corruption thing over the emacs-next-pgtk specific bits.

bug#61882: emacs-next-pgtk does not find emacs-org-roam, other path issues

[Csepp]

b...@bokr.com writes:

> Hi,
>
> On +2023-03-01 12:16:56 +0100, Csepp wrote:
> [...]
>> How the hell would my paths affect what's in the bin folder?  Like, the
>> flatpak binary is literally not present in the profile, that's why it's
>> not showing up in $PATH.
>
> Could something in one of your path directories
> accidentally have gotten a name starting with '-' ?
> (or full name '-')?
>
> Surprising things can happen depending on how an
> app rejects an unexpected option, or tries to use it :)
>
> BTW: If you can't delete a file named '-'
>  try emacs dirmode. IIRC emacs seems to see
>  anything and be able to delete it.
>
> Do you have any scripts that are both sourced and executed?
> If so, are they doing return or exit respectively or
> something trickier as intended?

So, first things first:
% guix package -I | grep -E '(flatpak|roam)'
emacs-org-roam  2.2.2-0.74422df out 
/gnu/store/bxxjy8ydm62fr0bckxfrj27xnlvqbfmy-emacs-org-roam-2.2.2-0.74422df
flatpak 1.14.1  out 
/gnu/store/mf0k987xvpgk79l74lmdjv9jz8gy8cdf-flatpak-1.14.1

Both are installed.

ls $(guix build flatpak)/bin/
flatpak  flatpak-bisect  flatpak-coredumpctl

The store paths also match.

This path also exists:
$(guix build emacs-org-roam)/share/emacs/site-lisp/org-roam-2.2.2-0.74422df

I don't know the details of how Emacs loads things, but org-roam has an
org-roam-autoloads.el while lsp-mode (a package that does work) does
not.

Some relevant paths:
EMACSLOADPATH=/home/raingloom/.guix-profile/share/emacs/site-lisp
PATH=/home/raingloom/.local/bin:/run/setuid-programs:/home/raingloom/.config/guix/current/bin:/home/raingloom/.guix-profile/bin:/home/raingloom/.guix-profile/sbin:/run/current-system/profile/bin:/run/current-system/profile/sbin

The only additional item is on PATH and at worst it would shadow an
existing flatpak binary.  But it doesn't, there is just a single utility
script there that I should probably get rid of.

Also:
guix shell --check -p .guix-profile
This seems to hang.  Or at least it's taking an awful long time for
something so simple.

I'm running Guix as my system distro and I'm not in the habit of adding
random junk to my dotfiles, so I would be rather surprised if this
turned out to be a path issue, especially when it's obvious the packages
are literally not even showing up in the profile they are supposed to
show up in.

% ls ~/.guix-profile/share/emacs/site-lisp/

This does not print any org-roam directory.

bug#61882: emacs-next-pgtk does not find emacs-org-roam, other path issues

[Csepp]

Liliana Marie Prikler  writes:

> Am Mittwoch, dem 01.03.2023 um 02:58 + schrieb Csepp:
>> emacs-org-roam is installed in my default profile and all the other
>> emacs packages work with the emacs-next-pgtk package in the same
>> profile.
>> guix shell emacs-org-roam emacs-next-pgtk does not work, guix shell
>> emacs-org-roam emacs does.
>> 
>> Possibly related: when I had flatpak installed it was not showing up
>> in my profile's bin directory, so I had to open it through guix
>> shell.
>> 
>> Maybe this is related to the bug where shell and build produce
>> differen derivations?
> You probably messed up some of your paths.  As a hint,
>   guix shell --pure -E DISPLAY emacs-next-pgtk emacs-org-roam -- emacs
> should run without any issues (apart from your init.el not working as
> intended – in that case, supply -Q).
>
> Try adding --check to your invocation of guix shell to see whether your
> rc files are borked.
How the hell would my paths affect what's in the bin folder?  Like, the
flatpak binary is literally not present in the profile, that's why it's
not showing up in $PATH.
Well, I'll check next time I'm on that machine, right now I'm writing
from the netbook and I'm in a bit of a hurry and don't want to wait for
derivation computations.
But I'm like 99% sure it's not due to my paths, because all other emacs
packages work.

bug#61883: evince no longer opens comics

[Csepp]

Evince used to be able to open cbz files but isn't anymore.
It still has the MIME type association registered and AFAIK upstream has
not removed support, so this is likely a packaging issue.

I've been meaning to investigate it but hasn't gotten around to it for
months, so I'm making this issue so that it's documented at least.

bug#61882: emacs-next-pgtk does not find emacs-org-roam, other path issues

[Csepp]

emacs-org-roam is installed in my default profile and all the other
emacs packages work with the emacs-next-pgtk package in the same
profile.
guix shell emacs-org-roam emacs-next-pgtk does not work, guix shell
emacs-org-roam emacs does.

Possibly related: when I had flatpak installed it was not showing up in
my profile's bin directory, so I had to open it through guix shell.

Maybe this is related to the bug where shell and build produce different
derivations?

current guix describe output (but this has been going on for at least a
month or so)
Generation 186  Feb 28 2023 02:57:13(current)
  guix ff5fbcc
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: ff5fbcc19bce6e94ead0cc79b27ae8ed0307463d
  raingloom c75fd77
repository URL: https://git.sr.ht/~raingloom/guix-packages
branch: master
commit: c75fd77980c7c5b45c91b0d921a25d8558266f41
  guix-science 5fc5e3e
repository URL: https://github.com/guix-science/guix-science.git
branch: master
commit: 5fc5e3e855c298a692c62129e9edd0fcc7c6949f
  nonguix 3a1e9f0
repository URL: https://gitlab.com/nonguix/nonguix.git
branch: master
commit: 3a1e9f0507d99403d1ba0f5557ee868b95b61eef

bug#61201: Installation hint crashes when user names contain at sign

[Csepp]

Ludovic Courtès  writes:

> Ludovic Courtès  skribis:
>
>> A funny thing was reported earlier today on the Café Guix channel:
>>
>> $ guix install hello  [17:52]
>> building profile with 5 packages...
>> hint: Backtrace:
>
> [...]
>
>> In guix/ui.scm:
>> 312:5  6 (display-hint _ )
>>   1451:24  5 (texi->plain-text )
>> In texinfo.scm:
>>   1132:22  4 (parse )
>>980:31  3 (loop # (fragment) _ _ )
>>967:36  2 (loop # #f # ?)
>>  92:2  1 (command-spec )
>> In ice-9/boot-9.scm:
>>   1685:16  0 (raise-exception _ #:continuable? )
>>  
>> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
>> Throw to key #E1E1E1">parser-error' with args(#f "Unknown command" univ)'.
>
> Here’s one way to reproduce the bug, showing a crash in ‘display-hint’
> due to an unescaped brace:
>
> $ mkdir /tmp/x{ample
> $ touch /tmp/x{ample/guix.scm
> $ (cd '/tmp/x{ample' ; guix shell)
> guix shell: error: not loading '/tmp/x{ample/guix.scm' because not authorized 
> to do so
> hint: Backtrace:
>   13 (primitive-load "/home/ludo/.config/guix/current/bin/guix")
> In guix/ui.scm:
>2279:7 12 (run-guix . _)
>   2242:10 11 (run-guix-command _ . _)
> In ice-9/boot-9.scm:
>   1752:10 10 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
> In guix/scripts/shell.scm:
>308:15  9 (_)
> In guix/ui.scm:
> 312:5  8 (display-hint _ _)
>   1451:24  7 (texi->plain-text _)
> In texinfo.scm:
>   1132:22  6 (parse _)
>980:31  5 (loop # (*fragment*) _ _ _)
>980:31  4 (loop # #f _ _ _)
>911:31  3 (loop # #f # 
> #f _)
>746:27  2 (_ # #f (example smallexample 
> verbatim lisp smalllisp menu w %) # …)
> In sxml/ssax/input-parse.scm:
>  88:2  1 (next-token _ _ _ _)
> In ice-9/boot-9.scm:
>   1685:16  0 (raise-exception _ #:continuable? _)
>
> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> Throw to key `parser-error' with args `(# "EOF 
> while reading a token " "reading char data")'.
>
> Ludo’.

Would it be heresy to recommend that plain strings and strings that
contain texinfo markup be separate types to catch this sort of thing?
In 2023 it's pretty embarrassing to have bugs that are basically SQL
injections.

bug#54944: guix pull hangs on 32 bit

[Csepp]

Csepp  writes:

> Csepp  writes:
>
>> Maxim Cournoyer  writes:
>>
>>> Hi!
>>>
>>> raingloom  writes:
>>>
>>>> It's been at 67% on guix-packages-base for at least an hour now. The
>>>> system itself is responsive and with the swap I gave it, it has more
>>>> than enough memory. Htop shows three guile processes at the top of the
>>>> list when sorted by CPU%, their states are S, D, D.
>>>> Both CPUs are practically idling.
>>>> This looks like some kind of lockup to me.
>>>>
>>>> Fresh install based on bare-bones example on a 32 bit netbook, but the
>>>> install image used is the latest tagged version, since apparently there
>>>> is no 32 bit option for edge.
>>>>
>>>> I also tried pulling using channel-with-substitutes, since I'm not too
>>>> keen on locally building everything on such an old machine. Although
>>>> Guix itself should frankly not take this long to build if we want to be
>>>> competitive with other distros. Anyways, pulling with that in
>>>> channels.scm gives a cert related error, so that's great, means old
>>>> images can't easily be used for installation.
>>>
>>> Have you been able to reproduce this?  If so, could you share the commit
>>> you are starting from and the CPU architecture, so that we may hopefully
>>> reproduce too?
>>>
>>> Thanks,
>>>
>>> Maxim
>>
>> CPU architecture is x86, commit it happened on last time is 347733b.
>> Other possibly relevant factors:
>> * spinning rust storage
>> * 1GB RAM
>> * encrypted BTRFS root
>> * 4GB (encrypted) swap
>> * 128MB zswap
>>
>> The last was not there when I originally submitted the bug.
>>
>> The swap is relevant because if it's a timing issue it's very possible
>> some part of the code assumes reads are almost instant, which is not
>> true with swap, and delaying a read might be exposing a race condition.
>
> Happening again.
> pulled to: 8320c0c
> pulled from: 4501a50
>
> Same system.
>
> The system version is from november of last year due, because trying to
> upgrade takes so damn long and often gets stuck on some package with no
> substitute.
> So... the situation is not great...

The process status says sleep so it's probably hanging in a syscall?
Maybe a kernel bug?

bug#54944: guix pull hangs on 32 bit

[Csepp]

Csepp  writes:

> Maxim Cournoyer  writes:
>
>> Hi!
>>
>> raingloom  writes:
>>
>>> It's been at 67% on guix-packages-base for at least an hour now. The
>>> system itself is responsive and with the swap I gave it, it has more
>>> than enough memory. Htop shows three guile processes at the top of the
>>> list when sorted by CPU%, their states are S, D, D.
>>> Both CPUs are practically idling.
>>> This looks like some kind of lockup to me.
>>>
>>> Fresh install based on bare-bones example on a 32 bit netbook, but the
>>> install image used is the latest tagged version, since apparently there
>>> is no 32 bit option for edge.
>>>
>>> I also tried pulling using channel-with-substitutes, since I'm not too
>>> keen on locally building everything on such an old machine. Although
>>> Guix itself should frankly not take this long to build if we want to be
>>> competitive with other distros. Anyways, pulling with that in
>>> channels.scm gives a cert related error, so that's great, means old
>>> images can't easily be used for installation.
>>
>> Have you been able to reproduce this?  If so, could you share the commit
>> you are starting from and the CPU architecture, so that we may hopefully
>> reproduce too?
>>
>> Thanks,
>>
>> Maxim
>
> CPU architecture is x86, commit it happened on last time is 347733b.
> Other possibly relevant factors:
> * spinning rust storage
> * 1GB RAM
> * encrypted BTRFS root
> * 4GB (encrypted) swap
> * 128MB zswap
>
> The last was not there when I originally submitted the bug.
>
> The swap is relevant because if it's a timing issue it's very possible
> some part of the code assumes reads are almost instant, which is not
> true with swap, and delaying a read might be exposing a race condition.

Happening again.
pulled to: 8320c0c
pulled from: 4501a50

Same system.

The system version is from november of last year due, because trying to
upgrade takes so damn long and often gets stuck on some package with no
substitute.
So... the situation is not great...

bug#60927: gPodder database version field different when built using --with-latest

[Csepp]

Ludovic Courtès  writes:

> Hi,
>
> Csepp  skribis:
>
>> So it looks like the hashes are the same and the difference is instead
>> in how it's run.
>> Usually I run it with i3's XDG desktop file based launcher, but when I
>> used the --with-latest transformation I was running it from a guix
>> shell.
>> Maybe it's using the non-canonicalized path to itself as part of the
>> version string.
>
> Note that right now ‘--with-latest’ has no effect because it’s already
> the latest version that’s packaged:
>
> $ guix build gpodder -n
> 4.2 MB would be downloaded:
>   /gnu/store/7jhmy0j4z50vb7051ckl0fkwv60y9aq8-python-pytest-httpserver-1.0.0
>   /gnu/store/rmkakj3hbijzcn8jdicyhh4fcwgw4kjk-xset-1.2.4
>   /gnu/store/almvw06pqf7gj09zkzi37iyzxph7abb2-xdg-utils-1.1.3
>   /gnu/store/zbsg01v7jzryx2ccgaxnm0qzi8b9022h-youtube-dl-2021.12.17
>   /gnu/store/cl22f0z9xggjspqsplf91bkqm35ad6fw-python-flake8-4.0.1
>   /gnu/store/spwqzk6l1r8wx34wlfnw487rc86skzgv-python-pycodestyle-2.8.0
>   /gnu/store/gaqm1cgvbam1jr2x7r6jw5gdrm9hv997-python-mutagen-1.45.1
>   /gnu/store/75h3kapgwpgh6q2dxddgrzbxwb22z9k7-python-xmlschema-1.2.5
>   /gnu/store/ixp9xd4cbs774yh5qkvywmjk1606s8i8-python-pytest-bootstrap-6.2.5
>   /gnu/store/7frqm5ijy66f81hr8i1j6791k84lds9w-python-pytest-6.2.5
>   /gnu/store/rfgdckaa197c4wkzixqqi3lmd6cvv414-python-requests-2.28.1
>   /gnu/store/hz1fv46474jm8d0lbirglx3cvmy8npkl-gpodder-3.11.0
> $ guix build gpodder -n --with-latest=gpodder
> guix build: 3.11.0 is already the latest version of 'gpodder'
> 4.2 MB would be downloaded:
>   /gnu/store/7jhmy0j4z50vb7051ckl0fkwv60y9aq8-python-pytest-httpserver-1.0.0
>   /gnu/store/rmkakj3hbijzcn8jdicyhh4fcwgw4kjk-xset-1.2.4
>   /gnu/store/almvw06pqf7gj09zkzi37iyzxph7abb2-xdg-utils-1.1.3
>   /gnu/store/zbsg01v7jzryx2ccgaxnm0qzi8b9022h-youtube-dl-2021.12.17
>   /gnu/store/cl22f0z9xggjspqsplf91bkqm35ad6fw-python-flake8-4.0.1
>   /gnu/store/spwqzk6l1r8wx34wlfnw487rc86skzgv-python-pycodestyle-2.8.0
>   /gnu/store/gaqm1cgvbam1jr2x7r6jw5gdrm9hv997-python-mutagen-1.45.1
>   /gnu/store/75h3kapgwpgh6q2dxddgrzbxwb22z9k7-python-xmlschema-1.2.5
>   /gnu/store/ixp9xd4cbs774yh5qkvywmjk1606s8i8-python-pytest-bootstrap-6.2.5
>   /gnu/store/7frqm5ijy66f81hr8i1j6791k84lds9w-python-pytest-6.2.5
>   /gnu/store/rfgdckaa197c4wkzixqqi3lmd6cvv414-python-requests-2.28.1
>   /gnu/store/hz1fv46474jm8d0lbirglx3cvmy8npkl-gpodder-3.11.0
> $ guix describe
> Generation 244  Jan 29 2023 23:24:35(current)
>   guix 4eccb27
> repository URL: https://git.savannah.gnu.org/git/guix.git
> branch: master
> commit: 4eccb27b4c74a9112cbbad722d85558e9565f20b
>
> So as you wrote, the issue you’re seeing probably has nothing to do with
> ‘--with-latest’.
>
> Could you show exactly what command you’re running, what output you’re
> seeing, and what you were expecting?
>
> TIA,
> Ludo’.

This works:
/gnu/store/1k5zcw81xfqlpxx4wfi5idi9pzlziykj-profile/bin/gpodder

This doesn't:
/home/raingloom/.guix-profile/bin/gpodder

The error is this:

```
1675212137.273854 [gpodder.log] ERROR: Uncaught exception: Traceback (most 
recent call last):
  File 
"/gnu/store/kchlzn44ykckx7x5ixx3vjsdnwyw9pzj-gpodder-3.10.21/lib/python3.9/site-packages/gpodder/gtkui/app.py",
 line 189, in do_activate
self.window = gPodder(self, self.bus_name, core.Core(UIConfig, 
model_class=Model), self.options)
  File 
"/gnu/store/kchlzn44ykckx7x5ixx3vjsdnwyw9pzj-gpodder-3.10.21/lib/python3.9/site-packages/gpodder/gtkui/main.py",
 line 91, in __init__
BuilderWidget.__init__(self, None, _builder_expose={'app': app})
  File 
"/gnu/store/kchlzn44ykckx7x5ixx3vjsdnwyw9pzj-gpodder-3.10.21/lib/python3.9/site-packages/gpodder/gtkui/interface/common.py",
 line 36, in __init__
GtkBuilderWidget.__init__(self, gpodder.ui_folders, gpodder.textdomain, 
parent, **kwargs)
  File 
"/gnu/store/kchlzn44ykckx7x5ixx3vjsdnwyw9pzj-gpodder-3.10.21/lib/python3.9/site-packages/gpodder/gtkui/base.py",
 line 71, in __init__
self.new()
  File 
"/gnu/store/kchlzn44ykckx7x5ixx3vjsdnwyw9pzj-gpodder-3.10.21/lib/python3.9/site-packages/gpodder/gtkui/main.py",
 line 185, in new
self.channels = self.model.get_podcasts()
  File 
"/gnu/store/kchlzn44ykckx7x5ixx3vjsdnwyw9pzj-gpodder-3.10.21/lib/python3.9/site-packages/gpodder/model.py",
 line 1380, in get_podcasts
self.children = self.db.load_podcasts(podcast_factory)
  File 
"/gnu/store/kchlzn44ykckx7x5ixx3vjsdnwyw9pzj-gpodder-3.10.21/lib/python3.9/site-packages/gpodder/dbsqlite.py",
 line 158, in load_podcasts
cur = self.cursor()
  File 
"/gnu/store/kchlzn44ykckx7x5ixx3vjsdnwyw9pzj-gpodder-3.10.21/lib/python3.9/site-packages/gpodder/dbsqlite.py",
 line 99, in cursor
return self.db.cursor()
  File 
"/gnu/store/kchlzn4

bug#61033: opam importer can't handle list field

[Csepp]

Julien Lepiller  writes:

> Le Tue, 24 Jan 2023 03:23:44 +0100,
> Csepp  a écrit :
>
>> Truncated stack trace:
>> 
>> ```
>> ...
>> In guix/import/opam.scm:
>> 287:2  3 (opam->guix-package "mirage-crypto-pk" #:repo _ # _)
>> In unknown file:
>>2 (filter #
>> …) In guix/import/opam.scm:
>>290:13  1 (_ ("mirage-no-solo5" "mirage-no-xen"))
>> In unknown file:
>>0 (string-prefix? "conf-" ("mirage-no-solo5" "mirage-n…")
>> …)
>> 
>> ERROR: In procedure string-prefix?:
>> In procedure string-prefix?: Wrong type argument in position 2
>> (expecting string): ("mirage-no-solo5" "mirage-no-xen") ```
>> 
>> 
>> 
>
> The issue is related to lines like this in the list of dependencies:
>
> (("mirage-no-solo5" & "mirage-no-xen") | "zarith-freestanding" |
> "mirage-runtime" {>= "4.0"})
>
> This reads as a choice between three dependencies:
> - mirage-no-solo5 with mirage-no-xen
> - zarith-freestanding
> - mirage-runtime
>
> The importer infrastructure is not intelligent enough to really be able
> to solve constraints in imported packages, so I don't see an easy
> solution. It could silently use the first option, or put a comment
> instead.
>
> Ideas?

I think in unhandled cases it should emit something usable instead of
erroring, like how it can already emit missing-source or whatever symbol
it uses.

If Guile had good error types like, like Result in OCaml or Rust, it
could signal this with the Error variant and then the sexp it failed on
as a parameter.

Alternatively we could do what Nix does and have importers implemented
externally, so we could just hook into OPAM and let it run its solver
and then emit Guix package definitions.  It already has a distro
integration system anyways.

So far these errors have been rare enough that handling them on a case
by case basis is acceptable, however I also ran into issues where the
wrong version of a package was imported and I spent hours trying to
debug the build until I realized I imported a version that's too new.
Having an opam2guix tool would solve that.

bug#58495: opam import generates wrong check phase

[Csepp]

Julien Lepiller  writes:

> Le Thu, 13 Oct 2022 18:16:18 +0200,
> Csepp  a écrit :
>
>> Julien Lepiller  writes:
>> 
>> > Maybe this could be fixed in the dune-build-system?
>> >  
>> Actually, good call.  I'll look into it, unless you want to take a
>> stab at it.
>
> With the test-target argument removed, do you consider this fixed?

Yup, it's fixed now, thanks for closing these.

bug#61033: opam importer can't handle list field

[Csepp]

Truncated stack trace:

```
...
In guix/import/opam.scm:
287:2  3 (opam->guix-package "mirage-crypto-pk" #:repo _ # _)
In unknown file:
   2 (filter # …)
In guix/import/opam.scm:
   290:13  1 (_ ("mirage-no-solo5" "mirage-no-xen"))
In unknown file:
   0 (string-prefix? "conf-" ("mirage-no-solo5" "mirage-n…") …)

ERROR: In procedure string-prefix?:
In procedure string-prefix?: Wrong type argument in position 2 (expecting 
string): ("mirage-no-solo5" "mirage-no-xen")
```

bug#60927: gPodder database version field different when built using --with-latest

[Csepp]

Tobias Geerinckx-Rice  writes:

> Hullo,
>
> On 2023-01-18 9:13, Csepp wrote:
>> Haven't completely debugged this, but the symptoms are:
>> * running the packaged version doesn't work, blank scree, failed assert
>> on console about differing database schema version
>
> I can't reproduce this, in either direction.  However, I didn't have
> an existing GPodder configuration or database, and I'm not even sure
> where those are kept.
>
> If you do, could you grep for one of the hashes?

So it looks like the hashes are the same and the difference is instead
in how it's run.
Usually I run it with i3's XDG desktop file based launcher, but when I
used the --with-latest transformation I was running it from a guix
shell.
Maybe it's using the non-canonicalized path to itself as part of the
version string.

bug#60927: gPodder database version field different when built using --with-latest

[Csepp]

Haven't completely debugged this, but the symptoms are:
* running the packaged version doesn't work, blank scree, failed assert
on console about differing database schema version
* running the --with-latest version works, but Guix says it's already on
the latest version

I think it might be storing an incorrect version at build time, maybe
using its path as the version.

bug#60844: no text in Anki

[Csepp]

I recently installed Anki and added some decks to study Japanese.
However, I only see cog icons when I open Anki.  Clicking them does pop
up a settings menu and I can see their names there.
Is this a QtWebkit bug again?
I tried the sandbox workaround I saw in some other bug report but it did
not help.

bug#60811: Can’t change the build system of p11-kit to meson

[Csepp]

Vivien Kraus via Bug reports for GNU Guix  writes:

> Dear guix,
>
> p11-kit is switching its build system to meson. The README already
> advertises it as the way to build p11-kit. When I try to change that,
> guix builds fine. Then, if I try to run guix build p11-kit, guix will
> crash after exhausting all my memory. I suspect a circular dependency
> of some sort, but I don’t know how to debug it.
>
> If I try and run:
> $ ./pre-inst-env guix graph --type=bag p11-kit
>
> Then I get as an output,
>
> digraph "Guix bag" {
>
> And then guix starts eating my memory indefinitely until I cancel it.
>
> How can I debug this?
>
> Best regards,
>
> Vivien

The way I debugged a cycle was:
* use package graph type
* import graph into Python's networkx using pydot
* run networkx's cycle detection

Here is the script so you don't have to figure it out yourself:

```
#!/usr/bin/env python
# coding: utf-8
import networkx
import sys
G = networkx.drawing.nx_pydot.read_dot(sys.stdin)
Va = networkx.function.get_node_attributes(G, "label")
print(*[Va[e[0]] for e in networkx.find_cycle(G)])
```

bug#60413: cutter is outdated and also segfaults on launch

[Csepp]

Our package for the Cutter reverse engineering framework is very
outdated and now the package does not even work, since the Cutter
executable simply crashes on startup in ImportsModel::rowCount.

I attempted packaging the new version that uses the new rizin fork of
radare2 but didn't get far.  I can't work on it right now, but if
someone wants to pick up where I left off, I'll push my branch to
https://git.sr.ht/~raingloom/guix-source/tree/raingloom/cutter

It's not currently online and it's on a different machine than the one
I'm writing from, but once pushed, it should be at that URL.

I'm not sure how a package that doesn't even start passed its check
phase.  Tests don't seem to be disabled, so maybe it's Wayland related?
But it was working fine a few months ago, so this is weird.

Either way, the version is old, so unless the fix is trivial, time is
better spent updating the package than fixing the current version.

bug#54944: guix pull hangs on 32 bit

[Csepp]

Maxim Cournoyer  writes:

> Hi!
>
> raingloom  writes:
>
>> It's been at 67% on guix-packages-base for at least an hour now. The
>> system itself is responsive and with the swap I gave it, it has more
>> than enough memory. Htop shows three guile processes at the top of the
>> list when sorted by CPU%, their states are S, D, D.
>> Both CPUs are practically idling.
>> This looks like some kind of lockup to me.
>>
>> Fresh install based on bare-bones example on a 32 bit netbook, but the
>> install image used is the latest tagged version, since apparently there
>> is no 32 bit option for edge.
>>
>> I also tried pulling using channel-with-substitutes, since I'm not too
>> keen on locally building everything on such an old machine. Although
>> Guix itself should frankly not take this long to build if we want to be
>> competitive with other distros. Anyways, pulling with that in
>> channels.scm gives a cert related error, so that's great, means old
>> images can't easily be used for installation.
>
> Have you been able to reproduce this?  If so, could you share the commit
> you are starting from and the CPU architecture, so that we may hopefully
> reproduce too?
>
> Thanks,
>
> Maxim

CPU architecture is x86, commit it happened on last time is 347733b.
Other possibly relevant factors:
* spinning rust storage
* 1GB RAM
* encrypted BTRFS root
* 4GB (encrypted) swap
* 128MB zswap

The last was not there when I originally submitted the bug.

The swap is relevant because if it's a timing issue it's very possible
some part of the code assumes reads are almost instant, which is not
true with swap, and delaying a read might be exposing a race condition.

bug#59364: gnome clocks does not start due to missing libGLES.so

[Csepp]

Simon Streit  writes:

> Hello,
>
> Csepp  writes:
>
>> This is the exact error:
>> Couldn't open libGLESv2.so.2: libGLESv2.so.2: cannot open shared object 
>> file: No such file or directory
>
> I can confirm this error, though it only happens in wayland enabled
> sessions on my old laptop with an Intel GM965/GL960.  This doesn't
> happen on machines with modern graphics cards installed.
>
> The list is longer for me on Gnome applications that will fail to start:
>
> gnome-calculator, gnome-calendar, gnome-characters, gnome-clocks
> gnome-contacts, gnome-font-viewer, etc.
>
> Checkout is at 8f9588185d74f1f251b041b84d43302c337588ff.

It does work with LIBGL_ALWAYS_SOFTWARE=1, but it would be pretty messed
up if that had to be enabled globally.

bug#59364: gnome clocks does not start due to missing libGLES.so

[Csepp]

This is the exact error:
Couldn't open libGLESv2.so.2: libGLESv2.so.2: cannot open shared object file: 
No such file or directory

(Yes, a clock application not starting because it needs OpenGL is... pretty
weird indeed.)

bug#59016: photoflare crash in the fish-shell on Menu -> File -> Open...

[Csepp]

Rostislav Svoboda  writes:

> Under bash everything is fine, however under the fish-shell the
> photoflare crashes when Ctrl-o is pressed or when I go Menu -> File ->
> Open... with the error below.
>
> Cheers
>
> Bost
>
> (photoflare:19613): Gtk-WARNING **: 15:31:01.261: Could not find the
> icon 'document-open-recent-symbolic-ltr'. The 'hicolor' theme
> was not found either, perhaps you need to install it.
> You can get a copy from:
> http://icon-theme.freedesktop.org/releases
>
> (photoflare:19613): Gtk-WARNING **: 15:31:01.261: Could not load a
> pixbuf from /org/gtk/libgtk/icons/16x16/status/image-missing.png.
> This may indicate that pixbuf loaders or the mime database could not be found.
> **
> Gtk:ERROR:gtkiconhelper.c:494:ensure_surface_for_gicon: assertion
> failed (error == NULL): Failed to load
> /org/gtk/libgtk/icons/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
> /org/gtk/libgtk/icons/16x16/status/image-missing.png: Unrecognized
> image file format (gdk-pixbuf-error-quark, 3)

Looks like it wants the hicolor-icon-theme, you can add it to your
profile with guix install, or possibly in your guix home config, if you
are using that.

bug#59004: hyperledger-iroha is broken

[Csepp]

Maxim Cournoyer  writes:

> Hi,
>
> I've tried fixing hyperledger-iroha without success.  Updating it to
> latest would require prometheus-cpp, not yet packaged.  Anything I've
> tried always end up with C++ compilation errors, such as this one
> (protobuf 3.14):
>
> c++14 -Wall -fdiagnostics-color=always -O2 -g -DNDEBUG -fPIC -MD -MT 
> shared_model/backend/protobuf/CMakeFiles/shared_model_proto_backend.dir/queries/impl/proto_get_signatories.o
>  -MF 
> CMakeFiles/shared_model_proto_backend.dir/queries/impl/proto_get_signatories.o.d
>  -o 
> CMakeFiles/shared_model_proto_backend.dir/queries/impl/proto_get_signatories.o
>  -c 
> /tmp/guix-build-hyperledger-iroha-1.1.1.drv-0/source/shared_model/backend/protobuf/queries/impl/proto_get_signatories.cpp
> /tmp/guix-build-hyperledger-iroha-1.1.1.drv-0/source/irohad/consensus/yac/impl/peer_orderer_impl.cpp:
>  In member function ‘virtual 
> boost::optional 
> iroha::consensus::yac::PeerOrdererImpl::getOrdering(const 
> iroha::consensus::yac::YacHash&, 
> std::vector >)’:
> /tmp/guix-build-hyperledger-iroha-1.1.1.drv-0/source/irohad/consensus/yac/impl/peer_orderer_impl.cpp:28:14:
>  error: ‘shuffle’ is not a member of ‘std’
>28 | std::shuffle(peers.begin(), peers.end(), gen);
>   |  ^~~
> make[2]: *** [irohad/consensus/yac/CMakeFiles/yac.dir/build.make:121: 
> irohad/consensus/yac/CMakeFiles/yac.dir/impl/peer_orderer_impl.o] Error 1
> make[2]: *** Waiting for unfinished jobs

At first I thought it might be using a C++ standard that is too new or
too old, but std::shuffle seems to have been standardized in C++11 and
has not been removed since.  Hmm.
https://en.cppreference.com/w/cpp/algorithm/random_shuffle
Still, I'd try compiling again with different compiler flags, might have
some luck.  Or looking into how std::shuffle is defined in the standard library.

bug#58914: linux-libre kernel socft-lock on T400 Thinkpad (BTRFS related?)

[Csepp]

The latest kernel reliably soft locks on my T400 thinkpad.  Sometimes it
locks up before the elogind login prompt, sometimes it reaches the
prompt but I can't log in.  It does not reboot on ctrl-alt-del, although
it does seem to send some kind of signal to elogind.  It does reboot for
alt-sysrq-b.
When I got to see the kernel log, it looked like it was stuck in some
BTRFS related code.  I use BTRFS on an SSD on this machine.
I know we have some other users with T400 Thinkpads, maybe they have run
into it as well?

I will try upgrading again since the kernel is a few days old.

$ guix system describe
Generation 116  Oct 23 2022 03:52:27
  file name: /var/guix/profiles/system-116-link
  canonical file name: /gnu/store/dhvng1gj6z88qzq6f2s1bw34jk668z5y-system
  label: GNU with Linux-Libre 5.19.16
  bootloader: grub
  root device: label: "GUIX"
  kernel: 
/gnu/store/dzim8lv0wv9dk94f38a1ly35ckmfscm3-linux-libre-5.19.16/bzImage
  channels:
guix:
  repository URL: https://git.savannah.gnu.org/git/guix.git
  branch: master
  commit: 78d4a08ac3a1de481bc56eef967a2e5ed2a912d5
raingloom:
  repository URL: https://git.sr.ht/~raingloom/guix-packages
  branch: master
  commit: bd30bbb2f7815e212d327a379ddbddc78fc4428a
guix-science:
  repository URL: https://github.com/guix-science/guix-science.git
  branch: master
  commit: 2602edd5ec989d244ea065b2edfe3b95bf8a8c3d
nonguix:
  repository URL: https://gitlab.com/nonguix/nonguix.git
  branch: master
  commit: 3f00d57adce5d0a185708fd5c7c5ff6f852c2bf7
  configuration file: 
/gnu/store/mldk0f0lmnsc7ahv0hh4cpd7a0q17cmy-configuration.scm

bug#58760: Guix System iso too big for cdrom again

[Csepp]

"pelzflorian (Florian Pelz)"  writes:

> Hello Guix,
>
> thanks to commit
>
> commit 26c1bd9dfafb5a954d2174b7a000304cd7ae6345
> Author: Tobias Geerinckx-Rice 
> Date:   Mon Apr 6 17:48:21 2020 +0200
>
> vm: Transparently compress iso9660 images.
> 
> * gnu/build/vm.scm (make-iso9660-image): Use the ‘--zisofs’ xorriso
> filter at the highest compression settings for supported directories.
>
> it was possible to burn the Guix System install image to a 700MB CD.
> But it fits no more.  I compared using the du tool (comparison between
> good old Guix version e427593 and bad new Guix version 3734857f (with
> unmerged installer patches) is attached).  The result is that most
> packages got slightly bigger and this broke the camel’s back.  From what
> Tobias (Cc) wrote, he used the highest compression settings.
>
> So it seems nothing can be done to make the install iso smaller than
> 700MB and support this antiquated storage medium, but I thought I’d open
> a bug and ask, because my laptop doesn’t boot from USB, I have more
> CD/Rs than DVD/Rs and I guess they are cheaper than DVD.
>
> Regards,
> Florian
>
> [2. text/plain; install-image-du-commit-e427593]...
>
> [3. text/plain; install-image-du-commit-3734857f]...
>
> [4. text/plain; install-image-du-comparison]...

Are there unnecessary dependencies that could be cut out?

bug#58497: opam import doesn't work with ocaml_intrinsics among others

[Csepp]

Julien Lepiller  writes:

> (beautify-description #f _)
>
> Seems to be the cause. Yet, there is a description. Maybe parsing ends a bit 
> too soon?

That might explain issue 58112 as well.  I have a workaround that gives
#f for description.

bug#58568: Error when install the latest developments image

[Csepp]

Zhongyou Li  writes:

> Hi Guix,
> I got an error when install the latest developments image on virtual box on 
> macOS on MacBook Air
> 2015.
> I think the installation failed because the script did not delete the 
> download directory when the
> download failed, causing the directory name conflict when redownloading.
> I'm not sure if I'm right, so the specific information is below.
> For specific error messages, see the picture.
>
> Here is my configuration when install time:
> Local Language: English
> Local location: United States
> Graphical install using a terminal based interface
> Timezone: Asia, Shanghai

Looks like a substitution error, might have something to do with Guix
related servers being blocked in China and Russia, or at least they were
blocked recently.

bug#58551: kgraphviewer is broken

[Csepp]

message in GUI is "could not find the KGraphViewer part", on console it's:
kf5.kxmlgui: cannot find .rc file "kgraphviewerui.rc" for component 
"kgraphviewer"

Ran with guix shell --no-grafts because there is some gosh darn bug with
grafts again and even though both this and Krita report as OK on the CI
dashboard, users have to build dozens (no an exaggeration) of packages
on their own machines.

bug#58497: opam import doesn't work with ocaml_intrinsics among others

[Csepp]

The error might not be the same for others, I have a slightly patched
opam->guix-package function.

guix import opam ocaml_intrinsics
Backtrace:
In ice-9/boot-9.scm:
  1752:10 10 (with-exception-handler _ _ #:unwind? _ # _)
In unknown file:
   9 (apply-smob/0 #)
In ice-9/boot-9.scm:
724:2  8 (call-with-prompt _ _ #)
In ice-9/eval.scm:
619:8  7 (_ #(#(#)))
In guix/ui.scm:
   2263:7  6 (run-guix . _)
  2226:10  5 (run-guix-command _ . _)
In guix/scripts/import.scm:
92:11  4 (guix-import . _)
In guix/scripts/import/opam.scm:
   105:24  3 (guix-import-opam . _)
In guix/import/opam.scm:
   385:24  2 (opam->guix-package _ #:repo _ #:version _)
In guix/import/utils.scm:
   290:27  1 (beautify-description #f _)
In unknown file:
   0 (string-trim-both #f # # #)

ERROR: In procedure string-trim-both:
In procedure string-trim-both: Wrong type argument in position 1 (expecting 
string): #f

bug#58495: opam import generates wrong check phase

[Csepp]

Julien Lepiller  writes:

> Maybe this could be fixed in the dune-build-system?
>
Actually, good call.  I'll look into it, unless you want to take a stab
at it.