IRC channel logs


back to list of logs

<civodul>jackhill: heh, thanks for testing! i'll have to see why "herd stop networking" doesn't work as expected
<civodul>it worked for me in a VM, but maybe i overlooked something
<civodul>in other news: merge done in core-updates-frozen
<civodul>turns out that GTK+ depends on samba and git-minimal on that branch
<civodul>so merging master would trigger a big rebuild
<mbakke>civodul: that's unfortunate, then those can no longer be updated directly on 'master'
<civodul>mbakke: i pushed a workaround: fixed versions of samba and git-minimal
<mbakke>oh, ncie
<civodul>so if you pull now you won't have to rebuild gtk+ and all
<civodul>it's not clear why graphene would depend on git-minimal though
<civodul>but anyway, tomorrow we can hack without rebuilding all that :-)
<nckx>I am sad to miss the -fest.
<nckx>(A Thursday, of all -days ☺)
<mbakke>oh, I'm travelling tomorrow and can't participate either :(
<jpoiret>i think i'll help out tomorrow
<drakonis>how long until the mass rebuilding is over?
<nckx>892:2 0 (guile-for-build "3.0") | ./guix/self.scm:892:2: In procedure guile-for-build: Throw to key `match-error' with args `("match" "no matching pattern" "3.0")'.
<nckx>Is this a known thing when inferior'ing to ~2018?
<nckx>It's actually my first-ever non-toy inferior; of course this never happened when playing around :)
<mbakke>nckx: the time machine was invented in 2019 and can't travel further AFAIK
<nckx>How hard is it to hard-code the last (well, first) usable commit so we can short-circuit the failure and produce a human-readable error?
<nckx>This is inscrutable.
<nckx>Although I strongly suspected exactly that.
<nckx>(Still, thanks mbakke ☺)
<civodul>right, you can't travel before 0.15.0
*civodul -> zZz
<nckx>Okay, that should just be an explicit check. Hick, I even read the manual, and didn't see that mentioned.
<nckx>'night civodul.
*nckx is not far behind.
<nckx>…that came out wrong.
<jpoiret>goodnight everyone
<podiki[m]>speaking of graphene, python graphene related stuff was broke last I checked, tried to update but ran into dependency issues
<podiki[m]>will try again tomorrow then!
<ajarara>Hello! Is there a proc that takes a dependency tree to a
<ajarara> list? I don't care about topology or the different
<ajarara> dependency relationships (propagated/compile) , just want
<ajarara> to assert that every dependency in the tree satisfying some
<ajarara> predicate satisfies another.
<ajarara>Got it: (guix packages) package-transitive-inputs
<ajarara>Thanks for chewing on it though!
<jgart>florhizome[m], thanks building now to test
<apteryx>got 2/3 test suites to pass for mutter
<lilyp>vivien: there's probably ways around using the service but in that case at least look at its innards
<podiki[m]>although now I'm wondering why my system is pulling in mutter at all...
<podiki[m]>why do some themes depend on mutter??
<M6piz7wk[m]>podiki[m]: Because someone has to take care of them until they grow up :P
<podiki[m]>hahaha ok, you got me
<M6piz7wk[m]>is there a way to access the environment that guix failed to build? Like when building against the guix repo for developing packages?
<M6piz7wk[m]>like when i need to make a patch bcs guix's rust is from the middle ages -w-
<bavier[m]>6piz7wk: If you build with the `-K` flag, the build directory with have an `environment-variables` file you can source after entering an environment with `guix shell -D`
<M6piz7wk[m]><bavier[m]> "6piz7wk: If you build with the `..." <- how would that help? I need the source files to develop a patch
<M6piz7wk[m]>also what is the guix way to set up ccache
<bavier[m]>the source files are in the saved build directory.
<M6piz7wk[m]>i see
<M6piz7wk[m]>wait where is the saved build ri
<bavier[m]>It'll print the directory name with the failure message
<bavier[m]>usually in `/tmp/guix-build-...`
<M6piz7wk[m]>oh i see
<M6piz7wk[m]>oh ccache won't help me cache the build of guix repo
<M6piz7wk[m]>right make should do that.. nwm
<M6piz7wk[m]>is there a way to set up a distributed build for guile?
<M6piz7wk[m]>so that the repo is built across multiple systems
<M6piz7wk[m]>found it
<M6piz7wk[m]>nwm not that
<M6piz7wk[m]>that make is not caching sh!%&@ -w-
<bavier[m]>`make -j` should work when building guix itself. if you're talking about `make` for a package's build, idk if timestamps in the build dir might confuse make.
<M6piz7wk[m]>building guix and it doesn't work -w- keeps rebuilding everything
<M6piz7wk[m]>oh works now
<jackhill>sneek: later tell civodol I got started on the c-u-f sprint at little early :)
<ns12>Let's say I build an image like this: "guix system image -t qcow2 my-os-config.scm --image-size=3G". If I subsequently change the contents of my-os-config.scm, do I need to rebuild the image? Or can I use "guix system reconfigure" from within the running image to change the OS configuration?
<jackhill>sneek: later tell civodul I got started on the c-u-f sprint at little early :)
<sneek>Will do.
*M6piz7wk[m] sent a code block:
<M6piz7wk[m]>Why i can't build this?
<M6piz7wk[m]>this is on master branch u.u
*M6piz7wk[m] smash
<M6piz7wk[m]>yay it works
*M6piz7wk[m] sent a code block:
<M6piz7wk[m]>why is this failing now? it worked for cargo-make u.u
<M6piz7wk[m]>How do i specify the minimal supported rust version for the package?
<M6piz7wk[m]>the shell2batch package builds sanely on rust-1.52
*M6piz7wk[m] rage quits
<M6piz7wk[m]>damned manual not telling me how to specify minimal supported rust version for a package 💢
<podiki[m]>if you are on core-updates-frozen only "rust" is exposed (latest packaged rust version), rust-1.x are not define-public anymore
<M6piz7wk[m]>i ain't on `core-updates-frozen` because it doesn't allow me to define packages in crates-io.scm that are recognized by guix
<podiki[m]>(that exhausts my rust knowledge)
<M6piz7wk[m]>this is guix knowledge!
<M6piz7wk[m]>i have package that needs rust-1.52 minimal where guix builds it with 1.45
<podiki[m]>off to bed, but some build systems you need to add the explicit version as an input (and/or build argument as you have), not sure in this case
*M6piz7wk[m] proceeds with his rage quit
<M6piz7wk[m]>like i can make a patch that makes it to build on 1.45
<M6piz7wk[m]>but meh
<M6piz7wk[m]>malpractice -.-
<M6piz7wk[m]>Or like how should i handle the situation
<M6piz7wk[m]>should i just submit patch that changes the default rust version
<M6piz7wk[m]>or like ideally making a logic that outputs an error when insufficient rust is used
<M6piz7wk[m]> oh wait master has rust-1.53
<M6piz7wk[m]>it has set rust-1.54 which is not defined
<rekado_>M6piz7wk[m]: provide it as an argument to the build system
<rekado_>M6piz7wk[m]: #:rust ,rust-1.53 or whatever you need
<rekado_>I recommend looking at existing packages before complaining
<M6piz7wk[m]>rekado_: what does that do exactly?
<Guest42>please help
<M6piz7wk[m]>oh master has 1.45
<Guest42>im stuck on some unbound variable stupid error
<Guest42>with a bunch of garbage output
<rekado_>Guest42: please paste the output on a paste site and post the link here
<Guest42>i cant im on phone
<Guest42>laptop unusable
<Guest42>ita a bunch of \x0;
<rekado_>it’s unlikely you can be helped when we can’t see the error message.
<Guest42>fml lemme try
<Guest42>its when running guix system init
*rekado_ leaves
<M6piz7wk[m]>Guest42: eh? what's the problem again
<M6piz7wk[m]>Guest42: last time that happened to me on guix installer it was broken USB drive stick
<M6piz7wk[m]>so caused by disk corruption
<M6piz7wk[m]>mby you have the same issue?
<Guest42>this is the error
<Guest42>but ii only have this system
<Guest42>so im screwed
<Guest42>you mean disk corruption on the system im running the guix command from?
<Guest42>or on the target filesystem which i wanna install
<M6piz7wk[m]>So to clarify you just installed or are installing guix?
<Guest42>i have it installed on external drive
<Guest42>trying to install on laptop
<M6piz7wk[m]>then my best guess is that the guix installation on the external drive is corrupted
<Guest42>how do i fix it tho
<Guest42>dont have another installation
<M6piz7wk[m]>well you can either check all files and directories and make sure that it's not corrupted including reading and interpreting the assembly
<M6piz7wk[m]>or use whatever your filesystem has a repair
<M6piz7wk[m]>also not having a recovery USB drive is malpractice in general.. get systemrescuecd at least next time
<M6piz7wk[m]>or if you have an android phone with root then DriveDroid
<Guest42>that was my rescue cd lmfao
<Guest42>didnt know it was corrupted cuz it worked fine
<Guest42>everything works fine except for system init
<M6piz7wk[m]>have two rescues then! :p
<M6piz7wk[m]>so just fix system init?
<Guest42>how lol
<M6piz7wk[m]>I don't understand what are the implications of the failure -> elaborate
<M6piz7wk[m]>like does it prevent boot?
<Guest42>prevents nothing
<Guest42>except i cant instll guix on anither drive lol
<M6piz7wk[m]>So fix the installation?
<M6piz7wk[m]>probably requires you to make a new installation medium
<Guest42>i ghate my life
<M6piz7wk[m]>or you can define the filesystems and create the OS manually LFS-style
<Guest42>nah imma do a full reinstallation soon
<M6piz7wk[m]>just get rescue drives then! i would take off linux licenses from people who don't have em
<Guest42>like redownload original uiso and go through the whole process again lol
<M6piz7wk[m]>like if you have guix then you can probably do guix installation on target
<M6piz7wk[m]>at least portage can do that
<abrenon>hi guix
<abcdw>abrenon: o/
<abrenon>I was going to ask a question but I know the answer would've been: there's a mode in emacs to do it : )
<vivien>Hello guix!
<civodul>Hello Guix!
<sneek>Welcome back civodul, you have 2 messages!
<sneek>civodul, jackhill says: I got started on the c-u-f sprint at little early :)
<sneek>civodul, jackhill says: I got started on the c-u-f sprint at little early :)
<civodul>oh oh!
<civodul>today is the day!
<civodul>M6piz7wk[m]: hey, calm down :-)
*M6piz7wk[m] sent a code block:
<M6piz7wk[m]>civodul: hug no
<M6piz7wk[m]>this hugging thing keeps refusing to recognize my packages
<abrenon>: )
<M6piz7wk[m]>yay it works
<abrenon>another monitor saved !
<abcdw>civodul: Merge, please.
<abrenon>which from an environmental perspective is an excellent thing
<M6piz7wk[m]>i didn't throw monitor off of a window yet
<M6piz7wk[m]>just mouse, keyboard and girlfriend
<civodul>abcdw: hey! that's a pretty harsh way to say "hi" :-)
<abcdw>civodul: Hello, my friend!) I thought after the like on mastodon we already started our social interaction :D
<civodul>abcdw: true :-)
<abrenon>ah… mastodon, the place where it all happens : )
<M6piz7wk[m]>why do i have a feeling that the `#:rust` doesn't do sh@%!
<M6piz7wk[m]>the package builds outside, but fails with guix
<M6piz7wk[m]>aaa what the hell
<vivien>So, for the GNOME / nm-applet at-spi2-core issue, the plan was to remove propagated inputs from network-manager-applet, IIRC, right?
<M6piz7wk[m]>oh it's test
<M6piz7wk[m]>not build
<M6piz7wk[m]>how do i apply patch to a package
<civodul>vivien: i'm looking at but apparently Vigra builds fine right now on core-updates-frozen
<jpoiret>podiki[m]: mutter is a dependency of gdm
<civodul>now, perhaps these are non-deterministic test failures?
<civodul>vivien: re at-spi2-core, i started removing propagations but that didn't look great
<civodul>i'll take another look when i'm done reviewing patches
<vivien>civodul, anyway, if you do something, please post it to a branch so that I can try it on my system :)
<civodul>will do!
<civodul>vivien: did you see my message about Vigra? ↑
<vivien>civodul, I missed it, but that’s true, it was fixed in the mean time
<vivien>(please close this issue ^^)
<civodul>alright, thanks!
<PurpleSym>Hm, we don’t have substitutes for icedtea on core-updates-frozen, do we? My build just ran out of space.
<civodul>PurpleSym: apparently we don't have substitutes, not sure why
<rekado_>my over-night build of gst-plugins-good failed
<rekado_>that’s pre-merge, so I’ll update now and see if that’s still the case
<rekado_>it’s elements_splitmuxsink that fails
<rekado_>tests/check/elements/splitmuxsink.c:201:E:general:test_splitmuxsink:0: (after this point) Test timeout expired
<M6piz7wk[m]>How can i pass `-A unused_parens` to rustc from guix package definition
<PurpleSym>And the derivation for ghc-8.8 changed again, which means I’ll have to wait another four hours 😢.
<user_oreloznog>Hello guix!
*civodul looks at qgpgme
<civodul>PurpleSym: bah :-/ would be nice to see why it changed
<civodul>yesterday i found that gtk+ would now depend on Samba and git-minimal, which was a source of rebuilds when merging
<civodul>i fixed it by adding fixed vesions of these
<jpoiret>civodul: just for today, or will it be that way in master as well?
<efraim>Just how much does gtk2/3 need librsvg?
<civodul>jpoiret: it's in core-updates-frozen and i think it'll stay, unless we find better solutions
<PurpleSym>civodul: You (indirectly) said you changed git? It’s in ghc’s `native-inputs`, which could explain why the derivation changed.
<vivien>Hi :)
<civodul>PurpleSym: ah! then let's do the same there
<civodul>lemme see
<zimoun>on core-updates-frozen, I note an issue with llvm-9, e.g., guix show llvm. Does someone is working on it?
<civodul>hey zimoun! i don't think so
<zamfofex>I noticed package definitions change frequently unintentionally. I wonder if it’d make sense to create a tool to help figure out the reason more easily. Maybe even preemptively before making the change.
<zamfofex>And if there is already such a tool, I think it could be worthwhile to investigate why it isn’t used effectively.
<jpoiret>`guix refresh -l` should do the trick zamfofex
<jpoiret>if it's about updating packages that update dependents
<civodul>PurpleSym: i'm trying to avoid the ghc rebuild by introducing git/fixed, because ghc@8.8 depends on the full git, not just git-minimal
<civodul>but it seems there are other things triggering a rebuild of git :-/
<PurpleSym>Maybe it would also work with git-minimal/fixed?
*M6piz7wk[m] sent a code block:
<M6piz7wk[m]>how the hug do i fix this
<PurpleSym>(Nvm, you’re right git-minimal/fixed would cause another rebuild.)
<jpoiret>M6piz7wk[m]: non bit reproducible builds are a tough nut to crack
<zimoun`>I suspect this daa46cd151657ac4df991bf6651d46aae739fcef tweaking the wrapper to introduce failure. Let burn some CPU cycles to confirm.
<M6piz7wk[m]>jpoiret: it's rust! that's like reproducible reproducible!
<jpoiret>well apparently here it's not. This might not be rust's fault, but you'll need diffoscope to investigate this iirc
<M6piz7wk[m]>whaddya do then u.u
<M6piz7wk[m]>oh diffoscope
<M6piz7wk[m]>what do i diffoscope
<M6piz7wk[m]>guix build -K and then checking the tmp things?
*vivien managed to crash emacs
<M6piz7wk[m]>> * <> managed to crash emacs
<M6piz7wk[m]>is that supposed to be a rare thing?
<vivien>I don’t do it often
<M6piz7wk[m]>hmm O.o
<jpoiret>I guess that should be how to do it, although I haven't ever done that myself
<M6piz7wk[m]>so what do i do x.x i am limited in time and want to finish this package already >.<
<jpoiret>if you're limited in time, i'm afraid fixing non-reproducibility is going to be a no-go
<M6piz7wk[m]>like i have 2 hours
<M6piz7wk[m]>and i worked on this for 7 hours today
<M6piz7wk[m]>and 18 hours in total
<M6piz7wk[m]>whaddya do then! guide mehhh
<M6piz7wk[m]>i already figured out how to do patches on my own
<jpoiret>well you'd have to fix the reproducibility issue, but for that you're kind of on your own
<jpoiret>there's no magical wand for these kind of things
<vivien>I don’t know how would one compare output rounds. From the error message, you have one of them, but the other one is missing
<M6piz7wk[m]>i don't even know where to start! i know how to solve those outside of guix though
<jpoiret>are you having this error because you passed --rounds n to guix build?
<M6piz7wk[m]>eh yes?
<M6piz7wk[m]>i passed `--rounds 2`
<jpoiret>well then, don't pass it, build it once, copy it out of the store in a temporary directory, rinse and repeat until you get two differing builds
<jpoiret>then diffoscope them
<florhizome[m]>I have an @ in a package name, it doesn’t want to be escaped w/ simple \ or \ :/
<vivien>Before you try to build each round, garbage collect it with guix gc -D /gnu/store/xxx-what-you-built (not .drv)
<jpoiret>vivien: right! i kind of forgot that
<jpoiret>florhizome[m]: I'm not sure package names are supposed to contain anything that's not lowercase alphanumeric characters
<vivien>And I forgot to ping M6piz7wk[m] for my last message, sorry
<florhizome[m]>jpoiret: The uri, I mean
<vivien>florhizome[m], you mean the home page or download URI?
<vivien>@ is %40 in URIs
<florhizome[m]>the download uri, see
<florhizome[m]>vivien: ty (:
<jpoiret>try using git checkouts instead of tarball downloads for git forges
<jpoiret>sometimes git forges recreate tarballs automatically, which changes the checksum
<civodul>PurpleSym: i think we have to change git to git-minimal/fixed in ghc@8.8, sooner or later
<civodul>PurpleSym: looks like e55547bf70384691712047912c793c517debd2ec (pre-merge) already lacked ghc substitutes
<M6piz7wk[m]>kreyren@leonid ~/Repositories/guix [env]$ guix gc -D /gnu/store/*-rust-shell2batch-0.4.2.drv; ./pre-inst-env guix build -K rust-shell2batch@0.4.2 | tee (full message at
<M6piz7wk[m]>eh ?
<M6piz7wk[m]> * ```... (full message at
<vivien>M6piz7wk[m], you’re deleting the .drv, not the thing
<vivien>You should guix gc -D /gnu/store/mzhsir8ajpf637vd0v6jsi11d18ggy18-rust-shell2batch-0.4.2
<vivien>(not .drv)
<florhizome[m]>jpoiret: but guix download doesn’t work for git checkouts :>
<jpoiret>if it's to get the hash, just copy a random hash in its place and guix will tell you both hashes when it tries to fetch
<vivien>(to get a random hash, change the first digit. If it’s a 0, put a 1. If it’s a 1, put a 0.)
<PurpleSym>civodul: I’ll build ghc with git-minimal/fixed locally to see if it works.
<vivien>It seems to me that cbindgen (and thus icecat) gets rebuilt after each master -> c-u-f merge
<vivien>That’s not a huge problem, but if you’re tracking down why things get rebuilt after merges, maybe it can help you
<M6piz7wk[m]>it is reproducible wtf
*M6piz7wk[m] sent a code block:
<civodul>PurpleSym: i've pushed changes that'll give you the same ghc@10 derivation as before last night's merge
<M6piz7wk[m]>is it because cargo caches builds and so doing it on rounds uses the second one from cache
<civodul>(though there are no substitutes either)
<civodul>vivien: yes, good to know!
<Guest42>i reinstalled guix and the problem persists!!!!
<PurpleSym>civodul: Yep, that worked. Thanks!
<vivien>M6piz7wk[m], it’s expected that they get the same name, because the name is a hash of the dependencies
<vivien>You need to copy each round to a separate place and diff them
<Guest42>omg i hate my life
<M6piz7wk[m]>Guest42: just get a working storage device m8
<Guest42>wdym get a working storage device
<M6piz7wk[m]>don't be like that stupid kreyren who spent 8 hours with it last time before he realized that the USB is piece of garbage
<Guest42>mine works
<M6piz7wk[m]>Guest42: looks like book example of data corruption to me
<Guest42>what does the usb have to do with anytging tgo
<M6piz7wk[m]>krey had the same issue and it was caused by his USB drive
<civodul>Guest42: the syntax is: "guix system init CONFIG DIRECTORY", where CONFIG is your Guix config file and DIRECTORY is the name of a directory (not a block device)
<M6piz7wk[m]>that he was trying to install guix
<Guest42>oh wtf
<civodul>that said, "guix system init" is super advanced usage
<Guest42>so i reinstalled because i mistyped the command
<civodul>you normally don't need it
<M6piz7wk[m]>also relevant probably
<civodul>yup :-)
<Guest42>my day wasted for nothing
<civodul>make sure you really need it anyway
<Guest42>well im tryint to install so ye
<Guest42>i think i do
<M6piz7wk[m]>Guest42: welcome in the club of "guix wasted my time for nothing" :p
<M6piz7wk[m]>i should implement membership fees would be milionaire again
<Guest42>wow im such a retard
<M6piz7wk[m]>hey that's my sentence 🔪
<Guest42>huh lol
<Guest42>you were a millionaire once?
<Guest42>mustve been fun
<M6piz7wk[m]>Guest42: like 8 months ago and on the road to be again bcs hugging covid
<Guest42>damn bro
<Guest42>i get paid less than 1k$ a month
<Guest42>way less lol
<Guest42>i actually work at mcdonalds lmfao
<M6piz7wk[m]>then just do more productive things :p or gamble on stocks
<florhizome[m]>guix: still at gtk 3.24, glib 2.62
<florhizome[m]>also guix: qtbase 6.1 as default
<Guest42>nah i gave up on that lmao
<Guest42>lost alot of money to crypto
<M6piz7wk[m]>Guest42: fool never heard of the power that silver has bwhahha
<florhizome[m]>(I get why, but it’s kind of funny since qt6 just isn’t really adopted anywhere in Linux (institutional) world)
<vivien>Don’t gamble on stocks just because someone told you to :)
<M6piz7wk[m]>ye don't sue me if you lose all your money
<M6piz7wk[m]>but invest in silver make me rich
<florhizome[m]>I think I should screenshot this, make an nft out of it, and then sue you.
<florhizome[m]>where do we set XDG_RUNTIME_DIR for tests?
<vivien>And sell the NFT to Guest42 for a million $
<civodul>i'm trying to debug qgpgme (Qt bindings of gpgme) but it's terrible
<civodul>i don't even know how to display a QByteArray
<civodul>gdb doesn't know either
<civodul>does anyone happen to know? :-)
<vivien>florhizome[m] seems to know a lot about qt
<florhizome[m]>I find the bug Q a little suspicious since a few years, sorry don’t know
<florhizome[m]>vivien: you know me better then myself :O
<M6piz7wk[m]>how do i disable diffoscope showing me the time when the file was modified
<zimoun`>compiling Guix with make -j1 is so slow… obligated ;-)
<vivien>M6piz7wk[m], --exclude-directory-metadata?
<M6piz7wk[m]>vivien: yep thanku
*M6piz7wk[m] sent a code block:
<M6piz7wk[m]>what am i supposed to do about taht
<vivien>I see 2 problems: one in the json where "outputs": is changed, and the content of .crate-content. For the latter, I guess you need to reset the modification time in a phase before install
<vivien>(for Cargo.lock and Cargo.toml)
<vivien>For the "outputs": problem, I don’t know.
<vivien>You should really get help from someone who knows Rust and/or how Rust in package on guix, my advice here is as sound as "sell all your silver you’ll get rich"
<vivien>Or you know, replace silver with anything
<Guest42>kernel compilation is taking too long
<Guest42>the anxiety
<ekaitz>hi guix can anyone help me know the default version that GCC uses for building packages?
<rekado_>ekaitz: we use gcc 7 on the master branch
<ekaitz>thanks rekado_ !
<rekado_>ekaitz: it’s some later version on core-updates-frozen
<ekaitz>okay thank you very much
<rekado_>you can check by looking in (gnu packages gcc); the gcc variable is just an alias for gcc-7 on the master branch.
<M6piz7wk[m]><vivien> "You should really get help..." <- how shall krey find this person
*vivien does not know
<M6piz7wk[m]>so should i just submit a patch, set it as DO NOT MERGE - NOT REPRODUCIBLE
<M6piz7wk[m]>and then annoy everyone who comes in this channel with it?
<vivien>Submit the patch with a warning, yes :)
<zimoun`>civodul or any wizzard. Weirdness on core-updates-frozen, checkout then “make“ is ok. Then “touch gnu/packages/llvm.scm && make” fails. Any idea?
<vivien>zimoun`, sometimes a rebuild is necessary, run make clean and make again
<vivien>(I’m not a wizard)
<zimoun`>vivien, thanks. But here I miss why. Especially because “guix build foo” is broken for the very same reason.
<zimoun`>where ’foo’ is some llvm related.
<jpoiret>is anyone working on mutter?
<jpoiret>i'm hitting the error as well
<ekaitz>rekado_: and can I choose a different version for an specific package as a builder?
<rekado_>ekaitz: yes, generally it should be enough to add a “gcc”-labelled package to the native-inputs.
<ekaitz>rekado_: aiight! thank you very much for your help
<zimoun`>rekado_: about in-place source upstream modification of R packages, have you already fixed them?
<rekado_>ekaitz: you’re welcome! Let us know if it’s not working. In some cases you may need to hide the default GCC by fiddling with env-vars.
<rekado_>zimoun`: these are just regular upgrades.
<rekado_>I’m going to push them today.
<rekado_>(only just returned from the pediatrician)
<rekado_>it’s 20 or so packages that have changed.
<zimoun`>rekado_, ok. You already did the upgrade dance (or going to do it :-))
<zimoun`>(hope everyting is fine)
<florhizome[m]><M6piz7wk[m]> "how shall krey find this person" <- Just look out for who merges a lot of rust maybe?
<rekado_>I’m building the packages now; will push straight to the master branch once that’s done.
<rekado_>zimoun`: (all is fine, thanks)
<zimoun`>rekado_: some build fine on master but fail on core-updates-frozen. Anyway.
<efraim>looks like enlightenment is broken on core-updates-frozen ATM
*civodul pushes a qgpgme fix
<ekaitz>rekado_: it worked :)
<civodul>zimoun`: i've reproduced the bug with llvm.scm (also in master)
<civodul>solution: move llvm-julia to llvm.scm, as it should be
<florhizome[m]>efraim: On master as well
<civodul>(we must not inherit cross-module)
<civodul>efraim, zimoun`: could you make this change on master, and then we'll merge it?
<M6piz7wk[m]><florhizome[m]> "Just look out for who merges a..." <- eh.. oke.. need to do school now so bayyy x.x
<zimoun`>PurpleSym, some python2- packages fails with sanity-check on core-updated-frozen but pass on master. What is the best?
<efraim>what package has Xwayland?
<efraim>wait, enlightenment is broken on master? how did I not notice?
<jpoiret>mutter needs it apparently
<jpoiret>xwayland was split from xorg-server iirc
<efraim>i'm testing an upgrade to git-annex on master ATM
<zimoun`>civodul: on master “guix build llvm” passes but the very same fails on core-updates-frozen
<zimoun`>civodul, I am currently checking if julia builds on core-updates-frozen. All the dependents do.
<henk_guix>hi, what can I do if a guix refresh -u failed? is there a force pull or something?
<florhizome[m]>efraim: idk I installed it a few days ago and it won’t start from sddm.
<jpoiret>xorg-server-xwayland is broken on c-u-f
<rekado_>zimoun`: sorry, I’m not following. There are R packages that fail to build on core-updates-frozen?
<zimoun`>civodul, efraim: for instance “guix build -e '(@@ (gnu packages julia) llvm-julia)'” builds on core-updates-frozen.
<zimoun`>rekado_, yes. For instance r-a4.
<jpoiret>efraim: are you looking for Xwayland on master or core-update-frozen?
<civodul>zimoun`: regardless, llvm-julia must be in llvm.scm or bad things can happen
<rekado_>zimoun`: oh, okay. I’ll look at R stuff on core-updates-frozen later today. I’m still building chromium on that branch. Want to upgrade my profile first before refreshing my checkout of that branch (and building things *again*…)
<civodul>71% of x86_64 substitutes right now on core-updates-frozen
<florhizome[m]>what should I set as XDG RUNTIME DIR for tests ? KWinFT builds fine elsewise
<M6piz7wk[m]>what's even the point of core-updates-frozen
<jpoiret>they're the big updates that cause massive rebuilds and so aren't pushed to master
<jpoiret>it's supposed to be merged every couple of months
<zimoun`>rekado_, hehe! I understand. I can send the fixes if it helps.
<M6piz7wk[m]>hm O.o
<jpoiret>(massive rebuilds *and* general breakage)
<M6piz7wk[m]>looks like something i could devops hell out of~
<zimoun`>civodul, ok. efraim: Do you plan to do it?
<florhizome[m]>hm i will try to just import the runtime dir variable then
<M6piz7wk[m]>Does GNU even have the infrastracture to run builds worth of 2M CPU cycles?
<zimoun`>I have to go. See you later.
<ssouth>If any reviewer has a moment, there is still my patch for strace on core-updates-frozen for AArch64 outstanding:
<the_tubular>This is a dumb question, but what does "core-update frozen" means ?
<the_tubular>I though Guix was rolling release, am I wrong ?
<civodul>ssouth: sure, looking into it...
<jpoiret>the_tubular: look 10 messages above
<the_tubular>Got it, my bad
<jpoiret>what i said is more about core-updates in general though, then the branch is frozen at some point to clean it up and test it and then merge it into master
<ns12>What is this "core-updates-frozen" thing?
<ns12>I still don't get it.
<jlicht>hey guix!
<abcdw>jlicht: hi!
<PurpleSym>sneek: later tell zimoun`: I’ll look into the failing python2-* packages.
<sneek>Will do.
<ns12>Why are sudden large rebuilds necessary?
<jpoiret>ns12: suppose you want to bump the gcc version used by default in guix for example
<jpoiret>you'd have to rebuild all packages using gcc for their build
<jpoiret>now that's quite a lot, right? that's why these commits are not pushed on master but on core-updates, which isn't used as a daily driver by users
<jpoiret>otherwise users wouldn't have any substitutes for a long time
<jpoiret>also, since it's often related to upgrading complicated/essential packages, it leads to breakage
<ns12>jpoiret: Why would upgrading gcc break many builds? I thought that gcc is stable.
<jpoiret>gcc was an example for rebuilds
<jpoiret>for breakage, see upgrades of all gnome-related packages
<jpoiret>or upgrades to the rust toolchain, Xorg, all that jazz
<florhizome[m]>Actually, not upgrading gcc does break some builds :^)
<ns12>jpoiret: Got it. Thank you for the explanation. Who donates the computing power necessary for the large rebuilds?
<ns12>florhizome[m]: Could you explain?
<jpoiret>there is a build farm at, which serves the substitutes on the default substitute server configured in guix
<ns12>jpoiret: Who owns those servers?
<florhizome[m]>some c++ packages will break with gcc 7.5, the current default. I don’t know the details, it prints stuff related to “filesystem”
<florhizome[m]>also don’t know if it’s only c++
<florhizome[m]>actually I think wlroots and this applies so yeah
<florhizome[m]>*wlroots is c
<jpoiret>not upgrading gcc won't break already-working packages
<florhizome[m]>yeah I meant builds /future builds.
<apteryx>civodul: I was trying to understand an interesting guix builder-specific problem when attempting to run the mutter test suite in the guix container, and got this reply about the build container not reaping processes because lacking a proper PID 1:
<PurpleSym>sneek: later tell zimoun`: Usually if python-build-system’s 'sanity-check fails the package won’t work properly afterwards. I’ve looked at a few failures and it’s a mixture between missing dependencies and non-python3-compatible packages. I’m very much in favor of just removing them.
<apteryx>PurpleSym: that sanity-check phase is very cool; caught a problem updating docker-compose on core-updates-frozen the other day
<apteryx>ns12: the MDC own the infrastructure behind the build farm (; many thanks to them!
<apteryx>most of it anyway; there are some other build machines outside of the MDC but the bulk of it is there
<PurpleSym>apteryx: Thanks ☺️. We should have more plausibility checks like this.
<jpoiret>civodul: was looking at timothy's mail and he mentions having to remove the mach64 module. Is that a problem or do we not care about it? I found out that caused the breakage, and it should be pretty simple to patch (although upstream might not react very
<jpoiret>fast given the date of the last commits on mach64).
<apteryx>PurpleSym: agreed!
<mbakke>apteryx: there are some workarounds for 'kill -0' in test suites in guix, see e.g. 'ngircd' or 'openvswitch'
<mbakke>re: sanity-check, I have a plan for fixing django and friends on c-u-f and should have time to hack on Saturday :)
<apteryx>mbakke: thanks!
<efraim>sorry I went away for a bit ~1.5 hours ago
<civodul>apteryx: interesting! you could add a pre-check phase that does something like: (sigaction SIGCHLD (lambda () (waitpid WAIT_ANY WNOHANG)))
<civodul>you need to catch waitpid exceptions too
<efraim>yes, I was looking for Xwayland on core-updates-frozen
<civodul>but anyway, it should reap those processes
<efraim>git-annex still FTBFS even with a version bump
<efraim>I assume it's related to the git version bump
<civodul>jpoiret: sorry, which email or issue are you talking about? there's too many of them :-)
<jpoiret>51938 * sorry civodul
*civodul looks
<jpoiret>whatever, I'm fixing it anyways, it's just a simply sed afaik
<jpoiret>Will try sending it upstream if it does work (it broke with xorg 21.1 iiuc)
<civodul>oops i mistakenly closed that bug
<civodul>jpoiret: alright, lemme know if/when there's a patch i can apply
<civodul>i'm also known as "git am" :-)
<civodul>so, mid-sprint review: how are we doing, comrades?
<apteryx>it's early here ;-)
<civodul>ah right
<civodul>well, it's first-quarter review then
<apteryx>but we have two set of patches restoring GNOME IIUC :-)
<civodul>oh, two?
<civodul>there's Timothy's and another one?
<civodul>we should be careful not to be too productive
<apteryx>guillaume fixing xwayland (but it seems incomplete -- luckily I have something for xwayland to, I should tip in)
<civodul>oh right
<civodul>are you reviewing that one?
<apteryx>I'm looking at 51900, yes
<apteryx>does (assoc-ref inputs "something") do the right thing when "something" is both an inputs and a native-inputs?
<apteryx>I'm guessing yes, but just checking, as I've also see the (or inputs native-inputs) pattern; but that must be for conditional inputs
<efraim>oh, xwayland is ... now a separate package
<apteryx>also seen*
<efraim>i'll leave xwayland alone, I see it's being worked on
<jpoiret>if a package is fixed in a commit upstream but there has been no release yet, what is the best practice? Creating a patch and applying it, or changing the origin to point to the upstream commit?
<jpoiret>ah, we use tarballs anyway, my bad
<efraim>gnupg-2.3.32 conflicts with flatpak, which propagates gnupg
<apteryx>you could always switch to git, if patching is too hairy
<jpoiret>should we look into moving various xorg things to git-fetch or are tarballs better?
<jpoiret>nono, it's just a single patch so it will be easy
*efraim has to run off for a while again
<apteryx>jpoiret: tarballs are preferred for pacakages very low/core in the tree to avoid the extra dependencies of git, but otherwise both are fine
<apteryx>in this case if the patch is easy to apply I think it's preferrable
<apteryx>what are you working on?
<setq>Is there some way to automatically update the environment variables after installing new software so that my application launcher (meta-key+! in Stumpwm in my case) can find the newly installed applications without needing to quit StumpWM and loging in again?
<civodul>efraim: re flatpak/gnupg, i suppose flatpak could propagate 2.3.32 or, better yet, not propagate gpg?
<jpoiret>setq: there is no general way to do that, the application has to support some kind of update of env vars itself
<jpoiret>ie shells can do it with "source", but not permanently
<setq>alright, thanks for the answer jpoiret.
<jlicht>setq: in general, after the first few installs of software you use, the env vars are set up already; it is only when you do something that requires a totally new env var that you need to restart your session
<jpoiret>(but note that with profiles and symlinks, we often don't need to update env vars at all, it will just work™)
<apteryx>civodul: nice idea about adding a signal handler
<zimoun>I am back. :-)
<sneek>Welcome back zimoun, you have 2 messages!
<sneek>zimoun, PurpleSym says: I’ll look into the failing python2-* packages.
<sneek>zimoun, PurpleSym says: Usually if python-build-system’s 'sanity-check fails the package won’t work properly afterwards. I’ve looked at a few failures and it’s a mixture between missing dependencies and non-python3-compatible packages. I’m very much in favor of just removing them.
<jpoiret>setq: maybe your launcher hashes the binaries it sees on launch once, and you would need to trigger a rehash
<vivien>So I have a patch to upgrade GNOME builder:, but meson is a pain because it isn’t wrapped
<setq>Thanks for the help jpoiret and jlicht.
<civodul>vivien: what do you mean by "meson isn't wrapped"? your patches yield working packages, right?
<vivien>It’s also a pain in guix home.
<vivien>civodul, yes, but GNOME builder usually builds packages with meson, and it’s not possible because the meson program does not set the python path.
<vivien>so meson fails with an exception
<civodul>vivien: so the 'meson' command doesn't find its own Python modules, right?
<civodul>ok, got it
<zimoun>PurpleSym: Ok, thanks for checking. I will do a list. BTW, some are already removed, please give at look to <> appliable to master.
<civodul>vivien: how 'bout making a user-visible "meson" package where 'meson' is wrapped?
<PurpleSym>civodul: I successfully built ghc@8.8 with git-minimal/fixed as well.
<vivien>I don’t know, the package definition has a comment:
<vivien> ;; Meson calls the various executables in out/bin through the
<vivien> ;; Python interpreter, so we cannot use the shell wrapper.
<zimoun>efraim, about llvm-julia, do you plan to move it from (gnu packages julia) to (gnu packages llvm)? Or do I send a patch?
<civodul>PurpleSym: yay! we can switch to git-minimal/fixed later on, after the sprint
<PurpleSym>zimoun: I see alot more python2-* packages on master than on core-updates-frozen. Looks like the two branches have diverged quite a bit :(
<civodul>vivien: i see; we can keep that one for later, i'll apply your GNOME Builder patches first
<apteryx>PurpleSym: in a good way I hope? (python2 packages been dropped on core-updates-frozen rather than added to master?)
<zimoun>PurpleSym, apteryx: it could be nice to push before the merge. :-)
<apteryx>zimoun: did you take care of removing their dependents packages as well?
<apteryx>(if any)
<PurpleSym>apteryx: Yes, I think so.
<apteryx>ok, neat
<zimoun>apteryx, yes. It is leaves packages. “guix refresh -l” says they are their own dependants.
<zimoun>python2-factor-boy seems removed on core-updates-frozen. All the others fails on master and are still on core-updates-frozen.
<PurpleSym>Actually, looking at the numbers it’s just three packages less. But alot more failures on core-updates-frozen.
<apteryx>That's kind of expected; as more and more Python libraries drop Python 2 support
<zimoun>I propose to send a series removing the ones which fails because Python 2 support. And a list of python2- which fails because sanity check. For instance, some are scientific packages and I am sure people want to fix them instead of remove. :-)
<pukkamustard>hi guix! ocaml-dose3 does not seem to build on core-updates-frozen. Reverting the fix that was applied with 91b29aa37394b660117e1d79927621db1344b7fe seems to make it compile again. I don't know why...maybe something in python changed?
<zimoun>efraim, civodul: in fact, julia fails to build. A test is failing.
<PurpleSym>zimoun: I think we have Python 2 packages in guix-past already. Why not add them there if they are *really* important?
<zimoun>PurpleSym, this is what I suggested many times. But people finding them *really* important do not do it; and they are not enough important for me for doing it. So instead, they stay on master and I am doing the janitor once they are broken.
<rekado_>I’m all for moving python2 things over to guix-past
<rekado_>requires some extra work and time, though.
<civodul>hi pukkamustard! if the fix breaks things instead of fixing them, we can revert the commit
<awb99>I am testing enlightenment window manager. And I have a highdpi display. I managed to customize the enlightenment desktop for that. But application menus and application fonts still are very very tiny. Any ideas where I can tweak that?
*rekado_ still builds qemu for some reason
<PurpleSym>Alright, these python2-* packages are failing on c-u-f for me:
<zimoun>PurpleSym: cool! Thanks.
<rekado_>python2-warpedlmm is mine. There’s no python3 variant.
<ekaitz>hi I need some package description suggestions... I'm packaging libresprite which is a fork of aseprite. Aseprite was a GPL software but now is proprietary and libresprite is a fork of aseprite from that moment. Should I mention that in the package descriptions? like... aseprite is stuck at the GPL version...
<rekado_>this is fine to move too guix-past
<jpoiret>wlroots doesn't build for me, something about -Dlogind_provider not being a valid option, anyone else?
<rekado_>PurpleSym: are these direct failures or also failures due to inputs failing to build?
<PurpleSym>Both, rekado_.
<rekado_>all the science stuff could be moved: scipy, seaborn, pybedtools, scikit-learn, statsmodels, etc
<rekado_>pandas, of course
<rekado_>many of these are already pinned at old versions because upstream dropped support for Python 2 a long time ago.
<zimoun>at first, it should be distinguished if they fail because Python 2 unsupported or because sanity check phase.
<pukkamustard>civodul: then I think we should indeed revert 91b29aa37394b660117e1d79927621db1344b7fe on core-updates-frozen. On master it is a fix. On core-updates-frozen it becomes an anti-fix. Could somebody check?
<jpoiret>mbakke: i see you updated wlroots last month but it doesn't build with -Dlogind_provider option which is not an option anymore in 1.14
<PurpleSym>zimoun: Sanity checks failing might mean you have to *add* more python2-* packages to satisfy requirements though.
*apteryx sent the xwayland patch they + mutter wip to 51900
<zimoun>PurpleSym, thanks.
<civodul>pukkamustard: i've checked and i confirm; will push shortly!
<civodul>thank you
<civodul>jpoiret: re wlroots, same error here
<jpoiret>i'm looking into it. It doesn't depend on elogind anymore because it uses libseatd instead
<PurpleSym>rekado_: I have logs for these which means they failed directly.
<pukkamustard>great! That makes my random sampling of ocaml packages on core-updates-frozen build again!
<zimoun>PurpleSym: for instance python2-sadisplay is removed by patch#51870
<zimoun>python2-sql too.
<zimoun>python2-libmc too. :-)
*rekado_ worries about updating the guix-bimsb* channel after merging c-u-f with removed python2 packages…
<jpoiret>civodul: turns out the seatd package was borked as well, didn't propagate dependency on elogind for pkg-config...
<apteryx>civodul: I wonder if we should have some init in the build env to properly handle signals; in dockerland they use something called 'tini'
<PurpleSym>zimoun: Maybe we can just keep them on c-u-f and do a full python2-* removal in a separate branch. I thought the -f meant frozen…
<PurpleSym>(No harm in having unused, broken packages.)
<roptat>hi guix
<roptat>PurpleSym, if they're broken and nobody uses them, I don't see the harm in removing them, even in c-u-f
<zimoun>PurpleSym, yeah for sure. The removal can happen after the merge.
<zimoun>roptat: many are working on master. But broken because sanity check, feature on core-updates-frozen only. :-)
<roptat>ah, I see, then we should fix them instead?
<jpoiret>civodul: I have wlroots and seatd building correctly, but have to go now so can't test them (and gnome-shell fails to build). Will send a patch in ~2 hours
<vivien>Is there a package that provides sys/sysctl.h?
<civodul>jpoiret: cool, thank you!
<civodul>vivien: libc?
<PurpleSym>roptat: Fixing is difficult to impossible. Some lack dependencies, some don’t support python2 any more.
<roptat>vivien, glibc
<civodul>apteryx: dunno, i think we never encountered that issue before, but if needed, adding a phase that calls sigaction might be enough
<zimoun>I think we should distinguish the ones which fails because Python 2 support and the ones because “sanity check” phase.
<roptat>vivien, you would have found with "ls /gnu/store/*/include/sys/sysctl.h" ;)
<roptat>zimoun, what's the sanitiy check phase?
<vivien>civodul, roptat, oh but it’s not in core-updates-frozen glibc 2.33 anymore, is it?
<zimoun>roptat, a new phase. Really cool feature!
<mbakke>jpoiret: I think the reason it no longer builds is because of a meson regression, it was working at the time
<roptat>vivien, dunno
<mbakke>also, seatd is not required, one can set LIBSEAT_BACKEND=elogind
<mbakke>(IIRC, don't have the configs at hand)
<civodul>vivien: ah, perhaps that header was removed, i forgot
<PurpleSym>roptat: 'sanity-check loads a Python package after building it to see if dependencies are missing.
<zimoun>pukkamustard, roptat: indeed ocaml-dose3 is failing. Because check phase.
<vivien>I think it was deprecated, and in 2.33 it has been removed.
<roptat>vivien, ah yes it's actually not the first time I encountered this it seems, I have a few in my browser history
<jlicht>building ghc, good times (and temperatures) :-)
<apteryx>bah, gst-plugins-base failed a test: elements_appsrc
<roptat>vivien, it was when we tried to fix java. It looks like we replaced it with "#include <linux/sysctl.h>"
<M6piz7wk[m]>You don't fix java.. you break it until it works
<vivien>roptat, that file isn’t in glibc either :(
<rekado_>apteryx: and gst-plugins-good also has a failing test (i reported it yesterday here)
<roptat>mh, then just remove the import, or wrap it around #ifdef HAVE_SYSCTL
<vivien>I’ll try that thanks :)
<roptat>probably that linux/sysctl.h is from icedtea itself
<apteryx>rekado_: OK, I'll try to disable them (pinging upstream in the process)
<zimoun>this llvm-9 think is really annoying. “guix build ocaml-llvm“ raises an ugly Backtrace on core-updates-frozen.
<samplet>jpoiret: Thanks for the patches for mach64 and nouveau! I’m looking at them now.
<civodul>zimoun: are you working on it?
<fcw>How do I add a new file (before the build stage) to a package? I see that Guix has a "plain-file" procedure ( Are there any examples of its use in a package definition?
<roptat>zimoun, I don't see a backtrace?
<roptat>in fact, it seems to download from ci without problems
<vivien>fcw, you would modify the #:phases argument to add a phase where you would use regular guile functions.
<zimoun>roptat, on core-updates-frozen?
<zimoun>civodul, I do not know what to do. )-:
<vivien>For examples, pick a module where packages similar to yours are defined, and grep for #:phases
<M6piz7wk[m]>zimoun: will you be the chosen one who will show krey how to package rust in guix?
<zimoun>rekado_: thanks for the R update. :-)
<roptat>zimoun, yes
<zimoun>M6piz7wk[m], what do you mean?
<roptat>zimoun, I'm on the very tip of the branch, 2b3046beca1b35e03f975fb95956f32eb46dee8c that was pushed less than 30 minutes ago :)
<fcw>vivien: I have already grepped. I am trying to package pgcli ( Unfortunately, one of its dependencies (python-pendulum), does not have a!), so the build for pgcli fails with: "no found".
<civodul>zimoun: alright, lemme give it a spin
<zimoun>roptat, using ./pre-inst-env it works. But not if you do ‘guix pull –branch=core-updates-frozeen’ then ‘guix build ocaml-llvm’. Or I have something wrong on my setup. :-)
<vivien>fcw, you don’t need to build python-pendulum, it’s already packaged in guix
<civodul>samplet: howdy! thanks for the GNOME patch series, you'll make everyone happy with that
<roptat>zimoun, oh? weird
<fcw>vivien: I know. The build for pgcli fails because python-pendulum does not have a
<vivien>fcw, as far as I understand, is only provided in the source, it’s not installed. Is it?
<vivien>Well, should it be installed?
<samplet>civodul: :) Thanks for the call to action.
<fcw>vivien: By "regular guile functions", do you mean procedures like "open-output-file"?
<vivien>Plus whatever you can find in (guix build utils)
<ekaitz> <-- I finally made libresprite like this, maybe we should mention on aseprite that it's not updated since 2016 because it became proprietary
<fcw>vivien: I declared python-pendulum in pgcli's propagated-inputs. When I try to build pgcli, it fails with "no found" because of python-pendulum. I will look into this. This is only my second attempt at packaging a Python tool for Guix.
<vivien>fcw, did you use pypi importer, guix import pypi pgcli?
<fcw>vivien: I am using "python-build-system".
<vivien>So you wrote the package from scratch?
<roptat>fcw, so python-pendulum is missing a, and it fails to build?
<fcw>roptat: Yes, apparently.
<fcw>Btw, I am quite new to this, so I might have missed some things.
<roptat>so how do pendulum developpers suggest to build it?
<roptat>oh, it uses poetry :/
<fcw>roptat: Is that bad news for me? ;-)
<roptat>I don't think we have a poetry-build-system
<roptat>zimoun, ah indeed this is weird, after guix pull I get a backtrace too
<fcw>"guix refresh --list-dependent python-pendulum" shows that python-orator depends on python-pendulum. I wonder how python-orator manages to build without failing ...
<fcw>vivien: Yes, I manually typed a package definition into a text editor.
<roptat>fcw, I'd say an older version of python-pendulum used to build
<roptat>mh, someone updated it without checking it was still building...
<vivien>fcw, I would suggest you to start from the output of "guix import pypi pgcli"
<rekado_>I don’t understand an error. I’m looking at the build failure of python2-send2trash. It fails in the ‘setenv’ build phase — but neither the python-build-system nor this package has such a phase.
<apteryx>these xkbcomp warnings are annoying: [...]Warning: Could not resolve keysym XF86KbdLcdMenu5\nErrors from xkbcomp are not fatal to the X server
<zimoun>civodul, ’make as-derivation’ does not report an error. Weird bug this llvm-9 stuff.
<rekado_>I’m probably missing something obvious – could someone please point me at what that is?
<rekado_>ah, sorry, I’m just dumb
<rekado_>I looked at the definition of python-send2trash
<rekado_>python2-send2trash does in fact add this phase
<apteryx>rekado_: I've reported the failure I saw here:, and disabled it with commit ab22743ad4. Do you have the build log for the failure you saw yesterday?
<zimoun>roptat: are you planning to give a look ocaml-dose3?
<roptat>zimoun, I think it was just fixed by ludo
<roptat>zimoun, yes, it builds now
<fcw>vivien: Okay. Thanks for the advice.
<vivien>zimoun, didn’t civodul fix it?
<vivien>Sorry ^^
<zimoun>ah yes, sorry the noise. I have missed it. :-)
<rekado_>apteryx: I only have the name of the test that failed
*rekado_ fixes more python packages that fail due to referencing ‘PYTHONPATH’
<apteryx>OK. I'll wait until we reproduce it again; as I'd prefer to report it upstream at the same time it is disabled
<vivien>Don’t worry for my meson patch, I’ll put the changes in a separate variable, but for now I test it.
<awb99>I have a highdpi display and am testing enlightenment. enlightenement really rocks. But all my fonts are so small. Text in applications is so small, and the menus in applications are small. I managed to configure the enlightenment desktop. But I cannot find a way to set menus and text size for normal apps. Any ideas?
<apteryx>awb99: what I do with ratpoison is use xrandr to set the DPI via --dpi
*civodul hits ENOSPC, means it's been a busy day
<apteryx>and then hack the Xft.dpi value accordingly in .Xresources
<apteryx>and then the font sizes in a few places... it's a mess
<civodul>apteryx: that'd only work for old programs like xterm
<civodul>"normal apps" do client-side font rendering via gtk and all that
<apteryx>GTK uses .Xresources
<civodul>oh? nice
<apteryx>at least some GTK applications (Gimp correctly uses the xorg server's DPI setting)
<apteryx>but others such as Icecat don't
<civodul>heh, so like you say, it's a mess :-)
<apteryx>when you're done configuring your DPI, you can start e.g. Inkscape, and see if an A4 sized document corresponds on your screen to the real thing.
<apteryx>by default xorg's dpi is 96 for compatibility with Windows (or something close)
*apteryx laughs
<apteryx>or perhaps s/windows/legacy systems/
<awb99>thatnks apteryx civodul !
<apteryx>civodul: re zombie process reaping in build container "Just keep in mind that SIGCHLD will be received by your PID 1 process. Which is probably some random script that wraps everything." (c.f.
<civodul>apteryx: PID 1 for us is the Guile process that executes build phases
<apteryx>what would PID 1 corresponds to in the Guix build container? ah, thanks
<civodul>(unless --disable-chroot)
<fcw>vivien: The output of "guix import pypi pgcli" is essentially the same as what I manually wrote. As before, pgcli will fail to build/install because python-pendulum does not have a file.
<fcw>I have made some progress by adding a file to python-pendulum.
<jlicht>does `guix time-machine --branch=core-updates-frozen -- build texlive' give "error: integer expected from stream" for others?
<civodul>zimoun, efraim: pushed a fix for the llvm/julia/cpp module circular deps
<awb99>so I have called xrandr --dpi 144
<awb99>but it does not seem to do anything.
<awb99>do I have to login / logout?
<podiki[m]>I think so?
<zimoun>ocaml-mlc is broken because a weird ld error.
<awb99>ahhh... It works for quassel. Just had to restart quassel after setting the dpi.
<awb99>Is the xrandr setting persisted ? Or do I have to call this on every startup ?
<podiki[m]>jpoiret: (on gdm and mutter) I'm missing it, don't see mutter in gdm inputs or it's graph, tried reverse graphs on mutter and didn't get to it either...
<podiki[m]>awb99: call on startup or put in something like an xinit (whatever is appropriate for you start X)
<apteryx>awb99: I put this in my .xsession (it's not persisted)
<apteryx>rather, I invoke xrandr in my .xsession
<apteryx>and yes, I think you have to relogin to see changes
<podiki[m]>mine is in .xinitrc, but that's what runs my session
<samplet>Is there much of a backstory to the at-spi2-core propagation issue (bug 51916)? I’d like to tackle it, but I think I might be missing some context.
<zimoun>civodul, thanks. touch gnu/packages/llvm.scm && make is now fixed. I miss why such error is not reported by Guile at compile time.
***sneek_ is now known as sneek
<awb99>so I have rebooted my machine.
<awb99>when I call xrandr --dpi 300 after starting, then quassel (my irc client) scales nicely.
<awb99>for chromium it does not work at all.
<podiki[m]>you may need gtk scaling settings too
<awb99>how do I change gtk scaling settings?
<podiki[m]> is useful
<rekado_>has python-matplotlib-documentation worked in recent history? Does anyone really care about it enough to fix it?
<podiki[m]>(though may need some experimenting to find what works well for you, and some programs like to scale, others less so...)
<jpoiret>podiki[m]: now that you're talking about it, it's rather a dependency to gnome-shell
<awb99>gsettings-desktop-schemas -> is this the package I need for gsettings?
<jpoiret>the question is, why doesn't gdm depend on gnome-shell? iirc, gdm is hard-wired to start gnome-shell through gnome-session
<podiki[m]>jpoiret: right, and in like Arch that is a dependency of gdm, but not for us it seemed?
<jpoiret>also, I'm back, patch to wlroots and seatd incoming
<podiki[m]>hum. okay, maybe something to disable in the future?
<podiki[m]>I was very confused last night not finding gnome-shell or mutter in dependency graphs, but knowing it must be true
<vivien>awb99, if you want gsettings-compile-schema, use glib:bin
<vivien>Sorry, ignore my last message
<awb99>so dont use glib:bin ?
<podiki[m]>mutter is not in gdm's guix size output either (which runs to 1.5G)
<awb99>guix install gsettings-desktop-schemas
<awb99>this did not bring me a binary gsettings.
<awb99>I am getting crazy :-)
<jackhill>on core-updates-frozen, network-manager-applet and gnome don't seems to get along?
<samplet>jackhill: That’s what I’m looking at right now. See bug #51916.
<jpoiret>podiki[m]: yes, it's not there, which is pretty weird
<samplet>It works if you remove at-spi2-core from the gnome package, but I’m not sure that’s a good idea.
<samplet>(I’m not sure if it’s a bad idea, either!)
<podiki[m]>jpoiret: okay, I'll leave it for now. but that type of hidden dependency could drive a person mad :) I always wondered why my gnome-less system tries to build it. guess time for sddm or slim!
<podiki[m]>jpoiret: worth filing a "bug" report for later?
<samplet>podiki[m]: GNOME has a habit of bundling a couple of subpackages in each package (like one package might have two libraries and an application). Other distros (e.g., Debian) split them up, but it’s harder in Guix. Last I looked, that was the reason our GDM package is so big.
<jackhill>samplet: cool. Yeah, I don't know enough about what it does to make a judgement either
<podiki[m]>thanks for the info
<podiki[m]>maybe I'll file something for future reference; gnome seems to be a packaging beast on guix
<samplet>The Debian trick is to build everything together and split up the outputs. Since everything ends up in “/lib” and friends, it’s easy.
<samplet>We would like to say “install this library here, that library there, and this other application over there”, but you configure the entire GNOME package in one go.
<podiki[m]>and gnome-shell depends on gdm, thoroughly confusing me
<samplet>podiki[m]: Right. That’s the same issue, IIRC. I think that GNOME Shell needs some library tucked inside of GDM, but the main part of GDM needs GNOME Shell. Since we can’t tease the subpackages apart, we have to do tricks to avoid the circular dependency.
<podiki[m]>the trick is so good mutter disappears into the magicians hat!
<podiki[m]>I'll file later as a "nice to do at some point" if it is possible to have gdm without gnome (mutter); otherwise I don't like it as a default login manager unless you use gnome anyway
<civodul>ah ha! Matrix users unanimously decide to leave the core-updates-frozen sprint
<apteryx>oops :-)
<vivien>Quick, while they’re away, let me say that XMPP is the best !
<vivien>Oops, I’m rebuilding webkit
<apteryx>try again, it should be on berlin now
<vivien>:( that must be on my end
<apteryx>what is the arg that a sigaction handler takes?
<apteryx>the Guile doc seems to lack this detail
<vivien>Well, I have to rebuild webkitgtk on origin/core-updates-frozen
<apteryx>it must be the disabling of a broken test on gst-plugins-base
<apteryx>I rebuilt on berlin but with a couple changes on top; guess I should push them now
<M6piz7wk[m]><podiki[m]> "and gnome-shell depends on gdm..." <- infuriating
<samplet>Maybe the best option is to just use at-spi2-core-minimal in the gnome package.
<apteryx>yeah; perhaps we can in later cycles have our regular variable at-spi2-core be at-spi2-core-minimal, and a at-spi-core-with-documentation or something
<jackhill>I've fixed the wlroots build on core-updates-frozen:
<samplet>apteryx: That makes sense to me. It’s a /very/ small problem to get hung up on. I’ll switch the gnome package to the minimal variant for now.
<apteryx>civodul: "inheritance should be in the same module"; good to know!
<apteryx>then I've sinned in (gnu packages python-xyz); some packages there inherit from (gnu packgaes python-build), I think.
<apteryx>samplet: sounds good
<apteryx>vivien: do you get a substitute for webkitgtk now?
<apteryx>you should
<vivien>apteryx, yes :)
<vivien>Thank you
<apteryx>I've pushed a 'wip-mutter-on-c-u-f' for mutter if anyone would like to try it
<apteryx>oh, it includes the currently broken pre-check phase
<podiki[m]>nice! what was the final status on the tests?
<rekado_>is anyone using screenkey?
<podiki[m]>I see mesa is bumped to the latest 21.2.5 too, very nice (too bad 21.3.0 just came out, but x.x.0 are development releases); mesa is so fast these days
<rekado_>I just fixed the build, but the tool doesn’t start. Fails with this error: TypeError: gobject `Screenkey+screenkey+Screenkey' doesn't support property `type'
<apteryx>podiki[m]: I'd like to get the zombie processes killed (the test uses dbus, which double forks processes, expected to be reaped by a PID 1 init)
<nckx>guix system: error: Invalid value for field cups: #<inferior-package cups@2.2.11 7c99d7884750>
<nckx>I know that inferior-package? != package? but this seems like a rather fundamental part of the abstraction :) What'm I missing?
<apteryx>as they cause the tests to run very slowly
<nckx>Also, hullo, and I hope the hackathing is going well.
<roptat>"so julien, do everyone in Belgium speak French and German?"... I don't think I'm the best suited to answer that question ^^'
<nckx>French, most. German, few.
<nckx>Und es ist das German from der Aldi.
<jpoiret>alright, so finally tracked down if there is or not a hard dependency of GDM on gnome-shell
<roptat>isn't Dutch more spoken than German?
<jpoiret>turns out (spoiler) the default configuration of GDM shipped upstream does in fact depend on gnome-shell
<jpoiret>but it isn't a hard dependency theoretically podiki[m]
<jpoiret>so gdm shouldn't indirectly depend on gnome-shell
<nckx>roptat: By a ridiculous order of magnitude, but we got a bit of Germany from the Germans to say sorry for the war business and it's since an official language, and the local population of that tiny part does speak German.
<nckx>Traffic signs etc. also.
<nckx>But only there.
<nckx>Belgium and its unhealthy relationship with language & identity is a topic fit for a separate IRC channel though.
<apteryx>civodul: I got: In procedure waitpid: No child processes
<roptat>nckx, thanks :)
<podiki[m]>thanks for investigating jpoiret; I know Arch has gnome-shell dep
<rekado_>nckx: we have a neat hack in (@ (guix profiles) packages->manifest) that allow an inferior-package to be used interchangeably with a regular package.
<jpoiret>that's because they don't really separate packaging defaults and system configuration
<podiki[m]>so this could be a future change, to unbundle gdm/gnome-shell, making gdm a more neutral login manager
<jpoiret>theoretically, if you change the default gnome session you could get away without having gnome-shell on your system
<rekado_>I suppose this part of “guix system” doesn’t use packages->manifest?
<nckx>Thank you very much for that pointer, rekado_! That'll save me much time. Any idea why it would break here, perchance?
<civodul>apteryx: yeah like i wrote, you need to catch 'system-error exceptions around the waitpid call, because it can thorw (in particular due to WNOHANG)
<jpoiret>anyone got gnome-shell to build?
<nckx>Probably not indeed. It seems like an ‘odd’ place to implement the abstraction.
<nckx>It's not universally taken.
<podiki[m]>I think that was waiting on the mutter fix before
<apteryx>civodul: i see :-)
<apteryx>I tried to use 'tini', but it said: [WARN tini (5027)] Tini is not running as PID 1 and isn't registered as a child subreaper.\nZombie processes will not be re-parented to Tini, so zombie reaping won't work.
<apteryx>not being root I don't think I can change that
<civodul>no need for an extra process IMO :-)
<rekado_>nckx: I felt the same when I first saw that.
<civodul>we're in 2021 and it seems that autotools are still the only build system that gets RUNPATH & co. right:
<apteryx>civodul: that's with meson 60
<apteryx>try 0.59. I initiated a conversation here, if you have something to add:
<crodges>Hello everyone. I'm missing something basic here. When I install a package (using debian for example) there's usually a config folder for the app inside /etc/<package>. I installed synapse as root, where do I find the respective configuration files? I know that I'm not supposed to used /etc directly in guix. For services I know that I have to modify config.scm, but what about packages?
<rekado_>crodges: packages install *all* their files to their own prefix directory
<rekado_>so the stuff that would end up in /etc on a traditional distro would end up in /gnu/store/…-name-1.2.3/etc/
<rekado_>of course that’s immutable
<apteryx>civodul: I tried this but the zombie processes still aren't reaped, as python-dbusmock reports: ERROR: timed out waiting for bus process to terminate
<podiki[m]>on meson, there were some changes with 0.60.1 and backwards compatibility with some options I thought? is that a better fix than 0.59 for ones that fail? (if that is related)
<rekado_>so for our services we usually call the executabel with an argument to override the default location of the configuration files
<apteryx>podiki[m]: that's something else (being more strict about things)
<podiki[m]>apteryx: ah
<rekado_>jpoiret: I’m trying to build it now.
<civodul>apteryx: ah, thanks for the tip!
<rekado_>we still have a lot of packages that use PYTHONPATH instead of GUIX_PYTHONPATH
<apteryx>time for sed
<jpoiret>oh, the fix is in the bunch of patches that timothy sent
<jpoiret>(how do you apply a bunch of patches with notmuch-emacs and magit?)
<rekado_>it would nice if we could avoid last minute surprises like this; a lot of this is caused by merges, of course. Maybe we could register a bug report and use the bug tracker as a core-updates merge checklist?
<crodges>rekado_: ok I don't see /etc inside my synapse install, only bin, lib and share. Even if I find it, where am I supposed to change configurations for a regular package that it's not on this etc?
<rekado_>crodges: this depends very much on the package
<rekado_>(I don’t know synapse)
<samplet>jpoiret: I pushed my patches, BTW. You should be able to get them from Git.
<rekado_>many packages read per-user configurations from a directory in XDG_CONFIG_HOME
<rekado_>those that don’t sometimes offer an option to provide a configuration file
<podiki[m]>crodges: do you mean for a homeserver.yaml config? that I think can go anywhere? (option to start synapse pointing to a file? I forget)
<jpoiret>samplet: Great! (the question still stands if anyone knows)
<rekado_>some others accept a location in an environment variable
<rekado_>yet others don’t do any of that and then they may need to be patched.
<podiki[m]>I agree we could use a discussion on better organizing, seems like core-updates ends up with a lot of stuff that could be done in separate branches (and then pushed to master)
<rekado_>hmm, don’t know why but I’m building icedtea@1 on c-u-f
<rekado_>podiki[m]: yeah, I feel we should not do too much in that one branch
<jlicht>jpoiret: I believe notmuch-show-pipe-message can pipe entire threads. Does that help? (Or not at all?)
<rekado_>we have enough build power for x86_64 to do several big branches at once
<rekado_>once they are done we could merge them, freeze, build for all architectures, and then hope to merge sooner.
<podiki[m]>rekado_: perhaps a "post-mortem" of sorts is in order after 1.4.0
<podiki[m]>yeah, leverage the CI
<jpoiret>well, I saw that, but didn't really know how to properly use that pipe with `git am` or magit. I'll look into it later (when i need it)
<podiki[m]>it has come up here and on the mailing list a bit, but from my perspective (as still pretty new) seems we could make it easier for ourselves with the great tools Guix and the CI give us
<podiki[m]>easier to test if someone can just pull on branch with a set of changes, too
<crodges>rekado_ thanks. podiki[m] yes, and the signing keys. You're right, it can go anywhere. I think I just need to generate everything in a proper place. I am a little confused about which user should run synapse (synctl) and if I need to create a herd service for it
<rekado_>podiki[m]: before mothacehe’s work on cuirass this wouldn’t have been feasible. I think cuirass is *much* better suited for a more flexible and independent core updates workflow.
<apteryx>rekado_: icedtea? oof
<podiki[m]>crodges: my synapse experience is limited to Arch (on a Pi), but I know it takes a bit to get set up
<rekado_>(I always build pigx to be sure that most common bioinfo tools build fine)
<podiki[m]>rekado_: certainly looks that way to me, let's discuss soon, make the next round easier :-D
<nckx>I was overexcited to finally have a real (paid) use case for inferiors. I understand they are a tech preview, and the manual makes no false promises, but I didn't realise that its ‘example’ use case is the only existing one so far. Is there no way to cast an inferior package to a regular one without writing much new code?
<rekado_>oh, lots of new rebuilds
<jlicht>jpoiret: I just checked: C-u notmuch-show-open-or-close-all to close all, manually open what you care about (e.g. the V2 patch series and then pipe into (cd your-repo; git am)
<rekado_>I’m building clutter now
<rekado_>I think I need a break.
<jpoiret>jlicht: Impressive! Thanks a lot :)
<crodges>podiki[m]: thanks, I'm have even more limited experience because I installed on debian but using yunohost, I have some digging to do
<podiki[m]>crodges: good luck! once set up doesn't need much, been using my synapse to consolidate all my messaging through matrix (and is how I chat on here right now)
<jlicht>jpoiret: and if you do a lot of guix-stuff, you could probably create a defun that fills in the (cd src/guix; git am) if the mail is a guix-patches one
<apteryx>rekado_: apologies, that must have been my last push that fixed xorg-server-xwayland
<crodges>poidiki[m]: thanks! I'm hoping to substitute my debian/yunohost server with a guix one in the near future.
<apteryx>rekado_: what were you working on?
<jpoiret>definitely, for now my process was very manual (c F on a mail in notmuch, w m C-y in magit)
<podiki[m]>I hope to successfully do a system reconfigure post-lunch with all these fixes I saw get merged. will report back and find some packages to fix
<jpoiret>i think we're getting to the point where i can't test the new changes without taking some hours to recompile xorg and such, sad
<jpoiret>jackhill: by the way, i have the patches for wlroots/seatd ready if you want, i was waiting to be able to test them though, and currently i'm stuck building a bunch of things
<civodul>nckx: inferiors are about mixing things from different revisions; is this really your use case?
<civodul>honest question because often time-machine is all one needs
<jackhill>jpoiret: cool, I could give it a go. Yeah, so far I haven't tried reconfiguring a system, just building things
<jpoiret>lord, gnome-shell depends on gnome-bluetooth… this is why we can't have nice things
<nckx>civodul: Yes.
<rekado_>apteryx: I’m working on python stuff and bioinfo packages that still use PYTHONPATH.
<rekado_>I don’t feel like building dbus now
<rekado_>I’ll wait for to catch up
<apteryx>if it's just a key couple packages I can help accelerate things
<jpoiret>by the way, does anyone use the greetd/seatd patchset?
<nckx>The need is for HPLIP 3.19 (‘a very old HPLIP’ that makes their tens of printers go brr instead of zonk), which itself needs an old CUPS, etc. So I can define custom packages (and even C&P from old Guix revisions) with some more effort, but I thought that inferiors' closure-like nature would be magic here.
<nckx>My mistake.
<nckx>civodul: ☝
<jpoiret>oh no, greetd is rust too, what a mistake
<apteryx>the world is rusting
<jpoiret>alright, gnome-shell manages to end up pulling fluidsynth through gtk -> gst-plugins-bad
<nckx>apteryx: :)
<civodul>nckx: got it; inferiors should work as long as the revision is post-0.15.0
<civodul>if that's not the case, you could add these packages to Guix-Past, but that could be tedious
<civodul>apteryx: Meson, SONAMEs, etc.:
<jpoiret>jackhill: I'll send my patches when I'm doing reconfiguring and they work properly (i can imagine libseatd not detecting elogind at runtime properly, and either patching that or wrapping wlroots compositors with an env var)
<jpoiret>if that's okay with you
<nckx>civodul: Thanks! What does ‘work’ mean here? I'm using (cups-configuration (cups ancient-cups) (extensions (list ancient-hplip…)) …) and it gives the error above: guix system: error: Invalid value for field cups: #<inferior-package cups@2.2.11 7c99d7884750>
<nckx>That error implies that there's nothing wrong with my inferior itself.
<civodul>nckx: oh i see; maybe things aren't well integrated somewhere
<nckx>It's just that the abstraction is not implemented where I thought it was.
<jpoiret>maybe the cups service wasn't made with inferiors in mind? since they're not really packages (i've seen (? package? p) (? inferior-package? p) in places)
<nckx>The magic is in packages->manifest.
<nckx>jpoiret: It ‘shouldn't’ be, though; that is not tenable.
<jpoiret>i agree
<apteryx>civodul: haha, thanks a lot for providing them with better hintsights than I could
<apteryx>and even tracing down the source of the behavior change
<civodul>we'll see where it goes!
<jpoiret>but if you manage to make your use-case work with a configuration like this, then that'd be a killer example for all the Guix doubters out there
<jpoiret>"yeah just tell guix that you want your cups to be from 5 years ago, no problem"
<civodul>nckx: that comes from define-configuration: cups-configuration defines 'cups' as a 'package' field, and somehow define-configuration assumes that it must match the 'package?' predicate
<civodul>it should be changed to package? or inferior-package?
<civodul>or just always return true
<civodul>or file-like?
<jpoiret>mhmmm, but don't you think the distinction package vs inferior-package will eventually always end up creating issues like this?
<roptat>is a package file-like?
<jpoiret>is there no way to make an inferior-package behave "just like a package"?
<civodul>roptat: yes
<nckx>civodul: Eh, guess what I changed locally ;-) But I don't want to upstream this, I think… (nor do I want to maintain a fork of Guix, that would defeat the purpose of using it).
<civodul>jpoiret: we could use this fancy concept called "inheritance"... we'll get there :-)
<nckx>Every keystroke of that change felt wrong so I thought I was way off.
<nckx>I'm not sure if I'm glad or not that you suggested the same thing. Appreciative, definitely, but I don't think glad.
<jpoiret>well, now that my macro skills have been properly trained, maybe we could look into guix records
<civodul>nckx: it's wrong to expect 'package?', so changing it to 'file-like?' would be good for upstream IMO
<jpoiret>but you could pass it things like (plain-file) then, right?
<civodul>jpoiret: indeed, looks like you've fallen for the macro game :-)
<civodul>jpoiret: yes
<civodul>which makes sense, for instance you could write a wrapper for cups as a computed-file
<nckx>Is ‘it's wrong to expect 'package?'’ documented anywhere? Do you not think it counter-intuitive to the point of being unacceptably dangerous? There's probably a cute name for code/names that make people do wrong things over & over again.
<nckx>‘package? is not a good way to test for packages’ is one of those. I *do* understand why.
<nckx>No absurd decisions were made but the end result is absurd.
<jpoiret>nckx: Maybe we could document Guix best practices™ (for example for error reporting and such) somewhere in the manual. I feel like it could help people contribute faster to the project without going on a wild goose chase of "let's find some examples of best practices, oh, this is from 2019 and they way they do it has changed since, damn"
<civodul>yeah i don't think it's documented but the whole point of file-like polymorphism is that you can choose what kind of file-like thing to write
<vivien>Is a monadic value a file-like?
<civodul>there are cases where you really want a package in the sense of a thing that is a file-like *and* has a name and version
<civodul>but that's quite rare
<nckx>‘file-like’ is a bit broad here but that's better than the current opposite.
<civodul>vivien: no
<civodul>vivien: but nowadays you should rarely need to fiddle with the monadic APIs
<nckx>civodul: <there are cases> Isn't that what we want here?
<jpoiret>civodul: I'd see one use-case for this, checking in service definitions for old package quirks and such. But maybe guix doesn't want to support the whole history of software quirks, and only guarantees the services it ships work with the latest versions
<nckx>It's cool to give users the tools to use /etc/motd as their CUPS package (and deal with the fall-out) but maybe it's a bit too (pointlessly) ‘empowering’? 😉
<nckx>Mainly thinking out loud.
<civodul>it's hard to tell what's right or wrong as a value for the 'cups' field
<jpoiret>nckx: but the use case for a wrapping script is pretty good though. Maybe I want my cups to be "cat > /dev/null"
<civodul>as long as it's file-like, it's potentially right, and i can see how it could be useful
<civodul>the wrapper example is used for dbus services in several places
<civodul>so it's not far-fetched
<nckx>jpoiret: That won't work.
<nckx>You want your CUPS to be a *package* that provides such a wrapper script, fine.
*civodul goes afk for a bit
<nckx>But the service has to be able to assume (possibly incorrectly; that's up to you) that it's a thing that has, I dunno, /share/ppd subdirectories.
<jpoiret>i agree, guix doesn't (yet?!) enforce strong typing, and that's why it's easier to script with it i think
<nckx>Even your wrapped CUPS would still behave like a CUPS package, not a single file.
<nckx>I feel like there still is a spot for ‘something any human would call a package’ that isn't ‘package-record-object?’ or ‘anything-remotely-file-like?’ but somewhere in between.
<nckx>But the difference of opinions here made me wonder if that's wrong.
*nckx shrugs.
<nckx>I'll replace my hard-coded #t with file-like?, thanks civodul.
<M6piz7wk[m]>nckx: Will you be the one who helps krey to fix reproducibility on his nice rust package submission~
<M6piz7wk[m]>looking at other rust packages they also fail the reproducibility test though so i guess i've already reached perfection there
<M6piz7wk[m]>i like the idea of benchmarking to define the expected build time to adapt timeout though
<jpoiret>I'd also be interested in the reason behind the ABI check in guix records. What causes an issue with rebuilding there?
<M6piz7wk[m]>jpoiret: +1 if i have to rebuild guix repo one more time i will scream
<M6piz7wk[m]>it takes 18 min and 42 sec on average to build and costs me like 120 Wh of power >.<
<crazazy>huh 18 mins doesnt sound too bad
<M6piz7wk[m]>it's torture for someone so impatient as me
<roptat>M6piz7wk[m], assuming you're krey, the patch looks trunkated. Do you really intend to only delete the line that says "fn ... {"?
<M6piz7wk[m]>+-fn add_arguments(arguments: &str, additional_arguments: Vec<(String)>, pre: bool) -> String {
<M6piz7wk[m]>++fn add_arguments(arguments: &str, additional_arguments: Vec<String>, pre: bool) -> String {
<M6piz7wk[m]>i am not deleting it i am removing the parentecies
<roptat>I don't see that last line
<roptat>uh, nevermind
<M6piz7wk[m]>eh.. um..
<M6piz7wk[m]>did you press arrow down or something
<M6piz7wk[m]>oh lol
<roptat>I found a bug in my text editor ^^'
*M6piz7wk[m] doesn't like submitting patch for that, but he can't just flip a flag in cargo/rustc to avoid the build failure
*M6piz7wk[m] also submitted request for a new version upstream
<M6piz7wk[m]>roptat: glad i could be the tool that enabled you to find the bug~
<M6piz7wk[m]>would even say that it's virtual headpat worthy effort
<roptat>virtual headpat then :)
*M6piz7wk[m] headpats himself then hmph
<jpoiret>M6piz7wk[m]: this was more about the internals of guix records and how we could look into being more helpful with the ABI check error (ie auto triggering rebuild or whatnot)
<M6piz7wk[m]>it kinda helps on the headache that the school gave me
<M6piz7wk[m]>jpoiret: yep would be nice.. i tried to cherrypick the failed things, but gave up after 5
<M6piz7wk[m]>then tried to make a script that checks for the output, but eventually ragequitted on simpsons
<M6piz7wk[m]>Why is guix even using mumi? none can adjust bots to build the new merge requests, run tests and format it up to the standard x.x
*M6piz7wk[m] regrets putting maple sirup in his tea
<nckx>nckx: Sorry, not today Satan, I have my own nemeses to conquer.
<M6piz7wk[m]>did i really went from people looking at my cool patch to people giving up on the patch bcs they have bug in the editor that they have to fix instead
<M6piz7wk[m]>THIS CLOSE.. to be a guix maintainer
<nckx>Sounds very plausible TBH.
<nckx>I can relate.
<roptat>M6piz7wk[m], ^^
<roptat>M6piz7wk[m], I'm having a look, don't worry
<M6piz7wk[m]>nckx: I have a cute horns that i wear in support of Free Software and white hair .. THAT IS NO WHERE NEAR SATAN 💢
<M6piz7wk[m]>roptat: i try, but guix makes me feel like playing a russian roulette
<drakonis>my body is ready for 1.4.0
<M6piz7wk[m]>something about lisp + functions breaking my brain
<roptat>M6piz7wk[m], it'll get better with time ;)
<M6piz7wk[m]>constantly making me just start writting rustlang and not notice it for like few seconds x.x
***stikonas_ is now known as stikonas
<M6piz7wk[m]>roptat: ye lisp always takes me so much time to get used to x.x
<jpoiret>can we have a guix build coordinator across all people sprinting right now? webkitgtk-with-libsoup2 is preventing me from doing any useful work :(
<podiki[m]>I'm also racing on webkit with libsoup
<podiki[m]>(hooray new machine, or it would take 5x longer on my old one)
<M6piz7wk[m]>jpoiret: last time i tried to do something about webkitgtk and libsoup2 i ended up being laughed at by my team so pretty sure that's a bad idea for me to touch that thing
<roptat>M6piz7wk[m], did you generate your patch with "git format-patch"? I can't apply it cleanly...
<roptat>fatal: empty ident name (for <>) not allowed
<M6piz7wk[m]>wait guix can actually do distributed builds?
<M6piz7wk[m]>with git show HEAD
<M6piz7wk[m]>it should apply cleanly though u.u
<jpoiret>that's how the build farm does it
<jpoiret>M6piz7wk[m]: there's a Contributing section in the manual with all info
<podiki[m]>(wow that package likes its memory at times, ate up my 16gigs)
<roptat>well, I got the code in my local repo, so I'll try building, linting etc
<jpoiret>what i learned is that not using git send-email and git format-patch is just asking for trouble
<M6piz7wk[m]>roptat: the git format-patch should generate the same thing.. maybe it's because of the comment?
<M6piz7wk[m]>but it applied cleanly to me
<roptat>ah maybe the comment
<M6piz7wk[m]>jpoiret: but it's long and confusing >..
<M6piz7wk[m]>and it told me to format using /etc/forma...el which hugged up formatting in the whole repo -w-
<roptat>I don't know how to apply that patch, but I can still test the package inside it, don't worry
<roptat>could you resend a patch that you generate with "git format-patch"? You'll also need to check you package definition with "guix lint rust-shell2batch", and add your additional patch to gnu/ (in alphabetic order, in dist_PATCH_DATA iirc)
<podiki[m]>(the manual is there for a reason though, and is pretty good)
<crazazy>Hey guys I'm wondering, how well does the `package` function sandbox things
<crazazy>like I want to try out guix, but like still have all the comfort of the nix buildign process
<M6piz7wk[m]>roptat: eh oke x.x
<M6piz7wk[m]>roptat: patch -p1 -i <dir> <patch-file> ?
<roptat>yeah, but then I loose the author information
<jpoiret>still hitting 500 with things such as
<crazazy>So I was wondering, how hard would it be to call out to nix building a package in that store, and then adding teh results of that package to your own store?
<roptat>M6piz7wk[m], oh I forgot, add a copyright line for yourself in rust-io.scm :)
<M6piz7wk[m]>ehh i didn't mess with rust-io
<M6piz7wk[m]>with crates-io.scm
<podiki[m]>crazazy: I'm confused, guix != nix, what do you mean exactly?
<bdju>what is /run/systemd? just noticed it in my df -h output
<jpoiret>(apparently webkitgtk-with-libsoup2 has just finished on the CI, but I can't substitute it either (and the derivation looks different to me))
<roptat>M6piz7wk[m], yes, crates-io.scm, sorry
<crazazy>well currently I use nix, but I used guix in a VM a bit ago and got a bit fustrated with how slow some things were going
<M6piz7wk[m]>roptat: okeoke
<crazazy>also at the fact every download had ts own download bar
<podiki[m]>I just finished it too (a tie!), was /gnu/store/8fq6fh90zbn3fz7kja831hl2bknqav78-webkitgtk-with-libsoup2-2.34.1.drv
<M6piz7wk[m]>Do i have to add the copyright? i like secrecy
<M6piz7wk[m]>legally probably yes
<roptat>M6piz7wk[m], yes, but we accept a pseudonym
<M6piz7wk[m]>so i can be barrack obama?
<podiki[m]>crazazy: guix on top of another distro should be self contained (but I have no experience with nix), everything in just /gnu/store
<roptat>M6piz7wk[m], :p
<crazazy>so I was wondering, with the whole "we're using full guile schme" thing, if I could just call out to an inferior nix process from my guix configuration, let nix do all the package building, and then have guix add the results that nix put in /nix/store in to guix's own /gnu/store
*M6piz7wk[m] is failing to figure out the git format-patch
<podiki[m]>jpoiret: I think I produced the same hash as the CI (but had pulled just before starting)
<jpoiret>we use (a slightly modified version of) the nix daemon crazazy
<roptat>M6piz7wk[m], "git format-patch -1" to get a patch for the latest commit you did
<podiki[m]>crazazy: I don't know, but there is build offloading, take a look at that?
<podiki[m]>(but still needs to be guix involved)
<roptat>crazazy, I think the answer is no, guix and nix can't communicate afaik
*M6piz7wk[m] hugged up the whole git repo and is now fixing it
<jpoiret>we'd love to have the daemon rewritten in guile though, but for now there would be no interesting way to make them cooperate i think
<crazazy>hmm but point is, can I make a build process that can make network calls that are not managed by guix?
<jpoiret>no, but nix cannot either right?
<crazazy>i mean probably if you disable some settings for the package manager
*M6piz7wk[m] sent a code block:
<M6piz7wk[m]>like this?
<M6piz7wk[m]>for the .. guix thing
<roptat>M6piz7wk[m], I meant for the guix patch, not the patch file, it's confusing
<M6piz7wk[m]>why do i always realize that i did stupid thing when it's 2 sec too late
<crazazy>you can also make the entire nix store writable
<roptat>M6piz7wk[m], we're all like that sometimes :)
<crazazy>its not advisable, and poorly documented for good reason
<crazazy>but possible
<jpoiret>crazazy: you can remount the store rw yourself, it's just a mount command tbh
<jpoiret>but I'd advise against it, also you cannot expect nix packages to be compatible with guix packages: we have different definitions and derivations
*roptat has a rw store for some reason
<roptat>it's not very comfortable ^^'
<jpoiret>i think what's bothering you is actually all the guix specifics, not the build daemon itself
<roptat>they'd also reference other derivations outside guix's store
<M6piz7wk[m]>patch submitted
<roptat>M6piz7wk[m], thanks
<M6piz7wk[m]>thank you now make meh guix maintainer~
<crazazy>but to conclude: I can't horribly break sandboxing rules in guix out of my own stubbornness right?
<M6piz7wk[m]>... or at least guix maintaining able
<jpoiret>you could by patching the daemon, but that's the same as in nix
<roptat>M6piz7wk[m], you're not a maintainer :p but a contributor, and that's already very cool :D
<M6piz7wk[m]>good enough~
<M6piz7wk[m]>i shall flex with FSFE with it
<crazazy>jpoiret: right got it, thanks!
<M6piz7wk[m]>*in FSFE
<jpoiret>alright, a small git pull got me to the same derivation as CI, no need to finish building this! podiki[m]: the substitute is available if you're still building
<rekado_>weird flex
<M6piz7wk[m]>rekado_: :P
<podiki[m]>jpoiret: I tied with the CI
<podiki[m]>on to gtk+-4
<jpoiret>gtk4 is also substituted i think
<jpoiret>i didn't have to build it
<podiki[m]>(I'm spoiled with a desktop I built a few months ago, love the 12 threads)
<podiki[m]>oh? must have just missed the sbustitute info, will restart
<rekado_>yo, the GUIX_PYTHONPATH thing: I see that a lot of packages already use GUIX_PYTHONPATH, but they still wrap their executables with PYTHONPATH. Should they instead use GUIX_PYTHONPATH for the wrapper as well?
<rekado_>Or doesn’t this matter?
<podiki[m]>(nevermind is on "check" already)
<M6piz7wk[m]>roptat: published in
<rekado_>we still have 61 matches of "PYTHONPATH in c-u-f.
<jpoiret>oh no, that wasn't true i guess, it seems to have errored on CI, but the details still give 500 so don't know why
<roptat>M6piz7wk[m], much better, thank you! I won't be able to push until another 4-5 hours, but unless there's something wrong, I should be able to push later this evening
<M6piz7wk[m]>it fails the reproduction though
<M6piz7wk[m]>well same way as other rust packages
<M6piz7wk[m]>it seems
<roptat>I'll have a look
*M6piz7wk[m] has no idea what he's doing
<roptat>I don't know enough about rust packages, but if others fail reproduction, then it requires a different fix, it shouldn't block new packages
<M6piz7wk[m]>like the binary is bit-by-bit reproducible
<podiki[m]>jpoiret: built for me, my ssytem reconfigured!
<M6piz7wk[m]>it just seems to use cache when using --rounds=2 that generates different json database for cargo
<podiki[m]>/gnu/store/dn4z4c158p8q16b4rw01dplqhbdyib7l-gtk-4.2.1.drv was my hash
<M6piz7wk[m]>and the files have different modify date
<jpoiret>i'm in the middle of a bunch of module-imports atm, will have a reconfigured system soon!
<podiki[m]>dare I reboot??
<jpoiret>rebooting as we speak
<jpoiret>no need to worry, thanks to Guix Rollback Solutions™
<podiki[m]>(technically i'm supposed to be doing work at the same time...)
<jpoiret>(disclaimer: if you edited the code for the Guix Rollback Solutions™, your warranty is void)
<podiki[m]>after all that mutter talk though, I think I'm still on gdm...
<M6piz7wk[m]>podiki[m]: technically i should be doing work, school and paying attention to gf and bf, but guix more important~
<jpoiret>aha yes. I'll do the switch to greetd soon, maybe with a guix-specific greeter
<apteryx>rekado_: in this case, it doesn't really matter because the PYTHONPATH wrapping is local to the package itself, e.g. it's not going to pollute a profile
<roptat>M6piz7wk[m], looks like this issue:
<M6piz7wk[m]>podiki[m]: wait is this a diclaimer bcs you are a google-alike employee where everything you submit during work hours is the property of the company? O.o
<jpoiret>worrying: GDM's password prompt is borked and doesn't hide the password at all, you type in plaintext
<podiki[m]>nope, just a (teaching) academic
<jpoiret>also the little icon on the right of it is missing apparently
<podiki[m]>oh wow
<M6piz7wk[m]>roptat: yep the diffoscope looks very similar to mine
<jpoiret>and... sway doesn't start
<podiki[m]>I'll try building a few other things, the CI is just doing x86-64 today?
<jackhill>jpoiret: sounds fine to me, I'll be on the lookout for them
<jpoiret>also, gdm does not let me switch VTs
<apteryx>jpoiret: did you need to fix mutter to get to that point?
<jpoiret>alright, so i'm getting (gnome-shell:617): mutter-WARNING **: 20:16:20.135: Failed to switch VT: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Permission denied in GDM
<jpoiret>fix mutter as in make mutter build?
<jpoiret>i don't think i have any patches applied for it except for a guix pull 10 minutes ago
<roptat>M6piz7wk[m], so shell2batch is only a library? no binary?
<apteryx>perhpas try using the one on the wip-mutter* branch, set the tests to #f, and remove/comment that pre-check phase
<jpoiret>will do! did you rebase the new c-u-f commits?
<podiki[m]>(ugh nevermind, i686 needs the full rust chain to be built)
<apteryx>podiki[m]: try using polkit-duktape instead of polkit
<rekado_>apteryx: but the wrapping *augments* the PYTHONPATH, it doesn’t replace it
<rekado_>and the rules for PYTHONPATH vs GUIX_PYTHONPATH also differ
<apteryx>rekado_: ah, then that's probably wrong in most cases, given (getenv "PYTHONPATH") going to be #f in most places
<podiki[m]>python-nautilus is failing, something with template files?
<podiki[m]>current log:
<rekado_>(with regard to ordering, where PYTHONPATH is controlled deeply inside of Python and GUIX_PYTHONPATH is controlled through our site file)
<jpoiret>apteryx: is that mutter update mandatory for GDM to work?
<apteryx>I don't know, but given your feedback it probably won't hurt
<podiki[m]>apteryx: mutter builds on c-u-f
<rekado_>apteryx: I’ll replace them all. Thanks for the quick chat to help me make up my mind :)
<podiki[m]>apteryx: do you know where polkit comes in for python-nautilus? not sure where to make the change to check building
<apteryx>I know the mutter I have is passing most of its tests suite, when not running in the chroot
<apteryx>s/chroot/build container/
<apteryx>and it has proper EGL support, which seems like something used by wayland
<M6piz7wk[m]><roptat> "6piz7wk, so shell2batch is..." <- mhm used for rust-cargo-make which is the end-goal
<rekado_>M6piz7wk[m]: then set #:skip-build? to @t
<M6piz7wk[m]>eh? It has to build for rust-cargo-make though
<rekado_>because rust doesn’t do dynamic linking anyway, so you don’t need to attempt to build the intermediates.
*M6piz7wk[m] confused
<apteryx>you just throw all the sources in the pit, and ask rust to build them into some fat binary
<jpoiret>i'll enable gdm debugging as well
<M6piz7wk[m]>eh O.o oke
<apteryx>podiki[m]: it's used by elogind I think
<apteryx>which is used by gtk
<apteryx>or something like that
<apteryx>podiki[m]: try to make it globally; I'm curious if that works (at the top level, based on (or (%current-system) (%target-system))
<apteryx>e.g. polkit on x86_64 would be the one we know, and on other architectures it'd be polkit-duktape
<podiki[m]>apteryx: we're discussing python-nautilus with its syntax failure (on curly braces)?
<apteryx>I was answering about the polkit vs polkit-duktape suggestion on i686
<podiki[m]>oh, don't think that was me. or at least I mentioned i686 only in that it needs everything built
<podiki[m]>I wanted to look at the python-nautilus build failure
<apteryx>OK, disregard what I said then ;-)
<jpoiret>apteryx: getting this when building
<jpoiret>i cherry-picked only the last commit on wip-mutter, is that ok?
<apteryx>yep, that's all there is to it
<apteryx>yeah, comment out the pre-check phase, it was buggy in that commit
<apteryx>and set the tests to #f, as they won't pass in the build container yet
<podiki[m]>I'll look at python-nautilus later, seems those shouldn't be compiled as they are templates; good luck all in the meantime!
<apteryx>podiki[m]: thanks for the help :-)
<podiki[m]>I'll also reboot eventually and see how that turns out :)
<M6piz7wk[m]>what does "criminally outdated" mean? O.o
<jpoiret>3.36.1 to 41.2 seems like a big step to me (also funny versioning scheme)
<jpoiret>can't wait for the 41.2 -> 1.2 upgrade
<M6piz7wk[m]>jpoiret: they are pulling the google on things eh? apparently 1B marketing idea
<jpoiret>apteryx: looks like our version of gnome-shell wants mutter-clutter-8 though, and this gives mutter-clutter-9
<jpoiret>(pkg-config wise)
<apteryx>hmm, which version is gnome-shell at?
<jpoiret>hmmmm, actually, we're not ready for Gnome 41 on cuf right?
<jpoiret>gnome-shell is 40.5 for me
<jpoiret>maybe i missed a commit on wip-mutter
<jpoiret>i think it'd require to update gnome to 41
<drakonis>apparently gnome can be upgraded piecemeal now
<apteryx>jpoiret: 41 is supposed to be a minor upgrade compared to 40 (stability, fixes)
<jpoiret>well, not mutter and gnome-shell it appears
<jpoiret>mhmmmmmm, still not convinced
<jpoiret>mutter 40.x should work though, no?
<jpoiret>i'll reboot with gdm debugging on, and with the old mutter
<samplet>It looks like mutter 40.6 was tagged two weeks ago, too. (I had the same question about mutter 41 with GNOME 40....)
<lilyp>vivien: w.r.t. gnome-builder, what's the thing that still requires libsoup-2?
<mmarshall540>Is this a good place to ask for help with an installation problem?
<jpoiret>I see lots of critical errors in the gdm logs
<jpoiret>not good
<jpoiret>mmarshall540: of course
<mmarshall540>Thanks. Trying to install Guix System, I go through the guided installation accepting the defaults, and everything seems to go fine... After rebooting, I get the boot screen with the Guix logo and press return to boot Guix... But after a fair amount of text flying by (including the brief appearance of a login prompt), it ends up at blank screen with a flashing cursor. Nothing else happens, and I can't reach any other TTYs.
<jpoiret>GDM might be failing to start for some reason
<jpoiret>can you boot into grub, press e on the option you want to boot, and add "nomodeset" to the command line?
<mmarshall540>Will try that...
<mmarshall540>Is the command line the one that starts with "linux"?
<mmarshall540>(not search or initrd)
<vivien>lilyp, gnome-builder itself, and more specifically the rust-analyzer plugin
<nckx>mmarshall540: Yes.
<jpoiret>yes! mmarshall540 it should be pretty long and have --root in it
<civodul>nckx: re file-like?, SGTM!
<civodul>but yeah, we should also have a <package> type hierarchy at some point
<apteryx>civodul: re sigaction; the handler gets 17, whatever this is (the pid of the terminated children I guess?), while python-dbusmock attempts to SIGTERM process 5485. Odd.
<jpoiret>jackhill: looks like libseat doesn't work as expected with the patches
<vivien>lilyp, although it builds fine if you substitute* libsoup-2.4 -> libsoup-3.0 in "src/plugins/rust-analyzer/"
<vivien>Maybe it’s worth dropping libsoup2 that way?
<lilyp>you can try and check whether rust-analyzer still works, but only if you have time to waste
<mmarshall540>jpoiret: and nckx: It still goes to the flashing cursor. I'm wondering if I could change something in the system configuration before finishing the install that might help?
<lilyp>I do think that moving to soup-3 where we can is the right decision though
<jpoiret>well, the thing is, we don't know what may be causing this. You could try removing gdm-service-type from your services
<nckx>Same. I just saw your command line question, I have no idea what's going on.
<mmarshall540>jpoiret: Will try that. It does remind me of a problem with GDM that I had on another computer. Not the same machine, but similar hardware.
<civodul>apteryx: 17 = SIGCHLD
<civodul>then you need to call waitpid, and that will either throw or return a PID + "exit status"
<apteryx>but yeah, I was calling it as you suggested with (waitpid WAIT_ANY WNOHANG)
<apteryx>will inspect the return value of waitpid
<civodul>maybe you can simply ignore the return value as there's nothing PID 1 can do
<apteryx>yeah, it's too understand why it doesn't work
<apteryx>as in, the children processes that have been killed (and should have been waited for by our sigaction) are still visible to python-dbusmock
<civodul>you can print something from the handler to make sure it's called
<vivien>pan (the last user of gmime-2.6) has experimental support for gmime 3.0. Should we enable that and get rid of gmime-2.6, or keep gmime 2.6 for pan?
<apteryx>perhaps the later? I don't know what pan is.
<vivien>It’s some sort of a news reader, I think?
<vivien>I can run it with gmime 3.0
<roptat>looks like I can't access build details on ci:
<apteryx>hmm, at least tho cogl suite passes with current mutter; so the clutter failures must be due to /bin/sh or similar
<apteryx>current mutter = mutter in wip-mutter, sorry for the confusion
<jpoiret>roptat: this has been the case for a while now
<apteryx>civodul: not sure if it helps, but I've scp'd what I'm inspecting at /tmp/whzlk50cwl90mii3sj1ifkzgp6v9l9w2-mutter-41.0.drv; you can grep for things like "ERROR: timed out" to see what python-dbusmock is doing. The handler I installed should print 'got-pid upon encountering SIGCHLD and 'waitpid-returned: iw waitpid returned (rather than raised).
<apteryx>(on berlin)
<apteryx>the handler doesn't seem to receive and SIGCHLD for the doubly forked dbus processes
<apteryx>(that are terminated by python-dbusmock with a SIGTERM)
<apteryx>around here:
<civodul>apteryx: when waitpid returns a pair with 0 in its car, that means "no process was collected"
<civodul>so in this case, you get SIGCHLD prolly because of the child processes started via invoke and system* that terminate
<civodul>but waitpid gets nothing because there's already been a waitpid call under the hood for these processes
<civodul>however you're prolly not getting SIGCHLD for the dbus processes
<apteryx>seems like this is the problem yes (not getting SIGCHLD for the process I'd like to wait for)
<civodul>you could check whether this guile process really is PID 1
<civodul>if not you'll have to use the "child reaper" prctl call from (guix build syscalls)
<civodul>so yes, it's really PID 1 apparently
<civodul>so i guess i dunno :-)
<civodul>you could also run 'pstree -p' or similar to check what the process hierarchy looks like
<apteryx>good ideas!
<ekaitz>hey I have a weird question: how difficult could it be to make a guix pack flatpak format?
<ekaitz>do you hate me a lot just for proposing this?
<apteryx>shouldn't be too hard? you should give it a try!
<apteryx>I intend to tackle RPM soon (TM)
<civodul>ekaitz: i think flatpak is not just a "format"; they have this notion of "runtimes", which are libraries taken from granted
<civodul>as if you would cut the dependency graph
<ekaitz>yes, I'm reading a little bit about it now
<civodul>now, if you look at (guix scripts pack), you'll see the different backends
<vivien>ekaitz, since runtimes are not built reproducibly, maybe a first step would be to make them with guix
<civodul>the backends are relately small so you could give it a spin
<civodul>maybe one can create valid flatpak images that do not rely on any "runtime"?
<vagrantc>yeah, i just installed my first flatpak the other day and though "hmmmm... would be nice to do with this guix instead" :)
<ekaitz>hmm sounds like a good weekend research project
<vagrantc>yeah, that would be nice.
<apteryx>civodul: mentions of automatic child reaping; byt setting the "disposition" (?) of SIGCHLD to SIG_IGN; could that be a way?
<vagrantc>or maybe guix could actually be used to build it's various runtimes?
<civodul>if vagrantc uses flatpak, then i think distros are really doomed :-)
<vagrantc>e.g. so if you have two flatpaks built with guix they can share the same guix-built runtime
<civodul>apteryx: ah yes, maybe?
<ekaitz>I'll give this a spin this weekend and I'll keep you all informed :)))
<ekaitz>thanks for the support
<vivien>Flatpak is a pain, because to install a flatpak, you need a runtime, and the runtime is hosted on flathub (alongside proprietary flatpaks). So, if we could get these runtimes outside of flathub, that would be great.
<vagrantc>using flatpak did feel a little dirty, but i wanted to try a couple apps and ... may as well see this newfandangled flatpak thing and how it works
<vagrantc>it looks like you don't have to enable flathub, so in theory you could use a runtime from elsewhere ...
<vagrantc>guixflat ... a little apartment of your own
<ekaitz>yeah it sounds a little weird but I should give it a try
<ekaitz>is AppImage better? :)
*vagrantc shrugs
<apteryx>oh, I was thinking about AppImage all the way
<ekaitz>both sound equally bad to me :)
<vagrantc>i've tried flatpak a total of one times, appimage zero times ... although there is *another* sketchy app i'm curious about available via appimage :)
<apteryx>I think AppImage format looked feasible
<apteryx>from a guix pack point of view
<ekaitz>apteryx: yeah, it's "simpler" from that perspective
<samplet>Hello from GNOME 40 on c-u-f!
<podiki[m]>I use flatpak for a few things (like Element, what with the whole javascript/electron thing)
<podiki[m]>works fine, especially after I ironed out a few fixes that got merged here
<podiki[m]>i like the idea of our own paks or runtimes, would be cool
<apteryx>samplet: really :-)
<samplet>I reconfigured on commit fc3e4ef0db1e6c4c83819e5b8d5a7571a3d656c1 with no other changes.
<mmarshall540>jpoiret: Success! Removed all references to desktop, redid the install and am now able to login at the console. Guess I'll experiment with installing a non-gdm display manager from here. Thanks for the help!
<vagrantc>how goes core-updates* ?
<vagrantc>i checked the other day that diffoscope builds on core-updates-frozen, which pretty much builds half of guix
<apteryx>samplet: awesome!
<apteryx>that's great news
<samplet>Let’s see if I can build my normal user profile, too.
<apteryx>how many packages do you have in there?
<samplet>Very few. I’m a pretty boring computer user. :)
<samplet>Ouch, I’m not going to build Icecat, though.
<apteryx>civodul: would (sigaction SIGCHLD SIG_IGN) in Guile be equivalent to signal(SIGCHLD SIG_IGN); in C?
<gbrlwck>to build my user profile on c-u-f i first `guix pull --branch=core-updates-frozen` and then `guix package -u` ?
<apteryx>yes, or via time-machine
<apteryx>or you build a special profile with -p /tmp/your-new-profile -m your-manifest.scm
<civodul>apteryx: yes
<podiki[m]>if anyone is looking for simple packages to fix, python-nautilus fails (compiling something it shouldn't?) and ledger fails a test suddenly (looks like a simple pathing issue)
<apteryx>weird, it throws system-error "system" "~A" ("No child processes") (10) directly
<podiki[m]>I would work on them but gotta finish something else first
<notmaximed>new patch series for openat, chmodat, chownat, statat, ... bindings:
<notmaximed>yes, that's more #guile than #guix, but I don't have access to my password at the moment, and guix needs to work-around the lack of these procedures in some places
<jpoiret>mmarshall540: ideally you could try to use gdm-service-type but passing the debug? #t field to it, so we could get gdm debug logs and see what's wrong
*apteryx plugs the incantation after the first (system "pipewire&") line
<apteryx>samplet: icecat is at 42626/48941 on berlin
<gbrlwck>guix pull --branch=c-u-f fails on "guix-package-cache.drv"
<gbrlwck>apteryx: what's the command to use with the -p and -m options?
<apteryx>guix package
<notmaximed>those (openat et al) patches would allow fixing
<samplet>Epiphany keeps crashing on me.
<vagrantc>only guix lint typos on guix master left are "allows to" ... which take a little more thinking
<mmarshall540>jpoiret: Is there an example config.scm where that debug field is used?
<kaelyn>Hello #guix! I was finally enticed onto the channel by the 'core-updates-frozen' sprint declared yesterday. :)
<podiki[m]>we're still sprinting! (well not me, I'm "working" first)
<podiki[m]>welcome to the fun
<samplet>The new GNOME about screen is very nice! It has a giant Guix logo and says the OS Name is “Guix System”. Pretty classy.
<kaelyn>Thank you! I'm actually about to mail my second patch for the sprint (my first one was technically a little early as I sent it yesterday)
<gbrlwck>when i build my manifest how do i specify the branch (c-u-f)?
<gbrlwck>ah, is it "--with-branch=core-updates-frozen=master"?
<jpoiret>mmarshall540: let me pull mine
<jpoiret>samplet: are you running Gnome with gdm?
<samplet>jpoiret: Yes.
<jpoiret>i'm having some permissions issues with elogind/dbus/polkit/idk what
<civodul>does anyone know of a package using go-build-system that can be cross-compiled?
<civodul>i'm looking for a working example
<apteryx>jpoiret: perhaps his?
<jpoiret>looks like it, thanks! (i thought it was just some configuration problems on my part)
<jpoiret>dbus is a pain
<jpoiret>mmarshall540: you can use this for your services field for example (adapt it if you have other services modifications)
<samplet>I’m pretty impressed: I’m getting substitutes for icecat and libreoffice on c-u-f.
<apteryx>samplet: so you are using xorg-server, right?
<apteryx>GNOME on top of xorg
<apteryx>and that works on commit fc3e4ef0db
<apteryx>(is it even possible to use our GNOME desktop service with Wayland so far?)
<samplet>apteryx: Yes. Plain old X.
<samplet>I thought I saw a patch or something about GDM and Wayland, but I haven’t investigated yet.
<jpoiret>yes (i'm the one who wrote it!)
<jpoiret>if you're using c-u-f, just add wayland? #t to your gdm-configuration-type
<apteryx>very nice!
<samplet>jpoiret: Ooh! Cool thanks! I will try it.
<apteryx>civodul: pid is indeed 1
<apteryx>oh, it seems to have worked! (sigaction SIGCHLD SIG_IGN)
<apteryx>the test suite zipped through
<notmaximed>civodul: ^ (the openat & friends patches) (I don't want to single anyone out, but it has been 8 months since the original patches without replies by guile maintainers, and you're both a guile and guix maintainer IIUC, and you were involved with the work-around in guix ...)
<apteryx>ah, nevermind, (exit status 255 or signal 127 SIGinvalid)
<apteryx>every test failed on that :-P
<apteryx>I guess because someone else is interested in the return status of child processes, and (sigaction SIGCHLD SIG_IGN) shortcircuits that
<samplet>jpoiret: GNOME + Wayland works well in a VM. I’ll try it on my laptop whenever it finishes building VLC.
<jpoiret>watch me rebuild the whole WM+DE stack because i patched elogind
<jpoiret>iiuc, there should currently be an outstanding bug for anyone running c-u-f
<jpoiret>elogind should not be using polkit
<civodul>notmaximed: yes, you're right; sorry about that, i'll try to catch up :-/
<jpoiret>elogind causes gst-plugins-base to be rebuilt because of sdl -> pulseaudio
<jpoiret>i don't think i'll see the end of this rebuild today
<jpoiret>is grafting fast/can i hope that grafting a patched elogind will work?
<florhizome[m]>plank works :)
<civodul>jpoiret: sure, you can try that
<jpoiret>i don't understand though why sway wouldn't work if polkit supported isn't enabled in elogind. What kind of polkit actions/policies are needed to make it run?
<civodul>"guix graph --path gst-plugins-base elogind" is interesting and kinda unexpected
<jpoiret>ok, i'll try grafting it then
<civodul>i know nothing about sway
<jpoiret>it's more of a libseat thing though, but i'm in the dark as well
<jpoiret>if i saw correctly, the only polkit policy we have is one for wheel users. Does that mean that sway won't work for users that aren't in that group? doubtful
<jpoiret>civodul: i know some channel that was using it until this week :)
<apteryx>civodul: 2014!
<darth-cheney>hey all, quick question about packaging a guile module
<darth-cheney>Am I correct in saying that I specify my other guile dependencies in the `inputs` section? If so, should I expect the referenced packages to be installed when I install my package on a fresh setup? Right now I cannot get the latter to work and I'm not sure why
<darth-cheney>For refernce, here is my channel with its single package def:
<notmaximed>propagated-inputs + native-inputs (not 100% sure about the latter, but it's required when using gnu-build-system & cross-compiling, due to how guile's module system works)
<notmaximed>propagated-inputs: because guile doesn't have things like RUNPATH or RPATH or the like
<darth-cheney>so plain inputs are things that would only be required for the build itself to work
<darth-cheney>not necessarily for the resulting program/library to run
<notmaximed>basically, yes, though reference scanning is a thing
<darth-cheney>sub-question: how can I refresh the channel definition on my own system once I've updated it in a repository? guix pull seems like overkill
<notmaximed>i.e., if this was a C library, gnutls wouldn't need to be in propagated-inputs, because C (actually ELF) has RUNPATH, which hardcodes the locations of the library dependencies
<notmaximed>darth-cheney: Use -L or GUIX_PACKAGE_PATH (or even -f in this case) instead of a full-blown channel?
<darth-cheney>notmaximed: yeah I might just do that for now. Though I was planning on putting all my custom guile modules into my own channel etc
<notmaximed>channels are mostly for sharing package definitions with others in my experience, and less useful for local hacking
<darth-cheney>makes sense
*notmaximed leaves
<samplet>Okay. I’m gonna reboot into Wayland.
<jpoiret>alright, rebooting after grafting elogind
<podiki[m]>i'm also gonna reboot, see how gdm did on the upgrade (and then immediately get rid of it I think :-P)
<podiki[m]>godspeed to us all!
***stikonas_ is now known as stikonas
<podiki[m]>gdm worked, no wokiness that I could tell! though the guix logo at the bottom was gone
<apteryx>good to know!
<apteryx>thanks for testing
<apteryx>civodul: should %prctrl be exported from (guix build syscalls); or is it intended to be wrapped in something nicer
<podiki[m]>that may be my last gdm boot, after this "must include mutter" matter :)
<apteryx>my call is simply (%prctl PR_SET_CHILD_SUBREAPER 1)
<samplet>Well, I now have everything running just as if c-u-f were merged. I’m even running Wayland now. I will keep running it and see if I have any trouble.
<apteryx>samplet: terrific!
<samplet>Thanks to everyone for doing soooooooo much work to get this all working!
<podiki[m]>yeah, huge changes in just the last ~24 hours
<jpoiret>now i get interactive authentication required, which is weird: the Activate dbus action of systemd/elogind should not have any policykit filtering iiuc
<podiki[m]>is there an easy way to exclude python-build-system for trying to build some files?
<apteryx>indeed, thanks to everyone who contributed to this successfull hackaton :-)
<podiki[m]>should I remove and restore the files after build somehow? (I think the files are needed, they are templates in python-nautilus, but I don't know how it works exactly)
<jpoiret>wow, so gdm restricts your ability to change VTs
<jpoiret>through Polkit too
<podiki[m]>security I guess?
<mmarshall540>jpoiret: The end of /var/log/gdm/greeter.log indicates the following, "/gnu/store/[...]-xf86-video-ati-19.1.0/lib/xorg/modules/drivers/ undefined symbol: exaGetPixMapDriverPrivate"
<jpoiret>oh! nice, we get an actual error
<jpoiret>didn't believ it was going to be that easy, although the problem is not yet resolved
<mmarshall540>I learned a lot just trying to get the error.
<civodul>apteryx: it's meant to be wrapped into something nicer
<kaelyn>So I just switched my main computer over to c-u-f and rebooted, after getting hit by a graphics card reset again (it included upgrading from a 5.14.8 kernel to 5.14.15, which includes some potentially relevant fixes). ^.^
<samplet>jpoiret: When testing in a VM, I could change VTs with GDM on X but not Wayland.
<jpoiret>mhmmm, maybe this is the issue
<jpoiret>seems like Polkit really wants us to do an interactive auth for some reason
<jpoiret>either to Activate using systemd/elogind's login, or to switch VTs (again using elogind)
<podiki[m]>I can switch VTs with GDM on X at least; also see a missing icon where you type password (but password remains hidden); missing Guix logo was the only other thing I saw
<jpoiret>yes, i could not reproduce the visible password glitch