<jmd>civodul: watch out. You'll hurt yourself! <ng0>speaking of which, when will savannah get an cert <lfam>ng0, civodul: It was already in progress when I asked. <ng0>ok, so it could happen soon, which hopefully does not mean at the speed of snails, but within 12 months :) <lfam>Stepping back a bit, in the past 6 months we've seem RCE bugs in the package update systems of both Debian and FreeBSD. Yikes <lfam>We also saw that nobody is sure were RPM is developed or by whom... <lfam>So, that's the two big GNU / Linux distros and the biggest BSD system, without good system update stories <civodul>our system update story is not good enough yet <lfam>No, we aren't there yet either <ng0>there's also funny things and beliefs about portage I don't want to touch. <detrout>You can pull debian packages over tor if you want <lfam>detrout: That sounds like a good mitigation for this vulnerability, thanks! <cbaines>Does anyone know of any attempts to do data processing using Guix? I've been thinking about doing processing of database dumps, perhaps with intermediate stages involving starting PostgreSQL, loading in some data, doing some transformations, and dumping it back out again. <lfam>cbaines: Yes, I think so. Try searching the guix-devel archives for 'pipeline' and 'workflow management'. <detrout>lfam: the downside is you somehow need to get apt-transport-tor <ng0>lfam: I've been a bit out of the loop since I stopped using gentoo. iirc they switched to git to syncing. but previously (and maybe still). it's believed to not be necessary to have default signed tree updates, this was an very optional and hidden item (though in the handbook), but the priority wasn't so high. a very small minority of the gentoo mirrors offers https. that's all I remember right now <lfam>detrout: Well, it probably doesn't make a big difference either way. I doubt these bugs are first discovered by those who disclose them. <lfam>The libarchive / FreeBSD bug analyses were leaked anonymously. <ng0>to add a native tor option to the layman application (for gentoo-overlays) was welcome, but the idea came from our side and as soon as I got the clearnet thing in, we just dropped the idea of investing any effort into that application <ng0>though it's capable of torify.. etc. <lfam>What a mess this all is :) <ng0>I should really only travel at night.. fell asleep on the bus for some hours and now I can't get tired <lfam>"At this point, the code <lfam>isn't aware anymore whether the Release file was clearsigned or <lfam>split-signed, so the file is opened using OpenMaybeClearSignedFile()" <ng0>sneek: later tell civodul: adding to my last sentence, yes I will try to get to some constructive solutions if possible. <ng0>a thing we should do next year: fix curl and gnurl for the last remaining absolute paths which currently somethings make the setenv solution at least curl work not always <ng0>well it just has to be curl, I can chery-pick that into gnurl <ng0>s/somethings/sometimes ***Piece_Maker is now known as Acou_Bass
<paroneayea>anyone around to try a very brief voip test with me? <lfam>Oh, I wish I was free to try it! With a Guix package? <paroneayea>though I haven't had success just recording my voice in audacity <paroneayea>I have this nagging feeling I'm going to need to install debian tonight so I can make this voip call tomorrow. <davexunit>hopefully in like 10 minutes I will have everything <paroneayea>I wonder how likely our package for icecat can be adapted to compile vanilla firefox. probably pretty easy <paroneayea>just in case the person wants to connect via webrtc and I can't get that going in icecat <lfam>Bah, certbot breaks on the python-tests branch. That package is so fragile <lfam>ACTION works on updates to icedtea, NSS <geemili>I'm having trouble using a sha256 hash for a package <lfam>geemili: You need to use `guix hash` <geemili>I'm getting an issue decoding the hash from a string, because it has an invalid character <lfam>geemili: I'm confused. Can you give more detail? <geemili>My thought was that the hash isn't using base32 <geemili>But I can't find anything that describes the sha256sum output encoding <lfam>geemili: Look at the sha256 section of the manual, section 5.1.2 Origin Reference, and also section 6.4 Invoking `guix hash` <lfam>I'm still not sure what exactly you are doing or what's going wrong, so I can't give more specific advice <lfam>geemili: You used the output of `sha256`. You need to use `guix hash` instead. <lfam>Also, the license is not a non-copyleft free software license. Tarsnap is not free software. <lfam>I haven't looked, but I presume that the difference between `sha256 | base32` and `guix hash` is that `guix hash` gives the base32 representation of the "raw" hash, before it's encoded as a hex string. <geemili>lfam: Oh, I just reread what you said about the license. I didn't know that. I'm staying up to late. >.< <geemili>I'm not sure what license it's under. <geemili>It says that the source code hasn't been released under an open source license <lfam>The client source code is available for users to inspect and compile (no binaries are provided), and several components are free software, but the license is not a free software license. The license only allows the user to use the software with the Tarsnap service. <lfam>No server source code is available AFAIK <geemili>But it has parts that are released under opensource licenses <lfam>Yes, most notably scrypt came out of Tarsnap <lfam>It's a password-base key derivation function that a lot of cryptocurrencies decided to base themselves on. It requires lots of RAM <geemili>How do I depend on bash for compilation? <lfam>geemili: Basically, put it ("bash" ,bash) in the (inputs) field of your package definition. Most packages have some inputs, so you should be able to refer to them. Make sure to import the correct module, which is (gnu packages bash) <Apteryx>by "my" package I mean python-pip, which I'm updating to 9.0.1. <lfam>Apteryx: Have you set the variables SSL_CERT_FILE and SSL_CERT_DIR? <Apteryx>Should I? I'm using GuixSD. Usually it does this kind of magic for me, FWIU. <Apteryx>Ah... Maybe I should reboot or at least logout then log back in. <lfam>Is the nss-certs package installed on your GuixSD system? <lfam>I make it available globally in my OS declaration <Apteryx>lfam: It should, it's part of my config.scm. <lfam>Okay, trying to reproduce... <lfam>Works for me "out of the box" on GuixSD. Make sure that SSL_CERT_DIR and SSL_CERT_FILE point to something that exists for you <lfam>For me on GuixSD it's '/etc/ssl/certs' and '/etc/ssl/certs/ca-certificates.crt'. I'm sure this happens automatically <lfam>You're not in `guix environment --pure`, right? <Apteryx>lfam: no! I'm just in my regular profile (nowhere special) <lfam>I see you're in the REPL. Can you test it from the command line? <Apteryx>I could if I knew what to type in :) <lfam>`./pre-inst-env guix lint python-pip` <lfam>Not if you just want to test the linter and TLS. But if you want to test the package definition you wrote, that's how you work from a Git checkout <Apteryx>lfam: OK. I think I had created a symlink directly to my git, so I believe I never need to run that one to get my "in-development" packages. <Apteryx>Still same error using "guix lint python-pip" <Apteryx>Still no luck (same tls error). I'll try reconfiguring my system and see tomorrow. <lfam>If you can't make it work, please file a bug <marusich>Is there a way to force a rebuild of a package that has already been built, the output of which is already in the store? <marusich>Actually, wait, I realize my question is not what I wanted to ask. I really just wanted to be able to see the build log, and there is a command for that. <lfam>marusich: To answer your original question, there is --check <marusich>lfam, I tried that but it didn't rebuild it <lfam>Probably it just --checked a grafting operation, right? Try it with --no-grafts <marusich>I think you're right; the build log also showed two graft messages (I had to look at the build log for the output path it grafted) <ng0>fixing up the pagure patches, I'm almost done. but coming back to monday: pagure is french for "hermit crab", but how do you pronounce it? my french is in sleeping mode most of the time. <ng0>i think i pronounced it right, but who knows. <Petter>I'm thinking "1.0-1.commit" will do. <roelj>Petter: Why not just "1.0-cutoff"? <sneek>roelj, efraim says: you can work around the auto-offload problem with the --no-build-hook flag <sneek>roelj, rekado says: Your problem seems to be that you build Guix in “guix environment guix”, which contains “guile-ssh”. Offloading is enabled when GuileSSH is found at build time. When you run Guix later, however, you do not seem to have GuileSSH available, which results in an error. To fix this: 1) remove guile-ssh from the environment in which you build Guix, or 2) install GuileSSH, or 3) pass “--no-build-hook” <roelj>efraim: rekado_: Thanks! I will try the --no-build-hook when the current builds succeed. <Petter>I need a Guix revision, because we have a checkout after the release. So, if "cutoff" is something to keep, it would be "1.0-cutoff-1.<commit>"? <roelj>Petter: Usually we try to avoid specific commits. Can you pursuade the author to make a new release? <Petter>I'm following the Syncthing manifest, and they use this one specific commit (for some reason) of a library. I think we'll see this regularly with Go projects, so I think we better deal with it. <roelj>Ok. In that case, maybe avoid using the version at all and use the commit ID instead. ***piyo` is now known as piyo
<Petter>Yeah, that's an idea. I've used "release-revision.commit" numerous times already though, so to be consistent I should either do it one way or the other. <Petter>For libraries with no releas at all I've used "yyyymmdd.commit". <roelj>Right, so since you've used "relase-revision.commit" already for other things, there's not going to be any better answer anyway. <Petter>I feel like release trumphs no-release, so I'm a bit torn here. <lfam>Petter: I'd rather use the commits that Syncthing uses, at least for the initial revision of these packages <Petter>Just to be clear, this is only a discussion on what to use for (version). Particularly, when a commit is after a release. <Petter>Also, when the last version contains "extra stuff", like "go1.0-cutoff". Adding revision and commit to this becomes.. weird. "go1.0-cutoff-1.db54ac1" <lfam>When we are using an untagged commit for a project that has at least one previous release, the version string should be version-revision.commit, and 7 characters of the commit should be used <lfam>If that's their version string, then we should use it <lfam>It's not our fault that it's weird :) <Petter>Ok, I'll add that again then, I went with "1.0-1.db54ac1". <lfam>I think we should use what matches upstream. That way readers of the Guix package can more easily understand what software they are using. <lfam>Sorry my review is behind schedule :) <Petter>Cool, I still have no idea if this whole thing works for anyone but me. <Petter>I haven't used the command other than to print out --help. <lfam>Okay, I'll find out when I test it <lfam>geemili: Do you have a Guix development set-up yet? <lfam>Okay. The basic idea is clone our Git repo and build it. You will a file 'pre-inst-env' in the root of the source code repo. Prefix your Guix commands with `./pre-inst-env` to use the Guix you've built from source. <lfam>To try the Rust patches, apply them to your Git tree and rebuild <lfam>See the manual, section 8 Contributing for more detailed instructions on building Guix <lfam>Make sure to read the note about setting localstatedir properly in section 8.1 <lfam>Please let us know if you have more questions :) <lfam>"You will a file 'pre-inst-env' in the root of the source code repo." <lfam>I meant to write, "You will find a file ..." <lfam>And at the end, please give feedback on guix-devel :) <lfam>Almost, but the computer is behind the curtain, working the magic for you <lfam>geemili: I use `git am path/to/patch` <roelj>My Guix talk proposals for the HPC track have been rejected. :( Unfortunately, no exposure for Guix from my two proposals there. <lfam>roelj: That's too bad :( <kahiru>hey, I'm trying to get guix working on my arch installations and all attempts to install any package end with ERROR: In procedure getaddrinfo: Name or service not known. I tried starting nscd (as suggested somewhere) but it didn't help at all. Any ideas what might be the cause? <lfam>kahiru: How are you trying to install Guix? <lfam>Or, how did you install it <Petter>Maybe a network issue. Are you able to ping anything? <lfam>Okay. It sounds like you are having trouble looking up names with DNS. <lfam>I agree with Petter. Are you sure you're online? <kahiru>I can use system curl to download the packages without any issue from the urls stated in the log <lfam>Hm... and there are no other errors messages or warnings printed? <lfam>How about `guix download`? Does that work? You can use it like curl to try downloading something <Apteryx>I've just reported a bug where "guix lint" fails on some gnutls errors. <lfam>Petter: I'm using the Syncthing built from your package. It works! <Petter>ACTION takes 10 pushups to celebrate <kahiru>ifur: guix download works for some of the mirrors, some of the http mirrors return 404, some of the ftp ones fail with 550 - failed to change cwd <lfam>kahiru: Some ideas: Can you run the guix-daemon with `strace -f` to see what it's doing? Is the daemon running as root? You installed 0.11.0, right? Did you run `guix pull` yet? <Petter>lfam: Yes. I temporarily went with git while I figure out how I broke unpacking with tar. <kahiru>the daemon is running as root, version is 0.11.0, I tried running guix pull after things didn't go as expected and it failed as well <lfam>Okay, at this point I'd try using strace, because I'm stumped :) <lfam>Petter: Let's find out what that does. Our package should disable telemetry / stats reporting by default <lfam>I'll ask in #syncthing on Freenode <Petter>I wonder if it's opt-in or opt-out. <lfam>I'm digging around a bit before I ask there <paroneayea>let's add automatic statistical profiling to guix by default ;) <paroneayea>bake in google analytics, right into "guix package -i" ! <Petter>Maybe have some ads pop up here and there as well. That would be great! <lfam>Let's circle back on this later; I have to go meet Donald Trump for the tech summit. <paroneayea>hey I'm not hearing any skips in my streaming radio this morning <cbaines>I'm seeing some issues with nss-certs, with broken symlinks from /etc/ssl/certs to the nss-certs 3.27.2 package <cbaines>This might be related to the update late yesterday <cbaines>No time to investigate now, but I'll have another look very late tonight, or early tomorrow morning <cbaines>This is the target of the broken symlink: '/gnu/store/c7kr9pdni867k2778pykh16sw003kl1s-nss-certs-3.27.2/etc/ssl/certs/AC_Ra??z_Certic??mara_S.A.:2.15.7.126.82.147.123.224.21.227.87.240.105.140.203.236.12.pem' <davexunit>sorry everyone, but functional package management doesn't work except for simple libraries. <cbaines>At the Guix level, I'm seeing errors of the form ERROR: Throw to key `gnutls-error' with args `(#<gnutls-error-enum Error while reading file.> set-certificate-credentials-x509-trust-file!)'. <cbaines>Which is I think when it tries to read the broken symlink <lfam>I pushed the NSS update about 3 hours ago. Did you see that issue before then? <cbaines>I don't think so, but I haven't managed to track down exactly what I did to introduce it, as I think I have a bug in the way I'm isolating Guix for my projects, as the Guix checkout that I'm using for this project doesn't include that commit <lfam>Okay, I'll try to reproduce the issue on GuixSD. I didn't notice it on my Debian system <cbaines>Try: guix environment --pure --container --ad-hoc nss-certs coreutils <cbaines>then: find $GUIX_ENVIRONMENT/etc/ssl/certs -xtype l <paroneayea>davexunit: I think not enough people have actually seen functional package management for themselves <paroneayea>eventually it will win, and *everyone* will be a smug functional package manager weenie <paroneayea>just like how smug the average developer is about git! <ng0>I think it would be nice to have something like fedoramagazine.. write guix related web log entries, for those which are not of so official nature that they need to end up on gnu.org/s/guix news <davexunit>only 8 comments but I thought you might like that people are talking about it <lfam>cbaines: Can you send a message to bug-guix if you can't make it work? <ng0>lfam: why pypi? Because of the updaters? I've read at least one person complain about depending on pypi infrastructure in the past <lfam>ng0: Can you point to a discussion where it was decided that we would not use PyPi anymore? <ng0>there was none, but it was just a preference of some people <lfam>Or those discussions? It's typical to use PyPi in our packages, and I haven't heard a reason not to <ng0>`notmuch search "why pypi?"` doesn't return many messages, less than 30 since end of 2014 <ng0>I have no preference. I'll change the sources back to pypi <lfam>Here's some reasons to use PyPi. We don't have to maintain the URL. We have an automatic updater for PyPi. And we won't need to use the (file-name) fix <davexunit>speaking of tracking, our Mumble package opts users into tracking. <davexunit>there's a checkbox in the setup wizard that is checked by default. it should be unchecked. <lfam>It defaults to 0 ("unset"), but I'd like to know how to build it so it defaults to -1 ("no and don't ask"). The variable is called URAccepted in the Syncthing code. <lfam>Petter: I asked on #syncthing what to chanage to accomplish that, but do you think you could try looking? <lfam>On #syncthing, I asked, "Is there a place in the code where the default usage reporting choice is made? Or does it default to 0 because Go's int type defaults to 0?" <lfam>davexunit: Can you file a quick bug? <kahiru>lfam: so I got that strace, but I'm not exactly sure what I should be looking for in there <lfam>kahiru: Can you put it online somewhere? <ng0>can it disabled though? I just assumed everyone disables those anyway <ng0>maybe just a patch on the source <lfam>Locale error or warning? <lfam>The warning shouldn't cause this <kahiru>anyway I just tried it in a fedora lxc container and there it works flawlessly <kahiru>guess my setup is just broken somehow <lfam>Strange. I wonder what the problem is. I haven't seen this issue before <kahiru>I'll keep poking into it for a while and report back if I find anything <janneke>kahiru: the secure connection failed? <cbaines>lfam, sorry, I should have specified. That find command should be showing broken symlinks, so all the files listed are broken symlinks <cbaines>I get errors "No such file or directory" if I run this: find $GUIX_ENVIRONMENT/etc/ssl/certs -xtype l -exec head {} \\; <kahiru>janneke: it seems to fail even earlier <lfam>The links are good the store <lfam>The links are in the store <janneke>kahiru: ah...i can only get into mega using conkeror <lfam>Sorry, I mean to say that the targets of the links do exist in the store, but the symlink is broken somehow <cbaines>I have a suspicion that its something to do with character encoding <cbaines>The real file with "mara" in the name should be called: AC_Raíz_Certicámara_S.A.:2.15.7.126.82.147.123.224.21.227.87.240.105.140.203.236.12.pem <cbaines>the symlink, as shown in your paste however, points to: AC_Ra??z_Certic??mara_S.A.:2.15.7.126.82.147.123.224.21.227.87.240.105.140.203.236.12.pem <cbaines>Maybe this is something at the profile generation level, rather than at the package level? <cbaines>(got to run off again, I'll be back in a few hours) <lfam>cbaines: I bet you're right <kahiru>janneke: should I reupload it somewhere else? <janneke>but now I'm wondering how you get into mega... <geemili>Building the 'hello' package with a dev build of guix is giving me an error with gnutls <lfam>substitute: guix substitute: warning: ACL for archive imports seems to be uninitialized, substitutes may be unavailable <lfam>Are substitutes authorized on your installation? <lfam>I don't know if that's related or not <geemili>I applied all of the patches for rust except [05/12] and [10/12] <lfam>Do you have Guix installed besides from this Git repo? <geemili>Do I have to make a user group for the build daemon manually? <lfam>geemili: No, on GuixSD it's all set up for you <lfam>The daemon runs automatically <lfam>I'm building a fresh Git clone on GuixSD to see if I can reproduce this <lfam>You tried building hello from the master branch, without any of the Rust patches applied, right? <geemili>I didn't build until I applied the patches <lfam>Yes, I recommend first testing your development setup with the code on the master branch <lfam>geemili: From commit 27fab2bf659 (gnu: python-cryptography: Update to 1.7.1.), I used `guix environment guix` to set up a Guix development environment. Then I did `./bootstrap && ./configure --localstatedir=/var && make && ./pre-inst-env guix build hello`. That works for me on GuixSD <davexunit>I made an attempt to explain to someone how functional package management avoids the problems that are caused by SAT solving <davexunit>not sure if I explained things clearly, though <lfam>Yeah! I started working towards it and got discouraged <lfam>Not too much, really. I added the dependency Vc, which builds on my computer and fails on all architectures on Hydra. <lfam>ng0 sent a patch for another dependency, opencolorio, to guix-devel <ng0>I think I only sent it because someone else was working on it and provided it as an comparison <ng0>I'd say I can finish 0ad when I have cut my roadmaps into pieces where I'll also allow myself flexibility. right now I feel like the only thing the 0ad package needs is the build-time symlink, but you need time to work on it because the data is big <lfam>I think it won't be too much work to finish for someone who sets their mind to it <lfam>Drawn in Krita, I presume ;) <ng0>if someone is very much into games I can post the new progress <lfam>davexunit: It sounds like a cozy rabbit hole to fall into, don't you think? :) <ng0>I started working on some film company software, lightning etc but then I thought I have other things to spent my time on, if companies want this, they can pay someone to package it.. I should post the minimal progress I made there <ng0>wow, gitlab-ce uses markdown in their commit messages.. with pictures <ng0>theoretically you can have pictures in irc <ng0>microsoft added that in the late 90s i think <ng0>geemili: yeah, markdown message style <ng0>i only noticed because I'm doing a feature matrix for comparison, gitlab-ce, gogs, pagure <ng0>opened the git log of gitlab-ce and saw the messages <ng0>works for gitlab webview.. looks bad in the log <ng0>my cat does not aprove <geemili>I think the problem was that I wasn't using `/var` as my localstore <geemili>And I was running the guix daemon manually <lfam>Ah, you almost always want to use /var as the localstatedir, so you can share /gnu/store with the rest of the system 