Missing .so for guile-aiscm
Hi all - I'm trying out OpenCV via AIscm in Guix using the guile-aiscm package, and I'm having some trouble. When I attempt to load one of the AIscm modules, I get an error about a missing native library: #+begin_src jfred@lambdacrypt ~$ guix shell guile guile-aiscm hint: Consider passing the `--check' option once to make sure your shell does not clobber environment variables. bash: alias: -p: not found jfred@lambdacrypt ~ [env]$ guile GNU Guile 3.0.8 Copyright (C) 1995-2021 Free Software Foundation, Inc. Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'. This program is free software, and you are welcome to redistribute it under certain conditions; type `,show c' for details. Enter `,help' for help. scheme@(guile-user)> (use-modules (aiscm image)) While compiling expression: In procedure dlopen: file "libguile-aiscm-util.so", message "libguile-aiscm-util.so: cannot open shared object file: No such file or directory" #+end_src I've just updated to the latest Guix revision as of now with the same result, so it looks like it's not something that was broken in a previous revision and since fixed. It seems like installing the library into this temporary shell may not have installed its native components or something? I feel like I must be doing something wrong here. Any help would be much appreciated! -- Jonathan Frederickson
Re: Geiser and Guix - how to avoid long compilation steps?
Ah! Thanks for the hint about the version of Guile. Turns out it was actually the other way around; I had built Guix with Guile 3 but still had Guile 2.2 in my profile. This explains why an ad-hoc environment with Guile worked just fine, but Guile in my normal profile did not. (Looks like Guix gained support for Guile 3 prior to version 1.1.0: https://guix.gnu.org/blog/2020/gnu-guix-1.1.0-released/) On Tue, May 26, 2020 at 2:05 am, divoplade wrote: Hello, I think that guix does not support guile 3 yet, so you should have guile 2 bytecode for the guix modules. If geiser starts guile 3, then guile 3 will recompile everything because the bytecode format changed (and it could even compile native code). Maybe it could work if you used guile 2.2 with geiser. divoplade Le lundi 25 mai 2020 à 19:02 -0400, Jonathan Frederickson a écrit : I've been using Geiser to hack on Guix lately, which is absolutely wonderful to use when it works. The trouble is, after I upgrade my system's Guix, Guile attempts to compile large portions of Guix when I attempt to switch to the module I'm working on in Geiser, e.g.: M-x run-guile ,m (gnu services games) This despite the fact that I'm working on a copy of Guix that I've already compiled with 'make' and that has the compiled copy alongside the source. The compilation step takes a *long* time on my hardware, which is fairly painful when I want to hack on Guix. I do have my Guix checkout in geiser-guile-load-path in my emacs config as per https://guix.gnu.org/manual/en/html_node/The-Perfect-Setup.html: (with-eval-after-load 'geiser-guile (add-to-list 'geiser-guile-load-path "~/sources/guix")) My guess is that Guile is picking up my system's version of Guix before my local copy. I understand that I could start a version of Emacs in a pure ad-hoc environment (and Guile doesn't appear to start recompiling Guix when I do so), but the typical Emacs workflow is to have a long-running Emacs session and use that for everything; that's what I'm used to, and I'd like to continue to do so if possible. Does anyone else experience this? What's the best way to use Geiser to hack on Guix when running Guix System?
Geiser and Guix - how to avoid long compilation steps?
I've been using Geiser to hack on Guix lately, which is absolutely wonderful to use when it works. The trouble is, after I upgrade my system's Guix, Guile attempts to compile large portions of Guix when I attempt to switch to the module I'm working on in Geiser, e.g.: M-x run-guile ,m (gnu services games) This despite the fact that I'm working on a copy of Guix that I've already compiled with 'make' and that has the compiled copy alongside the source. The compilation step takes a *long* time on my hardware, which is fairly painful when I want to hack on Guix. I do have my Guix checkout in geiser-guile-load-path in my emacs config as per https://guix.gnu.org/manual/en/html_node/The-Perfect-Setup.html: (with-eval-after-load 'geiser-guile (add-to-list 'geiser-guile-load-path "~/sources/guix")) My guess is that Guile is picking up my system's version of Guix before my local copy. I understand that I could start a version of Emacs in a pure ad-hoc environment (and Guile doesn't appear to start recompiling Guix when I do so), but the typical Emacs workflow is to have a long-running Emacs session and use that for everything; that's what I'm used to, and I'd like to continue to do so if possible. Does anyone else experience this? What's the best way to use Geiser to hack on Guix when running Guix System?
Java fontconfig issues
I've been trying to run PCGen (https://github.com/PCGen/pcgen/releases) on my laptop running Guix System, so far without success. I know that ideally all software would be installed through Guix itself, but this thing is a Java app with several dependencies that aren't in Guix yet and... honestly, right at this moment, I'd be fine with running the jar directly for now. However, when attempting to run this Jar with openjdk installed, I get a null pointer exception related to some font configuration code. This seems related to an issue on the AdoptOpenJDK repos[0], which was solved in that case by installing the fontconfig package (on a Debian install in their case). However, installing fontconfig into my profile in Guix hasn't done the trick. There's a workaround mentioned involving creating a fontconfig.properties file in JAVA_HOME, but setting that as an environment variable didn't seem to do the trick either. While the specific application I'm focusing on is PCGen, this seems to affect graphical Java applications in general; I tested with a generic JAR build of Jitsi and ran into the same issue. Can anyone familiar with Java provide some assistance in tracking down this problem? https://github.com/AdoptOpenJDK/openjdk-build/issues/693 jfred@lambdacrypt ~/Downloads/pcgen$ java -jar pcgen.jar 11:46:40.374 INFO main Main:138 Starting PCGen v6.08.00 RC6 11:46:40.448 INFO main LanguageBundle:134 Initialising language bundle with locale en_US. 11:46:40.581 SEVERE main LookAndFeelManager:222 Look and Feel Java cannot be found 11:46:40.756 SEVERE main Main:484 Uncaught error - ignoring java.lang.InternalError: java.lang.reflect.InvocationTargetException at java.desktop/sun.font.FontManagerFactory$1.run(Unknown Source) at java.base/java.security.AccessController.doPrivileged(Unknown Source) at java.desktop/sun.font.FontManagerFactory.getInstance(Unknown Source) at java.desktop/java.awt.Font.getFont2D(Unknown Source) at java.desktop/java.awt.Font.getFamily(Unknown Source) at java.desktop/java.awt.Font.getFamily_NoClientCode(Unknown Source) at java.desktop/java.awt.Font.getFamily(Unknown Source) at java.desktop/sun.swing.SwingUtilities2.displayPropertiesToCSS(Unknown Source) at java.desktop/javax.swing.plaf.basic.BasicHTML$BasicDocument.setFontAndColor(Unknown Source) at java.desktop/javax.swing.plaf.basic.BasicHTML$BasicDocument.(Unknown Source) at java.desktop/javax.swing.plaf.basic.BasicHTML$BasicEditorKit.createDefaultDocument(Unknown Source) at java.desktop/javax.swing.plaf.basic.BasicHTML.createHTMLView(Unknown Source) at java.desktop/javax.swing.plaf.basic.BasicHTML.updateRenderer(Unknown Source) at java.desktop/javax.swing.plaf.basic.BasicButtonUI.installUI(Unknown Source) at java.desktop/javax.swing.JComponent.setUI(Unknown Source) at java.desktop/javax.swing.AbstractButton.setUI(Unknown Source) at java.desktop/javax.swing.JRadioButton.updateUI(Unknown Source) at java.desktop/javax.swing.AbstractButton.init(Unknown Source) at java.desktop/javax.swing.JToggleButton.(Unknown Source) at java.desktop/javax.swing.JRadioButton.(Unknown Source) at java.desktop/javax.swing.JRadioButton.(Unknown Source) at pcgen.gui2.dialog.OptionsPathDialog.addRadioButton(OptionsPathDialog.java:162) at pcgen.gui2.dialog.OptionsPathDialog.initComponents(OptionsPathDialog.java:104) at pcgen.gui2.dialog.OptionsPathDialog.(OptionsPathDialog.java:61) at pcgen.gui2.dialog.OptionsPathDialog.promptSettingsPath(OptionsPathDialog.java:68) at pcgen.system.Main.loadProperties(Main.java:328) at pcgen.system.Main.startupWithGUI(Main.java:230) at pcgen.system.Main.main(Main.java:157) Caused by: java.lang.reflect.InvocationTargetException at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source) at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source) at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Unknown Source) at java.base/java.lang.reflect.Constructor.newInstance(Unknown Source) ... 28 more Caused by: java.lang.NullPointerException at java.desktop/sun.awt.FontConfiguration.getVersion(Unknown Source) at java.desktop/sun.awt.FontConfiguration.readFontConfigFile(Unknown Source) at java.desktop/sun.awt.FontConfiguration.init(Unknown Source) at java.desktop/sun.awt.X11FontManager.createFontConfiguration(Unknown Source) at java.desktop/sun.font.SunFontManager$2.run(Unknown Source) at java.base/java.security.AccessController.doPrivileged(Unknown Source) at java.desktop/sun.font.SunFontManager.(Unknown Source) at java.desktop/sun.awt.FcFontManager.(Unknown Source) at java.desktop/sun.awt.X11FontManager.(Unknown Source) ... 33 more
Re: “Guix Profiles in Practice”
On Nov 3, 2019, at 9:24 AM, Ludovic Courtès wrote > Now, this would be very much stateful: you can’t tell in advance whether > you’re going to build a new profile based on the current Guix, or > whether you’re going to reuse a previously cached profile that could be > arbitrarily old. That doesn’t sound great. What if something identifying the profile (directory name? config file?) included info about the Guix revision it was built from? That way a profile would be reused if it’s built from the same Guix revision, but if you switch revisions it’d be rebuilt. I’m not sure how this would interact with a profile built from packages in multiple channels.
Re: Setting environment variables in Gnome session
On Wed, Aug 28, 2019 at 9:15 PM, Timothy Sample wrote: Yes. Because Bash is your login shell, it gets invoked as part of spawning your X session. Because of this, Bash-specific configuration files affect your X session’s environment. Oh, interesting! You're right - I did not realize that would happen. And that was indeed the solution, although I made a mistake at the time. I'd initially put that line in bashrc instead while trying things, then saw that bash_profile sourced bashrc so assumed it'd do the same. I missed, however, that bashrc returned earlier in the file if running in a noninteractive shell, so my additions were never reached while spawning the X session. Thank you for the help, and sorry for the run-around!
Re: Setting environment variables in Gnome session
On Wed, Aug 28, 2019 at 8:40 PM, Timothy Sample wrote: If you use GDM and GNOME, and have Bash as your shell, you need to set the variables in “~/.bash_profile” or “~/.bashrc”. Guix System sets up GDM to run your X session from the your login shell (which I’m assuming is Bash). Since Guix System provides a “~/.bash_profile” file by default, Bash will read this and skip “~/.profile”. So if you set the variables in a Bash-specific file it should work. -- Tim Thanks, but the environment variable I'm looking to set needs to apply to Gnome itself rather than my terminal shell. It's the search path that Gnome uses to find XDG application files. I believe ~/.bash_profile is only read by bash specifically? (I've just tried adding the relevant env var to ~/.bash_profile in any case, but it doesn't seem to have affected gnome-shell's environment.)
Re: Setting environment variables in Gnome session
On Wed, 28 Aug 2019 15:53:48 -0400 Jonathan Frederickson wrote: > However, my Gnome session in Guix System seems to ignore this file. > I've tried creating a file in my home directory in /etc/profile like > so, and as far as I can tell it's never getting run: Whoops - to be clear, I meant $HOME/.profile when I said /etc/profile here.
Setting environment variables in Gnome session
I'm trying to install some software through Flatpak alongside software installed through Guix (on a Guix System install) and I'm running into what feels like it should be a minor issue. On other distros (including my desktop where I'm running Guix as a foreign package manager), I would modify XDG_DATA_DIRS in $HOME/.profile to accomplish this. However, my Gnome session in Guix System seems to ignore this file. I've tried creating a file in my home directory in /etc/profile like so, and as far as I can tell it's never getting run: export XDG_DATA_DIRS=$XDG_DATA_DIRS:/var/lib/flatpak/exports/share echo "hi there!" > $HOME/test.txt Is there a preferred way to set environment variables in a graphical session?
guix system init results in image with no /etc/passwd or /etc/shadow present
Hey there! I'm trying to script the creation of a Guix System rootfs. However, when I run "guix system init" with this system configuration, the resulting filesystem tree doesn't have /etc/passwd or /etc/shadow. (Possibly some other necessary files as well? Those are the only ones I've noticed.) I've attached the operating-system configuration I'm working with. I've run this from both guix 1.0.1 and current master, with the same result: root@ubuntu:~/guix/etc# guix describe guile: warning: failed to install locale Generation 2Jul 23 2019 18:09:38(current) guix c42db89 repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: c42db89ff992037841e7937059db952571af86fa Some notes: - The device I'm configuring as the root mountpoint (/dev/sda) is correct; it's a partitionless VM disk. - The bootloader configuration is there to place grub.cfg without trying to install GRUB. It's not necessary in my case as the hypervisor has a pre-existing copy of GRUB, the VM just needs a GRUB config in the standard location. (That's a snippet I found in the mailing list archives.) I thought the fact that I'm not defining any user accounts was noteworthy, but I tried adding a dummy user to the operating-system config as shown in the manual, with the same result. I feel like there has to be something I'm missing, because I have another machine running Guix System that has a working config, but I haven't been able to figure this out. Any pointers would be appreciated. ;; This is an operating system configuration template for the default ;; CORP installation of the Guix System (use-modules (gnu) (gnu system nss) (gnu packages linux) (gnu system linux-initrd) (gnu services ssh) (gnu bootloader) (gnu bootloader grub) (gnu packages bootloaders)) (use-package-modules certs) (use-service-modules networking) (operating-system (host-name "guix") (timezone "America/New_York") (locale "en_US.utf8") (bootloader (bootloader-configuration (bootloader (bootloader (inherit grub-bootloader) (installer #~(const #t)) ;; Overridden to configure grub without installing it (file-systems (cons (file-system (device "/dev/sda") (mount-point "/") (type "ext4")) %base-file-systems)) (initrd-modules (append (list "virtio_scsi") %base-initrd-modules)) ;; This is where we specify system-wide packages. (packages (cons* nss-certs ;for HTTPS access %base-packages)) (services (append (list (service dhcp-client-service-type) (service openssh-service-type)) %base-services)))
Screen doesn't lock on lid close in XFCE
I recently tried switching from Gnome to XFCE on my X230. Almost everything still works as expected, but I haven't been able to get the screen locker to activate when closing the lid. If I suspend my laptop using the sleep hotkey (Fn-F4), xlock is active when I resume the laptop. However, if I suspend by closing the lid, no screen locker has started when I resume. I do have "Lock screen when system is going for sleep" checked in Settings -> Power Manager -> System. My current system config can be found here: https://raw.githubusercontent.com/jfrederickson/dotfiles/master/guix/guix/system.scm I tried searching the list archives to see if anyone else has encountered this, but didn't find anything. I don't see anything that looks relevant in /var/log/messages, though I could be missing something. Has anyone seen this before/know the fix?
Re: GuixSD on a laptop with Heads
Ah, apologies for the proprietary Javascript. I was looking for a good image host since I wasn't sure about the etiquette for attachments on mailing lists but... whoops. On 5/1/19 7:19 AM, Tobias Geerinckx-Rice wrote:> That won't help if there's nowhere to print to. From your screenshot, > you're not in VGA mode, for example. Is that screenshot from within > Heads? Which graphics driver is Heads using at that point? Have you > tried adding the same driver to the initrd? > > (initrd-modules (cons* "i915" %base-initrd-modules))) That did the trick, thank you! I didn't realize the i915 wouldn't be included out of the box, but in retrospect it makes sense. signature.asc Description: OpenPGP digital signature
GuixSD on a laptop with Heads
Hey - so I'm trying to get GuixSD running on a Thinkpad X230 running Heads. (https://github.com/osresearch/heads) For some background: this system boots into a Linux environment, has scripts that parse the GRUB config, and boots into the final system using kexec. The Heads boot scripts do not currently support booting from a system with full disk encryption, so I'm attempting to boot manually to start (after which I can patch the scripts to replicate what I did). However, I'm running into some issues when attempting to boot into the new kernel - the moment I run kexec, I get no output onscreen from the new kernel: https://imgur.com/a/r2lFD7k I've tried adding the usual debug flags to the kernel command line for troubleshooting (debug, higher LOGLEVEL, earlyprintk to vga) with no change. I'm not too familiar with the Linux boot process beyond GRUB configuration and the like, and I'm running out of ideas... does anyone have any pointers on things I could try next?