<mroh>jonsger: was war das problem/die loesung? <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 <brettgilio>leoprikler: Guile is a lot closer to those guarantees than some other languages. <leoprikler>For ‘map’, the order of procedure applications is not specified <leoprikler>There is also stuff like let, which doesn't specify order <leoprikler>(nvm the fact, that your scheme code will inevitably be executed on a CPU, that doesn't guarantee instruction order either) <kekoso>hello, i'm trying to install guix in GUI mode but after manually partitioning the disk setup starts over. i install guix to external. Сan you tell me what i need to do? please <nckx>kekoso: Do you use NVME storage? <kekoso>SSD is installed on my computer, but I am installing GUIX on an external HDD <nckx>Maybe it's ‘weird storage in general’. <kekoso>strange that the latest ISO download link is not working <mroh>wow, the ghc-8.6.5 check phase creates 200+ ghc-iserv{-prof}.bin zombies and never ends... <nckx>mroh: Never or ‘never’? It finished here. <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). <nckx>mroh: Sorry, don't know, don't keep logs. <mroh>yay, its in install phase ;) <nckx>brettgilio: Er, ‘sluggish’ of course. I miss baseball… <nckx>sneek: later kekoso: I hope all goes well but if it still fails, please send a bug report to bug-guix at gnu.org (and mention the USB drive). TIA! *nckx → 😴, good night mroh and silent geeks. <guixy>What should I do if I don't want to start the x server on startup, but instead when I run a script? <guixy>So far I'm using xinit -- vt1 but unless I specify a timeout it locks my VM. <guixy>It does successfully start X and show xterm though. <pkill9>is there a library for parsing guix profile manifests? and is there a library for reading .desktop files? <bavier[m]1>profile manifests are just scheme code, so they can be `read` directly <bavier[m]1>idk about .desktop files, but I'd imagine they'd be simple to parse with just a loop and regex, since they are just `var=value...` statements <hendursaga>bavier[m]1: I'm on a fresh git clone, master branch. I'm not sure what the terms are - merge, rebase, what? ***verne.freenode.net sets mode: +o ChanServ
***verne.freenode.net sets mode: +o ChanServ
<pkill9>imagine if all software could be built without any extra arguments and such, so you could always jujst supply a url and everything would be built fine <guixy>Then guix wouldn't exist... you need to have options to specify where to treat their root. <guixy>And you wouldn't be able to specify which compiler to use. Some people are picky. <guixy>guile-build-system is closest to that though. <guixy>But you still need to specify which guile... <guixy>Things would be bland. display managers like SLIM accept theme specs as an option. <guixy>Although configuration can be a pain in the neck... it has a very good purpose. <guixy>it doesn't make sense to include X stuff in emacs if everything is headless... <guixy>But some people are fine using emacs over SSH or a serial connection. <pkill9>hmm, actually i meant desktop packages or packages used directly by the user e.g. on the commandline, and more like, sane defaults rather than not being able to configure the package <ArneBab>pkill9: so you mean "what if all software would work with `./configure ; make ; make install`? <ArneBab>There is one piece missing here, that’s getting the libraries you need. It would be great if we had a simple interchange format to define those. <ArneBab>I toyed with creating some format which gives package names for different package managers, but don’t have anything concrete yet. <pkill9>couldn't that be done with pkg-config *ArneBab is no expert of pkg-config <pkill9>that's a distro-agnostic identifier of packages <ArneBab>as far as I can tell that only lists the installed ones, otherwise: yes <Diagon>Hey all - wondering... Is there a guix-install.sh for non-root installs? <Diagon>I got my sysadmin to create a rw /gnu so I could install binaries, avoiding copilation. Now I'm seeing I need /var/guix and /root/.config/guix . Do I need to go back to ask for these? <Diagon>I also see we need a guixbuild group. Can I get away without this? Will the server run? <ArneBab>Diagon: it sounds like you want an overlay install <Diagon>Ok, not sure what that means ... <Diagon>I do just want the pkg manager, tho <Diagon>I did read the guix-install.sh script. <ArneBab>When I installed it on a foreign distro, I needed Guix itself in root <Diagon>Will the link answer those questions? <ArneBab>with a description that does not use the script, so it explains the why <ArneBab>but yes, you need build users and stuff in /var and so on <Diagon>It is possible to do without root. <Diagon>Thing is, if you don't have /gnu, then you have to compile everything yourself. <Diagon>Since I've got /gnu, I thought I was good to go, but now reading the scripts I see those other requirements. <Diagon>I'm trying to see if I can get around it, so I don't have to compile everything. (Or bug my sysadmin again.) <Diagon>*reading the script [eg guix-install.sh] <reepca>do we have a package that provides a "geckodriver" binary? <Kimapr>poor geany had its config directory converted to empty file <Kimapr[m]>is there a reason why %desktop-services is made as a (cons* and not (list? <Kimapr[m]>"(cons* ...)" and not "(list ...)"* (the question mark is not part of the procedure name) <Kimapr[m]>i think gdm always runs last no matter what because of that <Kimapr[m]>i don't think it should wait for say ntpd to load before starting ***apteryx_ is now known as apteryx
***Guest34917 is now known as psydroid
***psydroid is now known as psydroid[m]
***psydroid[m] is now known as psydroid
<iyzsong>raghavgururajan: i think it's 'gjs' from gnome. <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). <nckx>bhartrihari: <latest squeak release image> Which one? From where? <NieDzejkob>do other distros that provide squeak-vm also provide the images? <nckx>Not stupid. Plus, the home page link was broken in a non-obvious way (www. fails, non-www. works fine). <Kimapr[m]>Not really guix-related but how do you make setuid bash scripts actually do setuiding? i tried flipping the setuid bit up and that didn't work <bhartrihari>I just assumed that guix packages latest of everything. squeak doesn't seem to understand --version option, and it didn't occur to me to see the version using guix search. <bhartrihari>I do wonder why we are still at version 4.10 of squeak-vm. <nckx>Kimapr[m]: I don't think that's possible. It's definitely unsafe. <nckx>bhartrihari: Because 5.x doesn't mean 4.x but better. It's a different programme. See the link above. <Kimapr[m]>i want a script that writes 'mem' to /sys/power/state so that my computer suspends <nckx>I suggest linking to the image file in the description if packaging (due to its purely binary nature) is considered ungood. <NieDzejkob>Kimapr[m]: you can set up sudo to let you execute a specific script/command without a password <nckx>Kimapr[m]: Why shell? Use C :-) Even if you're C-phobic, that's a trivial C programme and a cool first one? <Kimapr[m]>Shell because it's too simple to be a compiled program i guess? <Kimapr[m]>I thought about making a program in a compiled language too (maybe not C, e.g. Rust) <nckx>A C programme is much simpler than a shell script & much safer than both setuid shell (if you can even get it to work) or sudo. <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>I see. Now I wonder how has it been working all these months with only the latter… <nckx>[…:]$HOME/.config/guix/current/bin:$HOME/.guix-profile/bin:$HOME/.guix-profile/sbin:… <nckx>Tirifto: You shouldn't add these entries yourself, but source /etc/profile.d/something-guix which should already be done by /etc/profile <nckx>If they're missing, that *is* wrong, best to find out why and not paper over it in your .bashrc or whatever. <Tirifto>No trace of Guix in /etc/profile.d or /etc/profile. <NieDzejkob>did you use the installer script, or did you install manually? <Tirifto>I used the installer script a while back. <Tirifto>I don’t remember ever being asked to do anything outside of my home folder though. :/ <Tirifto>I think I may have modified the path manually over sourcing the profile at some point in order to have the Guix paths explored last, but I’m not sure when or if that happened… <Tirifto>I guess deleting Guix and installing it anew should get things set up right? <Tirifto>(I'm only using it for two packages right now, so it would leave me with greater peace of mind than trying to fix my quirky setup.) <Tirifto>Removing ‘/gnu’, ‘/etc/guix’ and ‘~/.guix-profile’ should do it, right? <Tirifto>Another shade of awesome; thanks! :D <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>raingloom: AFAICS, no package includes LD_LIBRARY_PATH in their search-paths <NieDzejkob>you can try setting it manually with something like 'export LD_LIBRARY_PATH="$LIBRARY_PATH"' <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) <pkill9>then put that in a script/function <nckx>Tirifto: Good. It's the law! <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 <Tirifto>I’m wondering this: do most Guix users run login shells, therefore having Guix behave as expected, or do they source ‘/etc/profile’ or ‘/etc/profile.d/guix.sh’ from ‘~/.bashrc’? <NieDzejkob>/etc/profile should get sourced at least once during your login sequence, so... <Tirifto>Oh yeah, I reckon it did. But am I not expected to have the same variables set in the shell I use for interacting with Guix? <nckx>They're exported so will be omnipresent. <nckx>Tirifto: Did you manage to get it to work? <nckx>I added the ‘please log out & back in’ only this week, let me know if it needs to be stronger (‘Setup needs to restart your computer’). <Tirifto>nckx: Not yet, but I’ll try restarting right now! *nckx has no clue how all this modern desktop stuff works :-/ Does GDM handle this? <Tirifto>‘$GUIX_PROFILE’ is still empty. I’ll try to log in in another… one of those things you get with Ctrl+Shift+F[number] and see if there’s anything there. <nckx>Don't make me feel older than I already am. <Tirifto>nckx: Thanks! It was Alt+Ctrl, but ‘$GUIX_PROFILE’ was indeed defined there! <Tirifto>So if exporting those variables should propagate them to other shells… could it be they’re not getting exported? <nckx>guix.sh exports them AFAIK. You can list all exported variables with ‘export’. <Tirifto>My ‘/etc/profile’ does ‘. "$profile"’ where ‘$profile’ is each ‘.sh’ file in ‘/etc/profile.d/’. <nckx>Tirifto: If you simply ‘. /etc/profile’ in an XFCE terminal, are the variables set? <nckx>If so, we can rule out any bug in that and know that it's simply not being sourced by your desktop stack. <nckx>About which, as I noted in your absence, I know absolutely nothing ☹ <nefix>Hello! Is there something like rycee's home-manager for Guix? <nckx>I don't know who rycee is but roptat has guix-home-manager. <Tirifto>nckx: They are, and it also removes my custom prompt. <nefix>nckx: yeah, that was it. Thanks! (rycee is the author of the same utility for NixOS) <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. <nckx>Tirifto: Where you you set your custom PS1? <Tirifto>nckx: Well, that did not work for me. :P <nckx>I didn't expect it to, rebooting the machine would surely have restarted most services already 😉 <nckx>But it implies that, at least at some point, it did do the right thing. <nckx>This isn't a problem with your terminal, by the way. It's correct. <nckx>It shouldn't spawn a log-in shell and even if it did Guix would only work inside that terminal window, which isn't generally what one wants. <Tirifto>Oh, good. I’m trying to look up Arch/XFCE specific solutions now. <Tirifto>…might be time to switch channels! :D <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! <nefix>`/home/nefix/.config/guix/current/bin/guix` <nckx>nefix: That is the right Guix at least. <nefix>nckx: so, am I missing some step or something? <nckx>No, it doesn't work as documented. <nckx>It's also not in the --help output. <nckx>It's possible the docs are mildly out of date; for example I'd expect a channel introduction in the example snippet nowadays. <nefix>the channel introduction is used for signing the channel, right? <nckx>Yes. Mind you, it wouldn't fix this issue, it's just something I'd expect in a README written today. <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... <roptat>and yeah, no channel introduction yet <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>roptat: Is this a 3.0 bug? <Tirifto>nckx: Actually it looks like lightdm might be the cause. <roptat>nckx, not a guile bug, it's the way guix loads its scripts <nckx>OK. I didn't know that had changed. <roptat>I can't load a script that's not part of the default channel <nefix>roptat: thanks! It's working now! :D <nefix>Let's see if I can manage to install something and write my own definitions.... <nefix>maybe it would be useful to have it in the README <roptat>I remember there was an issue with the installation, but I don't remember if I fixed it yet :p <roptat>let me know if you have any other issue ^^ <roptat>(it was something to do with symlinks...) <nckx>I hesitate to ask, but did you ever bring up the Pulse issue with upstream? <nefix>roptat: yep! It wails with `guix home: error: readlink: The argument was invalid` (the description is my translation, so it might not be exactly like that) <nefix>(I had to manually create /home/nefix and change owner and permissions) <nefix>(And set the two variables that you said to /data/nefix/...) <roptat>let's see... what does /home/nefix point to right now? <nefix>if I delete it, it throws an error saying that the permission was denied when creating a symlink <nefix>but if I run it with sudo, it doesn't find the guix home command <jack1>NieDzejkob: This works great. Thanks! <roptat>nefix, try "sudo ln -sv /var/guix/profiles/per-user/nefix/home /home/nefix" <roptat>that should ensure the symlink is present <roptat>the guix home should be able to update the rest <roptat>or maybe sudo -E guix home might work <nefix>yeah, it seems to do the trick! (now it's doing something) <nefix>in another set of things, how can I control the audio volume? Neither alsamixer or pactl seem to be installed <mbakke>NieDzejkob: I'd try diffoscope, though it might be noisy. Maybe 'find | xargs du -h' ? <nefix>is it normal that the installation is still running? *civodul pushes improvements to (guix diagnostics) <roptat>nefix, probably not, the first install should not take too long <roptat>nefix, what does "guix home build /data/nefix/.config/guix/home.scm" say? <nefix>should I cancel the running command? <roptat>it's always ok to cancel a guix command <nefix>how much time should it take? <roptat>depends on what you have in your config, but the default one I propose should take no more than a few seconds <nefix>hmmm, so it's still running with the default config <roptat>oh, maybe guix is confused as to which version it is? Try to run explicitely /data/nefix/.config/guix/current/bin/guix home <nefix>(if it helps, it's a fresh installation with only weechat, icecat, chromium and two fonts installed) <nefix>should I try to start from the begining again? <roptat>give me some time, I'm pulling the newest guix and I'll try to produce the home configuration <roptat>let's see if a recent commit broke something :) <roptat>I don't think it will really help you, the instructions are really simple and they shouldn't affect guix's ability to build a profile <roptat>that was my substitute server not answering, ok now let's try guix home <roptat>nothing wrong here, it returns almost immediately <nefix>I've started from scratch, might have forgotten to export a variable or something <roptat>did you use sude -E, or did the symlink do the trick? <nefix>(had to do the symlink manually) <nefix>(with -E it failed too with the readlink: invalid argument) <nefix>should /home/nefix be a directory? <nefix>or should it be the symlink? <nefix>then I didn't make it properly <roptat>since the directory alraedy existed, ln created something inside it <nefix>now it doesn't even build again <roptat>build should be independent from your filesystem... <PurpleSym>mbakke: Thanks for merging the changes to beets so quickly! <mbakke>PurpleSym: np, I was "on a roll" :P <roptat>and I don't know of any unofficial script either <Diagon>I gather with a writable /gnu, I won't have to recompile everything. I got my sysadmin to create one, but now I'm seeing I need a /var/guix. Do I need to go back to ask for that? <roptat>not necessarily if you build guix yourself and don't run guix pull with the official channel <nefix>so, if /home/nefix is the symlink, the build command doesn't work at all <roptat>you could set your own localstatedir <nefix>but if I delete it (and everything is still in /data/nefix), it does work! <roptat>but then you can't reconfigure, can you? <nefix>and if I run it with sudo -E, it says the thing about the invalid argument <Diagon>roptat - thanks. so I'll put that and /root/.config/guix in my home dir... But I also see a guixbuild group. Anything I should know about doing without that? <roptat>I don't know, it's the build user that the daemon uses to delegate builds to <roptat>but if you're not running the daemon as root, then I don't know what happens <Diagon>Anybody on this channel who might have run a system like that? <roptat>nefix, I'll try running in a fresh VM and fix the instructions <Tirifto>nckx: I tried a different display manager and nothing has changed. >_< <mbakke>uh, so I rebooted a machine on an upcoming staging branch that includes PAM 1.4.0 among other things, and it failed to start <mbakke>not only that, but prevous generations also failed to start! <mbakke>I was able to fix it by booting a live USB and run "rm -rf /mnt/run/udev" after mounting the hard drive <mbakke>did not save a copy to inspect the differences, but I wonder if the udev service should unconditionally rm -rf /run/udev before populating it? <mbakke>gdi, now it boots just fine, too bad I did not save a copy (I did not really expect it to work...it was one of the few directories that had mtime 0) <Tirifto>nckx: At this point, is there anywhere else I could get ‘$GUIX_PROFILE’ from, other than ‘/etc/profile.d/guix.sh’? <nckx>I'd say that's the canonical place. It's not that magic a variable on its own; it's the rest of guix.sh that makes packages installed with Guix actually work. <mbakke>ah, previous generations are still failing, but the current one works now <nckx>‘By default, /etc/lightdm/Xsession is run. The script checks and sources /etc/profile …’ <mbakke>I don't understand what could be causing this issue, there is nothing PAM-related in /lib/udev that I can see... could it be the kernel upgrade (5.4.52 -> 5.4.53)? <mbakke>anyone feel like breaking their system? :P <nckx>mbakke: …that said, which branch? I might not be able to control myself 😈 <nckx>Tirifto: Is $HOME/.guix-profile a symlink? <nckx>Tirifto: Hm, actually… any hypothesis I had doesn't explain why manually sourcing /etc/profile.d/guix.sh *does* work (it did, right?). <Tirifto>nckx: It does not exist yet. (I figured the variable was just string-based, since I could set it and it does get set when logging in a vtt.) <mbakke>nckx: I did not push it yet, but considering it despite the terrible breakage... 'guix system vm' and various system tests work fine. <nckx>Tirifto: ‘String-based’? <nckx>mbakke: Push it to ‘staging-danger’ or so? <Tirifto>nckx: As in ‘when you set the variable to “$HOME/dir”, it won‘t care whether “dir” exists or not.’ <nckx>Tirifto: The variable doesn't care but maybe guix.sh cares too much. <Tirifto>I’ll try right now, and I had another idea that might explain this… <nckx>Keep in mind that I don't use Guix on foreign distroes, I do my best to maintain the script based but that's it. I rely entirely on bug feedback. So thank you. <nckx>-based. The script is not based. <Tirifto>nckx: Huh! It does not! Even though it *is* set, ‘export’ does not list it. <nckx>That's actually what I expected. <Tirifto>Sounds like you might know what’s wrong! :D <Tirifto>I was also wondering if ‘$HOME’ is known when ‘guix.sh’ gets sourced. <nckx>Honestly, I was so focused on the why-no-/etc/profile bit that I forgot your exact initial bug report. What were you expecting, and what didn't happen? <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.) <Tirifto>nckx: That was before I reinstalled Guix; I have no packages installed now. <nckx>Now I'm puzzled that you have ‘packages installed’ but not .guix-profile. <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’ <nckx>Install whatever you want, hello is fine. <nckx>I'm guessing ‘hello’ doesn't work yet? <nckx>Ignore that. Log out & back in, if you can. <Tirifto>nckx: Indeed, everything seems to be alright! <nckx>Happy to hear that! of course. <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>Complex emoticon of a big smile! ⁽\°_°/⁾ <nckx>You said you modified the paths to move down the Guix ones… is it possible you subtly edited guix.sh and replaced it with the stock version whilst debugging? <nckx>Yes, I'm grasping at straws here. <nckx>(…or something like that?) <nckx>Otherwise I doubt we'll ever know what happened. 🤷 <Tirifto>Oh, no; I did that before I reinstalled Guix today (or yesterday—not 100% sure). <Tirifto>To me it looks like whatever program was in charge of reading and sourcing ‘guix.sh’ just dropped the file at some point. <Tirifto>Something in the default ‘guix.sh’ probably caused that, and stopped causing it once a program was installed. <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>I think I had no ‘guix.sh’ then though. <Tirifto>Some profile fire used to get sourced from my Guix profile directory symlink, but I did drop it because I wanted the PATH to follow a different order. <nckx>Tirifto: That's possible. It wasn't added until 28 December 2019. guix-install.sh is much older. <nckx>It = /etc/profile/guix.sh. <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. <NieDzejkob>PotentialUser-23: You've come to the right place! Any error messages, or...? <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: Yeah, I’ll try to be more careful with this installation. Modifying path later seems like a good solution if necessary. Thanks a lot for walking through this with me! :-) <nckx>You're very welcome, thanks for killing your session whenever I asked you to! <mbakke>hm, so the 'rm -rf /mnt/run/udev' trick still does not let me boot older generations <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: on the UEFI firmware in my laptop, the .efi file *must* be in BOOT/BOOTX64.EFI - try copying /boot/efi/EFI/Guix/grubx64.efi to /boot/efi/EFI/BOOT/BOOTX64.EFI <nckx>It might not fix your bug of course. <nckx>I basically forked %base-file-systems years ago, I didn't know /run was still persistent 🙂 <serrvan>I'm trying to install guix system on my laptop but after choosing partitioning method and hitting enter it retests the installation process and starts from beginning <mbakke>NieDzejkob: that location is what the UEFI specification mandates to auto-discover bootloaders (i.e. for live USB installations), it sounds like your system is unable to update EFI variables? <nckx>serrvan: Do you use an NVME device? <nckx>(serrvan: You weren't here yesterday under a different name, were you?) <nckx>If not, this is a daily occurence, also not good. <mbakke>I believe the bug in question has been fixed though, so we should push that 1.2.0 release soon :/ <serrvan>No, this is the first time i try to install guis system <nckx>mbakke: Yes, it's fixed by the /latest link (which is the next item in my support checklist), but y'day someone had that symptom without the NVME. <nckx>And let us know how you fare. *nckx doesn't really have a support checklist, but if they did it would have little hearts as bullet points because Guix ♥. <serrvan>this might be cuz of the nginx buffer size <nckx>serrvan: Good guess, but it's just the Web frontend being dorky. I fixed it by restarting it :-/ <PotentialUser-23>I noticed that my Windows 10 installation actually doesn't boot from UEFI. Maybe I could reinstall in legacy BIOS mode? <nckx>It's worth a try if you don't care about UEFI (or need it to boot something else). <serrvan>nckx: you can't be around all the time, think some sort of automatic restart or something similar <nckx>serrvan: You'd be surprised, but I agree. <PotentialUser-23>I went and disabled SecureBoot, and despite that the "Launch EFI Shell from filesystem device" option still complains about Secure Boot being enabled. <serrvan>nckx: is it take some time to build the latest iso file? this might be the issue if that's the case you can increase the timeout val <nefix>roptat: any luck? I might disconnect later, so I'm not sure how to check whether you find a solution or not <NieDzejkob>serrvan: the ISO file is being built before you issue the request <NieDzejkob>the issue is that the entire web frontend sometimes hangs/crashes/$something <roptat>nefix, it'll probably be fixed tomorrow, but I need more time :) <nefix>roptat: sure, no pressure! It was to make sure I could do it. Sorry for bothering you <serrvan>NieDzejkob: i see but the point is if something behind nginx hangs for some reason and you know it's going to hang at random time then you should increase timeout accordingly <roptat>no problem, I'm happy to help, but have other things to do too :) <PotentialUser-23>Btw, are there any already open bugs relating to manually partitioning in the graphical install? <nckx>serrvan: It would hang forever. <nckx>I think a virtual /download/latest/guix-latest-x86_64-linux.iso link that returns a stale cached response after 10s or so would be better. <nckx>If I can figure out how to express that in using Guix's Scheme wrapper syntax. <nckx>…and we don't care about the file name. <serrvan>nckx: actually it's not going to hang forever if you know the avg val for the download process time and set nginx timeout to it <serrvan>i can help with the nginx but i'am not familiar with guix scheme <nckx>proxy_connect_timeout ∞; <nckx>(There's a hard limit of 75s, anyway.) <mbakke>nckx: lol, yes, I don't even understand myself, much less the OS I'm trying to make :P <mbakke>maybe I just don't like documentation "talking" to me <nckx>serrvan: The average of ‘it hangs forever’ is… more than that. <nckx>If it really bothers you I'll take it out. <nckx>mbakke: It just felt… personal, since that was just me writing me. <mbakke>nckx: I think personal touch is good! I probably just have some bad association to that term, idk. <PotentialUser-23>Maybe my boot issues are related to the EFI partition being in the last 1100GiB of an 8TiB drive? <nefix>how are vim / neovim plugins managed? <nefix>is there any way to package them? <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. <NieDzejkob>nefix: there's a vim-build-system and you can install them to your profile, but you need to add the right directory in ~/.guix-profile to your runtimepath manually <PotentialUser-23>NieDzejkob: I'm going to see if I can shrink the Microsoft reserved partition at the front of the disk by 1 MiB and slide in a legacy BIOS boot partition <nefix>NieDzejkob: I didn't understand the last part, sorry :S *mbakke reconfigures their trusty work horse laptop on that wip-staging branch <NieDzejkob>nefix: how well do you know vimscript? with the right patch, we could get this to work out-of-the-box <nefix>I've tweaked my configuration, but nothing further <nefix>I'm coming from NixOS, where there's a standard way to package vim plugins, and you can use them as normal packages, add them as dependencies, etc etc <nefix>NieDzejkob: so, if I understand correctly, with rtp you say "search plugins also here", and here is where the derivations are build, right? <NieDzejkob>here is where the packages are installed*, but yeah <nefix>And where do the packages come from? <NieDzejkob>derivations get built in /tmp/guix-build-foo-* and the results are stored in /gnu/store <nefix>I mean, are there already definitions in the guix repository? Or do you have to build them? <NieDzejkob>the packages come from package definitions in the guix repository, or other channels <nefix>yeah, I've read that part! :P <nefix>And is there a plugin example or something like that? <NieDzejkob>you could try something like 'guix edit vim-neocomplete' <NieDzejkob>make sure to send any packages you write our way at (info)Contributing :D <NieDzejkob>(guix edit is a *bit* of a lie, in a normal installation managed with guix pull it's more of a guix view) <Tirifto>Question: in comparison to ‘glibc-locales’, the manual says that ‘the “glibc-utf8-locales” is smaller but limited to a few <Tirifto>UTF-8 locales.’ Does this mean ‘glibc-utf8-locales’ supports fewer languages to the same extent, or are there more limitations? <nefix>I'll do so if they're usable! xD <NieDzejkob>(it actually lets you edit in a ./pre-inst-env in a git checkout, again see the contributing section) <serrvan>nckx: after downloading latest version, it's working now, thanks <NieDzejkob>glibc-utf8-locales should really be called glibc-locales-for-tests, tbh <NieDzejkob>it only contains de_DE, el_GR, en_US, fr_FR and tr_TR <nckx>Tirifto: It's a super-arbitrary collection of locales. <nckx>‘Something needed this once.’ <NieDzejkob>(which I know because I did tree -d `guix build glibc-utf8-locales`) <Tirifto>So if my locale is fr_FR, it’s a convenient way to get localisation for less space? :P <nckx>A much better way is to use locale-definitions on Guix System, but on a foreign distro I guess you're stuck with that. <nckx>(You could still create your own locales-for-tirifto package and put it in a channel, but that's starting to feel like work.) <lfam>nckx: We actually added one of them (GR I think) based on user request ;) <lfam>"Someone needed this twice" <nckx>lfam: I'd first typed ‘it's a random me-too language list of the first Guix contributors’ but that felt a bit sharp 🙂 *nckx is not too sharp but very extra. <Tirifto>nckx: Oh, yeah, I might look into that later. So far I tried making one package and that didn’t exactly work, so I’ll need to get to know Guix a bit better first. <nckx>Tirifto: Glorious that you tried! <Tirifto>Wow, that took about three seconds to install. Sweet! <NieDzejkob>if you try to package something again and it doesn't work out, say hi and we'll help :P <Tirifto>Also, this keeps popping up: /gnu/store/29jhbbg1hf557x8j53f9sxd9imlmf02a-bash-minimal-5.0.7/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.utf8) <Tirifto>‘/home/tirifto/.guix-profile/lib/locale’ <NieDzejkob>maybe it's coming from the daemon-side guix substitute, or something? <Tirifto>Yes. It contains the directory ‘2.31’ with a bunch of ‘[code].utf8’ directories and a bunch of ‘[code].UTF-8’ directory symlinks. <NieDzejkob>you might need to install glibc-(possibly utf8)-locales in root's profile <Tirifto>Should I do that with ‘sudo -i guix install glibc-utf8-locales’? <Tirifto>(The manual advises ‘sudo -i guix pull’ for upgrading the build daemon.) <Tirifto>Ah, forgot to pull on the daemon. Out of context that sounds like something you generally don’t want to do if you value your life. <Tirifto>And for sure I’ll ask around here about packaging! I’ll just get something functional (in more ways than one) to package with first. :P <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? <NieDzejkob>nothingmuch: the fixed-hash derivation is identified primarily by the output hash <NieDzejkob>sometimes this doesn't happen because the filename changes <NieDzejkob>(since git-file-name includes the commit in the file-name...) <NieDzejkob>I just managed to fix a bug that's been on my TODOs since I started using Guix <roptat>nefix, ok, so guix tries to mkdir ~/.cache in a loop, but fails to do so then retry, so it never gets to build anything when there's a symlink to /var/guix/... that doesn't exist yet <roptat>if /home/nefix points to /data/nefix, I can indeed build the home profile, but I can't reconfigure because guix home is being very cautious not to remove your home directory <nefix>roptat: I see, that makes sense, since when I did build, it created /home/nefix/.cache <roptat>I guess it could test if it's a symlink and replace it in any case <nefix>and if I modified the $HOME var? <mbakke>NieDzejkob: congrats! :-) how did you solve it? *mbakke is still working fine after a reboot on staging <roptat>nefix, no because then your home directory is /data/nefix and guix home will try to replace *that* <roptat>it's always challenging to think about it ^^ <NieDzejkob>mbakke: after some gdb and strace, I realized that it's only checking paths ending in .png, while the theme is .svg. Adding qtsvg to the deps makes it work <mbakke>serrvan: you need to type your passphrase again so linux can unlock the hard drive (the first time was just for GRUB) <nefix>roptat: and what about setting a temporary env var to point the good home path? e.g. GUIX_HOME_MANAGER_HOME=/home/nefix and set HOME=/data/nefix <mbakke>serrvan: there is a well-hidden line "Enter passphrase for ..." <serrvan>mbakke: I've typed passpharse two times <roptat>and it wouldn't affect guix internals that try to access $HOME/.cache anyway <nefix>roptat: hmmm, so how it could be solved then? :think: <roptat>I need to fix it in the channel's code <mbakke>serrvan: what is your graphics driver? at this point I would expect kernel mode-setting to kick in <NieDzejkob>serrvan: I get an "Image not found" error on your link <serrvan>NieDzejkob: dunno why, i can open it and i believe mbakke can too <serrvan>mbakke: i've got lenovo thinkpad E495 <nothingmuch>NieDzejkob: can you explainwhat you mean by the filename changing? in this case it's a git URI, so not a single file <mbakke>serrvan: right, AMD GPUs require nonfree firmware to function, so the radeon driver does not work on linux-libre :/ <mbakke>serrvan: it's possible you can boot to a framebuffer console by adding "modprobe.blacklist=radeon" <mbakke>in the GRUB menu (by pressing 'e' at the prompt) <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>it would be good to have a general workaround for radeon cards on linux-libre, so it was at least possible to log in at the console <nckx>nothingmuch: And since Guix doesn't save ‘this /gnu/store/source came from this git URL’ (why would it, right?), it can't detect changed URLs. <tricon>Nvidia announces first-party support of nouveau. AMD's response: ¯\_(ツ)_/¯ ***nckx is now known as AMDinc
*AMDinc ups the budget for the ‘buht AMDGPU is teh free softwares?!’ forum spam army. ***AMDinc is now known as nckx
<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? <PotentialUser-23>I noticed the graphical installer didn't include it in the config.scm that it generated. <nckx>PotentialUser-23: Variables are defined in modules, you need to import the module that provides the variables you need in order to use them. <nckx>My guess is you use nss-certs somewhere? Same for gnome[-something]. If you don't, they might not be needed (comment them out, run reconfigure, find out 🙂). <nckx>(use-package-modules a b…) and (use-service-modules a b…) are simply syntactic sugar for (use-modules (gnu packages a) (gnu packages b) …) to save on boilerplate if you use many. <nothingmuch>nckx: the git commit hash has changed (referenced by tag), as did the git tree hash, so it's different files.. building it on another machine did result in a hash failure as i expected <nothingmuch>nckx: the guix build output of the one with the non-updated guix hash (the base32 sha256) did build from the right git checkout <nckx>nothingmuch: Which different files? Do you use (git-file-name …)? <nckx>That should not happen (and while not impossible, it's very unlikely that you found a bug). <roptat>mh... delete-file can't remove a symbolic link? <nckx>Humans (including me) suck incredibly at keeping hashes/versions/anything apart in their head compared to Guix 😛 <nckx>roptat: It can, even to a directory. <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. <Tirifto>(Err, ‘$GUIX_PROFILE’ is still set properly, so… I guess I should just do ‘. $GUIX_PROFILE/etc/profile’ and ignore the first line, if anything?) <nckx>* nothingmuch is enlightened. <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. <tricon>FYI, I am on a foreign OS (Arch Linux). <nckx>tricon: Are you installing it using ‘guix install nomad’ or similar? <nckx>Guix packages don't consider your user profile (or any other system state) at all. <tricon>@nckx: guid package --manifest=/path/to/manifest -i <tricon>@nckx: I see, that is helpful, thank you. <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? <nckx>I guess nobody uses nomad… <tricon>nckx: Guix is so cool. I appreciate all the work being done on it. <nckx>I'll try to fix it but I know nothing about it. <roptat>sneek, later tell nefix I fixed it and updated the README. you should run "guix pull" again to get the latest code, then create the two symlinks like the instructions now say <nckx>tricon: Pull and try again. <Noclip>It didn't modify .profile, .bashrc or /etc/profile. <nckx>In ~/.guix-profile/etc/profile. 