<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>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.
<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>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.
<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'.
<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?
<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
<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.