Missing .so for guile-aiscm

2022-12-30 Thread Jonathan Frederickson
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?

2020-05-25 Thread Jonathan Frederickson

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?

2020-05-25 Thread Jonathan Frederickson
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

2019-11-16 Thread Jonathan Frederickson
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”

2019-11-03 Thread Jonathan Frederickson
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

2019-08-28 Thread Jonathan Frederickson




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

2019-08-28 Thread Jonathan Frederickson



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

2019-08-28 Thread Jonathan Frederickson
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

2019-08-28 Thread Jonathan Frederickson
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

2019-07-23 Thread Jonathan Frederickson
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

2019-07-07 Thread Jonathan Frederickson
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

2019-05-01 Thread Jonathan Frederickson
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

2019-05-01 Thread Jonathan Frederickson
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?