IRC channel logs

2020-08-27.log

back to list of logs

<leoprikler>There is `guix import crate`, not sure how it handles semver
<NieDzejkob>#38408 still hasn't been merged, jsoo
<jsoo>I see. Someday soon!
<msavoritias[m]1><str1ngs "msavoritias: how do you figure g"> From the conversation above. Maybe I am mistaken though.
<msavoritias[m]1>Is go a systems programming language?
<str1ngs>msavoritias[m]1: yes, thought that's kinda a subject term.
<NieDzejkob>I wouldn't call go a systems programming language, but to each their own, I guess
***sneek_ is now known as sneek
<str1ngs>I know right, what would Ken Thompson know about system programming. :P
<NieDzejkob>just because you wrote a systems language doesn't mean you can't write an applications language
<str1ngs>well he designed Go and UNIX. and they clearly state Go is systems programming language. hard to kinda say otherwise after that.
<str1ngs>I was being a little sarcastic there too apologies. :)
<Noclip>Is there a list of all bootstrap binary files in the guix repository which are not part of the main bootstrap seed for guix?
<guixy>hello guix
<guixy>I might be misunderstanding the purpose of --with-source
<pkill9>it builds a package with the given source
<guixy>The pattern --with-source=package=source should replace the source of 'package' as long as one of the packages it's building is dependent on 'package' correct?
<guixy>I'm having trouble with that.
<samplet>Noclip: I don’t think there is. Would you like to bring it up on guix-devel? I’m sure the resulting discussion would be interesting.
<guixy>So for example "guix build --with-source=python2=/path/to/local/python2/source lci should build the 'lci' package with the python2 package built from /path/to/local/python2/source correct?
<guixy>But "guix build --with-source=python2=$(guix build --source=python2) lci" doesn't work. And guix says lci depends on python2.
<Noclip>guixy: I think that's correct.
<Noclip>(The first message)
<guixy>guix build --with-source=python2=$(guix build --with-source=python2) lci
<guixy>guix build: warning: transformation 'with-source' had no effect on lci@0.11.2
<guixy>Am I doing something incorrect?
<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>Okay.
<str1ngs>botsnack
<str1ngs>o.O
<lfam>sneek: botsnack
<sneek>:)
<str1ngs>thank you lfam :)
<lfam>Sneek is too well-behaved to eat just any food it finds
<sneek>So noted.
<lfam>sneek: forget it
<sneek>Okay.
<str1ngs>a robot and a gentleman!
<Noclip>@samplet What's guix-devel?
<samplet>Noclip: The development mailing list: <https://lists.gnu.org/mailman/listinfo/guix-devel>.
<xelxebar>Could someone do me a favor and try out a guix system vm --expose=/some/path? The guest /some/path is only picking up file creation and deletion from my host but not file modification.
<xelxebar>I have to remount the 9p filesystem to see the reflected changes.
<lfam>xelxebar: If you are observing that, it's probably going to be the same for all of us :)
<samplet>Noclip: If you write to <guix-devel@gnu.org> and ask your questions, I think there would be a valuable discussion.
<samplet>*question
<str1ngs>xelxebar: can you mount 9p after somehow. my guess is --expose uses a bind mount.
<xelxebar>lfam: Yeah. I just want a sanity check.
<lfam>Okay, I'm trying it
<lfam>Could not resist
<xelxebar>str1ngs: --expose uses the 9p virtio driver
<lfam>I didn't realize that `guix system vm` supported --expose and --share
<str1ngs>xelxebar: ah interesting. seems you have a better grasp then.
<xelxebar>Only because I am trying to resolve this issue, really. --expose essentially just adds the appropriate -virtfs flag to qemu along with the corresponding entry in /etc/fstab
<xelxebar>And -virtfs is just a convenience shortcut for adding a -device virtio-9p-pci and associated -fsdev
<xelxebar>lfam: Cheers, mate
<lfam>Yes, I can reproduce it xelxebar. And, when accessing the changed file after remounting, I get these kernel messages: https://imgur.com/a/T3OSPeN
<lfam>Each time I change the file and remount, it prints a similar message. But if the file is unchanged, it doesn't
<lfam>Now I'm trying it with `guix system container`
<xelxebar>lfam: Thanks. I don't see the same in my dmesg, but I'm also running an old kernel in the guest.
<lfam>I'm running different versions of 5.8 for the host and guest
<lfam>I don't know how to use `guix system container` :(
<lfam>Have to be root!
<lfam>It works in the container
<lfam>Can you report the bug xelxebar?
<xelxebar>lfam: Sure. Will do.
<lfam>Thanks. Please attach that image to the message so it doesn't disapperar
<guixy>So... why doesn't --with-source work for me?
<xelxebar>lfam: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=43062
<lfam>xelxebar: I'm curious, do changes to the file from the guest get updated on the host?
<xelxebar>lfam: If you remount without ro, the filesystem becomes rw, and you can test that out. When I tried it was almost the same in reverse.
<xelxebar>The only difference being that a remount clobbered the guest changes for me.
<lfam>I mean, before remounting, if you change the file in the guest, are those changes observed from the host?
<xelxebar>Not when I tried.
<xelxebar>You do have to initially remount the drive as rw, though, since it is initially readonly.
<guixy>When I specify --with-source=package=source I get a warning that the option will have no effect on the build product, unless 'package' is the build product. Am I doing it wrong?
<xelxebar>guixy: What are you confused about?
<xelxebar>guix build can handle more than one package at a time, so --with-source needs a way to match up the 'source' part with the 'package' it goes with.
<xelxebar>If you are trying to replace the source of a *dependency*, then you probably want --with-input instead.
<guixy>xelxebar, I thought --with-input swapped packages...
<guixy>If I want to have a local input for python2 when I build lci what should I use? Assume the source's root is /tmp/python2
<xelxebar>guixy: Oh wait. You're right. --with-input just specifies a package. Have you tried --with-input in combination with --with-source?
<xelxebar>By specifying a different version or something?
<guixy>I have a modified python2 source in /tmp/python2. I want to build the package "lci" to use python2 from that source. What command should I use?
<guixy>'guix build --with-source=python2=/tmp/python2 lci' doesn't work
<guixy>But I expect it to work.
<xelxebar>I don't know the answer, but have you tried something like 'guix build --with-source=python2@999=/tmp/python2 --with-input=python2@999 lci'?
<guixy>guix build: error: invalid replacement specification: "python2@999"
<guixy>That seems connected to --with-input
<guixy>If the source doesn't actually exist I would expect
<guixy>guix build: error: lstat: No such file or directory: "/tmp/python2"
<guixy>But I was only able to get that with `guix build --with-source=lci=/tmp/python2 lci`
<guixy>Does it fail on your end? Should I file a bug report?
<apteryx>how can I tell git send-email "send the previous commit only" ?
<apteryx>the range HEAD^^..HEAD^ works, but there must be something more to the point?
<lfam>apteryx: I know that `git format-patch` and `git send-email` share many options, so maybe the -1 argument of `git format-patch` will work
<apteryx>hm, -1 is the last commit, and -2 is treated as a range -2..
<apteryx>the same as specifying just HEAD^^ would be treated as HEAD^^..
<apteryx>well, '-2..' is not valid, but that's what it does (can test with the -n option for dry run).
<lfam>Ah, I didn't realize you meant the penultimate commit
<apteryx>yeah, seems useful to be able to rely to one given commit as the first commit to send to debbugs
<apteryx>not really actually as it will mess the patch counter... hmm
<apteryx>so is the only way to send series to format first using git format-patch then to git send-email those files?
<apteryx>ah, there's start-number
<guixy>After some hacking, I have concluded that --with-source does not apply any sort of filter to a package's inputs. I'm hoping I missed something.
*kmicu is happy to see that Guix Security Team patched out‑of‑bound/interger underflow C kreffufles in libx11.
<civodul>Hello Guix!
<xelxebar_>Hey civodul :)
<xelxebar_>How does one go about setting /etc/sysctrl.conf variables in an operating-system configuration?
<guix-vits>sneek: ?
<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 👍
<zimoun>hi Guix
<guix-vits>Hello
<xelxebar>Ah, sysctl-service-type. Of course!
<PurpleSym>Is there a trick to running a `guix system container`? It is starting, but all the services inside fail, because /sys/fs/cgroup/* cannot be mounted.
<civodul>grr more ssh issues: https://berlin.guixsd.org/eval/16065/log/raw
<civodul>apteryx: how well does it work for you?
<civodul>well this one is "guix offload: error: corrupt input while restoring ..."
<civodul>so it could be something else, but that sounds quite unlikely
<guix-vits>sneek: later tell nckx: CONFIG_CGROUP_FREEZER=y isnt set in linux-libre-arm64-generic kernel. I think that why i cant use elogind. Didn't tested yet, need to make a custom kernel.
<sneek>Got it.
*guix-vits fbset it man's best friend.
***trav88852 is now known as travankor
***guix-vits is now known as das-gluck
<efraim>civodul: actually that might be ssh related with the corrupt input
<efraim>I just recently had an error like that with a guix-daemon built with libgit2 built without libssh2 support (I think that was the chain)
<rekado>tb
<rekado>oops
<bdju>is something like jitsi usable on guix these days? I recall something about icecat not being built with webrtc support
<das-gluck>bdju: Jitsy is currently usable with qutebrowser, at least.
<bdju>ah interesting, that would be preferable to chromium at least
***das-gluck is now known as guix-vits
<bdju>I haven't used qutebrowser in a while
<guix-vits>* nomad currently not supporting webrtc, as tests show. Anyway, i use it dayly.
<brendarn>chromium is failing to build for me at the moment anyway
<guix-vits>bdju: qutebrowser uses qt-webengine, and written in Python. Works there for Jitsy.
<zzappie>hello guix!
<zzappie>Has anyone tried mingw in guix? I can't seem to get why there are only libs and headers but no compiler and other tools in the package?
<civodul>hi zzappie!
<civodul>zzappie: with guix you would cross-compile to MinGW
<civodul>as in: guix build --target=i686-w64-mingw32 hello
<civodul>dongcarl & janneke worked on cross-compilation support
<brendarn>I hope the semver importer for rust crates can get into guix master!
<leoprikler>regarding webrtc: it seems you need gst-plugins-bad in webkit for that
<janneke>o/
<leoprikler>[and also configure gst-plugins-bad so that webrtc is built]
<guix-vits>leoprikler: Thanks, forwarded to #nomad-browser.
<nckx>guix-vits: But this was aarch64! With the default Guix kernel! 🤔
<sneek>Welcome back nckx, you have 1 message!
<sneek>nckx, guix-vits says: CONFIG_CGROUP_FREEZER=y isnt set in linux-libre-arm64-generic kernel. I think that why i cant use elogind. Didn't tested yet, need to make a custom kernel.
<nckx>
<nckx>Good morning Guix.
<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’.
<zzappie>civodul: aha thanks for the cue!
<nckx>guix-vits: Do you use the default aarch64 kernel?
<guix-vits>nckx: Hello. linux-libre-arm64-generic?
<nckx>I'm confused because ‘grep CGROUP_FREEZER ~/guix/gnu/packages/aux-files/linux-libre/*arm64’ reports =y here.
<nckx>Also in 5.4-arm64.conf.
<guix-vits>Mine said "not set" (/run/booted-system/kernel/.config), linux-libre-arm64-generic
<nckx>I'll reconfigure the machine again and see what /run/booted-system actually says.
<nckx>guix-vits: Line 71, with default arm64 kernel (5.8): https://paste.debian.net/1161442/ Now building generic-5.4...
<guix-vits>nckx: Can You share what exact name and version of Your kernel?
<nckx>Exact enough, or do you want hashes? https://paste.debian.net/plain/1161443 (different host, same system.scm).
<guix-vits>nckx: .. and package name is?
<nckx>‘Whatever Guix uses without a kernel field.’
*guix-vits info guix
<guix-vits>‘kernel’ (default: ‘linux-libre’)
<nckx>/gnu/store/apzz77g7wysspfq3wa9wfmzdcspj89x1-linux-libre-5.8.3, so the name field is simply ‘linux-libre’.
<guix-vits>i use linux-libre-arm64-generic, as seen on mailing list.
<guix-vits>Probably that is my trouble.
<guix-vits>* at least now i know that 5.8.3 should compile on aarch64 ^^
<guix-vits>nckx: Thanks. I'll continue, my "adventures", then.
<nckx>My knowledge of aarch64 Guix is extremely limited. But why in hell's bells is ‘linux-libre-arm64-generic’ a different package than ‘the default arm64 kernel’. 😛
<guix-vits>
<guix-vits>Though isn't good that all linux-libre-xyz packages has same "description:" field. How one can realize where is the catch (from description)?
<nckx>I'm reconfiguring with 5.8-generic.
<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).
<nckx>As long as you don't GC you can roll back.
<guix-vits>nckx: and as my keyboard aren't being recognised by u-boot :) GRND, RX, TX -- to choose previous generation.
<guix-vits>nckx: Was!? Kernel can be gc'ed?
<guix-vits>`guix duct-tape kernel` he-he.
<nckx>guix-vits: Depending on which arguments you pass to ‘guix gc’ it can, but not by default.
<nckx>OK, try (kernel linux-libre-5.4) first just to be safe(r).
<guix-vits>:D
<str1ngs>leoprikler: thanks for the WebRTC info. I'll see about building gst-plugin-bad with webrtc support.
<str1ngs>though crosses fingers it maintains freedom still
<kmicu>Folks work on mutliple shells around handful of engines which break APIs from time to time https://nyxt.atlas.engineer/article/release-1.3.3.org but at least Guix packages them xD
<guix-vits>mmmmmmmmmmmmmmmmmmmm
<str1ngs>guix-vits: /gnu/store/3b7f8pj1z7m3lp8yglgp1m55l0hgp55y-gst-plugins-bad-1.16.2/lib/libgstwebrtc-1.0.so so should be available already
<str1ngs>guix-vits: btw these run time dependencies will eventually be managed by Nomad using guix. Actually eventually you'll be able to guix profiles graphically with Nomad.
<str1ngs>to manage guix profiles*
<guix-vits>str1ngs: i just ran qutebrowser with webkit backend, and neither html5 tests, nor Jitsy worked.
<guix-vits>So, probably some configuration still required?
<guix-vits>Nomad shows the html5 page (failing webrtc tests), and in Jitsy at least the chat working.
<guix-vits>Interesting, how it's handled by Epiphany?
***terpri__ is now known as terrpi
<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
<guix-vits>Epiphany, webrtc..
<peanutbutterandc>Hello
<str1ngs>guix-vits: did you try https://html5test.com/ with ephiphany?
<str1ngs>peanutbutterandc: hello o/
<str1ngs>err epiphany even*
<guix-vits>I'll; hello
<peanutbutterandc>str1ngs, guix-vits Hi there
<str1ngs>guix-vits: webrtc should be under the peer to peer section.
<guix-vits>TY
<guix-vits>(that just a drv and mime being built)
***jonsger1 is now known as jonsger
*guix-vits the_dangerous_symphony.ogg :)
<str1ngs>gotta love guix, when you want to use something but only once. guix environment --ad-hoc epiphany -- epiphany
<peanutbutterandc>str1ngs, I've been doing that a lot too
<str1ngs>nice
<guix-vits>str1ngs: 0/45
<str1ngs>guix-vits: lol
<civodul>:-)
<civodul>nckx: do you know if the ath9k issue is fixed with the latest kernel?
<str1ngs>guix-vits: I think maybe gst needs to be configured for webrtc. as far as I can see it should work. also I'll have to check webkit as well.
<str1ngs>guix-vits: though being plugins GST should work if propagated. Which Nomad already does though it's not ideal.
<str1ngs>guix-vits: I assume youtube works?
<guix-vits>str1ngs: Yes.
<str1ngs>guix-vits: thanks for checking. okay I'll put this on my TODO
<hendursaga>I'm trying to package dangen and I have a slight problem - it's dual-licensed, GPL2 but also Artistic License 2.0beta5, which isn't identical to Artistic License 2.0. What do I do?
<apteryx>civodul: it seems to work well, but I've seen this issue perhaps once before (I don't recall if it was before the upgrade of guile-ssh 0.13.0 or after.
<civodul>apteryx: ok, weird
<civodul>i thought (hoped?) these were problems of a distant past
<apteryx>I'll let you know if I get it. Do you have an idea of what is causing it?
<civodul>not really, it could be a gc issue in guile-ssh, but it could be anything
<apteryx>Would you know if this was occurring with guile-ssh 0.12 ?
<bdju>my battery says it's at 105% and charging... what do I do?!
<qyliss>Nothing
<apteryx>take cover
<bdju>:(
<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
<bdju>not sure of the acpi command
<apteryx>it probably just reads that file
***caleb_ is now known as KE0VVT
<mbakke>bdju: compare /sys/class/power_supply/BAT0/energy_full_design vs /sys/class/power_supply/BAT0/energy_now
<sneek>mbakke, you have 1 message!
<sneek>mbakke, nckx says: https://github.com/guix-mirror/guix is out of date.
<mbakke>for new batteries, it's not uncommon that the capacity exceeds the hard-coded design capacity
<civodul>howdy mbakke! :-)
<mbakke>howdy :-)
<guix-vits>nckx: I just set 'the CONFIG_CGROUP_FREEZER=y' in arm64-generic kconfig, and now elogind works. Can someone push the changes to generic config?
<nckx>guix-vits: Let's see what vagrantc says first. Why are you using -generic instead of the default?
<guix-vits>nckx: because i used an config.scm, seen on mailing list as a template, and i don't know what i'm doing.
<nckx>That's fair.
<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.
<noon>Hello there
<nckx>civodul: In *our* kernel? I'm not sure (I don't use it...) I'll check the source before guessing.
<nckx>Hello noon.
<terpri>hendursaga, there are some "generic" licenses in license.scm. checking artistic 2.0 status
<civodul>nckx: ah, i think i read about an ath9k issue before going on vacation and indeed had to use an older generation to get wifi to work
<civodul>damnit http://logs.guix.gnu.org/guix/guix/search?query=ath9k is broken
<nckx>civodul: It does not look like it ☹ linux-libre@5.8.3 still has <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2bbcaaee1fcb>, which caused a regression.
<civodul>hmm why /guix/guix/
<civodul>nckx: oh
<civodul>but maybe it has a followup fix?
<nckx>Yeah who knows.
<civodul>hmm
*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 licensing@gnu.org 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
<nckx>civodul: We do have the fix: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/net/wireless/ath/ath9k/hif_usb.c?id=92f53e2fda8bb9a559ad61d57bfb397ce67ed0ab
<nckx>wewt.
<jackhill>terpri, hendursaga: I don't know about the beta5 part, but otherwise it looks like Artistic 2 is a Free Software license: https://www.gnu.org/licenses/license-list.html#ArtisticLicense2
<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)
<terpri> https://spdx.github.io/spdx-spec/appendix-IV-SPDX-license-expressions/
<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...)
<jackhill>using spdx is an intriguing idea :)
<terpri>alright, another item (proposing adoption) for the TODO list :)
<nckx>A tiny Guix licence DSL (that evaluates to SXML or SRDF or whatever) would do.
<guix-vits>nckx: Yes, i'll try the default now.
<nckx>Why the everloving dickens does nano disable suspension by default.
<guix-vits>nckx: Security. Do not throw away work on half the road.
<nckx>Was that about nano? I can't parse it.
<guix-vits>nckx: Yes, about nano. Sorry.
<guix-vits>*i am sorry.
<nckx>What's insecure about it?
<guix-vits>One can forget to done the suspended work! Not secure feature, that suspension is!
<nckx>It's like a GUI programme forcing itself full-screen and disabling all window management.
*nckx installs zile to fix mailutils to fix emacs on aarch64.
<guix-vits>nckx: emacs-minimal works for me, (guix d73cfd8).
<guix-vits>Is graphical version broken?
*guix-vits silenced
<apteryx>civodul: I have two flavors of ath9k, and don't know what is the issue about (I've not experience it on any kernel version).
<apteryx>Guix's linux-libre kernels, that is.
<nckx>guix-vits: On aarch64? Does ‘guix show mailutils’ show version 3.10? It fails the test suite on both aarch64 machines here and is a dependency of emacs-no-x.
<nckx>Weird, d73cfd8 includes the mailutils bump.
<guix-vits>nckx: ..
<guix-vits>nckx: Yes, 3.10
<nckx>So ‘guix build mailutils’ works for you too.
<guix-vits>IDK, but emacs-minimal working: i editing the config.scm in it.
<guix-vits>..
<guix-vits>Let's see
<nckx>Oh, emacs-minimal doesn't depend on mailutils.
<nckx>emacs-no-x does.
<nckx>And of course emacs does.
<guix-vits>Ah.
<nckx>Segmentation fault readmsg --no-site --no-user readmsg -h SOMETHING
<nckx>Oh.
*nckx .oO Why does mailutils segfault so much?
<nckx>3.9 → 3.10 was to fix a segfault on x86_64.
<swedebugia>hi. has anyone tried compiling palemoon on guix? any other browser with vim-like keys and javascript that work?
<str1ngs>hello is it possible using substitute-keyword-arguments to add some some flags to #:configure-flags I need to inherit webkitgtk and add a couple of flags.
<str1ngs>nckx: IIRC mailutis is not a hard requirement for Emacs. but don't quote me on that.
<nckx>str1ngs: (substitute-keyword-arguments (package-arguments foo) ((#:configure-flags original-configure-flags `(cons* "--enable-clippy" ,original-configure-flags)))
<str1ngs>nckx: it might be good to verify if that is even required
<nckx>str1ngs: It was added with a purpose.
<nckx>I vaguely remember that. Maybe even an important one. Searching mailbox...
<nckx>Yeah, pretty important: https://issues.guix.gnu.org/35512
<nckx>str1ngs: ☝
<str1ngs>nckx: I would assume that too. but some times soft requirements are added and never relay verified again.
<str1ngs>nckx: I'd agree it's worth having mailutils though who uses pop3 anyways! :P
<nckx>We could remove it if someone investigates and determines it's no longer a risk. Won't be me though.
<nckx>str1ngs: Hey I used it briefly in 2011!
<str1ngs>naw I'd say keep it. since it would not be obvious to the user they were using insecure mechanism
<nckx>I had a phone then. It could read e-mail. Kind of.
<str1ngs>nckx: thanks for the substitute-keyword-arguments will save me a bunch of copypasta
<nckx>YW. No need for cons-asterisk here of course.
<str1ngs>well if this works I should have webrtc support in nomad \o/. though it will be a experimental declaration only
<nckx>Nice.
<str1ngs>so people can zoom with the with scheme nirvana :)
<apteryx>I'll hope they'll choose the free Jitsi or BigBlueButton over proprietary zoom, with or without Scheme!
<str1ngs>apteryx: I hear ya, I was just being facetious. Nomad tries to endorse and be free, though much work needs to be done in those regards
<civodul>apteryx: oh, maybe there's no issue after all? :-)
<civodul>i'll give it another try
<apteryx>what's the bug # ?
<civodul>000
<civodul>:-)
<civodul>it's just something i saw mentioned here, and then i think i experienced it
<civodul>but i didn't really investigate, i just rebooted into an older generation
<civodul>so it could be what i experienced was something else
<civodul>i'll check
<apteryx>what does the problem look like?
<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.
<apteryx>using an Atheros 9280-based one on my desktop I don't have this issue (c.f. https://www.thinkpenguin.com/gnu-linux/penguin-wireless-n-dual-band-pcie-card-gnu-linux-tpe-n300pcied3-full-profile)
<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 crosses fingers
<nckx>Kimapr[m]: I don't think so, no.
<nckx>You could map the damaged store item to a .drv manually and ‘guix build that.drv’.
<nckx>str1ngs: Strange, that snippet should've worked. What did you need to change?
<str1ngs>nckx: (#:configure-flags original-configure-flags) was not enclose. unless copied wrong. no bigg
<str1ngs>no biggy
<nckx>Oh, missing ).
<nckx>Yeah.
<nckx>I scroll up & see it.
<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
<str1ngs>I assume git-fetch uses --depth=1 ?
<terpri>there is also guix build --repair, for fixing individual store items (vs. guix gc --verify=...)
<pancak3>nckx: Thanks! I think I'm good now
<str1ngs>leoprikler: btw regards to webrtc and webkitgtk it requires a experimental git branch https://github.com/philn/webkit/tree/gstwebrtc-2020 and gstreamer >= 1.27.
<str1ngs>err 1.17
<pancak3>so I fixed my problem manually before doing the gc verify, but the gc verify might have fixed it for me... That's a cool command to know
<raghavgururajan>Hello Guix!
<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?
<guix-vit`>Hello raghavgururajan.
<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?
<nly>hi
<str1ngs>hello o/ nly
***guix-vit` is now known as guix-vits
<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:
<pancak3> ((#:phases phases)
<pancak3>guix edit emacs-next for more info
<pancak3>oh, and then they refer to phases instead of %standard-phases
<nckx>((#:phases phases) `(modify-phases phases (delete 'move-docs)))
<nckx>Shit: ((#:phases phases) `(modify-phases ,phases (delete 'move-docs)))
<pancak3>language
<nckx>Poop.
<pancak3>;)
<nckx>‘phases’ here can be whatever you want (I used original-configure-flags above), you just binding to it.
<str1ngs>ha! thanks to pancak3 I discovered ,phase too
<nckx>pancak3: Uh, I didn't follow up on the emacs-debbugs discussion TBH. Someone confirmed ‘emacs’ was hard-coded? Maybe that someone was you?
*nckx doesn't *use* emacs-debbugs is the problem.
<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?
*vagrantc would be curious about that too
<nckx>By ‘bootstrap binaries’, do you mean packages like ccl that aren't built from pure source?
<guix-vits>str1ngs: do You sure You delete move-docs, not move-doc or smth?
<nckx>Otherwise I don't understand the question.
<nckx>(Read the ccl comments to see what I mean by that.)
*nckx won't be available much for the rest of the evening.
<nckx>vagrantc: Could you say (not do) something?
<vagrantc>nckx: hrm?
<sneek>vagrantc, you have 1 message!
<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.
<nckx>Thanks.
<nckx>Silly sneek.
<vagrantc>:)
<vagrantc>nckx: oh, i've been running elogind with linux-libre-arm64-generic ... linux-libre-arm-generic i haven't figured out the extra configs needed
<nckx>Oh, weird, guix-vits had serious problems on aarch64.
*nckx AFK now.
<vagrantc>there are some extra configs i had to enable ...
<vagrantc>added some things to %default-extra-linux-options
<pancak3>so debbugs is now indeed setup to use usertags. If you look at all the usertags for the guix user, you'll find I managed to set a plz-work tag on a thing.
<guix-vits>vagrantc: just freezer-fs didn't worked, and that broke boot.
<guix-vits>CONFIGURE_CGROUPS_FREEZER isn't set on -generic (aarch64)
<str1ngs>guix-vits: I think I'm deleting, but apparently not
<vagrantc>guix-vits: maybe i'm not using elogind in that configuration ...
<vagrantc>guix-vits: try adding to %default-extra-linux-options ?
<guix-vits>vagrantc: adding what?
<vagrantc>guix-vits: the kernel options you think are needed?
<guix-vits>CONFIGURE_CGROUPS_FREEZER=y
<guix-vits>I compiled with this option, and that maked elogind work
<guix-vits>I even started sway on that SBC, so it's really work.
<vagrantc>i suspect that should be enabled on all kernels, and thus should be added to gnu/packages/linux.scm: %default-extra-linux-options
<guix-vits>vagrantc: IDK, but will be great. Just that was the only logind-related option that didn't present.. and logind is "popular".
<vagrantc>guix-vits: agreed. email bug-guix about it :)
<vagrantc>guix-vits: feel free to cc: vagrant@debian.org
<vagrantc>it's present in all the gnu/packages/aux-files/linux-libre/*.conf ... so seems worth making a globally applied option
<guix-vits>vagrantc: OK, writing mail.
<jsoo>Does anyone know if the webassembly target is supported in llvm? I need to use rust's wasm target for work
<jsoo>Well, need is a strong word
<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.)
<guix-vits>Noclip: Try ask janneke, as that was He who wrote the blog-post https://guix.gnu.org/en/blog/2020/guix-further-reduces-bootstrap-seed-to-25/.
<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>A list would be great.
<nckx>It's not fun to proclaim ‘these are all the places where Guix still cheats!’ but we need to be honest.
<nckx>I don't know an easy way to automate it though. While packagers do their best to find them, in theory, any package could have generated code or worse hiding somewhere in its source tarball.
<Noclip>nckx: If you are the world's leader in bootstrapping it's okay to say that you're not perfect. 😂
<terpri> https://news.ycombinator.com/item?id=24260337 C-f guix -> nothing, C-f nix -> nothing
<raghavgururajan>nckx: Are you connected to Matrix?
<leoprikler>does guile not have generated code in its repo too?
<raghavgururajan>I have mentioned you in LibreMiami
<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
<nckx>ohrightitselementnowwhatasillygenericname.io
<nckx>vagrantc: Would they accept a free package that builds itself from a blob of its previous self?
<vagrantc>nckx: most of them
<raghavgururajan>nckx: Cool! When you see it. Sushh!!!
<nckx>Noclip: Tarballs contain tonnes (and by volume, probably more) of non-text files, and generated code is text, so I doubt it but would be happy to be proved wrong by a cool heuristic I mean AI.
<terpri>nckx, i'm 99% sure i've used openmcl/ccl in debian, but it might have been an unofficial package or built from source or something
<nckx>I just searched https://packages.debian.org/search?keywords=ccl , I didn't do any diligence at all.
<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.
<raghavgururajan>nckx: LoL!
*raghavgururajan connects to Matrix via XMPP, and doesn't have to deal with Riot shit.
<nckx>So you're pinging me in #guix to tell me to read a message elsewhere telling me not to mention... something in #guix.
<nckx>My brain hurts.
<Noclip>*Element
<raghavgururajan>nckx: That's 1 of 2.
<terpri>everyone has to deal with elements https://www.youtube.com/watch?v=AcS3NOQnsQM
<Noclip>raghavgururajan: But you know that Element isn't the only Matrix client, right?
<nckx>raghavgururajan: No butt-kicking initiated. That server is there to be used, with the caveat that it's a box in my house connected with copper wire.
<Noclip>There are also several shell based clients.
<raghavgururajan>Noclip: I know. I am not a fan of Matrix in general. I am a XMPP-head.
<raghavgururajan>nckx: Phew! I thought you didn't wanted more traffic.
<nckx>More traffic means other people getting the slower (uncached) first download instead of me.
<terpri>i wonder whether matrix's jitsi support works through an xmpp interface...given that jitsi itself is basically xmpp-based
<Noclip>raghavgururajan: Matrix vs. XMPP is most likely similar to Vim vs. Emacs ...
<raghavgururajan>+1 ^
<Noclip>(In other words: I'm sure you could get religious about it.)
<nckx>Oh, I thought you meant ‘there is an objectively correct answer’.
<raghavgururajan>I have my reasons with the design.
<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."
<terpri>Noclip, ah, good to know
<nckx>I like how on Matrix there are a light Guix channel and a dark Guix channel. Only they're the wrong way 'round.
*terpri has been digging into the details of free videochat systems lately for hcoop deployment, partly to get local political groups who should know better to stop using z**m
<leoprikler>The dark Guix channel deals non-free software under the table.
<nckx>The dark Guix channel is this one so I really hope not. Hey, you, stop.
<leoprikler>Wait... are we the baddies?
<nckx>😃
<nckx>So it seems https://guix.gnu.org was down this morning?
<Noclip>raghavgururajan: Isn't content-publishing the job of the Fediverse (activitypub)?
<nckx>Two people reported it in the fak^Wlight^Wnative Matrix channel but not here. This is why fragmentation is bad.
<raghavgururajan>Noclip: There are many protocols for pub-sub. The nature/architechure of Matrix makes me to think that it better suited for pub-sub instead of messaging.
<leoprikler>look at the positive side: you can get twice as much drama about RMS defaming ;)
<Noclip>leoprikler: In the world of free software unfree software are the drugs. 😂
<leoprikler>Yes, vendor, lock me in harder!
<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."
<Noclip> (https://wiki.debian.org/ReproducibleBuilds)
<civodul>so it takes more than 6h to build ungoogled-chromium, uh
<guix-vits>Thanks
<lfam>That sounds pretty good, civodul! ;)
<lfam>Only 6 hours
<msavoritias[m]1>It took more than 12 on mine before I stopped and installed qutebrowser
<msavoritias[m]1>I have an i5 cpu
<civodul>lfam: well, i just figured it times out at 80% in 6h
<jonsger>I had to remove ungoogled-chromium from my system config as it blocked every reconfigure...
<lfam>Oh :(
<nckx>Noclip: Does Debian's definition of reproducible explicitly imply ‘entirely from source’?
<civodul>jonsger: i would not add big packages like this to the system config anyway
*nckx ‘explicitly imply’ SMH.
<civodul>it's more flexible to have them in your profile IMO
<Noclip>civodul: I'm still waiting for a new prebuild version ...
<jonsger>civodul: I know, but that is annoying
<civodul>Noclip: yeah, it'll be there in maybe 10h now :-)
<jonsger>and kills quite some "nice ness" of guix :(
<lfam>I also use an i5. It's really a compromise CPU, between efficiency and power.
<lfam>nckx: Debian doesn't really have *any* correspondance between source and binary
<nckx>Your i5 might well be more powerful than my (hugs) i7. Isn't generation important? We've had 10 of them now.
<lfam>My understanding is that Debian package maintainers promise to explain how they built the binary
<civodul>jonsger: i'd say it's part of the niceness that user profiles and the system can be dealt with separately :-)
<civodul>but yeah, it depends on one's tastes!
<nckx>lfam: Oh...
<lfam>nckx: It's not like Guix where the process is integral to the distro
<civodul>lfam: it's changed a lot in recent years though, AIUI
<civodul>that is, maintainers now rarely upload binaries themselves
<jonsger>civodul: I have a desktop and a laptop and I want them to be as similar as possbile, but guix profile and other guix fog prevents that
<civodul>vagrantc can shed some light
<lfam>That's what I've heard civodul, but I still don't find up to date source code / build scripts via the Debian web infrastructure all the time
<lfam>Like, it's not a requirement
<lfam>They need a monorepo...
<civodul>heh
<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
<civodul>oh, not great
<lfam>Regarding the i5... yes! Generation is extremely important. I can't believe how much faster my x260 is compared to my old x230
<lfam>They both use i5
<nckx>Noclip: Yep. Better screen, too.
<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?
<jonsger>Noclip: I never run it
<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
<lfam>I wonder what changes are responsible...
<Noclip>*Oh it seems to be not a hex number.
<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
<lfam>idea
<jonsger>lfam: it's okay maybe but it is unusable on my laptop, waiting days after `guix pull` with reconfiguring doesn't helped the last weeks
<lfam>Yes, it's not great...
<lfam>If it is caused by some graft, the builds should not be too expensive except in terms of I/O
<nckx>Noclip: It's Nix-specific base 32.
<nckx>jonsger: CI had some trouble the past weeks, Cuirass would freeze up and no longer evaluate new commits. This has been fixed.
<lfam>That's great to hear
<nckx>Not by me!
*nckx throws credit at mothacehe.
<Noclip>jonsger: How long does it take you to do a reconfigure on avarage?
<nckx>AIUI this doesn't address the ‘CI is criminally underutilised’ meta-bug but it fixes the ‘nothing at all was being built at all’ bug.
<vagrantc>lfam: one of debian's ethics has largely been "let developers work however they want to" which is great for experimentation, but a more centralized approach is good for long-term consistancy
<jonsger>Noclip: if I don't need to build something it's a matter of minutes, if it's like atm on my laptop it takes 24h or more
<nckx>😳
<lfam>vagrantc: Makes sense, especially at the time that Debian began and matured
<lfam>The tooling was not very good in the 90s
<lfam>jonsger: What kind of laptop do you have?
<jonsger>x250, 2cores/4threads
<Noclip>How often should one update the system at least to make sure that it is secure?
<nckx>Hm, https://ci.guix.gnu.org/build/3134778/details - ‘Build failed’! Log: ‘build succeeded’.
<nckx>Noclip: There's not really an answer for that. Vulnerabilites are discovered and security updates can be pushed at any time.
<lfam>jonsger: Hm, we should definitely not be asking people with an x250 to spend 24 hours updating their system.
<nckx>‘As often as you can afford to.’
<lfam>That's a problem
<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>I also have a 2 core / 4 thread laptop
<nckx>I belvieve there is a wishlist bug open to treat downloads as separate from build jobs, so you can download 300 things at once on your Pentium 4.
<lfam>Yes, there is
<lfam>It's not that we want to download more than one thing at a time, but we want to use HTTP pipelining to avoid the setup / teardown costs of the Guile HTTP client
<lfam>Otherwise, you might spend 10 seconds downloading a 10 kb file
<nckx>The Linux kernel is already disproportionally optimised for compiling Linux kernels 😉
<nckx>lfam: That would help for substitutes which are all blasted from the same server, not for ‘real’ source downloads.
<nckx>(Perspective: I don't use many substitutes.)
<lfam>Right, I'm talking about downloading substitutes. The current method is extremely inefficient in terms of time
<Noclip>I'm thinking about using guix as main OS in the future but if updating core components sometimes takes several hours that might be a huge problem.
<nckx>Most Guix things currently are.
<lfam>Okay, but this one is egregious
<nckx>I mean: low-hanging fruit abounds.
<lfam>It should not take 10 minutes to download 5 megabytes of files when I have a 10 megabyte per second connection to a local substitute server
<lfam>--max-jobs=10 is a kludge but it helps a lot
<nckx>Put one in your house.
<nckx>😛
<lfam>I'm talking about the one in my house
<nckx>Well.
<lfam>Yeah :)
<lfam>The fruit will be picked eventually
<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>Worst tagline ever.
<lfam>Worse than Debian is still pretty good IMO!
<lfam>They do a good job of getting security updates out there fast
<Noclip>Is there a wish list for packages?
<nckx> https://libreplanet.org/wiki/Group:Guix/Wishlist
<lfam> https://libreplanet.org/wiki/Group:Guix/Wishlist
<nckx>But who actually checks that list and decides to package something because it's on there is entirely unknown.
<lfam>Yeah...
<nckx>Gnomes, I think.
<lfam> https://github.com/kpreid/shinysdr
<lfam> https://github.com/calebmadrigal/trackerjacker
<lfam>That's my wishlist
<nckx>I think a list of names would be better. Who want Jitsi? 3 people? Cool, I'll mail them to see if they've WIP.
<str1ngs>sometimes worst then debian, but still guix is lacking the cobb webs?
<nckx>Just posting ‘3 ppl wannit’ motivates no-one.
<str1ngs>maybe if 3.14 people wanted it. that would be better.
*nckx .oO is that the gnome
*nckx gets coat.
<str1ngs>it's PI! silly
<nckx>That's not Pi! Unless it's been mandated by some state. Or was that ‘3’...
<str1ngs>we could be here for every talking about PI.
<str1ngs>... get it? hahaah
<nckx>You write ‘PI’, all I can think of are moustaches.
*str1ngs should not drink caffeinated coffee anymore.
<vagrantc>both 3 and 4 have been legally defined as pi in different places and different times
<Noclip>Why is KDE not available in guix?
<str1ngs>vagrantc: 4 is imperial PI?
*str1ngs breaks out a yard stick
<lfam>Noclip: Nobody has made it available yet
<nckx>Many KDE packages are. And a full desktop: nobody stepped up.
<nckx>That's usually the answer.
<lfam>People have done a lot of work to package components of it, but the work is not completed
<nckx>Nobody is going to package KDE for fun.
<nckx>Not even for ‘fun’.
<vagrantc>not sure i'd even package KDE under duress
<fnstudio>hi i don't seem to be able to find virtualenvwrapper in guix, anyone knows if there's any popular alternative to it?
<Noclip>Is KDE extra hard to package or are there just no KDE users among guix users?
<str1ngs>you now, instead of deleting this 'move-docs phase in gstreamer-next it would probably be better to address why are the docs not being built instead.
<lfam>It's hard to implement fully-featured desktops like KDE and GNOME
*str1ngs regrets being lazy, pays the toll
<lfam>It was a major effort to integrate GNOME into Guix
<lfam> https://guix.gnu.org/en/blog/2016/gnome-in-guixsd/
<lfam>There was a talk with slides on the subject too
<str1ngs>that's from 2016 what about mah GTK 4!!!!
*str1ngs hides
<lfam>Help wanted :)
<Noclip>(I'm not really interested in KDE myself, I'm just wanted to know the reason. I mean it's even mentioned in the user manual as one of the limitations of guix ...)
*str1ngs tosses some patches around. to look busy.
<str1ngs>lfam: touche.. touche
<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.
<nckx>My mother runs Gnome on Guix System, sorry.
<nckx>Well no, her laptop does.
<nckx>That would be weird.
<str1ngs>hi mom!
<pkill9>step away from the Narcissus
<pkill9>and the Nostromo
<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")
<str1ngs>Noclip: yes, just not reconfigure
<str1ngs>jonsger: okay that's good. have you tried guix weather on the machine that does not subistute.
<vagrantc>how long does stuff generally take to land on bug-guix?
<vagrantc>more than two hours?
<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?
<nckx>Offloading.
<nckx>Berlin offloads to 25 of its beefy buddies in the same rack.
<Noclip>nckx: wtf, sounds like a virus eating up it's host 😂
<str1ngs>ahh offloading gotcha. sometimes I'd like to --export and --import but never works right for me. the failure is probably on my part.
<nckx>Noclip: Somebody suggested the subcommand ‘guix infect’.
<Noclip>😂
<nckx>I've run into bad (like you think: is anybody using this at all?) bugs with large exports (>40 GiB memory usage) but I don't have time...
<str1ngs>you can publish --import right? or maybe that's where I'am misunderstanding.
<nckx>I was already using that to work around a bug in offloading to test a bug in a package to...
<nckx>...do actual work.
<Noclip>nckx: That would be perfect for MS Windows: Guix cleans up the garbage ...
<nckx>A daring reason to port Guix to Windows.
<str1ngs>I have run guix on Windows. err but WSL2
<nckx>str1ngs: ‘guix publish --import’ isn't a thing & I'm not sure what it would be a typo of.
<nckx>‘guix archive --import’?
<nckx>(That reads stdin, so don't run it & wait 🙂)
<str1ngs>nckx: I mean like so. guix archive --export linux-libre@4.9 | ssh vps guix archive --import to the publish server that is.
<str1ngs>throw in -r for good measure :)
<nckx>Yeah, that should work but it has a memory leak or is just plain hungry.
<str1ngs>thats good to know, when I have more free time I'll play with it.
<nckx>I think that's functionally the same as ‘guix copy --to=vps’.
<str1ngs>oh I did'nt know bout guix copy
<nckx>You might also need to add --authorize to actually trust the import.
<nckx>I don't quite remember all the details. But keys need to be respected.
<str1ngs>I have trusts setup already
<str1ngs>in theory haha
<str1ngs>woot hint: Make sure `GUILE_LOAD_PATH' includes Guix' own module directory. thanks foreign distro!
<str1ngs>nckx: this looks easy to use. just need to fix LOAD_PATH's on foreign distro. thanks.
<nckx>Enjoy and/or good luck 🙂
<str1ngs>this help, will have to follow up at a later time.
<pkill9>lol, how to garbage-collect on windows using guix: `guix system init`
<nckx>On Windows, dd is faster.
<vagrantc>gah. pinebook pro seems really intent on suspending.
<Noclip>I thought the guix system commands would only work on guix systems so it's really nice to know that this is not the case!
<vagrantc>wonder if i let the battery get low again...
<str1ngs>pkill9: lol
<str1ngs>vagrantc: are you running guix on your pinebook pro?
<leoprikler>guix system init --nuke
<str1ngs>sometimes you can only fix something by purging it with the wrath of holy fire.
<jonsger>str1ngs: guix weather --manifest doesn't really help as it doesn't includes the packages coming from services in my config.sm
<str1ngs>jonsger: ah yes forget that does not work for guix system.
<str1ngs>jonsger: could also be network related? assuming you are using ci.guix.gnu.org?
<jonsger>str1ngs: I'm sitting in the same network
<str1ngs>well that might not meant there is'nt say a SSL issue. say if the date was wrong.
<str1ngs>guix system defaults to substitutes on right?
<jonsger>yes
<str1ngs>you could try invalidating the substitute cache. but it's rare you would need to do that.
<str1ngs>by removing /var/guix/substitute/cache/
<jonsger>^ doesnt help
<str1ngs>did you see updating subtitutes blah blah ci.guix.gnu.org? atleast?
<jonsger>yes
<jonsger>I think the problem is that something pollutes somewhere down the way and leads to different package/drv hashes. So there are no substitutes
<str1ngs>sounds likes its working. only thing I can thing is other computer has substitutes that are no longer on ci.guix.gnu.org
<str1ngs>jonsger: if it's not the exact config.scm potentially yes. dos guix build ~/config.scm -n give an idea what might need building?
<str1ngs>err system build*
<jonsger>str1ngs: it's the excact same config.scm apart from bootloader, hostname, uuid and mount-point
<vagrantc>str1ngs: yes, running guix system on the pinebook pro ... but it recently sometimes goes to suspend after getting to the login prompt (and can't come out of suspend)
<str1ngs>jonsger: how much is it trying to build?
<jonsger>str1ngs: 100s of derviations/package
<str1ngs>jonsger: yeah I agree that seems off.
<vagrantc>str1ngs: using the wip-pinebook-pro branch in guix (and occasionally merging in master)
<str1ngs>vagrantc: nice when I get my emmc usb writer I will try it out on my pinebook pro. right now I need to open mine up to much to fix issues. mainly with SPI and nvme
<vagrantc>str1ngs: i've been running off of microSD
<str1ngs>ouch, they have come down in price. well here they have I got a 64GB for 19.00 CAD couple of weeks ago.
<vagrantc>wanted to test the bug guix-vits reported
<str1ngs>with iwd?
<vagrantc>also need to get a fixed nvme adapter ... the one they shipped me was the earlier borked version
<vagrantc>str1ngs: still waiting for it to register on bug-guix ...
<str1ngs>vagrantc: yeah I got one of those too, wait for my replacement here.
<vagrantc> https://issues.guix.gnu.org/43078
<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?
<bonz060>Has anyone come across that? ^^
<vagrantc>str1ngs: or did they offer to give you a replacement?
<jonsger>str1ngs: okay it seems to be substitute/network related https://paste.opensuse.org/view/raw/3426988
<str1ngs>vagrantc: yeah, I ordered some other things and it's dirt cheap. buy other things I mean a pinephone and a rockpro64 lol
<vagrantc>bonz060: /usr/lib/libc ... that sounds very much not guix
<vagrantc>str1ngs: yeah, got guix running on the rockpro64 too
<str1ngs>vagrantc: nice
<lfam>bonz: How did yo uinstall Guix?
<lfam>I mean, how did you install Guix?
<str1ngs>vagrantc: they will give a replacement from my understanding. I just bought my replacement because it was faster
<lfam>bonz060: How did you install Guix?
<vagrantc>str1ngs: that's my understanding too ... just no idea how or when
<str1ngs>jonsger: does curl https://git.savannah.gnu.org/git/guix.git work?
<str1ngs>vagrantc: I would just email the pine store. do you have there email?
<jonsger>yeah
<str1ngs>though this stop partial soo probably not https related.
<str1ngs>jonsger: I have seen locale issues and substitutes. is it possible you can fix this uile: warning: failed to install locale
<lfam>bonz060: In general, Guix should never look for things in /usr. My guess is that something in your environment is setting LD_LIBRARY_PATH or a similar variable
<str1ngs>jonsger: also is it consistent failure at this point?
<jonsger>str1ngs: yes. it can reach ci.guix.gnu.org: wget https://ci.guix.gnu.org/nar/lzip/zsdwq22x0w1v0ki2g3rv8gbcdgdmfs58-guix-1.1.0-23.2f458ad-checkout works
<bonz060>vagrantc: I used: https://guix.gnu.org/manual/en/html_node/Binary-Installation.html
<str1ngs>jonsger: wonder if it's a substitute server issue.
<str1ngs>jonsger: so seems your other machine has cached substitutes but the newer computer does not.
<bonz060>lfam: You are right! I had something like that in my .zshrc(was a workaround for some Haskell stuff). Thanks!
<lfam>Great!
<jonsger>str1ngs: something like this
<str1ngs>yeah LD_LIBRARY_PATH on foreign distro is a no no.. don't ask me how i know!
<jonsger>str1ngs: I runned the example on the working system and it just downloaded the substitute from the CI. So it didn't had it before...
<str1ngs>jonsger: do you get the locale warning on your other machine?
<str1ngs>the working one.
<jonsger>not really but /run/current-system/locale from GUIX_LOCPATH links to the same store item on both machines
<str1ngs>yeah, I'm not sure if that is guix-daemon warning or a client warning.
<str1ngs>and still might not help your problem. I just know locale issues can effect substitutions like this.
<str1ngs>only reason I'm worried about it.
<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
<lfam>Otherwise, it should "just work"
<lfam>I don't know why that would cause the other issues that you saw, though
<lfam>In general, substitute availability is not deterministic, although I don't know why
<lfam>Just something that I've noticed
*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?
<str1ngs>vagrantc: I've done that and vise versa.
<lfam>fnstudio: There is a package for direnv. I don't know if that is relevant. Guix has its own environment management tool, `guix environment`