bug#48373: vice: processor dependency?
Hi, when I install vice from guix, and attempt to run a ROM, I get this error, and the GUI does not launch: Illegal instruction However, if I pull the source with `guix -S vice', create a build environment with `guix environment vice', and build it myself (with ./configure --prefix=/home/christopher/local --disable-pdf-docs) and then run the ROM, vice GUI opens up and the ROM runs without trouble. As a guess, I suspect your build made use of some advanced multimedia CPU flag not available on my computer. I am not very knowledgeable in C debugging, but gdb gave this backtrace: Thread 10 "x64sc" received signal SIGILL, Illegal instruction. [Switching to Thread 0x7fffce3fd700 (LWP 2511)] 0x00641a61 in reSID::WaveformGenerator::WaveformGenerator() () (gdb) bt #0 0x00641a61 in reSID::WaveformGenerator::WaveformGenerator() () #1 0x00641982 in reSID::Voice::Voice() () #2 0x0063e017 in reSID::SID::SID() () #3 0x00531f5f in resid_open () #4 0x0043db9d in sound_open () #5 0x0043eb85 in sound_flush () #6 0x0044315e in vsync_do_end_of_line () #7 0x005a70a3 in vicii_raster_draw_handler () #8 0x0059eedd in vicii_cycle () #9 0x0045221d in maincpu_mainloop () #10 0x00430244 in vice_thread_main () #11 0x7693af64 in start_thread () from /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc- 2.31/lib/libpthread.so.0 #12 0x7686c9af in clone () from /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6 Here is my system information: christopher@nightshade ~$ neofetch --stdout christopher@nightshade -- OS: Guix System 87b4b0e4385149b40ee87ae2d57712679452746b x86_64 Host: GA-880GM-UD2H Kernel: 5.11.19-gnu Uptime: 15 mins Packages: 105 (guix-system), 92 (guix-user) Shell: bash 5.0.16 Resolution: 1920x1200 DE: GNOME 3.34.5 Theme: Adwaita [GTK2/3] Icons: Adwaita [GTK2/3] Terminal: kitty CPU: AMD Athlon II X3 455 (3) @ 3.300GHz GPU: NVIDIA GeForce 8400 GS Rev. 3 Memory: 842MiB / 7959MiB Host: GA-880GM-UD2H Kernel: 5.11.19-gnu Uptime: 15 mins Packages: 105 (guix-system), 92 (guix-user) Shell: bash 5.0.16 Resolution: 1920x1200 DE: GNOME 3.34.5 Theme: Adwaita [GTK2/3] Icons: Adwaita [GTK2/3] Terminal: kitty CPU: AMD Athlon II X3 455 (3) @ 3.300GHz GPU: NVIDIA GeForce 8400 GS Rev. 3 Memory: 842MiB / 7959MiB christopher@nightshade ~$ cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 16 model : 5 model name : AMD Athlon(tm) II X3 455 Processor stepping: 3 microcode : 0x1c8 cpu MHz : 800.000 cache size : 512 KB physical id : 0 siblings: 3 core id : 0 cpu cores : 3 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt hw_pstate vmmcall npt lbrv svm_lock nrip_save bugs: tlb_mmatch apic_c1e fxsave_leak sysret_ss_attrs null_seg amd_e400 spectre_v1 spectre_v2 bogomips: 6629.32 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate processor : 1 vendor_id : AuthenticAMD cpu family : 16 model : 5 model name : AMD Athlon(tm) II X3 455 Processor stepping: 3 microcode : 0x1c8 cpu MHz : 800.000 cache size : 512 KB physical id : 0 siblings: 3 core id : 1 cpu cores : 3 apicid : 1 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt hw_pstate vmmcall npt lbrv svm_lock nrip_save bugs: tlb_mmatch apic_c1e fxsave_leak sysret_ss_attrs null_seg amd_e400 spectre_v1 spectre_v2 bogomips: 6629.32 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate processor : 2 vendor_id : AuthenticAMD cpu family : 16 model : 5 model name : AMD Athlon(tm) II X3 455 Processor stepping: 3 microcode : 0x1c8 cpu MHz :
bug#48266: support dynamic loading of modules from initrd
On 2021-05-11, Ludovic Courtès wrote: > Vagrant Cascadian skribis: > >> Initially, I tried adding just the obviously mmc related modules, but >> this gave me guile prompt from the initramfs as it failed to find the >> rootfs. Notably, even with the above list, I still need to explore >> additional modules to load in order to get the display and keyboard to >> work from the initramfs, in case I wanted to use this with encrypted >> rootfs... >> >> The above list of modules could almost certainly be trimmed, but even >> getting a bootable system for pinebook pro took about 20 tries, and the >> process of defining the modules is further complicated by several >> factors... >> >> * The filesystem names of the modules (e.g. dw_mmc-pltfm) do not >> necessarily match the runtime name from lsmod (e.g. dw_mmc_pltfm). >> This becomes a good deal of trial and error to figure out which >> modules to add. >> >> * One needs to manually resolve the soft and hard dependencies of the >> modules, and ensure they are loaded, and include them in the list. >> >> * If upstream changes the module name (which does happen from time to >> time), you have to update the system config.scm to the new module >> names. >> >> * If some functionality changes from a module to a built-in, or >> vice-versa, the system config.scm needs manual updating. >> >> * Switching system between two different arm boards potentially requires >> entirely different lists of modules. > > Note that ‘guix system init’, ‘reconfigure’, and ‘deploy’ error out if > drivers for a storage device are missing (see > ‘check-device-initrd-modules’). Yes, I often have to tell it to skip those checks when using 'guix system init', as I'm installing to a microSD card by way of a usb-to-microSD adapter, and it guesses all the wrong modules. > Now, that doesn’t help if you’re using ‘guix system image’, which > perhaps is what you were doing? I wonder how we could take advantage of > that code in such a scenario. I sometimes do 'guix system image' for the initial pass, and then follow-up with init or reconfigure... >> Rather than handling modules one at a time, I would propose to at least >> add an option that can add whole directory trees of modules to the >> initrd (e.g. kernel/drivers/usb/)... and then use modprobe (or udev?) >> to handle the dependencies. Maybe opt-in at first, but longer-term, >> explore making it default? > > I remember Danny and I worked on something along these lines in the past > but it didn’t completely materialize (some of the machinery is already > here, though). That said, we still wouldn’t want to include too much in > the initrd, would we? Notably, at the moment it loads various virtio modules on all my baremetal systems, which is a bit uneccesary. :) Honestly, when debugging support for a new arm system, I'm of the opinion that more is better than less, as it takes way too many iterations to get to a working modular configuration. So at least an option to include even the kitchen sink drivers would be nice. :) live well, vagrant signature.asc Description: PGP signature
bug#48331: Emacs' describe-package doesn't work for packages managed by guix
> the "-pkg\\.el$" exclude might have existed for a reason > (I don't know which, put perhaps byte compilation). Perhaps it should be ignored during byte compilation, but still installing it seems to be a good idea. Ok, let's wait for Maxim answer. > I know people take package.el for granted nowadays, but alternative > package managers for Emacs have their uses. This is not just a Guix > thing :) Why not take it for granted?) It's built-in since 24(?), elpa/melpa archives respect it format and provide package descriptions in -pkg.el format, AFAIK. Most other package managers seem to respect "infrastructure" provided by package.el. For example you can view a list of packages with `list-packages` even for packages installed with other PMs (Nix for example), BTW they keep "package.el" directory structure. https://0x0.st/-BxL.txt Don't see too many reasons not to follow this format. I mean it's easily fixable with current directory structure just by stripping "/elpa" suffix from package-directory-list, but why we would do that emacs "customization" instead of just placing packages under /elpa subdirectory and make everything work out of the box? > I don't think we want to fake elpa that hard. Two iterations ago it > was .guix.d and people didn't really like it. Do you mean the package installation path was site-lisp/.guix.d/NAME-VERSION? > My subdirs.el patch is also stretching it. Not sure what you mean by this, sorry, I'm not native speaker and automated translation doesn't make sense to me. Rephrase please. I do not insist on any particular directory structure, just curious why not to stick to the widely adopted format. Once again, thank you for placing packages into subdirectories, now the site-lisp structure seems more organized and less polluted + problem with describe-package (C-h P) and list-packages are easily fixable. Appreciate your work!) -- Best regards, Andrew Tropin
bug#48343: Cannot boot after installation
Hi Sergey, Sergey Petrov skribis: > Hm, I've added these lines to the etc/config.scm, tried to boot again > and it doesn't seem to change anything... Note that /etc/config.scm doesn’t have any effect in itself. You need to run ‘guix system reconfigure /etc/config.scm’ to deploy the changes you made. HTH, Ludo’.
bug#48240: “guix copy” to host with daemon listening on TCP fails
Bone Baboon skribis: > Ludovic Courtès writes: >> Fixed in da28efef36af8925bcd9e40a81cbf552cf8c2d02. Let me know if it >> works for you! > > This commit appears to have fixed a problem with guix copy that I was > having yesterday. I was getting this error "guix copy: error: failed to > connect over SSH to daemon at '', socket > /var/guix/daemon-socket/socket". > > Now I can successfully run guix copy. Thanks for confirming!
bug#48335: Emacs is broken
Hi, Xinglu Chen skribis: > The ‘emacs’ package seems to be broken, I can reproduce this with > > guix time-machine --commit=87b4b0e4385149b40ee87ae2d57712679452746b -- \ > environment --pure --ad-hoc emacs -- emacs --version > /gnu/store/as4fpcyq6qjngp6433w68v09x5znhh10-profile/bin/emacs: error while > loading shared libraries: libm17n-core.so.0: cannot open shared object file: > No such file or directory > > The latest “good” commit I know of is > ee86a035c79b838e3fdabbdb88dc30906a83cc30 (still bisecting). I wondered if this could be a missed reference issue due to grafting (whereby a recent ‘guix gc’ would have deleted m17n-lib from the store because the grafted Emacs didn’t have a visible reference to it) but that doesn’t seem to be the case (on x86_64-linux): --8<---cut here---start->8--- $ guix time-machine --commit=87b4b0e4385149b40ee87ae2d57712679452746b -- build emacs /gnu/store/d0r7zcph1f3y0cahp9yv5hs8rhi9hcig-emacs-27.2 $ ldd /gnu/store/d0r7zcph1f3y0cahp9yv5hs8rhi9hcig-emacs-27.2/bin/.emacs-27.2-real |grep m17n libm17n-core.so.0 => /gnu/store/pdwv15zmghndkqy5473v1hxgibmvzvlz-m17n-lib-1.8.0/lib/libm17n-core.so.0 (0x7f6800d1d000) libm17n-flt.so.0 => /gnu/store/pdwv15zmghndkqy5473v1hxgibmvzvlz-m17n-lib-1.8.0/lib/libm17-flt.so.0 (0x7f6800d11000) $ guix gc -R /gnu/store/d0r7zcph1f3y0cahp9yv5hs8rhi9hcig-emacs-27.2 |grep pdwv15zmghndkqy5473v1hxgibmvzvlz /gnu/store/pdwv15zmghndkqy5473v1hxgibmvzvlz-m17n-lib-1.8.0 --8<---cut here---end--->8--- Does passing ‘--no-grafts’ to ‘environment’ make a difference for you? Thanks, Ludo’.
bug#48331: Emacs' describe-package doesn't work for packages managed by guix
Hi, Andrew Tropin skribis: > M-x list-packages ;; Doesn't list treemacs Let me recommend Emacs-Guix (aka. ‘guix.el’) as a superior alternative. :-) I think it’s fine that ‘package.el’ is unaware of Guix-managed software and vice-versa. Ludo’.
bug#48266: support dynamic loading of modules from initrd
Hi! Vagrant Cascadian skribis: > Initially, I tried adding just the obviously mmc related modules, but > this gave me guile prompt from the initramfs as it failed to find the > rootfs. Notably, even with the above list, I still need to explore > additional modules to load in order to get the display and keyboard to > work from the initramfs, in case I wanted to use this with encrypted > rootfs... > > The above list of modules could almost certainly be trimmed, but even > getting a bootable system for pinebook pro took about 20 tries, and the > process of defining the modules is further complicated by several > factors... > > * The filesystem names of the modules (e.g. dw_mmc-pltfm) do not > necessarily match the runtime name from lsmod (e.g. dw_mmc_pltfm). > This becomes a good deal of trial and error to figure out which > modules to add. > > * One needs to manually resolve the soft and hard dependencies of the > modules, and ensure they are loaded, and include them in the list. > > * If upstream changes the module name (which does happen from time to > time), you have to update the system config.scm to the new module > names. > > * If some functionality changes from a module to a built-in, or > vice-versa, the system config.scm needs manual updating. > > * Switching system between two different arm boards potentially requires > entirely different lists of modules. Note that ‘guix system init’, ‘reconfigure’, and ‘deploy’ error out if drivers for a storage device are missing (see ‘check-device-initrd-modules’). Now, that doesn’t help if you’re using ‘guix system image’, which perhaps is what you were doing? I wonder how we could take advantage of that code in such a scenario. > Rather than handling modules one at a time, I would propose to at least > add an option that can add whole directory trees of modules to the > initrd (e.g. kernel/drivers/usb/)... and then use modprobe (or udev?) > to handle the dependencies. Maybe opt-in at first, but longer-term, > explore making it default? I remember Danny and I worked on something along these lines in the past but it didn’t completely materialize (some of the machinery is already here, though). That said, we still wouldn’t want to include too much in the initrd, would we? Thanks, Ludo’.
bug#48331: Emacs' describe-package doesn't work for packages managed by guix
Am Dienstag, den 11.05.2021, 21:55 +0300 schrieb Andrew Tropin: > > the "-pkg\\.el$" exclude might have existed for a reason > > (I don't know which, put perhaps byte compilation). > > Perhaps it should be ignored during byte compilation, but still > installing it seems to be a good idea. Ok, let's wait for Maxim > answer. I think we agree on that. > > I know people take package.el for granted nowadays, but alternative > > package managers for Emacs have their uses. This is not just a > > Guix thing :) > > Why not take it for granted?) It's built-in since 24(?), elpa/melpa > archives respect it format and provide package descriptions in > -pkg.el format, AFAIK. el-get[1] is still active. straight.el[2] is another package manager for Emacs, its README comparing 5+1 approaches for package mangers, including el-get and package.el. Those are very much wild lands, I say. Not to speak for all the distro-specific ways of handling things. Gentoo had (and probably still has) an overlay, that magically creates Gentoo packages from elpa – in which of course they drop the -pkg.el. Debian has a mix of elpa packages and non-elpa ones, some of which naturally don't have the -pkg.el either. (Also their packages use site-lisp/elpa-src instead of site-lisp/elpa). Arch also seems to install at least some Elisp packages "directly" in site-lisp/$PACKAGE. > Most other package managers seem to respect "infrastructure" provided > by package.el. I don't think that statement is well-supported by the data we have. > Don't see too many reasons not to follow this format. > > I mean it's easily fixable with current directory structure just by > stripping "/elpa" suffix from package-directory-list, but why we > would do that emacs "customization" instead of just placing packages > under /elpa subdirectory and make everything work out of the box? Why should we let ELPA dictate our layout? I have not even once tried customizing package.el for actual use since I got Guix, because the elpa importer is trivial. > > I don't think we want to fake elpa that hard. Two iterations ago > > it was .guix.d and people didn't really like it. > > Do you mean the package installation path was site-lisp/.guix.d/NAME- > VERSION? Yep, that was a kinda ELPA-y convention while also remaining more true to what we're doing. > > My subdirs.el patch is also stretching it. > > Not sure what you mean by this, sorry, I'm not native speaker and > automated translation doesn't make sense to me. Rephrase please. The patch, which I've made, that adds subdirs.el is not uncontroversial. > I do not insist on any particular directory structure, just curious > why not to stick to the widely adopted format. Once again, thank you > for placing packages into subdirectories, now the site-lisp structure > seems more organized and less polluted + problem with describe- > package (C-h P) and list-packages are easily fixable. Appreciate > your work!) I hope I've shed some light as to how "wide" this adoption actually is – Emacs users are a contentious people. Just because something is "the default" and enjoys being shipped with Emacs itself doesn't mean that everyone is happy with it. Thus we're not trying to keep in line with any specific package manager, we just need to make things work "with Emacs" in the sense that packages installed via Guix should have working autoloads and one should be able to (require ...) them. Regards, Leo [1] https://github.com/dimitri/el-get [2] https://github.com/raxod502/straight.el
bug#48343: Cannot boot after installation
Hm, I've added these lines to the etc/config.scm, tried to boot again and it doesn't seem to change anything... On 5/11/21 8:48 PM, Bone Baboon wrote: Sergey Petrov writes: Hi! I've installed ordinary guix system following graphical installer, but can't boot it, here what I got after installation complete: GC Warning: pthread_getattr_pp or pthread_attr_getstack failed for main thread GC Warning: Couldn't read /proc/stat Welcome, this is GMU's early boot Guile. Use '--repl' for an initrd REPL. loading kernel modules... /dev/nvme0n1p8: clean, 134898/5169152 files, 1320485/20649216 blocks loading '/gnu/store/519yr5adx95d26s3nu65mjOcc9731630-system/boot... making '/gnu/store/519yr5adx95d26s3nu65mj0cc9731630-system' the current system... setting up setuid programs in '/run/setuid-programs'... populating /etc from /gnu/store/d6k3c7p2s6ji0ix2g3lafx4iwOd43a98-etc... error in finalization thread: Success [ 3.049660] udevd[272]: no sender credentials received, message ignored [ 3.098019] sp5100-tco sp5100-tco: Watchdog hardware is disabled [ 3.104103] Error: Driver 'pcspkr' is already registered, aborting... [ 3.180575] kvm: disabled by bios At this point computer hangs infinitely, and if I enable CPU virtualization in BIOS it starts to hang at line "[ 3.104103] Error: Driver 'pcspkr' is already registered, aborting..." I ran into a similar issue with a computer I installed Guix on. It would not complete the boot up process. I am not sure if I was experiencing the same issue you are as I did not submit it to a Guix mailing list. I got help solving it on #guix. What worked for me was to add the Linux kernel argument `nomodeset` to my system configuration. In the operating system declaration of the system configuration I added: ``` (kernel-arguments (append (list "nomodeset") %default-kernel-arguments)) ```
bug#48331: Emacs' describe-package doesn't work for packages managed by guix
> The problem here is, that Guix does not include the -pkg.el > file, that would typically be generated by package.el. To deal with > this, you have to provide package specs on your own. There already > exists a utility to locate libraries in a package manager agnostic > fashion [1], all you need to do is to feed back that information to > package.el. Yep, I figured it out yesterday and even hacked around a little bit. Patched emacs-build-system to place packages under elpa/NAME-VERSION subdirectory and removed "-pkg\\.el$" from %default-exclude. > I have now published emacs-dpd [2], which does exactly that. To use it > for your Guix Emacs packages, execute > (dpd (list "$GUIX_PROFILE/share/emacs/site-lisp" ...)) > replacing "$GUIX_PROFILE" with the actual profile, after `package- > initialize' has run with `dpd-fuzzy-recognize' in `dpd-recognize-hook'. > I might write a more detailed README later. Most of the packages already have -pkg.el in sources, but yep, pretty cool utility, also thought about implementing something like that yesterday, but luckily I didn't and now I do not need to do it, because now I'm aware of already-existing implementations!) > Neither packed nor dpd are currently packaged in Guix. packed can > easily be imported from melpa-stable, but for dpd you'd have to write > your own guix.scm. I might do that at some point as well. > We already had modifications in emacs-build-system recently, so if you > want to argue, that all Emacs packages should have that - > pkg.el to work with package.el out of the box, I would ask you to wait, > so as to not cause an "Emacs world" rebuild again after only ten days. > I also don't know whether Guix has the same information as package.el > at build time, but that might change with time as well. Particularly, > there will hopefully be a move towards supplying name and version at > build, which would give us the most important information. Very cool, I didn't have the latest changes on my local checkout and didn't see your commits, but now I see, it is exactly what I needed. The only side note: it should be site-lisp/elpa/NAME-VERSION (right now it is site-lisp/NAME-VERSION). Also, on line 137 elpa-directory function can be used. When you will be updating the path, please remove -pkg.el from %default-exclude. Thank you very much for your work! Really appreciate it! -- Best regards, Andrew Tropin
bug#48331: Emacs' describe-package doesn't work for packages managed by guix
Am Dienstag, den 11.05.2021, 18:57 +0300 schrieb Andrew Tropin: > Patched emacs-build-system to place packages under elpa/NAME-VERSION > subdirectory and removed "-pkg\\.el$" from %default-exclude. I don't know whether that's a good idea. The elpa/ part I already dislike, and the "-pkg\\.el$" exclude might have existed for a reason (I don't know which, put perhaps byte compilation). > > I have now published emacs-dpd [2], which does exactly that. To > > use it > > for your Guix Emacs packages, execute > > (dpd (list "$GUIX_PROFILE/share/emacs/site-lisp" ...)) > > replacing "$GUIX_PROFILE" with the actual profile, after `package- > > initialize' has run with `dpd-fuzzy-recognize' in `dpd-recognize- > > hook'. > > I might write a more detailed README later. > > Most of the packages already have -pkg.el in sources, but yep, pretty > cool utility, also thought about implementing something like that > yesterday, but luckily I didn't and now I do not need to do it, > because > now I'm aware of already-existing implementations!) I know people take package.el for granted nowadays, but alternative package managers for Emacs have their uses. This is not just a Guix thing :) > > Neither packed nor dpd are currently packaged in Guix. packed can > > easily be imported from melpa-stable, but for dpd you'd have to > > write > > your own guix.scm. I might do that at some point as well. > > We already had modifications in emacs-build-system recently, so if > > you > > want to argue, that all Emacs packages should have that - > > pkg.el to work with package.el out of the box, I would ask you to > > wait, > > so as to not cause an "Emacs world" rebuild again after only ten > > days. > > I also don't know whether Guix has the same information as > > package.el > > at build time, but that might change with time as > > well. Particularly, > > there will hopefully be a move towards supplying name and version > > at > > build, which would give us the most important information. > > Very cool, I didn't have the latest changes on my local checkout and > didn't > see your commits, but now I see, it is exactly what I needed. > > The only side note: it should be site-lisp/elpa/NAME-VERSION (right > now > it is site-lisp/NAME-VERSION). Also, on line 137 elpa-directory > function can be used. I don't think we want to fake elpa that hard. Two iterations ago it was .guix.d and people didn't really like it. My subdirs.el patch is also stretching it. So I really don't want to add another subdirectory layer to it. If elpa can't deal with that, we'll have to code around it in Elisp. > When you will be updating the path, please remove -pkg.el from > %default-exclude. I've CC'd Maxim, perhaps they know more about %default-exclude. Regards, Leo
bug#42342: Wine64 segfaults (5.12/staging)
We are currently at wine 6.8/6.6-staging and from my own estimates my fix proved useful.
bug#37942: Insufficient environment wrappers
I concede, that the initial formulation was a bit too vague and that meta bugs are not that good unless they can easily be addressed. Thanks :)
bug#37933: gst* plugins in non-default profile not found by webkitgtk browsers (e.g. epiphany)
Am Samstag, den 26.10.2019, 12:48 +0200 schrieb Pierre Neidhardt: > Recipe that fails: > > --8<---cut here---start->8--- > guix remove gst-libav gst-plugins-bad gst-plugins-base gst-plugins- > good gst-plugins-ugly > guix package -p foo -i gst-libav gst-plugins-bad gst-plugins-base > gst-plugins-good gst-plugins-ugly epiphany > foo/bin/epiphany https://archive.org/details/guix-videos > --8<---cut here---end--->8--- How is this recipe supposed to work? You ought to source foo/etc/profile first. > Recipe that works > > --8<---cut here---start->8--- > guix package -i gst-libav gst-plugins-bad gst-plugins-base gst- > plugins-good gst-plugins-ugly epiphany > foo/bin/epiphany https://archive.org/details/guix-videos > --8<---cut here---end--->8--- >
bug#48213: offlineimap build fails
Mark H Weaver writes: > Hi, > > Bone Baboon via Bug reports for GNU Guix writes: >> On a x86_64 computer when I run `guix build --no-substitutes >> offlineimap` the build fails because the "test_ipv6_available" test >> fails. > > 'offlineimap' is the _only_ package in Guix that > depends on the 'python2-rfc6555' package, it's quite painless to work > around this particular issue using Guix's "--without-tests" package > transformation option. > > From the command line, you can simply do this: > > guix build offlineimap --without-tests=python2-rfc6555 > > Within an OS configuration, or within a profile "manifest" file (if you > use "guix package --manifest", which is highly recommended), you can use > the following Scheme expression in place of 'offlineimap': > > --8<---cut here---start->8--- > (let ((transform (options->transformation > '((without-tests . "python2-rfc6555") > (transform offlineimap)) > --8<---cut here---end--->8--- > > Note that you'll also need to put "(use-modules (guix transformations))" > at the top of the file, to import the 'options->transformation' > procedure. > > Please let us know if this works for you. Thank you I can build offlineimap with this command `guix build offlineimap --no-substitutes --without-tests=python2-rfc6555`. How would I refer to offlineimap (built without tests) in the configuration of a substitute server's client? The client is not building it's own packages and is instead relying on a substitute server to build offlineimap without tests.
bug#48352: Haskell cabal new-build fails
I am experiencing an error when I try to compile a Haskell program with Cabal a Haskell build tool. Previously I had Cabal working and was able to compile Haskell programs. https://lists.gnu.org/archive/html/help-guix/2021-04/msg00096.html Now when I try to build a Haskell program with `cabal new-build` I get an error. `guix describe` outputs: ``` Generation 14 May 11 2021 08:06:01(current) guix bddad00 repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: bddad00bffc5837e89942756fa5b7234f63f1f47 ``` The error message: ``` Build profile: -w ghc-8.6.5 -O1 In order, the following will be built (use -v for more details): - -0.1.0.0 (exe:) (first run) Preprocessing executable '' for -0.1.0.0.. Building executable '' for -0.1.0.0.. Linking /dist-newstyle/build/x86_64-linux/ghc-8.6.5/-0.1.0.0/x//build// ... In file included from /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/include/errno.h:28:0: error: 0, from /gnu/store/5i95kk1qdfvl6ld3hf6a4q7kxw6sgpkv-ghc-8.6.5/lib/ghc-8.6.5/include/rts/OSThreads.h:28, from /gnu/store/5i95kk1qdfvl6ld3hf6a4q7kxw6sgpkv-ghc-8.6.5/lib/ghc-8.6.5/include/Rts.h:168, from /tmp/ghc8802_0/ghc_1.c:1: /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/include/bits/errno.h:26:11: error: fatal error: linux/errno.h: No such file or directory # include ^~~ | 26 | # include | ^ compilation terminated. `gcc' failed in phase `C Compiler'. (Exit code: 1) ```
bug#48240: “guix copy” to host with daemon listening on TCP fails
Ludovic Courtès writes: > Fixed in da28efef36af8925bcd9e40a81cbf552cf8c2d02. Let me know if it > works for you! This commit appears to have fixed a problem with guix copy that I was having yesterday. I was getting this error "guix copy: error: failed to connect over SSH to daemon at '', socket /var/guix/daemon-socket/socket". Now I can successfully run guix copy.
bug#48343: Cannot boot after installation
Sergey Petrov writes: > Hi! I've installed ordinary guix system following graphical installer, > but can't boot it, here what I got after installation complete: > > GC Warning: pthread_getattr_pp or pthread_attr_getstack failed for > main thread GC Warning: > Couldn't read /proc/stat > Welcome, this is GMU's early boot Guile. > Use '--repl' for an initrd REPL. > > loading kernel modules... > /dev/nvme0n1p8: clean, > 134898/5169152 files, 1320485/20649216 blocks > loading '/gnu/store/519yr5adx95d26s3nu65mjOcc9731630-system/boot... > making '/gnu/store/519yr5adx95d26s3nu65mj0cc9731630-system' the > current system... > setting up setuid programs in '/run/setuid-programs'... > populating /etc from /gnu/store/d6k3c7p2s6ji0ix2g3lafx4iwOd43a98-etc... > error in finalization thread: Success > [ 3.049660] udevd[272]: no sender credentials received, message ignored > [ 3.098019] sp5100-tco sp5100-tco: Watchdog hardware is disabled > [ 3.104103] Error: Driver 'pcspkr' is already registered, aborting... > [ 3.180575] kvm: disabled by bios > > At this point computer hangs infinitely, and if I enable CPU > virtualization in BIOS it starts to hang at line "[ 3.104103] Error: > Driver 'pcspkr' is already registered, aborting..." I ran into a similar issue with a computer I installed Guix on. It would not complete the boot up process. I am not sure if I was experiencing the same issue you are as I did not submit it to a Guix mailing list. I got help solving it on #guix. What worked for me was to add the Linux kernel argument `nomodeset` to my system configuration. In the operating system declaration of the system configuration I added: ``` (kernel-arguments (append (list "nomodeset") %default-kernel-arguments)) ```
bug#48343: Cannot boot after installation
Hi! I've installed ordinary guix system following graphical installer, but can't boot it, here what I got after installation complete: GC Warning: pthread_getattr_pp or pthread_attr_getstack failed for main thread GC Warning: Couldn't read /proc/stat Welcome, this is GMU's early boot Guile. Use '--repl' for an initrd REPL. loading kernel modules... /dev/nvme0n1p8: clean, 134898/5169152 files, 1320485/20649216 blocks loading '/gnu/store/519yr5adx95d26s3nu65mjOcc9731630-system/boot... making '/gnu/store/519yr5adx95d26s3nu65mj0cc9731630-system' the current system... setting up setuid programs in '/run/setuid-programs'... populating /etc from /gnu/store/d6k3c7p2s6ji0ix2g3lafx4iwOd43a98-etc... error in finalization thread: Success [ 3.049660] udevd[272]: no sender credentials received, message ignored [ 3.098019] sp5100-tco sp5100-tco: Watchdog hardware is disabled [ 3.104103] Error: Driver 'pcspkr' is already registered, aborting... [ 3.180575] kvm: disabled by bios At this point computer hangs infinitely, and if I enable CPU virtualization in BIOS it starts to hang at line "[ 3.104103] Error: Driver 'pcspkr' is already registered, aborting..."
bug#48347: missing debug symbols for qutebrowser and python packages
I'm trying to debug a qutebrowser crash and I noticed qutebrowser and python are missing debug outputs. Could they be added?
bug#48240: “guix copy” to host with daemon listening on TCP fails
Hi, Simon Streit skribis: > Then it was suggested I checkout to commit > dd14678b9b9843be20e2bbb98ceb30d2433dab82 and force downgrade my new > system. While doing so, I noticed that guix-daemon would still offload, > while if I'd type in `guix offload test`, I'd get a response: > > guix offload: testing 1 build machines defined in '/etc/guix/machines.scm'... > guix offload: Guix is usable on 'host' (test returned > "/gnu/store/883yjkl46dxw9mzykykmbs0yzwyxm17z-test") > guix offload: 'host' is running GNU Guile 3.0.5 > guix offload: error: failed to connect over SSH to daemon at 'host', socket > /var/guix/daemon-socket/socket > > Anyway, back to this old commit offloading works for all users. > > The commit with this broken behaviour is at: > 87b4b0e4385149b40ee87ae2d57712679452746b. Fixed in da28efef36af8925bcd9e40a81cbf552cf8c2d02. Let me know if it works for you! Thanks, Ludo’.
bug#48331: Emacs' describe-package doesn't work for packages managed by guix
Am Montag, den 10.05.2021, 10:51 +0300 schrieb Andrew Tropin: > describe-package and list-packages do not show emacs packages, > installed > with guix. Packages themselves work perfectly fine, but not listed in > list-packages and can't be accessed with describe-package. > > Way to reproduce: > > guix environment --pure --ad-hoc emacs emacs-treemacs > > emacs -q > > M-x treemacs ;; Works fine > C-h P treemacs ;; Doesn't work > M-x list-packages ;; Doesn't list treemacs > > Played around with it a little bit, still not sure how to solve. This mail brought me back to the good old days of 2018, when I was still using Gentoo and had to solve a similar issue. The problem here is, that Guix does not include the -pkg.el file, that would typically be generated by package.el. To deal with this, you have to provide package specs on your own. There already exists a utility to locate libraries in a package manager agnostic fashion [1], all you need to do is to feed back that information to package.el. I have now published emacs-dpd [2], which does exactly that. To use it for your Guix Emacs packages, execute (dpd (list "$GUIX_PROFILE/share/emacs/site-lisp" ...)) replacing "$GUIX_PROFILE" with the actual profile, after `package- initialize' has run with `dpd-fuzzy-recognize' in `dpd-recognize-hook'. I might write a more detailed README later. Neither packed nor dpd are currently packaged in Guix. packed can easily be imported from melpa-stable, but for dpd you'd have to write your own guix.scm. I might do that at some point as well. We already had modifications in emacs-build-system recently, so if you want to argue, that all Emacs packages should have that - pkg.el to work with package.el out of the box, I would ask you to wait, so as to not cause an "Emacs world" rebuild again after only ten days. I also don't know whether Guix has the same information as package.el at build time, but that might change with time as well. Particularly, there will hopefully be a move towards supplying name and version at build, which would give us the most important information. Regards, Leo [1] https://github.com/emacscollective/packed [2] https://gitlab.com/leoprikler/emacs-dpd
bug#48240: “guix copy” to host with daemon listening on TCP fails
Hi, Simon Streit skribis: > Then it was suggested I checkout to commit > dd14678b9b9843be20e2bbb98ceb30d2433dab82 and force downgrade my new > system. While doing so, I noticed that guix-daemon would still offload, > while if I'd type in `guix offload test`, I'd get a response: > > guix offload: testing 1 build machines defined in '/etc/guix/machines.scm'... > guix offload: Guix is usable on 'host' (test returned > "/gnu/store/883yjkl46dxw9mzykykmbs0yzwyxm17z-test") > guix offload: 'host' is running GNU Guile 3.0.5 > guix offload: error: failed to connect over SSH to daemon at 'host', socket > /var/guix/daemon-socket/socket > > Anyway, back to this old commit offloading works for all users. Is the socket file name displayed above correct? Or did you specify something else in the record? Is the ‘GUIX_DAEMON_SOCKET’ environment variable defined on that machine? How do you run guix-daemon on the head node? The patches discussed here haven’t made it into the ‘guix’ package yet AFAIK. Thanks for reporting the issue! Ludo’.
bug#48240: “guix_ copy” to host with daemon listening on TCP fails
Hello! After reinstalling my system last night, I run into this problem too, that I couldn't offload. Then it was suggested I checkout to commit dd14678b9b9843be20e2bbb98ceb30d2433dab82 and force downgrade my new system. While doing so, I noticed that guix-daemon would still offload, while if I'd type in `guix offload test`, I'd get a response: --8<---cut here---start->8--- guix offload: testing 1 build machines defined in '/etc/guix/machines.scm'... guix offload: Guix is usable on 'host' (test returned "/gnu/store/883yjkl46dxw9mzykykmbs0yzwyxm17z-test") guix offload: 'host' is running GNU Guile 3.0.5 guix offload: error: failed to connect over SSH to daemon at 'host', socket /var/guix/daemon-socket/socket --8<---cut here---end--->8--- Anyway, back to this old commit offloading works for all users. The commit with this broken behaviour is at: 87b4b0e4385149b40ee87ae2d57712679452746b. Cheers Simon
bug#48045: guix challenge error
Hi, Bone Baboon skribis: > Ludovic Courtès writes: >> The bug comes from the fact that it’s gone beyond 100%. We could solve >> it by programming more defensively, but it’d be great to see where the >> problem comes from. >> >> Can you reproduce it with: >> >> ./pre-inst-env guix challenge >> /gnu/store/5ds5bli4p6gja2yzmzzc0sik1kzrasp9-guix-extra >> >> ? >> >> If so, could you apply the patch below and send the output of this >> command? We can discuss it on IRC if anything’s unclear. > > I can not reproduce this error any more. > > I have a new clone of the Guix repository. > > I ran `./pre-inst-env guix challenge > /gnu/store/5ds5bli4p6gja2yzmzzc0sik1kzrasp9-guix-extra` 20 times and the > error was no error. > > I ran `./pre-inst-env guix challenge` several times and there was no > error. > > I tried running `guix challenge > /gnu/store/5ds5bli4p6gja2yzmzzc0sik1kzrasp9-guix-extra` outside of the > Guix repository 20 times and there was no error. Thanks for checking. I’m closing it, but please do reopen if you stumble upon it again. Ludo’.
bug#33848: Store references in SBCL-compiled code are "invisible"
Hi Mark, Mark H Weaver skribis: > I intend to write a scanner in Scheme that is able to find Nix hashes > encoded in ASCII, UTF-16, or UTF-32. Using that, I'll write a procedure > that, for each package output, finds all store references that are found > encoded in UTF-16 or UTF-32 but never in ASCII, and write those > references to a file (if that set is nonempty). This procedure can then > be used by selected packages and/or build-systems. > > However, there's one thing I will need: the set of all transitive inputs > (and native-inputs, including implicit inputs) available to the build, > i.e. the set of possible hashes that might legitimately be found by the > scanner. > > Ludovic: what's the best way to get that list from the build-side code? You can use #:references-graphs for that. Sorry for the delay! Ludo’.
