IRC channel logs
2025-02-20.log
back to list of logs
<sobol>seems to have been down for a while now <anticomputer>so I defined a package, debugging its build with guix build, I consistently get a meson error that says a git clone for a https failed, that very git clone succeeds fine when I try it outside of the build container, so presumably there is some common thing I need to pass in there, is there a way to drop into the container env at the configure phase to continue debugging by hand? <anticomputer>and that clone succeeds fine in the debug env, so likely some default network or tls config for the build daemon? <eikcaz>I'm sure this sounds like a stupid question, but humor me. Should "guix pull --commit=<fixed commit>" generate a profile with the same build hash (i.e. hash in /gnu/store/<hash>-profile) on different machines? <eikcaz>anticomputer: I don't think you should be git clone'ing anything during a build. I believe building is done in an offline container <eikcaz>You need to obtain the git repo and pass it in somehow. <anticomputer>eikcaz: that makes sense from a reproducibility standpoint, it's not something I'm actively wanting to do, I'm extending an existing package and it falls back on a git clone due to a missing dependency, I'll poke at it some more, probably I'm not inheriting something properly <anticomputer>yeah the dependency doesn't exist as a guix package is the thing, it's some submodule that's supposed to be getting cloned into the main source tree it looks like <eikcaz>hmm. Is it a recursive git submodule? Maybe you can just include it with the recursive flag of the origin reference or whatever? <eikcaz>Re my previous question: I now have 3 machines with different build hashes for "guix pull --commit=<> --system=aarch64-linux". <mange>Builds definitely happen in a container without network permissions. In the worst case you can add the git repo as an (origin ...) directly as an input, and copy it into where it's needed in the build. <mange>eikcaz: I would have expected the same Guix commit to have the same build hash, for the same commit. Do they have the same content in the build output? <eikcaz>off for dinner now, but I'll check and report back <k-man>i'm compleetly new to guix. I just set it up in a vm using the qcow2 image. guix pull seems to take a while. is that normal? <eikcaz>whatever the source of the issue, it causes serious problems as my machine can't find substitutes as the hash differs for many packages <k-man>it's not clear to me. do I want to do a sudo guix system or sudo -i guix system... ? <mange>I just use "sudo guix system ...". Did you set this VM up using the qcow2 image from the Guix download page? <mange>It's possible that image doesn't have a config file inside it. <mange>Only if you want to update the system. :) <k-man>ok. let's pretend i want to update my system. what should I put in my config.scm? <mange>I don't know for sure, though. <anticomputer>mange: just a bit confused as to why since it's a fairly simple inherit of an existing guix package, I'd expect it to hit the same build issues upstream? but will poke at it a bit more <anticomputer>actually let me try and build that base package and see what happens <anticomputer>hrmm so when I manually propegate the parent package arguments my extended package builds fine <anticomputer>does inherit not imply that arguments are propegated as well? <mange>Using "inherit" is essentially the same as setting each field explicitly to the inherited value. If you set (arguments ...) in your call then it's up to you to combine your value with the inherited (package-arguments record) value. <mange>So (package (inherit X) (arguments `(#:tests? #f))) would override the arguments of X in the inherited form, but (package (inherit X) (arguments `(#:tests? #f ,@(package-arguments X)))) will prepend to them. <anticomputer>aaah and then with package-arguments and substitute-keywords-arguments, got it <mange>Yeah, "inherit" is fairly naive. It doesn't know anything about what's inside the fields, so it can't do anything to combine them. <anticomputer>kay so I get through the compilation part but, I'm assuming because we set our epoch to something consistent for reproducibility, I bomb out on a Python unzip test ala raise ValueError('ZIP does not support timestamps before 1980') ... I tried adding a build phase mod that sets SOURCE_DATE_EPOCH to something > 1980 but that doesn't work, since the test file is created during the build phase I can't touch it either to update its <anticomputer>timestamp before the test runs, is there a common way to deal with this kind of thing? <anticomputer>ah just had to set and touch after unpack, it was the files it was ADDING to the zip that it was tripping up on,works now <anticomputer>wellp that was a useful journey through packaging internals at least :) <meaty>Is there a way to "decompose" the arguments to a scheme function? <meaty>e.g. (apply (lambda ((a . b) c) (+ a b)) '((1 . 2) 5)) -> 3 <PotentialUser-86>Hello guys I just wanted to say that the package repository browser on the main guix website has been down since at least yesterday <PotentialUser-86>I'm just trying to look at some packages in the browser and maybe look at some sample build configurations <iyzsong>meaty: sounds like (match-lambda (((a . b) c) (+ a b))) from (ice-9 match) <meaty>How do I load bash completions into 'guix shell'? <aure84>Hello. When I run `guix system vm` on the `system/examples/vm-image.tpl` I get a XFCE-based with autologin, where a "unnamed window" appears fullscreen. futurile has seen this behaviour before. Is it a bug that should be reported? <mange>Hmm! I don't know, but I think I've seen the same thing! One of my Guix systems is set to autologin and autostart Firefox, but there's a second unnamed window that shows up as well. That system is using i3 and the slim-service-type. I'll check the vm-image to see if it's similar. <mange>Ah, it also uses slim-service-type! I wonder if that's what's causing it... <aure84> mange slim could be the culprit. I experience the same issue if I replace XFCE by openbox <mange>I'm trying to reconfigure my machine with sddm, but it's complaining with <mange>"extraneous field initializers (xorg-configuration)" <mange>which is surprising me, given I can see it in the manual and in the code. <mange>Ah, it was because I hadn't used (gnu services sddm), but the xorg-configuration object was failing at the syntax expansion step, so I was getting a misleading error message. <aure84>mange: do you mind to share a paste if you get a base working system? <fnat>I get this error when building a stripped-down VM image with OpenSSH: guix system: error: service 'ssh-daemon' requires 'loopback', which is not provided by any service. Any idea on what additional service is required here? <fnat>I do have DHCP already (dhcp-client-service-type). <iyzsong>fnat: %loopback-static-networking, as defined in (gnu services base) <fnat>Aha! Got it, I must have dropped the basic services by mistake - thanks iyzsong! <mange>aure84: I've got it working with something like (service sddm-service-type (sddm-configuration (auto-login-user "my-username") (auto-login-session "i3.desktop"))), where you could use xfce.desktop instead of i3 if that's what you're using. <mange>I expect the slim thing is still an issue, and maybe should have a bug raised, but at least I can avoid the problem with sddm. I expect you could use gdm or lightdm or whatever, too, if you wanted. I haven't tested, though. <mange>Thanks for the prompt about slim, though! I doubt I would have worked that out without you mentioning your issue. :) <efraim>civodul: I'm still looking through the manifests I sent before, but right now I'm stuck on `guix build -m manifest.scm --system=i686-linux` and (%current-system) being x86_64-linux <civodul>the ‘release.scm’ manifest would automatically try all the supported system types (thus ignoring ‘--system’) <efraim>I wanted to make it so that it could be built per architecture, for the different build farms <efraim>and so people could try it out on their systems without needing to edit it down to the architectures they had access to <civodul>right, so removing the always-all-systems-by-default thing <civodul>and so you’re saying -s is being ignored? <efraim>I'll have to re-build what I had since I foolishly threw it away yesterday, but I had supported-package testing against x86_64 and then package->manifest-entry working for i686 <efraim>yay! forgot to close vim so I still had a copy of it <efraim>I've been testing it with i686 since gnome isn't supported <mra>civodul: sorry to bug you, but have you seen Maxim's updates on 41602? they seem to bear on our ability to merge 55231. <mra>just something to look at if you have time :) <efraim>civodul: I think I found a solution to `guix build --manifest` not honoring --system, now I need to see about making --system not be position dependant <dariqq>efraim: One thing that does not currently work for i686 is mate: ( some test failures in dependencies for cantarell, i have a bit more info in #73575 ) <efraim>yeah, that font has been causing problems for forever <dariqq>it depends on the entire python world ... . I have not tried what happens if it is missing. xfce has no issues without it <aure84>mange: thanks for the snippet. It seems to be working fine. To me, that confirms a bug in slim <kxfh>I just installed guix for the first time and like it a lot so far :) <kxfh>I chose exwm in the installer and don't seem to be able to change the emacs version to emacs-next. <kxfh>With this in config.scm... <kxfh>(packages (append (list emacs-exwm emacs-next) %base-packages)) <kxfh>...guix still boots into emacs-29.4, though only emacs-next exists in the system profile. <kxfh>/var/guix/profiles/system/profile/share/xsessions/exwm.desktop <kxfh>still pointing to a exwm-script that loads emacs-29.4 from some place in the store. <kxfh>Did I do something wrong / do I need to do more than <kxfh>sudo guix system reconfigure config.scm? <kxfh>... oh and sorry for the formatting - is there a proper way to do multine in erc/irc? Haven't used it in a long, long time. <jakef>guix system: error: error parsing derivation `/gnu/store/gr7jfs1i9iayxvymb5j0xxcfkbbkd1qy-module-import-compiled.drv': expected string `Derive([' <jakef>getting that on a system reconfigure at 00787cd <fnat>kxfh: How do you launch Xorg/EXWM? I use startx+xinitrc. In my xinitrc I explicitly launch Emacs which is then configured to use EXWM. <fnat>If you check on the command line, do you get any other Emacs version other than 29? <fnat>Have you checked the store /gnu/store to see if there's any trace of emacs-30 or emacs-next? <fnat>In terms of the formatting, I think the best practice is to avoid blank lines and large blocks of text. For anything that requires more space and/or formatting, use a pastebin service, e.g. paste.debian.net or one of the many available. <fnat>Unrelated to the above, I've created a Guix system image from a repository checkout with 'pre-inst-env guix system image ...'. When I boot the image I'd expect 'guix describe' to return the commit of my repository's HEAD, but that's not the case... I wonder why. I had run a 'make clean && make' before creating the image. <iyzsong>fnat: you can use (current-guix) for the system guix. see gnu/system/examples/vm-image.tmpl for its usage. <fnat>iyzsong: Hey, super, thank you!! <vhns>Is there an easy way to do a package transformation on a package that inherits another package? I currently need wpa-supplication version "2.6" for testing, but I can't just (define my-wpa (pacckage (inherit wpa-supplicant) (version "2.6"))) and be done with it, as wpa-supplicant inherits wpa-supplicant-minimal. <fnat>Interesting, if I use current-guix from the context of a local checkout I get an error during the authentication phase though. Rightly so, I guess... <kxfh>fnat: exwm is launched via gdm, as it was set up by the installer (through %desktop-services) <kxfh>On the command-line I get emacs-next. The old emacs only exists @ store, nothing linking to it except the "exwm-executable" script that /var/guix/profiles/system/profile/share/xsessions/exwm.desktop points to. <fnat>kxfh: You might have to create a custom version of the EXWM package that uses emacs-next instead of emacs. (Just my hunch!) Otherwise, if GDM is negotiable, you could try a startx-based approach. <kxfh>As far as I understand its definition, emacs-exwm shouldn't be tied to a particular emacs version. <kxfh>Thinking about it, the exwm-executable must have been updated at least once: My initial install had emacs28 and after a guix pull it became emacs29. I might have messed something up in between... vagely remembering needing a --force on one of the pulls or reconfigures. Will re-pull and see what happens. Should I run sudo guix pull as well, or is that only ever needed when running guix on a foreign OS? If it fails, i'll try startx. <kxfh>Feels cleaner anyways :) <noe>Hey, could any committer take a look at #74972? I set it to reviewed-looks-good but it doesn’t show on QA, its a simple patch to add a font. <csantosb>And here we go for a 9 years old update ... #76438; is this a record ? <oriansj>odd thought but the stable guix ISO really needs to be updated. It hasn't been updated since 2023 <divya>Where does Guix System have its sysroot headers? Apparently I need them while compiling something <avalenn>I would like to have some script launched at least once per week on my laptop which is not always powered on. Do you know what is possible with shepherd timers ? <Kabouik>It's not clear to me where the conflict in my profile could be. <dariqq>Kabouik: pandas depends on numpy@1 and this conflicts wiht numpy@2 <Kabouik>So I should just try to install pandas, right? <dariqq>that should also make numpy available, yes <Kabouik>The Guix error is confusing, it seems it's hard to understand what the issue is without manually checking (and being able to read) package definitions. <civodul>avalenn: shepherd timers only fire when the machine is on on the specified calendar event <civodul>you can also fire them manually with ‘herd trigger’ but that’s not ideal in your case <avalenn>nope, my hope would be to not need to do it manually <civodul>i guess we should add support for that <civodul>kinda annoying because it requires keeping track of state across reboots <ieure>There are other things it'd be nice to save/restore across reboots, like screen brightness and maybe volume level. Don't like when I boot Guix in the evening and the brightness is at 100%, which is what things default to. <futurile>lechner: he's normally here as 'sharlatan' I think , but doesn't come to IRC that much (I think). On Mastodon often. <avalenn>cidovul the only info to track across reboot is the last execution date, but yes it is needed <lechner>ieure / there is software to adjust screen brightness (and color) by time of day <ieure>lechner, Is there something like that which runs early in the boot process? I'm aware of redshift, but that's a home service, which means I get blasted in the face by the greeter at 100% brightness before it can do anything. <lechner>you adjust your terminal brightness? <ieure>There are files in /sys/class/backlight which control the screen brightness. Debian saves the value on halt/reboot and restores it when it boots. <ieure>It's a good feature, even if it is stateful. <ieure>Could definitely restore, not sure if save would work that way. <ieure>Depends on what environment you use. DEs generally have some kind of integration. I wrote an Emacs package to deal with it. <ieure>My point here isn't that "Guix should implement [thing I want] for me," but that if we have a few things that need to persist state across boots, it'd be nice to have some well-defined place (at least) or mechanism (ideally) to handle doing do. <lechner>a definitely agree with that, although please consider also the vexation that might occur when one of those values is off by mistake <lechner>you adjust the backlight all the time? <ieure>lechner, I adjust it as needed, I don't know if that qualifies as "all the time." <ieure>That's all I ever use, light text on dark background causes me physical eye pain. <ieure>If I use the laptop outside, I turn it way up, if I'm inside during the day, it's 30-40%, if it's dark outside, generally 15% or so. <ieure>I mostly work around it by not rebooting too often. <lechner>how about a udev rule that adjusts the brightness by hour of day? <lechner>that's until we figure out how to measure the incident sunlight via your camera <ieure>Wouldn't like that, it can't tell if I'm inside or outside. I generally dislike automatic brightness stuff. Save/restore across reboots is really the only thing I want. <lechner>okay, but don't people usually turn the computer off inside and then go outside, or the other way around? you reboot while outside? doesn't the persistence just reverse your problem the other half of the time? <lechner>sorry, I am just asking. not trying to convince you that you don't have a valid issue <ieure>The way I adjust brightness throughout the day is orthoganal to the thing I'm saying I want, which is, if I turn the laptop on, it shouldn't default to 100% brightness, it should default to whatever it was when it shut down. <ieure>It currently defaults to 100% brightness. While there's no automated way to know what I'd like the brightness to be at any particular boot, 100% is the worst possible value to default to. <ieure>Could I make it default to 50%? Yes, definitely. Is that what I actually want? No, not really. <lechner>also, my cynical self says that Debian needs to preserve the value across reboots. My Guix equipment is so stable, I reboot it every two months <ieure>lechner, That changes what driver ends up handling requests to change the backlight. Maybe some vendors store the brightness in an EEPROM? I don't know. Whether it does that is going to vary based on hardware. Guix supporting it will make it work consistently everywhere. <ieure>Again, the *specific* usecase I care about is cold booting. <ieure>Yes, I often suspend. But something about Guix makes it drain *way* more battery during sleep than Debian does, so I sometimes find the battery dead flat when I open the lid. <ieure>I reboot Guix way more often, because the kernel updates way more often. 67 days uptime on my Debian desktop, but that's only because there was a power outage. <ieure>Anyway, I have to focus on work instead of repeatedly explaining why I want a particular thing. Again, my point is that if Guix needs to save some state across reboots, it would be nice if that was reusable for other stuff which could also benefit from that. <redacted>using the host-environment configuration parameter of the oci-container-configuration, can I use a gexp to do something like PASSWORD=$(pass ls docker/service-password)? <redacted>Assuming I want pass to run at run-time, not build-time <Rutherther>redacted: yeah, just create a program-file that will run the command you want <redacted>What user will run that command when the host environment is created? <Rutherther>although no sorry that probably won't work, it seems to expect just strings <redacted>Docs say it accepts gexps, though, I think <redacted>"Pair members can be strings, gexps or file-like objects." <Rutherther>that something expects gexps doesn't mean it will execute a script on runtime when you give it something that's a script <redacted>oh, right. it's not necessarily using 'sh -c' or something to set environment variables <redacted>I'm confused by the claim that it's for securely adding secrets then. Isn't any string you give it going to end up in the globally-readable store? <Rutherther>it just directly puts it to #:environment-variables of shepherd service <Rutherther>yes, you are right you would need run time script as you want for safe secret management <Rutherther>I don't know what the idea was that makes it secure for adding secrets <lechner>Hi, should the output of ./etc/teams.scm list-teams be an S-expression? <jackhill>I produced a pack with ` guix pack -RR -S /bin=bin -S /etc=etc libreoffice bash glibc-locales <Rutherther>jackhill: my guess is that the issue is with the user. I also am using packed guix on rhel, I had an issue with emacs where it doesn't find the user and I have to append "--user """. Not sure what the workaround will be with libreoffice, but judging from that "cannot open /libreoffice/4/user/registrymodifications.xcu: 21", there should likely be something before /libreoffice, like $HOME/.config (I don't know specifically) <Rutherther>so the question is how does libreoffice recognize the user and you should try to give it that, so it knows where to find config <df>is there a reason why (by default) GUILE_LOAD_PATH doesn't contain /run/current-system/profile/lib/guile/3.0/ as well as ~/.guix-profile/lib/guile/3.0/? <df>ie guile packages installed by the system profile are not available by default whereas those in the user profile are? <Rutherther>df: there is no default in this, you need to install both guile and the package in the same profile to get the search path <jackhill>Rutherther: hmm, --user with the empty string, with my username, and with =my-username just prints the "error in option --user" and the help message <Rutherther>jackhill: I think there is a misunderstanding. I said that was the solution for emacs. Not that it will work for libreoffice. Just that the symptom is the same, so there has to be a workaround applied to find the user's home/config dir. <vagrantc>ACTION makes a plea when posting to the list (and in general) to use --long-hand options rather than -s ones :) <Rutherther>jackhill: you can try exporting USER and USERNAME, maybe redhat exports just one, but that is just an initial guess, to know for sure probably googling will be necessary to know how libreoffice handles user profile loading, to know why the libreoffice from guix pack isn't seeing the correct user <jackhill>Rutherther: indeed there was a misunderstanding. Thanks! <jackhill>vagrantc: oops, I'll do better next time :) <vagrantc>jackhill: oh, i was responding to the thread on guix-devel where i had to read halfway through the thread before i had a clue what it was :) <old>any thing for handling coredump like systemd does for Guix? <df>er... actually I seem to have been wrong <df>/run/current-system/profile/etc/profile *does* contain a line adding <system profile>/share/guile/site/3.0 to GUILE_LOAD_PATH <df>not sure how I missed that before <df>I'd say it was changed by my recent reconfigure adding a guile package to the system, except that that failed <vagrantc>do i need patch review to convert gnu/packages/usb-modeswitch.scm to UTF-8 ... seems to be encoded in ISO-8859 ... or should i just push it? :) <vagrantc>seems to use the ISO-8859 encoding for the copyright symbol... <vagrantc>i have splitted my abbrevation one last time <fnat>I applied a patch to my local checkout. I then wanted to build a VM with './pre-inst-env guix system image ...' but I get a Guix authentication error (the patch shows up as unsigned commit). I think it might be this https://issues.guix.gnu.org/57229. The workaround mentioned in the bug report doesn't seem to work here. Any ideas? <fnat>(I'm running a make on a fresh checkout + patches of the repository now.) <lechner>Hi, is the "Recent issues" list on issues.g.g.o being updated for anyone? <ieure>lechner, It's been broken since early January. <lechner>Hi, does anyone think 'candle' should be shipping a (sole) executable starting with a capital letter, namely 'Candle'? <ieure>lechner, Is your beef with it shipping one binary, the capitalized name, or both? <meaty>Would packaging things for Guix count as volunteer work? <ieure>meaty, I was wondering this myself. I think it's unquestionably volunteer work if you're not getting paid, but I'm not sure if it's something you can turn into a tax advantage or do if your employer lets you take VTO. <ieure>I think for the latter, most US-based companies want the volunteering to be a 401(c) of some sort for it to count. Maybe the GNU project Guix is under the umbrella of counts? Hard to say. <lechner>ieure / the capitalized name without a lowercase link <meaty>nah, was just wondering if I should put it on my CV <ieure>lechner, It's definitely uncommon, but not unheard of. I think it's really up to the users of the package, what are they going to expect to work when they try running it? <ieure>Would assume that if it's capitalized upstream, they'll know that's how to invoke it. <lechner>ieure / Do you use NetworkManager in Guix? <lechner>meaty / i would put in on your CV so you can tell prospective employers about one cool project <lechner>ieure / actually, nvm. we don't restyle that either <vagrantc>ooops. one of my typo fixes actually triggered rebuilds... <vagrantc>guessing it was the changes to guix/build/kconfig.scm <mra>hey, I'm working on hacking together a Guix+ZFS system for myself, and to construct the file-systems, i need to understand how Guix actually translates a declared file-system into a call to `mount` by the initrd to figure out what I need to hack. what should I look at here? <ieure>mra, I think it serializes out to a fstab with the auto option set. <ieure>Can you even mount ZFS with mount(8)? <dstolfa>ieure: basically ZoL ships a mount.zfs which i assume mount just calls out to, much like any other mount.X <dstolfa>so assuming that's present, it should work <ieure>dstolfa, Well, you can't mount unless the system knows about the pool. Debian keeps pool state in /etc/zfs/zpool.cache, or you can `zpool import -a'. Maybe mount.zfs does all that for you? But typically, you cannot simply mount some ZFS, because those are logical volumes within a pool, and something has to tell the system that the pool exists first. <dstolfa>but my usage of zfs is limited to freebsd and 1 ubuntu machine, so i don't know how it'd work on guix as it currently exists <mra>ieure: it mounts just fine with mount, yeah. just set the mountpoint to legacy <mra>oof, indeed. I hadn't considered the problem of importing the pool. that's another thing that the initrd will have to do <mra>I can probably write a gexp and pass it as #:pre-mount? <mra>I guess I'll have to pick this up tomorrow anyway. I have a class at 8 am, so I should sleep <ieure>mra, Appreciate your work on this! <fnat>I've been (happily) using guix deploy with the new Hetzner environment type. I get this warning though: "<machine-ssh-configuration> without a 'host-key' is deprecated". Should I somehow pass the host-key when setting the environment type? <nikolar>yes, if you want to mount zfs pools through mount(1), you need to create it with mountpoint=legacy <vagrantc>why does make dist need to build all of guix?