<rekado_>I have a server with GuixSD and I added support for LDAP accounts. <rekado_>I’m reconfiguring the system now and wondered why it takes so long. <rekado_>Turns out Guix is trying to delete all LDAP groups. <nckx>Pigeon: That's just because the GRUB configuration for an encrypted system is identical to unencrypted ones :-) <Copenhagen_Bram>Ooh I just had an idea: Suppose one had a 'boot' partition, installed a full guix system in the encrypted partition, and put a second bootloader in the boot partition that points to the encrypted partition? <Copenhagen_Bram>you'd have to go through grub 2 times (or 3 if you use libreboot with grub) <nckx>Copenhagen_Bram: Wouldn't it have all the drawbacks of the current approach though, while just being slightly slower? <nckx>ACTION is trying to imagine how that would work. <nckx>What we really need is to copy the kernel & initrd out of the encrypted volume to /boot/... at (re)configure time. It shouldn't be hard, just a bit tedious, and nobody's done it yet. <nckx>Copenhagen_Bram: I'm afraid I can't parse your last line. <Copenhagen_Bram>nckx: depends on whether it's the bios that is slow to decrypt or if it's grub that's slow <nckx>Copenhagen_Bram: But the BIOS doesn't decrypt anything. <Copenhagen_Bram>or does it? is there more to learn about how a full disk encryption works? <nckx>Well... If your BIOS embeds and launches a copy of GRUB, that's just GRUB loaded from a different place doing exactly the same thing... <nckx>But I see what you meant now. <Copenhagen_Bram>my theory is that if you're decrypting something from a chip in the motherboard, that might just be slower than it should be <Copenhagen_Bram>also my theory is that my crazy plan of having an unencrypted boot partition (boot, not /boot), installing grub to the encrypted partition without mounting anything to /boot, and then adding bootloader to the unencrypted partition, might just work. I'd like to start exploring that theory tomorrow. <Copenhagen_Bram>that is if I don't run into something that holds me back. Which could happen because I'm new to guixsd. <nckx>Copenhagen_Bram: But what does that solve? <nckx>Having to enter your passphrase twice? Having GRUB do the decryption the first time? <Copenhagen_Bram>well if i'm right, and decryption from libreboot is slow because it's from the bios, then when i load the bootloader off the hard drive and use it to decrypt the full guix system, it'll be faster <Copenhagen_Bram>now i'm wondering if there's a way to simulate that slowness in qemu <nckx>Copenhagen_Bram: Oh. I've never used Libreboot before, but I'd be very surprised if that did anything. ***anon is now known as Pigeon
<nckx>Surely a ROM chip is faster than a hard drive. <nckx>I'm guessing, maybe the ROM is mapped into RAM but that would only affect the very first stage of GRUB loading. <Copenhagen_Bram>but anyways even if it isn't any faster than how long it takes when I have to type in the command manually to boot my drive, I can just point a second bootloader to my guix system, so no more manual command typing <nckx>Copenhagen_Bram: OK. One of us is missing something crucial, and I honestly hope it's me :-) <nckx>I don't want you wasting your time. Just have fun. <Copenhagen_Bram>nckx: don't worry, I'm not stupid enough to just do a thing like that to my computer. I'm gonna try it on qemu, for sure <nckx>Copenhagen_Bram: Hehe... you just called me *very* stupid then. (^_^) <nckx>(Bare-metal hacking on GRUB is *fun*, just so you know. And addictive. Be warned. G'night!) <Copenhagen_Bram>Copenhagen_Bram, GRUB hacker. *smiles and continues mopping the floor* <lyr3>hey I want to add /usr/bin/env via extra-special-file but I am too dumb to see what is wrong... <lyr3> (services (extra-special-file "/usr/bin/env" <lyr3> (file-append coreutils "/bin/env")) %desktop-services) <lyr3>error: invalid field specifier <OriansJ``>lyr3: you need it to be (service special-files-service-type `(("/usr/bin/env" ,(file-append (canonical-package coreutils) "/bin/env")))) <lyr3>(services (service special-files-service-type `(("/usr/bin/env" ,(file-append (canonical-package coreutils) "/bin/env")))) %desktop-services) ???? <OriansJ``>it also remove the need for %desktop-services and a bunch of other things I didn't need <lyr3>OriansJ``: I intend to do that too. %desktop installed a loooot of packages! <OriansJ``>well, then what I posted is exactly what you need <lyr3>OriansJ``: do you prefer to install packages for allu users (reconfigure) or locally (guix package -i)? <lyr3>It seems easier to handle through guix package rather than reconfigure... <OriansJ``>lyr3: for things that need to be common, like shadow-utils and the login screen must be shared. But generally outside of a minimal core, I expect users to have their own preferences <lyr3>interesting! thanks, I will analaze you config! haha <OriansJ``>So the example I provided includes many things I expect on a desktop and could be removed; such as torsocks and icecat <lyr3>I thought that most guixsd user prefer global packages rather than user..interesting! <lyr3>where i get more info so I to remove %desktop safely? <OriansJ``>lyr3: if you look at the config I posted, it doesn't need %desktop and provides i3-wm <lyr3>yep, I noticed. I barely know what %desktop-service provide, so I am rather confused on how to remove it safely... <lyr3>I will take my time reading you config and guix manual! haha <OriansJ``>lyr3: the really simple way to see what %desktop-service provides is simply do a git clone on the guix repo and grep -iR %desktop-service . to find the definition <lyr3>did that, it issue a lot of entries haha <OriansJ``>(define %desktop-service was a dead give away <lyr3>emacs grep-find is so cool! haha <OriansJ``>as for why I prefer minimalism and individual control, probably is the same reason I am part of the guixsd bootstrapping effort (we are on #bootstrappable in case you are curious) <lyr3>OriansJ``: haha, cool, interesting approach, I like it! <Copenhagen_Bram>How do I get my graphics card in action so I can play games? Do I just install xf86-video-intel? Do I install it with guix package -i or add it to config.scm and system reconfigure? <lyr3>AMD gpu shoul work out of box, same goes for intel, cant say about nvidia ones <lyr3>noveau aint that perfoming <lyr3>wow, reading guix source code shows how charming is scheme.... <lyr3>yep, I will probably erase my existence! hehehe <lyr3>nah, just delete all lyr3 accounts...hehehe <pkill9>i have no packages in my default guix profile, i split them up into separate profiles <OriansJ``>Copenhagen_Bram: traditionally that is triggered by either an init script or a program like logind <OriansJ``>because the guix store is immutable by design. <Copenhagen_Bram>How do I get guixSD to stop suspending on lid close? How do I edit logind.conf? <mange>You'll have to modify your system configuration file and reconfigure your system. <mange>I don't know the details of how to do that specifically. Have you checked the manual? I don't know if it says anything helpful. <mange>In particular, handle-lid-switch. <mange>So you'll have to modify the elogind service to change that setting. <mange>I haven't tested that at all, but it should hopefully give you enough to go on from. <mange>Put it in place of %desktop-services. <mange>It returns a new list of services that is %desktop-services with the modifications having been applied. <brendyn>cannot link `/gnu/store/.links/1r9hlr9f751mz9577bl703w0x0xgdq50v0bxcfmgvr2d79p9bm6q' to `/gnu/store/v6z4q0vsal4ilj44d997qf6wxzd0g1mj-guix-daemon-0.14.0-12.77a1aac/libexec/guix/list-runtime-roots': No space left on device <brendyn>I'm getting this while running guix pull but I have 60GiB free <mange>Are you having trouble reconfiguring your system? <mange>brendyn: What filesystem are you on? <mange>Hmm. Well, I know nothing about filesystems, and my quick search only points to a lack of inodes being a potential problem. Can you check the output of df -i? <brendyn>My GuixSD has been kinda borked for a while now. Can't run guix pull <brendyn>now I'm getting guile: warning: failed to install locale <mange>At this point I'm definitely out of my comfort zone, though. <brendyn>I'm running guix gc to see what happens <brendyn>I'm finding I have no locale command now <roptat>\\o/ I've corrupted the store with guix pull <roptat>unfortunately, guix got corrupted <roptat>not sure how I can recover from that :/ <Copenhagen_Bram>roptat: ouch, how did you do that? And do you have a guixsd live usb drive? <Copenhagen_Bram>do I need to restart after using guix system reconfigure? Does `guix system: error: symlink: Permission denied: "/var/guix/profiles/system-2-link.new"` mean I have to run guix system reconfigure as root? <g_bor>hello roptat! I'm also interested how did you do that? <g_bor>Copenhagen_Bram: yes, you have to run system reconfigure as root, and while most of the things get updated without reboot, you need a reboot to get all things updated. This notably includes the guix-daemon itself. <g_bor>Copenhagen_Bram: guix pull updates the pre user guix. It does not touch for example system packages. :) <g_bor>Copenhagen_Bram: guix pull as root pulls guix for the root account. For the system packages to be updated you need a guix system reconfigure. You need root privileges for that. If you do a system reconfigure as root, the root's guix is used. <g_bor>It is possible to do a reconfigure using a user guix with sudo -E (this preserves the env, so the user guix is found). <Copenhagen_Bram>is it okay to kill guix while it's doing `compiling... 100.0% of 179 files`? <g_bor>if it is not, the it is a bug :) <rekado_>Copenhagen_Bram: it is okay to kill it at any time. <roptat>Copenhagen_Bram: I ran out of memory <roptat>guix pull was killed at exactly the wrong time <rekado_>Copenhagen_Bram: it’s atomic and does not change the system in place. <roptat>when it was killed, I got "guix pull: error: corrupt input while restoring archive from #<closed: file 31742a0>" <roptat>then "cat `which guix`" shows complete garbage <roptat>the first line says " sáraíonn an sainmhíniú ar `%T' an ceann coitianta" <roptat>which it isn't anymore on my system :/ <roptat>I don't want to reboot, I'm pretty sure it won't start at all <g_bor>Copenhagen_Bram: see swap-devices in the operating system reference. <roptat>yes, I'm not sure where it comes from, but I see things I can recognize <roptat>like "ní féidir athróg '%T' a uathiompórtáil. Léigh an doiciméadú "ld" ar --enable-auto-import chun na mionsonraí a fháil." <roptat>but I don't understand why it got modified <roptat>readlink -f `which guix` is in the store <roptat>it's the same store path as before running guix pull <roptat>linked to from the only generation at .config/guix/current <Copenhagen_Bram>roptat: can you copy the text in guix to your home directory for later translation? <Copenhagen_Bram>and hmm, maybe you can look through /gnu/store for some form of guix that does work? then add that to your $PATH <roptat>Copenhagen_Bram: need to go now, but I'll be back later <Copenhagen_Bram>jlicht: Should I install graphics drivers as a system-wide package in config .scm? <jlicht>Copenhagen_Bram: I've never had to fiddle with graphics drivers on my GuixSD system, so I wouldn't konw :) <Copenhagen_Bram>huh, how does that work? When I had guix and gnome, I tried playing a gif and it didn't work <jlicht>I use i3 as well, and afaik, it uses Xorg. (Sway is a i3-clone for Wayland btw) <jlicht>Copenhagen_Bram: I am reasonably sure I do need those. It's just that I never had to explicitly install them as far as I can remember. FYI, I'm running GuixSD on a librebooted T400 <civodul>what's the story with gst-plugins-base on i686? <Copenhagen_Bram>jlicht: mpv works, but the sound is really quiet. How do I turn it up a bit? <jlicht>snape: you could check out ambrevar's mu4e-conversation, if you like different ways of working with mu4e <snape>Copenhagen_Bram: ha! So you gave up about having a separate unencrypted /boot partition? <snape>jlicht: cool! I'll check it out now. <snape>s/now/when I find some time/ :-) <snape>yes I read you were talking about that <civodul>Copenhagen_Bram: no, "i386-pc" in GRUB terms designates traditional BIOSes <snape>ACTION is going to have another coffee. Sending guix paches at 3am and going to work next morning is not a good idea... <Copenhagen_Bram>jlicht: i just tried to play minetest, framerate was only 11 then went down to 3. Do you get that? <jlicht>I am able to somehow play fullscreen youtube video on the T400, but not if I'm also running `guix pull' in the background. My guess is that gaming on the T400 might be best limited to nethack and similar games ;) <Copenhagen_Bram>jlicht: try playing freedoom, i've found that odamex runs really well <Copenhagen_Bram>jlicht: so if the T400 sucks for gaming, how come when I was on parabola I could play minetest at 40 or so fps if I started it right after I booted? (until the framerate dropped to a single digit) <jlicht>I'm not saying it sucks for gaming, it just is not a gaming powerhouse. I do not know why there is such a discrepancy between gpu performance on GuixSD and parabola though ╮ (. ❛ _ ❛.) ╭ <snape>Copenhagen_Bram, jlicht, are you both using T400? <jlicht>It might just be a simple configuration setting somewhere. If you do find out how to increase performance on the T400, please do let me know though. <rekado_>civodul: there is no new version of opus AFAICS. <rekado_>civodul: I don’t know if this is just a problem with opus on i686 or with gstreamer itself. <rekado_>as a stopgap we could remove opus from the i686 variant. <jlicht>is Guix(SD) still committed to support i686 in the forseeable future? <rekado_>(I’m also using i686 hardware myself FWIW) <rekado_>curiously I did not have a problem upgrading my i686 machine after the core-updates merge. <pkill9>Copenhagen_Bram: what's the problem with minetest? <Copenhagen_Bram>when I move the scroll bar with the mouse, I see white 'spots' flashing along the length of the scroll bar <pkill9>just after boot or all the time? <Copenhagen_Bram>btw where do I put commands to export environment variables that guix recommends? <pkill9>i put them in ~/.profile, but you'l have to relogin <Copenhagen_Bram>do you have to remove the environment variable command after reboot? <pkill9>it does add them to ~/.guix-profile/etc/profile <pkill9>you can just source them in ~/.profile <pkill9>i assume you're using foreign distro <pkill9>GuixSD will source them automatically , but you have to relogin to have them applied <g_bor[m]>Oops, after guix pull I get a backtrace stating that no variable is bound to define-module* <snape>pkill9: GuixSD sources ~/.profile automatically? <snape>I meant ~/.guix-profile/etc/profile <g_bor[m]>I also can't seem to get my build working. configure now complains, that there is no recent enough guile-sqlite3 <pkill9>maybe -DENABLE_REDIS=0 affects minetest performance? <pkill9>i'll make you a package that inherits minetest and adds that configure option <rekado_>g_bor[m]: did you try “./pre-inst-env guix environment guix”? <rekado_>g_bor[m]: the “guix pull” problem is a problem with Guile. You may need to try again. <g_bor[m]>rekado_: thanks rekado_, trying again did help. <g_bor[m]>rekado_: where can I get more info from this guile peroblm? <nee`>I tried to package yesod-bin 1.4.5 and got into a mess of up/downgrades for haskell packages. What is the current update/import strategy for haskell packages? Are stackage LTS sets somehow considered, yet? How can I import packages for the LTS that the rest of guix uses? <Copenhagen_Bram>pkill9: it says you missed a paranthesis, lemme see if i can edit that <Copenhagen_Bram>pkill9: the people in #minetest said that that cmake option probably wouldn't improve performance, but I'll try it anyway <rubenwardy>Redis isn't used unless you choose to convert a world to it <pkill9>Copenhagen_Bram: what graphics card do you use? and do you use any particular drivers on parabola? <roptat>Copenhagen_Bram: the French you see is from the French manual <rekado_>g_bor[m]: Guix bugs 27476 (27652,31740…) <roptat>I think I didn't fix the links properly, the French sections are still pointing to (guix) instead of (guix.fr) <rekado_>nee`: the importer does not consider LTS versions. We should update it to prefer LTS versions. <nee`>rekado_: Thank you for the info. <platoxia>On GuixSD, after 'guix pull' as root I get "guix: system: command not found" when tryting to reconfigure. <pkill9>running `guix build -f` doesn't overwrite anything <pkill9>if you installed it with `guix package`, jsut run `guix package --rollback` <pkill9>`guix build` doesn't modify any profiles though <nyberg>Just wondering how I would add an entry for booting guix on my x220. Currently using gpt but seems the BIOS doesn't detect the grub partition at all. I can boot if I load the grub configuration from a livecd but anything else fails. <g_bor[m]>after the second guix pull succeeded the problem with guile-sqlite3 is also gone :) <civodul>rekado_: 31841 is a weird bug report IMO <civodul>i started warning people about guile-sqlite3 several weeks ago <platoxia>Bug 31841 is not limited to to ./pre-install-env. I have the same problem on GuixSD that has only ever run guix pull. <platoxia>I don't know how useful that information is though... <platoxia>I missed g_bor's comment. Will re-run guix pull. <civodul>yeah, prior to the new 'guix pull', the 'guix' command would not know about new dependencies <civodul>so the old 'guix' command wouldn't know that guile-sqlite3 is now required <civodul>qemu-system-i386 built for i686-linux segfaults <g_bor[m]>civodul: i'm running a make check, and it seems that test/containers.scm takes a very long time. It thsi expected? <civodul>g_bor[m]: i think tests/guix-pack.sh takes ages and builds the world, and that's a mistake <g_bor[m]>civodul: Would it be possible to split the test suite into normal and expensive tests? Would that make sense? Or it is only this test that should be modified? <janneke>civodul: help! x86 binaries do not execute anymore on machine -- reconfigured to latest master 2 days ago, ring any bells? <g_bor[m]>janneke: do you know when was the machine reconfigured before the last time? <janneke>all mes binaries segfault after i rebooted -- can be only a kernel bug? <janneke>Linux dundal 4.17.1-gnu #1 SMP 1 x86_64 GNU/Linux <janneke>on my other guix machines, ubuntu machines, the static binaries run fine <g_bor>What is not working? I'll try to reproduce this locally. <janneke>i suspect this is the segfault you saw... <g_bor>I see. It would be nice to know the commit range to bisect for, that's why I asked for the previous reconfigure... <janneke>tar xf mescc-tools-seed-32881b9ff21fb41dc846914753b6cdadd75927c4.tar.gz <janneke>cd mescc-tools-seed-32881b9ff21fb41dc846914753b6cdadd75927c4/ <Copenhagen_Bram>Where is ~/.guix-profile/etc/profile sourced? I'd like to source it in ~/.bashrc <janneke>this segfaults now (4.17.1), but runs fine 4.15.0-gnu SMP 1 x86_64 GNU/Linux <g_bor[m]>civodul: you are right, this was the pack test. I interrupted it. <janneke>g_bor[m]: what kernel are you running? <g_bor[m]>janneke: ok, this is a small executable, I will have a look at it in a debugger. Maybe we get some clue. <g_bor[m]>Also tell me how that goes. If we know it's the kernel, then it will be easier. <g_bor[m]>janneke: so far I tried it on an ubuntu system linux-4.15.22, it works on that. <g_bor[m]>it has 4.17.0-gnu. I saw segfaults there eariler <janneke>a guix recipe that worked for me and does not work for you...*scary* <civodul>janneke: you mean i686 binaries crash? <g_bor[m]>janneke: this segfault must be somewhere very early, most probably in the application initialization, as we don't actually get to the command line parsing. <civodul>janneke: maybe you could check in 'guix system vm' with different kernels? <janneke>i udated to latest master some days ago, just before the mes 0.15 release <civodul>(that's different from my qemu-system-i386 crash though, because even the one built on x86_64 crashes) <civodul>are you sure the kernel is at fault? <janneke>civodul: no, but i'm rebooting now, brb <civodul>mbakke: are you aware of mutex/condvar fixes in the libc 2.27 branch? <janneke`>civodul: yep, Linux dundal 4.14.49-gnu #1 SMP 1 x86_64 GNU/Linux is fine <janneke>only change: + (kernel linux-libre-4.14) <civodul>could you try with something more recent, like 4.16? <janneke>i'm going to ask the internet first, i think <pkill9>what do people think of adding pinentry as an input to gnupg and giving gnupg the pinentry store path (plus 'bin/pinentry') as the default pinentry program? <jlicht>pkill9: what is the default behaviour of gnupg? <jlicht>crash and burn "could not find pinentry" or something like that? <pkill9>although the output isn't entirely clear that that's the reason <pkill9>because it then also says it couldn't find the key <pkill9>but i fixed it by specifying the path to pinentry in ~/.gnupg/gpg-agent.conf <jlicht>I have that specified as well. Could adding a default pinentry program not be a potential security risk in some situations? <pkill9>not sure, but the default pinentry would be to the store path of the guix-packaged pinentry <Copenhagen_Bram>What do you use in GuixSD to mount things automatically/easily? I used udiskie in parabola <jlicht>Copenhagen_Bram: auto-mounting can (and has in the past) lead to some security issues, so I'd reconsider :) <janneke>bah, google now thinks that i'm a robot, and exwm quickly hides the popup window <jlicht>janneke: fwiw, I also run into a segfault with the tarball you uploaded <janneke>jlicht: thanks for checking, what kernel are you on? <jlicht>Linux braveheart 4.17.1-gnu #1 SMP 1 x86_64 GNU/Linux <jlicht>pkill9: I need to sign in for that page, so I guess it is private ;-) <Copenhagen_Bram>I can live without auto mounting, I'd just like a nice cli way to easily mount something. I miss typing `udiskie-mount -r /dev/sdc1` and then it would decrypt and mount my external drive <jlicht>Copenhagen_Bram: I don't know, I actually put my mount commands in some bash scripts <janneke>g_bor[m], civodul: yes, that's it; the vm.mmap_min_addr default was changed <janneke>this "fixes" it: echo 4096 > /proc/sys/vm/mmap_min_addr <janneke>i haven't found yet where/when this happened, who did this <pkill9>is it bad to instead of adding a propagated input, create a wrapper with 'PATH=/gnu/store/path/to/binary:{PATH-:}$PATH (or whatever)'? <jlicht>pkill9: what is wrong with your config flag? <jlicht>pkill9: propagated input vs wrapping with PATH vs configuring pinentry with the ./configure flag all lead to the same result, no? <pkill9>oh there's nothing wrong wtih using the config flag (infact probably better to do that), it was more just a general question <pkill9>i guess one downside is search-paths don't get propagated <janneke>oops, i'm still on my old kernel//my bad <janneke>does someone have a shortcut for something like <janneke>janneke 2794 0.0 0.0 8264 1536 pts/0 S+ 16:14 0:00 | \\_ grep icecat <janneke>janneke 1535 2.9 2.5 2971024 413420 pts/4 Ssl+ 15:33 1:13 \\_ /gnu/store/1bvm60z69533fbrm9vr7q11bhb6j9syr-icecat-52.6.0-gnu1/bin/icecat --app /gnu/store/mm89pb1xmnfwfkrkryg2fi56c3cd9izc-conkeror-1.1.0/share/conkeror/application.ini <civodul>janneke: thanks for the mmap_min_addr trick! <janneke>civodul: i'm suspicious too, gonna test it myself by booting 4.17.1 again <snape>janneke: killall -9 icecat or pkill -9 icecat <janneke>i have been looking at our gnu/packages/aux-files/linux-libre/4.1*-x86_64.conf <janneke>but they have had the same CONFIG_DEFAULT_MMAP_MIN_ADDR=65536 for ages <janneke>it may just be that the internet was lying to me <civodul>the internet is like this sometimes... <janneke>snape: pkill, i learned something new! <janneke>snape: you guessed my question -- thanks a lot! <Copenhagen_Bram>When I click on a link in sakura, it gives me an error saying it couldn't find firefox. How do I configure sakura, or mimetypes, to open icecat instead? <janneke>echo 4096 > /proc/sys/vm/mmap_min_addr <janneke>so we really found a new kernel bug or feature <brendyn>Where is the best place to host source files for guix packages for free? i need to mirror 200MiB of free fonts <brendyn>civodul: Did you ever learn anything about that mysterious bug with pcmanfm/thunar showing misc /dev drives it shouldn't instead of actual hard drives? I still have that bug. <bavier>brendyn: are these font source, or compiled fonts? <brendyn>bavier: compiled I guess. .TTF files. Isn't that what we treat as source for TTF fonts? <brendyn>I was not aware that fonts were compiled from anything else <snape>Copenhagen_Bram: maybe xdg-utils is needed? <bavier>brendyn: we "build" some fonts from the fontforge source, but if that's not applicable here, then TTF file are fine too. <civodul>brendyn: i remember i digged into GLib and all that, and posted the details in the relevant bug report, but i didn't get to the bottom of it <brendyn>bavier: The issue I have is that I put a font in guix, but the source is wrong now because upstream updates the file in place, rather than using unique names and keeping old files <civodul>snape: does git.lassieur.org run GuixSD? :-) <brendyn>civodul: Hmm ok I wish I knew how to debug it further <civodul>brendyn: as a starting point, could you find the bug report about it? <civodul>it might have been on help-guix actually <civodul>cat: -: Resource temporarily unavailable <civodul>brendyn: i cannot investigate right now, but if you can try and continue from where we left it off, that would be awesome! <brendyn>That's ok i know you are busy with things more important than this bug, I'll see what I can do, maybe ask others in here for help <snape>sneek: later tell jlicht: mu4e-conversation looks good! It's not yet in Guix though :-) <janneke>g_bor: can you downgrade to: (kernel linux-libre-4.14) <janneke>it may take some time to find the root cause of this problem <janneke>rain1 suggested to "just up the base address" and that's a plausible fix <janneke>but it's quite some work and we don't know why it's needed af if it's gonna help <j3kyl>maybe its worthy adding an note that at install of guixsd efi is located at /mnt/boot/efi rather than /boot/efi as it is after guixsd is installed. GuixSD dont chroot and it will always generate errors as we issue grub-mkconfig <j3kyl>( For ‘grub-efi-bootloader’, it should be the path to a mounted EFI file system.) <j3kyl>Can we run-dry the reconfigure config.scm just to confirm there is no issue? <bavier>j3kyl: you can `guix system build config.scm` <bavier>which will do everything except update the system link <joeyh>does guix have a process for handling embargoed security issues? Would like to get in touch with whoever about one <bavier>joeyh: you can mail guix-security@gnu.org <civodul>joeyh: we discussed being on the distro list in the past and i think Leo, who handles a large part of security issues, had mixed feelings and would rather wait <civodul>perhaps we should revisit this issue <joeyh>understood, it's a complex topic in a lot of ways. <pkill9>how do i refer to the build directory e.g. /tmp/guix-build-... ? <wigust>pkill9: You could use a (getcwd) procedure <pkill9>oh nevwermind just worked out how <g_bor>janneke: can we consider this as solved? Will you take it from here? Or do you need more assistance in figuring this out? <janneke[cm]>the LD segfault / with-lib-path whatever problem still remains <janneke[cm]>you wouldn't see that if you can't get past the MesCC tools build <j3kyl>cool: (device (file-system-label "home")), neat! <j3kyl> what is the meaning of this symbol on scheme file? <roptat_>hey, I'm getting the same on my broken server now <roptat_>it seems the issue wasn't guix after all, but corruption of the file system <Copenhagen_Bram>according to the research i've done most people get this error after typing an incorrect password or something <roptat_>I get a lot of 'PAM: initialisation failed' too <Copenhagen_Bram>at least i sort of know what pam is. It's 'password authentication module' or 'psomewordthatstartswithp authentication modules' or something <Copenhagen_Bram>i remember editing files in /etc/pam.d/ to allow me to log in with the fingerprint reader <Copenhagen_Bram># chsh -s /gnu/store/1g9r9lk412srqwggv1wv33j4fby7jpg1-shadow-4.6/sbin/nologin <roptat_>I mean, you're already logged-in, so I don't why it needs PAM <pkill9>anyone know of a simple way to add all inputs to an environment path with the wrapper? <Copenhagen_Bram>where did rubenwardy go? I just confirmed that minetest temporarily runs at an extraordinary rate of 60fps if I play it right after I boot <pkill9>Copenhagen_Bram: is that on GuixSD? <pkill9>does it slow down to signle digit FPS if you play it later than boot? <pkill9>what do you do after you boot but before you run minetest when it runs slow? <Copenhagen_Bram>I was just playing minetest and the framerate collaped while I was playing it <Copenhagen_Bram>my battery is wearing out, according to i3 it could only charge to 30% <Copenhagen_Bram>where can I learn how not to wear out computers in just a year or so? <ng0>write a small service for it? <ng0>ah. there's pam extensions which are treated differently here <ng0>grep the source for pam <Copenhagen_Bram>I have a feeling there's supposed to be a chsh/ folder in /etc/pam.d <ng0>guix source. cd gnu/services ; grep "pam.d" ... or read the manual. I don't have the time to provide specific instructions, I just know you have to do something there <roptat_>so I tried to repair the store, but "executing SQLite statement: FOREIGN KEY constraint failed" <pkill9>worked out solution to my question <roptat_>I'm going to reinstall the whole server <Copenhagen_Bram>pkill9: do you mean your question about 'do GPUs wear out like that?'? <pkill9>nah, about add all inputs to an environment path <Copenhagen_Bram>pkill9: do you think putting `(pam-services (cons* (base-pam-services) (chsh))` in config.scm will fix my pam issues? <pkill9>i dunno what your PAM issues are <pkill9>i dunno what PAM is, isn't it a privilege management system? <Copenhagen_Bram>pkill9: no, its pluggable authentication modules, it handles logging into things. I once edited /etc/pam.d/login to let me log in using the fingerprint scanner on my laptop <Copenhagen_Bram>I don't use the fingerprint scanner anymore, since I like being paranoid for fun and a fingerprint is basically a password you leave on everything you touch <pkill9>i think fingerprint scanners aren't very reliable, i havne't used them though <Copenhagen_Bram>plus the plastic around the fingerprint scanner seems to be bulged up a bit, i wonder if someone has my fingerprint now <pkill9>i think better kind of security would be a key, e.g. on usb stick, + a password <Copenhagen_Bram>i think the best kind of key would be a pgp smart card, or whatever pgp device there is that can keep the secret key inside itself for all eternity <pkill9>actually i wonder if anyone's considered using an RFID key soyou wouldn't need to plug it in either ***roptat_ is now known as roptat
<j3kyl>there is any way to not upgrade if a package is already installed <j3kyl>Copenhagen_Bram: sorry, lemme be more precise. <j3kyl>guix package -i ncurses -not-upgrade-if-installed <j3kyl>there is anything like that? <j3kyl> as you are aware, if a pack is install and you try to install it again it will upgrade the installed version. <j3kyl>I have a lot of scripts that install some packs that option would be great <Copenhagen_Bram>That would be nice. Maybe you can find the currently installed version and re-install that version <ngz>j3kyl: You can use "guix-package -I | grep <pkg>" to see if it's installed beforehand. <ngz>or "guix-package -I <pkg>" actually. <wigust->j3kyl: don't need to pipe in grep though :-) just a ‘guix package -I <pkg>’ <j3kyl>wigust-: uhum, guix package info said so! hehe