IRC channel logs

2021-07-03.log

back to list of logs

<jsgrant>Saw that LVM support landed; Been holding off for literal years -- excited to play with Guix(SD) more seriously on my 'experiments' box. :^)
<Noisytoot>Does Guix support LVM in the installer now?
<Noisytoot>I think it supported LVM, but the installer didn't
<jsgrant>No idea, 'shredding' and old thumbdrive and going to dd it by the end of the night -- doubt I'll have time to actually poke around in it between now and work tomorrow though
<jsgrant>You can still install it via a config file you supply it from the live enviroment, in a tty right?
<jsgrant>Because that's not a big deal; Or shouldn't be. Going to "have to" setup linux-nonfree anyways to get my wifi working.
<nckx>Yes, you can still trivially ‘guix system init’ using a configuration file you prepared earlier.
<Noisytoot>I can't use /etc/nftables.conf as my nftables configuration if my filesystem is mounted in /mnt
<Noisytoot>(when installing Guix System)
<nckx>Then symlink it or similar.
<jsgrant>Guessing the installer is still the blue-tui one from a few years back?
<Noisytoot>yes
<nckx>I keep my system.scm in /etc/guix, together with all external files (keys, smtpd/dovecot/nginx/….conf, …) partially so it's easy to symlink into place during installations like that.
<nckx>They used to be scattered all over; that was no fun.
<Noisytoot>I commented it out for now
<jsgrant>Are those TUI background colors configurable? Wonder why it's like "always" blue. lol
<nckx>You can configure it by inducing a fatal error!
<nckx>A nice eye-bleed red.
<jsgrant>Yeah, I've seen that one via the Debian 'expert install' a few times. loool
<nckx>jsgrant: It's configurable in that it was written from scratch (newt-set-color COLORSET-ROOT "white" "blue"), it's not based on an existing installer, but the author was obviously inspired.
*nckx wonders if KMScon supports more than the usual pseudo-16 colours allowing for a more Guixy theme.
<nckx>The default ANSI ‘orange’/brown is utter ralph.
<jsgrant>I know like NOTHING about TUI programs, but wonder how much is trying to just to stay 'as compatible as possible' between devices in a tty. Like intuitively I'd think "oh just make the framebuffer render everything" and shove like actual gui elements if-possible lool
<Noisytoot>guix system: bootloader successfully installed on '#f'
<nckx>\o/
<nckx>jsgrant: Some ‘text mode’ programmes in the 80s/90s used passed a custom font to the hardware with unused characters replaced with (parts) of GUI symbols like arrows, checkboxes & c. It was all monochrome but it could look quite convincing. Unfortunately, yes, hardly portable.
<nckx>s/used //
<nckx>Actually, the Hurd image does something similar! 4 (IIRC) ‘glyphs’ redefined to one quarter of the GNU logo.
<nckx>OK, bit more than 4: https://librecmchacker.files.wordpress.com/2020/05/screenshot-from-2020-05-30-18-40-02.png
<nckx>Maybe KMScon could do something like that, but then we might as well make the installer a Web app and run ‘links -g’ in the framebuffer.
<nckx>(I'm not sure if I'm serious.)
<mroh>nckx: thx for refactoring the neural network revision! That was fast ;)
<iskarian>another quick packaging question: is "lib/pkg", "lib/pkg-X.Y", or "lib/pkg/X.Y" preferred when the package is installed in /usr/lib/pkg or /usr/lib/pkg-X.Y on other distros?
<nckx>I'd follow the same pattern, since other software might rely on either. But I'd expect the package's own build system to handle this, e.g., with a Makefile or pkg-config or… Why is it your problem?
<nckx>mroh: You got lucky!
<iskarian>The build system doesn't handle installing except to dump everything in /usr/lib/pkg, ha
<iskarian>(this is go, which is currently cluttering my ~/.guix-profile with its non-FSD folders)
<iskarian>s/FSD/FHS/
<bricewge>nckx: Disabling the debug port didn't helped.
<iskarian>Arch dumps it in /usr/lib/go, debian dumps it in /usr/lib/go-X.Y
<iskarian>(with some fancy symlinks)
<char>What do I do if no one picks up my patch?
<nckx>After a week or two, send a friendly ping to the bug address.
<bricewge>But in tty the options seems fine, this is definitely an issue with xorg
<bricewge>Removing inetutils from the system profile revealed a missing dependency in lightdm
<nckx>To the bugmobile.
<nckx>iskarian: Is ‘pkg’ the package name, or literal "pkg"?
<nckx>What actually ends up in that directory?
<nckx>It all depends.
<char>nckx the xxx@debuggs.gnu.org or guix-patches@gnu.org?
<nckx>The former.
<nckx>The latter on its own always opens a new bug.
<char>nckx: thanks
<Guest14>nckx: Hi, I’m following up on the VMD driver from earlier today. The install image boots, but the install fails while trying to build the kernel-modules derivation. Is there further configuration that needs to be done?
<Guest14>nckx: The vmd module loads in the installer and the NVMe drive is detected. So that part is fine.
<nckx>Could you share (ideally as text but a photo is OK) the actual error?
<nckx>I might think I know what's going on (perhaps).
<Guest14>Will do. Please give me a couple of minutes.
<iskarian>nckx: the package name; I was trying to be generic. This is the go compiler, which expects everything to be under one directory (/usr/lib/go by default); with libraries and commands under 'pkg', source under 'src', binaries under 'bin'. The current package has these dirs directly in the main output, so they are appearing directly in ~/.guix-profile. With the exception of 'bin', I figured we would rather have these in a 'lib/go' subdirectory
<iskarian>or something
<iskarian>Which is similar to what python, perl, etc. seem to do
<nckx>iskarian: So you're suggesting moving misc/, pkg/, and src/ to lib/ ?
<nckx>Or lib/whatever.
<iskarian>Yes
<nckx>OK, so src definitely belongs in /share/go. misc also looks like architecture-independent text, is that correct? So also /share/go. With only pkg in /lib/go, which BTW sounds like the right choice.
<nckx>I'd not include the version anywhere for simplicity.
<nckx>OTH, /src is also ‘correct’, since $prefix/src (/usr/src) is a thing.
<nckx>*OTOH
<iskarian>Go would still require a symlink in /lib/go/src pointing to /share/go/src, or wherever
<nckx>So Go demands src in lib even though that's wrong? Cool.
<iskarian>Yup. They did not design it to be installed system-wide, as I understand it
<nckx>Not sure why I'm surprised. That completely fits with the rest of Go's high design quality.
<nckx>s/ to be installed system-wide, as I understand it// — FTFY
<nckx>Yeah, fine, chuck it in /lib 👍
<nckx>/lib/go.
<iskarian>Ha!
*dstolfa is so happy he found an authentic italian pizzeria here in the UK... he's missed good pizza for years now
<nckx>😃
<nckx>Great. Now I'm hungy, be right back…
<dstolfa>i would say sorry, but if this results in you getting a pizza, i'd call that a win
<iskarian>Cool. The other elephant in the Go room is that the tests are currently in a separate "tests" output, but to actually use them you have to construct a symlinked directory so that Go thinks they are still in its main directory...
<Guest14>nckx: https://bib.co/zxHGFJB
<Guest14>nckx: https://ibb.co/zxHGFJB sorry
<nckx>Guest14: Ah… sorry, the error itself is in the log file after ‘View build log’. You can bzcat it to the screen and tab completion should work.
<nckx>The installer also has GPM running so you can be all fancy about it and copy-paste.
*nckx → pantry.
<nckx>ok so what kind of a monster even buys capellini
<nckx>like
*nckx → garage.
<Guest14>nckx: I’m posting this from a different machine. Excuse my ignorance, but where is the build log located?
***iskarian is now known as Guest5039
<bricewge>My keyboard is ... a mouse https://paste.debian.net/1203196/, oh well
<nckx>Guest14: in the log file after ‘View build log’. At the prompt, bzcat /var/log/that.
<nckx>Well I guess I'll just starve to death then. Was nice knowing you all.
<nckx>bricewge: I saw that in the log. Does it have a trackpoint or similar extension?
<dstolfa>nckx: i'm sure there's some fast food truck nearby that will save you!
<nckx>evdev: ZMK Project m60 Keyboard: Found scroll wheel(s)
<nckx>It's 01:36.
<dstolfa>hmm, maybe that's only here then. student city and all that, there's always food vans
<nckx>No I'm pretty sure this is it for me. Good by all. I'll leave some capellini for the rats so they don't immediately start on me.
<nckx>dstolfa: Ah, yes, well, I'm in the middle of the woods here.
<dstolfa>nckx: i'll send you food... if you can wait 2 weeks for it to arrive given the speed of post recently
<nckx>Can't wait for that call from customs.
<nckx>‘Sir, this is a kebab.’
<lispmacs[work]>nckx: you can send the food to me
<dstolfa>i almost got that call from customs once because my mom decided to send pre-made pastry
<nckx>What a typical mum thing to do.
<nckx>‘Are you eating well enough son.’
<dstolfa>nckx: and even if you are... you are never eating enough! :D
<Guest14>nckx: I was doing a manual installation. There wasn’t a ‘View Build log’ on failure.
<nckx>It's right there in your screenshot.
<nckx>The line right under the red one.
<Guest14>Whoops, my bad
<nckx>😉
<nckx>I'm afraid I do have to step away for a while now, but I'll be back.
<nckx>Guest14: ☝
<Guest14>nckx: I understand. No problem, I’ll post the log on here and you can take a look at it whenever you get back. Thanks.
<Guest14>nckx: https://ibb.co/KN3wqgg
<zacchae[m]>I installed xinit and xorg-server, but startx crashes saying that it can't find my X executable.
<zacchae[m]>Is this a bug or am I not understanding something?
<zacchae[m]>Yes I updated guix path after installing
<zacchae[m]> * I installed xinit and xorg-server, but startx crashes:
<zacchae[m]>xinit: unable to run server "/gnu/store/8...5-xinit-1.4.1/bin/X": No such file or directory
<nckx>Well, great, now how do I leave them a message…
<dstolfa>just use sneek, so that when some poor soul shows up with the same nickname, they get a completely out of context message
<nckx>Instructing them to just download this random ISO from my Web site that installs Guix on their computer.
<nckx>Hm, actually, I should do that in all channels.
<nckx>And they're not coming here through the Web chat on guix.gnu.org because the template there is PotentialUser, not Guest, so I can't change it to PleaseChangeThisKThx.
<nckx>Guest14: Are you the VMD person?
<Guest14>nckx: Yes
<nckx>Ah, excellent. I've pushed a change to master that should address your problem. Since the image won't be rebuilt today, I've built one myself, here: https://www.tobias.gr/guest/
<nckx>(And since you shouldn't trust strangers on the internet, I've signed the uncompressed .iso with my key, which is last in the list here <http://guix.gnu.org/en/security/>)
<nckx>Guest14: Consider choosing a more descriptive nickname (/nick xxx) so people can leave you messages through sneek, our friendly if somewhat simple bot.
<Guest14>nckx: Whoa. That’s really great of you. Much appreciated.
*nckx blushes.
<nckx>My pleasure.
<Guest14>nckx: I’ve registered a nick, but I’ve logged in using the web chat on Libera
<nckx>Well, at least the ‘14’ is constant, I wasn't expecting that.
<Guest14>nckx: I’ll burn the usb and let you know.
<nckx>👍
<Guest14>nckx: I left the tab open on my browser
<Guest14>nckx: while I have you on here, was the problem because the kernel being installed was a substitute?
<Guest14>so the module was not available?
<nckx>No, substitutes are content-addressed and always guaranteed to be (at least functionally, but usually bit-by-bit) identical. The issue is with how Guix works in general and how we build the image in particular: packages definitions are ‘part of’ guix (e.g., unlike Debian there's no apt executable + separate repo)
<nckx>So whilst the CD booted with the new kernel, and the installer is clever enough to add currently loaded modules that look important to your new system configuration, the guix command contained on that same CD would still install the old one, which lacked the module.
<raghavgururajan>nckx: Any luck with #48729 (v7)?
<nckx>Guest14: You probably could have worked around it by switching to another VT and running ‘guix pull’ while the installer's running, but I've been told by people who actually grok the installer that it's not recommended 🤷
<nckx>raghavgururajan: What's the actual problem? I went to that bug and saw a boatload of patches, but no question.
<nckx>Although it's possible I missed it.
<raghavgururajan>nckx: No problem. Just wanna ask if it looks good to you. Third-eye.
<Guest14>nckx: I see, thanks for the explanation. I actually did run a ‘guix pull’ but i must’ve messed up something.
<nckx>I hadn't pushed the update to Guix itself at that point.
<nckx>raghavgururajan: OK. I thought you were having actual trouble and that Leo had already managed to help you with that.
<raghavgururajan>nckx: That was different (pipe-viewer). This is bitmask.
<nckx>I got them confused
<nckx>sorry.
<raghavgururajan>nckx: Any thoughts on messages from #177 and #186?
<raghavgururajan>No worries! :)
<raghavgururajan>s/and/to
<nckx>Re: http://issues.guix.gnu.org/48729#186 I agree with Maxime. I'd really rather not add things to profiles like that. You say that upstream is ‘planning’ on dropping the polkit requirement. How concrete is that plan?
<nckx>I'd like to here ‘very concrete and happening very soon’ so this is just a temporary wart in Guix, not something that will end up sticking around for 5 years while upstream ‘plans’ ☺
<nckx>raghavgururajan: For http://issues.guix.gnu.org/48729#177 , are you asking because you had trouble getting it to work? If you got it to work, (1) congrats! and (2) it's a good solution.
<Guest14>nckx: Works perfectly. Install done and I’m rebooted into my shiny new Guix. Thanks very much.
<nckx>Welcome! Don't worry, plenty of other cool shiny bugs to keep you company.
<Guest14>Lol, look forward to sorting them all out. Cheers.
<raghavgururajan>nckx: Bitmask's lead dev told me that polkit is a hindrance on some distros, as they got complaints. So they are gonna remove the dependency. I am not sure when.
<raghavgururajan>To load the polkit policy of bitmask, I have to extend the polkit-service-type. For that I need the package the to be in system profile, as it provides the policy. Is there any other way you could think of to make this work but not adding package to system profile?
<raghavgururajan>Regarding 177, I got it to work.
<raghavgururajan>I had to typo in one of my messages before. Its messages from #177 to #186. That's where Maxime and I had conversation. I could apply most of his suggestion, but not all.
<raghavgururajan>s/his/their
<raghavgururajan>Actually, just extending the polkit-service-type is enought to load the policy. I think I added to profile to avoid mismatch betwen versions.
<raghavgururajan>Like policy is loaded from one version, when a user using app from diff version.
<zacchae[m]>Is it possible to just start x servers as a user with startx, or do you need to use one of the system X services?
<iskarian>nckx, another thing our Go package does currently is bake in a gcc for cgo support. Do you think this is more or less reasonable than allowing it to use whatever is accessible in PATH at runtime, for example a gcc-toolchain in the same profile?
<char>pkill9: I installed guix package manager on pinephone
<char>on top of postmarketOS
<nckx>iskarian: I think that is a feature yes.
<nckx>zacchae[m]: I don't think ‘rootless’ X is going to work without changes to Guix.
<iskarian>nckx, that's "baking in gcc is a feature", yes?
<nckx>Indeed.
<nckx>raghavgururajan: Yeah, I thought as much when I wrote ‘in sync’ in my last mail. I get it, but am I correct in concluding the service itself is only needed until polkit is dropped?
<nckx>Well, actually, answer that in my mail ☺
*nckx → leaves for work.
<raghavgururajan>nckx: Thanks for going over the patch-set. Yes, it is only needed until polkit is dropped.
<raghavgururajan>Ah.
<raghavgururajan>sneek, later tell nckx: For #48729, I have applied your suggestions and sent v8. Here is the tarball (https://share.raghavgururajan.name/rg/B8OjZCI0n3DeWVvz/bitmask-patches-v8.tar.gz).
<sneek>Okay.
<raghavgururajan>sneek, later tell nckx: Please ignore v8 and use v9 instead. https://share.raghavgururajan.name/rg/xeHQFU1mDzlkASco/bitmask-patches-v9.tar.gz
<sneek>Got it.
<xnnx>Guys the official package def for Greay fails to build this is that I get http://ix.io/3rAT
<leoprikler>xnnx: does the package have gsettings-desktop-schemas as input?
<raghavgururajan>leoprikler: For packaging a bash script, do we patch coreutils programs to its absolute path?
<leoprikler>absolutely
<raghavgururajan>Cool!
<raghavgururajan>jgart: So we'll patch them as well for Ytfzf.
<zap>weekend guix!
<zap>Still stuck at crosscompiling. Am I right that "vendor specific" field in target triplet (or qadruplet?) doesnt really matter? Im talking about arm*-THISPART-linux-gnu
<jgart>raghavgururajan, leoprikler got it! :___)
***jonsger1 is now known as jonsger
***dekenevs is now known as kitzman
<viivien>Hello, in which package is the command "cmp"?
<cbaines>viivien, I see it in diffutils
<viivien>cbaines, right, thank you
<irfus>podiki[m]: what changes did you make before merging into master? I'm trying to rebuild my system from a local checkout and libepoxy and glu refuse to build
***jonsger1 is now known as jonsger
<TheAsdfMan>Hello, I'm trying to build keepassxc and it builds fine until the wrap-qt phase where it fails with a backtrace
<TheAsdfMan> https://paste.debian.net/1203234
***jonsger1 is now known as jonsger
<nckx>TheAsdfMan: Thanks! Fixed.
<sneek>Welcome back nckx, you have 2 messages!
<sneek>nckx, raghavgururajan says: For #48729, I have applied your suggestions and sent v8. Here is the tarball (https://share.raghavgururajan.name/rg/B8OjZCI0n3DeWVvz/bitmask-patches-v8.tar.gz).
<sneek>nckx, raghavgururajan says: Please ignore v8 and use v9 instead. https://share.raghavgururajan.name/rg/xeHQFU1mDzlkASco/bitmask-patches-v9.tar.gz
<TheAsdfMan>nckx: thanks! now it builds fine
<kitzman>is there a way to instruct emacs in .dir-locals.el, to run geiser as a custom command? (i.e: guix environment ...). i tried setting geiser-guile-binary but that one tries to run the command with arguments as a single binary..
<kitzman>this is emacs-related, but this might be the best channel to ask
<dstolfa>is there an example somewhere on how to access a jupyter notebook run from `guix environment --container`?
<ajarara>I'm trying to get my yubikey to work w/ udev: I've tried modifying the udev-service-type config to have the rules I need, but I'm not seeing them in the dir returned by `herd rules udev`
<Noisytoot>I have added (bluetooth-service #:auto-enable? #t) to config.scm, when I restart, I get a popup saying "g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.blueman.Mechanism was not provided by any .service files (2)". How can I fix it?
<dstolfa>hmm, the guix jupyter kernel seems to crash on me for some reason every time i run it
<dstolfa>i just get Nudge: attempt ... on kernel <HASH> until it just shuts down
<dstolfa>all i'm trying to run is `;;guix environment matplotlib-env <- python-matplotlib python-numpy python-ipykernel`
<dstolfa>the way i've run the kernel is `guix environment --pure --ad-hoc guix-jupyter jupyter -- jupyter notebook
<dstolfa>i'm really not sure what's causing the issue, it just keeps timing out
<ajarara>Ah, just had to restart, otherwise following the man pages for udev-rules-service worked to get rules under `herd rules udev` (and it's reading the rules too)
<podiki[m]>irfus: trying now. I do see that libepoxy had a version bump and change to propagated-inputs for mesa in origin-updates
<sarg>nckx: hi, i've updated the goldendict patch as you suggested. Is it now good to merge? http://issues.guix.gnu.org/48909
<irfus>podiki[m]: yep, that and I had to change the patch file-path routine to look for libs from libglvnd
<irfus>now it's working, and everything hopefully goes through glvnd
<podiki[m]>ah nice
<irfus>I'll probably need to send another patch...
<podiki[m]>I'm rebuilding a lot since my branch has patches I made to gobject-introspection, I'm also probably a bit behind current, but I'll test anyway
<maximed>Hi
<civodul>o/
<maximed>civodul: Have you received a response from glibc folks yet?
*dstolfa is sad his guix-jupyter doesn't want to work
<civodul>maximed: nope! maybe i'll go ahead and apply it
<civodul>i'll apply the patch unconditionally though, so full rebuild ahead
<civodul>dstolfa: what's wrong with guix-jupyter? :-)
<dstolfa>civodul: it keeps timing out :(
<civodul>anything in the console?
<dstolfa>Nudge: attempt 30 on kernel <HASH> ... until it just times out
<dstolfa>goes 10, 20, 30, 40, ..., 120 and then i get this
<dstolfa> https://paste.debian.net/1203250/
<dstolfa>python-ipykernel works fine
<maximed>The patch to also process "libexec" doesn't seem to have caused any issues yet (testing with ./pre-inst-env guix build guix) -- build not yet completed though
<maximed>likewise for adding "bash-minimal" to inputs when 'wrap-program' is used, with the same caveat
<podiki[m]>irfus: can confirm libepoxy doesn't build on core-updates as you said
<irfus>podiki[m]: thanks
<civodul>maximed: yes, i'll apply these at the same time, while we're at it
<civodul>dstolfa: that message you pasted doesn't come for guix-jupyter though
<civodul>how do you run it?
<civodul>perhaps you can report the details at gitlab.inria.fr
<dstolfa>`guix environment --ad-hoc guix-jupyter jupyter -- jupyter notebook` and then i simply create a new notebook with the guix kernel
<dstolfa>the console then shows these nudge messages and nothing gets executed, and i'm unsure why
<podiki[m]>irfus: also on my custom version from master; I think the idea will be once the patch is pushed, we can see build failures on cuirass to see what needs updates with newer mesa build?
<maximed>civodul: which ones do you mean: (a) the 'libexec' patch, (b) the add 'bash-minimal' when 'wrap-program' is used
<maximed>(c): both
<dstolfa>civodul: happy to do so, but i'm not sure how to register :D
<irfus> http://ix.io/3rQa
<civodul>maximed: all of them?
<maximed>civodul: ok
<irfus>podiki[m]: ^ that patch should fix it (and consequently xorg-server)
<civodul>dstolfa: from https://gitlab.inria.fr there should be a link? otherwise report by email to bug-guix@gnu.org, with "[guix-jupyter]" in the subject
<dstolfa>"All users without an Inria account can request an account from an INRIA member with which they collaborate..." according to https://gitlab.inria.fr/siteadmin/doc/-/wikis/home
<dstolfa>so i guess bug-guix sounds like the right place
<maximed>civodul: do you also mean the cross-compilation series that were a preparation for meson? Then please exclude the libgcrypt-error patches, I'm doubting if I did those correctly.
<maximed>(the patches for symlinking some headers; the patch for fixing the error in the shell script should be ok)
<nckx>Does OpenCPN launch for anyone else?
<podiki[m]>irfus: that patch wasn't applying cleanly for me on top of the previous one (some changes I had, and then mesa complained about removing the libglvnd input); could you do one patch with all the changes from origin-updates?
<podiki[m]>(i mean core-updates)
<civodul>maximed: ok, noted!
<civodul>first i'd like to understand why ci.guix is not building core-updates for ARM
<maximed>and ‘cross-base: Fix cross-compiler for i686-linux-gnu’ isn't all that useful, more a hack to test meson when aarch64-linux-gnu didn't work and probably not worth the complexity
<dstolfa>civodul: i've ruled out docker and the likes from being the culprit by disabling them, still hitting the issue, so it might be relatively easy to reproduce with a pretty basic setup. the only "variable" in my setup and something pretty stock is that i use btrfs. could that be causing it?
<Akawama[m]>I keep coming across this error when I run `guix system reconfigure`:
<Akawama[m]>`guix substitute: error: TLS error in procedure 'write_to_session_record_port': Error in the push function.`
<civodul>dstolfa: could you email bug-guix@gnu.org with all the info: how are you running the jupyter and guix-jupyter, what do you see on the console, etc.?
<Akawama[m]>I looked up but can't find anything like it so I'm thinking to submit a bug report. Is there any guideline for it? Other bug reports seems very detailed and I haven't done something like it before
<civodul>Akawama[m]: hi! is that with a recent installation? (1.3.0ish)
<dstolfa>civodul: yep, did that already :)
<dstolfa>oh dear, is there a regression with telegram-desktop?
<dstolfa>just hit https://paste.debian.net/1203258/
<civodul>dstolfa: perfect :-) i'll take a look ASAP
<Akawama[m]>civodul about a month old
<Akawama[m]>civodul**
<dstolfa>i wonder if the telegram issue is caused by all the QT changes
<civodul>Akawama[m]: there's this bug reoprt: https://issues.guix.gnu.org/48903
<civodul>Akawama[m]: could you tell which version of guix-daemon is running, as shown by "ps aux| grep guix-daemon"?
<dstolfa>nckx: i see you touched some qt -- have you noticed that `guix build telegram-desktop` fails, or is that just on my end?
<dstolfa>seems to be caused by (guix build qt-utils) being unhappy with imported-compiled-modules
<dstolfa>specifically, module-import-compiled.drv fails with no code for module (guix build qt-utils)
<mothacehe> dstolfa: Cuirass reports that multiple dependencies of telegram-desktop are currently broken: https://ci.guix.gnu.org/build/641147/details
<sneek>mothacehe, you have 1 message!
<sneek>mothacehe, civodul says: hey! something fishy with the .i686-linux.i686-linux job names: https://ci.guix.gnu.org/eval/56101
<dstolfa>mothacehe: yeah, my guess is that the qt build changes are responsible for it, since that's what the failure in the derivation is
<dstolfa>mothacehe: this is the failure i have locally https://paste.debian.net/1203263/
<nckx>There is definitely something not right with (guix build qt-utils). Ran into that error yesterday, a clean rebuild didn't fix it.
<nckx>sneek: later tell mothacehe: …it did however uncover some uncommitted test changes to choose-services which I will commit soon ☺ Sorry!
<sneek>Got it.
<nckx>raghavgururajan: On which commit are you developing the bitmask patch series? I'm still unable to actually build it, with the same error reported by others for unrelated packages: no code for module (guix build qt-utils)
<dstolfa>nckx: are there qt tests for check-system?
<dstolfa>or something that would cover buliding it?
<dstolfa>building, rather
<dstolfa>wondering mostly in the context of if it might be interesting to add a git hook to master that only pushes if the affected packages also build
<dstolfa>telegram-desktop isn't that important, but if something more serious broke it might be a problem
<nckx>I don't think that's the place.
<nckx>The current hook is already slow.
<dstolfa>hmm
<dstolfa>and i guess you can't make it asynchronous since if it takes a while to build, you might run into merge conflicts
<dstolfa>and all the other goodness of race conditions
<nckx>The place to gate this is on the CI end, with a separation between ‘the branch to which we push’ and ‘the branch from which users pull’, with automation to sync the latter with the former when all tests pass. And send sternly worded e-emails if not :)
<nckx>You know, what CI means for other projects.
<dstolfa>yeah... :)
<dstolfa>how hard would it be to implement something like this?
<nckx>Not implying that's trivial btw.
<dstolfa>it's never trivial... it's software after all
<dstolfa>:D
<nckx>cbaines is probably closest to where all this would happen.
<dstolfa>hmm, my `make check` just deadlocked on guix-packages.sh
<dstolfa>guix-package.sh rather
<dstolfa>the second run passed... i guess something weird happened
*dstolfa shrugs
<nckx>civodul: Some tests fail when run with a non-UTF-8 locale. OK, that's ‘by design’, but are there any drawbacks to forcing an UTF-8 locale when running tests? Is there a reliable way to do so? Is there a reason we don't? We're not testing the user ☺
<na2th>Hello everyone! Here am I again trying to upgrade texlive.
<na2th>With the help of nckx I was able to compile texlive-bin, so I am quite happy about that.
<na2th>On the other hand, I noticed that *the whole file tex.scm* uses two variables %texlive-version and %texlive-revision to select a given version of the tex scripts they download
<na2th>of course I want to bump these versions, but that seems to imply that I have to recalculate *every* hash in tex.scm
<na2th>is this the way to go? Of course, to "scratch my own itch" I can only recalculate the hashs that I use, but this seems to completely rule out my attempt of producing a patch in the end
<na2th>the variable %texlive-revision has 150 occurences, and there are 293 define-public's
<na2th>so it seems that bumping this version implies recomputing hash for half of the 300 packages in tex.scm
<maximed>na2th: what about defining a %next-texlive-revision, and updating the texlive packages to the next version one-by-one?
<na2th>maximed: that seems reasonable; is this what is done in other Guix packages?
<maximed>and at the end of the series, when %texlive-revision is unused, rename %next-texlive-revision to %texlive-revision
<nckx>Could someone run guix environment guix -- make check TESTS="tests/cpio.scm" ?
<na2th>because this really looks like something that comes up in other places
<nckx>It fails here: https://www.tobias.gr/cpio-test-diff.html
<maximed>na2th: Not in my experience
<maximed>what other places are you thinking of?
<na2th>maximed: perhaps is this telling us that we should avoid using %texlive-version and %texlive-tag?
<na2th>well, IDK, but it seems bad to have two variables which define *every* download in a file with 300 packages
<maximed>na2th: I don't think we should avoid it. The situation with texlive is that, texlive consists of many separable components, but there is still an ‘common’version
<na2th>maximed: Ok, but that still feels kinda bad
<na2th>for example, how do I know that I should create %next-texlive-revision?
<na2th>am I the first one trying to bump texlive-bin?
<na2th>where should I document this change, so that whoever comes next will find it?
<maximed>na2th: because you're updating texlive?
<na2th>maximed: sure, but how do I know that someone did not already provide a similar fix before me?
<maximed>to be sure I understand correctly: you want to update the texlive packages one-by-one, and not as one big patch
<na2th>perhaps %new-texlive-revision
<na2th>or perhaps another solution
<maximed>na2th: What do you mean, a fix?
<na2th>yeah
<maximed>Is something broken currently?
<na2th>AFAIK, no
<na2th>but you see, if I create this change, I am not sure I would have found it
<na2th>because I am not simply fixing a new variable, I am leaving a job to be done by future maintainers
<civodul>nckx: tests/cpio.scm passes here, with cpio 2.13 from master; which version are you using?
<na2th>"do not use %texlive-revision, use %next-texlive-revision"
<civodul>2.13 is the latest
<na2th>and if I need to communicate that to "posterity"
<na2th>perhaps someone already did something similar and communicated me in a place IDK
<maximed>na2th: I'm not following you
<maximed>(%texlive-revision, %texlive-tag) would just be the last ‘completed’ upgrade of the texlive packages
<maximed>(%next-texlive-revision, %next-texlive-tag): would be version we're striving towards.
<maximed>So new texlive packages should use %next-...
<maximed>And, over time, texlive packages should be migrated to %next-...
<na2th>right, where should I tell people to use %ntext-texlive-{tag,revision}?
<na2th>and is this place, let's say, standard enough, so I can introduce this and be safe that there is no "competing solution" for this problem I should adopt?
<maximed>And when that's completed, and no used of %texlive-revision, %texlive-tag remain, the %next-texlive-revision can be renamed o %texlive-revision
<maximed>ok, so the question is, how to communicate this?
<na2th>yes
<na2th>and how to find if someone already solved this problem
<na2th>perhaps in a way I am not aware right now
<maximed>na2th: You could look at https://issues.guix.gnu.org, and ask on #guix, if someone has been updating texlive. (I don't see a problem, except the packages are outdated)
<maximed>Also, you don't have to use %texlive-revision, %texlive-tag I suppose.
<maximed>I don't see %texlive-revision and %texlive-tag being documented in the manual
<maximed>So I suppose you could just document it in ‘guix/build-system/texlive.scm’
<maximed>Also, you've been communicating now, on #guix! Though it may be a good idea to send a mail to guix-devel@, to reach a wider audience and give people some time to respond
<na2th>that makes a lot of sense, maximed
<na2th>I will send an email, and look around the issues
<maximed>Note that if you use texlive-ref, you'll have to adjust it to accept an (optional?) ‘revision’ argument
<maximed>otherwise, guix will try to download an old version anyway
<na2th>wait, texlive-ref function in gnu/build-systems/texlive.scm ?
<maximed>yes?
<na2th>it seems to be using the global variables, and does not accept optional arguments
<maximed>Then patch it to accept optional arguments
<na2th>lol nice
<na2th>that makes sense
<maximed>(define* (texlive-origin name version locations hash #:key (tag %texlive-tag) (revision %texlive-revision)) code code ...)
<maximed>that can be used like (texlive-origin .... #:tag %another-tag #:revision %another-revision)
<na2th>I see
<na2th>lemme see if I can make that work out
<na2th>and read a little bit about scheme default arguments, so that I actually understand what I am typing
<maximed>The exact method you use to gradually update texlive doesn't really matter, as long as it works
<na2th>thank you very much!
<civodul>hmm seeing Guile 3.0.7 test failures on i686 on core-updates: https://web.fdn.fr/~lcourtes/pastebin/guile-i686-test-failure.html
<civodul>(and not on master)
<civodul>could have to do with libm changes?
<maximed>(and preferably, split into separate patches that can be reviewed seperately, and such that things are disectable)
<na2th>maximed: just to check if we are on the same page: the idea is to update these functions, so that I can pass the version I want as optional arguments
<na2th>then in the package definition, I pass these aditional arguments
<maximed>na2th: Info:(guile)Coding With Keywords
<maximed>na2th: yes
<na2th>this would simply "demote" %texlive-tag and %texlive-revision to fallbacks, instead of default values
<na2th>and make everyone's job upgrading things later easier
<dstolfa>nckx: tests/cpio.scm passes here too
<maximed>"fallbacks" and "default values" seem the same thing to me
<na2th>maximed: well, not right now, as I cannot change the defaults
<na2th>at least without breaking everything
<na2th>maximed: thank you very much for the help!
<maximed>I don't see why being a "default" would imply changing the "default" wouldn't break things.
*maximed demands a default bikeshed
<na2th>you are right
<na2th>I think I have a "fixed value" that I want to demote into a "default value"?\
<maximed>I don't see why that would be called a ‘demotion’. On second thought, I suppose that could be called a ‘demotion’, though I wouldn't call it that.
<maximed>‘demotion’ sounds negative, while making a previously hardcoded value into a default value seems an improvement
<na2th>well, I am being negative on the hardcoded value
<na2th>he was the big boss in town
<na2th>and I want to make him obsolete
<maximed>The hardcoded value %texlive-revision is the same as the default value %texlive-revision. With this change, %texlive-revision can now serve guix better, so that seems positive for %texlive-revision?
<maximed>If/when all texlive packages are upgraded to some common version, then %texlive-revision can be updated again
<maximed>So %texlive-revision will ococcasionally be granted a vacation (-:, which seems positive for %texlive-revision?
<na2th>maximed: I see why you demanded a bikeshed, you are good at it
<maximed>Actually, if this change is made, it is quite possible eventually %texlive-revision will disappear. I suppose you could call that ‘negative’ for %texlive-revision
*maximed gives na2th a bikeshed: https://commons.wikimedia.org/wiki/File:Station_Oudegem_-_Foto_3_(2009).png
<nckx>civodul, dstolfa: Thanks. I'll let you know civodul.
<tisquel9-pm-user>Hello, Guix.
<tisquel9-pm-user>I am using the Guix package manager on Trisquel 9 and would like to know if I can use 'install-info' or some other method to get Emacs (installed with Guix) to see the custom .info file I made or do I have to create a Guix pacakge and install it that way.
<tisquel9-pm-user>So far I've had no luck by adding the directory path to INFOPATH, up to and including creating a dir file for that directory and using 'install-info' on Trisquel...where it works but still can't be seen by Emacs.
<bricewge>nckx: I managed to unveil the mystery of the mouse-keyboard, xorg-configuration force evdev driver on keyboard
<bricewge>When removed, libinput driver identify the keyboard as a keyboard and not only a mouse!
<bricewge>I've sent a patch about it https://issues.guix.gnu.org/49359
<drakonis>roptat: you around?
<nckx>bricewge: Thanks for following up! I was a bit of a libinput fanboy before, but now I'm just going to going to consider evdev deprecated. I think your patch is the way to go.
<maximed>sneek: later tell civodul: I forgot importing (gnu ... bash) in (gnu ... xdisorg) in the ‘Add input for 'wrap-program'.’ series
<sneek>Okay.
<maximed>sneek: botsnack
<sneek>:)
<cwebber>hi hi
<drakonis>hey hey
<nckx>Hoi hoi.
<cwebber> https://lists.gnu.org/archive/html/guix-devel/2021-07/msg00004.html is exciting
<drakonis>indeed
<tisquel9-pm-user>Please disreguard my previous questions: I solved the issue by simply adding a hook to info-mode in my .emacs as per the last suggesting in the Info manual.
*nckx is registering 666 items 😈
<drakonis>that's a lot of items
<drakonis>truly devilish
<nckx>This is also cpio 2.13 from master, civodul.
<drakonis>guix pull: error: Git error: object not found - no match for id (3c637d3318f83d82037f4a58e83b60ed82bbb92d)
<drakonis>this is a first
<nckx>That's upstream wip-gnome?
<drakonis>weird
<cwebber>every time I work on updating a package:
<cwebber> - bump the version number
<drakonis>i'm not following wip-gnome
<cwebber> - change a single character in the hash
<cwebber> - see what hash it complains it got instead
<cwebber> - use that
<nckx>Works here. Try removing ~/.cache/guix/checkout.
<nckx>drakonis: …oh! Oh.
<nckx>guix pull: error: Git error: object not found - no match for id (011386a446f448f86c266d189d7d972c5c048ff1)
<nckx>Haha what.
<nckx>I get that instead.
<TheAsdfMan>Hello, I have problems starting the libvirtd service, it used to work but after it got updated to 7.5.0 it doesn't, i think the problem is in the config file it reads, it writes 'auth_tcp: unsupported auth sasl:'
<drakonis>hmm
<drakonis>i wonder if it has something to do with extra channels?
<drakonis>hmm nope not at all
<drakonis>that's something i've never gotten before lol
<drakonis>wtf
<nckx>TheAsdfMan: I don't think SASL support is enabled, so that explains that. I'll take a look.
<dstolfa>drakonis: which branch are you following
<dstolfa>someone might have force pushed a rebase
<drakonis>master
<dstolfa>hm
<dstolfa>not it, then
<nckx>drakonis: Same here, I recently pulled. This is mildly worrying.
<dstolfa>nckx: uh-oh
<drakonis>ruh roh
<nckx>Very mildly.
<dstolfa>this sounds, uh
<dstolfa>how do i put it
<dstolfa>scary?
<dstolfa>i can dig myself out of this, but this is not great
<drakonis>we're going to have some people show up and ask about that, arent we?
<dstolfa>most certainly
<drakonis>i'm going to try something out real quick
<dstolfa>drakonis: you know what would be funny
<dstolfa>if guix managed to hit a sha-1 collision
<drakonis>do tell
<nckx>N.B. that this only happens when I run ‘guix pull --commit=3c637d3318f83d82037f4a58e83b60ed82bbb92d --allow-downgrades’, not when I ‘guix pull’ proper.
<drakonis>i'm doing guix pull proper atm and i'm getting that so
<drakonis>wonder why
<dstolfa>did you track any other branch at any point?
<drakonis>not at all
<nckx>My guix/channels doesn't point to Savannah but to a local clone. Let's delete it and try some tasty defaults.
<dstolfa>drakonis: how did you end up on a wip-gnome commit then
<nckx>Eh, rename, why did I say delete :')
<drakonis>i have no idea lol
<drakonis>i tried pulling using the latest hash just now
<drakonis>still getting an error
<dstolfa>drakonis: can you just `guix pull --commit=<last hash on master> --allow-downgrades`?
<drakonis>i just did that lol
<drakonis>still getting an error
<TheAsdfMan>This is the config file it reads https://paste.debian.net/1203277/
<drakonis>guix pull --commit=e789ce538ed848bacb8f4eb5742f78b965ccf57c --allow-downgrades
<drakonis>i was not mentally prepared for this :V
<drakonis>cwebber: still doing racket?
<drakonis>hmm maybe what i should try is rolling back my channels
<nckx>Did you try deleting your ~/.cache/guix just in case?
<drakonis>okay rolling back to an older commit is workng
<drakonis>then i'll try to upgrade to a newer one and find out what's up
<drakonis>f2a8b7e09c043aeb926e20301b8ae249ddfd652f this is the current hash i'm on
<drakonis>rolled back to 6623d1cd7f3298f2e5c224299d11a77f7ae18bf5
<drakonis>i'm sure the problem must've been something related to the gnome branch
<nckx>Why do you say that?
<nckx>(You all have faster/idler machines than I do, I'm still pulling…)
<dstolfa>the gnome branch was rebased onto master i think, so it would cause issues... but i don't know how you ended up on wip-gnome if you say you've never used it
<drakonis>because my current guix repository clone dates to 30th june
<drakonis>i hadn't pulled in a few days
<nckx>dstolfa: Right.
<drakonis>was fiddling with wine and dark souls :V
<drakonis>video games i tell ya
*nckx is going to take that sentence literally and not as a reference to non-free software.
<nckx>Makes your life sound way cooler.
<drakonis>lmao well
<drakonis>sure it does
<nckx>OK, ‘guix pull’ without a channels.scm succeeded. I'm now on upstream commit e789ce538ed848bacb8f4eb5742f78b965ccf57c. Let's see if the new guix can pull itself too.
<drakonis>let's pretend i'm not playing video games with guix right now
<nckx>Well, you're not, are you? You're wasting your life on IRC like your mother always warned about.
<drakonis>hahaha
<nckx>‘Pulling guixes’ and doing the drugs no doubt.
<nckx>Successfully running ‘guix pull’ twice without a channels.scm on two independent machines has reassured me that no post-mortems will be written today, so that's nice. I wonder what *is* up then.
<Noisytoot>After I added bluetooth-service to config.scm (with #:auto-enable? #t), when I start my computer, I get a popup saying "g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.blueman.Mechanism was not provided by any .service files (2)" (and bluetooth doesn't work)
<drakonis>something that an ill timed pull may have caused
<dstolfa>drakonis: maybe you just forgot you used wip-gnome?
<drakonis>i dont think i ever have
<drakonis>my channels list doesn't have it active
<nckx>Noisytoot: I have the same code and last reconfigured on 49dc5bb7d22af9019b71be67bd8e43f15c41cf23 and BT works fine. I don't use anything that could display a pop-up though, only bluetoothctl directly. Have you tried that? Maybe the problem is with your DE?
<Noisytoot>nckx, I think blueman displays the popup
<nckx>Ah, don't use that; only the same snippet as you.
<Noisytoot>What package provides bluetoothctl?
*nckx typed bluetootctl and found no results.
<nckx>Noisytoot: bluez.
<nckx>I get the same error when I run blueman-adapters.
<nckx>Seems to be ‘just’ an error in Blueman packaging or how it interacts, not with that snippet you pasted above.
<Noisytoot>bluetoothctl works
<Noisytoot>blueman-adapters spells "adapters" as "adaptors" in some places
<nckx>So it's a GUI for Bluetoothings, right? Forgive my ignorance.
<nckx>At least you can use the CLI for now, but of course a bug report is welcome.
<Noisytoot>yes
<Noisytoot>GNOME's bluetooth thing in settings doesn't work either
<nckx>It's probably something related to the usual gsettings-desktop-schemas or similar suspects missing from somewhere.
<Noisytoot>blueman should propagate bluez
<nckx>Sorry if I sound dismissive, that's not it, I'm just a bit burnt out on keeping the big ball of G-spaghetti working.
<Noisytoot>It doesn't do anything without bluez being also installed (apart from the popup)
<Noisytoot>If bluez is installed, it still shows the popup, but does actually work
<nckx>Huh!
<TheAsdfMan>nckx: Should i change auth-tcp to none since you said libvirt isn't compiled with sasl anymore
<drakonis>nckx: is it a big ball of mom's spaghetti?
<Noisytoot>Does anyone here use blueman or GNOME's bluetooth thing?
<nckx>drakonis: Nice. I'd prefer mom's spaghetti TBH.
<nckx>TheAsdfMan: Let's see if we can enable SASL first, I guess.
<nckx>And by ‘we’ I mean ‘I’.
<drakonis>hmm, i dont know what am i doing incorrectly with regards to pulling lol
<drakonis>also if i want to use a local checkout i need file:///?
<nckx>Yes.
<drakonis>cool
<drakonis>its been taking a little while tho
<nckx>And URLs don't support magic ~, just in case :)
<drakonis>i'm using the full path, yeah.
<drakonis>nckx: did i forget to do something again?
<drakonis>guix pull: error: Git error: cannot locate remote-tracking branch 'origin/keyring'
<drakonis>file:///home/drakonis/guix
<nckx>I don't know if you forgot, maybe it's undocumented. You need to check out the keyring branch (tracking origin/keyring!) at least once in your local repository.
<drakonis>ah i see
<drakonis>i dont think it is documented
<drakonis>at least for this workflow
<drakonis>aha found it
<nckx>Building from Git.
<drakonis>it is in the workflow for building from git, but it isnt alluded to if you're running a local guix channel
<drakonis>aye
<drakonis>that's where i found it
<raghavgururajan>Hello Guix!
<nckx>There are docs for using a local channel?
<drakonis>t last.
<drakonis>at last.
<drakonis>hmm
<drakonis>maybe i should read more docs
<nckx>Folk: how the *hell* do I get Meson to tell me why it's failing to find a library right in front of it? There's something called meson-log.txt but it contains nothing of value. Where's the real log?
<nckx>We should all read more docs.
<nckx>It would keep us busy from writing software.
<nckx>There is already too much software.
<nckx>Hi raghavgururajan.
<dstolfa>nckx: sort of bleeding over the discussion from ML here... are there any lawyers floating around in the guix space that could comment on the ZFS thing?
<nckx>Not of which I'm aware.
<dstolfa>:(
<raghavgururajan>nckx: On my local bitmask branch, guix describe is bd67ba445a386ba95a7b9b5bfc0803e46d8af5e7. In v9 patch-set, I imported (guix build qt-utils) inside bitmask definition, to overcome the error.
<jgart>nckx, by using local channel do you mean something like this? https://github.com/jsoo1/dotfiles/blob/eaf7070a78cbf3d0b43623d00a7feacbbad78068/guix/channels.scm#L8
<nckx>My position is that the CDDL incompatibility applies only to the kernel module (and some dispute even that — see Canonical).
<nckx>That is correct jgart.
<nckx>raghavgururajan: Ah, OK, so it was a ‘real’ error.
<dstolfa>nckx: yeah, i'd like to know why it would not be okay to distribute a standalone zfs kernel module as a substitute
<dstolfa>because it's not distributing a big binary that requires to be GPL'd, just the CDDL'd source under whatever license
<nckx>I think that's been documented elsewhere.
<nckx>I mean, in non-Guix circles, since it's a general problem.
<dstolfa>has it? the only thing i'm aware of is https://www.fsf.org/licensing/zfs-and-linux, but this mostly just talks about why it can't be a part of linux
<nckx>I did not mean RTFML.
<dstolfa>e.g. you link ZFS (CDDL) into linux (GPL) and you need to distribute ZFS as a part of linux under the GPL and thus the source under the GPL. but if we're just distributing ZFS as a standalone thing, this isn't really the same thing that the FSF discusses here right?
<nckx>Modules are a part of Linux.
<nckx>What would a stand-alone ZFS look like? IIRC there was a FUSE effort but I thought it petered out.
<dstolfa>well in this case standalone zfs module would just be whatever ZoL is. if we stretch it, i'm not sure we could even argue that ZoL in source form is okay then, as it includes linux headers
<dstolfa>i'm not a lawyer, so this is just armchair lawyering at its finest
<dstolfa>hence why i asked :P
<nckx>That's all this is.
<nckx>Worse: *IRC* armchair lawyering. That's 2 levels of bullshit instead of 1 😉
<dstolfa>ahahah
*dstolfa hopes that someone will have some experience with the law on the mailing list
<dstolfa>would be really nice to get an actual professional take on this
<nckx>I don't think your source-binary parallel holds, since the rules for either aren't the same, complicated by the fact that there are 2 licences to discuss and not just the GPL. But I am indeed no more a lawyer than Sweaty Joe down the street who lives in a box and sells expired cough syrup to children.
<nckx>Probably even less.
<nckx>dstolfa: Agreed!
<dstolfa>nckx: the thing i struggle with is where the line is. it's easy to go through the ZFS on linux code and find a bunch of includes of linux headers, which are GPL'd. the thing i want to know is... why is that okay, but building it and giving it to thy neighbor is not
<dstolfa>and i fear that the only way to know the answer to that is court, which i doubt is in anyone's interest
<nckx>We really need an opinion on what *Guix* does. Our #:substitutable? #f hack is clever and fun and very clever. Do organisations like the SFC answer questions like ‘but does it actually work’ for free?
<nckx>Finding people to give free legal advice: hard.
<dstolfa>FWIW, regarding guix i think it's perfectly acceptable to say: "we don't want any part of this, brr scary"
<civodul>nckx: i think https://www.fsf.org/licensing/zfs-and-linux is a good summary
<sneek>civodul, you have 1 message!
<sneek>civodul, maximed says: I forgot importing (gnu ... bash) in (gnu ... xdisorg) in the ‘Add input for 'wrap-program'.’ series
<dstolfa>civodul: it doesn't answer my question unfortunately :( i've read through it a few times but never could reconcile why it's okay to include linux headers from CDDL'd code and redistribute that, but not building it as a standalone module which is modprobe'd and redistributing that
<civodul>yeah, but i don't have a better answer
<civodul>it's surely a grey area
<dstolfa>yeah, that's fair. i'm mostly just curious because i don't fully understand it :D
<nckx>People keep pasting that FSF link, I don't think it answers this question.
<nckx>We've all read it several times by now as required by our faith.
<civodul>oops, hadn't seen it had already been discussed
<nckx>Even then, let's assume we've all read that link before 😛
<civodul>not knowing people on the other end makes it hard to assume what they've read tho :-)
<dstolfa>i feel like the simplest answer to this is: "let others put in the lawyer work, we just follow"
<dstolfa>given how much of a grey area it is
<nckx>It's not a bad link. And I'm sure there are good reasons for it not even explicitly mentioning the CDDL except in the background section.
***TheCreeper1 is now known as TheCreeper
<dstolfa>yeah, that article definitely answered a lot of the questions as to why it's a problem to put it in linux itself (and not assuming things is good civodul! i appreciate the link. if i didn't read it before, i would have learned something)
<dstolfa>alas... lawyer things are hard. sorry for starting a bikeshed (it wasn't intentional, i promise)
<Noisytoot>nckx, licensing@fsf.org
<nckx>dstolfa: Did it answer your question on why there's no such thing as a ‘stand-alone ZFS module’? Because it's in there, next to the dig at Canonical's lawyers 😉
<vagrantc>dstolfa: it pretty much comes down to the relevent clauses of the GPL only come into effect when you distribute a binary to another party/person
<vagrantc>you can ship CDDL+GPL source code together all you want
<dstolfa>vagrantc: but does ZFS the binary module contain any GPL symbols, etc? i thought they stripped all of that out
<vagrantc>dstolfa: can you build the binary without using any GPLed code?
<Noisytoot>Is there any reason to use ZFS rather than btrfs?
<dstolfa>vagrantc: i don't really know, i don't use ZFS on linux
<vagrantc>btrfs has a reputation, deserved or not ... to me both zfs and btrfs sound really complicated and i keep coming back to ext4 :)
<vagrantc>dstolfa: i think that was a rhetorical question, but i also don't use it. :)
<vagrantc>dstolfa: if you could build a binary without building against the kernel sources, the issue would be moot. but i don't think you can.
<The_tubular>There was a guy talking about packaging podman yesterday or 2 days ago (I really gotta use something else than this web IRC browser ...) Did he succeed, if not, does he need a hand ?
<dstolfa>vagrantc: well, i guess it's something that would need to be answered by someone who does :D. thanks for the input, much appreciated
<dstolfa>i'll see if anyone knows
<vagrantc>Noisytoot: another reason to use zfs on linux instead of btrfs is if you like to get caught up in complicated debates about things that are very grey areas
<civodul>:-)
*dstolfa uses btrfs
<civodul>btrfs seems to be a good contender in that area
<civodul>i wouldn't bother with zfs
*Noisytoot also uses btrfs
<vagrantc>seems like btrfs natively deduplicates the filesystem ... does that mean when updating /gnu/store the deduplication process is a no-op and goes very fast?
<vagrantc>i keep thinking i'll try btrfs, but then realize i'm about to try it on a machine without a lot of ram, and seem to recall it's a bit ram hungry
<Noisytoot>vagrantc, How much ram does it have?
<The_tubular>It's not as bad as ZFS
<Noisytoot>I run btrfs on a computer with 4GB of RAM (and 8GB of swap)
<Noisytoot>s/8/4/
<vagrantc>ok, so *maybe* could work on the pinebook pro (4gb ram)
<vagrantc>any other resources it tends to consume? e.g. cpu?
<nckx>Noisytoot: ZFS is more mature and reliable than current Btrfs, although I don't know if that applies to the Linux port. It has more and more complete features that btrfs lacks, than btrfs has features over ZFS. These features do matter ‘at scale’ and in ‘the enterprise’. ZFS is still the only credible option there.
<vagrantc>oh, u-boot doesn't support btrfs ... so would have to fix the bug for a split /boot partition
<nckx>Btrfs is still struggling to reimplement RAID5/6 after they vastly underestimated it and designed a system that didn't work :-/
<bricewge>vagrantc: I did a cleanup about open pcscd issues. The last one open is https://issues.guix.gnu.org/31337, do you still have issue with it?
<vagrantc>bricewge: i haven't even tried in ages, to be honest :)
<vagrantc>oh, actually there is some support for btrfs in u-boot ... though it might not be enabled for pinebook-pro ... hrm.
<nckx>vagrantc: It provides system calls to deduplicate files you tell it are duplicates. It's more efficient than hard links but it's not native as in transparent. It would vastly speed up the final GC phase (deleting links) because you don't have to stat() the world.
<bricewge>vagrantc: Now there is a pcscd-service-type, that should the issues you had. Do you think it can be closed?
<vagrantc>bricewge: i suppose, i can always reopen or open another bug if i use it again and it doesn't work :)
<vagrantc>nckx: interesting, thanks!
<apteryx>vagrantc: there's nothing RAM hungry about Btrfs, unless I'm missing something. There's something about ZFS (deduplication) that *is* very memory hungry, from what I've read.
<bricewge>Great, thanks. Hit me up if you need help with this
<vagrantc>apteryx: ah, maybe i've got them mixed up then
<nckx>I've also never heard that about btrfs, but I've never used it on a 128-MiB RAM VPS either.
<bricewge>I just found out that xinit's bin/startx is a bare shell script with call to "dd", "hostname" and co. How to deal with such executable?
<vagrantc>dd ?
<nckx>(indeed)
<nckx>bricewge: You can patch them to use the full file name.
<nckx>I keep getting this fatal error from the gui-{uefi-,}installed-os system tests:
<nckx>command ("guix" "system" "init" "--fallback" "--no-grafts" "--no-substitutes" "/mnt/etc/config.scm" "/mnt") failed with exit code 1installer[220]: crashing due to uncaught exception: system-error ("umount" "~S: ~A" ("/remove" "Device or resource busy") (16))