bug#34243: update cmake to latest release (3.13.3)

This is a wish. :-) Clément

bug#34243: update cmake to latest release (3.13.3)

Marius Bakke writes: > Clément Lassieur writes: > >> This is a wish. :-) > > Will 3.13.1 from 'staging' do? Yes sure! I hadn't checked staging. Thanks you :-)

bug#35606: Gajim

Thank you Ricardo for fixing and Raghav for reporting this bug I introduced! Sorry not to have more time to work on it at the moment. Clément On Tue, May 14, 2019, 2:13 PM Ricardo Wurmus wrote: > > Raghav Gururajan writes: > > >> I fixed this with commit a624c3631077aa3fa5c05849579932c5b67b98

bug#38171: guix lynx can not connect, ArchLinux lynx can, why?

t © 2018 Pierre Neidhardt +;;; Copyright © 2019 Clément Lassieur ;;; ;;; This file is part of GNU Guix. ;;; @@ -222,7 +223,7 @@ and the GTK+ toolkit.") ("perl" ,perl))) (inputs `(("ncurses" ,ncurses) ("libidn" ,libidn

bug#38171: guix lynx can not connect, ArchLinux lynx can, why?

Leo Famulari writes: > Can you double-check that the licenses of Lynx and OpenSSL are > compatible for redistribution? https://lynx.invisible-island.net/current/README.ssl says: --8<---cut here---start->8--- OpenSSL's distribution and use may be restricted by

bug#38186: dd doesn't copy whole file when specifying units with bs

Hi Jack, > It seems that my version of dd from coreutils-8.31 does not seem to work > correctly when using units with the bs option (e.g. bs=1M). In the terminal > session below, I first use bs=1M. The output looks okay: dd appears to have > copied the whole 2.3GiB file, but it has done so impossi

bug#38186: dd doesn't copy whole file when specifying units with bs

Jack Hill writes: > On Tue, 12 Nov 2019, Clément Lassieur wrote: > >> Does this[1] help? >> >> [1]: >> https://superuser.com/questions/730801/dd-immidiately-completes-but-actually-needs-sync > > Indeed it does. I guess I just got lucky with the second in

bug#38171: guix lynx can not connect, ArchLinux lynx can, why?

Pushed. Bengt, you can 'guix pull', it should work now :) Clément

bug#38232: Cuirass: Some builds fail although their log file ends with 'build-succeeded'

See https://ci.guix.info/build/1934383/details.

bug#36378: Guix Cuirass Issue with Input channels

Hi Reza and Ludo, Reza Alizadeh Majd writes: > adding additional inputs to cuirass specification with name started > with `p` letter, fails the evaluation of specification. Thank you for reporting this! It actually fails with names that come after the first input (in this case: "guix") in alph

bug#36378: Guix Cuirass Issue with Input channels

Clément Lassieur writes: > So it's indeed a bug in Guix, introduced by commit > b5f8c2c88543158e8aca76aa98f9009f6b9e743a (hydra: Compute jobs in an > inferior). We can't just take the first input we find, build it and > open an inferior for it. I believe we should tak

bug#36378: Guix Cuirass Issue with Input channels

Clément Lassieur writes: >> So it's indeed a bug in Guix, introduced by commit >> b5f8c2c88543158e8aca76aa98f9009f6b9e743a (hydra: Compute jobs in an >> inferior). We can't just take the first input we find, build it and >> open an inferior for it. I believe w

bug#38232: Cuirass: Some builds fail although their log file ends with 'build-succeeded'

Hi Ludovic, > Perhaps the build failed (transient failure or something) but was > eventually restarted either as a dependency of some other build or > manually on berlin. In that case Cuirass may be unaware that the build > eventually succeeded, hence the discrepancy. Thank you for the explanati

bug#31910: hydra doesn't build

Closing because hydra was removed[1]. [1]: https://git.savannah.gnu.org/cgit/guix.git/commit/?id=cc908fde64799eaa60e1e63be75697a12f7cb017

bug#38320: Cuirass: Allow to use authenticated Git repositories as inputs

Hi, I'd like to use private Git repositories as inputs, authenticated with SSH. I think it is important because it would encourage users to use Cuirass for other purposes than just a CI tool to build Guix packages. I'd like to see it as an alternative to Jenkins, it would make its user base broa

bug#38309: Recent $EMACSLOADPATH changes crash gnome-session

"Alex Griffin" writes: > After upgrading my packages today, gnome-session started segfaulting. I think > I finally tracked the problem down to the recent changes in how Emacs searches > for packages. Apparently Emacs now uses the search path > $EMACSLOADPATH. Unfortunately, this is a very long va

bug#38309: Recent $EMACSLOADPATH changes crash gnome-session

Hello Maxim, Thanks for taking the time to look into this. I've seen your other email, you can install libpcre3-dbg to have PCRE's debug symbols. It might help. Maxim Cournoyer writes: > Hello Ludovic, > > Ludovic Courtès writes: > >> Hi Maxim, >> >> Maxim Cournoyer skribis: >> >>> There wo

bug#38309: Recent $EMACSLOADPATH changes crash gnome-session

Maxim Cournoyer writes: > Hello Ludovic, > > Ludovic Courtès writes: > >> Hi Maxim, >> >> Maxim Cournoyer skribis: >> >>> There would be a couple more commits to include in the revert to undo >>> the changes (one to the build system, others to adapt the renaming of >>> the emacs-set-load-path p

bug#38309: Recent $EMACSLOADPATH changes crash gnome-session

Clément Lassieur writes: (in https://lists.gnu.org/archive/html/bug-guix/2019-11/msg00363.html) > Thanks for taking the time to look into this. I've seen your other > email, you can install libpcre3-dbg to have PCRE's debug symbols. It > might help. I thought you were repr

bug#38309: Recent $EMACSLOADPATH changes crash gnome-session

Hi Maxim, Maxim Cournoyer writes: > I was ready to revert the changes when I saw a reply from Leo Prikler in > this thread. They had really good ideas that I believe fix the > annoyances you reported about the recent changes, while preserving the > new plus points (per profile management of Ema

bug#38309: Recent $EMACSLOADPATH changes crash gnome-session

Maxim Cournoyer writes: > I was ready to revert the changes when I saw a reply from Leo Prikler in > this thread. They had really good ideas that I believe fix the > annoyances you reported about the recent changes, while preserving the > new plus points (per profile management of Emacs packages

bug#38320: Cuirass: Allow to use authenticated Git repositories as inputs

Mathieu Othacehe writes: >> * Fix the regression mentionned above. > > I would need some help for this regression I don't understand, but I > will take care of the work needed in Guile-Git and (guix git) once this > is fixed. Thank you Mathieu for your replies! I'm looking forward to your work

bug#36378: Guix Cuirass Issue with Input channels

Hi, Clément Lassieur writes: > Attached is a patch that makes sure the checkout is from the Guix input > providing the 'proc'. I'll push this tomorrow if nobody objects. Thanks, Clément

bug#36378: Guix Cuirass Issue with Input channels

Pushed, closing.

bug#38445: Guix CI evaluation broken

Hi, https://git.savannah.gnu.org/cgit/guix.git/commit/?id=99c45877a984dd0148151b2e304afef6fb04f1a5 broke Guix CI. The reason is: (local-file (string-append "" "../some-file")) now differs from (local-file "../some-file") And in gnu/system/install.scm (line 246) there's a STRING-APPEN

bug#38446: Guix pull broken

https://git.savannah.gnu.org/cgit/guix.git/log/ returns 502 error. Reproducible 9 times out of 10.

bug#38446: Guix pull broken

Clément Lassieur writes: > https://git.savannah.gnu.org/cgit/guix.git/log/ returns 502 error. > > Reproducible 9 times out of 10. Since at least yesterday.

bug#59570: zbarimg displays a weird message on stderr

Reproduced on foreign distro (Ubuntu 22.04). Steps to reproduce: > echo bar | qrencode --8bit --output foo.png > zbarimg -1 -q --raw -Sbinary foo.png Output: > Name Error (Connection ":1.734" is not allowed to own the service > "org.linuxtv.Zbar" due to security policies in the configuration f

bug#59570:

X-Debbugs-CC: g...@posteo.net

bug#59579: installing zbar prevents gdm to start on Ubuntu 22.04 foreign distro

Severity: serious Steps to reproduce: > - install Ubuntu 22.04 > - install Guix package manager > - guix package -i zbar > - reboot Expected result > boot result > login loop It's very difficult to pin the issue down to a guix package being installed. I imagine the bug would not happen if ~

bug#31789: nss-mdns test is failing

t replicate this; does this still occur for you? > > Clément Lassieur writes: > > > nss-mdns test is failing. Here is the output: > > > > Starting test avahi > > Group begin: avahi > > Test begin: > > test-name: "wait for services"

bug#32954: Cuirass: logs of failed dependencies are unavailable

Thanks!!! Awesome :)

bug#38445: Guix CI evaluation broken

Bengt Richter writes: > Would s/exemples/examples/g do any good? Definitely.

bug#38445: Guix CI evaluation broken

Hi Ludo, Ludovic Courtès writes: > Sorry for the breakage! I noticed it yesterday and fixed it in > 33d1c970c323971da8d70a662748c7b1b520d6b6. > > Let me know if you think anything else is wrong! I find the initial commit[1] counterintuitive and would have loved a discussion before the fix. I

bug#38445: Guix CI evaluation broken

Sorry for my tone, it might sound harsh, it's not what I meant, I just didn't have coffee yet ;) Clément Lassieur writes: > Hi Ludo, > > Ludovic Courtès writes: > >> Sorry for the breakage! I noticed it yesterday and fixed it in >> 33d1c970c323971da8d70a662

bug#38309: Recent $EMACSLOADPATH changes crash gnome-session

Hello Maxim, Any update about this? Any plan to push a fix or a revert? I've been using your new patches without any issue for a few days already. Thanks, Clément

bug#38446: Guix pull broken

Hi Amin, Thank you for this nice reply. Would it be possible to have an *official* backup Git repository hosted somewhere else (like Github, or whatever), where we could redirect users when they encounter issues? Clément Amin Bandali writes: > Hi folks, > > The reason for these errors is that

bug#38446: Guix pull broken

Hi Ricardo, Ricardo Wurmus writes: > For the time being you can do > > git clone https://guix.gnu.org/git/guix > > which is a read-only copy of my clone of the repository. I’d like to > make it automatically sync up with the repo on Savannah, but I ran out > of time. Great! Thank you very m

bug#38309: Recent $EMACSLOADPATH changes crash gnome-session

Hi Ludo and Maxim, Ludovic Courtès writes: > Hi! > > clem...@lassieur.org (Clément Lassieur) skribis: > >> Any update about this? Any plan to push a fix or a revert? I've been >> using your new patches without any issue for a few days already. > >

bug#38550: Cuirass: in job-name: replace 'version' with 'anchor'

See IRC conversation[1]. The idea is that we want to be able to select all the builds that have the same job-name. Then we'll be able to see the first one that's failing and its associated evaluation (the culprit). We could use PACKAGES->ANCHORS[2], which was created for the website. Thus instea

bug#38320: Cuirass: Allow to use authenticated Git repositories as inputs

Hi everyone, Whoo, nice, thank you so much Mathieu! I'll test everything this week-end probably, and start working on the (guix git) / Cuirass counterpart (which is 1% of the work :D). Mathieu Othacehe writes: > Now regarding (guix git) integration, I have a question. It would be nice > to hav

bug#39298: re-exporting local variable: iota

Ricardo Wurmus writes: > Since the upgrade to Guile 3.0 I can no longer upgrade my profile. The > module-import-compiled derivation can no longer be built. It fails with > a backtrace involving only Guile modules, no Guix modules. > > The error is: > > ice-9/boot-9.scm:752:25: In procedure di

bug#39298: re-exporting local variable: iota

Ludovic Courtès writes: > Fixed in 5e61de242156cdb3314abac168d9682ca7a4c28f. Thank you for the quick fix!

bug#66254: "guix --version | head -1" crashes most of the time

> guix --version | cat | head -1 works > guix --version | head -1 crashes most of the time (on foreign distro) See attached log. Same bug with 'head' from Guix coreutils. Thanks, Clémentclement@newt:~$ guix --version | head -1 guix (GNU Guix) ce0cc6137df81919389f61671096a6ce701c0889 clement@ne

bug#66254: "guix --version | head -1" crashes most of the time

Simon Tournier writes: > Hi Clément, Hey Simon, [...] > Anyway. The issue is from leave-on-EPIPE. This patch fixes the issue, > I guess. > > diff --git a/guix/ui.scm b/guix/ui.scm > index 6f2d4fe245..507bc67f1d 100644 > --- a/guix/ui.scm > +++ b/guix/ui.scm > @@ -2309,7 +2309,7 @@ (define (r

bug#66659: (home-)on-first-login script broken when no gexps are added

Nils Landt writes: >> I’ve just pushed something similar to what you provided, Carlo, in >> commit e098ba2f499bbddfea50c85058e4077e39b85513. >> >> We should be good now. > > I'm afraid this did not fix the issue. It results in > (when (claim-first-run flag-file-path) (begin)) > > which leads to

bug#51884: [IceCat]: Segmentation Fault

On Mon, Nov 15 2021, Raghav Gururajan via Bug reports for GNU Guix wrote: > Hello Folks! > > Icecat segfaults when 'Detect captive portal' is enabled. > > Steps to reproduce: > [1] Temporarily remove or rename `~/.mozilla`, for clean start. > [2] Start IceCat. > [3] Enable 'Detect captive portal'

bug#66659: (home-)on-first-login script broken when no gexps are added

On Tue, Oct 24 2023, Rostislav Svoboda wrote: >> > I've just pushed something similar to what you provided, Carlo, in >> > commit e098ba2f499bbddfea50c85058e4077e39b85513. >> > >> > We should be good now. >> >> I'm afraid this did not fix the issue. It results in >> (when (claim-first-run flag-fil

bug#66290: transmission-daemon-service-type not serving web interface

On Sun, Nov 26 2023, Alan Manuel Gloria wrote: > The necessary files are in the "gui" output, with a relative path of > "/share/transmission/public_html". It seems to have been fixed by Clément > Lassieur in commit > 27ec9eeceb971afe11aae4f24ceb8764f1735634 (wh

bug#66290: transmission-daemon-service-type not serving web interface

On Thu, Nov 30, 2023, at 2:44 AM, Alan Manuel Gloria wrote: > Just did a `guix pull` and rebuilt the system with `guix system reconfigure` ( > which took a few days, !! > seems there was a lot of changes), and now the transmission web UI is > working. So probably I was just before that change. >

bug#67967: Clang 15.0.7 is not reproducible

Hi, I got this message today while building with offload something that depends on Clang: guix offload: error: hash of path `/gnu/store/2najhc2xrch1ix7y6424zhbym9cm1ih0-clang-15.0.7' has changed from `9909f3f5754b9361ace302243051797cfda01ef006051f4bc4415e027e34f111' to `666da88645ad4b0dc806785

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

On Mon, Jan 15 2024, chris wrote: > On 1月15日 月, chris wrote: >> On 1月16日 火, Sergey Trofimov wrote: >> > >> > Here you go: >> > ```sh >> > qtw=$(guix build qtwayland@6)/lib/qt6/plugins >> > QT_PLUGIN_PATH=$qtw QT_QPA_PLATFORM_PLUGIN_PATH=$qtw/platforms qutebrowser >> > -s qt.force_platform wayl

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

On Tue, Jan 16 2024, Sergey Trofimov wrote: >> Would this work with non-wayland users too? (So that it would make >> sense to add it to the main package?) >> >> Thanks, >> Clément > > Yeah, it would work, but forcing the platform through parameters is not > necessary. I added it just to be sure t

bug#68512: Qutebrowser 3, no sound from pipewire-only system

On Fri, Jan 26 2024, Sergey Trofimov wrote: > chris writes: > >> This attempt from the discussion here >> https://lists.gnu.org/archive/html/guix-devel/2021-03/msg00441.html >> >> ``` >> (define s (open-connection)) >> >> (display (derivation->output-path >> (package-derivation s pipewi

bug#46961: Nginx and certbot cervices don't play well togther

Hi Carlo, On Wed, Jan 24 2024, Carlo Zancanaro wrote: > * gnu/services/certbot.scm (): Add > start-self-signed? field. > (generate-certificate-gexp): New procedure. > (certbot-activation): Generate self-signed certificates when > start-self-signed? is #t. > * doc/guix.texi (Certificate services):

bug#46961: Nginx and certbot cervices don't play well togther

Also, I forgot, I think it would be great to have somewhere in the doc an example of minimal config.scm that works. I know we can't do proper testing because we depend of certbot service but that would make it easier for a lot of people to test it. Maybe such example is already in the docs and I

bug#46961: Nginx and certbot cervices don't play well togther

On Tue, Jan 30 2024, Carlo Zancanaro wrote: >>> + ;; Due to the way certbot runs, we need to >>> + ;; create the self-signed certificates in the >>> + ;; archive folder and symlink them into the live >>> + ;; folder. This mimics what certbot does wel

bug#46961: [PATCH v2 0/4] Make certbot play more nicely with nginx

On Tue, Jan 30 2024, Felix Lechner via Bug reports for GNU Guix wrote: > Hi Carlo, > > On Tue, Jan 30 2024, Carlo Zancanaro wrote: > >> certbot can't produce certificates without a functional nginx > > Yes, it can. The option is called --standalone. [1] > > Maybe another way to bootstrap the certi

bug#46961: Nginx and certbot cervices don't play well togther

I removed guix-devel, not sure we need to spam it. On Tue, Jan 30 2024, Carlo Zancanaro wrote: > +(define %default-deploy-hook > + (program-file > + "reload-nginx.scm" > + (with-imported-modules '((gnu services herd)) > + #~(begin > + (use-modules (gnu services herd)) > +

bug#46961: Nginx and certbot cervices don't play well togther

Removing guix-devel. On Tue, Jan 30 2024, Carlo Zancanaro wrote: > +(define (file-contains? file string) > + (string-contains (call-with-input-file file > + get-string-all) > + string)) > + > +(defi

bug#68831: gnu: torbrowser: noscript gets picked up by icecat

Hello André, On Tue, Jan 30 2024, André Batista wrote: > Hi guix! > > It seems that 'make-icecat-extension' is not sufficiently kosher. When > torbrowser and icecat are both installed to the same user profile, > noscript gets picked up by icecat too. The same also happens when > mullvadbrowser is

bug#46961: Nginx and certbot cervices don't play well togther

On Wed, Jan 31 2024, Carlo Zancanaro wrote: >>> + (< attempt 12)) ; 12 * 10 seconds = 2 minutes >> ^-- >> This comment is not true because certbot takes time to execute (around 15s >> on my vm). I don't

bug#68831: gnu: torbrowser: noscript gets picked up by icecat

On Wed, Jan 31 2024, André Batista wrote: > Hi Clément, > > qua 31 jan 2024 às 03:19:26 (1706681966), clem...@lassieur.org enviou: >> Hello André, >> >> I thought about it, and I even started working on a fix. But I stopped >> working on it because I thought it added too much complexity for too

bug#68894: Prosody guix service required fixes.

On Fri, Feb 02 2024, em...@msavoritias.me wrote: > Tried to write a system declaration that includes a prosody server. > > This bug aims to collect some bugs that were found and some features that > were needed during writing. > > 1. The opaque-prosody-configuration as used in this example > http

bug#68894: Prosody guix service required fixes.

On Sat, Feb 03 2024, em...@msavoritias.me wrote: > We could simplify it by a lot i think either way. Some ways could be: > > 1. Remove the opaque-configuration since it never worked for raw > content which does already. > > 2. Remove the ssl config section here > https://guix.gnu.org/en/manual/de

bug#69267: icedove.desktop has no StartupWMClass

Hello Damiano, On Mon, Feb 19 2024, Damiano Ognissanti wrote: > Sorry for the confusion, I copied the line from the wrong file. It should > obviously be > > StartupWMClass=icedove-default I think we should do: (setenv "MOZ_APP_REMOTINGNAME" "Icedove") StartupWMClass=Icedove Like we do with Ice

bug#70121: [PATCH] gnu: emacs-magit: Fix generation of autoloads.

On Mon, Apr 01 2024, Liliana Marie Prikler wrote: > * gnu/packages/emacs-xyz.scm (emacs-magit)[#:phases]: Replace ‘make-autoloads’ > like the others. > > Fixes: Magit autoloads are missing > --- Hi, Tested, looks good to me.

bug#70121: [PATCH] gnu: emacs-magit: Fix generation of autoloads.

On Wed, Apr 03 2024, Clément Lassieur wrote: > On Mon, Apr 01 2024, Liliana Marie Prikler wrote: > >> * gnu/packages/emacs-xyz.scm (emacs-magit)[#:phases]: Replace >> ‘make-autoloads’ >> like the others. >> >> Fixes: Magit autoloads are missing <ht

bug#70444: Broken Emoticons in Browsers

Hi Arne, On Thu, Apr 18 2024, "Dr. Arne Babenhauserheide" via Bug reports for GNU Guix wrote: > for more than a month now many emoticons are broken in my browsers. > > An example is https://www.draketo.de/wissen/klimalinks.html > I see ⚠, but I cannot see 💡 (though copying it into an Emacs buffe

<    1   2   3