<vagrantc>the top-level commit in it i'm working on checking if i can push it to core-updates-frozen, as all the other patches that were there are apparently present in core-updates-frozen as rebased patches
<vagrantc>sent a mail to the list about it, hopefully can follow-up with "i went ahead and pushed to core-updates-frozen, that's going to trigger ~10k rebuilds, wheee"
<nckx>If it existed you would have had to delete it first.
<nckx>So whilst, yes, the ‘focus’ was to bang c-u-f into releasable shape and that took a lot of work (probably more than expected, which it always has, so that was expected), the usual routine c-u bumps would just go to c-u. Less chance of introducing new bugs that way.
<vagrantc>and people don't consistently run "guix lint" ... that was my real lesson for the day ... everything from typos to broken packages deep on the dependency chain
<nckx>“The article on the dot discussed the development process where "It's always Summer in trunk". I don't know who coined that expression, but it's a nice one. I think it appeared in the KDE circle in a blog by Sebastian Kügler: he asked the question "What if we never froze trunk?"”
<nckx>I know it mainly by whay of Exherbo back in the day, IIRC.
<vagrantc>i get it, but it required some explaining :)
<vagrantc>the contrast between frozen and summer, basically...
<vagrantc>i might have nice rocks to hide under :)
<nckx>Yeah, it contrasts with our previous workflow, which was ‘sometimes c-u freezes, and everybody needs to be told this because it's very important, so we send (if that!) a mail to some ML, so a few people know this, so only a few keep pushing to c-u, which only creates a few head-aches; then after a while c-u unfreezes and we communicate that out-of-band in a very missable way, too, then repeat’. Doing it in-band in git just makes so much more sense.
<nckx>Which branch is frozen? Oh the one with frozen in the name. Is c-u frozen? No, it never is.
<vagrantc>what's unclear to me is what *can* go to frozen ... i think a "make dist" breaking change probably, so ... uh, i'll push soon :)
<nckx>vagrantc: They cannot go to frozen but someone forgot to tell the bug that. It happens. But it's the reason that ‘bump package x only because number go up’-style changes do *not* belong on c-u-f. Only bugfixes. These can introduce new bugs, as you found out, but hopefully fewer.
<steggy[m]>👋 I'm looking at fixing up the fish shell package, and I was curious what the protocol around using propagated-inputs is. I think it makes sense to add e.g. coreutils(for cat/ls/etc) and ncurses(for clear) to the inputs, especially as doing substitute*'s on the functions defined in fish can be hairy, but wanted to know if that would be generally acceptable or if I should put my regexp'ing hat on and get to work on that approach. Also open to
<steggy[m]>"both of those are wrong do this third thing"
<steggy[m]>To be clear, right now e.g. `clear` isn't packaged with fish, and so if you don't have ncurses installed as I didn't, you'll set a very sad message about not being able to find clear if you try to C-l. This is what I'm hoping to address by ^
<jackhill>dragestil: this probably isn't the right forum for this discussion (we should package all free software for guix!), but I am curious to learn more about how webkit gives google more leverage? My impresion is that they're being pulled along in a game of catch-up like everyone else.
*jackhill worries about how quickly bug/security fixes can be backported to qtwebengine (in addition to the other problems)
<jackhill>I will say that my impression to this point of webkit has been good: project with multiple stakeholders, comparatively easy to build compared to the other browsing engines, and appears to be easier to build novel browsers on top of compared to gecko/servo.
<kittyblam>the web and the corporations that break it fundamentally need to die, but thats better for another chat at another time lol
<jackhill>kittyblam: yeah, I'm with jgart in staring off into the void :)
<kittyblam>yeah lol, I have a lot to say but it would get heavily into copyright and politics xD in other news I need to work more on trying to package that one thing ... I know it should be obvious but still can't figure out whatever the guix version of the thing being done in nix was...
<jackhill>kittyblam: I've only looked at it for about 30s, but it seems like it has to do with passing the path to get it to build with a packaged version of a library rather than a bundled one. Probably something with setting configure/make flags and (assoc-ref inputs …) would be my guess
<jgart>Interesting.... I just tried to install a package to my profile from within a guix container and it blew away my default profile
<kittyblam>jgart: ah thats quite neat, I've never really touched mailling lists before I will have to figure that out lol, i might have to check that out as even once I am done with figuring out this (I believe last) piece of the puzzle of packaging yafaray I def have a few more projects (especially rendering engines) I am wanting to work on lol
<jgart>if you want, post some pastes here of yafaray package as you work on it and we can give tips on it
<jgart>like that you don't get stuck on it for too long if it happens
<kittyblam>ye thanks uwu, I made that mistake already and have just been off and on coming back to this, pretty excited that recently its almost working and it now seems very easy to understand apart from still being a bit lost on this - if the nix package is of any indication - last signifigant change that needs to be done to get it working I imagine
<rekado>apteryx: commit 781f475bbac4e73848f68cb9f420a7283ec17c16 is problematic for installing Gnome systems because different variants of at-spi2-atk end up in the same profile.
<vivien>(to be honest, vala-language-server is a recent addition, I don’t know if it worked before the -bc merge)
<lenny>jpoiret: cve description: "library/std/src/net/parser.rs in Rust before 1.53.0 does not properly consider extraneous zero characters at the beginning of an IP address string, which (in some situations) allows attackers to bypass access control that is based on IP addresses, because of unexpected octal interpretation."
<lenny>i think there were also some updates that make compilation faster (i don't know about compiling the compiler though)
<jpoiret>oh, alright! might be a candidate for grafting, but I am not knowledgeable on this front
<jpoiret>civodul: about what you told me yesterday, what exactly is blocking launching the installer image with `guix system vm`, apart from the fact that we need space at the end to use the store?
<jpoiret>the first part of the installer should work fine
<rekado>civodul: it happens when building a gnome system. The conflict is between the gnome package and network-manager-applet
<rekado>they propagate different variants of the same package.
<rekado>I think we can fix this by not propagating the -minimal variant and carrying it where it’s needed manually
<vivien>rekado, you indeed fixed the build, but in order to run, it requires libhandy 1 and a wrapped python path, which is mostly the goal of my patches (plus, as a suggestion from lilyp, get rid of libhandy-0 where I can, which is in seahorse)
<civodul>vivien: i'm testing these gnome-tweaks patches
<pkill9>does anyone use the signal messenger flatpak?
<civodul>vivien, rekado: what GLIBC_2_33 messages do you get?
<rekado>I rebooted already (because I had to have a working chromium for a meeting), but I can provide the exact message later.
<vivien>As for me: I don’t remember exactly, and replicating the issue requires me to reboot, which is inconvenient at that time.
<rekado>something like this: /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6: version `GLIBC_2.33' not found (required by /gnu/store/px2h9zci8dmwi55xqbd732mbm8wpiims-libproxy-0.4.17/lib/libproxy.so.1)
<rekado>I think one of the problems might be that gnome-shell still sets LD_LIBRARY_PATH
<rekado>we have a bug report about this, and I should have removed LD_LIBRARY_PATH (because I added it years ago), …
<rekado>this is what gnome-shell sets up globally: LD_LIBRARY_PATH=/gnu/store/vpwvgnjzpnan4nzbl75lvwbi13nlkydv-gdk-pixbuf+svg-2.42.4/lib:/gnu/store/ml5njpw1ggdk28ix4hginh3bs9rpacw3-gnome-bluetooth-3.34.5/lib:/gnu/store/p4ljkxzc88xz666d795g8acgr7ij3yrn-librsvg-2.50.7/lib:/gnu/store/6xabiy5r3a84gh7nz8mvwr811abwkwh2-libgweather-40.0/lib
<rekado>I think it was a very simple problem: gnome-shell just didn’t start at all.
<lenny>hi, i tried to update the package taskwarrior to the newest version. I used pre-inst-env from the git repo and modified the package definition. But if run task --version i still get 2.5.3. When building manually i don't get this. What could i have done wrong?
<rekado>it’s a cheap change; if it turns out to break things in unexpected ways I’d say we just address it then.
<rekado>bleh, I need a more recent matplotlib for a bioinfo package :-/
<rekado>I’ll go ahead and build a custom manifest for the user.
<lenny>I changed it to the output of guix download with the newest release tar
<lenny>Oh no! apparently i didn't. My editor must have overridden my clipboard when i removed the old hash. Still, i'm wondering why it didn't fail when the downloaded version did not match the hash. It simply installed the previous version
<vivien>lenny, yeah, if it sees a hash it already knows, guix won’t think twice about the version number
<abrenon>we're atually a very diverse community : )
<bost>abrenon: I guess you're a German right? Well a buddy of mine from London, once addressed a mixed crowd with "guys". Since that moment I feel safe using it, heh :)
<vivien>Are there people using the emacs vala-mode? If so, how did you patch it so that it compiles?
<vivien>I’m thinking about adding it to guix, but my solution is to kill the multi-line stuff altogether and maybe that’s not acceptable
<abrenon>bost: nearly ; ) yeah, I know it is actually pretty genderless for native speaker, I even have in mind several occurrences in TV shows for instance of a girl adressing her all-female group of friends "guys"
<singpolyma>In person I usually use "hello fellow humans" but people say it makes me sound like an alien invader
<abrenon>(bost: on top of that, it's a language habit that's been criticized by proeminent feminists in that it tends to erase feminity from public space and the asymetry is obvious when you think about calling "gals" an all-male group or even a group that you know includes men)
<rekado>singpolyma: I do the same, actually. It helps that I’m not actually from earth.
<darth-cheney>Hi all, I'm new to guix packaging. I'm trying to package a Guile module that I'm working on and I'm running into problems. I have one main dependency which is guile-json. When I try to install from the package file, I'm getting an error on the build side saying
<phodina[m]><notmaximed> "sneek: later tell phodina..." <- Thanks, the Gexpr builds. I have to adjust the path as it failed on compress documentation
<shtumf[m]>Hello, how to install Qt 6 opensource, I downloaded an installer ... but if I chmod +x installer.run , and then try to run it with ./installer.run it fails, how do you install Qt 6 is the question ?
<shtumf[m]>Should I do it in some sort of environment, what is the approach to such things
<notmaximed>sneek: later tell phodina: ‘Unfortunately it's part of the lambda phase ...’ --> then add 'outputs' to the argument list (add-after 'stuff 'more (lambda* (#:key outputs other-things ... #:allow-other-keys) do-stuff-with-outputs))
<notmaximed>sneek: later tell phodina[m]: ‘Unfortunately it's part of the lambda phase ...’ --> then add 'outputs' to the argument list (add-after 'stuff 'more (lambda* (#:key outputs other-things ... #:allow-other-keys) do-stuff-with-outputs))
<florhizome[m]>Personally so far I use it for those packages that need some outside library so I have them in one profile. vterm, notmuch and emacs guix f.e. Besides that I still have the same config as before with straight.el and it’s hard to imagine getting completely off of it since it’s very good at just installing things from github and even memorizes local patches.
<notmaximed>M6piz7wk[m]: If guix isn't used as package manager for emacs things, then you need to use something else, e.g. ELPA
<notmaximed>M6piz7wk[m]: so you would need to learn yet another package manager
<florhizome[m]>I‘m actually wondering how convertible configuration macros like use–package are to guix?
<florhizome[m]>since I am still using my straight.el setup I have configured use–package to always use straight, which makes it unusable for guix emacs packages...
<notmaximed>Looking at ‘M-x package-show-package-list’, it appears Emacs' built-in package manager is easy to use. Personally, I'd use guix though (so I have the option of checking the source code for malware before installing, or trusting guix reviewers to have done at least a cursory check)
<notmaximed>florizhome[m]: I dunno, I always use guix to install things (well, actually Debian at the moment) and don't have an emacs configuration
<awb99_>My guix xfce desktop becomes unresponsive from time to time. I hear the CPU fan spinning crazy. It sometimes is so bad that I have to cut the power supply because nothing works. It typically starts with a few apps becoming unresponsive. Normally closing windows works (with some delay). Sometimes I can run htop but there is no cpu load really. This happens only on guix. Any idea what this could be?
<notmaximed>florhizome[m]: I don't think _every_ reviewers checks updates _completely_
<notmaximed>but personnally, I do a cursory check of the diff if it isn't super long
<notmaximed>E.g., checking diffs of different linux versions isn't realistic
<vivien>He he gnuzilla has a script to turn firefox into icecat, and there’s a sed script to replace "opensource" with "Free Software"
<notmaximed>but for small projects (which have a higher chance of having malware introduced without anyone noticing, so checking is more important there!), it's definitively feasible
<mitchell>Hello Guix! Can someone help me with how I would add new modify-phases to a package with inherits from a package with modified phases. Do I need to copy the modified phases from the parent package by hand and add my additional phases or is there a more elegant way to append new phases.
<florhizome[m]>for inputs you can do sth like (inputs (append (package–inputs emacs)) ....) though, so maybe doing something similar for arguments should be be possible. for committing upstream, probably not though :)
<florhizome[m]><notmaximed> "I suggest searching for substitu..." <- Is there something that lets me target specific package inputs?
<avp>Hello Guixers. I want to replace guile-ssh that is used by Guix with my version on a local machine. What is the proper way to accomplish that?
<yewscion>Hello All, I'm trying to package a piece of software that doesn't use autotools to configure, and has hardcoded directories in the install step of its Makefile. Is there a canonical way to fix something like this, or could someone point me towards an example of a package that does?
<yewscion>avp: You can write up a package definition and host it on Your own channel, which You can then use to install it. It's a long setup process, but it makes packaging other things very straightforward once it is complete.
<jgart>yewscion, I think you might have to modify gnu-build-system with custom phases and possibly substitute*'s to patch things
<jgart>Try just setting PREFIX= and CC= with #:configure-flags option that is a feature of the arguments field (package is a scheme record).
<avp>yewscion: Basically I need a test environment where only guile-ssh is replaced with my version, that should be enough for me. Should it be so complicated?
<nckx>yewscion: FOO = bar in a Makefile isn't (bad) ‘hard-coding’, it's fine: users can still modify those values on the make command line.
<yewscion>avp: I don't know if there is another way; It seems like this would be a use-case for `guix shell`, but I haven't learned how that really works yet. Sorry!
<jgart>yewscion, If you have owl packaged then you can use it with guix shell
<yewscion>nckx: I think my confusion mostly stems from not knowing how guix handles things such as env vars. I've been trying to avoid things like DESTDIR in my package definitions because of my lack of knowledge.
<nckx>yewscion: Not that #:make-flags are not environment variables! They are passed on the make command line and set variables inside the Makefile, nowhere else.
<nckx>DESTDIR is a ‘bad’ example because using it in Guix packages *is* usually a bad example, because it's meant for packaging workflows that are different from how Guix does things.
<yewscion>Ah, I see. That makes more sense. Thanks!
<nckx>Guix installs software directly to its final destination (often using something like PREFIX) whilst DESTDIR is meant to set a temporary staging area. These are just conventional names; technically they are exactly the same kind of variable. Some packages even get it wrong and that's why you'll see some DESTDIRs in Guix packages: the upstream author confused it with PREFIX ☺
<nckx>Or perhaps PREFIX is somehow buggy and DESTDIR happened to work.
<florhizome[m]>So my build (gala, with meson) doesn’t find libmutter, although a suiting Mutter package is included ( actually just built for that! ;(). libmutter binarys are basically output under ./lib and they are really right there ....
<nckx>They are syslog logs, awb99, and the kernel ‘dmesg’ is one of the things that it logs.
<podiki[m]>anyone familiar with libsoup and our libsoup-minimal?
<jpoiret>avp: what is your exact use case? have a different guile-ssh in your environment when developing guix?
<nckx>awb99: This cpuidle_enter_state shows up in wildly different random bug reports over the decade (ZFS, …) where it's obviously not the culprit, but yours is interesting in that the call trace is rather short, and the idle subsystem may actually be to blame for once. This is still just a guess though. I'm not very familiar with that part of the kernel. This is not related to Guix, so be sure to ask other channels (maybe #linux, if that's any good) if disablin
<sneek>phodina[m], notmaximed says: ‘Unfortunately it's part of the lambda phase ...’ --> then add 'outputs' to the argument list (add-after 'stuff 'more (lambda* (#:key outputs other-things ... #:allow-other-keys) do-stuff-with-outputs))
<sneek>phodina[m], notmaximed says: not 100% sure if that exists
<florhizome[m]><florhizome[m]> "So my build (gala, with meson..." <- What could be the reason here?
<nckx>awb99: Are you running the latest Linux kernel? If not, try a newer one, if yes, try an older one (5.10 or even 5.4 or evener 4.x if you're really desperate to try random things to gather more data).
<nckx>awb99: It's also possible there are more specific error messages in the kernel log before that point. The kernel logs ‘Linux version …’ every time it boots, everything between that & the stack trace you posted is from the same boot.
<awb99>I copied the first few lines after ddays of --MARK--
<awb99>matched exactly the time when the system went unresponsive.
<awb99>uname -srm gives me: Linux 5.14.9-gnu x86_64
<awb99>so the kernel version is determined by guix ?
<awb99>depending on the snapshot where I am in, right?
<awb99>when I run guix upgrade, my system also becomes very unresponsive for a while.
<awb99>but with the guix upgrades, at least after they are finished, it works again.
<pkal>Can someone give me a hint how to download a patch together with a package source?
<phodina[m]><sneek> "phodina, notmaximed says: ‘..." <- Unfortunately the outputs are already part of the lambdas for install. I added them to patch-python-references after unpack, but there of course it has no effect
<civodul>if anyone's willing to test, they'll have all my recognition :-)
<phodina[m]><notmaximed> "sneek: later tell phodina: I..." <- Unfortunately not in this case. There are other packages, where I made the changes to cross-compile them. But glib with the bin output is though one as I'm not that skilled in Guile.
<sneek>Welcome back phodina[m], you have 6 messages!
<sneek>phodina[m], notmaximed says: (string-append #$output "-bin") isn't the "bin" output. For the bin output, try #$output:bin