bug#73169: wifi driver problem

Hello Fadi. On Guix System, wi-fi is a tough issue. Partial solutions are to either use cable instead of Wi-fi [1], to use a free Wi-fi adapter (not compatible with new Wi-fi standards), or, with obvious downsides, to use a non-free distribution of Guix or Linux (perhaps with only Guix Home inste

bug#72257: Non-English manuals for 1.4.0 are unavailable

The manual builds now. Closing. (I had miscalculated how long it takes, but thanks if someone intervened and initiated the build.) Regards, Florian

bug#72257: Non-English manuals for 1.4.0 are unavailable

Thank you Ludo, with your diff, building doc/build.scm failed previously and works for me now. I tested and pushed it to branch `version-1.4.0' yesterday evening. But mcron should have picked it up by now, but has not. Maybe someone could look at the logs? Or wait some more. Regards, Florian

bug#72257: Non-English manuals for 1.4.0 are unavailable

Could someone knowledgeable in maintenance.git in hydra/modules/sysadmin/web.scm change the guix-extensions to use an older guix package earlier than June 2024, such as guix version 1.4.0? I try ((options->transformation '((with-commit . "guix=v1.4.0"))) guix) but could it be made to get a guix@

bug#72257: Non-English manuals for 1.4.0 are unavailable

The easiest resolution would be to generally use an old 1.4.0 guix package in with-extensions, because the modules from a guix@1.4.0 still should work fine even for the latest devel manual (I have not tested, but autonomous guix/self.scm ignores the changed Makefile). Regards, Florian

bug#72257: Non-English manuals for 1.4.0 are unavailable

"pelzflorian (Florian Pelz)" writes: > The old manual as referred to in maintenance.git in > hydra/modules/sysadmin/web.scm was expected to build with the > guix/self.scm of old guix.git; it should not try to use po4a.cfg. The issue seems to be, maintenance.git in hydra/modul

bug#72257: Non-English manuals for 1.4.0 are unavailable

Hello all, I do not understand why these old manuals are built with po4a.cfg. Why does it not use old guix 1.4.0 to build old manual 1.4.0? po4a.cfg was added to guix.git in early June 2024 in commits starting from commit 2d4af5247057505956e841d396ec78af9f769837 Author: gemmaro Date: Sun Apr

bug#71523: [guix-artwork] Include Gottfried’s song "Guix"

Closing this ticket. Luis Felipe recommended the archive.org for long-term storage of fan-art [1], which should be appropriate for relevant-enough fan-art. Regards, Florian [1] https://lists.gnu.org/archive/html/help-guix/2024-06/msg00062.html

bug#71523: [guix-artwork] Include Gottfried’s song "Guix"

Hello all. As you may have read in help-guix, Gottfried has written and interpreted and shared under CC-BY-SA 4.0 a song about Guix [1][2][3]. I wish to ask Guix maintainers, would it be okay to upload it to guix-artwork.git? It is not just a tune; inevitably, the song has praise and opinions, un

bug#63680: long lines in cookbook in German language

Overlong lines past the page border should be fixed now with commit 9c3a8a380bcfebdb77af61532e7bfec523d7bde8. Thanks to Nigko Yerden for telling me ExecStart lines can be multi-line . Translations will be updated on Weblate soon.

bug#70954: No 'guix pull' substitutes for foreign distros?

Hello Nigko, I’m glad the problem is solved for you. >From testing old Guix System system generations, I believe September 2023’s new daemon feature “builtin:git-download” has caused the change in hashes, but no further action is advisable. I’m closing this bug. But I would like to know, does \

bug#70954: No 'guix pull' substitutes for foreign distros?

Hello Nigko, I can reproduce your bug by using Guix in a Debian testing VM, their Debian guix package, and get /gnu/store/2cl0dr63d900v6406hs10qgjsp7iaysi-guix-packages-base-modules.drv like you. The difference between bad (i.e. not substituted) /gnu/store/2cl0dr63d900v6406hs10qgjsp7iaysi-guix-pac

bug#70954: No 'guix pull' substitutes for foreign distros?

I had not understood that you used the --commit option, sorry for the misunderstanding. Foreign distros are not treated specially, but configuration for substitute authorization could be missing as described at the end of [1]. I do not believe they are missing though: Could you try “guix pull -q

bug#70954: No 'guix pull' substitutes for foreign distros?

Hello Nigko Yerden. You could definitely test if substitutes are never available if you used https://guix.gnu.org/manual/en/html_node/Channels-with-Substitutes.html which should guarantee that it will use a version of Guix where guix pull has substitutes. When not using channel-with-substitutes

bug#70663: nss@3.99 is really hard to build

Hello Christopher. Christopher Baines writes: > Had the changes waited for longer, then these failures should have been > spotted by QA, I would guess that the revision might have failed to be > processed, and if it was processed successfully, the nss failures should > have shown up, so maybe we

bug#70781: Same situation in GuixSD install

Hello Kristofer. Even though I do not understand at all how to get into such a state, it appears using an older guix has helped you before, so you could try running /var/guix/profiles/per-user/dev/current-guix--link/bin/guix instead of guix. Regards, Florian

bug#48907: Grafts cause discrepancies in debug symbols file names (debug symbols missing in GDB).

Hello all. Ludovic Courtès writes: >>> I wonder if we should revert 482fda2729c3e76999892cb8f9a0391a7bd37119. >>> It’s often not very helpful anyway (we often find ourselves downloading >>> unnecessary package outputs because of grafting). >> >> Hmm. Perhaps. But it'd also suck to have to downl

bug#70140: Missing ./doc/guix-cookbook.pt_BR.texi

Pushed as 74517806f80dab17474a3c5f0b91d437e4d4e052. I picked up some of your rewording and have changed the wording slightly to mention Automake, to make it more likely to be picked up by search engines when given the error. Thank you for being insistent. Regards, Florian

bug#70140: Missing ./doc/guix-cookbook.pt_BR.texi

Hello Rostislav. I do not know how to address the issue properly or where to document it. The Writing Documentation section is the wrong place, because everyone has to bootstrap again, not only the one who is writing documentation; if we put a notice somewhere, then it would be something like: di

bug#70140: Missing ./doc/guix-cookbook.pt_BR.texi

My apologies for not giving a good response. Yes, the issue you mention is indeed different from a record ABI mismatch, in that the error message for an ABI message says “recompilation needed” and is documented in the manual, unlike the problematic error message that you reported. Adding a note t

bug#70140: Missing ./doc/guix-cookbook.pt_BR.texi

Hello Rostislav, This advice would not be read by most affected Guix developers. The problem is that every guix developer must rerun ./bootstrap and ./configure on pulling certain changes like ABI breaks (when a new record is added) and new cookbook versions. Every Guix developer making a breaki

bug#69755: Issue trying to guix pull

Michael Ford writes: > It looks like rolling-back has resolved the problem now. > So this issue can be closed. Closing. Thank you! Regards, Florian

bug#69755: Issue trying to guix pull

Sorry, I forgot, you might need to roll back first, if you had pulled the broken in-between Guix revision. guix pull --roll-back I believe the in-between Guixes cannot be fixed. Thank you for reporting. Regards, Florian

bug#69755: Issue trying to guix pull

Hello Michael. Michael Ford writes: > building > /gnu/store/p9nimij8lz4yln5jd3gm0kdhirrwz56h-guix-1.4.0-18.4c94b9e-checkout.drv... > -suspicious ownership or permission on > `/gnu/store/bj2rp8ql9zxnv4l9gvlhph55fa241mk4-guix-1.4.0-18.4c94b9e-checkout'; > rejecting this build output > Backtrace:

bug#69123: Guix manual returns a 404 when trying to download FiraSans-Regular.ttf

Pushed as b7ccc5cb1b4ec936c00dbd98376c5d2677e60a63. The text in the manual should be less wide now. Regards, Florian

bug#47714: Cutting the internet in guix installation will stop the installation permanently (irreversible)

: "pelzflorian (Florian Pelz)" writes: > Does the same issue affect installing software with Guix on an already > installed system? If it only affects the installer, there might be a > valid issue with Guix’ cow-store service. Regards, Florian

bug#47714: Cutting the internet in guix installation will stop the installation permanently (irreversible)

bo0od writes: > Hi There, > > Try install guix with manual installation while its on the end step > (downloading things which mentioned in config.csm) cut the internet > off, It will not reback you to the terminal so that you can > repeat/relaunch the installation/downloading from where it stopped

bug#67038: Inconsistent use of space before ellipsis

Simon Tournier writes: > For consistency, I suggest the rule: ’word...’ and not ’word ...’ > > Something like the patch attached. +1 This is more consistent. Looking at the translation files in po/guix, only guix/status.scm:568 uses the space before ellipsis. The message "applying ~a graft" do

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

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

bug#65572: Black screen in installer

Hi Iku-Tulo, one more thing, could you confirm that `nomodeset` alone without video=uvesafb really is not enough? Regards, Florian

bug#65572: Black screen in installer

Hello Iku-Tulo, thank you for the report. Vilutar writes: > intelfb: Version 0.9.6 > intelfb: Cannot reserve FB region An unlikely guess: I have had problems with a black screen when using a television as a screen. However this does not sound like it. > Then I tried `nomodeset video=uvesafb` L

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

Maxim Cournoyer writes: > M-x texinfo-update-all-menus is available out-of-the-box in Emacs, when > visiting a .texi file (you invoke it via Alt-x texinfo-update-all-menus > or by visiting the 'Texinfo -> Update All Menus' menu). Oops my bad. I should have expected that Emacs commands are invisi

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

Hello Maxim, I never used M-x texinfo-all-menus-update before and do not know which package or output provides it. As I understand, presumably the PO4A / POXREF step of make was interrupted and therefore there are half-complete stray .de.texi files. Otherwise, the references would be translated o

bug#63921: Activation snippets in reverse order, prevent boot

David Wilson has described a way to fix this bug in Guix Regards, Florian

bug#64006: Installation frustration weekend

Denys Nykula writes: > but I still look at > it as a bug, Then it is a bug. Please go ahead and open a separate bug when you have time or preferably a patch when you have a fix. However, the console default font in gnu/services/base.scm is universal for all locales and really should keep suppor

bug#64006: Installation frustration weekend

"pelzflorian (Florian Pelz)" writes: >> Console fonts lose Cyrillic support after the first pull and upgrade. >> Question marks appear in place of my letters instead. > This sounds like a bug/regression; in the source code > <https://git.savannah.gnu.org/cgit/guix

bug#64006: Installation frustration weekend

Hi Denys! Sorry to hear, but thank you for writing which bugs still cause trouble with Guix System. I can say this: Denys Nykula writes: > Installation with a desktop environment (EXWM) started to "die > unexpectedly" every time when loading subtitutes, please see installer- > dump-790b17b6. N

bug#63977: Incorrect language tags in case of incomplete translations

Maxime Devos writes: > This French web page has an English blog post. This is OK, HTML > supports that. Just put a "lang="en"' attribute in the 'article' tag Done in c392a144df6c1e11ec5a672f7e2c00fbfc51f5bd. Thank you for the report! I do not have a screen reader to test though. Regards, Flo

bug#63975: Broken link (404) in blog post breadcrumbs

Pushed as bf07f52a57505c4b12fa6b384b79751e387ae624 with some changes; the change is effected in the post-url-path procedure now.

bug#63975: Broken link (404) in blog post breadcrumbs

Maxime Devos writes: > then click on the link ‘Parameterized Packages for GNU Guix’ in the > breadcrumbs ‘Home -> Blog -> Parameterized Packages for GNU Guix’. > > This goes to > > https://guix.gnu.org/blog/2023/parameterized-packages-for-gnu-guix > > which is a 404 Not Found. Thank you Maxime fo

bug#63921: Activation snippets in reverse order, prevent boot

Jelle is right, multiple (delete mingetty-service-type) is not useful. With more thought, what I imagined as more explicit is probably more like (delete "term-tty2") than (delete mingetty-service-type). Also I wouldn’t actually need it. And as Brian says, just use filter. modify-services need no

bug#63921: Activation snippets in reverse order, prevent boot

"pelzflorian (Florian Pelz)" writes: > "pelzflorian (Florian Pelz)" writes: >> Using clauses at most once broke the greetd example in the manual: > Jelle Licht already reported this on IRC, see the end of > <http://logs.guix.gnu.org/guix/2023-06-06.log> Cc Jelle Licht

bug#63921: Activation snippets in reverse order, prevent boot

"pelzflorian (Florian Pelz)" writes: > Using clauses at most once broke the greetd example in the manual: Jelle Licht already reported this on IRC, see the end of <http://logs.guix.gnu.org/guix/2023-06-06.log> Regards, Florian

bug#63921: Activation snippets in reverse order, prevent boot

Hi Ludo, hi all. Ludovic Courtès writes: > I ended up > rewriting ‘modify-services’. Good news is we now have tests for this. In the rewrite, you wrote: > +(define (apply-clauses clauses services) > + "Apply CLAUSES, an alist as returned by 'clause-alist', to SERVICES, a list > +of services.

bug#58880: 'guix gc' does not round the amount of disk space freed

Pushed both patches now. Sorry Remco it took so long. To patch 1, I added a copyright line for you; even though you changed little, maybe there still is copyright together with your other patches. To patch 2, I added a period in the commit message and made the same po file change also to the new

bug#63680: long lines in cookbook in German language

Gottfried writes: > "unreadable overlong lines is an issue with > the PDF version of the cookbook in any language". > "On first sight, it looks like complicated TeX tricks are needed to fix > this. I do not know." > says Felix Lechner It was me who wrote these sentences, Felix commented on somet

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

Hi Liliana and all. Until now the user could decide what image loaders to install alongside. Or so I thought. However, surprisingly I cannot get any other loader except gdk-pixbuf and librsvg to work anyway. That is, guix shell viewnior webp-pixbuf-loader surprisingly does not see webp files.

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

Nathan Dehnel writes: > Yes, that one works That’s good. This means maybe either - if guix shell without --pure works too, you just have not run “guix upgrade” recently, or - --pure helped and viewnior is not compatible with the Adwaita dark theme, or - --pure helped because you have mi

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

Nathan, could you try running this command: guix shell --pure viewnior gdk-pixbuf -- viewnior For me this works now. My guess is that for you, something else breaks viewnior and --pure can help. Regards, Florian

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

Hi all. Josselin Poiret via Bug reports for GNU Guix writes: > For > that, we use the environment variable GDK_PIXBUF_MODULE_FILE, which is a > search-path for the package gdk-pixbuf, meaning that it is set only if > gdk-pixbuf is installed in your profile. […] So > we should fix this and propag

bug#58880: [PATCH v2 2/2] nls: Update translation keys for guix gc

Remco van 't Veer writes: > * po/*/*.po (guix/scripts/gc.scm): Round MiBs in user feedback. Thank you Remco for not breaking translations, which is nice to users. But note that usually committers just ignore that the translations stay broken for a while and that is more feasible for developers an

bug#60207: ci build of latest guix for armhf

Julius Schwartzenberg writes: > Op 24-12-2022 om 22:40 schreef pelzflorian (Florian Pelz): >> If you want `guix pull` without compiling, then look at >> <https://guix.gnu.org/en/manual/devel/en/html_node/Channels-with-Substitutes.html>. > > I added the lines

bug#60207: Bug report

Hello Julius. Julius Schwartzenberg writes: > I didn't imagine > I would need to do a 'guix pull' after running it. It seems I ran it > at a bad moment, just as 1.4.0 was about to be released. Indeed, but upgrading without compiling will be easier with bordeaux. (Probably it would also have been

bug#60207: Bug report

Julius Schwartzenberg writes: > Op 20-12-2022 om 10:34 schreef pelzflorian (Florian Pelz): >> does it work if you do this before pull? >> sudo guix archive --authorize < $(dirname $(which >> guix))/../share/guix/bordeaux.guix.gnu.org.pub > > When I do this, I get:

bug#60164: bug#60165: [1.4.0rc2] Installer doesn't properly render some non-Latin glyphs

Ludovic Courtès writes: > "pelzflorian (Florian Pelz)" skribis: >> is it too late to replace by font-gnu-unifont to fix CJK fonts? > Oh sure. Could you send a patch? Pushed as bbd11199e6856ded8d75468a16789715b6817b45. > That’ll be in the next release… It is

bug#60207: Bug report

Hello Julius, does it work if you do this before pull? sudo guix archive --authorize < $(dirname $(which guix))/../share/guix/bordeaux.guix.gnu.org.pub Then it would compile fine on the bordeaux build farm and you could download the substitute from there. Regards, Florian

bug#59784: [version 1.4.0rc1] Retrying a failed install fails

"pelzflorian (Florian Pelz)" writes: > * If I resume a crashed installer, I need to resume twice because the > first resume always fails immediately. Hooray, you fixed it. Ludo, your debugging speed is miraculous. I did not know SQLite uses multiple files per database. &

bug#60164: GNU Guix 1.4.0rc2 available for testing!

"pelzflorian (Florian Pelz)" writes: > is it too late to replace by font-gnu-unifont to fix CJK fonts? Sorry, it is not urgent. CJK translations are very incomplete anyway. This can wait for later releases. Still, I have reopened the bug. Regards, Florian

bug#60164: GNU Guix 1.4.0rc2 available for testing!

Hi Ludo, is it too late to replace by font-gnu-unifont to fix CJK fonts? Regards, Florian

bug#59784: [version 1.4.0rc1] Retrying a failed install fails

Ahoi. :) Ludovic Courtès writes: >> Now that you found the dynamic-wind’s out-guard does not even run: > It does not run on C-c, but it does run in other cases, typically if you > just press Enter after reading the message that says “command failed, > press Enter”. Ahh. Then would it be good if

bug#59784: [version 1.4.0rc1] Retrying a failed install fails

Ludovic Courtès writes: > The error message that’s haunting us: > > opening file `/gnu/store/….drv': No such file or directory > > comes from guix-daemon. It happens while the client is doing an > ‘add-text-to-store’ RPC to add that .drv to the store. > ‘LocalStore::addTextToStore’ supposedly c

bug#59784: [version 1.4.0rc1] Retrying a failed install fails

Ludovic Courtès writes: > One finding: when hitting C-c, the dynamic-wind exit handler (the one > that restores the database and umounts the cow store) is *not* executed. Impressive findings. Now that you found the dynamic-wind’s out-guard does not even run: Uhh I had misdiagnosed when I thought

bug#59784: [version 1.4.0rc1] Retrying a failed install fails

Maxime Devos writes: > So, I'm nominally 'on hiatus', but I noticed this mail, and noticed > you copied a file (and fsync'ed it), but forgot to fsync the directory > it was copied to -- from what I've read (but I don't recall the > source), fsyncing the contents of the file isn't enough, you also

bug#60010: [version 1.4.0] AMD screen stays black; modprobe fails

Ludovic Courtès writes: > I ended up with a minimal change, > pushed in commit b1aef25453067004279c4267cf25e8d6d365890d, that lets > modprobe load uvesafb for good (it was all about setting > ‘LINUX_MODULE_DIRECTORY’). Thank you Ludo for your excellent work. All is good now on AMD hardware (my l

bug#60002: installer console garbled on 1984.is VPS

Attila Lendvai writes: > their response: "I changed the video mode in libvirt to virtio instead of the > default cirrus." Yes yes, now that you mention cirrus, yhetil.org turns up results: https://issues.guix.gnu.org/36069 Could you test that patch maybe? Well of course it would maybe require

bug#59784: [version 1.4.0rc1] Retrying a failed install fails

Desperately I tried also adding fsync, to no avail, both issues remain. Non-working patch attached. Maybe dynamic-wind is an inappropriate pattern here? If I interrupt installation using Ctrl-C (which I normally don’t, instead I unplug Ethernet), then I have to press Ctrl-C twice. Maybe that cou

bug#59784: [version 1.4.0rc1] Retrying a failed install fails

Hi Ludo… Ludovic Courtès writes: > This time, I believe we only ever copy the database when we’re sure no > guix-daemon process is accessing it. Failure. In addition to your partially helpful patch from before (with which a second resume now works most of the time), I now tried further the new

bug#60010: [version 1.4.0] AMD screen stays black; modprobe fails

Hello Ludo, sorry to say I attempted your modprobe patch that uses (parameterize ((default-environment-variables … No good. Screen is black. Same [ modprobe ] failure in dmesg on QEMU and on real AMD hardware. There are workarounds by surrounding modprobe within strace or alternatively using ke

bug#59784: [version 1.4.0rc1] Retrying a failed install fails

"pelzflorian (Florian Pelz)" writes: > I shall try with fsync now. fsyncing the database had no effect. (In addition to Ludo’s 'stop-service', I had done diff --git a/gnu/installer/final.scm b/gnu/installer/final.scm index ef487805f0..13deffef85 100644 --- a/gnu/instal

bug#60010: [version 1.4.0] AMD screen stays black; modprobe fails

Ludovic Courtès writes: > Do you see hints as to whether uvesafb gets loaded? > > You can do that by adding “console=ttyS0” to the kernel arguments and by > passing ‘-serial stdio’ to QEMU. This serial output shows nothing about uvesafb, but dmesg contains about uvesafb exactly the same modprobe

bug#59784: [version 1.4.0rc1] Retrying a failed install fails

Eventual success, partially. First of all: Ludovic Courtès writes: > "pelzflorian (Florian Pelz)" skribis: >> Additionally, I had to do “GUIX_ALLOW_ME_TO_USE_PRIVATE_COMMIT=y >> make update-guix-package”. Or else the installer was using a Guix that >> did no

bug#59784: [version 1.4.0rc1] Retrying a failed install fails

Hi again. Ludovic Courtès writes: > So my guess is that things will be much better if we swap these two > lines. This was helpful, but not enough. Swapping them may have improved the likelihood of being able to retry, but the issue is still there. I uploaded as installer-dump-5f9f8dbe, but it

bug#60010: [version 1.4.0] AMD screen stays black; modprobe fails

"pelzflorian (Florian Pelz)" writes: > I will next try using 'load-linux-modules-from-directory' and no > modprobe. I tried the attached patch. Doesn’t work, still black (in QEMU). Says the dmesg: > [ 11.183789] shepherd[1]: Service user-homes has been started

bug#60010: [version 1.4.0] AMD screen stays black; modprobe fails

Ludovic Courtès writes: > Specifically, here’s the minimal change we should test:[…] > +(unless (file-exists? "/dev/fb0") > + (setenv "LINUX_MODULE_DIRECTORY" > + "/run/booted-system/kernel/lib/modules") Thanks for the patch.

bug#60010: [version 1.4.0] AMD screen stays black; modprobe fails

Thank you Josselin. Josselin Poiret writes: > I don't think there's a race issue with the files being available: Yes apparently, but it is some kind of race. BTW it happens on master branch too despite its more recent linux. > By the way, why is the modprobe binary inside a #+? The target wil

bug#60002: installer console garbled on 1984.is VPS

Hello Attila. So the admins are using a Web interface to QEMU. Which one? What -vga option is it using? Perhaps when in GRUB, press E to edit the linux boot command-line and append to it: nomodeset IIRC there had been discussions about QEMU Bochs graphics and such, but I can’t find them. > ma

bug#60010: [version 1.4.0] AMD screen stays black; modprobe fails

Just now I tried the installer on an AMD desktop but the graphical installer screen stays black. Same on an AMD laptop. After switching to another TTY, dmesg tells me this: > [ 11.625264] shepherd[1]: Service host-name has been started. > [ 11.625839] shepherd[1]: Service user-homes has been

bug#59784: [version 1.4.0rc1] Retrying a failed install fails

"pelzflorian (Florian Pelz)" writes: > shepherd: Service guix-daemon has been stopped. > shepherd: Service guix-daemon has been started. > guix system: Fehler: opening file > `/gnu/store/4z81a7njyvnwa4kn46ad6vhvi0lcnrhh-shadow-4.9.drv': No such > file or directory &

bug#59784: [version 1.4.0rc1] Retrying a failed install fails

Ludovic Courtès writes: > I tried to reproduce it: > > 0. I chose a basic installation to a fully-encrypted disk with a > single partition. > > 1. I hit Ctrl-C while ‘guix system init’ was downloading substitutes. > > 2. That led me to a confusing error screen says “Command cryptsetup >

bug#59781: bug#50892: [PATCH] guix-install.sh: Authorize all project build farms at once.

Ludovic Courtès writes: > If there are no objections I’d like to push to ‘master’ and > ‘version-1.4.0’ this modified version of your patch. Thank you two, this patch works (on 1.3.0 only ci.guix.gnu.org, on 1.4.0rc1 also bordeaux, except when I decline authorization). Regards, Florian

bug#59783: [version 1.4.0rc1] Suggested window managers don't work out of the box

Oops yes. Ratpoison even displays instructions to get help in a corner. C-t C-c works fine (after running `guix build xterm`). Openbox works fine when right clicking the black screen. No bug here. Closing. Regards, Florian

bug#59782: [version 1.4.0rc1] Add r8169 to unsupported hardware

Having the installer show a warning here would *not* be appropriate. These r8169 issues are so rare, I haven’t met one since. Even though I believe the r8169 Ethernet was at fault, and guix substitute freezing also had happened to me in the past with it, and even though Linux-libre reports it as

bug#58239: version1.4.0rc1 Installer ISO missing mkfs.ext4

This will be resolved by patch#59661. And my mail was tactless. Sorry, Tobias. Closing. Regards, Florian

bug#58239: version1.4.0rc1 Installer ISO missing mkfs.ext4

reopen 58239 thanks Huh, I thought it was fixed, but with the 1.4.0rc1 installer image: mkfs.ext4 is missing, but is needed for manual installation as described in the manual. e2fsprogs is in /gnu/store though; I can run the binaries in its sbin directory. The installer is among the `guix gc --r

bug#59781: [version 1.4.0rc1] install.sh script should authorize bordeaux

Tobias Geerinckx-Rice writes: > If you mean guix-install.sh: Yes I mean guix-install.sh. :) Regards, Florian

bug#59780: [version 1.4.0rc1] reconfigure fails

Tobias Geerinckx-Rice writes: > pelzflorian (Florian Pelz) 写道： >> Having installed the 1.4.0rc1 installer image: After guix pull, it >> failed to reconfigure, because master is an unrelated commit. > > Hah. This should indeed be mentioned in calls for -RC testing, but >

bug#59784: [version 1.4.0rc1] Retrying a failed install fails

I aborted graphical system installation (Ctrl-C), retried the installation and got this: shepherd: Service guix-daemon has been stopped. shepherd: Service guix-daemon has been started. guix system: Fehler: opening file `/gnu/store/4z81a7njyvnwa4kn46ad6vhvi0lcnrhh-shadow-4.9.drv': No such file or

bug#59783: [version 1.4.0rc1] Suggested window managers don't work out of the box

Once there was a commit commit 3ad3c55842dd34adc4b1a1b65ba0abfbdf5b92ee Author: Ludovic Courtès Date: Wed Apr 17 00:27:04 2019 +0200 installer: Desktop environment page now includes window managers. * gnu/installer/services.scm ()[snippet]: Change to be a list of sexps and add

bug#59782: [version 1.4.0rc1] Add r8169 to unsupported hardware

Installation (guix substitute) sometimes gets stuck on my Beebox mini PC with r8169 Ethernet controller. For the x86_64 graphical installer, I selected everything. After it had downloaded plenty of other substitutes, installation printed this and got stuck: substitute: Liste der Substitute von „h

bug#59781: [version 1.4.0rc1] install.sh script should authorize bordeaux

Could you make install.sh add bordeaux to /etc/guix/acl? It is important especially on ARM. Regards, Florian

bug#59780: [version 1.4.0rc1] reconfigure fails

Having installed the 1.4.0rc1 installer image: After guix pull, it failed to reconfigure, because master is an unrelated commit. Regards, Florian

bug#59717: ‘guix’ package fails to build on armhf-linux (OOM)

Ludovic Courtès writes: > [ 76%] GUILEC gnu/packages/uucp.go > [ 76%] GUILEC gnu/packages/valgrind.go > [ 76%] GUILEC gnu/packages/version-control.go > [ 76%] GUILEC gnu/packages/video.go > GC Warning: Failed to expand heap by 67125248 bytes > GC Warning: Failed to expand heap by 67108864

bug#59463: [doc] More foolproof command in https://guix.gnu.org/cookbook/en/html_node/Reproducible-profiles.html

Thanks for reporting in time for the 1.4.0 release of the cookbook. :) Fixed in 39f88ee29faa98d0b9b9761f2db8dc7721200fe5. Regards, Florian

bug#36786: Warn of AMD GPUs unusable with Guix System

pelzflorian (Florian Pelz) wrote on 26 Jul 2019 22:03 > I would rather see a more prominent link to the manual and h-node > where on the downloads page it says “runs on i686, x86_64, ARM”, > because I suppose many people do not read the manual until they know > they need to, and in

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

close 58760 thanks Thank you all for your responses. But I have closed the issue (without really trying the methods) because Tobias writes: > But we can go deeper if we choose to, by dropping zisofs and going for > something like squashfs, which achieves higher compression through > higher block

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

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

bug#58571: translations are incompletely pulled from weblate

Julien Lepiller writes: > One thing I suspect is that weblate takes quite a lot of time to pull > changes from the intermediate repository, so if you provide a > translation while the repo is being synced, I think they might be > reset when the file is finally loaded by weblate. Something similar

bug#58571: translations are incompletely pulled from weblate

two--- via Bug reports for GNU Guix writes: > hi > in https://git.savannah.gnu.org/cgit/guix.git/tree/po/guix/uk.po i see > kyrylo's translations are pulled there from weblate, but mine > (https://translate.fedoraproject.org/changes/?project=guix&lang=uk&user=two22) > are not, these strings stay u

bug#58444: Make gtk use librsvg on aarch64 again.

close 58444 thanks "pelzflorian (Florian Pelz)" writes: > "pelzflorian (Florian Pelz)" writes: >> I wrote a patch but probably it would rebuild the world. > It does rebuild the world. I will try with (or (target-aarch64?) >

bug#58444: Make gtk use librsvg on aarch64 again.

"pelzflorian (Florian Pelz)" writes: > I wrote a patch but probably it would rebuild the world. It does rebuild the world. I will try with (or (target-aarch64?) (target-x86-64?)). Regards, Florian

  1   2   3   4   5   6   >