IRC channel logs
2016-07-15.log
back to list of logs
<lfam>Wishing I could stop `guix build` after the current package build is completed <efraim>oh, quick question then I have to run around some more <efraim>what do you think about an aarch64 qemu machine on top of aarch64 hardware? I can supply my own kernel to it and shouldnt' have to worry about whatever is preventing the cloning from happening <janneke>Hi civodul! Thanks for identifying the grub test problem and asking grub-devel. <civodul>BTW GRUB 2.02 works fine on the bare metal, too <civodul>efraim: what was the conclusion regarding clone(2) already? <efraim>clone just works, except for when guix-daemon uses it <civodul>efraim: did you try with the exact same flags? <efraim>civodul: yes, i copied it from the daemon file to the clone file and then recompiled it <davexunit>I also have several technical difficulties during the presentation. enjoy! :) <Kooda>Hey there. Has anyone tried to build a kernel module with Guix? <lfam>Kooda: Would the package definition of ath9k-htc-firmware in gnu/packages/firmware.scm be relevant? <Kooda>Usually I use /lib/modules/`uname -r`/build but that directory is missing, it’s a symlink to a non-existing directory in /tmp <janneke>build --rounds=2 says: differs from previous round; rejecting as non-deterministic <lfam>janneke: I like to use the Diffoscope program, which is packaged <lfam>I build the package once, then copy it out of the store, with `rsync -rlptgoD`. Please double check the rsync flags :) <lfam>Then, I garbage collect it, build it again, copy it out of the store again, and then I use diffoscope to generate a report of the difference <lfam>Recently `guix build --check` was changed to leave the failed build in the store. I haven't tried taking advantage of that yet. It might improve the workflow <lfam>It's not a very good script, but it usually works ;) Sometimes I have to change the build command invocation, and the rsync flags have evolved over time <lfam>If there are *many* differences, you will have to redo the last step with `diffoscope --max-report-size BIG ...` <lfam>Hopefully it doesn't come to that :) <janneke>my how-to question is more than solved with a script that mostly works, thanks! <Kooda>ACTION has been working on making CHICKEN’s compiler deterministic, thanks to Guix’s position on reproducible builds. :) <Kooda>I have a working solution but it’s not that great. I have to start over in a different direction. <lfam>I'm going to email SourceForge and ask for advice. The new owners have made some effort to solicit feedback from their users, so hopefully they will reply <civodul>lfam: i think returning 200 instead of 404 is likely malice, but i hope to be proved wrong! <lfam>civodul: Perhaps, but I don't like to write introductory emails while assuming malice. I sent a message, and hopefully the conversation will be productive. <lfam>If not, that will be very annoying. We would need to change our approach to sourceforge packages. Maybe have the Guix downloader check some content addressed storage like tarballs.nixos.org before the sourceforge URLs? <lfam>Or, tarballs.guixsd.org or tarballs.hydra.gnu.org ;) <ng0>the new owners? sf got a management replacement? <ng0>when is it okay to bump an issues on github or ask for reaction? 3 weeks? It's just 9 days without reply now, but meanwhile others got opened and replied to. <lfam>In that case, it's possible the upstream maintainers are finding something difficult about your report. I would bump it, but make an effort to clarify the nature of the problem and the possible solution, if a solution is known. <civodul>lfam: i was thinking that our download code should indeed check the hash of what it got <ng0>guile 2.0.12 was released? I just saw a version bump of the gentoo bug I'm taking part in <civodul>lfam: this would be redundant with what guix-daemon does, but it would allow us to try another URL when the hash is invalid <ng0>lfam: maybe i split the 2nd issue. the first is rather clear, but I can clarify it <lfam>civodul: I should try reading guix/download.scm to see how much I can understand. My knowledge of Guix internals is still not great. <ng0>how do they version bump something which does not exist <ng0>it's not even a _p$date <lfam>ng0: I see it was released yesterday: ftp://ftp.gnu.org/pub/gnu/guile/ <ng0>meanwhile 355355 is solved at our (outside gentoo tree) side for a while now, and I predict it won't be solved internal with their stupid backwards compability by 2020 <janneke>oops, somehow sent the wrong patch to -devel... <jmd>... and the worst of us. <lfam>How can I get a list of all the packages that use the SourceForge mirrors? I want to pass the list to `guix lint --checkers=source` <lfam>It's really annoying when security update patches include binary content. <lfam>It assumes use of git to apply the patch <ng0>i'm updating gentoo to apply and test the latest guile release, and I' already missing the function in advance to have builds not affect my system without creating a vm in a stupid external way <ng0>would egrep "mirror://sourceforge" not work? <lfam>ng0: I'd still have to figure out what package the matching string was in. I'm sure it's easy in Scheme... <ng0>awk can do matching to include some lines before the result in the output <ng0>*before the matched result <ng0>but maybe it's smarter in guile <lfam>That can be done with grep also: `grep --before-context=n foo` <lfam>Otherwise known as `grep -B` <lfam>Having to remove the binary diffs and their associated changes from the security patches drastically increases the knowledge required to apply security patches. In general, security updates and patches should be easy to apply. <ng0>i think gnupg-2.1.14 was released.. at least that's what my gentoo hardened-musl is failing on now^^ <ng0>I have no energy to test this today on guix.. but i will this weekend <ng0>and libgrcrypt-1.7.2 <ng0>yesterday both.. I'll do it tomorrow or tonight, whenever I am concious enough again <alezost>save it to "/tmp/foo" and run "guile /tmp/foo" <lfam>ng0: I haven't forgotten about your libgcrypt-1.7.1 patch. I've been waiting until core-updates-next becomes core-updates. But now, I can instead wait on a libgcrypt-1.7.2 patch :) <lfam>alezost: Thank you. I will use it and study it too :) <ng0>i know. i know core-updates is being tested, i just can not help testing much currently, but i know more people should test and review stuff <ng0>I'd do the patch today but my focus is not completely there <lfam>ng0: Okay, I can remember to update it to 1.7.2 whenever core-updates-next is ready. It's not a burden <lfam>And it might be a little while because of the problems with hydra.gnu.org <alezost>lfam: np, btw it's better to use "sourceforge" regexp instead of "mirror://sourceforge": I've noticed there are 10 sourceforge packages that don't use mirror form. Look at output of this script: http://paste.debian.net/781793 <lfam>alezost: What is this called? "~a@~a:~/~a~%" I'd like to read about it in the Guile manual <alezost>lfam: (info "(guile) Formatted Output") <lfam>Ah, it's a format string? <alezost>oh, you are not an Emacs user, sorry <lfam>It's okay, I can translate that and find it in the manual ;) <alezost>format and it's "Formatted Output" in the Guile manual <alezost>lfam: translating it into human language: "<name>@<version><tab><uri>" <lfam>I'm currently working on the update of libgd <Gamayun>What module provides config-file? One of your own? <ng0>well okay I'll do libgcrypt+gnupg tomorrow and a bit today. I'm just trying to fix a gentoo system i still need. <ng0>Gamayun: i think alezost has a guile modules collection on gitlab somewhere <ng0>i read into the config deployment thing this week, much better than what i had :) <Gamayun>Hm, yes.. I think I tried looking at it, but couldn't without signing in. <ng0>it's open, alezost-config group i think <alezost>(config-file "foo") returns "/home/me/config/foo"; I keep all my various configs in "~/config" dir <Gamayun>Anyone have an elegant way of appending the contents of a file to the xorg config file? <Gamayun>Never mind, the solution was in alezost's files after all :) <ng0>ACTION appreciates the guix way of updates while fixing the hardened gentoo musl update breakage <ng0>23 updates, and 100 further updates to maybe get from a minimal server this used to be to a maybe X11 desktop