<ng0>testers welcome, I need to wait another 18 hours until I can test with huumanz. ***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>on debian I had to put something in /usr/share/X11/xorg.conf.d/ <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 <help-guix@gnu.org> <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? <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") <alezost>yes, it's the file that you specify to "guix system ..." commands <jmd>You can lear anywhere!! <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 had audacity on fedora and had lots of troubles <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?) <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 <buenouanq>well, if I ever fix it, I'll hope one of you can document it somewhere official <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>i just need to start some audio application first here, everytime <ng0>in case someone wants to test, i'm later connected to gnunet.org 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. <ng0>just my system does not start pulseaudio on its own <ng0>*it is in the inputs <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 <civodul`>ACTION is currently fixing encrypted root support <ZombieChicken>Just make sure the system can handle encrypted keyfiles and doesn't force the user into a single (or small set) of ciphers <civodul`>ZombieChicken: i suppose you'll be welcome as an early tester :-) <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>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 <ng0>civodul`: count me in for testing <ng0>though i'll just follow the commits and threads <ng0>so i'll see it anyway <ng0>when wgetpaste lands in master I think we should add it to the install-image <ng0>provide some way to enhance support options <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 <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>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>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>Everytime I reconfigure my system, I can't boot into my display manager, or access it by any means <baconicsynergy>[drm:amdgpu_device_init [amdgpu]] *ERROR* early_init of IP block <amdgpu_powerplay> failed -22 <civodul>sneek: later tell baconicsynergy what you described looks like an amdgpu driver bug, indeed <jmd>So what's new in Guix? <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>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 <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 <ng0>oh. yes :D that I have been using 6 times in a row now to check software I participate in. <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 <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? <sneek>Welcome back baconicsynergy, you have 1 message. <sneek>baconicsynergy, civodul says: what you described looks like an amdgpu driver bug, indeed <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 <jmi2k>lfam: the problem is that it creates them just in the middle of make <lfam>jmi2k: And then they are executed during the build phase? <lfam>Well, that sounds strange, but you can always make a symlink in the build environment to /gnu/store/...-bash/bin/sh <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>my most useful contribution for myself :) <civodul>sankey: the upstream maintainer of mcron didn't really welcome external contributions <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 <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 <ng0>they share sources, so whoever wants murmur can create that <ng0>pure egoism to be able to talk to the people in my team again. side effect is others can use it ;D <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>Petter: i remember you had posted a doc patch looong ago about that, i'll dig it up and adjust/apply it <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. <civodul>yeah it was a bit of a shame to not have that <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 :) <paroneayea>speaking of contributions, just sent one to the list for Shepherd :) <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 :) <civodul>i've been wanting something like that for some time <civodul>ACTION happy lfam is coming to FOSDEM <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 <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! <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 <Petter>You may consider a swap file as well. <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>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>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 <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>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… :-/ <jje>how does one install cpan on guixsd <rekado>it’s also an executable to access CPAN the service. <rekado>“cpan” is part of the “perl” package. <rekado>but I suggest to use the “perl-.*” packages instead of installing using “cpan” <rekado>jje: doesn’t seem to be packaged yet. But you can create a package by importing from CPAN. <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 guix-devel@gnu.org :) <ng0>if you need help getting started, someone can assist you <jje>well i just wanted to get pdf-tools running in emacs <jje>ok i get an error saying i don't have FileUtils.pm thats my sticking point. <rekado>emacs-pdf-tools doesn’t need any perl stuff. <jje>then i am doing it wrong eh <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” <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` <lfam>What it does is download a snapshot of the HEAD of the master branch and builds it <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. <ng0>I think this will never happen. where does your data go? into the cloud and back again? <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 <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>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 <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 <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 <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>I'm still wondering if I should try advertising Guix in that thread :) <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 <ng0> Date: Mon, 12 Jan 2015 17:26:02 +0100 <civodul>whereas you were talking about global package replacements no? <ng0>openssl /ssl is a use flag <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