bug#44254: Performance of package input rewriting

Hi Ludo, > I guess it’s easy to end up creating huge object graphs. Here’s an > example of an anti-pattern: > > (define a > ((package-input-rewriting x) ((package-input-rewriting y) p1))) > > (define b > ((package-input-rewriting x) ((package-input-rewriting y) p2))) > > The corre

bug#44370: Cuirass fails building (some) packages from a custom-packages input

Hi Mathieu, Mathieu Othacehe skribis: >> Now, why is David’s use case influenced by the way (gnu ci) handles >> licenses? > > David has some custom packages with the license set to "#f", causing the > following backtrace: > > guix/inferior.scm:247:2: ERROR: > 1. &inferior-exception: > ar

bug#44196: [PATCH 2/3] system: Add store-directory-prefix to boot-parameters.

Hi, Miguel Ángel Arruga Vivas skribis: > I've pushed this change as 2df44e934c9ba14a89d9245d1a4f7cf18e8cfdaa with > changes on the rest of the comment as well, as the wording was the same, > as I agree that path should refer to a route (where there could be > several concrete locations/file name

bug#44254: Performance of package input rewriting

Hi, Lars-Dominik Braun skribis: >> I guess it’s easy to end up creating huge object graphs. Here’s an >> example of an anti-pattern: >> >> (define a >> ((package-input-rewriting x) ((package-input-rewriting y) p1))) >> >> (define b >> ((package-input-rewriting x) ((package-input-

bug#44414: xterm has GI_TYPELIB_PATH set when started via gdm via fluxbox

Hi, this is one of the bug reports in the aftermath of the problem I had outlined in "GNOME in Guix" thread. Currently, even when using xterm, started by fluxbox, started by gdm-x-session, the environment variable GI_TYPELIB_PATH is set inside the shell started by that xterm. Please don't do set

bug#42162: Recovering source tarballs

Hi Timothy, I hope you’re well. I was wondering if you’ve had the chance to fiddle with Disarchive since the summer? I’m thinking there are small steps we could take to move forward: 1. Have a Disarchive package in Guix (and one for guile-quickcheck, kudos on that one!). 2. Have a Cui

bug#44417: ungoogle-chromium crashes on Jitsi & co.

Hello! Current ungoogle-chromium (commit e1f5c2292b88525414b5d0336a00bfa6741d4f14) crashes upon displaying video as in Jitsi (GPU_DEAD_UPON_ARRIVAL error, IIRC). Conversely, I found that this one works fine: --8<---cut here---start->8--- $ /var/guix/profiles/p

bug#44399: Cuirass problem with building from manifest file

On 2020-11-02 20:12, Mathieu Othacehe wrote: Could you please confirm that it works? Thanks, Mathieu Things do work now. I had made a mistake in my config. In case it helps someone; to fix it, I changed my-guixsd-config input load path to ".": ((#:name . "config")

bug#42162: Recovering source tarballs

Hi, On Tue, 3 Nov 2020 at 15:26, Ludovic Courtès wrote: > 2. Have a Cuirass job running on ci.guix.gnu.org to build and publish > the disarchive-db. One question is: how does the database scale? And only the real world can show it. ;-) > Ludo’, who’s still very much excited about thes

bug#38529: Make --pure the default for `guix environment'?

Ludovic Courtès writes: > Hello! > > "Thompson, David" skribis: > >> I have long thought that --ad-hoc should be implied, as that is the >> mode I use 99% of the time, but I disagree that --pure should be the >> default. > > I very much agree with that. I don’t think ‘--pure’ should be the > def

bug#35594: GNOME: Application icons are not displayed immediately after installation

Hello, sirgazil writes: > Hi, > > I installed the GNU system in a real machine using Guix 1.0 ISO > installer > (https://ftp.gnu.org/gnu/guix/guix-system-install-1.0.0.x86_64-linux.iso.xz). > > Whenever I install a desktop application, the application icon does > not show up immediately in the l

bug#44402: `guix pull` crashes on current master

Three of us in #guix experienced this crash, and then could not reproduce it afterwards. So... it's not great, but since nobody else is having trouble, I'm closing this bug.

bug#38529: Make --pure the default for `guix environment'?

Hi, On Tue, 03 Nov 2020 at 12:38, Christopher Lemmer Webber wrote: >> Ideas on how to achieve it are welcome! [..] > It suddenly struck me today that there is an easy way to change the > default behavior while supporting the legacy behavior. > > How about we have a new command, "guix env", wha

bug#35594: GNOME: Application icons are not displayed immediately after installation

Hello, Maxim Cournoyer writes: > After asking in the #gnome channel on freenode, the problem is likely > caused by GNOME Shell using inotify to watch the $XDG_DATA_DIRS > referenced $HOME/.guix-profile/share/applications directory. The > problem is that the inode of such directory will never c

bug#42162: Recovering source tarballs

Hi Ludo, Ludovic Courtès writes: > I hope you’re well. I was wondering if you’ve had the chance to fiddle > with Disarchive since the summer? Sort of! I managed to get the entire corpus of tarballs that I started with to work (about 4000 archives). After that, I started writing some document

bug#44382: Updating the guix package triggers a full Git clone of guix.git

Hi, Leo Famulari skribis: > I poked around a bit and found that Savannah can serve shallow clones of > random commits, but does not allow shallow *fetching*, except for > special things such as Git tags. We fetch instead of clone. Weird, what’s the difference between fetch and clone technically

bug#35594: GNOME: Application icons are not displayed immediately after installation

Hi again, Maxim Cournoyer writes: > Hello, > > Maxim Cournoyer writes: > >> After asking in the #gnome channel on freenode, the problem is likely >> caused by GNOME Shell using inotify to watch the $XDG_DATA_DIRS >> referenced $HOME/.guix-profile/share/applications directory. The >> problem i

bug#36376: Application menu of desktop environment not automatically updated

Ludovic Courtès skribis: > This is not news to us, but as > notes, the > application menu of desktop environments is not automatically updated > when a package is installed or removed. It’d be great if we could > somehow notify the deskt

bug#44417: ungoogle-chromium crashes on Jitsi & co.

Ludovic Courtès writes: > Current ungoogle-chromium (commit > e1f5c2292b88525414b5d0336a00bfa6741d4f14) crashes upon displaying video > as in Jitsi (GPU_DEAD_UPON_ARRIVAL error, IIRC). The demo at https://meet.jit.si "works for me". That is with "intel-vaapi-driver" installed. Does that make a

bug#36376: Application menu of desktop environment not automatically updated

Hi Ludo, Am Dienstag, den 03.11.2020, 23:46 +0100 schrieb Ludovic Courtès: > Ludovic Courtès skribis: > > > This is not news to us, but as > > notes, > > the > > application menu of desktop environments is not automatically > > updated >

bug#44053: ‘xdg-mime-database’ profile hook is slow

Hi, > > https://git.savannah.gnu.org/cgit/guix.git/commit/?id=76ea70bd70aeb76570445c11cea2f98139192b54 Clever workaround! What are now the performances on previous examples (same profiles and same packages)? > Unfortunately, AIUI, > > update-mime-database(X ∪ Y) ≠ update-mime-database(X)

bug#44327: `guix install` doesn't warn about collison in profile

> > I also suggest to raise an error when conflict detected during building > > profile to force user to resolve it. > It should be already the case. :-) IIRC the deafult collision handler of union-build is warn-about-collision which doesn't terminate the build when collision occured. BTW, Ther