<apteryx>will push a slightly modified version soon if it passes. I rebase the info patch on 5.2.0, adapted for meson. It's simpler, although I'll try to convince upstream again to make it easy to build an info manual.
<lle-bout>no new CVEs so I am looking at fixing pybitmessage still, some obscure python2-sip issue, then still need to go through the backlog of unhandled CVEs but a bit unmotivated for it now, will take on it soon
<lle-bout>I see lots of exciting announcements today in the mailing list!
<raghavgururajan>lle-bout: I have been re-working patches #42958, so that it can be applied on current master.
<raghavgururajan>> lle-bout: raghavgururajan: then you think I should try running GNOME in a VM? Are the services etc. also taken care of or not yet?
<raghavgururajan>This is one of few things from wip-desktop. More to come once we get this # out of the way. Then, as a whole GNOME will be super new and awesome.
<lle-bout>raghavgururajan: alright! so for now scope is just packages, then services?
<lle-bout>3.36+ means I can run tiling pop-os thing :-D
<raghavgururajan>Yeah, that too few packages. More patches for packages are in wip-desktop. Once we are done with this # and applied to c-u, with the help of Danny I will me rebasing wip-desktop <-> c-u, so that I work in remaining patches.
<lle-bout>raghavgururajan: and what is the reason we are trying to merge this with c-u first?
<raghavgururajan>lle-bout: Since the patches in wip-desktop are bulky (contains more changes in a single commit), the idea is that we take few changes out wip-desktop in a batch, split/clean them and merge to -c-u, which eventually goes into master.
<lle-bout>raghavgururajan: you basically do: git add -i, then p, then the number associated to the file affected by potential changes, then you press y or n for hunks to stage, or when you're finished you say q
<lle-bout>after the number, also press enter to start staging hunks of that file
<lle-bout>raghavgururajan: by the way I am trying to fix the use-modules as well, will send an uncommitted patch if you want.. then
<cbaines>I was thinking again about computing channel instance derivations, and whether it's necessary to do that with code running on the system you're computing the derivation for
<cbaines>or to put it another way, do you need to run aarch64-linux code to compute a channel instance derivation for aarch64-linux?
<cbaines>you don't for computing package derivations, but I'm unsure if the same holds for channel instance derivations
<lle-bout>"An issue was discovered in the Linux kernel through 5.11.6. fastrpc_internal_invoke in drivers/misc/fastrpc.c does not prevent user applications from sending kernel RPC messages" CVE-2021-28375 - kernel.org hasnt made a release yet, guess it will come soon
<efraim>found a bug in the recent changes to cargo-build-system
<cbaines>lle-bout, one retroactive bit of review for the cyrus-sasl change, because the replacement package is exported (define-public), there's the possibility of some confusion as the name and version match the other cyrus-sasl package
<lle-bout>leoprikler: and herd restart guix-daemon
<lle-bout>leoprikler: use: while true; do guix system reconfigure /etc/config.scm && break; done
<rekado_>leoprikler: where is that “HTTP situation”? Something wrong with ci.guix.gnu.org?
<PurpleSym>There are multiple issues with HTTP right now. Another one is that --discover is completely unusable, because downloading more than one substitute from a raw `guix-publish` results in an eof error: https://paste.debian.net/1189452/
<civodul>PurpleSym: is there a way to reproduce it? like isolating the way 'guix publish'-that-triggers-EOF runs, and the revision of the guix-daemon that fails
<PurpleSym>civodul: The daemon on both sides was pulled this morning, commit d059485257bbe5b4f4d903b357ec99a3af2d4f39. It looks like it only happens when downloading multiple substitutes from the same auto-discovered guix-publish instance in a row.
<lle-bout>PurpleSym: the issue is around connection reuse so that makes sense
<lle-bout>cbaines: is this issue related to subsitute refactoring?
<PurpleSym>lle-bout: Yeah, in wireshark I see a RST packet sent by guix-publish, which guix-substitutes on the other end apparently does not handle?
<cbaines>lle-bout, I don't know of any issues which the refactoring has introduced, but I have been trying to follow along with some of the open issues
<leoprikler>lle-bout, civodul: Currently reconfiguring, if I don't complain about it again it'll have worked :)
<lle-bout>okay, because the HTTP implementation in GNU Guile is quite ancient and low level, things like connection caching should be handled transparently and never even exposed to the user-facing API AIUI, also HTTP2 support, speeds things up a *lot*
<cbaines>civodul, I think I see how the error handling has changed in process-substitution, I think I may have discounted some of the network related error handling there because no actual data is read
<lle-bout>civodul: low-level as in you must handle connection reuse manually somehow
<cbaines>civodul, but the response header will be, so that bit of the call-with-cached-connection/with-cached-connection error handling would have applied
<lle-bout>Implementing HTTP libraries is huge work I don't think it's a good idea to try and make it Scheme considering we are already with limited hands, on the other hand curl is fast and mature.. and I don't think you would need the additional finer control of Scheme there since curl would just work and expose what you need through it's C and therefore Guile API
<davexunit>bailing out to a C library is not good. may help in short-term, but bad long-term.
<lle-bout>I think bailing out to a C library for HTTP handling is good, C integration is what GNU Guile is made for, I don't see the problem here
<davexunit>replacing Scheme code with a C library is going to be a very hard sell in Guile land.
<davexunit>as a community we generally work towards the opposite goal.
<civodul>cbaines: would it be an option to revert this patch series? that's a bit brutal but we could then start afresh from a "known state"
<cbaines>civodul, it's an option, but that seems more work than just adding back error handling around fetching nars
<lle-bout>davexunit: nothing prevents from writing complete HTTP library in GNU Guile and changing it back, it just doesnt exist now, so
<lle-bout>But I think once this issue is sorted, HTTP 1.1 with TCP connection reuse may very well suffice performance-wise in GNU Guix for a good while
<roptat>what do you mean by huge speed up with HTTP 2.0?
<lle-bout>roptat: HTTP 2 could allow to download all substitutes required in a single TCP connection in parallel, with HTTP 1.1 and connection reuse you are stuck with 1 substitute at a time (sequential)
<lle-bout>It is ideal for maximizing bandwidth usage
<roptat>so you don't have to send more than one header?
<lle-bout>roptat: you do, but HTTP 2 implements a multiplexing protocol to send multiple requests (queue-ing them up) in a single TCP connection (avoiding TCP handshake latency for parallel requests)
<lle-bout>HTTP 2 also features header compression (HPACK)
<lle-bout>but it's not very important for us (header compression)
<roptat>right, comparing the size of headers vs substitutes ^^
<lle-bout>substitutes are especially fit for this use case, since they can be numerous, introducing many requests
<lle-bout>roptat: yes don't know exactly what it is, I mean more generally the substitute fetching phase of GNU Guix
<roptat>from your description I feel like HTTP2 would be beneficial below a certain ratio of data size / request
<roptat>there are two parts: fetching substitute information (narinfo), and fetching substitutes themselves (binaries, in nar archives)
<roptat>the first one is obviously fast because there aren't too many data, but that's probably where you get the most speedup, though it's not really interesting
<roptat>for nar, I don't really understand how multiplexing could help, they're big files, and not so many requests per MB
<lle-bout>I think it is beneficial in every way, individual requests may be slow for various reasons like disk I/O, if you can queue many requests up, these bottlenecks disappear and the systems become fully utilized I/O wise up to their full potential
<cbaines>civodul, which makes me unsure how this could act to retry a request, if it's just going to re-raise the original error anyway?
<lle-bout>roptat: but more generally, it means GNU Guix can send in one row all things it needs and the server can answer all at the same time also, so bandwidth is full as much as it can (and therefore faster..)
<lle-bout>roptat: dnf over at Fedora's implemented something even better, that is, fetching from multiple repo mirrors at the same time, which will come naturally to us when ipfs/gnunet support is complete
<lle-bout>ipfs is even better since it can download chunks of substitutes from different places
<roptat>help, I'm kinda sold on the idea of using http2 now
<lle-bout>Some times I felt like substituing over SSH was faster than HTTP
<lle-bout>roptat: for it to work we also need server-side support, so not sure how the substitute server currently serves them
<lle-bout>curl doesnt do server side AFAICT, we would need nghttp2 bindings or something there
<Aurora_v_kosmose>lle-bout: Oh, that's unfortunate, but good to know it's not just me. In the meantime I'll keep manually pulling failing derivations with guix-build.
<lle-bout>rekado: if you have lots of fast SSDs to use as cache then it's probably fine
<lle-bout>whether it's at the end faster to offer only one single compression algorithm to all users and cache that or offer several and cache all of them (worse off caching diversity), that I don't know
<lle-bout>seems like server compute power is not a problem here
<lle-bout>It would be nice to have more granularity when it comes to trusting substitute servers keys (like for what purpose exactly, temporary append-only store in a container you can discard modifications of maybe..)
<jackhill>pkill9: what subvolume arrangement are you going for? I have my home volume on a different subvolume, but have /gnu/store on subvolid=5
<jackhill>I couldn't figure out how to get grub to load the kernel and initramfs from a different subvol (although with Guix, btrfs snapshop and rollback of the volume with /gnu/store is less compelling, so I decided I was fine with that ☺)
<pkill9>jackhill: i have /home on a different partition
<pkill9>i'm not sure what the purpose of different subvolumes is
<atw>Building openjdk@14 is failing for me, and I see "Connection attempt failed: Connection refused" in the build log, which I think sounds a little suspicious. Have other people experienced this?
<jackhill>pkill9: cool. I meant to address my replies at Gooberpatrol66 as well. For me a different subvolume means I can keep independent snapshots and send/recv it for migration and backup
<pkill9>oh yea, i get it for snapshots, but, other than that i'm not sure
<Gooberpatrol66>most of guix is disposable because it can be generated from a single file, so that's a lot of data that you can exclude from your backup subvolume
<roptat>well, I'll send the message later this evening if nobody reacts :)
<nckx>roptat: Good idea :) Can't comment on the contents (I assume that if you wrote it, it's the way things are?), but don't really get ‘If it's not on weblate, what are you waiting for? :-)’ -- if you mean ‘ask them to add it’, you might want to explicitly point out that it's possible, and how.
<roptat>I actually got the string freeze date wrong, we're planning it for the 12, not 11, otherwise I think the rest is correct ^^
<roptat>I think it's just as easy as pushing a button for the users, you just have to visit the component and "add your language"
<nckx>I guess what I mean, then, is I don't understand the difference between ‘If your language is on weblate but not yet in the Guix repository’ and ‘If it's not on weblate, what are you waiting for?’.
<nckx>It's probably obvious if you know even the first thing about Weblate, but I'm an example of someone who just started clicking enough random things to start translating ☺
<nckx>So the first quote is, for example, the ‘nl’ situation? I've created a translation for it but it's not in guix.git.
<roptat>but I can remove the sentence if that's confusing
<nckx>I think it could be confusing if you're not familiar with how Gettext works (and to a lesser extent Weblate) and why ‘adding a language’ is a multi-step process. But that might be obvious to ‘real’ translators of which I am not one.
<nckx>Just someone who got sucked into translating 😛
<apteryx>diffoscoping qemu has an ETA of 2h20. Hmm.
<bone-baboon>I have been using the --no-substitutes flag when installing software. Icecat has a dependency on rust. Rust has a dependency chain of previous rust versions. Why does rust require these previous versions?
<lfam>bone-baboon: They are the "bootstrap chain".
<lfam>In order to build Rust, you have to have the previous version of rust
<nckx>bone-baboon: At the end, you have the latest Rust compiler. At the beginning, you have mrustc, a Rust compiler in mrustc. ‘Bootstrapping’ as a concept or good practice has nothing to do with bootstrappable.org, which I guess you'd call an ‘awareness campaign’/extended hackathon to bootstrap more stuff.
<apteryx>bone-baboon: note that on core-updates the time to build the full rust bootstrap has been halved, mostly by bootstraping directly from a newer rust and getting rid of the tests of the intermediate rusts.
<bone-baboon>apteryx: So the tests are only done for the version that are dependencies of programs?
<nckx>rekado: Is there no IPv6 at the MDC? Could it be arranged for berlin? Alternatively, is it possible for berlin to respond to ICMP pings from a whitelisted IP address?
<apteryx>right; the test suite on core-updates is run only for the current rust version, which is the only one made public.
<apteryx>lfam: had you tried running --check -K on qemu 5.2.0? It doesn't seem to be reproducible. ISTR it used to be.
<pkill9>does anyone know how to use a daemon to execute a command, that would act like calling it normally, i.e. the calling program would get the output of the command, and the calling program can write to the opened program's stdin
<pkill9>the usecase is executing a command from within a container, but with the command executed outside the container
<pkill9>but still connected to the shell or whatever than called the program
<nckx>Yar54: I think some people don't understand what trademarks are and aren't, and it leads to suboptimal decisions like that one.
<mubarak>yesterday I tried installing Guix 1.2.0 amd64. but i faced a problem in my /etc/config.scm after modifing desktop.scm. When I run "guix system init /mnt/etc/config.scm /mnt" I get error like ( many wrong numbers of arguments in system init) I think that what i get every time I run guix system init