<lfam>nckx: Does btrfs-progs 4.8.3's test suite segfault for you? <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>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 <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>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? <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 <lfam>My understanding is you have to choose a NIC model <lfam>Assuming your system has virtio <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 <lfam>I don't think you can not select a model. Presumably some other choice would work too <lfam>I tried to give the absolute minimal QEMU invocation in our manual, section 7.2.14 Running GuixSD in a Virtual Machine <lfam>Can you boot other systems in QEMU without specifying the NIC model? <lfam>I'm wondering if it's a limitation of QEMU or of GuixSD <lfam>ZombieChicken: Can you send a message to bug-guix@gnu.org 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>It's long, detailed, and I think has everything other than the actually VM image attached <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>Not sure about guix itself, but the basic concepts involved are certainly worth looking at and paying attention to <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" <cehteh>to bad that its license issues cant be resolved easily <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: <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... <cehteh>ratpoison is a bit too lightweight :D i3 and other tiled/tabbed can be at least used with keyboard AND mouse <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 <cehteh>if you need it extremely lightweight dont use X ,, use terminal and screen <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... <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 <ZombieChicken>apparently there is an X in my VM, but startx/xinit doesn't see it, so it won't start X <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 <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 <lfam>It's a limitation of using the Git log for security advisories <ZombieChicken>I do recall being able to amend commit messages, but I don't know if that works with pushes <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>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>ACTION restarts evaluations & builds on hydra.gnu.org <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. ***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. <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 <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 <ng0>there are still teams in genetral though at their side <civodul>jmd: it's already running, even: bayfront.guixsd.org :-) <ng0>like general, theme oriented teams <ng0>"infra" , "hardened" , etc <civodul>kmicu: there's a new evaluation pending <ng0>i'll look into python-papy failing today <jmd>we will we have the first non-alpha release? <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 alpha.gnu.org <jmd>ng0: reconfigured since when? <civodul>should we upload the next release to ftp.gnu.org instead? <jmd>I think we should consider it. <jmd>When do we release 1.0 ? <civodul>i think we can achieve that within 6 months or so <jmd>Maybe then 1.0 should be the first unload to ftp.gnu.org <civodul>well, i've been saying that for a couple of months already ;-) <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 libertad.pw expire. sorry for the .mailcap annoyance. <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>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 nic.is 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>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>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 <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 <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? <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 <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 <davexunit>paroneayea: yes, the test suite hangs. very bad. <davexunit>I reverted the commit that updates the guix snapshot <efraim>it also motivated me to fix python-jsonschema <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 7.2.6.1 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 <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 <ng0>reads older than stable <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>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>what's recommended to add for locale, 2.23 as ludovic wrote? <lfam>ng0: Did you see (locale-libcs) in section 7.2.6.1? <lfam>ZombieChicken: I believe it's possible with a little hacking <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>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>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>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 <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 <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>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? <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? <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>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 <cbaines>ideally, I want something that looks like the origin, with the git-fetch, but without having to specify the sha256 <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 <davexunit>cbaines: see current-guix in (gnu packages package-management) <davexunit>I think we ought to put them somewhere for easy use by others <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>if you want to get something from the network, there's no way to avoid a hash check. <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... <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 <civodul>lfam: i wonder if libgit2 has similar bugs <lfam>Don't worry, they are old <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 :) <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 <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, 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 <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 <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 <davexunit>I think with that approach then it would be better if the package recipe was in the repo itself <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 :-) <cbaines>civodul, yep, I'll probably end up using all approaches one way or another :D <cbaines>anyway, thanks everyone for your input :) <lfam>civodul: ~439 rebuilds. What do you think? Xorg updates branch? <lfam>~439 per-architecture, of course <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>IIRC, there was some safe change to Cmake or the cmake-build-system that was destined for staging. Does anyone remember the context? <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 <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 'github.com' could not be verified: signer-not-found invalid <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?