<vvedantham>When I try guix import pypi readline I get "guix/build/download.scm:296:6: X.509 certificate of 'pypi.python.org' could not be verified: insecure-algorithm signer-not-found invalid" I tried searching for the error online and it seems that my University proxy is changing something. I tried "pip install --trusted-host pypi.python.org readline" but that also did not succeed. Does anybody have any idea how to solve this? Thanks.
<rekado_>vvedantham: you may need to install the nss-certs package and then set the following environment variables:
<thorwil>that i get: config.scm:49:4: In procedure native-inputs: alist-delete: unbound variable
<rekado_>“alist-delete” is not defined. You’re missing a use-modules clause.
<thorwil>hmm, none of the examples here list anything that seems related; apparently it belongs to srfi-1 list library
<thorwil>indeed (srfi srfi-1), which is absent from my examples
<davexunit>civodul, rekado_: I'll be talking about guix at libreplanet this weekend. any recent developments that you think I should mention?
<davexunit>it will be sort of a beginner's talk, but I'd like to cover some new ground as well
<davexunit>the theme of the conference is "freedom embedded" so I'll be repeatedly demonstrating how guix enables the user to exercise software freedom. any cool tricks that reinforce that theme would work well.
<efraim>davexunit: as far as embedded goes, creating a
<efraim>GuixSD image for an arm board is pretty cool
<demotri>I have in mind that there is a difference between github.com/pro/ject/archive/... and /release/... When packaging, the "release" should be prefered, as this is stable, where the "archive" could change slightly, leading to stability-problems with Hashsums. Is that right or have I made that up? Do we have any reference/mail-archive for that?
<soundtoxin>Okay. I was just surprised to not find it, but find similar games that I had not even heard of already packaged.
<bavier`>soundtoxin: we would certainly welcome a patch if you'd like to package it :)
<soundtoxin>I was worried I'd give such an impression. I have no experience with that sort of thing. I'm used to giving up when something isn't packaged on a distro. I've got my own little list of stuff that isn't packaged on guix get.
<rekado_>sahithi-ihtihas: you can run “guix hash” on the source code archive.
<Cogitri>So I'm currently trying to upstream a few patches related to elogind, but I've received some doubts if elogind will update new functionality of logind in a timely fashion and won't keep releases of the respective software back. Does elogind have some guideline about that, or is it "just" "We'll work on it when we have time"?
<civodul>Cogitri: i suppose the latter, but note that elogind is now maintained independently of Guix
<efraim>I thought we had deluge, I'll have to take a look at that
<efraim>I have a local patch for ranger, some of the tie-ins don't work correctly yet though
<nckx>soundtoxin: There was a guix-* list post about the i3lock(s), but I fail at finding it.
<civodul>rekado_: do you have tips to make NFS caching more efficient for the store?
<civodul>stat(2) is quite expensive, so package lookups are slow
<thorwil>does the guixsd default kernel configuration conatin anything special to avoid a dependency on python?
<mbakke>nckx: I think the main reason guix pull is discouraged is that there may be inconsistencies with the manual, e.g. bootloader syntax.
<civodul>castilma: the store is already a cache, though maybe coarser-grain than what you'd like
<mbakke>Also, we do keep substitutes for releases for a long time, whereas master may not have substitutes for everything.
<nckx>mbakke: I'm aware. I just thought it was in the manual, but I guess I was dreaming.
<nckx>Anyway, I wonder which release shoaloak is using since — at a glance — that configuration looked pretty stock and the mode of breakage is pretty... bad.
<castilma>civodul: AFAIU, it doesn't address the issue ccache does. ccache caches compilation units (right name?), /gnu/store caches whole builds. if you built foo-1.0.0, building foo-1.0.1 would take less time using ccache. /gnu/store wouldn't help there in that sense.
<civodul>castilma: right, that's why i said it's coarse-grain
<civodul>so in a sense they're similar, but in practice you're right that ccache operates at a lower level and could be more beneficial in some cases
<nckx>ACTION tries to leave the house, attempt #2. o/
<civodul>however, using ccache can introduced undesired side-effects, even if it's not supposed to, so we don't use it
<mbakke>I used it for years on Gentoo without problems, but still sceptical about Guix use. Gentoo isn't known for their reproducibility efforts.
<castilma>mbakke: that's my only idea about side-effects. but those are always bugs in the implementation, right? caching by itself can not produce nondeterminism; is my understanding correct? so one should be able to live with it as opt-in, as all software has bugs?
<mbakke>I don't know enough about ccache internals to comment on that, unfortunately :)
<castilma>bavier`: you looked into it. what was your conclusion? why didn't you do it? (or did you?)
<bavier`>castilma: I didn't end up implementing anything, because of time and current efforts to rewrite the daemon in scheme. it would be doable imo
<bavier`>it would at least be interesting to run a daemon running --with-ccache and 'guix challenge' it with hydra over time
<ng0>civodul, rekado_ , is it okay if I CC you wrt something Whonix plans on writing a Debian community proposal for exception of Guix and Nix? So far it was okay for me, but writing up something on behalf of the project (or helping to) in this would be more like maintainers work. I'll fill you in the details when Whonix agrees to switch to Email.
<castilma>bavier`: (second post:) exactly my thoughts. (first post:) wouldn't it be pretty simple to implement? replace the compiler with symlinks to ccache?
<civodul>ng0: this is lacking a bit of context, but in general, i have nothing against receiving email :-)
<lfam>efraim, mbakke: On staging, "ERROR: In procedure %resolve-variable: Unbound variable: target-arm32?". Any idea which compiled objects need to be rebuilt?
<civodul>ng0: getting Guix in Debian is something i'd really want to see happen, but that requires work (social work in particular)
<ng0>civodul: yeah, sorry. it spans quiet a lot of time. goes back to the time when bancfc asked about Guix for Whonix. I'll give you the summary in Email + their bugtracker link
<ng0>it's about the social work ;) -> Debian community vote
<dustyweb> - Debian and Guix should be best friends: what's good for one is good for the other (or especially: what's possible to package in one is generally possible in the other)
<dustyweb> - the biggest threat Debian and Guix face is the "giving up" direction of packaging things caused by non-composable language package managers which often are not focused on reproducibility
<vagrantc>i'd be very interested in getting guix into debian!
<vagrantc>though it is a particularly unusual package ...
<dustyweb> - a number of us are happy-ish with GuixSD :) but Debian provides something that Guix doesn't have, which is long term support and stability, a lot of packages that aren't *yet* in Guix, and honestly an amazing community with a more advanced governance model than we have (Guix hasn't needed Debian's level of governance complexity... some day we might!)
<dustyweb> - Guix provides something Debian doesn't have: "guix environment". If Debian folks encouraged people to use Guix for local development, we'd end up with more packages that could be packaged in both Guix and Debian
<dustyweb> - so chocolate and peanut butter, right? :)
<dustyweb> - except: it isn't possible, currently, to "apt-get install guix" in Debian. detrout made some progress:
<dustyweb> - Guix likes /gnu/ and doesn't want to give it up, it's the complement to /nix/, it's a cute name, and it's hard to do something that isn't three characters anyway because of linux restrictions on path limit length iirc
<dustyweb> - Debian doesn't want anything that's not in the FHS, and /gnu/ is not in the FHS
<dustyweb> - 7/8 of participants were women... and we didn't even mention gender on the flier! Instead, we made a call-out to people who wanted to program but felt like they were excluded by being not part of that field