IRC channel logs


back to list of logs

<lechner>Kolev / go for it! i came from Debian
<KE0VVT>Installing. Wish I had a server.
<sneek>KE0VVT, you have 1 message!
<sneek>KE0VVT, jpoiret says: Thanks to the core file you sent me, the segfault should now be fixed on master!
<KE0VVT>jpoiret: oh wow!
<KE0VVT>Installing on spare disk right now. :)
<KE0VVT>Dual booting Guix and Foreign Distro is going to be hard.
<KE0VVT>Does the GNOME install use Wayland?
<KE0VVT>Man, I'm so spoiled by Foreign Distro.
<chipb>why not stay with foreign distro then?
<KE0VVT>chipb: I am. I'm keeping Guix on a spare disk to play around
<lechner>KE0VVT / only with (wayland? #t)
<KE0VVT>Damn. OK.
<lechner>link is coming
<vagrantc>KE0VVT: presuming you're using grub and it's not a wildly different grub build, you could put an entry to load the grub.cfg from guix on your foreign distro's grub. not sure it is supported the other way around, unfortunately.
<vagrantc>but in theory it wouldn't be difficult to add support to arbitrary menu entires
<vagrantc>configfile (hd0,0)/path/to/grub.cfg ... or something like that
<KE0VVT>I'm manually swapping the disk
<KE0VVT>The issue is keeping my data between the two systems synced
<vagrantc>but both disks are installed at the same time?
<lechner>KE0VVT / something like this
<KE0VVT>No. I take my main disk out and shove the Guix disk in
<lechner>that'll get old pretty fast
<lechner>what are you using now?
<vagrantc>KE0VVT: yup, sounds like a hard way to dual boot :)
<KE0VVT>I really wish i could have just put guix in a vm but my x200 cant do it
<KE0VVT>lechner: Fedora
<KE0VVT>[Installs Guix.] - Mom: "Damn, what's your computer doing?"
<hab25[m]>I want to be notified when [Guix Home's stateful data
<hab25[m]> management](
<hab25[m]>n%20experimental%20stage%2C%20though.) becomes non-experimental. How can I best achieve this?
<advanced>this is absolute spyware, get rid of it... go look at the source code, it monitors literally everything you do on your computer AND phones home to a remote server over unencrypted HTTP.
<lechner>KE0VVT / I am not sure Guix plays nice with dual boot. Unlike the popular distros, our boot entries are hard to reconstruct by hand. I would recommend to experiment with the Guix package manager on Fedora instead. There is no point to go through the headache of a system configuration right now. You can always switch later
<KE0VVT>lechner: Guix does not sandbox like Flatpak
<lechner>KE0VVT / i thought it is totally separate. vagrantc?
<rekado>you can use “guix system” on Fedora; if you want the Guix System experience but cannot launch a VM on your laptop I recommend a system container.
<rekado>here’s an example:
<KE0VVT>rekado: Guix container. Awesome.
<apteryx>rekado: I just had some idea for node 129: we should reinstall using the 10 TiB SAN slice as its main file system
<apteryx>then we'll be able to test our progress on the multipath thing
<advanced>re: my last message. logs everything you do on your computer, even reads your emails, and shares it all freely over dbus.... & file transfer and IM conversations transmitted over unencrypted HTTP
<apteryx>why is there 2 processes for guix-daemon on a guix system?
<KE0VVT>Cannot get past boot screen.
<lechner>this is on the second disk, or in a container?
<KE0VVT>Second disk
<lechner>you see the grub screen?
<KE0VVT>Oh.... Invisible second password prompt....
<jtmoulia[m]>hello! I've been curious: is it possible to use guix to bundle a group of dependencies into a standalone application which can be run on a different system? For example, I'd like to bundle Emacs along with my config and Emacs-related packages such that I could run it on a different linux distro without a guix foreign install.
<Michal_Atlas[m]>Yes, guix pack, tested it on our school computers a few days back, mind you though the tarball for git for example was surprisingly large.
<Michal_Atlas[m]>It doesn't directly create an application but basically packages a bunch of store items in a tarball, but there's ways to make it more convenient to use afterwards, but for that the manual will probably explain it better
<jtmoulia[m]>Michal_Atlas: perfect! will dig in, much thanks
<lechner>jtmoulia[m] / Another alternative might be to install the Guix package manager on the foreign host system. Your package definition would then be built locally, and you can provide substitutes
<TylerWolf[m]>does anyone know if anyone is packaging jellyfin for guix?
<KE0VVT>If it's not packaged, I'll run it in Podman.
<TylerWolf[m]>KE0VVT: great! i’ll take a look.
<Kolev>TylerWolf[m]: This is KE0VVT. Is there a Jellyfin package or do I need to use containers?
<the_tubular>KE0VVT you are able to run podman fine on guix ?
<Kolev>the_tubular: I have not tried yet. Why?
<the_tubular>Last time I've tried, package was broken and you couldn't port forward to your host
<Kolev>I need Podman to run The Lounge and Jellyfin
<Kolev>Staying on cozy Fedora.
<the_tubular>Docker works fine though
<Kolev>Grrr ok
<the_tubular>Podman needs too much systemd stuff too ...
<Kolev>the_tubular: Hm...
<oriansj>does anyone have a working iwd configuration?
<oriansj>because it is starting to look like I'll have to manually create a herd service for iwd so that iwctl will work and possibly install the d-bus service
<oriansj>I wish I knew this earlier so that I wouldn't have to awkwardly figure it out while connected to a wired network
<lechner>oriansj / how about connman?
<oriansj>lechner: a bit bloated but a valid option
<lechner>oriansj / sorry, just trying to get you off the wallplut
<oriansj>well even installing connman will still end up requiring a guix system reconfigure
<oriansj>and I can manually start iwd and figure out the creating of a proper service later
<oriansj>(once I get d-bus service working by the looks of it)
<bdju>is there documentation anywhere on making your own custom Guix System ISO with desired programs installed? and can you easily include configs as well, such as for your text editor or shell?
<wdkrnls>bdju: look at the `guix system` command.
<wdkrnls>Section 3.9 of the manual gives an example of how you can create an installation image.
<bdju>thank you
<rekado>apteryx: it’s a good idea to use the SAN!
<unmatched-paren>KE0VVT: The GNOME setup is X by default, but you can configure it to use Wayland quite easily
<unmatched-paren>sneek: later tell advanced: looks like zeitgeist has no dependents, fortunately. maybe you could make a post asking whether it should be removed?
<sneek>Will do.
<unmatched-paren>sneek: botsnack
<unmatched-paren>AERC IS IN WOOOO :D
<unwox>unmatched-paren: congrats :)
<yarl>Hello guix
<projectmoon[m]>hi, i think i am running into this:
<yarl>Where is the filesystem when you run `guix system container`? Is it in RAM? I am trying nginx+php-fpm+mariadb service. To keep the state I `--share` mariadb and php files. Thhe problem is that when I share, things are significantly slower.
<projectmoon[m]>i am using guix on gentoo and trying to just build 1 package... currently i am doing guix pull, but it fails build openssl due to a test failure
<projectmoon[m]>is there a workaround for this?
<unmatched-paren>yarl: the filesystem is real, but it's being "overlaid" with a container, i think?
<unmatched-paren>to hide and move filesystem items
<rekado>the rust builds on kreuzberg timed out. Restarting them with ludicrously large timeouts
<projectmoon[m]>specifically i am getting a failure on ../test/recipes/80-test_ssl_new.t
<rekado>projectmoon[m]: how does it fail?
<rekado>projectmoon[m]: are you not using substitutes on purpose?
<rekado>(I’m guessing that this is intentional, since you’re using gentoo)
<unmatched-paren>projectmoon[m]: this has been reported before; the problem is that openssl's tests contain a time-bomb
<projectmoon[m]>Not specifically, no. I can turn them on, but I'd assume it should work without
<projectmoon[m]>Let me try turning them on
<rekado>yarl: I think it is in /tmp; you might be able to set TMPDIR to some disk-backed location.
<rekado>projectmoon[m]: yes, it should work without, but some certificate tests are sensitive to the current year and will fail too far into the future.
<unmatched-paren>rekado: i suppose the time-bomb is removed on core-updates or something?
<yarl>rekado: nothing in /tmp while a container is running.
<yarl>rekado: (nothing relevant)
<nckx>projectmoon[m]: If you don't want to trust substitute servers, one real work-around too silly not to share is to literally set your system clock back to whenever that openssl was released before you build it.
<sneek>Welcome back nckx, you have 1 message!
<sneek>nckx, unmatched-paren says: could you please merge my gtkd fix patch when it arrives?
<projectmoon[m]>rekado: turning on binary substitution makes it run much better so far
<nckx>If it's good!
<projectmoon[m]>nckx: yes, i could do that... or i could turn on substitution
<unmatched-paren>nckx: thanks :)
<projectmoon[m]>was able to install the hello package... now will try to do guix pull
<projectmoon[m]>but if the substitute is built, then how is that actually being built? o_O
<projectmoon[m]>assuming subsitutes are created by using guix... which runs the tests, which fail
<unmatched-paren>projectmoon[m]: the substitute was built on the server before the certificate in the tests stopped working
<projectmoon[m]>i see
<unmatched-paren>projectmoon[m]: problem is we can't modify openssl at the moment because that would cause rebuilds of everything depending on it
<projectmoon[m]>too many rebuilds?
<unmatched-paren>so we have to do that on the ``core-updates'' branch, which contains commits that cause tons of rebuilds
<projectmoon[m]>and not enough computers to build them on i guess
<yarl>What can I use to "style" or "format" guile scripts in the store so It's more readable?
<unmatched-paren>we do have pretty powerful substitute servers but it would take too long to rebuild them, so everyone would be left without substitutes for a while
<unmatched-paren>yarl: i suppose you could use guix style -f file.scm
<unmatched-paren>but that modifies the file in place, so you'd have to copy it out of the store
<yarl>unmatched-paren: oh great this is perfect, thank you!
<projectmoon[m]>unmatched-paren rekado i was able to do guix pull now
<unmatched-paren>yay! :)
<projectmoon[m]>when using guix as "just a package manager," you can still declare a scheme file somewhere to define your guix environment/list of packages, right?
<unmatched-paren>or use guix home...
<rekado>yarl: in Emacs you can use M-x pp-buffer
<unmatched-paren>guix home works on foreign distros
<projectmoon[m]>unmatched-paren i see. last time i used guix, i don't think guix home was ready yet. is this the recommended way for foreign distros?
<unmatched-paren>projectmoon[m]: i use it regularly, but it's not exactly the recommended way, just another way to do it
<yarl>rekado: Thank you bug the result is ugly!
<projectmoon[m]>ok. what's the other way?
<unmatched-paren>projectmoon[m]: manifests or the CLI
<projectmoon[m]>mm yes
<projectmoon[m]>guix home looks to be what i would want
<projectmoon[m]>will try it out later, thanks
<unmatched-paren>here's a manifest:
<unmatched-paren>equivalent command line invocation:
<unmatched-paren>and my guix home config:
<projectmoon[m]>i am not even sure what i will install with guix yet
<projectmoon[m]>but this will be helpful
<unmatched-paren>agh, zoxide fails to build now. i guess a rust dependency has been updated...
<unmatched-paren>ACTION goes to update it
<florhizome[m]>What's a base distro that plays nice with guix home?
<florhizome[m]>A foreign system.
<florhizome[m]>I want one "more stable", relatively well User distro to become comfortable with that i can recommend to not-so-much geeks
<civodul>Hello Guix!
<sneek>civodul, you have 2 messages!
<sneek>civodul, zamfofex says: Do you know if it is possible that ‘ld’ is trying to link against the native glibc as opposed the the cross‐built glibc when cross‐building libstdc++, and that it happens to work “by accident” on glibc 2.33 (but not on 2.35) because it’s shared and the symbols just happen to line up right? The target architectures are “compatible” on the CPU level (i586, x86‐64).
<sneek>civodul, zamfofex says: Note that ‘libpthread’ does contain the symbol ‘pthread_create’ on host glibc 2.33, but ‘libc’ doesn’t on cross‐built glibc 2.35 — it only has ‘__pthread_create’, so it doesn’t seem unlikely to me. I’d have to check whether ‘libc’ contains ‘pthread_create’ on host glibc 2.35, and if it does, that would seem like a sensible conclusion.
<zamfofex>sneek: botsnack
<zamfofex>Note that it has been a few days, and I concluded that my theory might not make much sense. It is more likely that it is using the native glibc *headers* when compiling libstdc++, and the trying to link against the cross‐built glibc and failing then.
<yarl>Hello civodul, can you tell me where is stored the root filesystem when you run `guix system container`, please?
<yarl>Or where to look in the sources?
<yarl>I am trying to understand why when you use --share its significantly slower.
<yarl>My guess is that it is in RAM and --share bind mounts (so, disk folders) and that is why those folders are significantly slower.
<civodul>yarl: hi! yes, the root file system is essentially empty, containing only bind-mounts
<civodul>so i don't see why using --share would make it slower
<yarl>civodul: Hmmm. I am trying to configure a service using nginx+php-fpm+mariadb. I am testing it inside a `guix system container`. The (php) application needs one to run some 'install.php' to create and populate the database and modify some of the php files. When I `sudo /gnu/store/XXXrun-container` I have no problem. But If I want to keep the state, so I can stop the container an launch it again later, by --share mar
<yarl>iadb data and php folder, the install.php is long then I end up with a "504 gateway timeout". There is another indication that it is slower : the service I declare copy-recursively and chown the php folder outside the store (say "/srv/http/app"). This step seems slower with --share than without.
<yarl>civodul: I suppose that without --share, the php folder is copied to RAM. Is it?
<rekado>good news: grunewald is alive again
<cbaines>what's up with the latest commits on the master branch, things are being changed, reverted, then changed again
<rekado>cbaines: weird!
<rekado>reverts should always have an explanation in the commit message
<rekado>and undoing a revert should also come with its own explanation
<rekado>confusing: Andrew Tropin reverted but signed off the following reverts of the reverts
<unmatched-paren>abcdw: what's up with those reverts of the swayr patchset? :)
<rekado>this should be discussed on the mailing list (or here if it’s really urgent) instead of having this back and forth play out in the repository
<jonsger>asking for a friend: does "This reverts commit HASH" count as explanation?
<projectmoon[m]>is there also a place i can easily find the builds that guix uses? like the build scripts/definitions? I assume they are written in shceme
<unmatched-paren>projectmoon[m]: or run ``guix edit PKG'' to see it in $VISUAL
<rekado>jonsger: no
<rekado>jonsger: it should answer the question why the commit has been reverted
<projectmoon[m]>seems fairly straight forward... ebuils with more parentheses
<civodul>i guess maintainers should have a discussion with the people involved and the broader community
<unmatched-paren>projectmoon[m]: each package is built in a completely isolated container, so all inputs must be stated
<rekado>projectmoon[m]: this is the surface syntax, the DSL Guix provides. Under the hood this is compiled to build scripts (also Guile) that are executed by the daemon.
<abcdw>unmatched-paren: ^_^
<rekado>it’s probably not a good idea to revert just to change authorship
<abcdw>rekado: Ok, sorry for that
<abcdw>Is there a better way to do so?
<rekado>abcdw: I don’t think so.
<abcdw>rekado: Ok, will try not to confuse Nicolas G with Nicols G next time :)
<rekado>it’s tricky :)
<rekado>projectmoon[m]: if you’re interested in what actually gets run during the build you can build the derivation files and look at the “guile-builder” they reference.
<projectmoon[m]>i might be
<projectmoon[m]>i'm interested in guix because i like the concept, and maybe to fill a void that gentoo's repos/overlays and flatpak don't have
<projectmoon[m]>i kind of also want to deliberately over-engineer a build system for some ebuilds i maintain
<projectmoon[m]>why do it with a 300 line bash script when you can make it more complicated
<rekado>cbaines: thanks again for catching my mistake regarding bayfront vs bordeaux. Saved me a day!
<projectmoon[m]>i just have yet to choose how to over-engineer it
<unmatched-paren>projectmoon[m]: have a look at these papers
<mprodrigues>hello, I'm trying to use a python venv in guix, however when I activate the venv packages that depend on packages other than pure python fail to load. For example I always get the following error "Importing the numpy C-extensions failed". it says the culprit is libz " cannot open shared object file..." however I can find it in my default
<mprodrigues>profile, I also tried to install zlib standalone, and put my  default profile lib/ path in the PATH inside the venv explicitly, but nothing solves the issue.
<unmatched-paren>mprodrigues: you probably want to use guix shell
<civodul>uh, significant drop in coverage reported by "make assert-binaries-available", due to GTK 4 being unavaialble
<civodul>maybe due to recent Rust changes?
<unmatched-paren>civodul: i noticed a rust build failure too...
<unmatched-paren>with zoxide
<mprodrigues>unmatched-paren I do, and it works fine, but I'd like to keep the option of using venv as well if possible
<rekado>mprodrigues: where does the numpy C extension come from? Is this on Guix System or another distro?
<mprodrigues>rekado: it is a guix system
<cbaines>rekado, glad I could help :)
<unmatched-paren>civodul: maybe we should revert those rust changes for now?
<rekado>unmatched-paren: …again?
<unmatched-paren>rekado: they seem to have broken quite a few packages
<unmatched-paren>such as gtk4
<unmatched-paren>and zoxide
<unmatched-paren>ACTION builds gtk to see what exactly is wrong... libavformat starts building?
<civodul>no seriously?
<rekado>we can add variant packages instead
<rekado>keep the originals for gtk4, keep the new ones for swayr
<unmatched-paren>rekado: ah, fair
<rekado>drop the old ones when everything’s been built
<rekado>this stuff must happen on a separate branch
<rekado>this kind of disruption is not okay for the master branch
<unmatched-paren>now it's building gst-plugins-bad
<civodul>so gtk is actually broken, it's not just that build farms are lagging behind?
<unmatched-paren>i don't know yet
<civodul>ACTION tries as well
<unmatched-paren>it did break zoxide though
<civodul>did qa.guix have a chance to test those patches?
<unmatched-paren> <- hm, no idea, it seems like qa removes results of closed issues :(
<civodul>it's super slow
<cbaines>I was having a look too, I think the patches might have been sent too long ago though
<unmatched-paren>civodul: oh, it builds
<unmatched-paren>gtk does, i mean
<rekado>ACTION started a gtk build on berlin
<rekado>rav1e –> ffmpeg –> gtk
<rekado>pankow is alive
<rekado>maybe I’ll bring them to the data centre later today
<civodul>gtk builds fine for me
<rekado>still building libavcodec on berlin
<rekado>finished ffmpeg
<civodul>ACTION a bit depressed by the "there's no debugger" "it's all unsuable" tone of discussions recently
<abcdw>civodul: Having so much people contributing to various guile project it obviously usable ;)
<zamfofex>civodul: I wanted to say: I highly suspect the build failure I encountered has nothing to do with the updates I made to the Hurd packages, and that it’d happen on core-updates as is. I’d love to figure out what causes it, though.
<civodul>well there are certainly issues, i don't deny that
<civodul>but the negativity is, i dunno
<civodul>not good for my mood
<civodul>maybe it's just me getting old and grumpy
<projectmoon[m]>how do i change where guix's build directory is?
<civodul>(or grumpy-averse :-))
<zamfofex>civodul: That is understandable. I feel like it’s important to acknowledge the defects of the things we are passionate about, but it’s also nice when others acknowledge its benefits too.
<oriansj>well it appears installing D-bus wasn't enough and I need to do some configuration to enable iwd to use D-Bus; here is the error I am getting: and here is my configuration:
<zamfofex>projectmoon[m]: I don’t think you can.
<civodul>zamfofex: sorry i didn't catch it; you encountered build failures earlier?
<projectmoon[m]>zamfofex: well that's inconvenient...
<projectmoon[m]>guess i need to up /tmp
<zamfofex>civodul: Yes, see: (I thought you had seen it, given that you responded to it!)
<abcdw>civodul: I think that's more about people giving feedback in non-polite and non-constructive way, I encounter it from time to time and if it goes this way I just try to make a funny statements and get some fun out of it =)
<civodul>zamfofex: oh, sorry! so yes, i guess a lot has changed on core-updates so it could be that other things broke
<civodul>i didn't really follow lately
<zamfofex>I see. Could it be that it’s just compiling libstdc++ against the native glibc headers? It might be true under master too, but since it has a different version of glibc, maybe the issue didn’t manifest.
<abcdw>civodul: There is no perfect software, especially in so large scale. Legacy, demand and many other factors dictates the way it's right now. Negativity won't help to make it better, so try to focus on good things happening around and enjoy the rest of the community.
<civodul>abcdw: i guess you're right, thanks for your support :-)
<zamfofex>civodul: I feel like you and your work on Guile and on Guix have changed people’s lives by being an inspiration. I’m a fan of many things that people dislike or deem useless, but I feel like being part of a community and working towards a common goal is motivating and rewarding, which gives those things reason and motive.
<cbaines>civodul, I'm excited to see those texinfo patches for the Hurd :)
<projectmoon[m]>next issue i'm running into trying to build icecat is the configure phase of its build failing
<projectmoon[m]>%exception #<&invoke-error program: "./mach" arguments: ("configure") exit-status: 127 term-signal: #f stop-signal: #f>
<unmatched-paren>civodul: ^ might this be another casualty of that swayr merge?
<projectmoon[m]>it just says starting phase configure, prints out the configure flags, then dies
<projectmoon[m]>no obvious error or anything like that
<unmatched-paren>127 means command not found
<unmatched-paren>AAAAA why does Every Single rust patchset I write somehow end up with having to update rust-tokio?!
<mbakke>I need to practice writing, is there a topic people would like to read a blog post about?
<projectmoon[m]>is there also a command to clean up unused dependencies in guix?
<projectmoon[m]>or is that handled automatically
<rekado>projectmoon[m]: “guix gc”
<rekado>it will delete whatever thing under /gnu/store is not reachable from a “GC root”, e.g. a profile generation
<rekado>to make it work well you’ll actually have to “release” some packages, though, e.g. by deleting unused profile generations (guix package -d, to delete all but the current generation)
<rekado>“guix gc” can also be told to delete “old” stuff
<rekado>the manual shows this example: guix gc -d 2m -F 10G
<rekado>“this command deletes all the generations of all your profiles that are older than 2 months (except generations that are current), and then proceeds to free space until at least 10 GiB are available”
<projectmoon[m]>i just did guix package -i emacs, then guix remove emacs
<rekado>this creates two new profile generations
<rekado>one with emacs added, and another one with emacs removed
<rekado>but emacs remains in /gnu/store
<rekado>until you delete the profile generation containing emacs and run “guix gc” to delete the thing in /gnu/store
<rekado>this is by design and lets you roll back updates and switch profile generations
<rothari>Hi guys. Is it normal that when I boot the system I get asked the decryption passphrase twice? Once before the GRUB screen and once after it.
<rekado>projectmoon[m]: see “guix package -l” to see how your profile has changed
<rekado>rothari: this is normal
<unmatched-paren>Aaaaaand yay, now I have to update rust-windows-sys and add new versions of all the rust-windows-ARCH packages...
<projectmoon[m]>rekado: ok
<florhizome[m]>It would be great if we could give some flag to guix system reconfigure to clean up profiles by some policy.
<rekado>florhizome[m]: why as part of system reconfigure?
<florhizome[m]>rekado that was just a quick thought, not saying it needs to be only there
<florhizome[m]>because it’s my main interface for maintaining guix I guess and because I think to remove system profiles you need root privileges anyways, do I remember that right?
<minima>i was looking into how to use guix with aws lambdas; i watched the video from the GuixDays event in Feb; is anyone aware of any further development with regard to python-awslambdaric? it looks like that hasn't been upstreamed yet?
<florhizome[m]>Different topic: what are the issues with bundled dependencies?
<florhizome[m]>Declarative ess or reproducibility?
<florhizome[m]>*searches up manual*
<hab25[m]>I want to be notified when [Guix Home's stateful data
<hab25[m]> management](
<hab25[m]>n%20experimental%20stage%2C%20though.) becomes non-experimental. How can I best achieve this?
<unmatched-paren>hab25[m]: eh, it's not really experimental
<unmatched-paren>i replaced ``guix package'' entirely with ``guix home'' ages ago
<hab25[m]>I'm talking specifically about the stateful data management feature
<unmatched-paren>i never saw that feature before
<unmatched-paren>the manual doesn't seem to tell you how to do it though.
<unmatched-paren>i mean, periodically rsyncing can just be done with home-mcron-service-type
<unmatched-paren>and cloning would be possible with home-activation-service-type
<hab25[m]>Good to know, I'll consider those as alternatives.
<hab25[m]>But is there such a notification system for one to be informed of such updates? I'm guessing I could check again if there is a tracking issue in the mailing list and create an email filter for that, but I don't think I'm gonna find one. Is there a better option?
<unmatched-paren>hab25[m]: i'm not sure this is actually a single coherent feature
<unmatched-paren>there is no relevant mention of ``state'', ``stateful'', or ``data'' in the gnu/home directory
<mirai>is it possible to "install" a file with config.scm? I'd like to have 'guix system reconfigure' automatically drop some files under /etc/NetworkManager/system-connections
<unmatched-paren>mirai: yup
<unmatched-paren>with special-files-service-type or etc-service-type
<unmatched-paren>etc-service-type would be more appropriate here since it's in /etc...
<mirai>unmatched-paren: thanks
<hab25[m]>unmatched-paren: Thank you. I'm specifically interested in git cloning/pulling and in managing the dconf database. I'll search specifically for those things, then.
<unmatched-paren>hab25[m]: you'll probably want to use activation-service-type for those things
<unmatched-paren>ACTION wonders if it would be worth writing home-git-clone-service-type and home-dconf-service-type
<florhizome[m]>unmatched-paren: why not use the gsetrings cli directly?
<florhizome[m]>I think it makes sense
<florhizome[m]>Oh i didnt read the comment before. I have never worked with the dconf Database
<florhizome[m]>> <> Different topic: what are the issues with bundled dependencies?
<florhizome[m]>> Declarative ess or reproducibility?
<florhizome[m]>> *searches up manual*
<florhizome[m]>In General, we don't want anything bundled, is that right?
<ph03n1xaimverncc>Heyya howdya create a custom service in config.scm
<unmatched-paren>ph03n1xaim[m]: You need to write a ``service-type'' record.
<unmatched-paren>It has a ``name'' (symbol), ``description'' (string), ``default-value'' (any), and ``extensions'' (list of service extensions)
<ph03n1xaimverncc>What's extensions
<ph03n1xaimverncc>And default values
<unmatched-paren>the way you add functionality to services is by extending *other* services
<unmatched-paren>(service-extension SERVICE VALUE)
<ph03n1xaimverncc>What if I just want to run a binary file/shell script directly
<unmatched-paren>SERVICE is a service-type, VALUE is a lambda that takes the service configuration and returns a value for SERVICE to use
<ph03n1xaimverncc>As a service at boot
<unmatched-paren>ph03n1xaim[m]: Ah, so you probably want to use the ``simple-service'' procedure
<unmatched-paren>which is shorthand for a new service that extends only one other service
<unmatched-paren>(simple-service NAME SERVICE-TYPE VALUE)
<unmatched-paren>I *think* what you want to use might be ``boot-service-type''
<unmatched-paren>Produce the operating system's boot script, which is spawned
<unmatched-paren>by the initrd once the root file system is mounted.
<unmatched-paren>(simple-service 'my-service boot-service-type #~(invoke #$(file-append pkg "/bin/my-program")))
<unmatched-paren>ph03n1xaim[m]: you can run any scheme code inside that #~...
<ph03n1xaimverncc><unmatched-paren> "I *think* what you want to use..." <- Actually I wanted to run rathole as a service
<unmatched-paren>ph03n1xaim[m]: is this a daemon?
<ph03n1xaimverncc>unmatched-paren: Yes, it's used for reverse proxy
<ph03n1xaimverncc>I'm trying to run the client
<unmatched-paren>ah, you will want to write a service-type then
<unmatched-paren>does it run as root or as a user?
<ph03n1xaimverncc>unmatched-paren: It's not available as a package tho
<unmatched-paren>ph03n1xaim[m]: ah, you'll need to package it then
<ph03n1xaimverncc>As root
<ph03n1xaimverncc>unmatched-paren: Was tryna run it from local bin
<unmatched-paren>right, you'll want to add both a system service-type and a package
<unmatched-paren>AAAAAA WHY RUST WHY
<ph03n1xaimverncc>unmatched-paren: How would I do that?
<ph03n1xaimverncc><unmatched-paren> "(simple-service 'my-service boot..." <- To this?
<unmatched-paren>ph03n1xaim[m]: no, that won't work
<unmatched-paren>since you're trying to run it as a daemon
<unmatched-paren>that will do a one-shot thing
<ph03n1xaimverncc>unmatched-paren: Yep
<unmatched-paren>ph03n1xaim[m]: so, you'll want to add this to your config.scm:
<ph03n1xaimverncc>How would I declare the service?
<unmatched-paren>ph03n1xaim[m]: you'll need to write the package first
<unmatched-paren>what build system does it use, and where do you download it?
<unmatched-paren>here's the basic structure:
<unmatched-paren>that ``package'' is a record
<unmatched-paren>now, you'll need to figure out what the latest version is
<unmatched-paren>add that as a ``version'' field after to ``name''
<rekado>pankow and grunewald are now in the data centre
<rekado>I can ping but I cannot ping
<apteryx>rekado: I note that node 130 is still operating a as a cuirass worker:
<ph03n1xaimverncc><unmatched-paren> "what build system does it use..." <- Cargo
<apteryx>we should take it offline until investigations are done and it is operating smoothly again, no?
<ph03n1xaimverncc><unmatched-paren> "what build system does it use..." <-
<rekado>apteryx: I’ll reseat the SSDs and turn on node 129 now
<apteryx>rekado: OK
<rekado>any ideas what’s up with the wireguard thing and how I can debug it?
<apteryx>did you see my idea of reinstalling it using the 10 TiB SAN slice?
<apteryx>would give us a convenient sandbox to experiment
<rekado>yes, I replied here that it’s a good idea
<unmatched-paren>ph03n1xaimverncc: Oh dear.
<unmatched-paren>You'll want to use ``guix import crate rathole'', probably.
<ph03n1xaimverncc>unmatched-paren: Ohhh thanks
<civodul>rekado: thumbs up for pankow/grunewald! are they failing to connect to WireGuard?
<rekado>the wireguard service is running
<unmatched-paren>ph03n1xaimverncc: this will only work if rathole is on
<rekado>but they cannot ping
<rekado>they can talk to the on its private ip though
<unmatched-paren>ph03n1xaimverncc: you'll want to change rust-rathole in the output to just rathole
<unmatched-paren>only rust libraries get the rust- prefix
<ph03n1xaimverncc>unmatched-paren: Ohh
<ph03n1xaimverncc>unmatched-paren: Okay
<rekado>and berlin can see them on their respective IPs
<rekado>but not on wireguard
<rekado>BTW: the data centre is pretty warm. Might not be so good for our aarch64 nodes.
<rekado>ambient temps are high and airflow is not great
<rekado>not ideal conditions for these consumer grade parts
<rekado>apteryx: node 129 looks like it’s powered on. It wasn’t off when I came in.
<mirai>unmatched-paren: this etc-service-type is a list of lists?
<unmatched-paren>mirai: (("FILE-IN-/ETC" ,FILE-LIKE-OBJECT) ...)
<rekado>apteryx: powercycled 129
<apteryx>rekado: yeah it was on but stuck on the boot
<rekado>builder for `/gnu/store/s6l146bms1cxnqk2ja1rai4n7zhcmswd-rust-1.54.0.drv' failed with exit code 1
<apteryx>rekado: seems it's still down. I don't think it'll recover
<rekado>“Unable to run process '/tmp/guix-build-rust-1.54.0.drv-0/rustc-1.54.0-src/vendor/getrandom/output/cargo-build/build_getrandom-0_1_14_H20_run' - No such file or directory”
<mirai>unmatched-paren: it looks like it could be done with an alist instead
<unmatched-paren>mirai: oh, really? how? :)
<rekado>apteryx: still during system init
<rekado>Lifecycle Controller: Collecting System Inventory...
<rekado>it’s a scheduled task
<rekado>booting now
<mirai>unmatched-paren: is it not? the value to the service is (list `("issue" ,(plain-file "issue" "Welcome!\n")))
<rekado>bunch of errors corrected, but it didn’t wait and just marched on with booting
<rekado>so now the shepherd services have failed
<unmatched-paren>mirai: that's not an alist :)
<unmatched-paren>an alist is (list `(foo . bar))
<unmatched-paren>sorry, `((foo . bar))
<unmatched-paren>this is `((foo bar))
<rekado>apteryx: I’ll reset it
<apteryx>rekado: yes, so same
<apteryx>the guix db is corrupted at least
<apteryx>civodul: when you have a chance I'd like your input on (i.e. renaming the "location" accessor to something less conflict-prone)
<rekado>do you want to init on the 10TB SAN then?
<apteryx>yes, I think we should proceed with that
<rekado>can I do something else while I’m here?
<apteryx>perhaps pull out these small SSDs, they won't be needed anymore
<apteryx>we'll be using SAN + large SSDs for nar backup
<apteryx>(with the root file system being on SAN)
<mirai>unmatched-paren: yes, it's not an alist, that's what guix currently uses
<mirai>the etc service I mean
<apteryx>rekado: we'll want to double check the /dev/sdd one (4th slot?) it may be dying
<mirai>but wouldn't it be better if it were an alist though?
<rekado>apteryx: I removed the small SSDs and moved the big ones down to the more stable slots
<unmatched-paren>mirai: it's an extra . to write -.o.-
<rekado>(the upper slots are not great without an adapter from 3->2.5")
<rekado>server is powering up
<rekado>it’s all yours
<apteryx>rekado: thanks! I'll try to find time to re-init the thing
<ph03n1xaimverncc><unmatched-paren> "(simple-service 'my-service boot..." <- How do I pass arguments to it?
<apteryx>perhaps later this well
<unmatched-paren>does anyone know why there's a strange cascade of ``unbound variable'' errors when you miss out some fields of a record?
<ph03n1xaimverncc>ph03n1xaimverncc: Like my-program -s path/to/rathole.scm
<ph03n1xaimverncc>* Like my-program -s path/to/rathole.toml
<unmatched-paren>ph03n1xaimverncc: add strings to the invoke call's arguments
<unmatched-paren>ph03n1xaimverncc: no, that won't work
<unmatched-paren>you need to write a shepherd service
<unmatched-paren>and a package...
<ph03n1xaimverncc>unmatched-paren: I got the package from guix import
<unmatched-paren>ph03n1xaimverncc: okay, you need to put the package define in the config.scm
<unmatched-paren>and then you can write something like this:
<ph03n1xaimverncc>unmatched-paren: So simple-service won't work?
<unmatched-paren>ph03n1xaimverncc: nope
<unmatched-paren>because this service is not simple :)
<unmatched-paren> <- here's the basic layout of the service-type
<rekado>unmatched-paren: I’d like it to abort early
<unmatched-paren>rekado: ?
<rekado>that cascasde of unbound variable errors
<unmatched-paren>rekado: ah
<rekado>when there’s an unrelated error somewhere else
<ph03n1xaimverncc>unmatched-paren: What's the default value for?
<unmatched-paren>ph03n1xaimverncc: you know the (foo-configuration ...) records that some services accept?
<civodul>rekado: does "ip a" show the wg0 interface?
<unmatched-paren>that's the default value if you don't provide that
<civodul>(IOW, is the shepherd service state consistent with the network interface state?)
<unmatched-paren>since you presumably aren't going to set up any configuration stuff, you can just use '() or something
<rekado>civodul:yes, it shows wg0
<ph03n1xaimverncc>unmatched-paren: Is it the configuration like the ones openssh service accepts?
<rekado>looks the same as on kreuzberg
<rekado>(different IP of course)
<unmatched-paren>ph03n1xaimverncc: yeah
<ph03n1xaimverncc>Since it's custom config do we need that?
<ph03n1xaimverncc>What do I put in default-values then?
<unmatched-paren>it's a mandatory field in the service-type record, but because this is only a service for your own use, you can just configure it by editing the source, so you don't need a -configuration record=
<unmatched-paren>so you can just insert a dummy value like '() in
<ph03n1xaimverncc><ph03n1xaimverncc> "Like my-program -s path/to/..." <- Like all I want is:
<ph03n1xaimverncc>path/to/rathole -s path/to/rathole.toml
<ph03n1xaimverncc>unmatched-paren: Ahhh
<rekado>…is this wireguard problem an obstacle to using the machines?
<rekado>I guess we could solve this later
<rekado>since they are connected at a different layer
<rekado>offloading, for example, should work
<unmatched-paren>ph03n1xaimverncc: sorry, i'll come back in a moment, i just need to step away for 2 minutes or s;
<ph03n1xaimverncc><unmatched-paren> "" <- In extensions what all should I provide? And where do I store the command?
<ph03n1xaimverncc>unmatched-paren: Cool cool
<apteryx>rekado: wireguard is the main link no? unless the machines have a public IP with their SSH port listening, they won't be reachable
<ph03n1xaimverncc>Do I need this?
<ph03n1xaimverncc>ACTION sent a guile code block:
<ph03n1xaimverncc>Is this to be put in extensions?
<rekado>apteryx: they have IPs that can be reached from berlin
<unmatched-paren>ph03n1xaimverncc: That's close, but not quite.
<unmatched-paren>ph03n1xaimverncc: This is what extensions should look like: (list (service-extension shepherd-root-service-type rathole-shepherd-services))
<rekado>almost forgot to copy the SSH key to the nodes…
<unmatched-paren>ph03n1xaimverncc: and this is what rathole-shepherd-services should look like:
<unmatched-paren>you were close, but it needs to be a procedure
<unmatched-paren>the procedure is fed with the configuration
<unmatched-paren>ph03n1xaimverncc: and *maybe* add #:log-file "/var/log/rathole.log" to the forkexec-constructor
<unmatched-paren>so that the output of the daemon has somewhere to go
<rekado>not sure what’s going on, but pankow isn’t booting
<rekado>it gets stuck at [ 6.609622] fsl_dpaa2_eth dpni.0: Probed interface eth0
<rekado>this worked at home :(
<rekado>guess I’ll have to take this one home again…
<ph03n1xaimverncc><unmatched-paren> "the procedure is fed with the..." <- Ohh
<ph03n1xaimverncc><unmatched-paren> "/ph03n1x/aim ( and this..." <- How do I add this to services tho?
<ph03n1xaimverncc>(service rathole-shepherd-services)
<unmatched-paren>ph03n1xaimverncc: then you just do (service rathole-sservice-type) in your services list in (operating-system) and it should work
<unmatched-paren>ph03n1xaimverncc: wait, actually
<unmatched-paren>here, you need to do this to pass it the config file
<rekado>ACTION leaves
<unmatched-paren>local-file simply grabs a file on your fs, and drops it into /gnu/store
<unmatched-paren>as an output path
<ph03n1xaimverncc><unmatched-paren> "local-file simply grabs a file..." <- Ahh
<unmatched-paren>ph03n1xaimverncc: there are a few other kinds of "file-like objects" (local-file and package are two of them, and what they have in common is that they both have ``gexp-compiler''s defined for them, which are basically procedures which take a record and produce a derivation, which is a set of instructions telling guix how to build an output path)
<unmatched-paren>``origin'' is also a file-like; it produces an output path containing a file or directory downloaded from the internet
<unmatched-paren>there's ``plain-file'', which just dumps some text into the store, ``computed-file'', which accepts a gexp that should create an ``#$output'' file, ``mixed-text-file'' which accepts gexps returning strings and just plain strings and concatenates them all together...
<ph03n1xaimverncc>unmatched-paren: Is this it?... (full message at <>)
<ph03n1xaimverncc>unmatched-paren: Is this it?
<unmatched-paren>ph03n1xaimverncc: it should be ``rathole-service-type'', not ``rahole-shepherd-service-type'', and you wrote ``rathole-service-services'' in the extensions, but other than that and that you probably should add a #:log-file, looks good!
<unmatched-paren>Oh, yeah, the service-type needs a (description ....) field, and the ``shepherd-service'' description field should be called ``documentation'',
<reyman>Hi guixer!
<reyman>I have a little guile question, how do you get the real path of a binary from guile ?
<reyman>for example if i want the real store path of clang ?
<unmatched-paren>reyman: in what context?
<reyman>in a guile script, i need to (setenv "CLANG_BASE_PATH") with correct clang binary path, needed by compilation.
<reyman>is there something like (which "clang") :)
<unmatched-paren>reyman: (guix build utils) provides a ``which'' procedure exactly like that
<unmatched-paren>i don't think guile base does though
<reyman>i hope that return the
<unmatched-paren>reyman: if it doesn't return the /gnu/store path, try ``(realpath (which "clang"))''
<reyman>i try now
<apteryx>is someone successfully using virt-manager with a bridged network interface?
<ph03n1xaimverncc>I think few dependencies of it is missing
<apteryx>I'm getting a "Failed to find a suitable default network" warning on the NIC configuration screen
<unmatched-paren>ph03n1xaimverncc: can you show the package?
<reyman>it's ok, thanks @unmatched-paren
<Kolev>GNOME Software now supports per-user package installations. Surely now we can add support for Guix.
<cbaines>why do you say "surely now" Kolev?
<unmatched-paren>cbaines: i think that might have been what was blocking it
<Kolev>cbaines: The issue with adding Guix support for GNOME Software was that GNOME Software does not support per-user installations.
<unmatched-paren>ph03n1xaimverncc: please use a paste site that doesn't require javascript :)
<Kolev>cbaines: Now, this is not the case.
<cbaines>Kolev, I wasn't aware that was/is an issue. Surely GNOME Software could just assume it's installing software for the current users profile in Guix, it doesn't need to be able to install software for other users.
<Kolev>cbaines: I'm confused. The normal behavior of GNOME Software is to install a package for all users. This does not work in Guix. But now, they've added support for user installations.
<futurile>Q: I see in a lot of tutorials that you can install a package at a particular version (e.g. guix install neovim@0.8.1). But how do I find the versions of a package that are in an archive?
<cbaines>My argument is that this is irrelvent. If GNOME Software could interact with a users profile, that would be fine. It doesn't need to have any concept of "per user" installation.
<ph03n1xaimverncc>unmatched-paren: Oh sorry
<apteryx>sounds like they've made it aware that "hey, this isn't a global system package manager, so you don't need to elevate to root via polkit"
<ph03n1xaimverncc>I shall
<unmatched-paren>futurile: guix show neovim
<futurile>unmatched-paren: that shows the current version, how do I see the other versions that are available in the archive?
<unmatched-paren>futurile: there are none
<unmatched-paren>if it doesn't show any other versions, there are no other versions
<unmatched-paren>example: try ``guix show gtk+''
<unmatched-paren>should show both gtk 3.* and gtk 2.*
<unmatched-paren>(we do have 4.*, but it's called ``gtk'', not ``gtk+'')
<unmatched-paren>guix doesn't have an "archive" of old versions
<cbaines>Kolev, I'd ignore this "per user" thing and instead focus on the lack of a plugin for Guix (or one which integrates with Guix):
<unmatched-paren>if you need an old package version, look for a guix commit that has it, and use ``guix time-machine'' or the inferiors feature to get it
<cbaines>I think that's a much more useful perspective on how GNOME Software could be used with Guix
<Kolev>cbaines: My point is, a plugin for Guix is now more feasible.
<unmatched-paren>ACTION looks at that directory, expecting to see .js everywhere
<unmatched-paren>oh, huh, it's C
<cbaines>Kolev, I disagree, but I don't know the details
<futurile>unmatched-paren: ok, I think I totally don't understand why tutorials make a big deal of being able to install different versions of packages. I thought I'd be able to see a list of all version of a package that had been put into the archive. Missing something :-)
<unmatched-paren>futurile: there is no archive :)
<unmatched-paren>there's a git repo containing the source code, including the packages
<Kolev>cbaines: Plan B is to make a Guix Settings GNOME app, containing all the things that are handled by Guix instead of the regular system configuration tools.
<unmatched-paren>and you can use ``guix time-machine --commit=... -- install PKG''
<ph03n1xaimverncc>Just made an account
<cbaines>I'm not saying GNOME Software support is infeasible, far from it, just that the app having some "per user" feature doesn't make a difference.
<cbaines>I think any Guix plugin would just assume per-user installation, nothing else makes much sense
<unmatched-paren>to run ``guix install'' in an old version of guix
<ph03n1xaimverncc>cbaines: Gnome software ain't available in guix, right?
<unmatched-paren>or, if you want to refer to old packages in Scheme, you can use inferiors
<Kolev>cbaines: I guess, but such a plugin would be a bit hacky.
<cbaines>ph03n1xaimverncc, doesn't look like there's a package for it
<unmatched-paren>i don't think gnome software integration would really work with guix...
<cbaines>unmatched-paren, why?
<unmatched-paren>given that it's not a traditional package manager
<ph03n1xaimverncc>cbaines: Hmmm
<Kolev>unmatched-paren: It's not that non-traditional. Flatpak does per-user installations.
<ph03n1xaimverncc>ph03n1xaimverncc: Any clue on this?
<unmatched-paren>it would technically work, but it'd hide all guix's special features
<Kolev>unmatched-paren: That would be fine, for a user-facing app.
<cbaines>unmatched-paren, you'd probably have problems with a lack of metadata (e.g. app icons), but it would extend Guix's reach to users who don't generally use the command line
<cbaines>which is a good thing
<unmatched-paren>i guess i don't really see much point in using guix over apt or something if you're just using install, remove, pull, and upgrade
<unmatched-paren>i mean, gnome-software wouldn't even be able to rollback, no?
<Kolev>unmatched-paren: As I said, a Plan B could be to make a special Guix app where you can do package management, system management and rollbacks, etc.
<unmatched-paren>Kolev: yes, i personally prefer that idea
<unmatched-paren>and that way, we can write it in Guile and directly hook into Guix APIs
<unmatched-paren>Gnome software would just invalidate what makes guix special, and hide what's actually going on
<cbaines>unmatched-paren, I think Guix is valuable even if you don't use all the functionality
<Kolev>unmatched-paren: Add/remove users, select which services you want added to the system config, add/remove packages, etc.
<unmatched-paren>Kolev: yeah! :)
<Kolev>unmatched-paren: I'm not sure if GNOME apps can be written in Guile yet.
<unmatched-paren>Kolev: there are several binding libraries for GTK
<unmatched-paren>one of them is better and better maintained than the others, but i don't remember which one :)
<unmatched-paren>i think it might be g-golf?
<pkill9>guix still has the benefit of not being borked if the transaction is interrupted
<pkill9>even if you only add/remove
<Kolev>And a "Test This System Config in a VM" option. 😂
<Kolev>unmatched-paren: Can G-Golf use libadwaita and make an actual GNOME app? Not just GTK.
<unmatched-paren>Kolev: G-Golf uses GObject Introspection, that's all I know -.o.-
<unmatched-paren>I have no idea whether libadwaita uses GI, but I suspect it does?
<old>I have a main library in a package that is used by sub-libraries in the same packages. These sub-libraries are currently linked with `-Wl,-rpath=$(shell $(pwd))` in the Makefile for testing. I want to install these sub-libraries along with the main library. How does one do that usually?
<old>I get a `phase `validate-runpath' failed`
<old> error: depends on '', which cannot be found in RUNPATH
<pkill9>oh yeah, another benefit could be running the application without installing it
<unmatched-paren>old: probably just replace that $(shell $(pwd)) with #$output/lib
<Kolev>pkill9: "Test-drive application" button.
<unmatched-paren>pkill9: but gnome software wouldn't be able to operate guix shell, would it?
<Kolev>Hm. Maybe there should be just a Guix Settings app.
<old>unmatched-paren: So I have to do a substitute on the Makefile?
<Kolev>It looks like GNOME Settings, but it has all Guix-related settings instead.
<unmatched-paren>old: yeah
<old>And how does autotools handle this usually?
<old>There's no such substitution to my knowledge
<unmatched-paren>old: probably adding -Wl,-rpath=$LIBDIR
<unmatched-paren>though you probably should add both
<old>okay I will try that
<unmatched-paren>i think?
<pkill9>Kolev: what kinda settings?
<pkill9>i was thinking a patched gnome settings, ubuntu does this and allows to add custom settings entries using .desktop files
<pkill9>but thats separate
<pkill9>idk the best way of doing something like adding users
<pkill9>the gnome settings will only add users twmporarily due to guix managing that
<reyman>hum, given a realpath or which command, how do you get the base path ?
<unmatched-paren>pkill9: that'd probably just be modifying the user list in /etc/config.scm...
<unmatched-paren>reyman: as in, /foo/bar -> bar?
<reyman>i have "/gnu/store/0wrp34pb4hrd1vvs7hm4aylx11bipyi9-clang-toolchain-13.0.1/bin/clang" and i'm trying to get "/gnu/store/0wrp34pb4hrd1vvs7hm4aylx11bipyi9-clang-toolchain-13.0.1/"
<unmatched-paren>reyman: ah
<unmatched-paren>(dirname (dirname "..."))
<reyman>uh ok, need a guile dictionary to found all this util function
<old>unmatched-paren: Awesome it works thanks!
<Kolev>pkill9: Guix Settings would probably have to give a notice after adding users, saying, "Settings will not take effect until you reboot or reconfigure the system. Would you like to reconfigure now? This may make you lose work."
<rekado>I’m a little confused with how offloading works
<rekado>on berlin it doesn’t seem to honor the settings in /etc/machines.scm; same for /etc/guix/machines.scm
<rekado>is it looking for another file…?
<Kolev>Actually, a system reconfigure may as well be a reboot for normal users. Just say you have to reboot.
<unmatched-paren>Kolev: many system reconfigure changes don't require reboots...
<jorge[m]1>Hello, who can help me pack, please.
<Kolev>unmatched-paren: But the effect on the running system is like a reboot. Your desktop won't keep running.
<unmatched-paren>ACTION away
<unmatched-paren>Kolev: Yeah it will, unless you ``herd restart blahblah''...
<ph03n1xaimverncc>Is this not possible to install?
<ph03n1xaimverncc>I'll probably run the binary file directly if it doesn't help
<unmatched-paren>ACTION actually not away, never mind -.o.-
<unmatched-paren>ph03n1xaimverncc: if you want to install it you could add it to your operating-system packages
<ph03n1xaimverncc>I tried
<unmatched-paren>does it fail to build?
<unmatched-paren>what's the error?
<ph03n1xaimverncc>The rust-http-proxy-1 doesn't exist
<ph03n1xaimverncc>I'm guessing, it's a missing package?
<unmatched-paren>yeah, you'll need to ``guix import crate http-proxy''
<civodul>ACTION posted draft release notes
<civodul>to guix-artwork.git
<unmatched-paren>civodul: \o/ might i also suggest the addition of the erlang build system?
<unmatched-paren>ah, that's what it was called; rebar-build-system
<civodul>unmatched-paren: sure!
<civodul>still a lot of work to do as you can see
<civodul>it's gonna be a 10MB Markdown file :-)
<podiki[m]>civodul: exciting stuff! so many nice changes since 1.3.0
<civodul>yup! and i'm grateful mothacehe & apteryx worked on the NEWS file before!
<unmatched-paren>civodul: maybe also mention the change from `(...) arguments to (list ...) with gexps
<rekado>weird: pankow boots fine here at home
<rekado>but it got stuck in the data centre
<rekado>I wonder if it’s related to temperature
<Kolev>Icons don't update in GNOME when you install an application.
<unmatched-paren>civodul: so, is the one-year gap between 1.3.0 and 1.4.0 unusual? "but let’s face it, it also shows an area where we can andshould collectively improve our processes"
<unmatched-paren>I wasn't here for the 1.3.0 release :)
<civodul>heh, see? :-)
<unmatched-paren>ACTION is sure there must be more major additions to mention but can't think of any off the top of their head...
<unmatched-paren>civodul: how about greetd and the lightdm-service-type?
<johnabs[m]>Hi all, just one quick question. How can I set my default gtk theme similar to using lxappearance? I've checked the manual and tried following a few threads, but no luck yet, unfortunately :/ I just want to use the nordic theme. I tried using lxappearance, and made the theme visible via a symlink to the gnu store, but it completely killed X and my window manager, then froze my machine so I had to reboot 😅
<attila_lendvai>i'm trying to fix gpaste, and trying to use gdb to get a backtrace, but the sigsegv happens in a thread, and gdb says "warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available." any hints how to proceed?
<attila_lendvai>for enterprising souls: the symptom is that `gpaste-client --version` sigsegv's
<attila_lendvai>there's an (unanswered) question on guix-help:
<podiki[m]>johnabs: weird. I use lxappearance (as well as setting various .gtk config files, see e.g. Arch manual) without issues
<podiki[m]>though I think I have a symlink in a user folder to probably a profile where I installed themes (not at that computer currently but can check later)
<johnabs[m]>podiki[m]: Hmm, I'll try again shortly. If you don't mind, could you try out the nordic-theme? It could be a bug there that caused my issue, perhaps.
<podiki[m]>maybe ~/.themes linked to ~/.guix-profile/share/themes or something like that?
<johnabs[m]>Yeah, that's what I did to make it show up in lxappearnace in the first place
<johnabs[m]>As it is missing after installation
<apteryx>rekado: it's suppose to honor /etc/guix/machines.scm on berlin, which is a special file corresponding to our versioned copy
<podiki[m]>I vaguely remember something about that, and why the usual xdg_data_dirs doesn't pick it up. but anyway, that's a more general lxappearance issue I believe
<podiki[m]>I can try out nord when I'm at my other computer, sure
<podiki[m]>you might try other themes to compare, I use orchis for example
<johnabs[m]>podiki[m]: Okay, will do! I'm writing a manuscript currently, but I'll report back once I take a break and try it. Thanks for being willing to try out the nordic theme on my behalf, I really appreciate it! :)
<podiki[m]>no prob, I'll let you know when I get a chance
<podiki[m]>also, what WM or DE are you using?
<rekado>apteryx: I unlinked /etc/guix/machines.scm and put a new file in its place where I commented kreuzberg and enabled grunewald, but it still seems to want to offload to kreuzberg
<johnabs[m]><podiki[m]> "also, what WM or DE are you..." <- Oh, I'm using xmonad, and I think that's it. I'm not sure what I'm using when logging in, I think it is whatever Guix System uses as the default.
<apteryx>rekado: 'strace -e file' may be useful, I don't know
<podiki[m]>johnabs: ok! (was also on xmonad recently but went back to stumpwm because I miss the lisp)
<johnabs[m]>podiki[m]: Oh I want stumpwm because I love lisp too! I just need my dynamic tiling layouts though. That's one thing I just can't get used to with it, or I would switch in a heartbeat. 😭
<podiki[m]>they did add dynamic groups, but I haven't tried it out much!
<johnabs[m]>I tried it recently, it's still a bit too clunky, as you have to manually add the windows to said groups, IIRC
<johnabs[m]>Whereas with xmonad, st, etc. the groups are spawned "automagically" into their tiling groups depending on the workspace
<podiki[m]>ah. I think you can create a dynamic grouping workspace so that all windows there do that by default, but I still need to learn about them (note that the website manual is out of date)
<podiki[m]>gnew-dynamic (but anyway, I'll not get further off topic, thanks for reminding me to play with it more)
<apteryx>which package provides lsattr?
<apteryx>ah. and that's not installed anymore if I don't use ext*
<nckx>Good point.
<apteryx>should we add this package back in the static list of utilities shipped in the base?
<nckx>ACTION nods.
<the_tubular>Isn't it in %base-file-systems ?
<nckx>Are you thinking of a different variable?
<the_tubular>No, it would make sense for e2fsprogs to be in %base-file-systems no ?
<nckx>That's a list of file systems.
<the_tubular>Ohh ...
<apteryx>ACTION looks at %base-packages-disk-utilities, and is confused, there's a lot of fs-specific tools there?
<apteryx>I thought this had been cleaned up already
<nckx>That's the variable I thought the_tubular might mean (although I didn't know the name by heart).
<apteryx>hence the lack of e2fsprogs
<nckx>I'm not sure what you mean.
<nckx>If you're arguing for %base-packages-disk-utilities to be added by default, no, I think that's (far :) too far.
<nckx>e2fsprogs has some grand-fathered in ‘universal’ tools like lsattr, the rest not so much.
<apteryx>ah, %base-packages-disk-utilities is only part of the install image, right?
<nckx>Ah. Yes.
<apteryx>OK, I got confused there.
<nckx>It's the ‘here's all the stuff you might need maybe’ variable.
<nckx>Ideally it would be renamed so you're the last person to wonder, but that might be considered churn.
<nckx>The %base-packages- prefix *is* confusing.
<apteryx>that's not for the base install images, that'd be (gnu system install)
<apteryx>so these utils really end up in any OS template taht doesn't override its 'package' field.
<apteryx>which is silly
<nckx>ACTION doesn't understand ‘that's not for the base install images, that'd be (gnu system install)’.
<apteryx>I meant image* singular :-)
<apteryx>the one we use to install Guix System, the installer
<nckx>That's the only place %base-packages-disk-utilities is ever used.
<nckx>How does that affect OS templates?
<apteryx>the default value of the package fields defaults to %base-packages, which is made of many things, including %base-packages-disk-utilities
<apteryx>ah, you're right there's no the *disk* utils. "Just" %base-packages-artwork, %base-packages-interactive, %base-packages-linux, %base-packages-networking and %base-packages-utils
<apteryx>I guess it was dropped from that place
<apteryx>hm, git log says no
<nckx>‘It's confusingly named’ hypothesis: confirmed.
<darosior>Hello, is there a way to enable substitutes on per-command basis? I'm running guix-daemon with --no-subsitutes and it sometimes happen i just want to be dropped into a shell without bootstrapping every single package myself. So i was wondering if i could just do something akin to `guix shell --with-substitutes` or if i need to restart my
<darosior>guix-daemon every time?
<nckx>apteryx: OK, I'll rescind the ‘churn’ argument against renaming it to %installer-…, if even someone looking right at it was confused. :)
<apteryx>agreed it's confusing
<nckx>darosior: I think guix --substitute-urls="…" should override the daemon's arguments.
<nckx>apteryx: OK, I'll change it then? I wonder if the intention was ever to add it to %base-packages.
<darosior>nckx: ok i was under the impression it wouldn't, since the doc says "--substitute-urls=URLS fetch substitute from URLS if they are authorized".
<nckx>Before the opposite direction was chosen with the per-<file-system> automagic.
<nckx>darosior: Authorisation is still required, but has nothing to do with the daemon command line.
<darosior>nckx: ok, thanks!
<nckx>It's the keys listed in /etc/guix/acl, managed through ‘guix archive’.
<pkill9>darosior: there is an environment variable for setting command line arguments for the guix command, i think
<pkill9>oh nvm probably not what you wnat
<johnabs[m]><podiki[m]> "also, what WM or DE are you..." <- Yo podiki, I got it working! I think the problem was me trying to change the theme when I had some gtk apps open. This time I closed everything but lxappearance, it worked!
<johnabs[m]>Oh, one more thing, do I have to run this every time I start the machine or did lxa set it to a permanent default? I assume the former, but I'm not positive.
<jab>hey guix friends!
<apteryx>nckx: I'm preparing a simple patch with the e2fsprogs fix
<nckx>johnabs[m], podiki[m]: Is there anything like xmonad for Wayland yet(/again, waymonad looked dead last time I poked it)?
<nckx>Hi jab.
<jackhill>nckx: I don't know the answer, but I'm curious which parts for xmonad are you interested in? I've heard of some compositors that have similar default layout schemes, but, to me, that wasn't the most interesting part of xmonad
<jgart[m]>nckx: There's something better:
<apteryx>does the "--add-header=X-Debbugs-Cc:" really work with git send-email?
<apteryx>does debbugs really use it?
<johnabs[m]>nckx: Currently, I don't think so, hence why I'm still using xmonad xD
<nckx>jackhill: The ability to programatically define real-time non-default layout schemes. That's all I'm personally missing from Sway.
<nckx>ACTION checks out velox, thanks.
<tricon>velox looks interesting, thanks. (long-time dwm user.)
<nckx>Hm, I see. Tagging's nice but I don't actually miss it that much.
<apteryx>nckx: I've tried the X-Debbugs-Cc trick with your email, let me know if it works!
<efraim>patch to get rust-1.64 building on riscv64 doesn't break building it on x86_64, still need to wait out building it on riscv64 to see if it actually works
<nckx>apteryx: The headers look the same as any other guix-patches message, but then I'm already subscribed to the list. Perhaps it's implemented entirely on the mailman side, and there's no visible CC difference on outgoing mail.
<nckx>I think you'd have to X-D-CC someone who's not subscribed to tell.
<mirai>Any idea what's causing this syntax-transformer error? ( It's mostly similar to the example in
<apteryx>hm. then it's not as good as a CC, at least for people filtering on Return-Path like myself
<apteryx>(all guix-patches mail go to a guix-patches directory, except if I'm mentioned explicitly, in which case they reach my INBOX)
<apteryx>I thought that was the idea of being part of a teams (to be notified)
<nckx>R-P is identical in both cases for me.
<jgart[m]>How do I explain #~, #$, and #$@ to my barber?
<nckx>And I didn't get another copy with different headers AFAICT.
<apteryx>I was under the impression that Debbugs might do something smart, like CC you to any communication in the issue you were originall X-D-CC'd to
<nckx>You might also be right that git gets in the way. I've never used X-D-CC to be honest… I just CC manually in those rare cases.
<jab>nckx: are you pretty busy with the latest guix release?
<nckx>No, thorer stuff unfort.
<podiki[m]>johnabs: glad it worked! shouldn't need to close other programs though, maybe a bug somewhere. and I don't need to run lx everytime, but I do set some gtk things besides what it sets and use xsettingsd as well
<jab>cool cool
<podiki[m]>nckx: I know nothing about wayland, but the lack of one I like (stump preferably, xmonad maybe) has kept me from trying out wayland
<gnucode>podiki[m]: I guess that you do not like sway?
<podiki[m]>gnucode: admittedly have not tried! I did start my tiling journey with i3, but that was a long time ago.
<gnucode>podiki[m]: I wish sway was a little flashier, but it is incredibly stable. No complaints from me.
<lechner>nckx / apteryx / X-Debbugs-CC is used during the initial bug submission\. It sends the recipient a copy of the report that includes the assigned bug number, which is unknown at the time of sending. Subsequent bug amendments are not forwarded to that recipient.
<podiki[m]>gnucode: good to hear. there's that really slick animated one, i think for wayland...hyprland looks very nice in screenshots/gifs I've seen
<podiki[m]>I wish debbugs would add anyone that responds to a bug number to who gets emails sent to that bug number; too often people don't cc directly (which can take a few steps depending on how you read bug reports)
<raghavgururajan>podiki[m]: I wish StumpWM be ported to wayland.
<gnucode>raghavgururajan: I just figured that you were going to do that on your off day out of sheer boredom. :)
<podiki[m]>raghavgururajan: ditto. there's a project that is trying, but according to the readme is not far along
<raghavgururajan>gnucode: Hehe!
<raghavgururajan>podiki[m]: I see.
<podiki[m]> I do want to see what it can do though
<podiki[m]>I guess first step is getting a nice guix package to make it easier to hack on :)
<jackhill>wayfire getting plugins is also interesting: maybe we're wondering off topic.
<jackhill>podiki[m]: yes! We should package all the things!
<jgart[m]>jackhill: are you still interested in working on a janet-build-system?
<jackhill>jgart[m]: yes. I'm not prepared to lead an effort right now, but I can review and test
<raghavgururajan>ACTION says GuixWM
<jackhill>Pure Guile wayland client:
<jgart[m]>jackhill: Do you have any notes on what you learned from how jpm works and how janet sources library code installed by jpm?
<jackhill>jgart[m]: not really, sorry, and I haven't kept up with and changes Janet may have made. The best I have is the patch for a GUIX_ environemnt variable to add locations Janet's loader will look:
<jackhill>Hey, there are some comments there!
<jackhill>jgart[m]: I don't think I ever looked into how jpm builds janet packages
<jgart[m]>Cool, did that patch work for you at the time? Were you able to load any 3rd party janet libraries that were installed via Guix?
<jackhill>jgart[m]: yes it worked for me. I never installed other libraries via Guix (maybe I'd have better luch now, buy my build-system understanding at the time was too poor (attempt in subsiquest commits on the same branch). My test case was manually installed janet source in some random directory.
<apteryx>lechner: OK; does it do something different w.r.t. mail headers for a user already subscribed to the list?
<apteryx>nckx: just sent the rest of 59661 that we discussed earlier
<apteryx>(e2fsprogs and related)
<jgart[m]>jackhill: Do you think jpm should be a separate Guix package?
<jgart[m]>jpm is not part of janet anymore
<jgart[m]>It's a third party package
<jackhill>jgart[m]: yes, probably
<podiki[m]>I've been meaning to catch up and respond to the "advanced" discussion on the devel list, but got me thinking about keeping "advanced" (I like it!) while still being accessible
<lechner>apteryx / which list, please?
<gnucode>raghavgururajan: :)
<podiki[m]>so what about something like: GNU Guix: An advanced distribution for everyone
<podiki[m]>as I think we should stress this is a welcoming and inclusive community
<lechner>podiki[m] / Hi, I also like "advanced" but I get the point that it's a value judgment not directly supported in the text. while that should not disqualify the word, it also slightly inaccurate: Our chief distinguishing feature is not actually that we are "advanced," but rather that we are advancing. That, however, reads silly as a replacement, so I would prefer "innovative and evolving" personally
<podiki[m]>maybe "a continually evolving distro"
<podiki[m]>and I agree that "advanced" can be seen as a barrier, even if it is not meant that way
<lechner>podiki[m] / we are "always one commit away from the future"
<podiki[m]>the real barrier is that we are different (for good reasons) more than being more "difficult" than any other distro
<lechner>as for being welcoming and inclusive, i think people will realize that when they get here
<lechner>many communities state so, but this is one of a handful i know that actually practices it
<podiki[m]>true, but messaging can matter; I think many would like what Guix offers, just getting to the trying point can be the trick :)
<jgart[m]>I think what sets Guix apart from the others is the Emacs Thesis applied to managing Operating Systems, Services, Packages, Dotfiles, etc.
<nckx>apteryx: Thanks! I've unmoderated you on info-guix 😉 should arrive now.
<nckx>ACTION busy.
<podiki[m]>jgart: ah, nice
<unmatched-paren>jgart[m]: re your question about #~, #$, and #@:
<lechner>jgart[m] / very true
<unmatched-paren>#~(...) is almost like `(...), where you can unquote things to access external variables `(if (and ,foo (= 2 (/ 4 2))) (display "hi") (display "bye")) <- quote of course can be used to store code, since all scheme code is just a bunch of basic data types in lists
<unmatched-paren>before gexps were added, `(...) was used for code staging
<unmatched-paren>buuuuuuut with gexps, there's an extra "rule" when un{quote,gexp}ing
<unmatched-paren>#~(display #$foo)
<unmatched-paren>now, if foo is "blah", it'll just look like this: #~(display "blah")
<unmatched-paren>when the ungexps are expanded
<jgart[m]>That's why I've stayed with Guix. I'm on a journey to hack the great hack and I need a real lang that won't pose any limitations at any junction along the way.
<unmatched-paren>and if bar is (list "foo" "bar" "baz") in #~(format #t "~a ~a ~a" #$@foo), it'll look like this when expanded -> #~(format #t "~a ~a ~a" "foo" "bar" "baz")
<unmatched-paren>so far, so similar
<jgart[m]>The only limitation should be my imagination and time.
<unmatched-paren>however! if the ungexped thing is a file-like object (that is, a record that is defined to be compilable to a derivation with ``define-gexp-compiler'')
<unmatched-paren>eg #~(display #$(local-file "foobar.text"))
<lechner>podiki[m] / jgart[m] / in a world of a thousand programming languages, many of them good, Guix contributors have one in common: Guile is our lingua franca
<unmatched-paren>when that file-like is ungexped, it won't be embedded like it would with unquote
<unmatched-paren>(with quote it'd probably look like `(display #<local-file ...>)
<unmatched-paren>ACTION checks whether it does
<jgart[m]>unmatched-paren: Are you going to finish the story? I'm waiting for the punchline ;()
<unmatched-paren>jgart[m]: yes, i'm just checking what a record expanded into a quoted form looks like :)
<unmatched-paren>jgart[m]: yeah, it looks approximately like that
<unmatched-paren>ACTION has to go for a moment, sorry :(
<jgart[m]>K, rain check plz
<podiki[m]>perhaps not the expected punchline, but the end result for packaging is getting store paths as a string, say to patch something to have the absolute path to a needed library
<podiki[m]>this needs to be done knowing the store path for an object, which is the gexp link for a build time value
<jgart[m]>lechner: The GNUsperanto of the GNUs
<jgart[m]>podiki: got it
<jgart[m]>I'm lost on using Guile's debugger
<jgart[m]>Not sure how to set a breakpoint and step through fibonacci
<jgart[m]>Anyone know?
<Kolev>jgart[m]: Chu vi diris pli Esperanto?
<podiki[m]>all I know is that there is a big discussion about guile debugging on the devel list right now :) some examples there too
<jgart[m]>I'd like to step through a Guix stacktrace
<jgart[m]>and inspect variables and objects
<jgart[m]>podiki: can you link me
<lechner>jgart[m] / "the extensible and self-documenting operating system"?
<podiki[m]>jgart: I believe the first message
<jgart[m]>Kolev: Ne, ne vere. Mi ne scias fekon. Mi estas novulo.
<jgart[m]>podiki: thnx!
<jgart[m]>lechner: I think self-documenting would be a stretch currently.
<jgart[m]>Guix is not self-documenting as far as I know unless you consider the source code to be the documentation ;()
<civodul>jgart[m]: see and the REPL page it refers to
<lechner>jgart[m] / you are right. i was trying to evoke the connection to Emacs without discriminating against users of Vim (or whatever)
<jgart[m]>civodul: I've read that but that doesn't show how to set a breakpoint iirc
<jgart[m]>civodul: unless the idea is to let the program crash and that's how you set the breakpoint?
<jgart[m]>one type of breakpoint, that is
<jgart[m]>I mean to let the program crash in the debugger in order to start debugging
<civodul>try ",break foo", where "foo" is the name of a procedure
<jgart[m]>But I'd like to step through (fib 12) or (lower foo) in the case of guix
<jgart[m]>how about fib 12
<jgart[m]>,break (fib 12)
<jgart[m]>let me try ;()
<civodul>see above
<unmatched-paren>jgart[m]: I'm back :)
<civodul>if you're trying to illustrate that the doc can be improved, i agree :-)
<jgart[m]>civodul: How do you think it can be improved? With a tutorial?
<civodul>with examples for breakpoints
<jgart[m]>debugging tutorial would be nice
<jgart[m]>I agree
<unmatched-paren>jgart[m]: so, you following so far?
<jgart[m]>not sure if I'm the right person to write it but maybe once I learn
<jgart[m]>unmatched-paren: ya
<jgart[m]>trying to see if I can step through fib in the guile debugger
<unmatched-paren>with a record that has been define-gexp-compilered, instead of producing the #<...> thing when ungexped, it'll be compiled with the gexp-compiler into a derivation
<jgart[m]>but ,continue
<jgart[m]>no pun
<unmatched-paren>and then that derivation's output path will be substituted in its place
<sneek>zamfofex: Greetings!!
<unmatched-paren>`(foo ,(local-file "foo.text")) => `(foo #<<local-file> ...>)
<jgart[m]>unmatched-paren: Are you reading me the manual out loud verbatim? If not, after you're done with the story can you commit the story to the docs?
<zamfofex>sneek 💞 botsnack
<unmatched-paren>#~(foo #$(local-file "foo.text")) => #~(foo "/gnu/store/...-foo.text")
<unmatched-paren>jgart[m]: no, this isn't in the manual
<jgart[m]>got it
<reyman>hum, i progress in the packaging of deno, but i'm now blocked by usage of ccache and a problem of homeless-shelter
<reyman> ccache: error: Failed to create directory /homeless-shelter/.cache/ccache/tmp: Permission denied
<reyman>someone know args of ccache to solve that ?
<unmatched-paren>reyman: (setenv "XDG_CACHE_HOME" "cache")
<unmatched-paren>in a build phase after 'unpack
<jgart[m]>so gexp is sugar to get us to not have to type the long hashes and paths in the store
<reyman>thanks @unmatched
<jgart[m]>wish the manual just said that tldr
<jgart[m]>i'll stop complaining and start texinfoing
<unmatched-paren>jgart[m]: for an example of a simple define-gexp-compiler, see ``scheme-file-compiler'' in guix/gexp.scm
<unmatched-paren>jgart[m]: i'll add a section for it, just as soon as i've finished this day-long escapade to update zoxide
<jgart[m]>good luck with rust
<unmatched-paren>jgart[m]: because zoxide is rust, i've had to update tokio, rust libc, etc...
<jgart[m]>you'll need it
<unmatched-paren>pain :)
<jgart[m]>especially since etc/committer.scm doesn't do what I thought it did
<podiki[m]>well you don't know the store path, you need that at actual build time
<podiki[m]>but yes, to get store paths is the effect wanted often
<unmatched-paren>yeah, ungexp on a lowerable object builds the derivation
<jgart[m]>I'll start to packaging rust code when etc/committer.scm auto-commits everything
<reyman>great rust v8 compile :)
<jgart[m]>silly question: building the derivation actually runs gcc?
<reyman>documentation say 30 min, thats a long time ..
<reyman>hope that don't failed this time
<unmatched-paren>jgart[m]: depends what the derivation specifies
<jgart[m]>or is there another bag after that?
<jgart[m]>well in the case of a C program
<unmatched-paren>the derivation contains the path to a build script written in guile
<jgart[m]>instead of say a dotfile as part of guix home
<jgart[m]>do all derivations ultimately become guile build scripts?
<unmatched-paren>if the derivation is made using <package>'s gexp-compiler and the package uses gcc, then yes, the build script will call gcc
<unmatched-paren>jgart[m]: not quite. the build script doesn't become a build script.
<unmatched-paren>try this: ``guix build guile --derivations''
<jgart[m]>if it's a build script already why does it need to become a build script?
<unmatched-paren>typo; first build script should be derivation
<unmatched-paren>derivation does not compile further into a build script
<unmatched-paren>if you look at that drv file
<reyman>hum clang++: error: invalid linker name in argument '-fuse-ld=lld'
<jgart[m]>ya I see this drv mess now:
<unmatched-paren>jgart[m]: lemme format that
<jgart[m]>would be cool to have a html drv pretty ssg printer or not
<jgart[m]>unmatched-paren: with emacs?
<unmatched-paren>jgart[m]: by hand :)
<jgart[m]>emacs-guix has a derivation pretty printer right?
<unmatched-paren>i dunno
<jgart[m]>oh ok
<jgart[m]>nckx: once shared a bash script to pretty print drvs
<jgart[m]>but it must be lost now in the irc ocean log
<unmatched-paren>i'll add comments to the drv...
<nckx>It was not pretty at all, just split some lines.
<jgart[m]>maybe we can add a derivation pretty printer as a guix subcommand?
<jgart[m]>or cli flag?
<jgart[m]>for the convervative
<unmatched-paren>guix style --derivation?
<jgart[m]>I realize cli flag might be better design ;()
<jgart[m]>that would be nice
<jgart[m]>instead of having me open that long path it will just take the package name and pretty print the drv to standard output
<unmatched-paren>oh, that's a good idea
<unmatched-paren>could accept either
<jgart[m]>I think that would be a killer feature
<unmatched-paren>guix build can accept both package names and drv paths
<jgart[m]>I don't think nix cli does that
<unmatched-paren>for example
<jgart[m]>I just want to give it a package and print the drv :)
<jgart[m]>to standard output in a pretty way
<nckx>Nix has ‘nix show-derivation’, but it's better as an option to ‘guix style’ indeed.
<jgart[m]>does nix show-derivation print to standard output pretty formatted?
<jgart[m]>I'd also like a github package importer
<unmatched-paren>jgart[m]: how would that work though
<unmatched-paren>i do think (guix git-download) should have github-url, git-sr-ht-url, gitlab-url, codeberg-url, etc though
<nckx>jgart[m]: I wouldn't have mentioned it if it didn't do so.
<jgart[m]>and a package importer for a package with a random hash. It tells me to pick the commit I want fuzzily with fzf for the give github repo and then generates the guix package with (let ((commit ...) (revision ...)) blah blah
<jgart[m]>nckx: didn't realize it had feature parity with this idea, k, thanks.
<jgart[m]>re git-download: I concur
<jgart[m]>I think we should also have a section in the doc that states what are policy is for rust packaging with regards to upgrading/choosing versions for existing/new packages
<jgart[m]>I think I know what it is now because of I've read a ton of efraim and others previous commits but it would be good to formalize it if we have a formalization
<jgart[m]>so that new rust packagers don't find out at review time and can have a game plan for how to upgrade a rust package
<unmatched-paren>jgart[m]: i don't know all the "arguments", but
<unmatched-paren>this is my best guess at what the derivation means...
<unmatched-paren>anyway, if you look at that module-import directory, that contains all the modules available to the build script
<unmatched-paren>it's loaded with -L
<jgart[m]>Is there a doc that currently explains and annotates the derivation outputs like that more or less?
<jgart[m]>It's in the nix docs?
<unmatched-paren>jgart[m]: here's the build script pped with emacs
<unmatched-paren>(that's where the deprecated %output, %outputs, and %build-inputs come from)
<unmatched-paren>gnu-build can be found in guix/build/gnu-build-system.scm in the module-import directory :)
<reyman>hum now this is a problem with torque compilation ... "./torque: error while loading shared libraries: cannot open shared object file: No such file or directory"
<reyman>Hope adding gcc tolchain solve the problem
<unmatched-paren>reyman: you shouldn't add gcc-toolchain to the inputs of a package
<unmatched-paren>try adding (list gcc "lib") instead, maybe
<jgart[m]>unmatched-paren: thnx, I'll take a closer look today
<lechner>unmatched-paren / Hi, what's /home/greeter, please? Also did you ever get pipewire to work? Thanks!
<reyman>oh ok, actually i try some brute force, because v8 is so big, i'm not a c/c++ programmer
<reyman> (native-inputs (list ninja gn glib clang-toolchain gcc-toolchain ccache clang python pkg-config lld python-pkgconfig))
<reyman>so i replace the gcc toolchain
<unmatched-paren>lechner: the greetd greeters run as the greeter user
<pkill9>pipewire has worked well for me
<unmatched-paren>reyman: it should be an input
<unmatched-paren>lechner: i haven't found the time to figure out pipewire yet, no :
<unmatched-paren>reyman: these are inputs:
<unmatched-paren>(inputs (list clang (list gcc "lib") glib)
<unmatched-paren>these should be native-inputs:
<unmatched-paren>(native-inputs (list ccache gn ninja pkg-config python python-pkgconfig))
<unmatched-paren>oh, yes, lld should also be in inputs
<unmatched-paren>don't use clang-toolchain either
<unmatched-paren>those -toolchain packages are for use with the command line only
<reyman>ok ! i will try that, thanks
<unmatched-paren>reyman: the difference is that if you are cross-compiling for aarch64 on an x86-64 machine, the inputs will be built for aarch64, but the native-inputs will be built for x86-64
<unmatched-paren>so non-source libraries, utilities to run during the build, etc, should be native, because they're run on the machine used for builds
<unmatched-paren>whereas things like compilers, linkers, .a/.so libraries, programs whose paths are substituted into the source, etc should be inputs
<unmatched-paren>actually, wait, non-source libraries should be inputs, not native-inputs
<mirai>Any idea what's causing this syntax-transformer error? ( It's mostly similar to the example in
<lechner>pkill9 / will you share your configuration for pipewire, please?
<pkill9>when i get home, sure
<lechner>unmatched-paren / i figured, but isn't it more common to set home folders for system users to some place in /var?
<unmatched-paren>lechner: -.o.- ask muradm :)
<reyman>hum i understand,
<reyman>changing native-input / input generate new error message at start, linked to gcc : ../../../buildtools/third_party/libc++/trunk/include/cstdlib:99:9: error: no member named 'size_t' in the global namespace
<unmatched-paren>reyman: are you sure clang is needed for this? i wonder if mixing clang and gcc:lib is causing problems...
<reyman>yes, clang is needed for v8 :
<lechner>size_t may be in linux/types.h
<reyman>i will retry without gcc to see
<unmatched-paren>lechner: decent point, reyman maybe try adding linux-libre-headers to native-inputs
<reyman>ok !
<reyman>hum same :
<reyman> In file included from /gnu/store/069aq2v993kpc41yabp5b6vm4wb9jkhg-gcc-10.3.0/include/c++/stdlib.h:36: ../../../buildtools/third_party/libc++/trunk/include/cstdlib:99:9: error: no member named 'size_t' in the global namespace
<unmatched-paren>that's really weird :(
<unmatched-paren>sorry, i don't know enough about gcc and clang to help further.
<lechner>i think -I XXXX may be missing
<reyman>thanks, and that's better than me :)
<reyman>adding clang-toolchain to inputs i have no error like that.
<reyman>ACTION uhuh .. trial and error 
<mmorko12>hello everyone quite new to guix, but linux user for a long time
<unmatched-paren>you could look at the propagated-inputs of clang-toolchain to see which packages it includes
<unmatched-paren>mmorko12: hello! feel free to ask anything :)
<reyman>hi mmorko12
<mmorko12>thanks guys
<mmorko12>i do have a strange issue on one machine with guix with TMUX and locale
<mmorko12>tmux: invalid lc_all, lc_ctype or lang
<mmorko12>i set locale in config file
<mmorko12>i installed glibc-locales via guix install
<mmorko12>but still the same
<unmatched-paren>mmorko12: try logging out and back in
<unmatched-paren>sometimes, packages set up "search paths" which are sourced by your .profile
<unmatched-paren>but to reload .profile, you need to log out
<mmorko12>i rebooted the machine N times no change
<mmorko12>i installed screen at the moment it do the job
<mmorko12>but ina corner of my brain it make me unconfortable :D
<unmatched-paren>hm, that is strange
<mmorko12>yes it is
<unmatched-paren>mmorko12: have you ``guix pull''ed yet?
<mmorko12>i have another machine with Guix as well and no problem
<unmatched-paren>oh, right
<unmatched-paren>i thought you were a completely new user :)
<mmorko12>yes guix pulled couple of time
<mmorko12>well no worries
<mmorko12>i am new to guix, not to linux
<unmatched-paren>that's really odd. maybe try searching through the bug-guix and guix-help mailing lists
<mmorko12>coming from void linux troubleshoot is not anew thing LOL
<reyman>lol, i have f*** strange error during this compile, "obj/third_party/icu/libicuuc.a" error /gnu/store/4y5m9lb8k3qkb1y9m02sw9w9a6hacd16-bash-minimal-5.1.8/bin/sh: line 1: ../../../../../../gnu/store/zfs41ixykm4z9162gajgs1ndc6bsbcqr-clang-13.0.1/bin/llvm-ar: No such file or directory
<mmorko12>well at the moment the idea is to refine my configuration and guix home and re install anyway
<mmorko12>it is a test machine
<unmatched-paren>ACTION away
<mmorko12>i do have some trouble in the conf as well, fighting with some fine tuning
<mmorko12>for example in the service section i would like to disable the lid switch when in AC but suspend when on battery
<mmorko12>; this disables sleeping on closing notebook lid
<mmorko12> (elogind-service-type
<mmorko12> c => (elogind-configuration (handle-lid-switch 'ignore))
<mmorko12>at the moment i acieve half of the feat
<mmorko12>not sure how to add the second half
<mmorko12>from the manual i understand i do use handle-lid-switch-external-power'ignore
<mmorko12>i can achieve one or another but not both
<mmorko12>as soon as i try to add a list to elogind-service-type it fails reconfigure
<unmatched-paren>why aren't rustcs 1.61 to 1.65 public?
<podiki[m]>probably because they didn't want to do a full rust rebuild from bumping the version? but you can use them in packages (sadly not build on CI then since nothing used them last I checked)
<podiki[m]>not sure why not public-ing newer versions, like a "rust-next' maybe
<omlet[m]>ACTION uploaded an image: (111KiB) < >
<omlet[m]>Audacity without tracker right?
<rekado>I think the wireguard thing is due to changed keypairs
<rekado>yup, new public keys
<rekado>nckx: I’d like to reconfigure berlin
<rekado>I’d like to update the wireguard keys that berlin expects for the reinstalled pankow and grunewald
<zamfofex>reyman: Thanks for working on packaging Deno! I will note: Maybe it’d make sense to remove code under ‘third_party’ (since it is usually for vendored projects in Chromium) and instead use the existing packages in Guix (including for LLVM’s libc++, which I think should already be packaged).
<zamfofex>Also, maybe it’d make sense to at least try to build it with GCC instead of Clang if it’s feasible.