bug#70051: guix system hangs on boot with LUKS /home partition
Hello, Up to guix 9b84b36, my system was properly booting with a LUKS2 partition mounted on /home. Starting with guix d5f857a (22 mar 2024), the boot hangs on the same system using the same configuration.scm file. The only way out I found when it hangs is hardware shutdown. There are no avaible console nor ssh server started to help troubleshoot and there is nothing written to /var/log/messages when it hangs. I have tried to transfer my /home data to a brand new LUKS1 partition, (as well as removing pointers to the old LUKS2 partition in my config.scm, of course) and the problem remains exactly the same, including those error messages (obtained with a video capture of the screen at boot, after removing 'quiet' from the kernel command line in grub) : #+begin_src boot shepherd[1]: Starting service device-mapping-luks-homes... shepherd[1]: Service device-mapping-luks-homes failed to start. shepherd[1]: Exception caught while while starting device-mapping-luks-homes: (unbound-variable #f "Unbound variable: "S" (bytevector?) #f) #+end_src Maybe it's worth mentionning that I have then tried one configuration of the 'mapped-device' with 'luks-device-mapping' and another one with 'luks-device-mapping-with-options #:keyfile "/…"'. I also tried one configuration with the 'source' declared in plain "/dev/..." and another one declared with the luks '(uuid "…")', but this didnt change anything to the "symptoms". So, although I have learned in the process that LUKS2 is not yet fully supported in guix, this problem also prevents booting using a LUKS1 /home partition in my case. Transfering the /home data to a clear (unencrypted) partition is my current workaround to this problem. Below is the configuration that has worked for several weeks, if not months, using my LUKS2 /home : (mapped-devices (list (mapped-device (source (uuid "")) (target "luks-homes") (type luks-device-mapping (file-systems (append (list […] (file-system (mount-point "/home") (device (file-system-label "luks-homes")) (type "ext4") (dependencies mapped-devices)) […] Best regards and thanks for guix !
bug#70051:
… And I forgot to mention that, when the boot hangs, shepherd still responds to ctrl-alt-del by closing some services and then the system hangs with hardware button shutdown as last resort.
bug#68948: highlight error, cannot open filetypes.conf: No such file or directory
Below changes at the highlight package resolve the issue here but may adversely affect "highlight-gui" functionality. Will wait for https://issues.guix.gnu.org/70047 before trying to proceed, ```diff - #:make-flags #~(let ((confdir (string-append %output - "/share/highlight/config/"))) - (list (string-append "PREFIX=" %output) - (string-append "HL_CONFIG_DIR=" confdir) - (string-append "conf_dir=" confdir))) + #:make-flags #~(list (string-append "PREFIX=" %output) + (string-append "HL_CONFIG_DIR=" %output "/etc/") + (string-append "conf_dir=" %output "/etc/")) ```
bug#70051:
And I also forgot to mention *sigh* that I am not the only one affected by this problem. See : https://lists.gnu.org/archive/html/help-guix/2024-03/msg00152.html
bug#69997: Should ‘guix import pypi’ get dependencies from pyproject files?
Hi, Tanguy LE CARROUR skribis: > Quoting Ludovic Courtès (2024-03-26 17:04:52) [...] >> But then I mean, we could offer, say, ‘guix import upstream https://…’, >> and that thing could parse ‘setup.py’ or similar to produce a package >> definition from that. > > I’m not against a good-old-generic-solution®, but this one might be > a bit… too generic. It contains no mention to Python, so the next logical step > would be `guix import URL`. Not that I would not like it, though! 😁 Well, this has been on my mind for a long time. Such a tool could provide at least a useful package skeleton even for software using CMake or Autotools. > So I would say… let’s wait and see what the others think. In the > meantime, I’ll have to dive deeper in the PEP and the actual importer > code. Looks like consensus among you Pythonistas has yet to be reached regarding whether ‘pyproject.toml’ data would be a useful addition. :-) We’ll see! Ludo’. PS: I hear more and more long-time Python developers dismayed by the sad state of packaging and code evolution in Python. In Guile land, we say: refugees welcome! Come discover a great language and a great community (together with their own set of problems).
bug#70026: QtBase 6.5.2: Wrong private header locations
Hi Daniel, Daniel Ziltener via Bug reports for GNU Guix writes: > The private header files of QtBase (and probably other Qt packages as > well) are placed in the wrong location. In my case, I am trying to use > qmetaobjectbuilder_p.h. The path for it is > /gnu/store/zywk3i6r200qd0w0fjizg3m5nwpkkzjs-profile/include/qt6/QtCore/6.5.2/QtCore/private/qmetaobjectbuilder_p.h > (expected would be > /gnu/store/zywk3i6r200qd0w0fjizg3m5nwpkkzjs-profile/include/qt6/QtCore/private/qmetaobjectbuilder_p.h), > which leads to issues when compiling, because qmetaobjectbuilder_p.h > contains an "#include ", which can then > not be found. It also means I cannot use any of the provided include > path env variables like C_INCLUDE_PATH. If you have the chance, could you try on the qt-team branch? It has a fresh Qt 6.6.2 version; perhaps something got fixed. -- Thanks, Maxim
bug#62645: Failing `guix install gnash`.
Hi, Gnash is incompatible with Boost 1.80.0. The latest commit in Gnash, from 2019, says: -This is the README file for the Gnash-0.8.8 release (or snapshot). +Gnash is currently not being actively maintained, as most of the internet +has moved to using HTML5. There are literally millions of flash files +that Gnash can play, as well as YouTube videos. As Adobe is letting their +flash player die on most platforms, Gnash will be critical in the future +for anyone wanting to play flash files for historical reasons. Gnash's code +is very portable, and should be compilable for many years, long after +Adobe flash is dead. It may not be feasible to support Gnash long-term. You could use Lightspark instead, which is still actively maintained and up to date in Guix, or use time-machine to move to a commit where Gnash was building, prior to the core-updates merge that introduced Boost 1.80.0. IMO we should remove Gnash from the repository, unless someone wants to patch it for the latest Boost. Vinicius
