IRC channel logs


back to list of logs

<lfam>nckx: Does btrfs-progs 4.8.3's test suite segfault for you?
<lfam>Scary KDE Neon security advisory:
<lfam>"The package archive used by KDE neon was incorrectly configured
<lfam>allowing anyone to upload packages to it."
<buenouanq>I'm having screentearing issues and my old Debian fix (though it does change the speed of the tear) no longer works. i7 sandy bridge with onboard graphics
<lfam>What's your old Debian fix?
<buenouanq>makeing a file /usr/share/X11/xorg.conf.d/20-intel.conf that contians Option "TearFree" "true"
<lfam>buenouanq: With Guix, software tends not to look for at /usr
<lfam>s/look for at/look at/
<lfam>You should figure out where your Xorg is looking for configuration and edit that file
<buenouanq>it does change the speed of the tear though, which I thought was weird
<buenouanq>or maybe I'm just crazy
<buenouanq>how do I find where X is looking?
<lfam>It's possible that our X package is misconfigured to look in /usr
<ZombieChicken>strace is useful to see where a program is looking for things. I think you can grep the output for "open" for that kind of info
<ZombieChicken>Is there a way to have guix build a vm-image? I seem to recall it can, but I can't find the docs for it
<ZombieChicken>nvm. Found it!
<buenouanq>so cool
<ZombieChicken>since I've retired my vPro-equiped laptop, if I want to play with a computer, I need a VM now adays
<ZombieChicken>Anyone know where the script to start a guix-generated VM is?
<buenouanq>you just run it
<ZombieChicken>hrm. It's erroring out at network-interface-flags and won't finish
<lfam>ZombieChicken: Did you use `guix system vm` or `guix system vm-image`?
<lfam>How did you invoke QEMU?
<ZombieChicken>qemu-system-x86_64 --enable-kvm -cpu host -net nic -net user -usb -usbdevice tablet guix-img.qcow
<ZombieChicken>I copied the image out of the store into $HOME
<lfam>My understanding is you have to choose a NIC model
<lfam>-net nic,model=virtio
<lfam>Assuming your system has virtio
<ZombieChicken>just tried w/o either -net option and still the same error
<lfam>Here's what I used the last time I booted a vm-image: `qemu-system-x86_64 -net user -net nic,model=virtio -enable-kvm -m 3072 ~/tmp/test-image`
<ZombieChicken>Interesting. The system errors when started w/o a network card mentioned
<ZombieChicken>but yeah, model=virtio seems to have worked
<lfam>I don't think you can not select a model. Presumably some other choice would work too
<ZombieChicken>yeah, but leaving it out shouldn't cause an error
<lfam>I tried to give the absolute minimal QEMU invocation in our manual, section 7.2.14 Running GuixSD in a Virtual Machine
<ZombieChicken>sometimes weird things happen
<lfam>Can you boot other systems in QEMU without specifying the NIC model?
<ZombieChicken>I don't have any other images on hand
<ZombieChicken>it /should/ work
<ZombieChicken>but oh well
<ZombieChicken>It's working now
<lfam>I'm wondering if it's a limitation of QEMU or of GuixSD
<ZombieChicken>Good question. I have no way to test
<lfam>ZombieChicken: Can you send a message to with the complete error messages and the command you used to trigger the error? Also the output of `guix --version` or a Git commit if you are working from Git
<ZombieChicken>I'm not working from git, and the error was in qemu, so it is kind of hard to get ahold of
<lfam>Would it be possible to take a screenshot?
<ZombieChicken>got 'em
<ZombieChicken>lfam: How do I check what version of guix I'm running?
<lfam>`guix --version`
<ZombieChicken>lfam: email should be sent now
<ZombieChicken>It's long, detailed, and I think has everything other than the actually VM image attached
<ZombieChicken>even grabbed the backtrace in one of the emails
<lfam>Thanks for the great report
<lfam>We probably need to gracefully handle this case in the GuixSD code
<lfam>I don't think it's a problem with QEMU
<ZombieChicken>Maybe it is, maybe it isn't.
<ZombieChicken>but yeah, that should be handled well
<ZombieChicken>lfam: you already have the report?
<lfam>Yes, I read it :)
<ZombieChicken>and the images?
<albertoefg>this channel is really active :)
<buenouanq>guix is the future
<buenouanq>people are finally catching on
<ZombieChicken>Not sure about guix itself, but the basic concepts involved are certainly worth looking at and paying attention to
<ZombieChicken>Well, crap. i think my backup hard drive might be dead...
<cehteh>raid ftw
<ZombieChicken>It's an external hard drive. My system is on a RAID5
<buenouanq>will btrfs raid ever be stable?
<ZombieChicken>Will BTRFS ever consider itself stable enough to be used is a better question
<ZombieChicken>last I checked, they still said "Don't use this unless you have backups" on their wiki
<ZombieChicken>and the tone was "...unless you want your data burned, pillaged, and then raped by nether beast"
<ZombieChicken>the good news it the drive is still under warranty
<ZombieChicken>so I can just send it back and get a brand spanking new one
<cehteh>i'd rather use zfs
<cehteh>to bad that its license issues cant be resolved easily
<cehteh>but its still free software
<albertoefg>buenouanq: indeed
<lfam>OpenSUSE's default filesystem is btrfs, and I've read that facebook uses it to store production data
<lfam>I think it's getting there
<cehteh>i always manage to crash it or at least slowing down after use
<cehteh>havent tested it for a while but a friend had some crippled fs recently on a backup server
<cehteh>then there was this news that the raid5/6 code is fuba and needs to be rewritten
<cehteh>feature wise btrfs would look promising, but most important for a filesystem is:
<cehteh>1 stability
<cehteh>2 stability
<cehteh>3 stability
<lfam>Fair criticism
<ZombieChicken>Just remember btrfs is backed by Oracle
<ZombieChicken>One day Linux will have a good filesystem
<ZombieChicken>until then we'll have to stick with the ext series
<ZombieChicken>anyone have any suggestions for lightweight window managers?
<ZombieChicken>hrm. so I merged xorg-server and ratpoison; how do I start X w/ ratpoison? startx doesn't seem to be installed...
<ZombieChicken>so apparently it is in xinit. Interesting
<cehteh>i use i3
<cehteh>ratpoison is a bit too lightweight :D i3 and other tiled/tabbed can be at least used with keyboard AND mouse
<ZombieChicken>I was just looking for something /really/ lightweight.
<cehteh>why that?
<ZombieChicken>it's in a VM w/ 16GB of drive space
<cehteh>i mean comparted to the weight of anything else yo have running it shouldnt matter
<ZombieChicken>I'm just messing around with this atm, and figured I'd try something else out
<ZombieChicken>Otherwise I'd be running Awesome
<cehteh>if you need it extremely lightweight dont use X ,, use terminal and screen
<cehteh>awesome is nice roo
<ZombieChicken>I prefer tmux
<ZombieChicken>or dtach, abduco, and dvtm
<cehteh>all work somehow
<ZombieChicken>yeah, but the last one is a little picky imo
<cehteh>i ever wanted to make a EmacsOS .. where init=/bin/emacs :D
<ZombieChicken>startx doesn't work since I don't have anything pointing to X...
<cehteh>but thats not lightweight :D
<ZombieChicken>Could try init=`which guile` or something
<ZombieChicken>and maybe the guile-emacs
<lfam>If you want lightweight you should try dwm. Almost the entire closure is X libraries that will be pulled in by any window manager
<lfam>Try `guix size dwm`
<ZombieChicken>I used dwm in the past
<ZombieChicken>I'm not a fan
<ZombieChicken>That is interesting
<ZombieChicken>apparently there is an X in my VM, but startx/xinit doesn't see it, so it won't start X
<efraim>I use enlightenment
<efraim>There's also openbox
<ZombieChicken>except I hate XML configuration files
<efraim>lfam: I saw your post on oss-sec, i have cryptsetup bumped to 1.7.3 here and it builds fine
<efraim>also, we don't build it with openssl
<efraim>I think its better to push the update than to wait to see if we should mention the CVE in the commit message
<lfam>efraim: I think the bug they reported is in the Debian scripts, but I'm not sure
<lfam>I didn't realize we didn't have 1.7.3. Yeah, we should definitely update
<efraim>i'll push it now
<ZombieChicken>Would a feature request be better sent to the devel list, the help list, or as a bugreport?
<efraim>also my debian testing box just got 1.7.3 this morning
<efraim>unless the feature request is "make it work right", i'd go with devel :)
<ZombieChicken>and if there is a CVE involved, I personally would like them added. Transparency is always good
<lfam>We can't add the CVE to the commit message after pushing it
<ZombieChicken>Oh well. I'm just a lowly user anyways
<lfam>It's a limitation of using the Git log for security advisories
<lfam>And I'm still not sure our package even has the bug:
<ZombieChicken>I do recall being able to amend commit messages, but I don't know if that works with pushes
<ZombieChicken>My git-foo isn't great
<ZombieChicken>ty lfam
<lfam>You can always rewrite old Git commits, but it's considered poor form to do so for commits you've shared publicly
<lfam>"The fault is caused by an incorrect handling of the password check in the script file /scripts/local-top/cryptroot."
<efraim>'master' is append-only, so even if you changed it you could never push the change to master on savannah
<lfam>AFAICT, all our use of cryptsetup is in (gnu system mapped-devices). We don't use those Debian scripts
<ZombieChicken>Yeah. It doesn't look like the drive is actually accessible, but it gives the booter root access to play with. I guess that's the problem
<ZombieChicken>Does Guix handle LUKS encrypted root yet?
<lfam>No, not yet:
<ZombieChicken>I have some stuff for that on my system, I just havn't had the time to learn guix nor guile to sort out how to do it
<efraim>is anyone else having trouble with `guix refresh -t github' ?
<efraim>ERROR: Error downloading release information through the GitHub API when using a GitHub token
<civodul>Hello Guix!
<jmd>civodul: hi
<kmicu>( ^_^)/
<civodul>ACTION restarts evaluations & builds on
<efraim>we discovered last night geiser was updated in place
<civodul>ACTION goes talk to jao :-)
<civodul>hmm, not here
<civodul>well that sucks
<civodul>but we need to update it anyway
<Sleep_Walker>efraim: I have the same problem with Github
<efraim>so it looks like github changed something then
<efraim>for `ssh build-slave guile -c "'(use-modules (guix config))'"` I want guix's guile and not debian's, or it isn't supposed to matter?
<Sleep_Walker>ACTION is making note to have a look on `guix refresh' to see what it is for
<efraim>hmm, nvm, it seems to be an `ssh -q` type issue i'm having
<civodul>efraim: better use Guix's but it shouldn't really matter
<ng0>python-papy fails its testsuite, is someone lookin ginto this?
<jmd>I think that now guix is getting big, there should be some sub-teams dedicated to certain tasks.
<civodul>good question, i don't know
<civodul>there are de facto teams
***mbuf_ is now known as mbuf
<civodul>formalizing them might encourage those already in, and/or it might discourage those out of the teams
<jmd>That is a valid point.
<civodul>what's important though is to have contact points, like we have for security
<ng0>I find myself comfortable (at least with packaging) to stick with what I do, mostly in the crypto and p2p sections
<jmd>ng0: There are two problems there.
<jmd>1. Everyone feels the same way.
<ng0>2. duplicated work
<jmd>there are always going to be some tasks which are really urgent, but nobody wants to do.
<jmd>and 2. is, ask you say, the risk of duplicating work.
<ng0>the teasm don#t have to be fixed
<ng0>one could circle around
<ng0>to gather experience and don#t get bored
<jmd>At any rate, I think the traffic on guix-devel is getting high.
<ng0>civodul: I'll be looking into financing university, so when I'm ready with the requirements I can dedicate some time at university to the distributed package updates problem
<civodul>jmd: the problem of tasks that nobody wants to do is hard to address in general when people are volunteers
<civodul>we should simply work hard on improving things such that there's no such task
<civodul>one example is sysadmin: we can make it rather painless and even fun by switching to GuixSD, i think
<kmicu>To give some perspective, Nixpkgs is order of magnitude bigger and still has no ‘teams’.
<ng0>wouldn't there still be a need for someone who monitors the machines for break in attempts etc, civodul ?
<civodul>ng0: of course, that still needs to be done
<civodul>so it's not a silver bullet
<civodul>but it can help
<ng0>gentoo is bigger, and used to have "herds", but those are dissolved now.
<jmd>presumeably this new machine will be running SD?
<civodul>applying security fixes to packages is another not-so-fun task
<civodul>jmd: yes
<ng0>there are still teams in genetral though at their side
<civodul>jmd: it's already running, even: :-)
<ng0>like general, theme oriented teams
<ng0>"infra" , "hardened" , etc
<kmicu>civodul: is 109370 the resumed evaluation ?
<civodul>kmicu: there's a new evaluation pending
<kmicu>Thank you.
<civodul>it should show up in a few minutes
<ng0>i'll look into python-papy failing today
<jmd>we will we have the first non-alpha release?
<civodul>it's beta already! :-)
<ng0>i'm not sure if I can risk upgrading the libreboot laptop again. the patches which fixed the previous error are merged
<ng0>has anyone with libreboot reconfigured?
<jmd>civodul: So where is the canonical download site?
<jmd>So far as I can tell, all install downloads are served from
<jmd>ng0: reconfigured since when?
<civodul>jmd: right, there's no
<civodul>should we upload the next release to instead?
<jmd>I think we should consider it.
<jmd>When do we release 1.0 ?
<civodul>see the last part of :-)
<civodul>i think we can achieve that within 6 months or so
<jmd>Maybe then 1.0 should be the first unload to
<civodul>well, i've been saying that for a couple of months already ;-)
<civodul>that was the initial plan
<jmd>What does "authenticated checkouts" mean?
<jmd>BTW, it looks like a few lines can be deleted from ROADMAP.
<ng0>jmd: since I reported the grub breakage
<ng0>afaik it went into core-updates, which has been merged yesterday or sunday or something
<jmd>ng0: I've not updated libreboot that recently.
<jmd>civodul: At least half of that bug has been fixed I think.
<ng0>i maybe have to change my associated email address in may again, it looks like I can find no middle party to use as an address to lower the price I need to pay for the domain I use rigfht now, so I might just let all but expire. sorry for the .mailcap annoyance.
<civodul>ng0: seriously?
<civodul>please be more cautious
<ng0>domains are expensive and I've got too much. when I got them, I did not calculate that I'd have less money next year
<jmd>domains cost as little as 12EUR per year.
<ng0>it's not about that
<ng0>hopefully one of the autonomous centres (AZ) here can act as the owning party, so I don't have to put my name and address into the world wide addressbook into the open. for me it's about the feature of name "protection", and that is 60 euro / year for one of my domains
<ng0>at the registrar i use
<ng0>which is 45 euro more than the simple would cost
<ng0>almost no one supports opennic domains, which is the price I'd prefer.. 0 euro / year
<jmd>Does opennic actually work these days?
<ng0>when I used to be part of it, it did
<ng0>wasn't so long ago
<ng0>that was even during the time where some servers had to be dropped and adopted by supporters
<jmd>I stopped using it when it got to the point that only 1 in 10 DNS queries would work.
<ng0>I think I participated in all of 2015
<ng0>*in the year 2015
<ng0>using it, and providing servers
<ng0>jmd: I used the randomizer by d0wn, so if there was an outage I only experienced it once
<ng0>afaik I still use the opennic servers, I don't look very much at my routers
<ng0>oh, Fusl and d0wn have anycast now
<jmd>Maybe I should give it a try again.
<ng0>my last server is still listed as remove.. that's a long time
<ng0>apparently opennic is still struggling though, at least for d0wn. still a long list of free servers
<jmd>If I have /gnu/ mounted on a dedicated ext4 filesystem, is there a recommended set of parameters to pass to mkfs ??
<ng0>just mentioning it because I'm fixing my router dns
<ng0>anycast is public beta, ah. ok I'm done with the monologue about dns
<efraim>Octave-4.2.0 is still compiling, I'm adding that to my "do-not-touch" list
<civodul>jmd: the defaults for ext4 should be fine
<jmd>civodul: Fine, yes. But optimal - I don't think so.
<civodul>if you fine settings to improve it, please share!
<jmd>Well one obvious thing that occurs to me: I cannot see any reason not to pass -m 0
<civodul>if /gnu/store is a separate partition, that makes sense
<civodul>otherwise no
<jmd>Yes. That is the use case which I am talking about.
<ng0>AttributeError: module 'pafy' has no attribute 'pafy' <- do we have some python expert around who can test build "python-pafy"? I don't get what it wants to tell me
<jmd>Also, I've been running some statistics on my /gnu/store and it seems that the 90th percentile is at ca. 26k so the bytes-per-inode and block-size could be increased from the default.
<Apteryx>Any idea how I can get rid of this kind of message without rebuilding Guix? note: source file /home/maxim/.config/guix/latest/gnu/packages/perl.scm
<Apteryx>;;; newer than compiled /home/maxim/.config/guix/latest/gnu/packages/perl.go
<Apteryx>Can I tell Guix to simply rebuild those?
<davexunit>Apteryx: you haven't run 'make'
<Apteryx>davexunit: I think I must've done a "git pull" passed my last guix build (with make check).
<alezost>Apteryx: "make check" is not needed, just "make" after "git pull"
<Apteryx>alezost: Without the test it must be quick?
<alezost>yes, "make check" is a long thing and it is needed only if you want to run tests
<Apteryx>alezost: Alright!
<Apteryx>davexunit, alezost: thank you.
<rekado>I love how Guix allows me to build things from source that are very very difficult to build on a recent Ubuntu
<rekado>we currently conduct a course on scientific imaging and the instructors forgot to tell us they need some software tomorrow.
<rekado>the tool depends on old versions of boost and wxwidget and with Guix this is all pretty straight-forward.
<davexunit>yeah, it's cases like this where guix really shines
<paroneayea>building of `/gnu/store/pziimf8zk4yysfd8n54rckgdpcdpfs9g-guix-0.11.0-2.166b.drv' timed out after 3600 seconds of silence
<paroneayea>got this during two attempts of doing a guix system reconfigure
<paroneayea>is anyone else experiencing this?
<paroneayea>right after:
<paroneayea>PASS: tests/scripts-build.scm
<davexunit>paroneayea: yes, the test suite hangs. very bad.
<davexunit>I reverted the commit that updates the guix snapshot
<davexunit>master is in a very bad state right now
<paroneayea>--do-not-upgrade=guix ???! ;)
<paroneayea>I'm upgrading guix; don't update my guix!
<efraim>iirc its fixed in master now
<efraim>it also motivated me to fix python-jsonschema
<ng0> any idea why this started to fail?
<davexunit>efraim: oh, good to hear!
<efraim>ng0: I hate it when that happens, no idea why it can't find itself
<ng0>efraim: is it safe to disable tests then?
<efraim>ng0: no idea, I'd try testing it with any programs that depend on it
<ng0>hm.. mps-youtube, which depends on python-pafy, fails the test suite as well.. different message.
<ng0>strange that it started now, worked before. I think i need to fix something in there: PermissionError: [Errno 13] Permission denied: '/homeless-shelter'
<lfam>Probably, the test suite was never run with Python 3.4. Now that we are using 3.5, we see the test failures
<lfam>For that homeless-shelter error, I usually set 'HOME=/tmp' in the package definition
<ng0>oh, core-updates bumped to 3.5?
<lfam>Has anyone used Xorriso (or another tool) to convert the GuixSD installer into an ISO for use with a VPS service?
<lfam>I will be trying this soon
<ng0>mps-youtube needs the test suite disabled until #556 upstream is fixed.
<ng0>before someone fixes this, I'm currently working on pafy and mps-youtube, this just as a comment
<ng0>now both build again, but there's a locale issue. is this local (my system) because of core-updates?
<ng0>I did not dare to reconfigure because of the last failure I experienced
<lfam>ng0: Is your system "mixed" between packages from before we merged core-updates -> master and after the merge? If so, the packages will be referring to different glibc versions
<ng0>my user profile has post core-updates, my system is pre core-updates
<lfam>Yeah, see the manual section Locale Data Compatibility Considerations
<ng0>last time I reconfigured the system grub broke because of libreboot. this was merged aswell?
<lfam>It all works for me after I updated all my packages and the GuixSD system software too
<lfam>I believe so, but I didn't pay close attention in the last week
<ng0>me neither, I was on holiday
<lfam>Lucky :)
<ng0>paroneayea: you use libreboot, a current version? did you succeed in reconfiguring and rebooting?
<paroneayea>ng0: I use: libreboot_r20160818_grub_x200_8mb.tar
<paroneayea>with utility: libreboot_r20150518_util.tar
<ng0>reads older than stable
<paroneayea>and I was able to reconfigure and reboot
<paroneayea>ng0: that's older than latest yes
<paroneayea>but it's the one I installed with.
<ng0>but i think the bug in guix grub was not depending on versions
<paroneayea>ng0: is it where it doesn't show up on libreboot grub?
<lfam>ng0: I think Chris Marusich fixed the problem in 3382bfe9ea199086134d90e45e3d759aefed3dcf (system: Avoid using device paths in <menu-entry> device field.). At least, he made that change based on your report
<ng0>yes, that one
<ng0>okay it is merged then
<lfam>That commit is on msater
<lfam>I guess that was more than one week ago... time flies
<ng0>Oh. Okay, i will try. And even if it fails again, what I like about guixsd is that the system can be inited new very fast
<lfam>True, but that should not be standard operating procedure :)
<ng0>but it helps ;)
<ng0>what's recommended to add for locale, 2.23 as ludovic wrote?
<ZombieChicken>Is it possible to start X w/o a login manager?
<lfam>ng0: Did you see (locale-libcs) in section
<lfam>ZombieChicken: I believe it's possible with a little hacking
<ZombieChicken>I'd hope so. I don't use login managers
<ng0>I meant the specific version to add there, is it 2.23 now instead of 2.21 or 2.22, because we use 2.24 now?
<lfam>ng0: Most likely 2.23, unless you have some very old packages that are still linked against earlier versions
<lfam>ZombieChicken: I find this Github repo useful, and this file might give you some ideas:
<lfam>Also the shepherd-config repo of that user, it will show you some tricks :)
<lfam>I like the "boot to console, then startx" set-up, too. I'd be glad to know how to do it on GuixSD
<lfam>Also, that person is in this channel :)
<alezost>indeed :-)
<alezost>I start just X server, without any login manager and without startx/xinit
<lfam>That's why you "reconstruct" %graphical-services from scratch, right?
<alezost>ZombieChicken: it is possible to use xinit (but not startx) but a bit tricky
<alezost>lfam: no, I've never used any predefined %desktop-services or alike, cause I know better what services I need :-)
<lfam>Right, %desktop-services
<alezost>in general I don't like predefined things and like my own customizations
<lfam>alezost: I notice that file doesn't use the urandom-seed-service. Seems useful to me :)
<alezost>lfam: if you want to use xinit, it is possible, there was some person (Kooda) on this channel who uses it
<alezost>re urandom-seed-service: I don't really know why it is needed :-)
<lfam>Oh, I will keep an eye out for them, and ask them about when they are back. Thanks for the tip :)
<lfam> /dev/urandom is considered to be useless for some time after reboot without it
<ZombieChicken>iirc, startx is just a shell script that calls xinit. I'm sure you can pull what you need from startx and build your own script
<lfam>So, ephemeral SSH and TLS keys might be easily crackable if they are generated soon after boot
<lfam>Things like that
<alezost>lfam: ok, thanks for the info
<lfam>I'm not an expert, but that's based on my reading of the comments in the kernel code. Plus, all the other Linux and GNU / Linux distros do it :)
<ng0>ZombieChicken: yes it is
<lfam>Specifically the comments in Linux's drivers/char/random.c
<ng0>i think I even started awesome directly on the last system
<ng0>like with /usr/bin/awesome
<ZombieChicken>I seem to recall some distros store /dev/random on shutdown then reload/reseed that into /dev/random to help avoid the no random data issue
<lfam>Exactly, that's what the urandom-seed-service is supposed to do. I welcome everyone to verify that it works reliably :)
<lfam>Well, it loads the saved data into /dev/urandom, not /dev/random, but close enough
<ZombieChicken>Is it? I thought urandom was seeded out of random
<lfam>We also use the seed at some other times besides before shutdown, in case we don't get a clean shutdown
<lfam>To prevent re-use of a seed
<lfam>Yes, they use the same pool, but /dev/random also tries to "account" for the amount of entropy and blocks if the level is too low
<lfam>Otherwise, they use exactly the same pool and CSPRNG
<lfam>Again, this is based on my relatively naive understanding. I'm not an experte
<alezost>lfam: ZombieChicken: basically, to use xinit, you need to specify X server (like "xinit -- /run/setuid-programs/Xorg") and to specify where it should find modules; Kooda explained a bit around here: <>
<lfam>Thanks a bunch for digging up that link!
<lfam>The urandom-seed-service does not help with low entropy conditions after first boot. The situation can be especially dire in VMs
<lfam>There are some other services that are meant to address
<lfam>that are meant to address those conditions
<lfam>Other related kernels, like the BSDs, sort of combine /dev/random and /dev/urandom by trusting the CSPRNG enough to only block until the entropy measurement is high enough, and then they never block again. There is no difference in behaviour between /dev/random and /dev/urandom on those systems, AFAIK
<ZombieChicken>alezost: ty
<ZombieChicken>lfam: Yeah. Some of the better CSPRNG out there (like Fortuna) will probably never see light in the Linux Kernel because they don't want to replace the current system (which, iirc, isn't exactly /that/ good)
<lfam>Is there some analysis of the current Linux CSPRNG that explains why it's not that good?
<alezost>lfam: ZombieChicken: actually there was more about it on July, but sneek was absent at that time :-) Here is an excerpt of my log: <>
<lfam>I'm not really qualified to make judgments on these things, but I do like to read analyses and arguments and try to increase my knowledge
<ZombieChicken>iirc, the issue was complexity and possible starvation, but I'm not entirely sure. Like I said, iirc
<lfam>Feel free to send me papers / articles you come across
<jin>hi, is there a way to load a driver in specific order?
<jin>in guixsd
<ZombieChicken>lfam: I just did some looking and didn't find much, so what I read may have been rather old.
<lfam>I meant, if you come across any new analyses that are interesting. I'm not asking you to dig through your history :)
<ZombieChicken>Schiedner (sp?) seems to have a somewhat recent article on it (~2014?), but all I read was the abstract, which just said it wasn't "robust" enough
<ZombieChicken>alezost: You wouldn't happen to know if Xorg has to be setuid to run these days, would you?
<cbaines>Evening all :)
<lfam>ZombieChicken: This one? <>
<cbaines>I have a bit of a weird question, I'm looking for a middle ground between providing a path as a package source, and using a origin with the git-fetch method
<lfam>Howdy cbaines
<ZombieChicken>lfam: Yeah, that looks right
<cbaines>ideally, I want something that looks like the origin, with the git-fetch, but without having to specify the sha256
<alezost>ZombieChicken: there is this mention about it on archwiki: <> but if you want to use startx/xinit, X server should be run as root. It is run as root by a display manager anyway, so I don't see a problem here
<lfam>cbaines: So, it just uses the HEAD of the Git repo?
<ZombieChicken>Well, given the chance I'd rather see X run with user perms instead of root for obvious reasons
<cbaines>lfam, well, I'm trying to put together a test setup for work (progress here ), and I'd like to be able to specify the git commit for a package, and have that just work
<davexunit>cbaines: see current-guix in (gnu packages package-management)
<davexunit>there's some functions you can snarf
<davexunit>I think we ought to put them somewhere for easy use by others
<davexunit>the 'source' field accepts a 'local-file'
<ZombieChicken>"useful code snippets" page in info guix? :)
<alezost>ZombieChicken: yeah, I would also like to run X as user, but IIUC it can be done only using systemd, dunno
<ZombieChicken>Well, that says to me that it should be possible, and at worst needs some apulse-style sanity layer
<cbaines>davexunit, I'm using source just with a file already, but doing that for many packages would mean having to write some scripts around Guix to manage cloning and checking out the appropriate revisions
<cbaines>I might end up doing that, but I wanted to see if I could do this a bit more elegantly
<davexunit>cbaines: either I misunderstood you, or you are greatly confused.
<davexunit>not sure which.
<davexunit>I assumed this was for a local git checkout
<davexunit>if you want to get something from the network, there's no way to avoid a hash check.
<davexunit>for good reasons.
<lfam>I'm still waiting to hear about the fallout of CVE-2016-2324 and CVE-2016-2315
<lfam>Speaking of Git and trusting the network...
<ZombieChicken>Someone found a vulernability in git?
<lfam>Of course, everything has bugs :)
<alezost>ZombieChicken: btw, I don't setuid X server, I run it with sudo instead (my /etc/sudoers allows my user to do it without password); I'm not sure if it's counted to be "better" than setuid though
<lfam>Those bugs are remote code execution on both Git clients and servers
<alezost>oh my, sounds really bad
<civodul>lfam: i wonder if libgit2 has similar bugs
<lfam>Don't worry, they are old
<civodul>it's in C, so it surely does ;-)
<lfam>We fixed them in our package tree a while ago
<cbaines>davexunit, its not the repository with the package definitions that I want to get a package for, but other packages
<jmd>Is cross-building a disk-image supposed to work?
<lfam>civodul: Yes, of course it does. Somebody just has to look for them :)
<davexunit>cbaines: I don't understand.
<cbaines>so, using local-file would require having to do the clone and checkout outside of Guix
<lfam>That's my attitude about these things
<cbaines>I was looking to see if I could handle that within Guix
<davexunit>cbaines: git-fetch
<civodul>cbaines: do you want to build software from precise commits, or rather build whatever happens to be in checkouts available locally?
<ZombieChicken>alezost: That only works if you are using something like SELinux to prevent X from touching things it shouldn't, and have a way to prevent a root shell from changing the rules
<cbaines>civodul, precise commits
<civodul>cbaines: so what you have in looks good, no?
<cbaines>civodul, well, where I want to go next is to specify the commits in some continuious integration system, and have the tests run against those
<davexunit>if you're trying to dodge the hash check, it's not going to happen.
<davexunit>any derivation that has network access must know its hash in advance.
<cbaines>and the only two options that I currently know of to make that work in an automated way are 1: doing the clone and checkout, and then using local-file or 2: somehow computing the hashes, and then using those with git-fetch
<civodul>cbaines: in that case you'd need to inject source like --with-source does
<civodul>so either you use --with-source, if doing that at the command-line level is ok
<davexunit>why is calculating a hash so unacceptable?
<civodul>or you use 'package-input-rewriting'
<civodul>davexunit: when doing CI, i guess you just want to "inject" the source and have the thing built
<civodul>i has to be fully automated
<davexunit>I know about CI but I don't understand how this is an issue.
<davexunit>someone would modify the guix package recipe with the new source code to use.
<davexunit>and the CI system would build it and see how it goes.
<ZombieChicken>Looking up why Xorg needs root perms is weird. I'm getting crap about both X (in a general sense) and hair care...
<civodul>davexunit: yes but at each commit the CI issue would need to modify the recipe
<civodul>the Jenkins/Hydra/etc. way is that the tool gives you a checkout and you have to build from there
<civodul>not sure if i'm very clear :-)
<davexunit>I think with that approach then it would be better if the package recipe was in the repo itself
<civodul>yes, that could be more convenient
<civodul>but it's orthogonal
<davexunit>I guess I just don't understand then.
<civodul>for instance, we could do CI of Guile just by overriding the source of our 'guile' package
<davexunit>but how do you get the source if not from the network?
<cbaines>davexunit, civodul this is really helpful :)
<cbaines>I'm not quite sure how package-input-rewriting would be used though
<cbaines>are you replacing the source input (if I remember correctly)?
<civodul>davexunit: the CI system (Hydra, Jenkins) fetches it for you and then calls your build method
<cbaines>as for --with-source, I'd probably want to something from Guile for neatness, but I can hopefully work that out from the code
<civodul>cbaines: if you just want to change the source of a package, do: (package (inherit the-original-package) (source the-new-source))
<civodul>package-input-rewriting would be handy if you want to do that recursively
<cbaines>I've just found where the build script does (download-to-store ...) as the package source, which may be the missing link I was looking for
<cbaines>I should be able to switch to using tarballs, where the url is generated from the treeish (commit, branch, tag), and then use download-to-store as the source
<civodul>or just use 'local-file' pointing to the checkout of interest
<civodul>see 'current-guix' like davexunit mentioned earlier :-)
<lfam>New release of Xorg:
<cbaines>civodul, yep, I'll probably end up using all approaches one way or another :D
<cbaines>anyway, thanks everyone for your input :)
<civodul>lfam: are you taking care of it?
<lfam>civodul: ~439 rebuilds. What do you think? Xorg updates branch?
<lfam>~439 per-architecture, of course
<civodul>oh, i thought it was a leaf
<civodul>well, that'd be 'staging' no?
<lfam>Sure, I think rekado was going to start the branch :)
<jmd>The --image-size option to guix system confuses me.
<jmd>If I say "guix system disk-image --image-size=1" will it create a functional image?
<rekado>lfam: we now have a staging branch
<rekado>just pushed the fftw patch there
<lfam>rekado: Thanks!
<lfam>IIRC, there was some safe change to Cmake or the cmake-build-system that was destined for staging. Does anyone remember the context?
<lfam>Found it
<lfam>Ah, xorg 1.19.0 requires xproto >= 7.0.31. This will require an almost full rebuild
<lfam>So, unless there are serious bugs in our xorg-server package, I guess it will wait for core-updates
<lfam>I'll work on updating the whole X system, and push it core-updates or an xorg-updates branch later
<albertoefg>jmd hello
<jmd>albertoefg: hi
<albertoefg>this channel is really active and helpful
<cbaines>On that subject, does anyone know why I'm getting certificate verification problems when using download-to-store?
<cbaines>ERROR: X.509 certificate of '' could not be verified: signer-not-found invalid
<lfam>Security bugs fixed in Firefox 50:
<lfam>cbaines: I'm having TLS trouble too, with the linter
<jmd>I wonder why disk-image depends on libtiff
<lfam>jmd: Probably via the dependency graph of guile-rsvg, which is used to create the GRUB background, IIUC
<lfam>If not through other graphs as well
<civodul>cbaines: 'download-to-store' now verifies HTTPS certificates based on what's in $SSL_CERT_DIR
<civodul>i suppose SSL_CERT_DIR is undefined or lacks the right certificates here?