IRC channel logs


back to list of logs

<terpri_>raghavgururajan, context for others? if it's public / not too complicated? e.g. is this a failing package definition that could be pastebinned?
<terpri_>does anyone happen to know if there are major upgrades imminent for icecat? i'd like to dig into the distorted-audio issues, now that i have some idea of where it's going awry
<nckx>raghavgururajan: Are you sure dbus is generating those warnings? I'm no desktop expert but I've only ever seen it complain about /etc/machine-id; /var/lib is unusual.
<nckx>I'd rule out an overly pedantic build system (by grepping the sources for that file name) first.
<terpri_>i'm guessing at least a few months til the next firefox ESR release, based on
<raghavgururajan>terpri_, ^
<terpri_>thanks raghavgururajan
<nckx>raghavgururajan: Your comment says /etc, or is that just copypasta.
<raghavgururajan>Error message:
<raghavgururajan>nckx: I see both /var and /etc in error message.
<raghavgururajan>Yes, it was a copypaste
<raghavgururajan>> terpri_‎: does anyone happen to know if there are major upgrades imminent for icecat? i'd like to dig into the distorted-audio issues, now that i have some idea of where it's going awry
<raghavgururajan>I have the same symptom.
<raghavgururajan>nckx: No source files contains "machine-id".
*raghavgururajan tries
<raghavgururajan>Wow! it worked.
<raghavgururajan>nckx: How?
<nckx>Don't ask; I still think Meson is an expensive trendy mistake that we'll all pay for some day.
<nckx>raghavgururajan: It also works when you replace "meson" with "ninja", I have no idea which is correct. Both work. Meson prints a warning, but maybe that's good because it's doing more? Dunno!
<raghavgururajan>I see.
<raghavgururajan>Yeah, I noticed the warning.
<nckx>Stick with "meson" for now.
<raghavgururajan>Thanks for the snippet.
<nckx>Happy to help.
*raghavgururajan is in "If it works, don't touch" mode.
<lfam>Build systems
<lfam>Also tagged "code of conduct"
<nckx>raghavgururajan: In return, let me ask (again): please, stop replacing with" name "/" name, it really adds nothing.
<nckx>" version " makes sense, " name " does not. It's(eems) inconsistent. It's unfair. It's cruel. I know.
<NieDzejkob>if you change the package version, the URL will probably stay correct. if you change the package name, the URL will probably break
<gnutec>Tips: guix package -i sky
<raghavgururajan>nckx: Ah, about that. I prefer to do "name" with gnome packages. The projects has a reputation of changing its software names.
<walter[m]1>hey lfam, I fixed my locale problem!
<lfam>Great! What was wrong?
*nckx runs the stranger's command on their machine because what else is the Internet for.
<walter[m]1>it turns out disabling auto-login on the sddm-service fixed it
<raghavgururajan>gtk+ has now been renamed to gtk, as of v4.
<walter[m]1>I'm thinking things were run out of order or some step was being skipped
<civodul>raghavgururajan: woow, that sounds like a revolution after all these years!
<terpri_>raghavgururajan, i have some decent hypotheses about the bug thanks to the suggestion to disable Media Source Extensions. will be tinkering with icecat today if bureaucratic errands don't distract me
*civodul -> zZz
<terpri_>btw, an aside on gtk versions: it's a bit of a pain that e.g. gtk2 and gtk3 aren't separate packages, because some programs actually require both versions to build!
<terpri_>including stock firefox / probably icecat
<nckx>raghavgururajan: I still think it's wrong and costs more person-hours in the long run than it saves but I can only ask so many times.
<nckx>terpri_: What do you mean not separate packages?
<terpri_>(why ff would want both versions i don't know)
<terpri_>nckx, that the gtk+ package has both 3.x and 2.x versions available, rather than having say gtk+3 and gtk+2 packages
<terpri_>guix search '^gtk\+' shows what i mean
<lfam>We have gtk+-2 and gtk+ packages
<nckx>terpri_: That's what I did, hence my question.
<nckx>That returns 2 packages.
<nckx>3.24.20 and 2.24.32.
<nckx>How are they not separate (enough)?
<nckx>Do they conflict?
<nckx>I've never tried to build FF, forgive me if that's a silly question.
<terpri_>nckx, oh, so they are separate packages, thanks for the tip. i think it may have changed since i was actively hacking on ff, and having trouble getting gtk2 and 3 installed in the same profile
<terpri_>(or i was just confused about it at the time :))
<nckx>Maybe you were still stuck in an old-school-distro mindset where 2 versions of the same package really are special incompatible things.
<nckx>guix environment --pure --ad-hoc gtk+@{2,3} didn't give me any warnings, at least.
<lfam>I mean, it's good that it works but it's messed up that icecat needs both versions of GTK
<nckx>Oh no question.
<terpri_>yep, that works perfectly now. i definitely remember *some* conflict that led me to define (package (inherit gtk+-2) (name "gtk+-2")) as a personal package
<terpri_>but that was a long time ago, and could have easily been a misunderstanding on my part. in any case, no problems now, hopefully :)
<nckx>terpri_: That was definitely a bug. Don't hesitate to report such weirdness. I hope it didn't prevent you from doing cool things.
<terpri_>basic idea is to check if our bundling, or some missed unbundling, mucked things up. the ff monorepo contains bits from ffmpeg, libav, all sorts of things
<nckx>(Or indeed misunderstanding, but report those too, because it's important to know and document common misunderstandings too.)
<terpri_>nckx, it was easier to type three lines than file a bug report ;)
<nckx>I know. It usually is. Plus, dealing with humans, yech.
<lfam>Guix makes it too easy to work around bugs /s
<nckx>Wait the /s stands for serious right.
<nckx>Like ha-ha-but-seriously.
<raghavgururajan>> civodul‎: raghavgururajan: woow, that sounds like a revolution after all these years!
<raghavgururajan>> terpri_‎: raghavgururajan, i have some decent hypotheses about the bug thanks to the suggestion to disable Media Source Extensions. will be tinkering with icecat today if bureaucratic errands don't distract me
<raghavgururajan>> nckx‎: raghavgururajan: I still think it's wrong and costs more person-hours in the long run than it saves but I can only ask so many times.
<raghavgururajan>Okay. (y)
<jonsger>CI seems down
<nckx>jonsger: ‘Fixed’.
*nckx resets the ‘hours since cuirass-web had to be restarted’ counter.
<nckx>It was only on 3 anyway :-/
***terpri_ is now known as terpri
*jonsger doesn't understand why cuirass breaks so often. whats wrong with it?
<terpri>a breaking cuirass...i'd suggest finding a good metalworker ;)
*raghavgururajan is having soup. To be exact, libsoup.
<NieDzejkob>nckx: could you restart the build for 'docker' on CI?
<terpri>what's the incantation to get guile to stop putting so many ellipses in backtraces? i.e. to widen the column width of debug output
<nckx>terpri: COLUMNS=9999, the gotcha is it needs to be set in the daemon's environment.
<terpri>so setenv in the package def, or do i need to customize the daemon service?
<nckx>NieDzejkob: Partially. I'm familiar only with the guix(-publish) part, not the Cuirass part. I'll restart and substitutes will be available if it succeeds, but the Web UI won't know.
<terpri>there's also debug-options from (info "(guile) Debug Options"), can't remember if that helps or not
<terpri>nope, not debug-options
<nckx>terpri: No, the latter (edit the service). Ironically easier (if more ‘stateful’) to do on systemd than Guix System AFAIK.
*nckx → 😴
<nckx>Oh: If anyone does know how to clear failed builds on Cuirass I'm dying to know. I assume it involves manual SQLite querios.
<nckx>Querios, the disgusting snack.
*nckx → 😴 now promise.
<lfam>Yeah, I guess /s was the wrong thing to use. It was haha but serious
<lfam>It's really easy in Guix
<apteryx>nckx: we can do as civodul said fetch the cpe database and do our own checks that our implicitly derived CPE names match something, and only fill the json with those that had match.
<pkill9>is it possible with cgit to add tabs linking to arbitrary URLs?
<pkill9>in a repository
<nckx>apteryx: Really just the other side of the lint warning/suggestion coin, I think. I hadn't seen the mail you were probably referring to when I answered earlier.
<jackhill>Was there ever any historical connection/idea sharing between Gobo Linux and Guix and Nix?
<bavier1>could maybe check eelco's disertation for references
<jackhill>bavier1: good idea
*** sets mode: +o nckx[m]
*** sets mode: +o ChanServ
***kmicu_ is now known as kmicu
<civodul>Hello Guix!
<janneke>hello civodul!
<jonsger>something wrent wrong with commit d283bb960f927dd5f7bb8b96bc697221e4e8ad39 civodul
<jonsger>I assume
<jonsger>I guess we need to update the guix package itself
<bdju> I threw this on the wishlist earlier. maybe someone who has experience packaging rust stuff could take a look
<mroh>jonsger, civodul: yes, I have the same problem after system reconfigure.
<peanutbutterandc>Hey guix
<peanutbutterandc>I am getting /var/guix/daemon-socket/socket connection refused error on Xubuntu 19.04 (installation via Any ideas please?
<peanutbutterandc>shoot. it seems that guix-daemon isn't running.... I thought the shell installer handled this... strange
<civodul>jonsger: oops, that's me!
<peanutbutterandc>Okay.... what is this gnu-store.mount thing that is referenced in shell script? Because I don't have it on my (foreign) system
<nckx>peanutbutterandc: Installed by said shell script, just like guix-daemon.service.
<peanutbutterandc>nckx, Hey there! Long time no see! I think I've found a bug in the function... I'm looking into it... just a little while please
<nckx>Great! (…that you're investigating)
<nckx>Strange, (X)ubuntu isn't obscure. Thanks for looking into it. And hi!
<peanutbutterandc>nckx, Ah! Gotcha!
<peanutbutterandc>nckx, There was a change 2 months ago...
<peanutbutterandc>nckx, Here. gnu-store.mount is in an if block in this shell function. But this line assumes that gnu-store.mount is always there (it isn't in both my foreign systems). And that causes this line to fail, which prevents the next line from executing
<peanutbutterandc>nckx, That is the reason why guix-daemon.service wasn't working on my new xubuntu 19.04 installation -> it was never enabled!
<nckx>peanutbutterandc: That change added the gnu-store.mount unit, it didn't exist before.
<nckx>If your systems are older than that, they won't have gnu-store.mount, but why are you running the installer on them today? If you install Guix using that script today, it *will* install gnu-store.mount, unless there's a bug.
<nckx>By systems I mean the Guix installations on them.
<nckx>peanutbutterandc: Do you think this line is buggy?
<nckx>The bugginess might be deliberate ( but should not be fatal.
<peanutbutterandc>nckx, I installed guix on this system 2 days ago and it has not installed gnu-store.mount. ~root/.config/guix/current/lib does not even have a 'systemd' directory for me. Only a 'guile' and 'guix' dir exist....
<nckx>Hmkay, I see what you mean.
<joesmack>hi, i've installed guix using the graphical install, created 1 user. now the manual tells me to do 'guix pull', but no channel definitions is returned (from /home/user/.config/guix/channels.scm) should there be? or do i need to add myself? manual seems to assume it is already there?
<nckx>peanutbutterandc: So systemctl start guix-daemon works fine, right? I should just replace the second && here <> with something else?
<nckx>joesmack: If that file doesn't exist, Guix uses the default upstream ‘guix’ channel.
<mroh>civodul: ty for the fix! reconfigure works now
<joesmack>no it just stops
<nckx>joesmack: Could you paste the full error to
<nckx>joesmack: So /home/user/.config/guix/channels.scm doesn't exist at all?
<joesmack>@nckx just says: error: >>/home/user/.config/guix/channels.scm<< didn't return a channellist
<joesmack>@nckx no doesnt exist
<mfg>Hi guix, i'm trying to set up an environment with some c++ libraries, but i can't find how i get guix to export the resulting include and library paths for it. How does that work?
<lle-bout>GNU Guix called a gcc "powerpc64le-guix-linux-gnu-gcc" during bootstrap, fun! aha
<nckx>joesmack: I can't reproduce that and Guix doesn't contain the words "channel list" (or "channellist") anywhere I can see.
<peanutbutterandc>nckx, umm.... it seems that systemctl fails if any of the given services don't really exist. I was wondering if we should add a variable in the if-block that checks for the .mount thingy. If that block is exported, set a variable .mount-set=true, then, we could probably change the at 370 to be something like `systemctl enable $(.mount-exists:+gnu-store.mount} guix-daemon && ...`
<joesmack>i can do sudo -i guix pull, but then manual tells me i have to do 'guix pull' separately.. but not sure what that means..separate from what?
<joesmack>@nckx ye, i translated from danish :s
<joesmack>i was just wondering if it should be there, cause then i just try install again
<nckx>peanutbutterandc: Honestly I'd rather just move the systemctl enable .mount into the if-block that installs it. Not looking at the code right now though.
<nckx>joesmack: Aha :-) No, what should happen is that Guix happily pulls the default channel. channels.scm is entirely optional.
<nckx>What you describe could happen if it exists but is *empty* (or malformed) but I don't understand otherwise.
<peanutbutterandc>nckx, Yes sir. That sounds just as well... but it's `systemctl start .mount` and `systemctl enable .mount`. So I thought that this idea would save us 2 duplicate lines....
<joesmack>ok, before i do anything i just try install again i think.. must have messed it up :D thanks
<nckx>joesmack: Out of curiosity, could you create a /home/user/.config/guix/channels.scm containing only the line %default-channels?
<nckx>And pull.
<peanutbutterandc>nckx, That is just a fancy parameter expansion thingy. If `${foo:+bar}` foo is set to anything, 'bar' is returned, but if foo is empty, it expands to empty string.
<nckx>peanutbutterandc: Lines are cheap, but yeah, I'll have to look at the code to see if it makes sense.
<peanutbutterandc>nckx, Haha. Most certainly. :)
<nckx>peanutbutterandc: I know my bash 😉 I think it makes sense to write guix-install in a more ‘straightforward’ style than that, is all. It's quite arcane to many users, and we need their bug reports too.
<nckx>The ${…:+…} stuff I mean.
<joesmack>@nckx yes, that makes it update channel >>guix<<
<Kimapr[m]>After a quick test, guix gc deletes VMs made with `guix system vm`. Is it how it is supposed to work? If so, is there a way to preserve the VM?
<peanutbutterandc>nckx, Oh... I see. That is entirely understandable. That shell installer script is a work of art. So very clean and elegant. BTW, I just realized that I was `git blame`-ing you this whole time. lol sorry :D
<civodul>lle-bout: hey, great that you've reached that stage!
<civodul>it's a good sign :-)
<peanutbutterandc>nckx, I mean I love the script and how clean it is. And I admire your decision to keep it understandable... without the arcane expansion stuffs. :)
<peanutbutterandc>"Readability > Lines of code"
<jonsger>civodul: thx for the fix
<mroh>Kimapr[m]: you can link the image to /var/guix/gcroots (or just copy it out of the store).
<lle-bout>civodul, heh yes! well it's been a while it has been reached, I'm trying yet again! Things went good on big endian; but little endian was left aside, fixing it now!
<Kimapr[m]>mroh: is it possible to do that without superuser privileges?
<lle-bout>I realize it's been a year this port is ongoing more or less
<lle-bout>way too long! Couldnt dedicate much time to it over the year but still!
<Kimapr[m]>(i do have them but would be cool if it is possible without them)
<mroh>Kimapr[m]: copy yes, link no
<lle-bout>civodul, "output (`/gnu/store/nbc354wi67wh33rcql10l6y8lhwxqm3q-binutils-2.34') is not allowed to refer to path `/gnu/store/vnshq5g4ghhbr6c3s69q9p8fp6hr0gpx-bootstrap-binaries-0'" - why is that so exactly?
<Kimapr[m]>i meant linking the image to /var/guix/gcroots
<Kimapr[m]>i know it is possible to copy it out of the store
<civodul>lle-bout: there's a #:disallowed-references argument in that package
<Kimapr[m]>because everyone has read access to it
<civodul>lle-bout: the goal is to ensure we don't keep a reference to the bootstrap binaries
<lle-bout>civodul, what is the goal of that?
<lle-bout>also how would I solve it? Recompile whatever bootstrap binary is being used?
<lle-bout>I had the problem before, I remember, I solved it using this patch:
<lle-bout>on gnu/packages/commencement.scm
<lle-bout>is it acceptable?
<lle-bout>re-using static-bash-for-glibc
<lle-bout>It's because, on PowerPC, there's a bash script in installed artifacts, it's inside binutils
<civodul>lle-bout: i'd need to load that in cache ;-), but the idea is that the first binutils is cross-compiled precisely so it's independent of the bootstrap binaries
<civodul>the bootstrap binaries are "one-shot" so to speak
<civodul>and from then on, we only ever use software built from source
<lle-bout>I see, but ultimately with GNU Mes, that would not be true anymore, since everything would be either documented binaries or source code
<lle-bout>What do you mean load in cache?
<civodul>i just meant that i'd need to wrap my head around it
<civodul>with Mes, we still have that kind of issue (for now), but the binary seeds are of course much smaller
<lle-bout>civodul, ohhh OK! yes it's complicated and GNU Guix is so huge by now aha
<civodul>heh :-)
<lle-bout>I think it has maintained over time quite good quality for a language that lacks a static type system
<civodul>"quite" ;-)
*civodul goes for lunch
<lle-bout>bon appetit!
<Formbi>I'm trying to update Node
<Formbi>and I have #:use-module (gnu packages node) in the file
<Formbi>but Guix says «(value "Unbound variable: ~S") (value (node))»
<Formbi>what's going on?
<mfg>Hm i really can't find documentation on how guix exports library and include paths in `guix evironment', because g++ seems to be unable to find them
<lle-bout>mfg, env?
<lle-bout>I think everything is done with standard environment variables
<lle-bout>LD_LIBRARY_PATH to a profile folder
<mfg>hm okay, then guix doesn't do anything because nothing changes there
<lle-bout>things like this
<mfg>LD_LIBRARY_PATH doesn't get set
<lle-bout>I may be wrong about LD_LIBRARY_PATH specially
<lle-bout>PATH then?
<mfg>i mean those variables don't seem to get set even for profiles, because the etc/profile of it doesn't contain those vars
<mfg>i really don't understand how this works :D
<lle-bout>I don't know precisely how it works either, so if it's not documented, best bet, read the code
<mfg>you are right i guess :(
<lle-bout>mfg, or wait for someone else that knows more about GNU Guix than me :p
<Kimapr[m]>oh wait i actually have write access to /var/guix/profiles/per-user/kimapr
<Kimapr[m]>does that mean i can link the and vm image to that dir and gc wont delete my vm?
<alextee[m]>do we have a build of gtk with debug symbols?
<mfg>lle-bout: ahh, so i noticed that i wasn't using g++ bt clang++ and g++ does find the headers, there i only need to add the correct library path
<lle-bout>mfg, good news!
<lle-bout>alextee[m], speaking of which, I don't know how debug symbols are managed in GNU Guix!
<lle-bout>is it package:debug? does it exist everywhere?
<lle-bout>on Fedora, there's this nice thing where gdb directly tells you what package to install to get missing debug symbols..
<nckx>lle-bout: ‘not’.
<lle-bout>nckx, what do you mean?!
<nckx>Guix doesn't manage them.
<lle-bout>ohh okay; area for improvement then! I am guessing it could be trivial to modify CFLAGS with -g for many packages on the command line..?
<mfg>lle-bout: irony is based on clang so emacs gives a lot of false errors :D
<nckx>There are some packages that manually create a :debug output but they are relatively few (really: < 1%).
<lle-bout>nckx, yep.. that was my impression!
<lle-bout>It's possible to automate code transformations across many packages with GNU Guix then commit those, correct?
<nckx>lle-bout: My guess is the same, some build system magic would take care of most packages.
<nckx>lle-bout: Hm. Yes. In theory 😛
<nckx>But if you're doing that, it's probably a sign it should just be magicked away into the build systems anyway.
<lle-bout>nckx, for another topic, if many packages have bad practices in them, to automatically fix it
<janneke>civodul: can you give a comment if necessary on, this fixes our childhurd offloads: "works for me"; so i'm a bit tempted to "just push" ;)
<nckx>lle-bout: That's doable (depends on the problem & the fix). I hope bad practices aren't so rampant that such an approach is needed?
<lle-bout>janneke, he's not logged in AFAICT!
<lle-bout>nckx, well I think it is inevitable a pattern becomes judged harmful after the fact!
<nckx>lle-bout: Do you have anything in mind?
<janneke>lle-bout: thanks, i missed that! will pester them later ;-)
<lle-bout>e.g. many packages trying to cope with a deficiency of GNU Guix and then later GNU Guix fixing it and providing a nicer way to do things. Example: this multi-origin thing and native-inputs?
<alextee[m]>nckx: lle-bout i'd love to have built-in ways to get debug packages (-g)
<alextee[m]>helps a lot when you're developing apps using guix
<lle-bout>Another thing, I've had weird lag on sheperd at boot time since I ever installed this machine, basically it times out on some service and NTP log lines appear very slowly
<lle-bout>alextee[m], definitely!
<alextee[m]>i need to look into gtk's backtrace now but i can't because i have no symbols
<alextee[m]>in meson build system you'd just add '--debug' to the params i think
<lle-bout>alextee[m], I think you can craft a recipe of gtk with debug symbols by substituing CFLAGS on the fly through GNU Guix command line
<lle-bout>It needs some Guile-fu
<lle-bout>Or Scheme-fu, if I may
<alextee[m]>i think just adding '--debug' to meson args should do it, let me try
<nckx>alextee[m]: Does that allow you to split the debug output into a separate output? That would be wonderful to have by default.
<nckx>So you're still debugging what everyone else is using.
<alextee[m]>nckx: no im not sure how to do that/how that works
<alextee[m]>--debug simply adds -g afaik
<nckx>Debugging a different package built with (slightly) different options is yeh.
<alextee[m]>that would be best though, fedora does that for many packages
<alextee[m]>they have separate packages for debug symbols
<lle-bout>Fedora debug symbols support integrated with gdb is just perfect.
<alextee[m]>you can do that with basic GNU tools i think, can be a post-install thing
<alextee[m]><alextee[m] "i think just adding '--debug' to"> actually nvm it's messy to try, i'd have to uninstall gtk and then install my custom version
<alextee[m]>i guess that would need a lot of rebuilds
<nckx>I know it can be done with autotools & is supported by GNU, I'm just… well, I'm ready to be disappointed by Meson at every turn. If it does support that, even better.
<lle-bout>Is Meson disappointing? I was under the impression that it was a nice and easy to use tool!
<nckx>If Fedora → Red Hat → Gnome supports it that's a good sign.
<alextee[m]>i asked in #meson
<lle-bout>janneke, the wizard is back!
<alextee[m]>nckx: the answer is "no it doesn't do it"
<janneke>lle-bout: let's stalk them!
<alextee[m]>apparently RPM does that
<alextee[m]>and archlinux's makepkg
<alextee[m]>BUT NOT GUIX :o
<lle-bout>ehmm stalk why stalk :-|
<janneke>dear wizard: can you give a comment if necessary on, this fixes our childhurd offloads: "works for me"; so i'm a bit tempted to "just push" ;)
<nckx>Hmkay, but it can be done. That's OK. Even if it's tedious we can abstract it away in the meson-build-system or a common phase.
<alextee[m]>nckx: there's an issue for it
*civodul looks around in search of a wizard
<lle-bout>civodul, :D
<civodul>janneke: lemme take a look!
<nckx>civodul is never late, he arrives precisely when he means to.
<janneke>ty, i'm especially hesitant about the "sqlite-for-hurd" package name
<lle-bout>the for-hurd packages are adding up aha
<lle-bout>childhurd is an offload server that runs GNU Guix on GNU Hurd? :O
<janneke>lle-bout: yeah, i'm hoping we'll get some real hurd-debugging in, but that's easier when we have substitutes available i think
<lle-bout>janneke, you're going to boost GNU Hurd developers productivity by a million!
<nckx>alextee[m]: Having it built into Meson would have the fantastic advantage that upstreams using Meson are more likely to fix their package to support it, vs. it being a weird Guix thing that we need to fix for each misbehaving package.
<lle-bout>OTOH I hope to do the same with PowerPC soon enough (!)
<janneke>lle-bout: childhurd is a "lesser" hurd; i.e. running in a VM
<janneke>lle-bout: and our childhurds run guix, of course :-)
<lle-bout>nckx, when little endian PowerPC is in better shape, you'll be able to add the OSUOSL machine as an offload to GNU Guix, would you?
<janneke>offloading to a childhurd is optional, just as offloading to any guix system is optional ;-)
<nckx>Of course.
<nckx>lle-bout: ☝
<nckx>That's what it's for!
<lle-bout>Super! Well I still wasnt able to run my own unofficial Cuirass and Substitute server!
<lle-bout>I doubt nested virtualization is enabled on the OSUOSL machine
<alextee[m]>nckx: i'll quote you in that issue
<elibrokeit>nckx[m]: I think you drastically misunderstand how debug symbols work?
<lle-bout>But you could ask for it, or another big endian VM, I think making little endian better tier than big endian is a good idea but having big endian somewhere is still quite useful. Some people in the community make it their mission to improve code quality everywhere and eradicate high level code with endian assumptions built in
<nckx>elibrokeit: Just nckx. And easy there. Why do you think that?
<elibrokeit>most build systems just... accept CFLAGS for debug. Boom. Debug symbols in the binary. That's literally all you need.
<elibrokeit>you don't need a build system option, and meson already supports the CFLAGS you need
<lle-bout>elibrokeit, there's also separate debug symbols I think; not sure how those are generated
<elibrokeit>they're generated by building binaries with integrated debug symbols
<lle-bout>elibrokeit, alextee[m] was mentionning a possible "--debug" switch
<elibrokeit>gcc only generates binaries with debug symbols
<alextee[m]>lle-bout: --debug is a different thing and is already there, it just adds '-g' to the cflags
<elibrokeit>separating them into separate files is a post-processing step
<elibrokeit>this post-processing is done usually by distribution methodologies like rpm
<elibrokeit>or makepkg
<elibrokeit>or, perhaps, guix
<elibrokeit>it amounts to running objcopy and strip on the binary
<civodul>janneke: replied! :-)
<janneke>civodul: thanks!!
<elibrokeit>I guess in theory meson could support doing it for you, but it's not clear it is meson's job to do so and you'd still need the code in guix to handle it for autotools, cmake, or plain Makefile builds
<elibrokeit>and makepkg, at least, supports user configurable settings here. You can opt into or out of generating these, it's a toggle in the packaging system, not in the upstream build configuration tool
<elibrokeit>you don't want to add code to every recipe to do this... you want to abstract it into the core of the packaging system
<nckx>elibrokeit: But what's your point?
<elibrokeit><nckx> alextee[m]: Having it built into Meson would have the fantastic advantage that upstreams using Meson are more likely to fix their package to support it, vs. it being a weird Guix thing that we need to fix for each misbehaving package.
<elibrokeit>it is not a weird guix thing :)
<alextee[m]>nckx: he's from #mesonbuild . I just mentioned that my question was about guix and quoted you o.o so he chimed in
<alextee[m]>he's a makepkg developer btw (archlinux)
<nckx>I gathered as much.
<nckx>Always fun to hear you don't understand something, then hear your own opinions verbosely parroted back at you :-/ Anyway, yes, this should be done in the build system, not ad-hoc in packages. We agree.
<elibrokeit>excuse me
<nckx>Currently it is done ad-hoc in packages, and that's not good.
<alextee[m]>nckx: heh, guix is much friendlier/welcoming than other communities
<elibrokeit>I very specifically replied to this by saying it should NOT be done in the build system (meson) but the packaging system (rpm, dpkg-buildpackage, makepkg, guix)
<alextee[m]>not saying that elibrokeit isn't friendly
<alextee[m]>he's helped me a lot with problems i had
<civodul>it's great to hear from build system people
<civodul>thanks for chiming in, elibrokeit
<elibrokeit>specifically, I don't understand how meson adding an objcopy feature causes any upstream to "fix" their software to support it :)
<nckx>elibrokeit: No, *our* build-systems 🙂 What you call a packaging system.
<civodul>i guess terminologies collide :-)
<alextee[m]>nckx: guix has a "meson-build-system", i think nckx meant that we could add this option to the meson-build-system if meson supported such an option
<nckx>I understand how that might have been confusing (my bad, maybe, but I'd use a more explicit term in #meson and this is #guix).
<nckx>elibrokeit: ☝
<nckx>Yes, what alextee[m] said.
<elibrokeit>hmm, then you'd still need to add a post processing step to e.g. "gnu-build-system" that does it on the guix level by looping through build artifacts and running objcopy/strip at the end.
<nckx>I stand by my ‘If Meson had a big ‘make the debug plz’ button upstreams would more readily support’, I'm not saying it's for technical reasons.
<nckx>Quite the opposite.
<nckx>elibrokeit: That's vaguely what I had in mind, ideally this (what we call) ‘phase’ could be shared between Meson/autotools/… anyway, right?
<elibrokeit>well, if the meson "make the debug plz" only works on software which builds using build.meson then I don't see how
<elibrokeit>you cannot tell meson to "make the debug plz" by giving it a CMakeLists.txt or ./configure and ./
<elibrokeit>I guess you could have a meson specific "phase" to generate splitdebug info, and a generic phase for things which don't have a special option
<nckx>Since I have no idea what you mean (why would an upstream using Meson want that? Who's giving whom a CMakeLists.txt? Why? Oh god wh—) I have no choice but to assume I agree with whatever it means.
<elibrokeit>then another phase to collect the results
<nckx>elibrokeit: Sounds legit.
<elibrokeit>Another alternative is for all Linux distributions to agree on a common program to do this, and then use that :)
<nckx>Hehe. But I like your optimism.
<elibrokeit>Anyway, I can link you to my generic code for creating split debug info given a $DESTDIR full of executables and libraries
<nckx>The problem with setting CFLAGS is that, at least in my past experience, upstreams tend to regard almost any change as unreasonable Gento^Wmeddling. I'm very happy if that's a warped view.
<nckx>elibrokeit: Thanks.
<elibrokeit>Pure bash, loops over all files in $pkgdir and runs strip_file() on them. If the internal option "debug" is also set, it saves the stripped debug info to /usr/lib/debug following gdb's documented lookup procedure
<elibrokeit>If they don't accept CFLAGS=-g then you simply don't get debug info anywhere, which is sad, but means they don't get good bug reports with proper backtraces
<elibrokeit>Fortunately people using meson don't really get much of a choice :)
<nckx>That's what I meant to convey previously, so we definitely agree.
<nckx>Which is nice.
<raghavgururajan>Hello Guix!
<raghavgururajan>I am trying to package
<raghavgururajan>What build-system uses configure.apxs and Makefile.apxs?
<nckx>raghavgururajan: I guess
<raghavgururajan>Hmm. So I could use trivial-build-system and replace 'configure and 'build with (invoke "apxs ...")?
<raghavgururajan>Wait, never mind! I am bailing out. I only need those for testting. So I am just skiping it for now.
<zimoun>Dear, feel free to spread :-)
<nckx>raghavgururajan: OK! I think that's a good workflow (‘minimum viable package’, or whatever you want to call it, then debug each addition separately).
<elibrokeit>actually you should just run ./configure.apxs directly with apache installed as a build-time dependency...
<elibrokeit>raghavgururajan: ^^
<raghavgururajan>nckx: I see.
<raghavgururajan>elibrokeit, ah thanks! So I need use trivial-build-system right?
<nckx>raghavgururajan: The trivial build system doesn't have phases.
<elibrokeit>I genuinely have no clue. I'm not a guix user, I happened to be here for other reasons and noticed your message. My distro uses pacman and runs ./configure; make; make DESTDIR=${pkgdir} install directly, without abstractions
<raghavgururajan>nckx: That's perfect! I can create one right? Or should I use gnu-build-system and replace phases?
<elibrokeit>so, I can observe that the correct shell command to build mod_fcgid is here:
<elibrokeit> cd $pkgname-$pkgver
<elibrokeit> ./configure.apxs
<elibrokeit> make
<nckx>raghavgururajan: The latter.
<elibrokeit>it's up to you to interpret that shell command into guix code. :)
<raghavgururajan>elibrokeit, What are the odds. Haha. Thanks!
<raghavgururajan>nckx: Cool!
<nckx>You said apxs was only needed for the tests, correct?
<nckx>Otherwise: (replace 'configure (lambda _ (invoke "./configure.apxs"))) etc. It won't be as simple as simply adapting the Arch package though. It ‘just’ invokes configure && make, which is correct, but also… well, trivial. You knew that already.
*nckx AFK.
<elibrokeit>apxs is a program provided by apache, which you probably already need, though this might depend on how you do package splitting
<elibrokeit># configure.apxs --- build configuration script for creating mod_fcgid
<elibrokeit># out of tree using the apxs utility and httpd build toolset
<nckx>elibrokeit: It's part of httpd.
<dustyweb>substitutes seem so much better and faster and more generally available than they used to be
<dustyweb>that's nice
<elibrokeit>point being that I'm not sure how you'd build this without apxs.
<elibrokeit>(the basic point of configure.apxs is to print some paths, and sed those paths into Makefile.apxs. Including ${httpd_root}/httpd/build/ et al)
<raghavgururajan>nckx: mod_fcgid and mod_ftp was required for some tests in libsoup. But most tests work fine with just httpd. So I am skipping for now.
<raghavgururajan>Those mods are good to have in Guix, to use httpd. So it is better to package it right than doing quick+dirty work for just libsoup.
*raghavgururajan finished having soup. Now gonna have tea latte. This time the literal one.
<raghavgururajan>dustyweb, lzip i guess.
<NieDzejkob>I don't think availability would be affected by lzip :P
<raghavgururajan>Ah, I over-looked the availabilty part. I was referring to better/fast.
***Kimapr_ is now known as Kimapr
<PotentialUser-47>Hey guys, I can't seem to increase my resolution past 1080p. Do I need to install a driver. I have an NVida card. Also, how do you search for packages. Is there a GUI software store like Ubuntu has in Guix?
<sneek>Welcome back PotentialUser-47, you have 1 message!
<sneek>PotentialUser-47, nckx says: It's possible said image is still affected by the bug, depending on installation method. I've uploaded another one (to the same URL) that *definitely* isn't.
<PotentialUser-47>Also, I'd like to install PaleMoon, which is open source but it's doesn't appear to be in the store. Is there a way to install software outside of the guix stores?
<Kimapr>if you want to install it in guix you either have to use a channel with a package you want or make up a package definition for it
<Kimapr>PotentialUser-47: ^
<raghavgururajan>nckx: Could you please build openjdk, openjdk:jre and icedtea? REPO: ; BRANCH: temp ; COMMIT; 0d704013d0
*raghavgururajan tried something but it didn't come out as expected
<janneke>civodul: oops, you can ignore most of the v2 series, didn't see your other mails until now; i'll be sending a v3. only v2-0004 will probably be unchanged ;-)
<civodul>janneke: heh, ok :-)
<mfg>Hello again
<NieDzejkob>mfg: Hi, did you resolve your C++ paths issue?
<mfg>NieDzejkob: not really, i have to pass the sotre path explicitly via -L
<NieDzejkob>mfg: Hmm. The thing is, guix will only set the paths if there's something *in the same environment* that can consume them
<NieDzejkob>so if you're doing guix environment --ad-hoc some-c++-lib, you also need to add gcc-toolchain to that invocation
<mfg>i just tested again with gcc-toolchain added, but this also results in the linker complaining about undefined references
<mfg>ah wrong error, forgot to add -lcl and now it can't find that lib ^^
<mfg>now i understand why it doesn't work
<Bryophyllum>Hi! I'm in the process of rewriting my configuration files to work on a UEFI-only system, and I'm wondering if vfat partition can be specified by a label in my config.scm.
<mfg>the library isn't under the profiles lib folder but in a subfolder of it and therefore it cannot be found... So i indeed have to add the path manually to the LIBRARY_PATH
***slyfox_ is now known as slyfox
<mfg>(device (file-system-label "label")) this doesn't work?
<Bryophyllum>mfg: I'm gonna try it out in a VM
<mfg> this is my filesystem section
<Bryophyllum>mfg: Found an actively-maintained public repository containing other Guix user's configuration.scm, which contains a file-system-label entry in a declaration of a vfat filesystem mounted at /boot/efi. I suppose I'm being too overcautious, but I really want to avoid nasty surprises in a case, where I hit an edge user case.
<mfg>Bryophyllum: If you make a change that results in a not booting system yo can always select an older generation of your system in the grub menu so there isn't much lost if trying something
<Bryophyllum>mfg: Not if the directory containing EFI bootloader fails to be mounted on the first boot, then there will no grub menu to begin with, but I guess I'll have to bite a bullet if Guix doesn't boot. Hopefully, my secondary backup Linux installation won't be corrupted out of nowhere hahaha
<Bryophyllum>Hmm. I may have a wrong idea how EFI booting works in the sentence above...
<mfg>I see :D
<civodul>zimoun: i'm looking at the "tarball issue" on SWH and prototyping a tarball "disassembler/assembler"
<Bryophyllum>Actually, if it failed to be mounted, the worst that could happen would be no new generations appearing in the grub menu
<civodul>the goal is to see if we can reconstruct tarballs "from source" (metadata)
<civodul>which is kinda fun actually
<zimoun>civodul: so pristine-tar in Scheme instead of Perl ;-)
<civodul>actually not quite the same thing
<civodul>pristine-tar stores binary deltas compared to a repo
<civodul>here we'd just store tar headers
<civodul>but yeah, it's similar in spirit!
<zimoun>civodul: really cool!
<zimoun>BTW, I failed to package their Python CLI package, zack pointed me something to compute SWHID or something.
<nikita`>question, maybe someone knows about this. is the posix_spawn() in Linux+glibc in userspace only or is it implemented completely in-kernel (compared to what we have in netbsd, kernel only)? looking for more updated info for my post on gsoc :)
<nikita`>i mean I've seen the glibc side, maybe I'm mixing it up after reading what the 2012 report had
<qyliss>I think it's userspace
<qyliss>The string "posix_spawn" also doesn't appear anywhere in my kernel checkout :)
<nikita`>thanks. okay yeah, i could grep the linux source, at the start of it I just read some libcs
<civodul>qyliss: posix_spawn is implemented in libc in terms of vfork (IIRC)
<civodul>nikita`: ↑
<nikita`>right, makes sense. thanks :)
<nikita`>(if you are interested in the archive link, it's in one paragraph here:
<linka>hey! does anyone know how to mount NFS filesystems at boot?
<linka>i added them to my file-systems but they fail to mount because networkmanager hasn't started
<linka>and they stop the system from booting
<civodul>nikita`: nice!
<civodul>linka: hmm not sure how to do that
<civodul>it's probably not much used
<linka>maybe i can try no_netdev
<linka>and needed-for-boot
<apteryx>linka: it's not possible currently
<apteryx>NFS needs to be treated differently than the non-network file-system-service
<apteryx>so we'd need a new service type, such as network-file-system-service I think
<apteryx>that would be attempted to be mounted after the network is up
<jgart[m]>Is there an equivalent of `nixos-rebuild boot` in guix system? If not, is there any plan to implement this feature?
<jgart[m]>It seems that `guix system reconfigure config.scm` behaves similarly to `nixos-rebuild switch`.
<jgart[m]>I imagine `nixos-rebuild test` is similar to using `guix system container config.scm` or `guix system vm config.scm`? I haven't been able to test that since my bios does not support kvm virtualization (😶 libreboot...).
<linka>apteryx: thanks
<apteryx>linka: for now what i do is describe my NFS mounts with something like:
<mroh>linka: you could also try autofs which works very well (for me).
<apteryx>then I have a shell script (than needs root) that mounts the shares... it's a bandaid waiting to be fixed properly.
*janneke checks new childhurd offload
<alextee[m]>can someone review my patches plz? #42273 to #42283
<linka>apteryx: thanks :/ do you know if autofs can be configured by guix?
<alextee[m]>will submit zrythm update too in a few days, waiting for a few fixes to release
<mroh>linka: not with scheme config-records. but you can load the config files of course.
<apteryx>linka: no, I don't use it.
<janneke>oh my...the updated guix package does not build...In procedure open-file: No such file or directory: "/gnu/store/ws6dr2gb795pcly4rli4zk6p5xcmhv3m-guix-1.1.0-17.09573ab/share/guix/"
<linka>another problem i'm having is that i'm prompted for disk encryption twice. my store is on an encrypted filesystem. is there a way around it?
<dissoc>when services use a config file (computed-file ...) with #$output where is this file stored?
<janneke>guix offload: successfully imported '/gnu/store/pgpjhjlrnsmyzjh4x20ngsnzgw4pdiyh-import-test' from 'localhost'
<nckx>raghavgururajan: OK!
<raghavgururajan>nckx: Thanks!
<raghavgururajan>jgart[m], Hey o/
<raghavgururajan>jgart[m], I am using libreboot too. You can generate vm image via `guix system vm` and use qemu to start it.
<linka>sorry, my irc got disconnected :/ did anyone answer my question?
<jackhill>linka: disk encryption? No one answered, but as far as I now there isn't really a good solution for entering the password twice right now.
<jackhill>*as far as I know
<nckx>linka: Nope, it's a known annoyance.
<bdju>new minetest release! I hope the guix package gets updated soon
<bdju>looks like it was already behind a release before this one, it's on 5.1.1 and there was a 5.2.0
*NieDzejkob tries bumping minetest
<ATuin>I have a question, do i need to run guix pull as root before doing system reconfigure? or guix will take my changes from my user pull?
<lfam>ATuin: Guix is per-user. If you want to use your unprivileged user's pull, then you need to use `sudo --preserve-env` when reconfiguring
<lfam>Otherwise, run `guix pull` after logging in as root
<ATuin>a good i always do `sudo -E guix system reconfigure ...` after `guix pull`
<ATuin>in that case i dont need to run the guix pull as root, thanks
<apteryx>is there anything to do to get the native GNOME browser to play Youtube's HTML videos?
<mroh>apteryx: gst-plugins-* are installed?
<raghavgururajan>apteryx: I will make some changed to enable that.
<raghavgururajan>*will be
<NieDzejkob>bdju: Thanks for the heads-up
<bdju>no problem. were you able to update it then?
<athune>I'm having a problem with the emacs interface: packages from other channels than the main guix one don't seem to show up. Does anyone know how to fix this?
<jackhill>Is it possible to create a vm-image with btrfs? guix system vm-image -t btrfs creates one with ext4.
<jackhill>On the plus side, it boots even though I've said it is btrfs in my system config…
<lfam>jackhill: I don't think that command takes a "-t" argument
<lfam>Filesystems are configured in config.scm
<bdju>NieDzejkob: I just did a pull and I see it's updated already. thanks!!
<lfam>jackhill: I didn't know it but there is a -t (--file-system-type) option.
<ATuin>mmm weird after upgrading i can not load the stumpwm contrib modules anymore
<lfam>jackhill: If it doesn't work, that's a bug. Can you report it?
<jackhill>lfam: sure! I guess we don't currently support btrfs, but it should probably error or warn if I pass a value that's not supported.
<lfam>jackhill: We do support btrfs
<lfam>It might be a documentation bug, not sure. Please report it so we can keep track
<jackhill>I mean just with the image creation stuff. Gotcha makes sense, I'll do that.
<lfam>Some of the documentation suggests it only works for the disk-image action
<ATuin>anyone here using stumpwm-ttf-fonts?
<ATuin>i can not make it work
<jackhill>lfam: done:
<lfam>I'm trying to package op25 but it fails to build with "ld: cannot find -litpp", even though itpp is available in the build environment. Any advice for manually specifying the path when using CMake?
<lfam>Thanks jackhill
<civodul>opinions on git-authenticate, notably the command name?
<jackhill>you're welcome
<PotentialUser-47>is virtualbox avaiable as a package? I looked on the Guix website and didn't see it.
<PotentialUser-47>Also what was the command to search stores for software again?
<lfam>PotentialUser-47: No, virtualbox is not part of Guix
<nckx>PotentialUser-47: No, it's either impossible (at this time) or challenging to build using free software.
<nckx>PotentialUser-47: Not sure what you mean by stores. ‘guix search’?
<PotentialUser-47>Oh yeah, guix search.
<PotentialUser-47>Oh, I thought virtualbox was libre software.
<lfam>Unfortunately it's complicated
<lfam>Check here:
<PotentialUser-47>I guess it must have binary blobs or something, because I believe it was open source.
<nckx>PotentialUser-47: I think it is (or is intended to be) but building the BIOS requires a non-free (Watcom) compiler.
<nckx>That's my memory of the issue anyway.
<PotentialUser-47>Thank you lfam I will educate myself on the issue :)
<PotentialUser-47>@nckx OIC, that makes sense
<PotentialUser-47>I need to setup a vmware image, can I do that using something in the guix store?
<PotentialUser-47>Or using guix software availbable using the guix install command?
<jgart[m]>PotentialUser-47: Is that useful?
<jgart[m]>`guix install qemu`
<PotentialUser-47>I will try it out.
<PotentialUser-47>@jgart[m] I will try it out thank you.
<jgart[m]>you might want also:
<jgart[m]>`guix install virt-manager`
<jgart[m]>check out [this section]( in the manual for a way to setup a service for libvirt and virtlog daemons
<PotentialUser-47>okay, thank you jgart[m], I just need to set up a simple VM Ware Virtual Machine. Is libvirt and virtlog easier to setup. I don't need heavy duty enterprise features or anything.
<PotentialUser-47>Oh and the resolution on my guix machine won't go past 1080p without logging me out and not adujusting the resolution.
<PotentialUser-47>nckx said it is a glitch. Should I reinstall guix?
<jgart[m]><PotentialUser-47 "okay, thank you jgart, I just ne"> in that case just try installing what you need to your profile with the `guix install` command
<PotentialUser-47>The image I need to install is a VM Ware image. Can I do that with that? How would I do that. Sorry for all the basic questions :P
<jgart[m]><PotentialUser-47 "nckx said it is a glitch. Shoul"> no sure. Maybe someone else knows what to do that issue?
<jgart[m]>> <> nckx said it is a glitch. Should I reinstall guix?
<jgart[m]> * not sure. Maybe someone else knows what to do that issue?
<jackhill>jgart[m]: I beleive you will need to convert the image format first. Fortunately qemu comes with tools to do that. doesn't use guix, but otherwise sounds similar to what you're trying to do.
<jackhill>er I guess that was for PotentialUser-47. Please see my preivous message.
<nckx>PotentialUser-47: I'm not sure I follow, but I think the ‘glitch’ message your refer to was for a different PotentialUser. Sorry for any confusion.
<nckx>It's hard to keep track of these random user names.
<nckx>I left that one yesterday for someone having trouble with the installer, doesn't sound like you're the same person.
<raghavgururajan>nckx: Can compilers and environment cause md5 mismatch?
<nckx>raghavgururajan: That response is so vague I can only say: yes, they certainly can.
<nckx>If their test just checks whether their own self-built Travis CI binaries always look the same, said tests have little value.
<nckx>‘This test checks whether Bob's binary matches this hash. Reproducible? Sure, if you borrow Bob's machine.’
<raghavgururajan>nckx: Okay. In that case, we can never enable tests that does md5 check on test files?
<NieDzejkob>You'll need to debug more
<raghavgururajan>Just a sec.
<NieDzejkob>I doubt they're checking for reproducibility of binaries. I'd rather guess that they want to check whether the raw pixels that the decoder produces are correct, or something like that
<NieDzejkob>in such a case, you wouldn't want to put the expected result in the source tarball, since it can be quite large
<raghavgururajan>Those can be applied on master.
<nckx>raghavgururajan: I didn't say that, but ‘can’… yes. They ‘can’. I'm looking at the package now. & thanks for the patches.
<raghavgururajan>nckx: Cool!
<raghavgururajan>NieDzejkob, The files are not binaries. They are image files.
<nckx>raghavgururajan: error: openjpeg-data: unbound variable
<raghavgururajan>nckx: Yeah, I pasted patch for that too.
<nckx>Ah, it scrolled away.
<jgart[m]><raghavgururajan "jgart, I am using libreboot too."> raghavgururajan: Did you add CPU microcode updates to make virtualization work with libreboot?
<jgart[m]>> <> jgart, I am using libreboot too. You can generate vm image via `guix system vm` and use qemu to start it.
<jgart[m]> * Hey raghavgururajan: Did you add CPU microcode updates to make virtualization work with libreboot?
<raghavgururajan>> ‎jgart[m]‎: * Hey raghavgururajan: Did you add CPU microcode updates to make virtualization work with libreboot?
<raghavgururajan>Hey Jorge! No, I did not update the microcode.
<raghavgururajan>jgart[m], What device do you have? Mine is X200-T.
<PotentialUser-47>@jackhill, once I convert the image, what would be the next step in getting it running in guix?
<raghavgururajan>NieDzejkob, Oh, you meant the binaries (decoders) that produce the images files?
<jgart[m]><raghavgururajan "jgart, What device do you have? "> I have a few librebooted computers: T400, X200, X200-T, and X60. I tried to run