<guixy>I even try "guix build --with-source=python2=/tmp lci" expecting it to complain relative to how /tmp is empty. But it says it's unaffected by --with-source
<str1ngs>sneek: later tell guix-vits. Hello, C-e aka 'end-of-line should now be fixed in emacsy. I've updated nomad-git to use the changes via emacsy-git. So if you pull nomad and guix environment -L guix noamd-git it should reflect these changes. Please test it out and let me know if there are any issues 👍
<sneek>Welcome back guix-vits, you have 1 message!
<sneek>guix-vits, str1ngs says: Hello, C-e aka 'end-of-line should now be fixed in emacsy. I've updated nomad-git to use the changes via emacsy-git. So if you pull nomad and guix environment -L guix noamd-git it should reflect these changes. Please test it out and let me know if there are any issues 👍
<nckx>The freezer (cgroup, which has nothing to do with echo freeze > /sys/power/state, by the way) is part of %control-groups which is part of %elogind-file-systems which is added to the defaults by elogind-service-type, which I added to SERVICES and rebooted. Although I didn't verify its existence, I ran only ‘herd status | grep logind’.
<nckx>And 5.4-generic on the other one. For science.
<nckx>guix-vits: One reason is that you can't use (description (string-append (package-description linux-libre) " but with a spoiler!")) because it breaks translation. So you'd have to write and sync each description as a full copy. A minor inconvenience but could get messy.
<nckx>I guess the nature of linux-libre-arm64-generic is obvious to aarch64 people, or at least to the one who added it, but it isn't to me. Why is it a ‘specialised kernel variant’ (comment)?
<guix-vits>nckx: IDK! I just wish a low-power desktop XD
<nckx>guix-vits: Well, try without a (kernel ...) field altogether, or (kernel linux-libre-5.4).
<str1ngs>guix-vits: I don't want to talk about qutebrowser right now. I had someone in #emacs randomly look at nomad's code to profess some part was insecure without having any understanding of the code at all. Then go on to profess how secure qutebrowser is. It was dishearten considering it was #emacs
<str1ngs>guix-vits: I'll have to check epiphany last I checked it did'nt work on guix regrads to webrtc
<qyliss>determining battery capacity isn't an exact thing
<bdju>well, my panel normally just says it's fully charged, but a bit ago my cpu temp was high and it had fallen below 100% so was charging (using more power than it's receiving maybe), now I got my cpu to cool down but my panel still shows it as charging and now 105%
<apteryx>bdju: is the 'acpi' command reporting the same (I guess)
<bdju>`cat /sys/class/power_supply/BAT0/capacity` reports the same
<nckx>If you override the default kernel (which is linux-libre, or linux-libre-5.4 if you need an older version) you technically know what you're doing, but this should still be clarified. Coming from x86 I'd expect ‘generic’ to mean ‘default’, not something wildly different.
*nckx @work, will look later but the only certainty is to test. I ath9k but can't boot with linux-libre so I'm out.
<terpri>hendursaga, if artistic 2.0beta5 is a free license, you can use the fsf-free function with the URL to the license as an argument (like '(license:fsf-free "https://www.tug.org/texlive/copying.html")'), but you might have to email email@example.com for confirmation that it is in fact fsf-free
<terpri>hendursaga, alternatively, since it's dual-licensed, you can just mark it as gpl2(+?) and leave a comment about the dual-licensing
<terpri>yeah, the beta5 part was my only concern there (i'm not familiar with the artistic license at all)
<jackhill>The way to start is probably comparing the text. If we're lucky there are no significant differences.
<terpri>imho we should adopt SPDX for licensing info, as it has "license operators" other than "list", and being RDF-based can be expressed as sxml (if there's not some superior rdf serialization for scheme)
<nckx>guix-vits: I can't even reconfigure to -generic, because it's missing a module I use: kernel module not found "xhci-pci" "/gnu/store/i32ifayy1an2x2lnhzw27j5l65vvi6il-linux-libre-arm64-generic-5.8.3/lib/modules"
<nckx>I suspect it's some spartan defconfig base meant for further tweaking. Or it just happens to work on someone's board.
<terpri>(or consider it anyway, it gives more options for clear, machine-readable licensing specifications than lists-of-licenses and code comments...)
<apteryx>Using a TP150 dongle, sometimes NetworkManager gets confused and asks for credentials, and the quick fix is to unplug and replug the dongle, but that seems a NetworkManager/GNOME issue rather than a driver one.
<pancak3>so I've gone and messed up my entire computer yet again. Somehow I managed to make the /var/guix/profiles/system/parameters file be completely blank (Not sure how I managed this. All I did was a reconfigure). This causes guix to crash when trying to switch profiles. I would just link the system parameters to a working profiles parameters but of course /var/guix is read only :/ help please.
<nckx>pancak3: /var/guix isn't, but /gnu/store is. ‘parameters’ is a symlink to /gnu/store/<hash>parameters. You can ‘mount -o remount,rw /gnu/store’ and replace the file. This is very naughty, and will void the warranty we don't offer, but it's an option.
<Kimapr[m]>I think you may have a filesystem corruption
<nckx>A better fix would be for Guix not to crash, if at all possible.
<nckx>Empty store file == classic corruption, yes.
<str1ngs>nckx: I had to tweak the substitute-keyword-arguments expression abit but it's building now.
<Kimapr[m]>nckx: don't we have 'guix gc --verify=contents,repair'? Ah wait it only downloads substitutes, it doesn't try to build anything, right?
<nckx>pancak3: You should run ‘guix gc --verify=contents,repair’ as soon as you've fixed this.
<str1ngs>it's a sophisticated expression it's understandable. I'm still unpacking it in my head. scheme does that to you :)
<str1ngs>quote by Eric S. Raymond also comes to mind under these situations. Lisp is worth learning for the profound enlightenment experience you will have when you finally get it; that experience will make you a better programmer for the rest of your days, even if you never actually use Lisp itself a lot.
<nckx>I find it very hard to type syntactically correct Scheme in a one-line input box. For some reason my brain needs 2 dimensions. I'm proof that counting brackets doesn't work 😉
<str1ngs>nckx: what's funny is I actually thought. I wonder if this is because you wanted a one line snippet.
<leoprikler>if the brackets don't match up, just assume an infinite amount of closing brackets at the end
<pancak3>so `sudo guix gc --verify=contents,repair' did fix a bunch of things, but it also spat out a bunch of messages saying "error: cannot repair path" or "error: error parsing derivation". Should I be afraid?
<pancak3>nckx: Not that I'll actually have any time to triage any bugs since I'm going back to school, but did we ever figure out the debbugs procedure for doing that? Did we ever get our guix debbugs email alias?
<terpri>pancak3, i'd be concerned, enough to check the SMART status (using smartctl from smartmontools) and run an fsck (or the equivalent for your fs)
<pancak3>terpri: Thanks for the concern. Maybe I'll check it but I'm not super worried. I had loaded some kernel modules that stop me from being able to reboot (no clue why)g. So I did a reconfigure, and then basically pulled the plug. I think it did a few shutdown tasks, but not many.
<str1ngs>hello I optimistically thought I could inherit gstreamer to produce a gstreamer-next, but I need to remove the 'move-docs phase. Am I going about this the right way? http://paste.debian.net/1161480
<str1ngs>it seems to not delete the 'move-docs phase.
<pancak3>str1ngs: I have no clue, but looking at emacs-next, they wrap the arguments keywords like this:
<nckx>I'd use it if it would facilitate this workflow though.
<pancak3>I found a few cases where both emacs and guix where hardcoded for various things. However, in order to use the user "guix" I think they have to setup an email alias on their machine so that "guix" is a valid email.
<str1ngs>hmm this gstreamer is stubborn! starting phase `move-docs'
<Noclip>nckx: Is there a list of all bootstrap binary files in the guix repository which are not part of the main bootstrap seed for guix?
<sneek>vagrantc, nckx says: Could you explain the difference between the ‘generic’ arm64 linux-libre and the default? For an x86-head like me it's quite confusing that they are (very) different; I'd expect generic == default == boring == always works. But -generic won't even run elogind.
<Noclip>nckx: Yes, packages like ccl that aren't built from pure source is exactly what I mean.
<Noclip>nckx: I think if we want to take bootstrapping seriously there should be a list of all binaries in the guix repository which are currently not bootstrapable. (Including the main bootstrap seed for the distro.)
<nckx>guix-vits: Thanks, but this is explicitly about ‘seeds’ that aren't used as part of Guix's bootstrap, but to build a certain package higher up. Like we go to great lengths to bootstrap Rust from GCC, but ccl (a Lisp) simply downloads a binary image and builds itself with that.
<nckx>This is apparently not uncommon in Lisp-land but it's not good.
<nckx>Noclip: I completely agree. I don't think there is such a list. It's just tribal knowledge (and probably very spotty at that).
<nckx>We're definitely (IM‘H’O 😉) leaders in distro-level bootstrapping thanks to the work of jan neke, sample t, Orians J, and probably more people I forget. I'm not sure we have less ‘naughty packages’ than, say, Debian. Would debian accept ccl? They don't seem to have it, but maybe that's just because they use a different name or Guix has more weird niche lispers.
<nckx>raghavgururajan: No, although I was in the LibreMiami channel (room? whatev) a while back. I can log in.
<Noclip>nckx: Source code is normally written in plain text format, right? So shouldn't filtering for anything that is not plain text work?
<vagrantc>nckx: well, debian is not at all bootstrappable ... so i'm not sure what you mean
<Noclip>nckx: But what if the AI is not bootstrapable? How do you know that it doesn't lie to you? 😂
<nckx>I thought Debian rejected packages that don't build entirely from source, I may well be wrong! It's even... quite likely!
<terpri>probably just used ccl's prebuilt binaries, actually
*raghavgururajan is about to get kicked in the butt by nckx
<nckx>My point was it's theoretically possible there's a distro out there that isn't as fundamentalist about Guix when it comes to bootstrapping the core (‘our bootstrap is Alice compiles everything with this GCC she found on the street’), but does actually build every last thing in its repo from source. Guix doesn't.
<Noclip>nckx: As far as I know debian has a giant bootstrap seed for the main system and has also all of those packages in their repo that are known to be unbootstrapable.
<nckx>raghavgururajan: Well luckily for you I never use Matrix/Element and find Web UIs total garbage, so I'm still in the ‘figuring out who is actually saying what in this unholy quotemess’ phase.
<terpri>maybe they chose a dreadful new name for riot just to encourage competition among other matrix clients ;)
<raghavgururajan>I think Matrix should never have been deployed for messaaging, but for content-publishing.
*raghavgururajan has to stop commenting more about it as it would become off-topic here
<Noclip>terpri: I think matrix doesn't really support jitsi. Element supports jitsi but Element is just one of many matrix clients.
*nckx .oO There's a topic? Oh, right, there it is.
<Noclip>But Jitsi is so easy to use that it doesn't make a big difference wether you use it inside Element or in your browser ....
*raghavgururajan screams "Hail XMPP!" for one last time
<terpri>i guess i'll have to poke around in the source to see whether it's something element-specific or if it's just "use this webrtc server"
<terpri>kind of unfortunate if there are significant client-specific features
<Noclip>terpri: Matrix has support for one to one webrtc calls but that has nothing to do with Jitsi I think. There is no support for group voice/video conversations in Matrix and that's why Element has built in integration for Jitsi.
<terpri>once unknown_lamer updates bobot++ i'll make an fsbot-style bot for #guix, so we can ask it important questions like:
<terpri>",guix-related xmpp vs matrix" "It may not be that obvious for the layperson, but xmpp vs matrix is indeed guix-related, terpri."
<Noclip>nckx: "Reproducible builds of Debian as a whole is still not a reality, though individual reproducible builds of packages are possible and being done. So while we are making very good progress, it is a stretch to say that Debian is reproducible."
<civodul>my understanding is that it's considered Very Bad Practice nowadays to upload your own binaries
<Noclip>nckx: Wait, you have the i7 version of the X230T?
<lfam>For example, I see a package update is available from `apt-get`, and I go to the web infrastructure to check it out. But the web infrastructure doesn't show this new version that I am downloading a binary of
<vagrantc>nckx: reproducibility in debian is essentially taking a package, and installing all the packages listed in the .buildinfo file which describes the build environment, and building from source
<vagrantc>lfam: do you mean VCS repositories? in debian, those are just treated as "nice to have" and the real source is shipped as tarballs in the archive.
<vagrantc>largely to maintain a strict GPL compliance
<lfam>Yes, that's kind of what I meant vagrantc. I see that there are lots of different approaches for how packages are managed, and it's up to each maintainer
<jonsger>what the hell, my laptop is building the same stuff as some days ago. Hundreds of drvs
<vagrantc>lfam: that's what i *love* about guix, coming from debian ... all the packages are all defined in a single git repository. refreshing!
<vagrantc>can't always grok the guile, but at least i know where to look for it :)
<lfam>It can be... frustrating... to inspect the source code. I mean, I trust Debian overall and use it primarily. It's a wonderful system. The decentralized style of creating the distro is interesting, but I do prefer working with Guix because it is centralized
<Noclip>jonsger: Did you run "guix gc" in the last days?
<lfam>It seems like it's basically a historical detail. Debian was started before massively scalable decentralized source code revision control existed. So, it grew up around this tooling, and the tooling created the community, and now they are intertwined.
<lfam>I am often brainstorming a FOSDEM talk about the relationship between tooling and community, and how they shape each other
<lfam>Somebody who likes giving presentations should do it :)
<Noclip>jonsger: Are the files really the same or could they be newer versions? (Does the hex-number differ)
<jonsger>Noclip: yeah the hex number differ but on master it shouldn't differ many hundreds packages in some days. Then something is wrong with master branch
<mbakke>jonsger: there was a new graft added recently
<lfam>In general, it is considered okay for many hundreds of packages to change over the course of days. The guideline is that no commit should trigger more than 300 rebuilds, but it's allowed to pushed 100 commits that each trigger 299 rebuilds
<lfam>That's an extreme example, but it gives the diea
<nckx>It sounds like there really is a problem, though.
<lfam>If you have the motivation, a bug report that shows the "what will be done" output of `guix system reconfigure --dry-run` would be useful
<nckx>Noclip: You can keep an eye on the git log to see if any updates mention [security fixes] or [fixes CVE-...], but not all upstreams mention this (for example Linux treats ‘security bugs’ no differently from others).
<lfam>Something I do that speeds things up a lot is to increase --max-jobs past the default. I use --max-jobs=10 when starting guix-daemon
<lfam>It doesn't help much when compiling, but it speeds up the downloading a substitutes massively
<lfam>The Linux scheduler could definitely improve the "compile 10 things at a time" use case, but it's not so bad
<abralek>jonsger: Compiling is indeed might take a lot of time, but I deployed guix in our production environment and now just offload the compilation. Awesome =)
<lfam>Noclip: Right, it's a bit different from other distros in the sense that "updates" to the source of the distro are made available to users immediately. On, for example, Debian, the update is not made available until the binary is built. So it seems to "take longer" but it's about the same amount of time.
<lfam>If you want to avoid building, you can try updating to "yesterday" rather than "right now", and things should be built and ready to download
<lfam>That's effectively what you get with old-school distros
<lfam>But, sometimes there are deeper problems with our build farm, and then it's actually worse than Debian :/
<nckx>I didn't know elogind was a wingothing. I assumed it was a Gentoo thing.
<nckx>Noclip: It's a chicken & egg problem, too. Nobody who doesn't love KDE is going to volunteer to package it (I think), and someone who loves KDE isn't going to install a system that won't run their favourite desktop properly for weeks while they add it (I think).
<str1ngs>I dunno, usually mother is the necessity of invention.
<str1ngs>this sounds like the beginning of a rap song.
<jonsger>I have some almost excact same systems: packages, services, packages in profile. I pulled them to the same commits and run reconfigure on a pretty similar system config. One system downloads some substitutes, the other wants to build derivations for those substitutes? How can this happen
<str1ngs>jonsger: check guix describe on both machines
<Noclip>nckx: Is it possible to use some of the "guix system" commands on a foreign distro?
<jonsger>str1ngs: it's the same as I said ("pullemd them to the same commits")
<nckx>Noclip: What strings said. About half of the subcommands work fine (build, vm, search, ...) on any system. ‘init’ will work too: it will turn your system into a (very messy) Guix System. Watch out 😉
<str1ngs>jonsger: btw guix describe was just a confirmation that you were using the pulled guix is all. which should work out of the box but good to confirm these things.
<nckx>By messy I mean there will be many left-over files from your previous distro, but it technically works (people have turned VPSes into Guix Systems this way).
<nckx>vagrantc: Not usually, but it's possible and no cause for alarm (yet).
<nckx>So despite the log file at https://ci.guix.gnu.org/build/3134778/details reporting success, there was no such store item on berlin. Building it manually there succeeded. I wonder if there's still some SSH bugginess in copying results from the build nodes...
<nckx>We reconfigured berlin. We didn't reconfigure the ~25 nodes. Could that be a problem?
<str1ngs>nckx: you mean building in one place the use --export and --import?
<bonz060>Hi, I upgraded thing in guix using `guix upgrade` and also earlier today I upgraded my arch linux. Now guix has stopped working: `/gnu/store/0w76khfspfy8qmcpjya41chj3bgfcy0k-guile-3.0.4/bin/guile: symbol lookup error: /usr/lib/libc.so.6: undefined symbol: _dl_fatal_printf, version GLIBC_PRIVATE`A
<vagrantc>str1ngs: did you just order a new replacement?
<str1ngs>but mostly on foreign disto's. on guix system locales are much smother.
<str1ngs>jonsger: I kinda run of idea's at this point.
<lfam>If you are seeing the locale warnings on Guix System, it usually means that there are multiple versions of glibc in use. For example, the system is using one version, and the user is using another
*vagrantc WTFs for a few moments until realizing that "guix system build" != "guix build"
<fnstudio>pipenv also doesn't seem to be in guix, anyone knows if there's a particular reason for that (eg i should be doing things differently, looking for another tool, etc) or just a matter of time / finding someone who'll package it?