<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 <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 :( <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>Although I strongly suspected exactly that. <nckx>(Still, thanks mbakke ☺) <civodul>right, you can't travel before 0.15.0 <nckx>Okay, that should just be an explicit check. Hick, I even read the manual, and didn't see that mentioned. <podiki[m]>speaking of graphene, python graphene related stuff was broke last I checked, tried to update but ran into dependency issues <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>Got it: (guix packages) package-transitive-inputs <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... <M6piz7wk[m]>podiki[m]: Because someone has to take care of them until they grow up :P <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 <bavier[m]>the source files are in the saved build directory. <bavier[m]>It'll print the directory name with the failure message <M6piz7wk[m]>oh ccache won't help me cache the build of guix repo <M6piz7wk[m]>is there a way to set up a distributed build for guile? <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 <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? <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]>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 <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]>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 <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 <Guest42>im stuck on some unbound variable stupid error <rekado_>Guest42: please paste the output on a paste site and post the link here <rekado_>it’s unlikely you can be helped when we can’t see the error message. <M6piz7wk[m]>Guest42: last time that happened to me on guix installer it was broken USB drive stick <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 <M6piz7wk[m]>then my best guess is that the guix installation on the external drive is corrupted <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]>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>didnt know it was corrupted cuz it worked fine <Guest42>everything works fine except for system init <M6piz7wk[m]>I don't understand what are the implications of the failure -> elaborate <Guest42>except i cant instll guix on anither drive lol <M6piz7wk[m]>probably requires you to make a new installation medium <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 <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 : ) <sneek>Welcome back civodul, you have 2 messages! <M6piz7wk[m]>TODAY IS THE DAY WHEN I THROW MY MONITOR OFF OF THE HUGGING WINDOWWWW <M6piz7wk[m]>this hugging thing keeps refusing to recognize my packages <abrenon>which from an environmental perspective is an excellent thing <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 <abrenon>ah… mastodon, the place where it all happens : ) <M6piz7wk[m]>why do i have a feeling that the `#:rust` doesn't do sh@%! <vivien>So, for the GNOME / nm-applet at-spi2-core issue, the plan was to remove propagated inputs from network-manager-applet, IIRC, right? <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>vivien: did you see my message about Vigra? ↑ <vivien>civodul, I missed it, but that’s true, it was fixed in the mean time <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 😢. <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. <civodul>PurpleSym: ah! then let's do the same there <zimoun>on core-updates-frozen, I note an issue with llvm-9, e.g., guix show llvm. Does someone is working on it? <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? <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 *vivien managed to crash emacs <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 <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? <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 <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 <vivien>florhizome[m], you mean the home page or download URI? <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 <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 <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 <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) <Guest42>i reinstalled guix and the problem persists!!!! <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 <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 <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) <civodul>that said, "guix system init" is super advanced usage <Guest42>so i reinstalled because i mistyped the command <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 <M6piz7wk[m]>Guest42: like 8 months ago and on the road to be again bcs hugging covid <M6piz7wk[m]>then just do more productive things :p or gamble on stocks <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 :) <florhizome[m]>I think I should screenshot this, make an nft out of it, and then sue you. <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 <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 <M6piz7wk[m]>how do i disable diffoscope showing me the time when the file was modified <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 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 <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 <rekado_>ekaitz: it’s some later version on core-updates-frozen <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 <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 <zimoun`>vivien, thanks. But here I miss why. Especially because “guix build foo” is broken for the very same reason. <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_>(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 :-)) <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. <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 <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 <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>wait, enlightenment is broken on master? how did I not notice? <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. <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 <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. <jpoiret>(massive rebuilds *and* general breakage) <zimoun`>civodul, ok. efraim: Do you plan to do it? <M6piz7wk[m]>Does GNU even have the infrastracture to run builds worth of 2M CPU cycles? <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 ? <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? <PurpleSym>sneek: later tell zimoun`: I’ll look into the failing python2-* packages. <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>for breakage, see upgrades of all gnome-related packages <jpoiret>or upgrades to the rust toolchain, Xorg, all that jazz <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? <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” <jpoiret>not upgrading gcc won't break already-working packages <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>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>fast given the date of the last commits on mach64). <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 :) <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>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>jpoiret: alright, lemme know if/when there's a patch i can apply <civodul>so, mid-sprint review: how are we doing, comrades? <civodul>well, it's first-quarter review then <apteryx>but we have two set of patches restoring GNOME IIUC :-) <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) <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 <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? <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 <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 <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 <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>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>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?) <apteryx>zimoun: did you take care of removing their dependents packages as well? <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 <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... <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? <rekado_>all the science stuff could be moved: scipy, seaborn, pybedtools, scikit-learn, statsmodels, etc <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 <civodul>pukkamustard: i've checked and i confirm; will push shortly! <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 <pukkamustard>great! That makes my random sampling of ocaml packages on core-updates-frozen build again! *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>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? <PurpleSym>roptat: Fixing is difficult to impossible. Some lack dependencies, some don’t support python2 any more. <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 <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>" <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 <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. <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>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, 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 (https://github.com/dbcli/pgcli). Unfortunately, one of its dependencies (python-pendulum), does not have a setup.py(!), so the build for pgcli fails with: "no setup.py 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 <fcw>vivien: I know. The build for pgcli fails because python-pendulum does not have a setup.py. <vivien>fcw, as far as I understand, setup.py is only provided in the source, it’s not installed. Is it? <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) <fcw>vivien: I declared python-pendulum in pgcli's propagated-inputs. When I try to build pgcli, it fails with "no setup.py 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 setup.py, 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? <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_>I looked at the definition of python-send2trash <rekado_>python2-send2trash does in fact add this phase <zimoun>roptat: are you planning to give a look ocaml-dose3? <roptat>zimoun, I think it was just fixed by ludo <fcw>vivien: Okay. Thanks for the advice. <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>at least some GTK applications (Gimp correctly uses the xorg server's DPI setting) <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>or perhaps s/windows/legacy systems/ <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 <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 setup.py file. <fcw>I have made some progress by adding a setup.py 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? <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. <awb99>how do I change gtk scaling settings? <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 <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. <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]>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 <vivien>Quick, while they’re away, let me say that XMPP is the best ! <apteryx>try again, it should be on berlin now <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 <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>vivien: do you get a substitute for webkitgtk now? <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? <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>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 <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) <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>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. <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/ <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) <rekado_>jpoiret: I’m trying to build it now. <rekado_>we still have a lot of packages that use PYTHONPATH instead of GUIX_PYTHONPATH <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 <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 <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. <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? <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) <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. <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 <rekado_>apteryx: I’m working on python stuff and bioinfo packages that still use PYTHONPATH. <rekado_>I’ll wait for ci.guix.gnu.org 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. <jpoiret>oh no, greetd is rust too, what a mistake <jpoiret>alright, gnome-shell manages to end up pulling fluidsynth through gtk -> gst-plugins-bad <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 <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) <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. <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 <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? <jpoiret>mhmmm, but don't you think the distinction package vs inferior-package will eventually always end up creating issues like this? <jpoiret>is there no way to make an inferior-package behave "just like a package"? <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>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 <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 <nckx>‘file-like’ is a bit broad here but that's better than the current opposite. <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 <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>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 >.< <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 { <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 *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 <nckx>Sounds very plausible TBH. <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 <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]>(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 <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]>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/local.mk (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 <roptat>yeah, but then I loose the author information <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 :) <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 <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 <roptat>M6piz7wk[m], yes, but we accept a pseudonym <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 <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? <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? <crazazy>i mean probably if you disable some settings for the package manager <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 <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 <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 <crazazy>but to conclude: I can't horribly break sandboxing rules in guix out of my own stubbornness right? <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 <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 <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_>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] 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 <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 <jpoiret>i'm in the middle of a bunch of module-imports atm, will have a reconfigured system soon! <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 <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 <jpoiret>also the little icon on the right of it is missing apparently <M6piz7wk[m]>roptat: yep the diffoscope looks very similar to mine <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>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 <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 <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>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 <rekado_>because rust doesn’t do dynamic linking anyway, so you don’t need to attempt to build the intermediates. <apteryx>you just throw all the sources in the pit, and ask rust to build them into some fat binary <apteryx>podiki[m]: it's used by elogind I think <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 <jpoiret>i cherry-picked only the last commit on wip-mutter, is that ok? <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! <podiki[m]>I'll also reboot eventually and see how that turns out :) <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 <apteryx>hmm, which version is gnome-shell at? <jpoiret>hmmmm, actually, we're not ready for Gnome 41 on cuf right? <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>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 <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? <vivien>lilyp, gnome-builder itself, and more specifically the rust-analyzer plugin <jpoiret>yes! mmarshall540 it should be pretty long and have --root in it <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/meson.build" <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>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? <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>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) <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>you could also run 'pstree -p' or similar to check what the process hierarchy looks like <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! <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>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 <ekaitz>I'll give this a spin this weekend and I'll keep you all informed :))) <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 <apteryx>oh, I was thinking about AppImage all the way <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 <ekaitz>apteryx: yeah, it's "simpler" from that perspective <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 <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>i checked the other day that diffoscope builds on core-updates-frozen, which pretty much builds half of guix <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>or you build a special profile with -p /tmp/your-new-profile -m your-manifest.scm <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>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? <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) <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>samplet: are you running Gnome with gdm? <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? <jpoiret>looks like it, thanks! (i thought it was just some configuration problems on my part) <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>(is it even possible to use our GNOME desktop service with Wayland so far?) <samplet>I thought I saw a patch or something about GDM and Wayland, but I haven’t investigated yet. <jpoiret>if you're using c-u-f, just add wayland? #t to your gdm-configuration-type <samplet>jpoiret: Ooh! Cool thanks! I will try it. <apteryx>oh, it seems to have worked! (sigaction SIGCHLD SIG_IGN) <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>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 <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? <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>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 :) <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 <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 <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) ***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>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. <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 <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/radeon_drv.so: undefined symbol: exaGetPixMapDriverPrivate" <jpoiret>didn't believ it was going to be that easy, although the problem is not yet resolved <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>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