<nckx>If you want to include outputs in a simple list you can use something like (map (compose list package->specification+output) (list "blah:bluh" …)).
<nckx>I don't use guix home but I assume the same applies: (packages (append (map (compose list package->specification+output) (list "cataclysm-dda:tiles" "more:outputs" "if:you" "want:them")) (list regular package variables if you want those))
<porcupirate>Unstable? Putting too many packages in the same profile?
<nckx>No big reason. I'm not feeling a gaping hole in my ~ that needs to be filled, tubes. It's that simple. I'll probably try it out when it's had time to stabilise, and maybe I'll be enlightened, but I doubt it.
<nckx>Manifests nicely take care of the only part of my user account I want Guix'd.
<char>Since I am ont sure why my binary could find the dynamic libraries, it is not working again. Durning cmake, it says the libraries are found. during ninja, no complaints. during runtime, library not found.
<reily>Tests are failing for password-store after latest pull.
<lfam>Heh, I like the first note in the tree 2.0.0 changelog: "Nothing is terribly well tested since there are a lot of changes and I would like to get this out the door finally, please report breakage."
<nisha>Hello! I am trying to get package definition generated by `guix import` to build but I get an error "unbound variable". I am not sure what's wrong. Can anyone help? My .scm file is here: https://paste.debian.net/1226913
<lfam>What the importer gave you needs a little extra work in order to be build-able
<nisha>lfam thanks! I figured it needed some extra work, but I think what is in there is accurate?
<lfam>First, you need to wrap the (package ...) in something like (define python-tern (package ...))
<lfam>Then, you need to make this Scheme file "return" the package you want to build. Then, you'll be able to do `guix build -f yourfile.scm`
<lfam>It will fail, because you still need to import the modules that contain the dependencies. Guix will give you a hint as to what they are
<lfam>For example, (gnu packages python-xyz) and (gnu packages python-crypto)
<lfam>However, this package has some dependencies that aren't yet part of Guix, such as python-debian-inspector
<lfam>You used the pypi importer, right? I think you need to do it again with the --recursive option in order to import unpacked dependencies
<nisha>I thought I did use the --recursive option. I will try again. Thanks again for the guidance lfam!
<lfam>When I try `guix import pypi --recursive tern`, it does add a bunch of other packages, and also takes care to "wrap" them in the define-public expression
<lfam>Hopefully from there, it's only a matter of importer the modules that contain the dependencies that are already part of Guix. But maybe there will be some manual fixes required to get everything to build
<lfam>I meant, to write "only a matter of importing the modules that contain the dependencies". Of course, this a different kind of "importing" that what `guix import pypi` does :)
<porcupirate>I have a long list of packages and I need to check if they can be substituted. I don't want to overwhelm the substitute servers with all those individual https requests. Is there a way to filter a list of packages with these constraints?
<rekado_>interestingly, the IT of the Berlin Institute of Health (which has their servers in the same building as our data centre) disagrees and expects the problems to last for a couple of days longer.
<jts>Hello. I'd like to try out Guix, but I can't seem to get the live image to boot. It begins outputting kernel messages and then just stops. I was getting errors related to pcspkr and sp5100_tco, but after some web searching I disabled those modules in the Linux commandline via GRUB. Now the only message I'm seeing is an error from udevd saying "no sender credential received, message ignored." Does anyone know what may be causing this and how
<asdf-uiop>roptat: thanks! weird that it does that for some and not for others.
<asdf-uiop>I pressed enter too soon: the one that worked probably just was correctly styled
<bost>roptat: I get 'invalid value for parameter "lc_messages": "en_US.utf8"'
<NicholasvonKlitz>I'm currently packaging the latest version of nextcloud-client, but it depends on a source file from the kirigami package which is not included in its outputs by default (wheelhandler.cpp). What is the recommended way to continue forward?
<NicholasvonKlitz>NicholasvonKlitz: Do I modify the current kirigami package to copy the applicable src file to the outputs?
<paul_j>Quick question: I have a system shepherd service called term-auto which is currently stopped, and doesn't restart. What is the purpose of this service, and would I expect it to be stopped?
<paul_j>I am playing with a VM installation on QEMU and noticed this, but the same service on my laptop is also stopped at the moment.
<roptat>bost, mh, I don't use postgresql, so I can't really help, but maybe you should look at documentation about migrating to the newer version? maybe something changed with the configuration?
<roptat>paul_j, I don't remember what it does, but I think it's expected to be stopped
<roptat>paul_j, herd doc term-auto → Run agetty on a tty.
<paul_j>roptat: that's good to know. Everything seems to be working OK, so I wasn't unduly concerned, but when updating the system I get the message about restarting services so I thought I had better educate myself!
<paul_j>roptat: I hadn't come across the doc option - thanks!
<roptat>NicholasvonKlitz, does it really need that file, or can it use the library from the system? depending on a cpp file is unusual
<bost>roptat: I definitely should do that sooner or later. But for the moment I thought I'd stick with 13.3 and that should be easy since I use guix... but it's not. Ugh.
<roptat>you can roll back to a previous generation where you had 13.3
<mothacehe>bost: you can also define you own 13.3 package inheriting from postgresql-13
<roptat>or use an inferior to fetch the package from a previous guix revision
<bost>roptat: by inferior do you mean `guix install firstname.lastname@example.org`? That doesn't work.
<roptat>no, "inferior" is guix jargon, it refers to using a package definition from a previous guix revision
<roptat>you can only use inferiors when writting guile, not from the CLI
<roptat>you can use inferiors in manifests and operating-system declarations
<bost>roptat: Actually I'm trying to do that since about a half an hour. The last commit with postgres 13.3 is the afe8ecd and I took the gnu/packages/databases.scm from it and now I'm trying to add it to my own channel.
<bost>roptat: ... and it seems like my real issue is not the postgres 13.4, but it has to do something with the 'invalid value for parameter "lc_messages": "en_US.utf8"'. And looks like something about 'locale' (whatever that is).
<roptat>mh, locale is about your computer's language
<abcdw>roptat: Seems it failing in a clean guix installation too. I did `guix time-machine --commit=0f869287ebf -- time-machine --commit=a79ad5fce5 --disable-authentication -- describe` on a separate machine.
<abcdw>bost: Thank you for checking it =) Maybe someone else can try to reproduce it? civodul, efraim.
<NicholasvonKlitz><roptat> "Nicholas von Klitzing, does it..." <- Yes it really does depend on the file.
<NicholasvonKlitz>There are other third party dependencies like this in nextcloud-client and they are resolved by substituting the source from with the sources files included in the outputs of the respective package (ex for KWidgetAddons). This doesnt work for kirigami because the required source files are not included inthe package outputs
<civodul>abcdw, bost: could you email bug-guix with a reproducer?
<civodul>i have a hard time following the discussion in my backlog :-)
<KarlJoad>Maybe I'm just uninformed, but why does Shepherd have such a hard time following processes sometimes? Like forking ones?
<jpoiret>wdym by having a hard time following processes?
<nckx>KarlJoad: Is it even possible to reliably follow forking processes at all without using cgroups? Because then the answer is ‘Shepherd doesn't use cgroups’. Bit circular, true, but that was my understanding :)
<jpoiret>oh, you mean if the process that shepherd starts itself forks?
<nckx>The traditional method is to use PID files but that's not really following, more like trusting your teenage kids to always truthfully tell you where they went.
<jpoiret>nckx: but wouldn't you expect the daemons you're running to be able to report the proper PID?
<jpoiret>i expect my init system to be able to launch containers with services embedded in signed usb devices
<jpoiret>- every systemd user ever, including someone's 60-yo grandma
<jpoiret>for anyone who hasn't done this yet, I suggest reading the latest systemd version changelog. It's quite entertaining.
<nckx>I expect my init system to not routinely lose track of foo-d so ‘herd restart food’ fills the log with ‘can't frotz, is foo already running? disabling service foo’. Clearly my expectations are unreasonable.
<utkarshsingh>Where do you find base32 hash for a Github software release?
<sneek>Welcome back utkarshsingh, you have 1 message!
<sneek>utkarshsingh, robin says: i think the netfarm author hangs out in #lispcafe, nick 'hayley', fyi (she's also a sicl hacker possibly?)
<smarton>civodul: hmm... I ran the first pull on a fresh Guix System 1.3 and that line appeared at least a dozen times. Reconfigure is running now and it appeared just in the begining however, so I guess showing it only once is a newer feature
<xelxebar>What am I doing wrong here? With `hello' this built, but with my custom package it doesn't: (run-with-store (open-connection) (mlet %store-monad ((hello (package->derivation hello))) (build (list (derivation->output-path hello)))))
<xelxebar>With my custom package, it just returns #t, but with `guix build --file' it starts a build as expected.
<nckx>utkarshsingh: The safest way is to clone a clean copy of that repository, cd into it, then run ‘git reset --hard 2.6.4’ and ‘guix hash -rx .’.
<KarlJoad>nckx: Is there a technical reason shepherd does not use cgroups? Or is it a legacy thing?
<nckx>If you don't actually bother verifying your checkout (or they don't sign their commits anyway), you could also write a provisionary package with a bogus hash (copy one from another package), try to build it, and Guix will complain & spit out the correct hash.
<nckx>KarlJoad: I don't know and I don't know if I want to know.
<jpoiret>KarlJoad: I think Shepherd (known as dmd when the project started) predates cgroups
<xelxebar>jpoiret: You consistently give on-point answers. So annoying :P
<g_bor>what happened is that the devices were detected the other way around that they usually are, so instead of just clicking through everything I actually had to update the device selection, as the install CD was selected
<utkarshsingh>nckx: Again thank you! And what about installing and re-installing them?
<jpoiret>installation in guix is stateless: you won't gain anything by reinstalling the same package
<jpoiret>ie, there are no hooks that change your system in any way
<g_bor>Is there a way we could get rid of hash guix after pull?
<nckx>If you used ‘guix install’, running ‘guix install’ again will replace the previous build with the current one. But same warning applies here too (as jpoiret is also typing): if the derivation didn't change, you might have wrong expectations about anything else changing.
<jpoiret>g_bor: needing to run `hash guix` is because shells often cache executable locations.
<nckx>g_bor: It's a permanent ‘suggestions [that don't make your eyes bleed] welcome’. ☺
<nckx>Technically, there is nothing stopping us from installing a custom PROMPT_COMMAND that hashes guix each time (assuming that works, I haven't actually tried it).
<g_bor>so, basically what is needed is something that ensures we have the directory set up...
<abcdw>g_bor: No problem =) I didn't want to depend on elogind and XDG_RUNTIME_DIR, but shepherd, dbus doesn't work well without it, so I decided it would be a reasonable requirement for Guix Home.
<abcdw>g_bor: Yes, basically it's just a directory, which appears on first login and dissapears after complete logout.
<nckx>Hm, I'm weary to pull without authentication…
<g_bor>abcdw: can we extend the installer to give an easy elogind install, like it is offered for let's say ssh?
<g_bor>That would basically make this easier to get over this
<g_bor>I can send a patch to that effect, if you think this is a good idea
<abcdw>g_bor: Theoretically yes, but I don't use the installer and not aware of its capabilities, so better to ask someone, who is more into the topic of installer. Overall, the patch and a brief rationale looks like a good idea.
<g_bor>abcdw: ok, I will try to roll something out and send it for discussion
<rekado_>re cgroups and the Hurd: the Hurd is flexible enough to allow for a cgroups-like feature (at least the parts that shepherd would need). Adding cgroups support to shepherd would not be blocked because the Hurd has no cgroups.
<KarlJoad>rekado_: Why would cgroup in shepherd not be blocked by Hurd not supporting them?
<jpoiret>abcdw: if all you need elogind for is to create XDG_RUNTIME_DIR, then I'm not sure it's a hard requirement
<jpoiret>dbus should work ok, although polkit less so (but there might be ways to circumvent that, and they might already exist)
<jpoiret>mothacehe: i hope i'm not spamming the dump service too much. I'm pretty much done with the selective dump page, although it looks pretty ugly
<taxuswc>Hello! Sorry for a newbie question. I have guix installed on the top of a foreign distro. What is the proper way to make udev rules a from a package installed via guix (it's udisks) accessible to the host udev? It looks like udev looks into /etc/udev/rules.d and /usr/lib/udev/.. for its rules only..
<jpoiret>taxuswc: there's no proper way to do that
<jpoiret>one would be to symlink the ones in the packages you want into /etc/udev/rules.d
<jpoiret>but there are many tradeoffs here: if you symlink directly from the store, you'll have to manually update the symlink whenever you update the relevent package
<taxuswc>well, I thought about that, but with the new version of a package the symlink has to be recreated, which looks a bit inconvenient
<mothacehe>jpoiret: the more data we can get the better I think. Regarding the uglyness not a lot of people are supposed to see that page :p
<jpoiret>you could also symlink ~/.guix-profile/etc/udev/rules.d/, that would get updated along with packages, but that's not very good security-wise
<mothacehe>jpoiret: I had a couple of installer hard failure on real hw recently: no backtraces. Probably a segfault in guile-parted.
<taxuswc>I know, unfortunately guixsd is not an option for me currently :( (need some forbidden stuff for host repos) ..
<taxuswc>jpoiret: what are the security issues with symlinking the dir in the profile?
<jpoiret>maybe you could install the udev rules through your distro's package manager
<taxuswc>yeah, that's my current solution, I thought there is a better way but apparently no
<jpoiret>well, the .guix-profile symlink is controlled by your user, so you (or any program that runs as you) could modify it at anytime to introduce rogue udev rules. Remember that udev rules run as root, and now you've got a privilege-escalation :)
<mothacehe>jpoiret: great! the only way to upload that hypothetic coredump would be to check on the installer start if a coredump is already there and propose to upload it
<taxuswc>it's a personal laptop, so probably that's not a very severe issue )
<jpoiret>the way I structured the new dump code would probably lead to good reuse on that point
<jpoiret>I don't think it would be more than 15 lines
<mothacehe>yeah we can discuss it later, uploading the Guile backtrace should cover most crashes.
<abcdw>jpoiret: Probably, elogind isn't a hard requirement, but Shepherd creates a socket in XDG_RUNTIME_DIR by default, also default (or mostly widespread and expected) path for dbus socket is XDG_RUNTIME_DIR/bus, some other apps also like to use /run/user/1000. It seems like an OK idea for Guix Home to rely on presence of elogind.
<jpoiret>you only need XDG_RUNTIME_DIR though, not elogind
<jpoiret>i bring that up because a surprising amount of people have expressed their wish of running an elogind-less system here
<taxuswc>hmm I don't have elogind too, but the pam works fine (but it is from a foreign distro anyway)
<abcdw>jpoiret, gnoo, taxuswc: pam_rundir should work fine for Guix Home as well as elogind, systemd and whatever else. Can't say about all the apps, which are wrapped into home services or will be wrapped in the future.
<gnoo>shepherd does not require xdg_runtime_dir as far as i can tell
<gnoo>and well, can't you just use /tmp if it is unset???
<podiki[m]>apteryx: or maybe some env variable? like when you get garbage when TERM isn't set correctly
<podiki[m]>or wait, there was talk about tree update to 2, maybe something there needs to be set?
<mfg>did guix output get new colors? it seems more colorful then i remebered :D nice!
<podiki[m]>apteryx: rolling back tree to 1.8.0 fixes password-store build; besides just version and hash had to change back "PREFIX" to "prefix" in make-flags; I think it was noted here the other day that most other distros have not updated tree yet
<apteryx>it's probably something that changed in the unicode output of tree 2, as just this test fails
<vagrantc>nckx: it's when i'm reading an irc channel, and think about switching to another channel and type the command to switch to that channel, and then finish reading and forget i already typed the command to switch to another irc channel
<jonsger>hm, icedove on sway (wayland) freezes now pretty often. I think it was fine on Gnome (Xorg) which I used until two or three weeks ago. Do others have similar problems?
<florhizome[m]><jgart> "not sure if the license allows..." <- the Problem is more that they have different licenses i think
<Guest85>For some reason I cannot get my customized keyboard layout to be applied in xorg, though it works in a tty. I had it working just fine yesterday and the only thing I have changed in my config is installing more packages into the system profile. Has anyone dealt with something similar? Here is my configuration: https://dpaste.org/093p
<florhizome[m]><jonsger> "hm, icedove on sway (wayland..." <- do you use icedove–wayland or set the environmental variable for Mozilla wayland stuff?