IRC channel logs


back to list of logs

<civodul>CharlieBrown: probably 'gtk+'
<civodul>ACTION -> zZz
<civodul>happy hacking!
<buenouanq>Do any freedom respecting e-ink readers exist?
<DusXMT>I wonder, is it okay to make packages for git projects, with versions that aren't linked to a tag/release? This one pretty nifty project I'm thinking of packaging has had its last release several years ago, with plenty of bug-fixes in-between
<DusXMT>If so, how does one version such a package?
<DusXMT>(perhaps by a date?)
<brendyn>DusXMT: there are examples in the repo
<DusXMT>Okay, thanks, just wanted to know if it's okay at-all, seems like yes :)
<brendyn>Well I'm not the boss or anything. Others have said they don't really like -git versions, but in this case there isn't any other choice
<DusXMT>There would be, using the old releaes, but having the bugfixes of recent times would be nice :)
<brendyn>I think Guix should be able to package every kind of software, but at the moment there is just one repo and I don't think the devs want -git versions in that. If Guix Channels get implemented then there could be a -latest channel in theory.
<catonano>DusXMT: one example is python-genshi
<DusXMT>catonano: Thank you :)
<catonano>the development is stagnating, the master branch contains some fixes, more fixes are being deployed by some distro suchhh as fedora and Ubuntu. It's a dependency of Tryton
<DusXMT>I'm thinking of upgrading the aging nvi package with a maintained fork, -- it uses BSD extensions pretty heavily, so but thankfully with libbsd it shouldn't be too difficult to port over - am working on a "GNU Compatibility Patch" :)
<DusXMT>s/so but/but/
<DusXMT>I have to say though, some of the bsd extensions, like strlcpy, are pretty neat :) Sure, you can eg. use snprintf instead, but that's needlessly inefficient
<DusXMT>Okay, a little status report: it looks like there are some incompatibilities with our berkely db and theirs; nvi2 compiles (after having all the files include), and it can open and edit files just fine, but it can't save them, neither can it be closed by normal means (reports errors, seemingly related to the database)
<DusXMT>*(include the libbsd variants of the standard library headers)
<cbaines>Does anyone know much about the certbot service? From the bug, it looks like dustyweb was going to merge the relevant patches.
<mb[m]1>Bah, the glibc gitweb instances give "403 - Snapshots not allowed" when attempting to download a tarball.
<dustyweb>hey cbaines
<dustyweb>I was going to do that
<dustyweb>but then I realized there were some issues with it at present
<dustyweb>mainly that it breaks the default nginx that *doesn't* use certbot
<dustyweb>by looking for stuff in the filesystem, eg in /etc/, on system build
<dustyweb>IMO we shouldn't do anything that looks at the filesystem at system build time
<dustyweb>init is another thing
<dustyweb>eg that may unexpectedly break things for something you wanted to build to send over the network, or test in a VM
<dustyweb>but... I was swamped because I was wrapping up activitypub
<dustyweb>so I mostly just put my thumb in it and said "I'll get back to this soon" ;P
<dustyweb>quietly, unhelpfully, to myself
<cbaines>dustyweb, interesting, I've been working on a patch today to get nginx to only warn on system build if the SSL related files are not there
<cbaines>I'd also be interested in removing the check, but changing the error to a warning seems a good first step
<lfam>mb[m]1: Is there a consensus about what to do with the glibc patches? civodul has a point that it's not really reasonable for all the downstreams to handle this high volume of patches themselves
<sneek>Welcome back lfam, you have 1 message.
<sneek>lfam, efraim says: utox got check as an input, should it be a native-input?
<mb[m]1>lfam: civodul suggested getting a gitweb tarball, or as a last resort host a tarball on
<mb[m]1>Snapshots are disabled in the glibc gitweb instance, so I think we'll have to go for the latter.
<lfam>I have to admit, I don't really understand why they don't release 2.26.1, if they want everyone to use these patches
<mb[m]1>Beats me.
<lfam>mb[m]1: This message changes my perception of the purpose of the stable branch:
<lfam>Specifically, "Giving a name, or releasing a named point release from the release branches implies something it is not, namely a fully tested release."
<lfam>So I guess that they do not do their full test suite against that branch
<lfam>And also this message, about their being release-blocking pending patches for a hypothetical 2.26.1:
<lfam>So, I guess the "stable" branch is not really ready
<lfam>Or, it just refers to a stable ABI, but not another relatively undefined concept of "stable"
<mb[m]1>Right. Should we just stick to pick out anything that looks important?
<thomassgn>buenouanq: A year or 2 ago I got my kobo; it was at the time the best compromize between "available in shops where I lived" and "good battery and screen" and "freedom 'respecting'".
<lfam>mb[m]1: Yeah, considering that it's proving to be so cumbersome to use all the patches, maybe it's better to just take the few that fix obvious problems
<thomassgn>buenouanq: By that I mean, they don't overtly go out of their way to subjugate you. I haven't noticed that they do it covertly either. In addition they have a linux based OS with a public (maybe free, but I can't remember) SDK. so there exists some libre stuff for it; and modding is possible.
<civodul>Hello Guix!
<lfam>Hi civodul and brendyn!
<civodul>hey lfam!
<civodul>how's everything over there? :-)
<lfam>Sunny and cool :)
<lfam>Staying warm by trying to compile mongodb ;)
<lfam>mb[m]1 and I were chatting about the glibc patches a few minutes ago
<civodul>oh good
<civodul>what are the conclusions?
<lfam>I read the whole libc-alpha thread, which clarified some things for me. The "stable" branch is about a stable ABI, but the branch itself is not fully tested, and may even be incomplete, pending patches from the master branch
<lfam>So, we should probably not take the whole branch as-is.
<civodul>oh i see
<civodul>so it leaves it up to distros to make the right choice
<lfam>Yes, they say that somewhat explicitly in the discussion. Although I don't know all the glibc developers, so take my use of "they" with a grain of salt
<civodul>maybe the initial 2-3 patches that mb[m]1 had identified are good enough?
<civodul>what's your take?
<civodul>if in doubt, we could explicitly solicit help on libc-alpha
<lfam>We definitely need those patches to build icu4c, which is the reason we started looking into this originally
<civodul>the question is whether we take any additional patch, i guess
<lfam>I didn't read them yet, so mb[m]1 is our expert :)
<lfam>I think the issue upstream is that they simply don't have the resources to do point releases to their usual standard. And for us, we also lack the resources (time, energy, expertise) to review all those patches.
<mb[m]1>lfam: The second of the potential release blocker patches has been applied to the "release/2.26/master" branch. IIUC the first would invalidate the need for all those workarounds, but apparently caused some problems in 'master'.
<lfam>What do you recommend?
<mb[m]1>I'm leaning towards hosting a patched tarball on I do believe the release branch is currently "stable".
<lfam>Whatever we do, we should describe it and our reasoning to libc-alpha afterwards. Maybe they would appreciate the feedback
<lfam>civodul: What do you think of mb[m]1's idea to host a tarball on
<lfam>Personally, I think we should either do the tarball *or* just a handful of patches. But soon :)
<mb[m]1>We could also host just the patches.
<mb[m]1>And pull them in in a similar fashion to "bash".
<lfam>Or could we fetch each patch from glibc's git repo? It would be nice to avoid hosting it ourselves
<civodul>lfam, mb[m]1: i'm fine with hosting a tarball
<civodul>or few patches
<civodul>i wonder whether/how we could use git-lfs
<civodul>or maybe it wouldn't buy us much compared to our (content-addressed) mirrors
<lfam>I am eager to start building :)
<lfam>Change of subject, it's really amazing how expensive mongodb is to build!
<efraim>i should try that again, I think that was the one I had changes for the snippet but kept on running out of room to build
<lfam>I just gc-ed to try again
<efraim>i think my swap and free space ran into each other, or 20GB of swap wasn't enough
<lfam>I'm rebuilding while testing the new scons-build-system
<lfam>Err, really?!
<efraim>probably actually out of free space, i've run guix gc since then
<lfam>I started with 9 GB free
<lfam>I wonder if it will fail again in an hour
<civodul>woow, is it tests that take this much space?
<lfam>It's still in the 'build' phase but ~3 GB have been consumed
<mb[m]1>lfam: The gitweb generated patches contains a git version signature, and I think glibc should be reproducible forever.
<civodul>lfam: is it C++? if so, make sure to build with "-g0"
<mb[m]1>Ideally we would upload a reproducible build artifact.
<lfam>mb[m]1: Ah, too bad
<lfam>That version signature... is there a point?
<civodul>lfam: yes, it allows attacker to know whether the web site runs a vulnerable version of gitweb :-)
<lfam>My thoughts exactly ;)
<mb[m]1>Maybe they're spoofing it (2.9.3) in which case it should be stable :P
<lfam>Whenever people start weaponizing the SHA1 collisions, it's going to be very confusing and messy. It could already be happening and people would probably not notice
<mb[m]1>I'm considering writing a git-fetch/tarball that preserves the original permissions.
<lfam>I'm adding exiv2 to my list of things to watch closely. They have a new maintainer and it seems like there are lots of low-hanging C-language fruits being picked
<lfam>The recent bug reports:
<efraim>the new gcl failed on aarch64, trying again with 1 core
<lfam>Oh man, 9 GB was not enough to build mongodb :(
<mb[m]1>How about uploading the output of `git archive --format=tar HEAD | xz --threads=0 -9 > $(git describe).tar.xz` from the "release/2.26/master" branch?
<efraim>ok, gcl built on my aarch64 substitute server
<mb[m]1>I get SHA256 bb820681fd8621bb32f81080bb9895e830ce17827515cfef2d54d98ccd015b44.
<mb[m]1>Not sure if additional bootstrapping is required.
<civodul>mb[m]1: sounds reasonable
<ryanwatkins>Anybody receiving issues installing synergy@1.8.8? I am getting:
<ryanwatkins>phase `build' succeeded after 81.4 seconds
<ryanwatkins>starting phase `check'
<ryanwatkins>phase `check' failed after 0.0 seconds
<ryanwatkins>builder for `/gnu/store/xwj5qbqkn4ybiiwskypfgglqyvkl539s-synergy-1.8.8.drv' failed with exit code 1
<lfam>mb[m]1: I get bb820681fd8621bb32f81080bb9895e830ce17827515cfef2d54d98ccd015b44 for glibc-2.26-91-gaaa2eb83b8.tar.xz
<lfam>So, looks good :)
<lfam>ryanwatkins: Hydra shows that it started failing to build somewhere between commits c3bece to 411937:
<lfam>ryanwatkins: Are you able to bisect it?
<ryanwatkins>lfam: bisect? :)
<civodul>ouch, 'herd status' no longer works in 'guix system vm'
<lfam>ryanwatkins: Yes, `git bisect`. Or just browse the commit log in that range and see if anything stands out
<lfam>ryanwatkins: You could also compare the build log from a succeeding build:
<lfam>Bisection is usually much easier than reading 2 weeks of commits
<ryanwatkins>lfam: how do I perform git bisect, am I able to somehow git clone that part of hydra?
<ryanwatkins>lfam: or should I git clone guix and git bisect {x, y} somehow
<lfam>Oh, I think we have an obvious candidate:
<lfam>ryanwatkins: `git bisect` is a Git tool that walks through a Git history and applies a test that you define at each step. It does a binary search for a particular result of your test.
<lfam>So, you can find when bugs were introduced in a mostly automatic way
<lfam>I'm guessing that synergy-core doesn't include the test suite or something
<lfam>Or maybe we are invoking the tests incorrectly, or something like that
<ryanwatkins>lfam: I also think it's something do with the tests, yup
<lfam>Can you investigate? If not, can you file a bug so we don't forget about it?
<ryanwatkins>lfam: My investigation would be poor. How do I file a bug?
<ryanwatkins>lfam: I know these are stupid questions :D
<lfam>ryanwatkins: You can send mail to <>, describing the problem and including the details we've learned so far
<ryanwatkins>lfam: Brilliant. Thanks
<lfam>There are no stupid questions :) Everyone begins in the same place
<ryanwatkins>lfam: Okay, well that's good!
<ryanwatkins>lfam: Hopefully it sent, my gnus config is troublesome lol
<efraim>interesting, gcl builds on my odroid-c2 but fails on the firefly
<nee`>I found a package name that is spelled wrong. 'pngcrush' is named 'pngcrunch' in guix.
<efraim>i hope that wasn't me, that's totally a spelling error I would make
<nee`>I guess the right thing is to make it a deprecated-package and fix the name.
<lfam>nee`: Yeah, that's a good idea
<nee`>When I run make in the current origin/master I get an unbound variable: gzip error in scripts/pack.scm. I also ran make clean and redid bootstrap and configure. I can't see an error in pack.scm. Does anyone else have the same problem?
<janneke>nee`: apparently no problem here
<janneke>didn't do a full clean tho
<civodul>nee`: could you paste the command and its full output?
<nee`>civodul: I'm trying a fresh checkout now
<nee`>fresh clone I mean
<nee`>It seems to work on a fresh clone. Is there anything else to reset other than `make clean && ./bootstrap && ./configure --localstatedir=/var && make`?
<efraim>qtsensors failed on x86_64
<efraim>mongodb's bundled wiredtiger FTBFS on aarch64
<nee`>okay I sent a patch to fix the wrong pngcrush name:
<adfeno>Hi all, is it normal for `sudo ./pre-inst-env guix-daemon --build-users-group=guixbuild' to make the terminal busy?
<efraim>you should see the output that would've gone to the system log
<adfeno>"/var/log/syslog" doesn't have anything new related to Guix.
<adfeno>It's apparently just siting there... I'll try attaching an strace to it.
<efraim>is it empty?
<efraim>i deleted mine earlier today
<ng0>So I guess I won't run guix pull again on this server as long as it is under heavy load from searx popularity and other stuff.. with 512MB RAM it took almost one week to pull :D but at least I was able to pull again
<OriansJ>ng0: spinning disk and 2GB swap?
<adfeno>efraim: If "it's empty" in the sense that no guix-daemon message came to syslog since I started it from pre-inst-env, then my answer is: yes, it's empty.
<ng0>6GB swap
<OriansJ>ng0: ouch
<lfam>One week?!?!
<ng0>I didn't keep time, but at least 3.9 days.
<ng0>I had to restart one time
<OriansJ>lfam: swap to spinning disk can case multiples of 100 delays
<lfam>Yes, I do it on a VPS too
<lfam>I guess the difference is I have a full GB of RAM
<lfam>It takes several hours. One week is really wild
<vagrantc>how feasible is it to download the whole OS into an initramfs and run with rootfs in ram only?
<vagrantc>obviously, ram-constrained, to some degree ... but is there support in guix's initrd generator for that?
<roptat_>rekado: I've just built /gnu/store/xgmivamp6x06gb8a89d9p4gpcxg8fa1z-groovy-2.0.0beta3 \\o/
<roptat_>now I probably need to wrap the binaries and it should be working
<roptat_>I couldn't run the tests because they depend on hsqldb
***roptat_ is now known as roptat
<roptat>now I need to go to bed
<civodul>nee`: regarding the 'make' error you got, that's weird
<civodul>i suppose it's not fully reproducible, is it?
<nee`>civodul: The same error keeps happening in that directory. I have a bunch of branches for my patches in there that I kept switching between, but for the last one I did `git fetch && git checkout -b newbranch origin/master`. I think there is some weird state somewhere.
<buenouanq>thomassgn: thank you, I'll check it out