<jonsger>mroh: verschiedenes, es braucht das ispell paket. Davon eigentlich nur `buildhash`, ispell selber ist noch kaputt. Und hunspell selber hat jetzt nicht so ausgereifte Makefiles und so, da ist viel Handarbeit und so angesagt
<jonsger>jetzt überleg ich mir grad ob und wie ich noch Pakete für de_AT und de_CH hinzufügen kann
<jonsger>cool funktioniert sowohl in Liberoffice als auch in Icecat
<mroh>How long did it take? I think its building >2h here
<nckx>brettgilio: It built fine on my laptop. I didn't mean to worry you, I'm sure you didn't push a broken package. I'll investigate the failure tomorrow (it's on a slugging RAID array that excels at teasing out race conditions).
<bhartrihari>Hello, I'm trying to run Squeak (smalltalk) on GuixSD. The squeak command that gets installed expects an image. I downloaded the latest squeak release image, and when run with squeak command, it reports a version mismatch. Apparently, squeak-vm that gets installed is version 0. I get the following error: This interpreter (vers. 0) cannot read image file (vers. 68021).
<bhartrihari>Kimapr[m], The following when put in the sudoers file would let users of power group execute binary with sudo without needing a password: %power ALL=NOPASSWD:/usr/local/bin/binary
<NieDzejkob>to make /sys/class/backlight/intel_backlight/brightness writable by the video group, I have put (simple-service 'backlight udev-service-type (list brightnessctl)) in my system config. Maybe there's an equivalent for /sys/power/state?
<NieDzejkob>is there any reason for a library to not provide the :debug output, other than that nobody made it work yet?
<Tirifto>Hello! ‘guix package -I’ reports I have several packages installed, but ‘~/.config/guix/current/bin’ only contains ‘guix’ and ‘guix-daemon’. Any idea what might be wrong with my setup? (Using Guix on Parabola.)
<nckx>Tirifto: Nothing! ~/.config/guix/current is supposed to contain only guix (obtained through ‘guix pull’). Your packages are in ~/.guix-profile.
<Tirifto>Oh! So my PATH should have ‘~/.guix-profile/bin’ rather than ‘~/.config/guix/current/bin’?
<Tirifto>Alright, this time I’ll keep a log of everything I do with Guix.
<raingloom>so, i need libtre.so in an ad-hoc environment for *reasons*, but it doesn't show up on LD_LOAD_PATH. in fact, there seems to be not LD related paths set. not even when i add gcc-toolchain to the environment.
<NieDzejkob>if you want something less hacky, you can create a dummy package and set search-paths on it
<pkill9>you could do something like `guix environment --ad-hoc ... -- bash -c export LD_LIBRARY_PATH=$GUIX_ENVIRONMENT/lib ; bash` (that won't work though, I'm not sure how to correctly do those nested bash commands)
<Tirifto>So I just installed Guix with the installation script, logged out and back in (as instructed) and ran ‘guix pull’. I now have ‘/etc/profile.d/guix.sh’, but so far nothing seems to source it and Guix has not mentioned it.
<nckx>Tirifto: At least if you use bash, your log-in shell must source /etc/profile which is expected to source all of /etc/profile.d.
<Tirifto>Hmm… I use bash, but none of the environment variables set in ‘/etc/profile.d/guix.sh’ are set in my shell. Variables from other files in the same directory do seem to be set, though…
<Tirifto>‘$_GUIX_PROFILE’ is unset, ‘$GUIX_PROFILE’ is unset, and ‘$XDG_DATA_DIRS’ don’t contain anything from Guix. There’s also no ‘.guix-profile’ in my home directory, but I suppose it only gets created once a package is installed.
<NieDzejkob>Tirifto: if you add some echo's to the various files in /etc/profile.d, which trigger?
<Tirifto>Oh okay, so apparently (according to ‘man bash’) only login shells source ‘/etc/profile’; non-login shells source ‘~/.bashrc’. I’m running XFCE’s terminal emulator, so ‘/etc/profile’ probably doesn’t get sourced there after all.
<Tirifto>NieDzejkob: I just added echos to ‘guix.sh’ and ‘mozilla-common.sh’; neither got triggered.
<NieDzejkob>it will probably get sourced while your DE starts after login
<nckx>Tirifto: I don't get it. I find answers on-line that suggest that the fix to reloading /etc/profile on XFCE is restarting the lightdm service, implying that it's in charge of loading it. Which would also be logical. /etc/profile is supposed to set session-wide variables, once, which is what we want.
<jack1>Hi! Does anybody know of a good way to work with npm/nodejs things in guix?
<nefix>nckx: so I'm struggling installing guix-home-manager. I've added the channel (it shows up when I execute `guix describe channels`, but the command `guix home` doesn't exist. Do you have any clue why it could happen? Thanks!
<jack1>More specifically does anybody know of a good workaround for installing npm packages globally e.g. "npm install -g truffle" spits out a bunch of "permission denied".
<NieDzejkob>I added the "debug" output to qtbase and added "-force-debug-info" to the configure phase, and now :out grew by 7 MB. Is there a good tool for finding the exact files that have a different size now?
<NieDzejkob>jack1: direct it to /usr/local somehow and run it with sudo, I guess?
<roptat>nefix, there's a bug in guix, you need to export something first...
<nefix>roptat: what do I have to export before? :D
<nckx>Tirifto: Mh. I so don't feel like getting into a discussion in #parabola, but if you're tempted to follow that hack I'd advise you to configure your terminal emulator to launch ‘bash --login’ instead of editing .bashrc. It's slightly less wrong. Or at least its icky effects are more localised.
<roptat>nefix, GUILE_LOAD_PATH=~/.config/guix/current/share/guile/site/3.0:$GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH=~/.config/guix/current/lib/guile/3.0/site-ccache:$GUILE_LOAD_COMPILED_PATH
<roptat>otherwise, guix doesn't find the scripts from the channels
<nckx>I *think* it's even magical, like $HOSTNAME, in that bash will set it for you if it doesn't. But it shouldn't be suspect in any case.
<Tirifto>Because it showed up in the login shell, but not after the display manager magic, which got me wondering if the display manager had it set at the time of handling the scripts.
<Tirifto>Initial report? Let me search in my memory (and maybe logs). :P
<nckx>Hello! ‘guix package -I’ reports I have several packages installed, but ‘~/.config/guix/current/bin’ only contains ‘guix’ and ‘guix-daemon’. Any idea what might be wrong with my setup? (Using Guix on Parabola.)
<nckx>OK, run guix pull && guix install something.
<Tirifto>(I didn’t want to install them with my Guix misconfigured, because it already happened to me in the past that I would install packages to the wrong profile by having a messed-up configuration.)
<Tirifto>I ran guix pull already today on this install; will just installing ‘hello’ do?
<nckx>Tirifto: before you do, what is ‘type guix’ now?
<nckx>I want to make sure that ~/.config/guix/current is in your PATH and the pulled guix is used.
<Tirifto>‘guix est /home/tirifto/.config/guix/current/bin/guix’
<Tirifto>‘$PATH’ contains both ‘/home/tirifto/.guix-profile/bin’ and ‘/home/tirifto/.config/guix/current/bin’, second to only some Perl stuff. ‘$GUIX_PROFILE’ is set to ‘/home/tirifto/.guix-profile’, ‘$XDG_DATA_DIRS’ starts with ‘/home/tirifto/.guix-profile/share’.
<Tirifto>Was it this line? ‘[ -L $GUIX_PROFILE ] || return’
<nckx>I mean, the ‘|| return’ is probably unnecessary (surely we can tolerate a ‘bogus’ entry in $PATH in order to make ‘guix install’ work out of the box) but it shouldn't have affected you when you first reported the bug.
<nckx>Tirifto: That would only have kicked in *after* you removed .guix-profile, not before.
<nckx>And you said you had stuff installed, i.e. it existed.
<Tirifto>Well, I’m not sure what was wrong with my previous installation. Could’ve been a cumulation of small changes over time.
<Tirifto>Yeah, my installation was older than that.
<Tirifto>And my circumstances here were somewhat different from those of a new user.
<nckx>Tirifto: Hm. Sourcing ~/.guix-profile/etc/profile is pretty crucial: it sets all Guix ‘search paths’ (take a look), not just $PATH, and it's expected to change (so you can't just copy & edit it).
<nckx>So don't do that, at least. Add some code (/etc/profile/zzz-guix.sh or so) to modify $PATH after the fact if you must, but keep sourcing Guix's profile before that.
<nckx>Tirifto: Correction: ‘take a look’ after you've installed some complex applications, not just GNU hello, which probably doesn't use any search paths 🙂
<Tirifto>1. I reinstalled specially to get all the paths and everything in order, to have a well-functioning profile. 2. I had been told that ‘guix.sh’ should exist and handle that. 3. I saw that ‘guix.sh’ wasn’t handling it before any programs were installed. | So I expected to have paths right away and wasn’t sure if it was safe to install anything before I did, but doing so was actually necessary to get the paths. The installation ma
<Tirifto>nual doesn’t say you need to install anything, but it also doesn’t say you need the paths, so this was likely a special case.
<PotentialUser-23>Furthermore, when I try to select Guix from the UEFI BIOS boot menu, the screen goes black for less than a second and returns to the same screen in the UEFI BIOS that was last open (the boot menu screen)
<Tirifto>nckx: Now I can follow Application Setup, right?
<nckx>mbakke: By the way: <I wonder if the udev service should unconditionally rm -rf /run/udev>, no Guix should mount a tmpfs there like all upstream software expects, or at least wipe *all* of /run at boot as required by the FHS.
<NieDzejkob>PotentialUser-23: I would expect UEFI to handle that without issue, but you never know
<NieDzejkob>boot firmware has the quality you'd expect from proprietary, never updated software
<mbakke>ahhh, I got one step further with debugging: the particular system I'm working on is new (to me) and has various hardware issues, apparently cold boot works, the whole /run/udev thingy was probably a red herring.
<Gooberpatrol66>i'm packaging a program which uses cmake. it can't find the headers for gtkmm, even though it's listed in the inputs. any advice?
<NieDzejkob>Gooberpatrol66: could you pastebin the package definition and build log file?
<nothingmuch>i have an old package definition, i updated the source to point at a new git tag but did not update the hash yet (was just going to let guix complain so i can get the new one) but it just happily built w/ the new tree... that's not supposed to happen, right?
<nckx>nothingmuch: If you use (git-file-name name version) as recommended, the sources will end up in /gnu/store/<hash>-<name>-<version>, so the directory will still change if you change the version, even if the sha256 stays the same.
<mbakke>serrvan: there is a guix channel that has various nonfree firmwares (you'll find it with a web search), but we can't help you on this support channel.
<nckx>nothingmuch: If you don't use git-file-name, and you don't change the hash, why would Guix even bother looking at the URL? It already has a checkout matching the hash in the expected /gnu/store/<hash>-git-checkout location!
<mbakke>lol, best novelty account I've seen in a while
<mbakke>it's awkward, AMD has a high-quality free driver, but it does not work without nonfree firmware; nvidia has a low-quality community-maintained free driver that somewhat works without firmware...
<PotentialUser-23>What the significance of the (use-package-modules certs gnome) in config.scm?
<roptat>I'm getting permission denied when the symlink and its target both belong to me
<nothingmuch>hmm, i'm really confused now. git-file-name is not used, TIL, lemme paste my full package definition in a sec... but i think the guix build output that *did* work is misreporting the version for some reason
<PotentialUser-23>For the GRUB bios bootloader should the target in config.scm be a drive (which seems to be implied) or a partition? The line of the config in questions is written as `(target "/dev/sdX")))` in the doc.
<roptat>bah it's not guile's fault, the parent directory belongs to root
<nckx>nothingmuch: If you didn't use git-file-name the file name (by which we mean /gnu/store/<hash, based *only* on sha256!>-checkout) won't have changed either. Guix would use whatever it finds there.
<nckx>So this is ‘expected’. The output not being what you expected is, of course, not…
<nothingmuch>nckx: that is in line with what i'm seeing, and i now realize why the program's --version is misreported too
<Tirifto>So I installed a bunch of packages and Guix now suggests I do ‘GUIX_PROFILE="/home/tirifto/.guix-profile"’ and ‘. "$GUIX_PROFILE/etc/profile"’. Am I correctly expected to add those to my profile manually?
<nckx>nothingmuch: Think of URLs as ‘hints’, or ‘directions to a file’ (hey, that's actually how they were intended! Everything old…). The ‘ID’ is the hash. If Guix already (thinks it) has the right file, it won't even look at the map.
<nckx>nothingmuch: Not idiot, just human. Embrace it 🙂 The alternative is much worse.
<nckx>Sorry, I've been reading too much French philosophy this week.
<tricon>Could use a pointer here as I am new to Guix. I am installing a pkg (Nomad) whose build script looks for Guile. Guile 3.0.4 is in my current profile. Guile 2.2.7 is in my Store. The Nomad build script does not find Guile 3.0, but it does find Guile 2.2.7. Do builds not consider only the current profile?
<nckx>Tirifto: It might not even be needed but I can't be sure on foreign etc.
<nckx>tricon: Packages are built in a completely self-contained environment that's identical across machines (yours & mine, so my running build just failed with the same error). It contains only the exact package inputs required to build.
<nckx>So yeah, our nomad package is just broken, nothing you install or remove will fix that ☹
<nckx>tricon: ‘configure: error: guile-gcrypt is missing; please install it.’ right?