<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? <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>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, https://github.com/lichray/nvi2 -- 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>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>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>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 <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 alpha.gnu.org <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 <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>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. <lfam>Staying warm by trying to compile mongodb ;) <lfam>mb[m]1 and I were chatting about the glibc patches a few minutes ago <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>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>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'. <mb[m]1>I'm leaning towards hosting a patched tarball on alpha.gnu.org. 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 alpha.gnu.org? <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>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 <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>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 :-) <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 <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. <ryanwatkins>Anybody receiving issues installing synergy@1.8.8? I am getting: <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>ryanwatkins: Are you able to bisect it? <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>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>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? <lfam>ryanwatkins: You can send mail to <bug-guix@gnu.org>, describing the problem and including the details we've learned so far <lfam>There are no stupid questions :) Everyone begins in the same place <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? <civodul>nee`: could you paste the command and its full output? <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>mongodb's bundled wiredtiger FTBFS on aarch64 <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. <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 <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>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
<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.