IRC channel logs

2021-11-19.log

back to list of logs

<jpoiret>samplet: according to the polkit rules of elogind, only an administrative user can change VTs
<jgart>Is there any guide with best practices for how to use guix.scm in a local repo to build a project?
<gbrlwck>pulling branch c-u-f i get an "unbound variable: icu4c-69, but i don't know where this reference should appear (error happens at guix-package-cache).
<jgart>If not, would this be something that would benefit from a cookbook entry?
<jpoiret>gbrlwck: this is an error with some other channel, please use their core-updates branch
<jpoiret>samplet: can you try disconnecting from a network with network-manager-applet if you're using that?
<jpoiret>i'm getting a not authorized error
<jpoiret>there definitely is something wrong with polkit/dbus
<samplet>jpoiret: You’re right: I can’t do anything with the network.
<roptat>I'm trying to find out how to use guard*, but I get &non-continuable whatever I try...
<roptat>it works as long as the body doesn't raise a condition, but when it raises &opam-not-found-error, first it's not catched by the (opam-not-found-error? c) clause, and second I get &non-continuable after the execution of a #t clause I added to check if it went through the first or not
<zimoun>sneek later tell civodul: on machine A, julia builds. On machine B, fails at test LinearAlgebra/test/matmul.jl:155.
<sneek>Okay.
<roptat>uh nevermind, apparently the body raises &non-continuable...
<raghavgururajan>apteryx: Could `hkps://keys.openpgp.org` be a default keyserver for gnupg package?
<roptat>got it, I wasn't looking at the right place. It's catched correctly, but then raises &non-continuable
<roptat>so... how do I make my condition continuable?
<vagrantc>raghavgururajan: i don't think it's a good choice, as i don't think you can search for keys by id ... it's ok for refreshing keys if you already know what you're looking for
<vagrantc>raghavgururajan: it also drops third-party signatures, so you *just* get the key, none of the web of trust
<vagrantc>that said, it actually does function
*vagrantc wishes it would still allow cross-signed signatures, which would at least build that much of the web of trust
<jgart>Is it possible to subscribe to a guix channel that doesn't have signed commits and install those packages?
<jgart>I realize the security implications of doing that
<jgart>I just want to know if it's possible currently or if I would have to hack guix to allow it?
<vagrantc>there's an --allow-unathenticated commandline option (or similarly named)
<raghavgururajan>vagrantc: I see.
<KE0VVT>Trying to install Guix on Fedora again. There is a workaround to allow just my user to use Guix, but that is not very useful. I'd rather be able to use Guix as any user.
<KE0VVT>The SELinux article does not address the regular Guix install script.
<KE0VVT> https://guix.gnu.org/manual/en/html_node/SELinux-Support.html
<raghavgururajan>vagrantc: Did you mean search keys by ID via web or directly from an application? Looks like it supports via web, https://keys.openpgp.org/
<vagrantc>$ guix lint --checkers=description | grep typo | nl ... only 29 known typos left!
<vagrantc>raghavgururajan: in the sense of making it the default for gnupg in guix, it doesn't provide all the functionality gnupg is expecting
<raghavgururajan>Ah gotcha!
<vagrantc>raghavgururajan: which they did for arguably valid reasons, but i think leaving an empty default is probably better
<Guest8848>Is there some way I can make sure that when using a custom Guix channel that the maintainer of that channel doesn't change the source url of a package to something malicious?
<Guest8848>Something that would show me the diff of the package definition before updating, maybe?
<jgart>Guest8848, see "First, a warning" section here: https://www.ryanprior.com/posts/try-guix-package/
<jgart>Guest8848, that sounds like a good feature to have
<jgart>Would be cool to have a way to show the diff of a package you are about to install before installing it.
<jgart>What would the diff show?
<jgart>difference between channel shasum and upstream channel shasum, etc...
<roptat>it might be difficult to evaluate because there could be many packages in the channel
<samplet>It looks like on c-u-f, PolicyKit is trying to use ConsoleKit instead of elogind....
<jgart>If anyone has the time to review this it would be much appreciated: https://issues.guix.gnu.org/47852#17
<jgart>It's v6 of a patch set for sc-im
<jgart>I upgrade sc-im to the latest
<jgart>I had originally packaged an earlier version but a new release was made since then
<jgart> https://github.com/andmarti1424/sc-im
<jgart>I also moved visidata to (gnu packages spreadsheet-apps), a new module
<apteryx>raghavgururajan: we don't need a default key server in guix; GnuPG has its own, and failing that the user can configure one they like
<GNUtoo>Hi, is it expected that we build the zfs kernel module source code?
<GNUtoo>The GPL and the CDDL are incompatible, so combining both is not legal: https://www.fsf.org/news/interpreting-enforcing-and-changing-the-gnu-gpl-as-applied-to-combining-linux-and-zfs
<GNUtoo>As I understand, the userspace part doesn't have this issue though
<GNUtoo>I found out about it because libvirt depends on ZFS (probably for the userspace part), but for me the kernel module failed to build with 'make[3]: *** No rule to make target 'arch/x86/Makefile_32.cpu'. Stop.'
<GNUtoo>and make install has some (string-append "INSTALL_MOD_PATH=" moddir) argument
<GNUtoo>So it really does build the kernel module
<GNUtoo>So that makes images with that module non redistributable
<GNUtoo>+ it's probably not a good idea to depend on something like that since we can easily end up in situations where our interest is that copyleft becomes void (to enable to use and redistribute the zfs module)
<GNUtoo>Should I raise that issue on the mailing list? or in a bugreport?
<GNUtoo>Or should I just try to send a patch to at least remove that compilation process?
<GNUtoo>And would I need to patch the source to remove the module code?
<GNUtoo>so that guix build --source would yield a source that doesn't have the module and that can safely be built
<apteryx>IIRC the way it is distributed in Guix is that it isn't; Guix provides you the package, but you have to build it locally
<apteryx>I'm not sure I'm following though; what triggers this? which package in guix is problematic? I don't see anything zfs about libvirt
<apteryx>sneek later tell civodul haha! I got the zombie reaping thing going by forking, calling my new (set-child-subreaper); and invoking the test by (execlp "tini" "--" ...)
<sneek>Will do.
<Myrcy>hello
<Myrcy>is it possible to start the GuixSD installer from terminal? I need some custom settings to connect to wifi, but want to use the GUI after that.
<jgart>yes it is
<jgart>there's a prompt that asks you if you want to drop down to a terminal
<jgart>can't remember which one now but if you go through the installer you won't miss it
<Myrcy>yes, I know how to get to the console.
<Myrcy>I just want to then load the graphic installer, after configuring wifi
<apteryx>I think there's always a terminal availably in one of the ptty (Control-Alt-F1/F2 or such)
<apteryx>along the info manual
<apteryx>raghavgururajan: any idea of what would be a minimal cursor theme for Mutter (GTK/GNOME I guess) ?
<raghavgururajan>apteryx: Separate cursor theme was dropped in gtk3 and after.
<raghavgururajan>IIRC
<TheOwlLady>Apteryx, thanks for the information
<TheOwlLady>I'm installing it on a VPS and my device registers the TTYL consoles instead
<guixy>Hi guix
<guixy>(if anyone is there)
<raghavgururajan>apteryx: cursor-theme is now part of icon-theme. GTK/GNOME's default is adwaita-icon-theme, which provides `[out]/share/icons/Adwaita/cursors`
<jackhill>jpoiret: ok, I think I caught up on the backlog. Sounds like there are polkit problems now but everything else is good? Should I be trying anything?
<samplet>Regarding polkit, it is not being built with support for elogind. It will need to be rebuilt (along with its 2308 dependants). I’m working on the fix now.
<jackhill>samplet: cool, thank you! Was it "just" a configure flag?
<samplet>jackhill: Nope. I’m pretty sure it’s broken upstream. It detects elogind, but then doesn’t use it.
<samplet>They’re switching to Meson, so it’s not a big deal.
<jackhill>huh, what fun!
<jackhill>hi guixy!
<samplet>Gentoo has a patch, but it applies to the “configure.ac”, which means I would have to regenerate the “configure” script....
<samplet>For “fun” I’m gonna try and build it with Meson.
<jackhill>:)
<jackhill>another one for the sprint (although I guess it's no longer Thursday in my timezone): https://issues.guix.gnu.org/51962
<samplet`>Nice! I’m about to test out a (grafted) polkit that might actually work.
<jackhill>best of luck!
<jackhill>ugh, rust-bitflags@1.2.1 fails to build, but I think I'm going to stay away from rust-land for now
***modula is now known as defaultxr
<fcw>Is anyone able to install python-pendulum ("guix install python-pendulum")?
<fcw>I'm wondering if I'm the only one who experiences an error: "no setup.py found".
<samplet>fcw: The build server shows the same error.
<fcw>samplet: Ah. Where can I see that?
<samplet> https://ci.guix.gnu.org/build/574386/details
<samplet>(Then go through to the “raw” log file.)
<fcw>samplet: Okay. Thank you for the link. How did you find the link so quickly? When I enter "python-pendulum" in the search box on https://ci.guix.gnu.org, there are lots of results.
<samplet>I added “spec:master” to limit it to the master branch.
<fcw>samplet: Okay. I've submitted a patch that fixes the problem: https://lists.gnu.org/archive/html/guix-patches/2021-11/msg00877.html
<samplet>Wow! Pretty quick on the draw, there.
<samplet>:)
<fcw>samplet: Well, I submitted that patch before asking on IRC ...
<samplet>That makes more sense. :)
<fcw>Is there a continuous integration server that automatically tries to build patches submitted to the guix-patches mailing list?
<efraim> https://data.guix-patches.cbaines.net/
<fcw>efraim: How do I use that website? How do I find the build results of a particular patch? For example, this patch series: https://lists.gnu.org/archive/html/guix-patches/2021-11/msg00876.html
<efraim>Unfortunately I'm not sure about that part
<fcw>efraim: I've figured it out. Go to https://git.guix-patches.cbaines.net/guix-patches/, and look up the branch name (e.g. series-10203) corresponding to the subject of the patch (which appears in the "Commit message" column).
<fcw>Although branches are created for each patch series, it appears that no patch has been built in the last two weeks ("No information yet"). Not sure what is going on.
<PurpleSym>Afaik cbaines disabled the building some time ago.
<fcw>If a supposedly open source Library A depends on Library B that has no explicit license, does it mean that both libraries cannot be added to Guix?
<fcw>I am thinking of packaging cl-trie (https://github.com/danlentz/cl-ctrie), which says that it uses the MIT license (see cl-trie.asd). However, cl-trie depends on cl-irregsexp (https://github.com/vii/cl-irregsexp), which has no explicit license.
<PurpleSym>No explicit license means non-free and thus not eligable for addition to Guix, fcw. You could try to open an issue and ask the author to clarify his intentions.
<PurpleSym>(Actually, there is https://github.com/vii/cl-irregsexp/issues/1 already)
<M6piz7wk[m]><PurpleSym> "No explicit license means non-..." <- I would argue for unlicensed so that anyone can just fork and set their license on the repo as the original author failed to provide any authorization that the code is their
<M6piz7wk[m]>I did this to Terraria modders they were furious, but had to adapt GPLv3 after I did it :p
<M6piz7wk[m]>*not a legal advice*
<fcw>M6piz7wk[m]: I don't think that's how it works.
<M6piz7wk[m]>Why not? As an author you have to prove that you created the thing.. if you fail to do that then its generally considered as unlicensed project free to grabs o.O *not a legal advice*
<fcw>M6piz7wk[m]: Really? Which country are you from? That is a completely new concept to me.
<abrenon>good morning guix
<M6piz7wk[m]><fcw> "6piz7wk: Really? Which country..." <- czechia.. it's not a legal advice because the original creator has lot of ways to prove that they are the copyright author though
<M6piz7wk[m]>so.. lets poke~ https://github.com/vii/cl-irregsexp/issues/2
<fcw>PurpleSym: I wonder if the lack of response is because the author works for Google. Maybe there's some kind of clause in the employment contract that complicates open source work? I am not familiar with these copyright stuff.
<M6piz7wk[m]>and i gave left them a lot of ways to prove that they own the copyright to the code..
<M6piz7wk[m]>So going through this legally would probably mean lose for me, but poke's a poke :p
<M6piz7wk[m]>So i guess you can package my fork in the meantime?
<fcw>The other way to solve the problem is to patch cl-tries, so that it no longer depends on cl-irregsexp.
<jonsger>it seems like the c-u-f hacking day was a success :)
<PurpleSym><fcw> "PurpleSym: I wonder if the..." <- I don’t have any insight into Google’s policies, but thought they were quite liberal with that. Probably just lack of time/motivation.
<abrenon>jonsger: so what happened ? did it get finally merged ?
<jonsger>no, but my substitute server has more successful builds on c-u-f :)
<abrenon>great ! : )
<abrenon>that's an excellent way to track improvements
<PurpleSym>6piz7wk: Seriously? You’re not going to solve the license issue this way…
<abrenon>wait, so people (at least, you) have substitute for development branches ?
<rekado>M6piz7wk[m]: why do you have to be so confrontational? I think I’d rather not interact with you any longer.
<M6piz7wk[m]><PurpleSym> "6piz7wk: Seriously? You’re not..." <- How else? :p
<M6piz7wk[m]><rekado> "6piz7wk: why do you have to be..." <- bcs being non-confrontational is boring and leaves people with undesired options :P
<M6piz7wk[m]>also keep talking to me u.u
<PurpleSym>6piz7wk: As fcw suggested the way to go would be to remove the dependency on this package to avoid it.
<M6piz7wk[m]>also i need more practice with law in copyright/licensing area so this is quite beneficial exercise and anyone could in theory do this and use non-free license
<M6piz7wk[m]>PurpleSym: reinventing the wheel meh
<vivien>Hello guix, I’ve spent the night building ghc-x509-validation, is it a bug?
<vivien>(it’s still building)
<PurpleSym>vivien: On master or c-u-f?
<vivien>c-u-f
<abrenon>M6piz7wk[m]: being non-confrontational is also what allows a community to find harmony and a common base to go forward
<M6piz7wk[m]>from my experience being confrontational is more efficient in finding common base to go forward e.g. what FSF and it's supporters did with returning windows keys in the 80s or protesting in front of an apple store recently
<PurpleSym>vivien: It builds fine on master. Let me check…
<vivien>The test suite seems blocked
<jpoiret>alright, just got up, hello everyone (didn't sleep well because of polkit)
<PurpleSym>6piz7wk: You’re not being confrontational, you’re simply being a dick.
<PurpleSym>vivien: Works fine for me on x86_64.
<vivien>Mmh
<jpoiret>samplet: here is the definition i'm using (i'm grafting elogind with it so that I don't have to rebuild everything)
<vivien>PurpleSym, are we talking about /gnu/store/dx0xrqv3awmv9wpdr2s03l50jxq8cx4v-ghc-x509-validation-1.6.11.drv?
<jpoiret> https://paste.debian.net/1220033/
<vivien>I see no substitutes
<jpoiret>jackhill: the thing is, I can't actually get sway/wlroots/seatd to work because of the polkit issues
<PurpleSym>vivien: Yep, that one just built fine for me. /gnu/store/mh2k0vfpj1z3b88dvkf7bhza7y71ykl2-ghc-x509-validation-1.6.11
<rekado>finally built my system successfully on c-u-f! First time since commit 258bbc4fdcc8a0538c9b151d5a8e82a82092a3cb
<jpoiret>sneek, later tell samplet: i'm using https://paste.debian.net/1220033/ and grafting elogind with it so that i don't rebuild everything (it shouldn't change the ABI iirc)
<sneek>Will do.
<vivien>PurpleSym, so maybe that’s a bug? How can I gather more information with haskell tests?
<rekado>(that was a month ago)
<vivien>It hangs reproducibly on my side
<M6piz7wk[m]><PurpleSym> "6piz7wk: You’re not being..." <- depends on the interpretation of the wording and it's consequences 🤔 I don't think i mean any wrong doing as the projected end result is avoiding reinventing the wheel in guix packaging
<abrenon>there doesn't seem to be anything specific on this package
<abrenon>it uses exitcode-stdio test mode with cabal
<abrenon>probably you could patch the test to add debug directly ? https://github.com/vincenthz/hs-certificate/blob/master/x509-validation/Tests/Tests.hs
<PurpleSym>vivien: Hm, I don’t think we have a switch to make testing more verbose for Haskell packages :(
<vivien>abrenon, I don’t know haskell, I think I’ll open an issue and if someone wants me to test a patch adding more debugging I’ll do it
<abrenon>ok
<abrenon>on the other hand, sorry, my remark was probably useless, I tend to rely too much on the source itself because I'm not proficient enough with guix
<abrenon>but since it builds on master…
<abrenon>^^'
<rekado>M6piz7wk[m]: you won't get away with framing your behavior as noble. As far as I’m concerned we’re not operating on the same foundations. I only help and socialize with people who act in good faith.
<vivien>Suspiciously, the hang only happens on the machine that boots with a message about rdrand giving spurious warnings and that I should boot with nordrand…
<vivien>Maybe there’s funny stuff involved here…
<abrenon>hmmm you mean it's not reproducible elsewhere ?
<civodul>Hello Guix!
<sneek>civodul, you have 2 messages!
<sneek>civodul, zimoun says: on machine A, julia builds. On machine B, fails at test LinearAlgebra/test/matmul.jl:155.
<sneek>civodul, apteryx says: haha! I got the zombie reaping thing going by forking, calling my new (set-child-subreaper); and invoking the test by (execlp "tini" "--" ...)
<abrenon>hi civodul
*abrenon is still slower than sneek : (
<jpoiret>hi civodul!
<vivien>abrenon, I have 2 machines running guix, and this build fails only on this machine with rdrand warning
<vivien>Maybe that’s unrelated
<abrenon>Oo
<rekado>jackhill: your patch looks good to me
<abrenon>but worth a try in any case
<rekado>(the python-libvirt upgrade))
<vivien>I’ll first try to build ghc-x509-validation on master with the sus machine
*rekado builds pytorch to check the GUIX_PYTHONPATH change
<abrenon>I have students project to correct (and I have never built anything from c-u-f <- that looks scary)
<jpoiret>inspecting dbus, something is trying to reach ConsoleKit, but I don't know what. What's even weirder is that Polkit itself is being used
<vivien>Also ghc-tls seems to have a similar problem
<vivien>I’ll try to reboot with nordrand
<vivien>Also why does linux even think it can use rdrand? I’m not running an intel CPU, so no wonder it does not produce anything.
<mothacehe>hey guix!
<abrenon>mothacehe: o/
<M6piz7wk[m]><rekado> "6piz7wk: you won't get away with..." <- b-but my behavior is always noble in some way u.u
<civodul>howdy mothacehe!
<civodul>mothacehe: sorry to bother you early in the morning :-), but i wonder if you have thoughts about https://ci.guix.gnu.org/eval/45343?status=failed
<civodul>when clicking on a given build, we get a blank page
<civodul>the cuirass-web log shows it's because the build alist lacks a status
<mothacehe>mmmh yeah, i think i know the reason. Those builds where created by the c-u-f-b-c specification.
<mothacehe>which has been deleted
<civodul> https://web.fdn.fr/~lcourtes/pastebin/cuirass-web-backtrace.html
<civodul>ah, i see
<mothacehe>i guess we should not delete the specification but set an active boolean to false
<mothacehe>meanwhile, we can trigger a full reevaluation of the c-u-f branch
<civodul>that would be great
<civodul>i can try that
<mothacehe>i already did it but i'm not exactly sure how
<civodul>ah ok, just did "Retry the evaluation" on #45463
<jpoiret>watch me struggle with substitutes-keyword-arguments
<jpoiret>although i'm confident I found the issue with polkit on c-u-f
<civodul>that's not the prettiest interface...
<civodul>there's an issue with polkit?
<Guest3474>Does anyone know if a Guix System live ISO exsists so that I can test if my hardware works with Guix without needing to install it?
<civodul>Guest3474: hi! you can try the installation ISO, check if networking works, etc.
<civodul>you can stop before it proceeds with partitioning and all
<civodul>and you can jump to a console to try things out
<fcw>civodul: I get "Échec de la connexion sécurisée".
<Guest3474>Ok civodul, I will do that, thanks for the info.
<fcw>With HTTP (http://web.fdn.fr/~lcourtes/pastebin/cuirass-web-backtrace.html), I get 404.
<civodul>fcw: yeah it looks like something's wrong with their certificate :-/
<mothacehe>civodul: i'm running "delete from builds where id in (select build from jobs where evaluation = 45343);", we can then retry the evaluation
<mothacehe>
<jpoiret>civodul: yes, polkit seems to to use ConsoleKit for sessions rather than elogind
<jpoiret>i'm grafting it right now to see if that fixes it
<jpoiret>elogind and polkit will have to be changed on master, so some recompilations will be needed (qt/gtk/all that stuff)
<jpoiret>s/master/c-u-f
<civodul>woow
<civodul>wasn't ConsoleKit phased out years ago?
<jpoiret>yes, but apparently it's still able to use it
<jpoiret>the weird thing is that, looking at configure.ac, it's supposed to use elogind if it finds it, but alas
<rekado>on c-u-f we still have a problem with python-notebook
<jpoiret>although grafting it just now doesn't solve the issue. still calls to consolekit are made
<rekado>it would, of course, be possible to disable the broken tests, but I feel that they point to a real problem.
<civodul>rekado: i'll see if i can take a look today
<vivien>So, c-u-f is not usable right now?
<jpoiret>not really
<jpoiret>can't use nm-applet for example
<vivien>Thank you
<civodul>jpoiret: apparently samplet just pushed a fix for polkit
<civodul>looks like it's addressing the same issue, right?
<jpoiret>oh, great!
<jpoiret>i was just using the --enable-libelogind configure flag, blindly thinking that a project as serious as polkit had working configure scripts in their releases
<civodul>heh
<zimoun>why “guix build bootstrap-tarballs” contains Guile 3? Other said, I though Mes was the Scheme interpreter. If the bootstrap uses Guile, why Mes is required? And vice-versa. :-)
<civodul>zimoun: it's complicated: Mes isn't used yet to run the build code (guix/build/gnu-build-system.scm and all that)
<civodul>the plan is to eventually use Mes instead of Guile for the early packages
<zimoun>Ah ok, so the story Guix is bootstraped with Mes+MesCC is not entirely true. In fact, it is bootstrapped with variant of Guile+MesCC. More some tools (sed, bash and friends). Right?
<jpoiret>even worse, this is a 3 year old bug on their issue tracker with a proposed one line fix from day one. what a joke
<jpoiret>did we always have such a patch?
<rekado>zimoun: no, the story is true. It’s just that the *convenient* and automated way uses Guix.
<jpoiret>great, this works for me civodul! I could finally start sway and use nm-applet
<zimoun>rekado, I do not understand if «Mes isn't used yet to run the build code» and Guile is instead. IIUC, a first Guile has to be trusted thus.
<Guest58>how do i change the default substitutes server to get a better internet speed
<Guest58>default server is slow af
<rekado>it’s not the server, but the connection to the server.
<rekado>apparently some ISPs have really poor connection to it. It’s very odd.
<Guest58>:(
<Guest58>i get 16mb/s on other programs
<Guest58>but 1.5mb/s tops on guix
<Guest58>its a pain waiting for packages like latex to download lol
<jpoiret>you can use `mtr` to see if there's any packet loss along the way
<rekado>re latex: I strongly suggest trying to make do with the modular texlive packages, and to forget that the “texlive” package exists.
<rekado>I get slightly better speeds than 1.5mb/s on average, but my connection and hardware is pretty slow.
<rekado>I’d be happy if network engineers with plenty of time would be willing to join the Guix sysadmins to make sure we aren’t doing anything silly on ci.guix.gnu.org
<rekado>it’s entirely possible that we did something stupid and aren’t able to see just how stupid it was.
<rekado>that said: I think my colleagues at the MDC haven’t done anything silly — not in the physical patching of cables, nor with data centre networking.
<jpoiret>now that i've got the hang of elogind/dbus/polkit shenanigans, ill look into why gdm won't let you shutdown
<jpoiret>iiuc the shutdown operation is restricted to administrative users, but then we should be able to authenticate them for that operation on the gdm login screen (or do other distros just let anyone shutdown?)
<rekado>this has been a problem since I upgraded a month ago.
<jpoiret>oh, this wasn't the case before?
<rekado>shutdown just silently won’t do anything
<jpoiret>elogind changed how it handles shutdown requests though
<rekado>well, a month ago I upgraded my system to c-u-f
<rekado>on the master branch it all works fine
<jpoiret>i'll be doing some testing then
<rekado>I don’t know if it ever worked on c-u-f
<rekado>excellent, thank you!
<jpoiret>i've been running on c-u-f for so long, i don't remember what master feels like
<jpoiret>:)
<rekado>I’ve been on c-u-f for a month now — but I’ve never shut down :)
<jpoiret>why aren't there any new evaluations on c-u-f? I'd need substitutes for the polkit patch
<jpoiret>here i've just been grafting things left and right to test
<jpoiret>don't just evaluate now though, i'll send a patch of elogind as well which will rebuild roughly the same things
<rekado>jpoiret: don’t know, but I can run a build manually on ci.guix.gnu.org if needed
<jpoiret>no worries
<KE0VVT>Right now, on Fedora, Guix will only work for my user. Something with SELinux and the files in /gnu/store/.
<KE0VVT>The workaround was to only let my user run Guix Daemon. Otherwise, it would not run.
<KE0VVT>I am very tempted to turn off SELinux.
<rekado>the SELinux stuff has not been maintained since I first wrote it.
<rekado>I would not expect it to work with a current Fedora
<rekado>if you’re adventurous I’d be happy if you would like to hack on it and bring it up to date.
<KE0VVT>rekado: Fine, I'll turn off SELinux. :-(
<rekado>I know, this doesn’t feel good
<KE0VVT>rekado: I can't even package linux-libre, let alone mess with SELinux policy files.
<rekado>among us admins at work I was the last to turn off SELinux, but I had to because nobody else bothered fixing problems when SELinux complained…
<rekado>these two things are *very* different and require different skills.
<rekado>SELinux is actually not too complicated. It’s mostly a matter of making it permissive and observing messages in the audit log.
<KE0VVT>rekado: Do you use RHEL at work, or something?
<rekado>yes.
<rekado>well, I used Fedora on my workstation, and we use CentOS / Rocky / RHEL on different servers.
*jonsger too, and their installer is kind of awful...
<rekado>but my workstation has now become nothing more than an SSH gateway
<rekado>I haven’t touched fedora in years.
<KE0VVT>I like Fedora. It's clean, fresh and mainstream. I use Guix so regular users can install packags easily for themselves.
<KE0VVT>And to avoid proprietary repos.
<rekado>I liked Fedora, too.
<rekado>very few problems with it
<KE0VVT>On my machine, Guix System is not bad, but it presents a TTY login prompt for ten seconds and then interrupts it, once it finally loads GDM.
<rekado>the “out of the box” experience is also pretty good
<rekado>KE0VVT: I’m working on it
<rekado>plymouth
<KE0VVT>rekado: Oh, so you are the one working on Plymouth. Very nice! It really adds polish to a system.
<rekado>I should post my WIP with open issues, because I feel I’ve been stuck for too long.
<rekado>one open issue is how to make it optional
<rekado>(it makes the initrd bigger and requires more memory when testing in qemu; it should be optional)
<rekado>jpoiret: “guix gc” is running again on ci.guix.gnu.org — and the build I requested waits for it to end.
<rekado>perhaps that’s why no other substitutes have become available yet?
<jpoiret>ouch, maybe yes
<jpoiret>i just send the patches, and so just committed to rebuilding gtk/qt/etc... myself
<jpoiret>KE0VVT, rekado: iirc we could disable that easily, last time i looked at it there's something about explicitely not disabling agetty on tty1 for some reason
<M6piz7wk[m]>any idea why is flameshot unable to access clipboard?
<M6piz7wk[m]>kinda need that functionality now x.x
<jpoiret>are you on wayland or xorg?
<M6piz7wk[m]>xorg
<M6piz7wk[m]>xfce4-screenshooter same issue
<civodul>would anyone know how to benchmark one of the packages shown by "guix graph -M1 -t reverse-package eigen | xdot -f fdp -"?
<M6piz7wk[m]>ah just can't paste in icefox
<M6piz7wk[m]>ehh icecat
<M6piz7wk[m]>works to gimp
<M6piz7wk[m]>weird but i guess that works for my usecase
<GNUHacker>have guix any httpd installed by default?
<rekado>GNUHacker: by default? No.
<GNUHacker>ok
<rekado>you can add nginx or apache (or lighttpd?) to your system config
<GNUHacker>apache is "httpd" package?¿
<M6piz7wk[m]>Does guix have any good math solver preferably from images or using input?
<M6piz7wk[m]>yes i am that lazy to do school
<M6piz7wk[m]>they are forcing me to do boring things
<M6piz7wk[m]>basically mathpix but more libre https://alternativeto.net/software/mathpix-snip/about/
<ekaitz>hi! is squashfuse packaged somewhere I'm missing?
<rekado>is this related to squashfs-tools, perhaps?
<ekaitz>i tried to include that but it didn't appear
<ekaitz>sounds weird to me that we don't have it because it's a debian package
<ekaitz>and i don't think it's a very complex one
***smartin1 is now known as smartin
<rekado>could be that nobody needed it so far. Want to package it?
<notmaximed>sneek: later tell roptat: Use raise-continuable instead of raise
<sneek>Got it.
<notmaximed>sneek: later tell roptat: However, there is rarely a need for continuable exceptions
<sneek>Will do.
<ekaitz>rekado: I'm working on something else and I may need to so I may package it then
<notmaximed>sneek: later tell roptat: So if you probably just need to escape the exception handler
<sneek>Will do.
<notmaximed>sneek: later tell roptat: E.g. with escape continuations or by throwing another exception
<sneek>Got it.
<ekaitz>also cmake is killing me saying that it's unable to find xdg-utils and stuff like that and I may give up
<notmaximed>sneek: later tell roptat: (AFAIK guard* is for continuation or better stack traces, I presume you want the latter)
<sneek>Okay.
<rekado>ekaitz: remember to pet the yak before you take out the scissors!
<ekaitz>rekado: haha yeah... i'm just trying to package libappimage
<ekaitz>all this cmake scripts that download code from the internet are killing me
<jpoiret>civodul: do you know enough about guile internals to see if we could pass whole syntax objects in the builder, to get back traces from where they're defined in the guix sources? although that may reduce the builder's performance
<rekado>ekaitz: you’re not alone. It’s a drag having to patch cmakelists.txt files to undo the damage.
<notmaximed>jpoiret: Possible problem: rebuilds would be needed if line numbers change. Possible work-around:
<notmaximed>only use syntax objects if requested (e.g. --with-backtraces=some-package and(package (arguments `(#:backtraces #true)) ...))
<notmaximed>The G-exp code would need to be modified to include position information
<jpoiret>that would look like a good compromise imo
<notmaximed>And package definitions would need to be changed to use G-exps (#:phases #~(stuff ...) instead of #:phases (stuff ...))
<jpoiret>yes, that's also why I was thinking about that, moving phases to gexps
<jpoiret>well, rather than that, isn't the whole argument supposed to be moved to a gexp?
<notmaximed>sexps can be used in most contexts were gexps are expected
<notmaximed>(but not the other way around)
<notmaximed>so it's currently done on a as-needed basis
<jpoiret>i don't know if the argument field is deconstructed before being "sent to the builder"
<notmaximed>jpoiret: the arguments field is deconstructed by (guix build-system ...)
<jpoiret>because here we can lookup keywords and such easily, whereas i don't know if that's the case in a gexp
<rekado>civodul: what do you think: should we kill ’guix gc’ on ci.guix.gnu.org again?
<notmaximed>only parts of the argument field are used as G-exps, not the argument field as a whole
<jpoiret>nice, that basically answers the question i had in mind!
<notmaximed>Another potential issue to consider: more position information --> guix uses more memory
<jpoiret>hmmm, maybe it's not that great of a feature then
<notmaximed>That could be mitigated somewhat by representing position information very efficiently (and not with syntax objects)
<jpoiret>currently, do we have good backtraces to the build scripts at least? I seem to remember that the scripts are eval'd rather than using read-syntax
<notmaximed>maybe pack them in a numeric (u16?) array or something
<notmaximed>jpoiret: backtraces for (guix build utils), yes, backtraces for build scripts, no
<jpoiret>oh, that's the thing then. I think it'd be a better middle ground
<notmaximed>read-syntax wouldn't (by itself) help, because the position information in the build scripts doesn't correspond to positions in package definitions
<jpoiret>yes but it would still report the position information in the build script which is readable
<jpoiret>maybe reporting the location in the guix package definition is a bit too ambitious
<notmaximed>readable, but not useful?
<notmaximed>though it would avoid all these eval etc. in the backtrace
<notmaximed>So seems like an improvement, though without useful position information.
<notmaximed>jpoiret: Ignoring #$, #$@ and #+ for now for simplicity, what about keeping a table from ((position of character in string encoding of G-exp) -> position in the source code) and compressing it?
<notmaximed>(with delta encoding)
<jpoiret>oh, pretty good! what do you mean by delta encoding though?
<jpoiret>maybe we could then extend the guile reader to use that information with read-syntax
<jpoiret>i'll look into making a MWE with these ideas (while qtbase is compiling)
<notmaximed>Consider the S-exp (G-exps are left as an exercise (-:)) (x y NEWLINE z)
<notmaximed>( has position (0,0), x has position (1,0), y has (3,0), z has position (0,0), ) has position (0,2)
<jpoiret>wouldn't that necessarily double the build script size?
<notmaximed>Putting that in an array (& including the spaces): [(0,0), (1,0), (2,0), (3,0), (0,0), (0,1)] (oops I gave the wrong position for )
<notmaximed>Delta encoding: don't use the number, but the current number minus the previous number:
<notmaximed>(0,0) [(1,0), (1,0), (1,0), (-3,0), (1,0)] (oops I again gave the wrong position for ))
<notmaximed>To reduce space, represent it in some binary form
<notmaximed>The idea is to somehow map the indentation in the build script to the indentation in the original code
<jpoiret>i don't think it'll mix well with macros on the guix-side
<notmaximed>And build script size isn't much of a problem because of the explicit --with-backtraces=... or #:backtraces #t, it's the memory usage of guix that is
<notmaximed>jpoiret: macros expanded in the builder, not in guix
<jpoiret>mhmmm, maybe we could somehow already pack the syntax object themselves and have guile use them instead of parsing
<notmaximed>Anyway, I don't see the problem.
<jpoiret>notmaximed: example: `(helllo ,(symbol-append 'where-should-this-be 'i-wonder))
<notmaximed>jpoiret: Do you mean #~(hello #$(symbol-append 'this 'that))?
<jpoiret>yes, i was just following your example
***wielaard is now known as mjw
<notmaximed>I think the #$(symbol-append ...) part simply won't have position information
<notmaximed>Same thing as in pure guile-without-gexps macros
<notmaximed>That's more procedures than macros, I think? The only macro is #~ (+ #$)
<notmaximed>Different example: (let ((stuff #~world)) #~(hello #$world))
<notmaximed>Or more interesting: (let ((stuff #~world)) #~(hello #$world !))
<notmaximed>The G-exp code can find the location with syntax-source and record it (at expansion time), but I'm not sure about how to represent it
<notmaximed>and how to combine conventional sexp + position information back into a ‘special sexp with modified position information’
<jpoiret>well, can't we just pack the whole syntax object?
<jpoiret>it should contain everything
<notmaximed>jpoiret: What do you mean, exactly? Record the syntax object in the G-exp object?
<jpoiret>nono, just pass the syntax object to the builder script, rather than the code itself
<jpoiret>so guile won't parse the code but rather use an already parsed syntax
<jpoiret>which will then contain the info we want
<notmaximed>Where do you get the syntax object from, then?
<jpoiret>one problem i see this early would be a possible guile-for-build mismatch with the syntax format
<notmaximed>If you don't record it when the G-exp object is created.
<jpoiret>well you can just record it when the g-exp is created
<jpoiret>but hang on, we can just talk about s-exps instead, this is the same behaviour
<jpoiret>instead of having the raw s-exp, you could just have an object that is the syntax of parsed s-exp
<notmaximed>The problem with that (recoding the syntax object when g-exp is created) was that syntax objects cost a lot more than s-exps
<notmaximed>(memory usage)-wise
<jpoiret>mhmmm, yes, i agree, although we could pack them i think
<jpoiret>and memory-usage wise, guile has to create them anyways if it's reading code
<notmaximed>guile has to create them anyway, but only when (gnu packages ...) stuff is being compiled, and not at run-time
<jpoiret>ah yes, so the problem would be with the size of the gnu/packages/*.go instead
<jpoiret>i understand
<jpoiret>i'll try to do a PoC still, i'm interested
<notmaximed>‘we could pack them’ --> my proposal basically was representing syntax objects (without the extra information for lexical transparancy, only S-exp + positions) in a very efficient matter
<notmaximed>Ideally, all the position-related part would be represented as some kind of numeric array (or a string, I suppose), because those could go in the read-only part of the .go
<notmaximed>and don't need relocations
<notmaximed>Whereas a tree structure like (this (that ...) (p q) ...) would need relocations
<notmaximed>Keep in mind that if you work with a syntax object, it will need to be serialised & deserialized somehow to be sent to the builder.
<jpoiret>yes... i'll try looking into the definition of the syntax object, that'll give us hints as to what is needed
<robertp>Hi. I'm a Guix System user, and I'm trying to manage my homedir config files. I can see `guix home` could do this, but ideally I'd be able to manage these via my /etc/config.scm (for the transactional rollbacks). I can't see how to do that. Is it possible?
<jpoiret>iiuc guix home also has rollbacks
<jpoiret>see `guix home list-generations` and `guix home switch-generations`
<civodul>rekado: i think it's the 4AM gc process we're seeing (!)
<robertp>Yes, though I'd prefer to avoid introducing a second deploy/rollback mechanism.
<civodul>rekado: according to /var/log/mcron.log it's at 90%, so i'm tempted to let it run to completion; it's the one that'll trim entries from /gnu/store/.links i believe
<civodul>it's now in the "rm -rf trash" phase
<nckx>Morning Guix! :)
<civodul>o/
<nckx>How'd the hackofest go?
<nckx>Wow, if #guix content generated is an indicator: exceedingly well.
<civodul>i'd say it went well!
<nckx>Yay!
<civodul>judging by the number of commits and issues fixed, that's quite good
<civodul>now we need to go past the finish line
<vivien>I still have a couple of issues, 51948 and 51956
<civodul>and we've never been this close
<civodul>vivien: ah!
<civodul>lemme see
*nckx starts building c-u-f.
<jlicht>I still see the "error: integer expected from stream" when trying to build texlive /w substitutes enabled on c.u.f. Is this something that I can address on my end?
<nckx>Sigh. M6piz7wk[m]: Stop. Trolling. Consider this your last warning here or whatever. I'm tired of dealing with the community unease you generate for no reason. Your behaviour is so counterproductive I don't understand why you haven't been corrected out of it yourself, but it's not our full-time job to do so.
<nckx>jlicht: Is this a specific URL?
<vivien>civodul, for meson I posted an update that put it in a variable named meson-wrapped
<jlicht>nckx: Could you clarify what you are asking for? It seems to wrong with something on ci.guix.gnu.org, if that is what you are asking :)
<nckx>Right. I meant if it was a particular server (seems so) and specific nar, reproducibly, or if it seems random.
<nckx>‘Is there a cursed nar I can download’ basically.
<nckx>(As I don't use ci.guix myself.)
<civodul>jlicht: i suspect this has nothing to do with the branch, but rather something with your daemon, no?
<jlicht>civodul: Maybe? I'll try to reproduce on another (much slower) machine. Is there some nar(info) cache I can clear locally?
<jlicht>I also doubt it has anything to do with the branch, but from searching the archives, last time this error popped up it seemed something went wrong on the server (a broken/corrupted narinfo? just cargo culting here)
<nckx>You could try --max-jobs=1 and it should print each URL before the error it generates. Unless they were hidden in the great substitute URL hiding. Then, maybe, ‘guix system build’ will show them, analogous to how ‘guix install’ hides but ‘guix build’ shows substitute URLs.
<jlicht>It crashes before getting to that: https://paste.debian.net/1220051/
<nckx>Huh.
<jlicht>glad I'm not missing something superobvious, at least :P
*nckx puts on their C++ spelunking helmet.
*nckx and nose clip.
<nckx>Seems to be a local substituter protocol error?
<jlicht>I seem to be able to reproduce it on another machine as well :/
<jlicht>as if I needed more reasons to stop using monolithic texlive
<nckx>OT: which project was it that used successive approximations of π as its version number? font-adobe-source-code-pro seems inspired by it.
<jlicht>tex, actually
<zimoun>civodul, I am always confused with Cuirass. How can I get the log if any of julia? See if it is another error than yours and mine.
<roptat>hi guix!
<sneek>roptat, you have 5 messages!
<sneek>roptat, notmaximed says: Use raise-continuable instead of raise
<sneek>roptat, notmaximed says: However, there is rarely a need for continuable exceptions
<sneek>roptat, notmaximed says: So if you probably just need to escape the exception handler
<sneek>roptat, notmaximed says: E.g. with escape continuations or by throwing another exception
<sneek>roptat, notmaximed says: (AFAIK guard* is for continuation or better stack traces, I presume you want the latter)
<sailorCat>Hi there. What can I do with 'Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS'?
<roptat>I figured raise-continuable worked. There's no point in raising another exception, the goal is to print a warning and return #f
<abrenon>hi roptat
<florhizome[m]>I sent an email to bump this a week ago, what are the chances it gets picked up again since nothing happened since then? http://issues.guix.gnu.org/49969
<roptat>I have no idea what's an "escape continuation", and the manual is really not helpful when it discribes continuable stuff
<roptat>what does that even mean: "the handler is invoked in tail position relative to the raise-exception call", I don't know half the words in this sentence
<abrenon>sailorCat: it certainly depends on whether it's expected or not (i.e. if you're running something that you know may legitimately recurse a great number of time or if you're only running something you expect to run out of the box on some reasonably sized input data)
<civodul>zimoun: the easiest way to get a log is "guix build PKG --no-grafts --log-file"
<abrenon>"escape continuation" : isn't that a function you pass for something that is going to loop so that it knows what to run next once it's done ?
<abrenon>I read a post about iterators comparing python and scheme recently which used stuff like that
<civodul>zimoun: alternatively you can construct the URL, like https://ci.guix.gnu.org/log/n8awazyldv9hbzb7pjcw76hiifmvrpvd-coreutils-8.32
<abrenon>roptat: I think "the handler" and "escape continuation" are coreferent in this situation
<roptat>abrenon, I think I need to learn more about continuations
<nckx>When docs make you use the word coreferent they are very good docs. /s
<roptat>so, as I was completely clueless, I just figured that &non-continuable meant I needed to raise a continuable exception, whatever that means, so used raise-continuable, which ludo didn't like, and I'm just as clueless as before (:
<florhizome[m]>I see gdm gets fixed in c-u-f but greetd is a good and clean alternative. as far as I understand the commit also leverages a new service configuration list without elogind. That’s win-win-win to me...
<abrenon>hmmm sorry, probably it has a meaning in comp.sci. too ? I meant they refer to the same concept ? as in "the handler" in second sentence is a phrase that means the same as the "escape continuation" from the previous one
<zimoun>civodul, from local log file, how do I construct Cuirass URL?
<roptat>I think I understand "the handler" is the exception handler, so the code that runs when an exception occurs
<abrenon>yes, that !
<roptat>but then what does it mean to run in tail position?
<sailorCat>abrenon: I'm going to build a package, that requires tones of derived packages, that requires tones of derived packages. So, roughly few hundred packages in total. Perhaps that's a lot but I have a mighty PC with 16Gb RAM, so I don't think it can't calculate because of resource limitation.
<abrenon>isn't that a stack-optimisation compiler stuff ? like it says it doesn't need to push a new function frame on it ?
<roptat>abrenon, that's the documentation for "#:continuable? #t"
<abrenon>(a bit like "tail recursive" ?)
<roptat>I don't think it's only compiler optimisation stuff, as it does have a different effect
<abrenon>hmmm ok
<abrenon>where is that ?
<abrenon>in the guix manual ?
<roptat>if it's in tail position, it doesn't raise &non-continuable, otherwise it does
<roptat>in the guile manual
<roptat> https://www.gnu.org/software/guile/manual/html_node/Raising-and-Handling-Exceptions.html
<roptat>well, maybe the "otherwise" part is more important
<roptat>well, I'll just ask on #guile
<awb99>building /gnu/store/p0i1fgjhd5sdypr256llpk2vsgbx90hc-switch-to-system.scm.drv...
<awb99>guix system: error: symlink: Permission denied: "/var/guix/profiles/system-36-link.new"
<awb99>I just tried to rebuild my system.
<awb99>And I got this error.
<awb99>I ran my build script with sudo.
<awb99>So this error should not happen.
<awb99>Any ideas?
<abrenon>roptat: hmmmm : / yeah that's clearly too mysterious for me
<roptat>basically, this is what I tried: (define-condition-type &my-error &error my-error?) (guard* (c ((my-error? c) #f)) (raise (condition (&my-error))))
<roptat>and it raises &non-continuable instead of returning #f
<roptat>I know the handler is called, I can make it print c
<abrenon>roptat: according to the manual, that would be because you didn't set the continuable flag to #t
<abrenon>s/raise/raise-exception/ ?
<roptat>right, but then civodul told me there was no reason to use raise-continuable
<nckx>awb99: Can you (as root) manually create a symlink in that directory?
<civodul>awb99: more generally, "guix system reconfigure" needs to run as root
<awb99>yes
<abrenon>sailorCat: well then you can possibly try and increase those environment variables ? aren't those mono stuff ?
<awb99>I did exactly that.
<awb99>I did run the same command multiple times in the past. There are lots of symlinks in that directory.
<awb99>I wonder if there is a difference between su and sudo ?
<sailorCat>abrenon: any ideas what would be a good values for them?
<abrenon>no, sorry, I'm not really familiar with mono : (
<sailorCat>ok, I'll try to take a 128 and double it until something happens
<nckx>Mono?
<nckx>awb99: Oh, does your script/guix system reconfigure work with su but not with sudo?
<abrenon>nckx: aren't those variables linked to that language ?
<abrenon>all I found searching for them was mono-related
<nckx>Which variables? Hence my curiosity, I didn't see anything Mono-related above.
<abrenon>is that only because it's more prone to heap consumption ?
<abrenon>MAXHINCR or MAX_HEAP_SECTS
<sailorCat>and FYI I'm building a go package.
<awb99>so I did "touch demo.txt" in /var/guix/profiles/" and it worked.
<awb99>very bizzare.
<abrenon>ok, my bad
<nckx>abrenon: They control the Boehm GC library (libgc).
<nckx>I guess it's also used by Mono.
<nckx>But in the context of Guix, most likely Guile.
<abrenon>ahhhh thank you
<nckx>awb99: There's no stale /var/guix/profiles/system-36-link.new in there? And can you create a symlink called /var/guix/profiles/system-36-link.new pointing to /gnu/store/something?
<nckx>Not that I have a clue what could cause this.
<notmaximed>sneek: later tell roptat: (let/ec escape (guard* (... from the exception handler, call (escape 'oops) at the end) stuff))
<sneek>Okay.
<roptat>thanks
<sneek>Welcome back roptat, you have 1 message!
<sneek>roptat, notmaximed says: (let/ec escape (guard* (... from the exception handler, call (escape 'oops) at the end) stuff))
<notmaximed>will return ‘oops’ in case of an exception
<roptat>where's let/ec defined?
<vivien>ice-9 control
<roptat>oh, that works, thanks!
<apteryx>clutter + cogl test suites of mutter are now passing in the build container :-)
<awb99>nckx: I only touched a file. I am too afraid that with making a symlink, I will fuck up the system.
<awb99>As I dont know if it depetes the other directory.
<awb99>I am very afraid to even go into this directory as root.
<awb99>hahah
<apteryx>perhaps you could use a throwaway VM as a playground for dangerous things
<nckx>You wouldn't fuck up anything, and you'd also immediately delete your new symlink.
<nckx>But better too cautious than too cavalier, I agree.
<rekado>civodul: guix gc completed. Let’s hope this removal of small files improves future runs!
<civodul>rekado: it's right in the "deleting unused links" phase now
<civodul>next time that part should be ~70% faster, but the whole operation remains expensive
<zimoun>civodul, yeah still expensive. Well, I do not know if adding a guard as I suggested would fix for “guix gc -D”.
<civodul>zimoun: i don't think so, unfortunately
<apteryx>zimoun: sorry, I'm not following the "adding a guard" idea? Seems you are suggesting the change of my original patch in 51427?
<civodul>that's my understanding
<apteryx>to which civodul objected that it wouldn't reap any disk space due to not touching the links
<apteryx>(which is a valid objection to have)
<apteryx>although perhaps we could add a new flag --skip-links-cleanup or similar, documented with a warning that it only touches the store, not disk space
<civodul>if the use case is just to invalidate a store item, we could have "guix gc --invalidate ITEM"
<apteryx>yeah, that would be useful when coping with corruption bugs
<civodul>though i wonder to what extent --check would fit the bill
<apteryx>sometimes people report corrupted items on berlin
<civodul>oh?
<civodul>recently?
<apteryx>not recently I think, but it happened
<civodul>ok
<nckx><guix gc --invalidate ITEM> Good idea, ask users to be more explicit about which side-effect they care about, so we're not eternally bound to preserve all of them.
<apteryx>and we have an easy way to produce such items with #51400
<apteryx>:-)
<civodul>d'oh!
<apteryx>that was the motivation to have a quick 'guix gc --invalidate' in my case
<zimoun>apteryx, yes. But your guard (remove GCOptions::gcDeleteSpecific) should not fix my issue, i.e., bypass the phase for few elements. I think adding the guard if (options.maxFree >0) should bypass the phase for few elements.
<apteryx>ah, so you want a 'guix gc --invalidate one two three', I see
<florhizome[m]>Is search paths/native search paths only affecting build or also runtime search paths?
<notmaximed>Both.
<nckx>florhizome[m]: ‘Run-time’ through Guix profile activation.
<notmaximed>IIUC, search paths don't make a distinction between "guix shell -D" usage and "guix build stuff" usage
<zimoun>I do “guix build foo -S” and check stuff (SWH and friend); then I want to delete this specific item. And run again “guix build foo -S”.
<florhizome[m]>Oh so it couldn’t access other profiles as well?
<notmaximed>Not sure what you mean?
<notmaximed>Do you mean nesting environments? ~/.guix-profile on top of stuff in the operating-system?
<zimoun>Now, I just do “guix gc -D $(guix build -S foo)” and hit ^C^C at deleting ununsed links phase because I cannot wait each to transfer all. Even if it is reduced to 70%. :-)
<notmaximed>guix shell stuff -- guix shell more-stuff -- ...?
<nckx>zimoun: Wouldn't an ‘--invalidate’ option fit your bill?
*roptat is on a bug closing streak :)
<roptat>(hopefully that's the right expression ^^')
<zimoun>roptat is starting early the «Advent calendar» bugs squashing ;-) https://lists.gnu.org/archive/html/guix-devel/2020-12/msg00001.html
<roptat>I'm just closing bugs that aren't bugs anymore :)
<zimoun>nckx, yeah probably. I am not sure to understand what ’invalidate’ an item concretely means. So yes
<zimoun>roptat, hehe! that’s count ;-)
<notmaximed>zimoun: delete from store (both /gnu/store & the database) I think
<nckx>Nor I, zimoun, I'm just guessing from context. The other interpretation I could see is not even deleting /gnu/store/hash-foo but only removing it from the DB, but that sounds like it could introduce subtle bugs/unexpectations.
<notmaximed>nckx: For the other interpretation, there appear to be code paths in the daemon that will delete /gnu/store/hash-foo in that case before building, but it would be surprising to the user (looking like guix gc --invalidate doesn't do anything)
<nckx>Yeah, i see those code paths more as robustness against unexpected failures than meaning we can be this ‘lazy’ during regular operation.
<zimoun>I would delete the item /gnu/<hash>-foo but not traverse .links. Basically do a clean ^C^C on the «deleting ununsed links» phase. ;-)
<nckx>s/can/should/
<zimoun>roptat, I hope this year, we will see a real inflection https://debbugs.gnu.org/rrd/guix_5y.png ;-)
<nckx>zimoun: Yes. And hence that matches my interpretation of the (hypothetical, right?) --invalidate.
<roptat>mh yeah...
<roptat>what do the acronyms stand for?
<roptat>CR, IM, NO, MI, WI?
<vivien>I guess CR is for critical
<nckx>NOTABUG? NORWAY? Michigan is obvious.
<zimoun> https://debbugs.gnu.org/rrd/guix.html
<nckx>Great, I was just going to ask how you generated that.
<vivien>Also there are a lot of bugs on Instant Messaging programs i see
<zimoun>Emacs folks are doing a great job as cleaning their backlog https://debbugs.gnu.org/rrd/emacs.html
<nckx>Damn, I was really hoping the huge orange expanse were notabugs.
<florhizome[m]><notmaximed> "Do you mean nesting environments..." <- basically
<florhizome[m]>f.e. I install a compositor in the os profile, since it should be started from login but plugins as user; they communicate via some xml files in /share which need to be found.
<florhizome[m]>Or packages needing dbus interfaces set up by the DE.
<vivien>There are like 2 people that submitted more than 400 bugs in guix
<nckx>florhizome[m]: That is a know shortcoming of the current system IIUUC.
<nckx>*n
<zimoun>nckx, this graph is meaningful IMHO https://debbugs.gnu.org/rrd/guix-oc.png
<zimoun>and if you want more https://debbugs.gnu.org/rrd/guix-patches.html
<nckx>zimoun: What meaning do you take from it?
<florhizome[m]>nckx: well I’m trying to leverage everything I can find to get around it^^
<zimoun>nckx, it is getting worse because we are not closing. But it means more people open which implicit implies more people use Guix. :-)
<vivien>These graphs are cool, but they fail to show bugs that haven’t been discovered.
<zimoun>A undiscovered bug is not a bug. ;_)
<zimoun>:-)
<nckx>zimoun: Yeah… I'm not convinced it's getting worse, exactly.
<nckx>There is a lot of room for improvement though.
<notmaximed>It appears to me that we often forget to close fixed bugs(/applied patches).
<nckx>…the room between the two lines, I know 😛
<zimoun>nckx, the fact that the gap between red and green lines means it is getting worse, IMHO.
<nckx>I understand.
<florhizome[m]>Is the development usage of “wontfix” a change in behavior or in, say “protocol”?
<nckx>‘development usage’?
<florhizome[m]>*in
<florhizome[m]>Are people just not using that tag anymore, leaving stuff open they don’t want to fix, or are actually more requests being worked on like an intuitive guess could be
<nckx>But which change in usage?
<vivien>zimoun, I’m not sure. The red and green line aren’t really comparable, because bugs need time to be fixed. We would need to visualize the time to fix past bugs also.
<nckx>I'm looking at https://debbugs.gnu.org/rrd/guix_tag_5y.png BTW.
<florhizome[m]>nckx: this is more apparent for emacs
<nckx>1 → 0 is not really significant.
<nckx>Oh.
<civodul>hmm 10.0.0.[56] are unreachable on berlin
<nckx>florhizome[m]: I don't see how they are related?
<florhizome[m]>guix and emacs?
<nckx>Yes.
<florhizome[m]>yes, I didn’t really look at the vertical axis for guix.
<nckx>If emacs has decided not to use wontfix anymore (weird but possible), that still wouldn't affect guix.
<nckx>I think your human pattern-matching went a bit too far :)
<zimoun>vivien, yeah for sure. IMHO, a gap is expected. But if the gap is increasing, it means more bugs are in which means: it is getting worse. :-)
<jpoiret>just when you thought webkitgtk was done, webkitgtk-with-libsoup2 shows up
<nckx>I'm sorry I laughed.
<florhizome[m]>nckx: if there would be a “cultural shift” I suppose changes in emacs debbugs behavior *could* be as indicative as anything for other lisp projects.
<florhizome[m]>but yeah. For guix the first question would be more why was it never used much in the first place.
<florhizome[m]>I just found it interesting to see that in emacs graph tbh.
<florhizome[m]>It doesn’t actually tell that much relevant stuff though probably.
<notmaximed>Speaking of ... interesting ... bugs: ‘assertion failure: number of’ elements in set is negative’ (non-guix)’
<notmaximed>Paranoia paid off.
<mothacehe>grr the GC is still running on berlin preventing c-u-f building
<nckx>florhizome[m]: True, it's hard to believe (at first glance) that the emacs graph is coincidental. A few big ‘shifts’ going on there.
<jpoiret>notmaximed: please file the bug with mathematicians
<nckx>In Guix, we're just rather bad at bug admin: I think the vast majority of notabugs just get -closed with no prior classification.
<nckx>I've certainly been guilty of this.
<florhizome[m]>yes the number of tagged bugs actually is too small to tell much at all
<nckx>So don't do too much big data involving Guix bug tags. Ideally none.
<notmaximed>Problem is, I wrote that buggy set cardinality code :p.
<notmaximed>(p:?)
<notmaximed>X-P
<nckx>:-P == N:-P
<notmaximed>N:-P
<notmaximed>:P
<notmaximed>:P is NP-hard? (-:
<florhizome[m]>Other than that they have more then doubled since July. Probably c-u-f?
<vivien>There’s a rumor that libreoffice is written is java. I can confidently say that this rumor is not propagated by guix people, because they spend their day waiting for those [build CXX] to complete ^^
<civodul>mothacehe: oh, that's the 2nd gc wave, lemme see
<notmaximed>The rumor is not propagated, because we prefer our rumors in 'inputs' or 'native-inputs' instead of 'propagated-inputs' :P
<vivien>True.
<civodul>mothacehe: it's running, but it's in the "deleting unused links" phase, with the GC lock released; so it doesn't prevent builds
<civodul>we should let it run to completion because it'll trim /gnu/store/.links
<notmaximed>Rumors that $LANG is slow don't go in inputs, native-inputs or propagated-inputs though, they go into the implicit inputs of $LANG-build-system
<apteryx>can someone think of a build-side hack to mimick the effect of https://gitlab.gnome.org/GNOME/mutter/-/blob/main/.gitlab-ci.yml#L248
<mothacehe>civodul: oh thanks for checking, not sure why the c-u-f builds are not picked up then
<apteryx>possibly copy the thing to /tmp, hack it there, and substitute its entry in XDG_DATA_DIRS
<civodul>mothacehe: i also started core-updates builds by hand for armhf, aarch64, and powerpc64le because apparently we have zero substitutes there :-/
<civodul>apteryx: there's no /usr/share or anything similar in the build env anyway
<vivien>From my personal CI, core-updates are broken in substantial ways
<civodul>vivien: you mean not -frozen?
<vivien>civodul, yes
<vivien>I build my guile + gtk+ app on some branches, and nothing works on core-updates
<vivien>But cuirass won’t show me the logs
<vivien>(so I guess that’s because of failing dependencies)
<civodul>yeah we should merge -frozen into non-frozen (melting?)
<roptat>global warming! :)
<mothacehe>the famous git melt command :p
<roptat>ok, I think I'm done closing my old bug reports that don't apply anymore :)
<civodul>closing and applying or just closing? :-)
<roptat>I want to encourage you all to have a look at issues.gnu.org, search for "submitter:<your name> is:open" and close old reports that are no longer relevant :)
<roptat>just closing
<vivien>isn’t that issues.guix.gnu.org?
<roptat>although, I did apply a few this morning
<roptat>bah yes, issues.guix.gnu.org
<roptat>can't type ^^'
<zimoun>the link http://guix.gnu.org/en/manual/fr/guix.fr.pdf is broken.
<vivien>Oh no, a new issue!
<nckx>Seeing http://issues.guix.gnu.org: I'm going to close https://issues.guix.gnu.org/37348#2 by pushing the patch.
<roptat>zimoun, oh, indeed
<vivien>So I had opened this issue: https://issues.guix.gnu.org/51890, but it got fixed by someone else in the mean time, but since we used different approaches the discussion is not completely finished. As far as I’m concerned, this is fixed, but I don’t want to close it in case people have more things to say. What should I do?
<roptat>trying to "guix build -f doc/build.scm", I get "Failed to produce PDF for language 'de'!"
<roptat>but it's not a fatal error, so the PDF is just missing
<roptat>maybe (@end occurred when @iftrue on line 19292 was incomplete)
<roptat>but it's not clear to me
<vivien>I should open an issue in the meta-issue tracker :)
<nckx>Visiting http://issues.guix.gnu.org or http://guix.gnu.org is no longer possible.
<nckx>kozo[m]: ☝
<civodul>nckx: it is, no? i get 308 Permanent Redirect
<civodul>or it's not, if you meant getting raw HTTP
<civodul>given the ambiguity, you're definitely right
<nckx>I meant the http: part yes.
<KarlJoad>Quick question, is the package download process that Guix goes through parallelized? Or does each package download one after another?
<florhizome[m]>I think not, if you mean what pacman has been doing more recently
<notmaximed>are you asking about, source code, or substitutes? They are handled by different code paths.
<florhizome[m]>*able to
<notmaximed>I thought there was some parallelisation but I'm not 100% sure
<KarlJoad>notmaximed: Mostly subtitutes, though source code probably would have been my next question.
<notmaximed>At least when using --max-jobs=something at least 2
<notmaximed>IIUC, there is some parallelisation, but I don't know if that's for substitutes or source code
<KarlJoad>florhizome[m]: Yeah, that is pretty much what I mean.
<florhizome[m]>Wouldn’t you need more mirrors for this to actually work, at least in the Pacman analogy?
<florhizome[m]>afaik you would basically set up 5 mirrors or so, while guix only has 2 official servers up for users rn.
<nckx>What's a Pacman analogy? Sounds cool.
<nckx>…oh, the package manager. Less cool.
<florhizome[m]>arch package manager
<florhizome[m]>:P
<nckx>You shouldn't need multiple mirrors to reap most of the benefits, no.
<nckx>For the same reason HTTP pipelining is so much faster.
<nckx>Both substitutes and source downloads are parallelised.
<nckx>Well, they used to be.
<nckx>I don't think that's changed.
<florhizome[m]>Maybe the multiple mirrors thing is just to have more servers to check in order to find the fastest
<civodul>KarlJoad: the level of parallelization is defined by the --max-jobs option, which is 1 by default (i.e., sequential)
<nckx>I think Guix has exactly one semi-official mirror at the moment, making that question just ‘China’ or ‘not China’ ☺
<roptat>I think what's done rn is that the substitute is downloaded, in parallel with any decompression needed to put the substitute in the store
<civodul>yes, it's all pipelined
<florhizome[m]>But I actually remember that it would seem like thoese variables correlate - number of mirrors v number of active downloads
<roptat>I had a patch (https://issues.guix.gnu.org/39728) to allow to choose independently how much download tasks and build tasks you wanted, so builds could happen in parallel to downloads when possible
<nckx>Much ancient venerable bug number. What's blocking it?
<nckx>Oh, you ☺
<florhizome[m]>The parallelization of dls speeds up things enormously in that phase though, and I’m not even in that of a week infrastructure region
<roptat>nckx, yes me :)
<roptat>if I have enough courage, I'll send a v2 this week-end
<nckx>(Belated) thanks for working on that.
<roptat>with that I could use -D50 while still building only one task at a time :)
<roptat>I'd like to improve the interface too, when there are more than one task running at the same time at least
<jpoiret>notmaximed: re what we were talking about, in any case we'd need to mostly rewrite/patch the guile reader/writer
<nckx>IMO it should default to something like 5.
<nckx>Or 4.
<notmaximed>jpoiret: Why?
<florhizome[m]>Is download and build necessarily coupled here?
<podiki[m]>different number of download (higher) and build (lower) jobs sounds great, I support that
<nckx>florhizome[m]: Now, intrinsically. With patch, no.
<podiki[m]>(higher/lower being what I would set to for my fast internet butnot wanting too many parallel builds)
<jpoiret>correlating source location while reading isn't supported with the guile reader
<jpoiret>at least, apart from just the line column of the current port
<notmaximed>jpoiret: Isn't read-syntax + syntax-source sufficient?
<florhizome[m]>So if you have a threadripper or power9 with tons of cores and perf would you still build one package at a time? :O
<notmaximed>That has line + position + filename of every part of the expression
<podiki[m]>I like building multiple, until you hit icecat or something and then it is slower trying to swap in other builds at the same time
<podiki[m]>shrug
<jpoiret>i mean, when reading the exported build script
<notmaximed>Though it can take some work to mangle it in a compact format
<notmaximed>ah
<nckx>florhizome[m]: By default. You can override it in your system.scm.
<jpoiret>you need to inject into the reader that the source is something different, and you need to actually fetch that information from somewhere
<nckx>(guix-configuration (extra-options (list "--max-jobs=N" …)))
<notmaximed>We could do something like ((@ (guix position stuff) eval-with-positions) '(the build sexp) 'all-the-position-information)
<podiki[m]>most things seems to do well with using all cores/threads in building, but not everything; or memory bound
<notmaximed>where eval = compile + run it
<jpoiret>notmaximed: but how do you associate position-information with specific terms of the sexp?
<nckx>Balancing max-jobs & cores is an art that's hard to get right without consulting the admin.
<jpoiret>you need to inject it into the reader process so that guile will just take over
<nckx>Ask my 8-core machine with 8 GiB RAM how much it likes things that sniff nproc :-/
<florhizome[m]>I thought it was automatically set at a reasonable number
<florhizome[m]>like 4 for my old x230 (2c4t)
<nckx>That number is what's hard to guess.
<nckx>1 is not unreasonable.
<nckx>4 is not necessary reasonable.
<notmaximed>We could look at (ice-9 read) for how to construct syntax objects
<jpoiret>yeah, that's what i was reading
<notmaximed>something like (make-syntax 'atom 'position) --> some syntax, (make-syntax (cons syntax1 syntax2) 'position-of-pair) --> some syntax
<jpoiret>syntax objects are defined in libguile/syntax.c
<notmaximed>make that a recursive procedure
<notmaximed>(make-syntax doesn't exist AFAIK)
<jpoiret>it does it does
<jpoiret>ice-9/psyntax.scm uses it
<notmaximed>we could use datum->syntax
<florhizome[m]>kinda depends on thermals, too?
<florhizome[m]>like how much impact does one core/thread on near max have
<notmaximed>(datum->syntax #f (cons syntax-1 syntax-2) #:source (vector filename line column))
<notmaximed>(see (ice-9 read))
<notmaximed>(You can stuff syntax'es into ‘datums’ passed to datum->syntax.)
<florhizome[m]>One thing that seems not parallel too is the step of generating the profile at the end.
<florhizome[m]>Also it struggles a lot with icon packs
<podiki[m]>yeah, and that seems to take a long time when you have icon themes, fonts, something like that
<podiki[m]>right
<florhizome[m]>Icons!
<nckx>florhizome[m]: Yeah, and RAM, and whether you like to use something called ‘Chromium’ (Firefox too, probably), that uses $all_the_ram to build, etc.
<florhizome[m]>just fonts are kinda ok
<florhizome[m]>As far as my research goes
<nckx>Are those not stand-alone derivations that can be built in parallel?
<florhizome[m]>Or gtk themes
<podiki[m]>I have to admit being spoiled on a new desktop with some water cooling, 16gigs of ram gets maxed out pretty often, but seeing 12 threads at max speed is fun
<nckx>I thought they were but I can't say I even paid attention.
<podiki[m]>it is the profile building at the end, the package themselves are fast
<nckx>podiki[m]: I… I also have 16 GiB of RAM… yaay…
<podiki[m]>nckx: I never thought I'd see it used so easily, but things like webkit, browsers...wow they want all the memory
<nckx>Are threads hyperthreads?
<nckx>I don't know what a threadripper is.
<nckx>Sounds aggressive.
<podiki[m]>kinda sounds like the opposite of what you'd want :)
<florhizome[m]>anybody try putting papirus icon pack, arc theme and breeze icon pack in one profile
*nckx protects their 8 threads against podiki[m]'s machine which is obviously something that steals threads.
<podiki[m]>florhizome: yeah, thats me
<podiki[m]>I don't have a threadripper! just a "normal" 5600X
<florhizome[m]>That’s enough to run profile generation for like half an hour and get my cpu to 95 degree
<nckx>Oh, sorry, I confused you with florhizome[m]'s message above.
<podiki[m]>but from a 4 core/thread old Intel to the latest AMD with 6 cores/12 threads...wow am I happier in compiling
<podiki[m]>florhizome: I'm with you, would be great to improve profile building with themes and such, must be the number of files involved?
<florhizome[m]>i guess ^^ but I’m ok waiting some time for a central, big package
*nckx has 8 threads, 12 isn't that many more, hence my 2013 laptop is basically your machine, QED, don't make me feel bad.
<podiki[m]>I don't know enough to help, but maybe we can have a simple test case that shows the huge slow down?
<jackhill>rekado: cool, do you want to push it? :)
<podiki[m]>hahah nckx don't feel bad! I was lucky to get what I could this year
<florhizome[m]>Can you run perf to measure this?
<vivien>8 threads is a maximum for 16 Gb of RAM
<florhizome[m]>Mutter 40 builds in like 10 mins for me (900 jobs) while generating a profile of the three aforementioned packages is taking at least the same time
<nckx>Interesting that you're all using/comparing threads. So they're not that dead/uncool.
<podiki[m]>florhizome: maybe submit a bug report with a sample manifest and your rough timing? or maybe we can come up with a few manifests that show the poor scaling
<podiki[m]>I've found number of threads somewhat important for VR stuff too, CPU has more to do than e.g. flat game
<florhizome[m]>nckx I thought parallelism is basically the core foundation of progress in hardware since a decade or so?
<florhizome[m]>podiki[m]: Maybe I can run perf to measure the subprocesses?
<florhizome[m]>i think it might be relevant that there is no standardized build procedure for generating icons (svgs) etc
<nckx>florhizome[m]: I just meant SMT threads vs. physical cores.
<florhizome[m]>while fonts are managed with the help of fontconfig.
<florhizome[m]>that could leave lots of stuff unoptimized.
<florhizome[m]>Caching f.e.
<podiki[m]>I guess my question is what is the profile building step doing exactly with icon themes? traversing all the files, links, ...? since the package is built at that point
<florhizome[m]>These icon packs seem to be rebuilt everything
<florhizome[m]>Mime cache?
<podiki[m]>been a while since I updated my "desktop" profile (c-u-f waiting the past weeks), but I thought the cache step finished quickly and it was just where it says "building a profile with 15 packages" or whatever
<podiki[m]>am I misremembering?
<nckx>Yes, icon union + cache.
<nckx>podiki[m]: Same. Probably depends on how many themes you have?
<florhizome[m]>podiki[m]: and everytime!
<podiki[m]>don't think I can do the upgrade right now (will report back when I do), but I see gnome-themes-extra, adwaita-icon-theme, breeze-icons, arc-icon-theme, arc-theme, orchis-theme, papirus-icon-theme ....which is probably more than I need
<podiki[m]>if anyone wants to try :-P
<florhizome[m]>nckx: there aren’t even that many. The... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/8a02b610aa5af9841c6dfc19ed171ef8238b6699)
<nckx>‘Many’ in nckx means >0 😊
<florhizome[m]>I could try decoupling icon themes and gtk themes
<nckx>Oh, I have adwaita-icon-theme, but that's probably a forgotten accident.
<podiki[m]>my guess is something to do with the huge number of files/folders for icon themes, but I don't know what is going on behind the scenes that we could improve
<nckx>You do all have SSDs, right?
<podiki[m]>yeah, nvme even
<florhizome[m]>Icon themes take some time to install on other distros too
<florhizome[m]>but only one time
<civodul>rekado: re python-notebook, the problem has to do with the trash mechanism of gio (GLib), possibly a file name encoding issue
<civodul>will resume investigations later...
<KarlJoad>Ok, so final answer: No parallel downloads right now, but may become part of it soon. Good to know!
<florhizome[m]>nckx: yup
<nckx>KarlJoad: No, as many parallel downloads as you have builds now, may become separately configurable soon.
<KarlJoad>Gotcha. I ask because it looks like my `guix system reconfigure` is only downloading one substitute at a time.
<nckx>With --max-jobs=N it should download N…
<nckx>But you'll be building N packages at once (when possible) which not all machines/packages like.
<KarlJoad>Ahh... So Guix does not do it automatically... This machine should be fine with it; I don't know why packages would care which is downloaded first (in parallel) when they are all substitutes.
<notmaximed>Barring out-of-memory problems, building & substituting in parallel should always be fine
<nckx>They don't. I meant that some package combinations (I dunno, say webkit + chromium + icecat + something else in C++) will OOM some machines if built at once.
<notmaximed>--cores=more-than-one can sometimes be problematic
<nckx>Non-OOM --cores=N failures are bugs, though.
<nckx>‘Chromium uses too much RAM’ isn't.
<KarlJoad>Oh. CPU & RAM are not issues here. Running Guix on my desktop, which is practically a server.
<nckx>Then running guix-daemon with, say, --max-jobs=$(nproc) should be fine.
<nckx>Or --max-jobs=$half --cores=$half etc.
<KarlJoad>So --max-jobs must be passed to the daemon, rather than the `guix system reconfigure`?
<nckx>Either.
<notmaximed>No. you can do "guix system reconfigure --max-jobs=..."
<nckx>The daemon sets the default, adding it to every guix invocation is tedious.
<nckx>But still useful for one-off --max-jobs=1, for example.
<notmaximed>likewise for --cores, --substitute-urls and possibly --no-substitutes
<nckx>s/possibly //
<nckx>Same for --substitute-urls= etc. You get the idea.
<nckx>It's what the extra-options field of guix-configuration is for.
<KarlJoad>Gotcha. I will look into passing the option around. Thanks!
<M6piz7wk[m]>Where are the guidelines stating that non-free software is a great insult to everyone in GNU ?
<M6piz7wk[m]>i want to reference them to make a case
*M6piz7wk[m] found https://www.gnu.org/distros/free-system-distribution-guidelines.html
<abrenon>well g'night everyone
<M6piz7wk[m]>gn <3
<nckx>FAIL: tests/texlive (actual-error: Unbound variable: ~S" (sxml->package))
<nckx>Does this look like something that could be caused by 21357224bc1f450931fb3a64fe6d06f9d1137b67, civodul?
<nckx>(Testing that but it'll take a while.)
<nckx>After actually looking, that seems very unlikely, never mind.
<rekado>nckx: this sounds like the old texlive tests
<rekado>I updated them, so there should be no more reference to sxml->package
<nckx>OK, thanks rekado. Rather than rebase & update hashes &c., I simply added #:tests? #f to the guix package because this should be a throwaway Guix…
***duds-_ is now known as duds-
<nckx>Hi M6piz7wk[m]. Did you see my message earlier today?
***TheOwlLady is now known as myrcy
<podiki[m]>I'm seeing ledger fail on a test, with output:
<podiki[m]> -Error: File to include was not found: "./non-existent-ledger-file-BF3C1F82"
<podiki[m]> +Error: File to include was not found: "non-existent-ledger-file-BF3C1F82"
<M6piz7wk[m]><nckx> "Hi M6piz7wk[m]. Did you see..." <- eh? no?
*M6piz7wk[m] goes to set M6piz7wk in his keywords
<M6piz7wk[m]><yewscion> "Thank You for Your help, jlicht..." <- u welcome <3
<M6piz7wk[m]>nckx: did you even send any message addressing me? I can't find any in the log
<nckx> https://logs.guix.gnu.org/guix/2021-11-19.log#141405
<M6piz7wk[m]>> Sigh. M6piz7wk[m]: Stop. Trolling. Consider... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/4f6c564af84965787bc38a8e55fa9b958ef5b440)
<M6piz7wk[m]>?
<nckx>The very same.
<M6piz7wk[m]>whaddya even do u.u
<nckx>I just wanted to make sure you'd seen it.
<M6piz7wk[m]>seems like you said it out of nowhere looking at the log O.o
<nckx>We both know that's not true.
<M6piz7wk[m]>... did the other GNUs told you about the bullying tradition and you joined up on it
<M6piz7wk[m]>nckx: i honestly dont know
<nckx>This is bullying, M6piz7wk[m]: https://github.com/vii/cl-irregsexp/issues/2
<M6piz7wk[m]> https://logs.guix.gnu.org/guix/2021-11-19.log#135054 i looked up to here in the log
<nckx>You took information from this channel to troll an unrelated project.
<nckx>This is not done.
<M6piz7wk[m]>i dispute that trolling is the intention
<nckx>I don't care.
<nckx>Your actions are what matters.
<M6piz7wk[m]>you should care if you are accusing me of wrong doing without having the require info to understand the action O.o
<nckx>This is not a game that we will play.
<nckx>Anyway, consider yourself warned, etc. Don't do this again.
<M6piz7wk[m]>what do you expect from me then.. i am politically active so you will probably find lot of things justifying hiring someone to beat me up irl without understanding the implications and motivation for my actions
<M6piz7wk[m]>nckx: i feel warned it's uncomfortable making me think that i just spend lot of time and effort learning guix and guile only for you to ban me because you disagree with my politics >.>
<nckx>I expect you to behave in a way that doesn't reflect poorly on this community to outsiders, and in a manner that doesn't poison the atmosphere inside of it.
<nckx>I don't care about your politics or even know enough about them to know whether or not we disagree ☺
<M6piz7wk[m]>I am happy to disclose that i am not affiliated with the projected and i don't want to be to this level where my behavior would be representative of GNU excluding my agenda for FSF member conference and activities i cooperate on with FSF and FSFE
<M6piz7wk[m]>possible FSFLA
<nckx>TBH ‘not being a dick’ sounds like a so much easier alternative than that tedious-sounding thing.
<M6piz7wk[m]>and `manner that poison the atmosphere inside it` could be anything >.> so i feel like you just set a ticking time bomb that you can press and kick me out >.>
<M6piz7wk[m]>nckx: well i am happy to try being less what you see dick-y, but i can't quarantee the success >.>
<M6piz7wk[m]>i can barelly succeed with pushing patches to guix at this point u.u
<nckx>Well, no. You got the chance to stop doing the thing that could result in being kicked out. I think it's better for all of us if that doesn't happen.
<M6piz7wk[m]>and in terms of my politics they are based on always keeping an open mind so if you have something that you can prove beyond a reasonable doubt then i will adapt it
<nckx>This is not a pro forma warning. I sincerely hope you adjust your behaviour in such a way that we can work together.
<samplet>I just noticed the elogind patch.... What’s the latest with polkit stuff on c-u-f? A lot of features seem to be working for me, but I haven’t tested exhaustively.
<sneek>Welcome back samplet, you have 1 message!
<sneek>samplet, jpoiret says: i'm using https://paste.debian.net/1220033/ and grafting elogind with it so that i don't rebuild everything (it shouldn't change the ABI iirc)
<samplet>Well, that kinda answers my question. :)
<M6piz7wk[m]>nckx: So would it suffice you that it's not my intention to take action in preventing the work on the project e.g. what streamlabs is doing to OBS now with the trademark thing
<nckx>M6piz7wk[m]: Just stop trolling and generally being aggressive. You used ‘confrontational’ earlier, so that. Don't do that thing.
<nckx>Unfortunately, in the worst timing ever, I have to leave now.
<nckx>I really hope I won't regret that.
<nckx>Bye M6piz7wk[m], and Guix!
<M6piz7wk[m]>but i am not trolling and being controversial and aggressive is kinda in my nature >.>
<samplet>jpoiret: So now that polkit can talk to elogind, you discovered that elogind can’t talk to polkit?
<M6piz7wk[m]>maybe you can create a #guix-dev that is only for development and keep #guix as offtopic and for novice help from which you can ban me at any time without preventing me to contribute to guix? ^-^
<roptat>M6piz7wk[m], also technically taking someone's project and applying a license doesn't make it yours. On the contrary, this is a violation of their copyright :p
*M6piz7wk[m] can already tell that if you have this approach that he will get banned soon
<M6piz7wk[m]>roptat: only if they can prove that they are the rightful owner of the work :p
<nckx>M6piz7wk[m]: ‘being non-confrontational is boring’ I strongly suggest you give it a whirl anyway. Bye! No, #guix is #guix, #guix-whatever is #guix-whatever, and there is not a single #guix-edgy-trolling.
<roptat>M6piz7wk[m], well, commits from 12 years ago vs a commit from today... I don't think the judge will be in your favor
<nckx>M6piz7wk[m]: They don't have to prove anything. You know this. This is not a national thing. The laws are the same where you live.
<nckx>Bye.
<M6piz7wk[m]>nckx: they do.. i had a long discussion with a lawyer about it O.o it's just generally accepted as that the original creator is the copyright holder as it's very difficult to prove otherwise
<M6piz7wk[m]>nckx: bye, don't have me u.u
<podiki[m]>anyone have any insight to why a ledger test fails with
<podiki[m]> -Error: File to include was not found: "./non-existent-ledger-file-BF3C1F82"
<podiki[m]> +Error: File to include was not found: "non-existent-ledger-file-BF3C1F82"
<podiki[m]>seems it wants the "./" leading for the error it receives in the test but not not getting it (on c-u-f, passes on master)
<M6piz7wk[m]>M6piz7wk[m]: *don't hate me
<roptat>podiki[m], I'd just disable the test, it "passes"
<M6piz7wk[m]>podiki[m]: ledger where? the err seems familiar
<podiki[m]>ledger as in the double accounting software
<podiki[m]>roptat: curious why it fails now though, but that was my instinct to disable
<podiki[m]>I can put a note in disabling it
<roptat>yes pleae
<roptat>please*
<podiki[m]>will do
<podiki[m]>on the nature of fixing packages, I wanted to fix python-nautilus. seems it tries to compile some template files (that have non-python notation like {{stuff}})
<acrow>I am a happy ledger user. I'm on 'master' and it seems fine. Is there something I can do to help with the current ledger issue?
<podiki[m]>is there an easy way to exclude that in a setup.py? an exclude directory to add maybe? I need to see if it is a guix build or general python setup.py failure first
<M6piz7wk[m]>FWIW i remember that output from java when i was working with it professionally, but i don't remember what caused it
<podiki[m]>acrow: you could check if the test failure on master (compile locally) or c-u-f. but I don't know what changed or if it is worth too much time
<acrow>Things do seem odd right now. I just did a pull and now make fails with failed to load 'gnu/packages/perl.scm' which seems impossible -- but ledger also uses perl IIUC. Maybe related issues?
<podiki[m]>on master or c-u-f?
<acrow>master
<acrow>256c3e714a master
<podiki[m]>huh
<podiki[m]>(gotta run right now, will investigate later)
<M6piz7wk[m]>roptat: So can i submit patches that merge rustlang that fails reproduction in the meanwhile?
<roptat>M6piz7wk[m], yes
<M6piz7wk[m]>ehh i will take special care for the bit-by-bit reproduction of the binary that should be preserved by rust though
<M6piz7wk[m]>roptat: oke should there be anything else that can be added to the packaging?
<M6piz7wk[m]>like i notice that there is a timeout.. i could do benchmarking to estamine how long the package should take to build on 1 threat at 1GHz
<M6piz7wk[m]>*thread
<roptat>M6piz7wk[m], don't change the timeout
<M6piz7wk[m]>which seems like cool thing in case the package fails in an infinite loop
<M6piz7wk[m]>eh?
<M6piz7wk[m]>or like in general what can i do to make the package better? I can submit CI if there is any to do periodical tests and stuff
*M6piz7wk[m] is too self aware that his packages are garbage and wants to investigate if he can do something to improve that
<roptat>just make sure guix lint <your package> doesn't give you any warning
<M6piz7wk[m]>hm O.o anything else?
<roptat>take some time to improve the synopsis/description
*M6piz7wk[m] is also making notes to make a new wiki entry on the unofficial wiki
<roptat>and that's about it, if there's anything it'll show up during review
<M6piz7wk[m]>roptat: ye x.x i just submitted the autogenerated and didn't give it much though x.x
<M6piz7wk[m]>anything else? ^-^
<roptat>not that I can think of
<roptat>just take good note of the comments I sent you on the package yesterday
<roptat>so I don't have to repeat myself :p
<roptat>(for reference: https://issues.guix.gnu.org/51944#7)
<M6piz7wk[m]>also how do i figure out arguments to the package
<M6piz7wk[m]>i currently just do reading of the source code but it's not very descriptive x.x
<M6piz7wk[m]>and manual seems to lack info on it 🤔
<roptat>mh, possible
<roptat>there's this: https://guix.gnu.org/manual/devel/en/html_node/Build-Systems.html#index-cargo_002dbuild_002dsystem
<roptat>doesn't talk about #:skip-build. Other than that and inputs, I don't think you need to use other arguments
<GNUHacker>my system dont have sounds, I can hear music and video but "the system sounds" dont play, wich package I need in guix?
<abralek>Hi everyone, Is it possible to set chmod 500 for a binary file at /bin directory building a package?
<abralek>somehow I cannot get rid of group and others
<roptat>GNUHacker, pavucontrol?
<GNUHacker>maybe?
<samplet>Okay elogind is not talking to polkit at all. Upstream bug: <https://github.com/elogind/elogind/issues/206>; patch from jpoiret: <https://issues.guix.gnu.org/51972>.
<roptat>abralek, not sure I understand, but you can't access to /bin from the build, and if you mean bin in the store, you can't set to 500, because the store is always at least readable to everyone
<samplet>I would like to push it, but I notice that CI is falling behind. It’s 2315 builds. Thoughts?
<roptat>2315 dependents? it goes to core-updates
<samplet>Maybe we could cancel the current evaluation (I’m not super hip to how we do CI stuff)? It’s mostly the same set of builds due to my recent polkit commit.
<M6piz7wk[m]><roptat> "just take good note of the..." <- hmm oke x.x
<acrow>disregard my earlier perl.scm comments. I needed to get clean. :(
<M6piz7wk[m]>when should i even use the `/etc/thing.el`
*samplet goes off to actually test the patch
<roptat>M6piz7wk[m], just before sending the package, I tihnk
<roptat>although, I never use it...
<GNUHacker>fixed! the package was "sound-theme-freedesktop"
<florhizome[m]><abralek> "Hi everyone, Is it possible to..." <- I think it would be useful to provide a backtrace ;)
*samplet -> afk for a while
<nckx>Hullo again Guix.
<nckx>M6piz7wk[m]: I don't hate you.
***stikonas_ is now known as stikonas
<apteryx>oh, mutter 41's test suite is now passing on guix, with only one disabled test. phew.
<civodul>\o/
<M6piz7wk[m]><nckx> "6piz7wk: I don't hate you." <- I feel hated >.>
***xgqtd is now known as xgqt
<ss2>hello, is there anything to read through regarding best practices in writing info documentation?
<ss2>For Guix services.
<lilyp>Rule of thumb is at least document all the fields :P
<vagrantc>i'd like to run guix's test suite, but i only want to run a single test ... i tried "make check SCM_TESTS=tests/lint.scm" but it still seems to run the other tests ... what am i missing?
<nckx>Bye Guix o/
<ss2>And I don't want to simply copy the description for the parameters that are explained in the manpage. Should I rephrase it all?
<civodul>vagrantc: it's "TESTS=...", see https://guix.gnu.org/manual/en/html_node/Running-the-Test-Suite.html
<vagrantc>ah
<vagrantc>i knew i did it at some point before :)
<civodul>:-)
<apteryx>civodul: is this expected? guix/derivations.scm:1260:2: warning: possibly unbound variable `gexp->derivation'
<civodul>apteryx: yup, there's a comment even :-)
<apteryx>appearing right after guix/derivations.scm:1221:4: warning: 'build-expression->derivation' is deprecated, use 'gexp->derivation' instead
<apteryx>ah, ok :-)
<civodul>no worries
<civodul>it's not optimal but that's ok
<civodul>took 7 years to formally deprecate that procedure!
<apteryx>hehe
<samplet>Running with <https://issues.guix.gnu.org/51972> (grafted) does in fact fix all the VT switching and shutdown/suspend problems on c-u-f.
<rekado>on c-u-f python-numba fails to build.
<rekado>problem is that it’s not compatible with numpy 1.21
<samplet>Why are there 70k builds scheduled for c-u-f? Am I reading Cuirass wrong?
<samplet>Unless there’s a reason to wait, I am going to push that elogind patch.
<rekado>numba doesn’t have a huge impact, but it’s 16 bioinfo packages that don’t work because of this.
<rekado>we can’t use an older version of numpy just for numba
<rekado>1.20 would be fine for numba
<apteryx>samplet: looks like there was a huge rebuild in the last patches
<apteryx>I've rebased and I'm rebuilding a good chunk of the world, it seems
<jpoiret>samplet: are you able to shut down from gdm? I'm building locally and haven't retested yet since trying with grafts
<samplet>jpoiret: I assume so. I tried suspending, which wasn’t even an option before, and it worked.
<jpoiret>suspending isn't a polkit-restricted operation iirc
<jpoiret>or at least it's not the same operation so it might work whereas shutting down doesn't
<samplet>I believe it is, because elogind was returning a not permitted error in response to “CanSuspend” method calls.
<rekado>so, uhm, … what do y’all think of reverting python-numpy to 1.20? Keeping it on 1.21 on core-updates?
<jpoiret>rereading org.freedesktop.login1 doc, it is
<samplet>Well, I’m very confident. Your explanation was good. Everything makes a lot of sense of the D-Bus traces I was looking at. However, it only takes 5 minutes to try. I’ll be back!
<rekado>1.20.3 was released in May 2021.
<samplet>It didn’t work! (Boy do I look silly now....) :)
<samplet>I could log out, which is new.
<apteryx>rekado: for 16 bio packages? why not keep a 1.20 variant instead?
<rekado>because we can’t have two variants of the same Python package in the same environment.
<rekado>everything else uses numpy 1.21.3
<apteryx>and latest numba won't support 1.21?
<rekado>no: https://github.com/numba/numba/issues/7176
<rekado>two tricky open issues
<rekado>would be nice if we could trick Python into using different variants of numpy for different packages in the same environment
<rekado>but I don’t see how.
<apteryx>if they are command line tools we can wrap them, but otherwise
<apteryx>(they already would by the python build system in fact)
<apteryx>oh, I guess it was the fix to polkit that caused a massive rebuild
<rekado>I’ll add the 1.20 variant and brace myself for conflicts then :)
<apteryx>yeah, I can't think of a good solution; revert doesn't sound to appealing. If we were to follow such strategy for each package that negatively impacts a few, we'd be stuck in guix-past
<rekado>we can tell users to make use of package-input-rewriting (to rebuild their environments with the older numpy if they must use other packages together with numba), and to have separate profiles.
<rekado>I’m biased towards not breaking many bioinfo packages, of course, but I think in this case we can let users work around it.
<samplet>apteryx: Really? I did check with ‘guix refresh’ and it said only about 2000. Did I miss something? We are looking at a similar situation with elogind now.
<apteryx>yeah, it says 2308 here
<apteryx>not sure then
<civodul>rekado: i pushed a fix for python-notebook \o/
<civodul>bits that lead to pigx remain to be tested
<civodul>i'm waiting for a qtwebgkit build...
<rekado>civodul: woo, thank you!
<rekado>I’m now upgrading llvmlite and numba, and then add numpy-1.20 for numba :-/
<civodul>it's a long road
<jpoiret>samplet: i'll look more into it when my poor laptop is done with webkitgtk-with-libsoup2
<apteryx>it'll be useful to get rid of webkitgtk-with-libsoup2 as soon as its few dependents can be upgraded
<florhizome[m]><florhizome[m]> "I sent an email to bump this a..." <- better question, should I send another mail or anything else?
<jpoiret>florhizome[m]: i may look at it when I'm done with the c-u-f investigation. I don't have repo access though, but I can review the patch
***mark__ is now known as mjw
<florhizome[m]>that sounds allright, I’ll be sure to remind you to ;)
<florhizome[m]>What is the current c–u–f investigation?
<civodul>jpoiret: i'll push the elogind patch shortly, thanks for explaining!
<samplet`>civodul: I have it ready (just have to push the button). I'll do it.
<samplet`>(I've been testing it.)
<civodul>samplet`: cool thanks
<podiki[m]>acrow: still around? (looking at ledger now)
***lukedashjr is now known as luke-jr
<podiki[m]> https://paste.debian.net/1220122/ is my patch to remove the test (removes the file used to run the test)
<podiki[m]>guix build ledger --with-patch=ledger=./thatfile.patch builds successfully
<florhizome[m]>* needs to do a system reconfigure to be able to do perf on the profile with icons thingy and wants to reconfigure his btrfs parameters as well while at it
<jpoiret>Also for those running on c-u-f, is the show password icon not working for you as well?
<jpoiret>On gdm i mean
<samplet>jpoiret: It’s not working for me.
<podiki[m]>same, but I haven't updated since yesterday (if there were changes)
<jackhill>heh, now that I'm done building webkitgtk and qtwebengin, I'm on to qtwebkit
<acrow>podiki: Timing is bad. I've got another obligation I've got to get at in the next 10m. Buses... Anyway. I'll look into it again later this weekend.
<rm_-rf>What creates the /run/user/$user-id directory? Asking because swaywm demands that it exists
<rm_-rf>I'm trying to install it from a tty with no GDM
<podiki[m]>acrow: no worries, I'll submit the patch in a little bit. I just removed the test file with a note of what isn't working and since roughly when
<podiki[m]>jackhill: oh boy, all the heavy hitters
<jpoiret>rm_-rf: elogind is responsible for those iiuc
<jpoiret>if you log in through the tty, does loginctl display a session for that tty?
<rm_-rf>i tried adding the elogind service but it bricked the system
<rm_-rf>error flashed on login, but was too brief to see
<rm_-rf>i got to use the rollback feature early on :p
<jpoiret>did you guix pull before installing?
<jpoiret>or you used the graphical install maybe
<jpoiret>in any case, that elogind failure must be annoying. I don't think it should prevent ttys from starting though, but maybe i'm wrong
<rm_-rf>i used the graphical install, and did not choose any DE since I wanted sway
<rm_-rf>so no %desktop-services
<jpoiret>yes ofc. In any case, elogind is started automatically by dbus I think, so unless you login in a tty it shouldn't do anything
<podiki[m]>the gnu/local.mk is tabbed??
<jpoiret>also desktop-services != DE
<jpoiret>I use sway with GDM and so use %desktop-services
<jpoiret>it contains mostly dbus/polkit/elogind and all that jazz
<KE0VVT>I wish IBus and Sway could work together like IBus and i3 do.
<jpoiret>maybe you didn't have a dbus and polkit service? i think for most uses %desktop-services is good, you can remove gdm from it if you really want (although using GDM is pretty great imo)
<rm_-rf>oh i thought dbus might be the problem
<rm_-rf>i'll add dbus and polkit and try again
<rm_-rf>*the lack of dbus
<jpoiret>maybe look into gnu/services/desktop.scm at the bottom for the definition of %desktop-services, and if it seems sane to you use it directly
<rm_-rf>okay
<jpoiret>in conjunction with modify-services syntax to remove the things you really don't want
<rm_-rf>yeah
<rm_-rf>i don't really like using a dm
<jpoiret>KE0VVT: what's the exact issue with ibus and sway?
<rm_-rf>all it does for me is increase the boot time
<jpoiret>true. Although we're currently looking at integrating greetd which has pretty lightweight greeters
<jpoiret>(and TUI ones)
<KE0VVT>jpoiret: IBus uses protocol version 1, Sway only supports protocol version 2.
<rm_-rf>it's also pretty disorienting for me, booting into a GNOMEish interface and then logging into something completely different
<KE0VVT>jpoiret: https://github.com/ibus/ibus/issues/2182
<jpoiret>KE0VVT: maybe they need testers for the corresponding pull request! You could look into using those patches and reporting about them
<jpoiret>also: finally done with `guix system vm`, now I can test a bunch of things!
<KE0VVT>Is 10 GB enough for a system?
<jpoiret>no
<jpoiret>the guix store will eat space easily
<KE0VVT>I'm wanting to install a few systems onto the same disk.
<rm_-rf>which module do i get dbus-service-type from? i'd prefer to explicitly add services instead of adding desktop-services and removing gdm
<rm_-rf>is there even a dbus-service-type?
<jpoiret>yes, see services/dbus.scm
<jpoiret>you can look at which modules are used at the top of the scheme files with `use-module`
<foobarfoo>hi guix, where are a server config file? Im triying up a ftpd server in guix but imma noob. I cant find tthe ftpd.conf file in /etc/vsftpd/
<rm_-rf>adding (gnu services dbus) makes reconfigure stop complaining about polkit but it still insists that dbus-service-type is undefined
<jpoiret>see gnu/services/desktop.scm, it's "(dbus-service)"
<jpoiret>see gnu/services/dbus.scm (dbus-service) for a docstring
<rm_-rf>ah okay
<jpoiret>see also "(guix) Desktop Services" in the info manual for a description of most desktop services