IRC channel logs


back to list of logs

<ng0>mumble is sent
<ng0>testers welcome, I need to wait another 18 hours until I can test with huumanz.
<ng0> o.o
***jje is now known as Guest62718
***jje is now known as Guest3336
***Guest3336 is now known as jje
***jje is now known as Guest87686
***Guest87686 is now known as jje
<buenouanq>where does x look for configs in guixsd?
<buenouanq>on debian I had to put something in /usr/share/X11/xorg.conf.d/
<buenouanq>but this isn't working here
<lfam>buenouanq: I don't have access to my GuixSD system at the moment, so I can't look myself. I think somebody else asked this recently (or maybe it was you).
<lfam>buenouanq: I'm guessing it is configured through the Shepherd service, in your GuixSD configuration file
<lfam>If you can't figure it out, please send mail to <>
<cbaines>I can't seem to get guix container to work, it always outputs "guix container: error: exec failed with status 1" (and some locale warnings) any ideas?
<cbaines>I'm trying: sudo guix container exec 17860 /run/current-system/profile/bin/bash --login
<cbaines>where 17860 is a pid of something "in" the container
<marusich>cbaines, is 17860 the pid of the running container?
<marusich>I am not sure if "the pid of the running container" is the same as "the pid of something in the containre"
<marusich>The Guix manual says that the pid should be "the pid of the running container".
<marusich>Second question: is /run/current-system/profile/bin/bash actually a valid path in the container?
<marusich>Perhaps it should be something else?
<cbaines>I've tried quite a few pids, with both /run/current-system/profile/bin/bash and /bin/sh, but nothing seems to work
<alezost>buenouanq: I think you can try "/etc/X11/xorg.conf.d/". BTW I'm pretty sure you are not supposed to modify "/usr/share/X11/xorg.conf.d" on Debian, as user configurations should go to /etc (I mean on classic distros; on GuixSD or NixOS you modify your system with a system config file)
<albertoefg>alezost: do you have a link where i can lear about that system config
<alezost>albertoefg: it's in the guix manual: (info "(guix) System Configuration")
<albertoefg>is it like ./emacs/init.el
<alezost>yes, it's the file that you specify to "guix system ..." commands
<jmd>You can lear anywhere!!
<albertoefg>thats why they call it the emacs of distros?!!
<albertoefg>i don't know what lear means :( it was a mistake
<albertoefg>alezost: it seems fun then but i have to learn a lot to take advantage of it
<albertoefg>i am liking guix a lot though
<albertoefg>i had audacity on fedora and had lots of troubles
<albertoefg>installed with guix and works like a charm :)
<albertoefg>i think the word is charm :p
<alezost>:-) I like Guix too
<buenouanq>alezost: that's where the ancient debian forum post told me to put it ┐( '~')┌
<buenouanq>it's to fix screentearing on an i7 sandybridge
<buenouanq>if you know of guix based solution to this, I'm all ears
<alezost>buenouanq: do you actually mean GuixSD? (or are you trying to use X package with Guix on another distro?)
<buenouanq>sorry, GuixSD
<buenouanq>anyone mention screentearing before?
<alezost>I think you can still use "/etc/X11/xorg.conf.d/", but the GuixSD way is to use 'xorg-configuration-file' as described at (info "(guix) X Window") ← this would probably be not easy to figure out
<alezost>buenouanq: I don't think so
<buenouanq>well, if I ever fix it, I'll hope one of you can document it somewhere official
<civodul>Hello Guix!
<Petter>Hello Guik!
<ng0>I think I need to build mumble with celt
<ng0>I started it again just now, and no microphone is found
<ng0>when I included celt, it worked
<ng0>ah, no. it's pulseaudio
<ng0>and it might be just my system
<ng0>yeah, it works
<ng0>i just need to start some audio application first here, everytime
<ng0>in case someone wants to test, i'm later connected to mumble server
<ng0>but around 7 PM UTC I can verify anyone as we have our meeting
<efraim>mark_weaver: civodul: looks like the a mips builder is out of space
<baconicsynergy>should i regularly run 'guix pull' and 'guix package -u' as root?
<rekado>ng0: needing to start an audio application first sounds like that spawns pulseaudio. Could you confirm this? You may need to add pulseaudio to the inputs of mumble.
<rekado>baconicsynergy: only if you want to update root's profile.
<rekado>"guix pull" and "guix package" (like almost all guix commands) operate on a per-user basis.
<rekado>as far as Guix is concerned root is just another user.
<baconicsynergy>okay, i think i see now
<ng0>rekado: it is
<ng0>just my system does not start pulseaudio on its own
<ng0>*it is in the inputs
<ZombieChicken>What is everyone's opinion of NixOS?
<ZombieChicken>I feel like it's time to reinstall my desktop and GuixSD simply won't do
<Petter>This is how I read it: "Your system won't do. Is this other system cool?"
<ng0>I found the command line syntax of nix akward compared to guix where it feels more like natural language
<ZombieChicken>ng0: I'd love to use GuixSD, but until encrypted root is supported that is pretty much a no-go atm
<ZombieChicken>and I thought I'd give something similar a try which does support it
<ZombieChicken>Petter: One can only learn so much about a distro via VMs.
<civodul`>ACTION is currently fixing encrypted root support
<civodul`>at last :-)
<ZombieChicken>civodul`: Sadly IRC offers no way to kiss someone
<ZombieChicken>Just make sure the system can handle encrypted keyfiles and doesn't force the user into a single (or small set) of ciphers
<ZombieChicken>like Ubuntu does and AES
<ZombieChicken>and I think Fedora and SuSe
<civodul`>ZombieChicken: i suppose you'll be welcome as an early tester :-)
<ZombieChicken>civodul`: Is it in a testable state?
<civodul`>i've pushed a couple of fixes yesterday and am working on the remaining ones and a test
<civodul`>i'll update the bug report when i'm done
<ZombieChicken>civodul`: Mind linking the bugreport for me?
<civodul`>the title is a bit misleading
<ZombieChicken>When you are looking for testers, post something on devel and PM me on here
<ng0>so the audit results were what happened in 7.51.0
<civodul`>ZombieChicken: will do!
<ng0>civodul`: count me in for testing
<ng0>though i'll just follow the commits and threads
<ng0>so i'll see it anyway
<civodul`>ok :-)
<ng0>when wgetpaste lands in master I think we should add it to the install-image
<ng0>provide some way to enhance support options
<baconicsynergy>i want a guix sticker for my laptop so badly
<ng0>"i'm just installing guixsd but i'm stuck and see weird output, please help" "ok, just run this and that with wgetpaste"
<ng0>stickers are rather expensive to produce because of the batch size you need to order when you want them good. there are diy ways which will not last so long but will work just fine
<baconicsynergy>i wonder if unixstickers would be willing to help out
<ng0>I have a Guix pin button or whatever you call it, we just say "button". those are easy to make, and very inexpensive to make yourself
<baconicsynergy>ooh that sounds cool
<baconicsynergy>I have a stupid question - should I regularly run guix system reconfigure, even if I don't make changes to my config? Or will guix's utilities be enough to maintain a system?
<ng0>the patch for wgetpaste does not apply.. is there something i'm missing? I just open the email, hit "."+"s" in emacs notmuch and save it. maybe there are parts which get stripped
<ng0>i just take the maildir file directly now.. maybe that works
<ng0>that did indeed work
<ZombieChicken>I'm not 100% sure, but I think system reconfigure is the easier way to update the system, though I seem to recall you can use --profile to run guix package for the system profile
<rekado>I have a mu4e action to apply patches directly from the mu4e-view with "a g".
<ZombieChicken>civodul: I'm curious; any idea how much longer it will be before encrypted root is a thing?
<baconicsynergy>I'm reading about guix system reconfigure in the manual, and there's something I don't get. It says it won't upgrade a service that's currently running... but when I reboot, will it switch to the updated service?
<baconicsynergy>Will 'guix pull && guix system reconfigure --fallback asdf.scm' be a safe and sufficient operation?
<ng0>reconfigure need root
<ng0>i don't know if sudo is enough, you might try that
<ng0>but "guix system build file.scm" can be done as unprivileged user
<ng0>!&idxname=guix-devel&max=20&result=normal&sort=score i wonder what's with pbpst, do we just wait until the curl problem is fixed "one day"?
<ng0>the problem is clearly curl, not pbpst
<ng0>i will send in an rebased and cleaned up patch later this week, but imo it really is curl to blame
<ng0>i should just fix gnurl and make it use gnurl instead of curl
<civodul>ZombieChicken: between "a few hours" and "a few days"
<civodul>the main difficulty is writing the test, actually
<civodul>but i think it's important to have it
<baconicsynergy>I'm so stumped :/
<baconicsynergy>Everytime I reconfigure my system, I can't boot into my display manager, or access it by any means
<baconicsynergy>I can still log in to a tty. I have no idea what to do!
<baconicsynergy>dmesg is displaying some interesting errors about my gpu
<baconicsynergy>im also receiving ntpd time errors
<baconicsynergy>It upgraded my system from 3.7 to 3.8.10
<baconicsynergy>[drm:amdgpu_device_init [amdgpu]] *ERROR* early_init of IP block <amdgpu_powerplay> failed -22
<baconicsynergy>amdgpu 0000:01:00.0: Fatal error during GPU init
<baconicsynergy>BUG: unable to handle kernel NULL pointer dereference at (null)
<baconicsynergy>i mean 4.7 4.8.10
<baconicsynergy>my bad
<baconicsynergy>I think it may be either a linux or amdgpu driver bug.....
<baconicsynergy>Should I submit a bug report to both parties
<civodul>sneek: later tell baconicsynergy what you described looks like an amdgpu driver bug, indeed
<sneek>Will do.
<jmd>So what's new in Guix?
<civodul>encrypted root in the works!
<jmd>That's good. Whole root, or just parts of root?
<ng0>I like the endurance of the people packaging KDE, and also the one who is porting Guix to Hurd/Mach
<ng0>guix build: error: build failed: derivation `/gnu/store/2nhqr0kbfjcr8lfb0168dbdz110xf97c-openssl-1.1.0b.drv' may not be deterministic: output `/gnu/store/pdjyffqmxz0nxgw1xpy163yqwy5hdmww-openssl-1.1.0b' differs (guix build --check openssl) .. so why is openssl not deterministic? I found some open reproducible bugs, and some addressed in earlier versions of openssl already
***eric is now known as bavier`
<Apteryx>Hello! I'm trying to get doc-view mode to display PDFs in Emacs, and apparently I need to install Ghostscript (gs command). I've read the thread where ghostscript gs was spinned in another output, so now we have "ghostscript", "ghostscript-gs", "ghostscript-with-x" and "ghostscript-gs-with-x". Which one should I install? Would "ghostscript-gs" be OK, or do I need to explicitly use "ghost-scriptgs-with-x" if I'm
<Apteryx>running the X server?
<Apteryx>I'm guessing the latter is what I need, but curious what would happen if I just install "ghostscript-gs" without the "with-x" suffix. Seems the only difference is the following added inputs for the "with-x" variant: libext and libxt.
<kablaam>hi, I'm trying to create a vm image for qemu. I'm running: guix pull & guix system vm-image config.scm --image-size=15G
<kablaam>and the system command fails with this message: output path `/gnu/store/a3zcv0b3x8gpvw5in2l1awncp7bjx9pm-geiser-0.9.tar.gz' should have sha256 hash `1n772ysl1dmn0vy3gk230ymyjm14h93zw99y6h2rqp1ixy7v43dm', instead has `0phz9d8wjk4p13vqannv0003fwh8qqrp0gfzcs2hgq1mrmv1srss'
<kablaam>cannot build derivation `/gnu/store/v7zlqw5kiwqbhsczf5yvqw8ny6i6d02l-geiser
<kablaam>how could I fix this?
<ng0>i could check if I could remember how to force a rebuild
<efraim>kablaam: geiser was updated in place, I guess no one fixed it yet
<efraim>ng0: do you mean like --check?
<ng0>oh. yes :D that I have been using 6 times in a row now to check software I participate in.
<ng0>duh x.x thanks
<efraim>kablaam: you can work around it for now by running `guix download'
<kablaam>I'm going to try, thanks!
<kablaam>the download command works well, but should I change something else? because `guix system vm-image` fails
<efraim>You could try with --fallback if it doesn't finish building
<kablaam>seems it doesn't work, same error
<jmd>How do I use the "challenge" command?
<sankey>civodul: i'm curious what you know about the state of mcron
<sankey>there were some changes to it about 6 months ago that haven't been merged upstream, but those changes are packaged anyway as mcron2
<ng0>I can confirm mumble works perfectly
<sankey>is it just difficult to contact the upstream maintainer?
<sankey>or do the changes represent a fork?
<sankey>woah, actually the changes go back 18 months
<jmi2k>One question more... neovim generates files with #!/usr/bin while building. Any ideas on how to avoid errors about /bin/sh not existing?
<janneke>what has /usr/bin to do with /bin/sh?
<jmi2k>Sorry :P /bin/sh
<baconicsynergy>/bin/sh should exist...
<sneek>Welcome back baconicsynergy, you have 1 message.
<sneek>baconicsynergy, civodul says: what you described looks like an amdgpu driver bug, indeed
<baconicsynergy>it should be the only file in /bin
<lfam>jmi2k: The gnu-build-system has a patch-shebang phase runs after the install phase. That should catch this
<lfam>Check the manual section 5.2 Build Systems
<baconicsynergy>sneek: thanks sneek!
<jmi2k>lfam: the problem is that it creates them just in the middle of make
<baconicsynergy>civodul: i'll submit a bug report post-haste
<lfam>jmi2k: And then they are executed during the build phase?
<janneke>jmi2k: it should not do that...
<lfam>Well, that sounds strange, but you can always make a symlink in the build environment to /gnu/store/...-bash/bin/sh
<baconicsynergy>lfam: that's my favorite solution to the problem
<lfam>Maybe there is a variable you can set that would obviate that
<lfam>That will be preferable to the symlink IMO
<jmi2k>I thought doing that, but I wanted to ask before to see if there was a better alternative.
<jmi2k>lfam: I'll look for something
<ng0>had 2 mumble sessions for almost an hour in total, and I've seen no bug
<ng0>so I'd say it works
<ng0>my most useful contribution for myself :)
<civodul>sankey: the upstream maintainer of mcron didn't really welcome external contributions
<civodul>which is why we have this "fork"
<ng0>lfam: how would that work, do you have an example at hand? the mach build system (mozilla mach) is creating a comparable situation for me
<lfam>ng0: An example of what?
<lfam>Of dealing with generated shebangs?
<ng0>symlinking during a phase.. oh wait, this can be done in advance
<baconicsynergy>i didn't know mumble was free software
<ng0>the symlink is only existent in the build environment
<ng0>so i should be able to do this myself
<lfam>ng0: Yeah, if you know which symlink you need, you can do it before the build phase
<ng0>the thought of symlinking did not occur to me
<ng0>baconicsynergy: it is
<ng0>i just packaged mumble though, not murmur
<baconicsynergy>all of these years I thought it was proprietary. woah!
<ng0>they share sources, so whoever wants murmur can create that
<Petter>Good job packaging mumble!
<ng0>pure egoism to be able to talk to the people in my team again. side effect is others can use it ;D
<paroneayea>yes, yay mumble!
<paroneayea>civodul: that's too bad to hear about mcron
<ng0>what does openssl do that libressl removes that libressl is able to build deterministic (it seems) and openssl isn't?
<paroneayea>ACTION thiiiinks he just patched shepherd to list things more sanely under "herd status" but needs a minimal shepherd file to test with...
<paroneayea>anyone have a minimalist shepherd file to give it a try with?
<rekado>Apteryx: with the latest Guix you only need “ghostscript”. It comes with the “gs” symlink.
<rekado>Apteryx: but I suggest using emacs-pdf-tools instead
<paroneayea>I borrowed from davexunit's stuff to try something :)
<rekado>Apteryx: it’s *much* nicer than doc-view.
<rekado>Apteryx: you get an actual PDF viewer (not just an image viewer); you can search in the text, view the outline…
<civodul>paroneayea: re mcron, in the end it doesn't matter that much ;-)
<civodul>paroneayea: re shepherd, you can run it from a checkout with a small file as in tests/*.sh
<civodul>that's what i do in such cases
<paroneayea>civodul: aha, cool thanks
<civodul>so... drum roll... officially fixed!
<civodul>ZombieChicken: ↑
<Petter>Nice, good job! 8-)
<paroneayea>civodul: we now have encrypted LVM?
<civodul>wait, we have encrypted LUKS
<civodul>but that's great too!
<civodul>Petter: i remember you had posted a doc patch looong ago about that, i'll dig it up and adjust/apply it
<paroneayea>so it encrypts the whole disk?
<civodul>the whole thing!
<paroneayea>ACTION wonders how /boot works
<civodul>it was already possible to have a non-root LUKS partition, though i was probably one of the only users of that feature
<civodul>paroneayea: GRUB asks you for a passphrase early on, before its "stage 2", the menu, and everything
<Petter>civodul: From just before FOSDEM. Primarily focused on Libreboot.
<paroneayea>I was just encrypting /home/ for now
<civodul>same here
<paroneayea>civodul: anyway, cool news!
<civodul>Petter: oh right
<civodul>yeah it was a bit of a shame to not have that
<paroneayea>nice work!
<jmi2k>can we have encrypted LUKS root? Nice, it's the only feature I missed from Arch!
<ng0>now there just needs to be documentation, if there isn't already :)
<ng0>nice work
<paroneayea>speaking of contributions, just sent one to the list for Shepherd :)
<paroneayea>it makes "herd status" more readable
<paroneayea>by printing as a bulleted list
<paroneayea>and uses + and - depending on whether enabled/disabled for the ascii bullet, so even if you grep "herd status" output, you can see whether enabled/disabled
<paroneayea>a small contribution, but I think it'll make my life a lot easier :)
<paroneayea>or at least, a little bit easier :)
<civodul>i've been wanting something like that for some time
<civodul>jmi2k: yes we can!
<civodul>ACTION happy lfam is coming to FOSDEM
<civodul>the more the merrier! :-)
<Petter>civodul: What do you mean with OCR screenshots?
<ng0>now I wonder how to apply this new luks root to a test system config
<Petter>Is the tests comparing screenshots?
<ng0>ah, there's an example
<ZombieChicken>civodul: You have encrypted root working?
<ZombieChicken>Now to figure out how to get around to testing that
<rekado>civodul: you are my hero! I hope I can find some time this weekend to test it on my laptop. Will do a full reinstallation, this time using the whole disk.
<rekado>paroneayea: thanks for making the shepherd output prettier!
<paroneayea>rekado: yw :)
<ng0>civodul: two luks (one for root, one for swap) will work in this system, right
<ng0>otherwise you'd use lvm for [ root , swap ]
<ng0>in theory I should get asked the two passwords
<ZombieChicken>According to the bugreport, I think so
<Petter>You may consider a swap file as well.
<ZombieChicken>I'm just wondering if encrypted keyfiles are supported
<ng0>is a swap file any different than a swap partition when it comes to speed etc? I only created one once for a ram-file iirc
<ZombieChicken>I'd be a little concerned about fragmentation, but unless your system has limited RAM, I don't think it would be a huge problem
<ZombieChicken>unless something decides to misbehave
<ZombieChicken>plus you can use it for suspend/hibernate w/o having to decrypt swap as well
<Petter>With SSD speed isn't really a big factor from what I understand.
<ng0>i don't use SSD and probably never will
<ZombieChicken>Some of us still use disk-based drives, though
<ZombieChicken>SSDs seem reasonably solid
<ZombieChicken>They've had enough time to iron out the major problems with them, that is for sure
<ng0>so there would not be more fragmentation than my usual 80GB / month builds cause?
<ng0>well the cheap drives are still problematic
<ng0>and the ones I'd consider to buy are above what I'd invest
<ZombieChicken>Oh well
<ng0>you basically have 2 kinds of memory used there. which I can not explain, but it was explained to me on monday
<ZombieChicken>anyways, off to figure out how the hell to convince this encrypted root to work happily with an external /boot
<ng0>what I took from it is that my constant builds would make ssd get wasted way ealier than my hdds
<ZombieChicken>and figure out how to build a vm-image from the git repo
<ZombieChicken>Yeah. If that is really an issue stick with the enterprise-grade drives and/or platter drives
<ng0>from what I remember and conclude from this: I create a swap file somewhere on one of the partitions inside the luks, and this can be used in config.scm for swap?
<rekado>sorry for the big patch dump to guix-devel. Perl… :-/
<ZombieChicken>Some days I wish perl would disappear
<ZombieChicken>Too much, imo, relies on it
<jje>how does one install cpan on guixsd
<ZombieChicken>Isn't CPAN a service?
<ZombieChicken>and wouldn't that be built into Perl?
<rekado>it’s also an executable to access CPAN the service.
<jje>ok thanks
<ng0>oh, ok
<rekado>“cpan” is part of the “perl” package.
<rekado>but I suggest to use the “perl-.*” packages instead of installing using “cpan”
<jje>i need File::Utils
<rekado>jje: doesn’t seem to be packaged yet. But you can create a package by importing from CPAN.
<rekado>guix import cpan File::Utils
<ng0>i think most of the dependencies are packaged
<ng0>at least the native ones
<rekado>you can bind this to a variable, add it to gnu/packages/perl.scm, build it, prepare a patch, and send it to :)
<ng0>if you need help getting started, someone can assist you
<jje>well i just wanted to get pdf-tools running in emacs
<rekado>jje: I’m using it.
<jje>ok i get an error saying i don't have thats my sticking point.
<rekado>huh? At what point?
<rekado>emacs-pdf-tools doesn’t need any perl stuff.
<jje>then i am doing it wrong eh
<rekado>what *are* you doing?
<jje>i installed it from elpa and put (pdf-tools-install) in ~/.emacs like the instructions said. or do i just require it and load it.
<rekado>jje: but you have Guix, so you can just do “guix package -i emacs-pdf-tools”
<jje>OK thank you!
<rekado>no need to mess with elpa or pdf-tools-install
<ZombieChicken>Can someone help me with building and running guix from the Git repo, or will the encrypted-root option already be available via the released manager?
<lfam>ZombieChicken: You should be able to get the latest Git master branch with `guix pull`
<ZombieChicken>okay, nice
<ZombieChicken>Then I don't need to mess with that
<ZombieChicken>that's nice
<lfam>What it does is download a snapshot of the HEAD of the master branch and builds it
<baconicsynergy>encrypted root is already available?
<ZombieChicken>so there is, in effect, no real stable or release branch?
<ZombieChicken>Seems like it
<baconicsynergy>aww yiss
<ng0>but you need to either create your own install-image or pull inside the 0.11 usb, because I don't see a way to reconfigure a full system where the disk goes from plain to encrypted.
<baconicsynergy>yeah at this stage i wouldn't expect it to be able too
<ng0>I think this will never happen. where does your data go? into the cloud and back again?
<baconicsynergy>we just have to believe
<ng0>never can become someday, but today is not the day
<lfam>ng0 is right, converting from unencrypted to encrypted seems risky
<lfam>ZombieChicken: Correct, users update directly from the master branch
<ZombieChicken>Migrating from unencrypted to encrypted requires a reinstall in most instances iirc
<ZombieChicken>no matter the distro
<lfam>We do our best to keep the master branch working; if something breaks, that's a mistake
<lfam>Guix makes this pretty safe, since individual packages each refer to their own dependency graph. Plus, users can always roll-back if something goes wrong
<ZombieChicken>That much I understand, but I wasn't sure if there was a release system or not. I know we're on 0.11.something, but that is all I really know
<lfam>Yeah, people have asked about a "stable" branch in the past, but for now, we aren't doing that.
<lfam>I think that Guix kind of obviates the need for it
<ZombieChicken>a stable package management is always needed
<lfam>What do you mean?
<ZombieChicken>Well, if a feature is likely to break in some cases (and the more people use Guix(SD), the more likely something will break somewhere), it can cause users problems that aren't trivial to fix
<ZombieChicken>Roll-back is nice and all, but it's a bit of a pain if what breaks is the roll-back system
<ZombieChicken>or something breaks the store or it's formatting
<lfam>Sure, there's always something you can break that *really* breaks the system
<lfam>For GuixSD, GRUB is something we have to be very careful about
<ZombieChicken>So once GuixSD gets far enough along, a stable and unstable branch might be worth a look
<ZombieChicken>since the userbase seems reasonably willing to help test things out
<lfam>But it's already more reliable than the old-school "mutate /usr" model in my admittedly limited experience
<ZombieChicken>Kind of
<ZombieChicken>It feels like a tradeoff imo
<lfam>What is lost in the trade-off?
<ZombieChicken>The change to the filesystem can cause a lot of breakage for packages that don't expect it and aren't patched for it
<ZombieChicken>Expecting something to be in /usr/lib64 or something when that dir may not even exist is kind of problematic
<ZombieChicken>and I'd really like to know more about the roll-back feature and know is there is a way to manually roll back an update
<lfam>For GuixSD, you can manually roll-back in the GRUB menu. If that doesn't work, you can boot a "live system" and manually edit the GRUB configuration
<lfam>If you can't do that, I'm not sure if using an old school distro would have helped :)
<ZombieChicken>manual editing of Grub2 configs is why my desktop uses extlinux for booting
<lfam>I don't really understand your points about changing the filesystem or /usr/lib64. Can you elaborate?
<ZombieChicken>Mostly just that if a program expects a file in a certain location in the filesystem breakage could occure. For example, a precompiled bin or something closed-source.
<lfam>Ah, we explicitly don't support that use case
<ZombieChicken>Like I have my concerns about using the nVidia driver with GuixSD, as well as Steam
<lfam>Of course, we don't go out of our way to exclude it (see the zero-th software freedom), but if we need to break it in order to improve Guix, we will
<ZombieChicken>which leaves users with installing a chroot at some point
<ZombieChicken>if they need something like that
<ZombieChicken>which reminds me
<lfam>With that said, Guix packages should *never* look for libraries on a path that is not named for its full dependency graph. That is, a /gnu/store/...-foo path
<lfam>Those paths are immutable
<lfam>This is how Guix offers an improvement on the old mutated /usr model
<lfam>I can update, for example, OpenSSL for some packages and not for others, and all my packages will keep working properly
<lfam>They will each continue to refer to the correct and separate dependency graphs
<lfam>And I think that "stable" branches cause too many problems for upstream projects, pushing them to lame "solutions" like flatpak et al. But, stable branches are necessary for the old distros, because it's impossible for them to offer working systems otherwise.
<ng0>"global" use cases would be good. like an --with-input=openssl=libressl , only in the system config. (and enjoy fixing what's not yet compatible)
<lfam>I think that the functional package management system (Guix / Nix) cut the Gordian knot
<lfam>Here's a recent discussion of a serious problem, and a lot of the difficulty they describe will go away once all distros use functional package management, IMO:
<lfam>I'm still wondering if I should try advertising Guix in that thread :)
<lfam>ng0: Did you see my OpenSSH with LibreSSL package?
<lfam>It works for me :)
<ng0>i don't mean something like that. I mean use "globally" not per package
<lfam>Right. It would be an interesting experiment. Lots of rebuilding :)
<ng0>I know roughly what works and what doesn't, the "what not" is just a small number at least it was on gentoo. I take a look though,m thanks
<lfam>Feel free to suggest it on guix-devel!
<ng0>didn't ludovic suggest it some time ago?
<ng0>not libressl, but the concept in general
<lfam>Global package replacements?
<ng0>I could be wrong, but it was something which systems like gentoo used
<lfam>Not sure, ask civodul :)
<ng0>sometime in early 2015 i think
<ZombieChicken>I don't guess anyone here has any experience with PCI-Passthrough and checking for support for it?
<ng0>let me ask my archive
<ng0> Subject: Re: Optional runtime dependencies in Guix
<civodul>lfam, ng0: me? what? :-)
<ng0> Date: Mon, 12 Jan 2015 17:26:02 +0100
<civodul>wasn't that about "USE flags"?
<civodul>whereas you were talking about global package replacements no?
<civodul>ACTION -> zZz
<ng0>similar.. kinda
<civodul>good night/day!
<ng0>openssl /ssl is a use flag
<civodul>hmm ok
<ng0>with libressl it became an if
<ng0>while we have now (ssl, libressl, openssl) in gentoo
<ng0>so +libressl excludes openssl from selection
<lfam>Right now, it's not too hard for users to do this on their own. But we can't build it for them
<ng0>while +openssl deselects libressl
<ng0>and ssl is just generic
<lfam>It's worth having an example of how to replace one package with another in the manual, with a caveat about having to rebuild the world in some cases