IRC channel logs


back to list of logs

<florhizome[m]>tissevert: Pretty sure there are other solutions, too, but haven’t tried.
<florhizome[m]>In fact I still want to get the greetd patch merged.
<radomir>tissevert, Did I just tag u? U see it green right?
<jpoiret>i've been happily using GDM to launch Sway on core-updates-frozen
<vivien>KE0VVT, when it can’t start the session, GDM won’t be very helpful as to why it can’t, and we get issues like this:
<jpoiret>you can backport the patch on master if you want
<KE0VVT>jpoiret: Good to know.
<vivien>(I don’t endorse the tone of that message ^^)
<jpoiret>vivien: i think with the debug? flag of gdm-configuration there would be a more verbose error message but alas
<tissevert>radomir: you absolutely tagged me ! we probably don't use the same client or not on the same terminal with the same color scheme so, no, I must confess it looks purple-ish here but it definitely looks like a tag
<florhizome[m]>jpoiret: *really soon* ;P
<florhizome[m]>i would just prefer a different default >.<
<vivien>Yeah, that’s like with crypto, if you knew in advance you would need to get it, you would be rich by now
<vivien>But it has no utility right now :)
<vivien>The debug? flag
<KE0VVT>jpoiret: Sway does not support IBus, which means no typing Japanese. :-(
<florhizome[m]>well you can still get rich with crypto vivien nobody’s stopping you ;P
<radomir>tissevert, glad to hear that! I just installed hexchat to try to join this channel in a fast and simple way. Will change the client to a less bloated one very soon. I actually come here to ask about compiling stuff on my own machine from source since it doesnt work out of the box like in the other distros. Do u know anything about that?
<KE0VVT>How small can I make my root partition, so that I can keep most everything else on a data partition?
<tissevert>I'm certainly not the most knowledgeable person in this room but I know this distro is good at preparing development environements for you so it shouldn't be a problem
<tissevert>I'd say it depends on the language you're working on
<jpoiret>radomir: the info manual of Guix has most of the basic info you need, there's a section "Development" there. Open it using `info "(guix) Development"`
<tissevert>(for haskell for instance, I directly write guix packages and have it handle the whole compilation because using cabal doesn't really work satisfyingly)
<jpoiret>but yes, you'll need to identify the toolchains you want to use to compile locally. If the thing to work on is already packaged though, it will be very easy to do using `guix shell` as described in the manual.
<jpoiret>tissevert: if only everyone did that as well :)
<tissevert>yeah I know
<tissevert>but on the other hand it's sometimes a real bore to see cabal going once again through all my source files when I know they compile perfectly well and I just wanted to check if the two characters I changed allowed the unit tests to pass
<tissevert>also, guix copying everything from my local copy of the repos, including .git and all the commits there to the store
<tissevert>how hearbreaking
<radomir>I want to try to use dwm (dinamic window manager) on my guix machine but it requires configuring the source file. its pure C. And i would like to use it as my main WM.
<radomir>jpoiret, I was searching through manual a lot but didnt find anything i looked for. Ill take a look under development section! ty!
<vivien>At that point, from what I understand of it, getting rich with crypto is either indiscernable from a gamble, or using it as a keyword to scam other people for their money, so I’ll pass.
<KE0VVT>Sounds like I cannot keep the system partition small, and the data partition taking up everything else.
<tissevert>ah, that's interesting, I have a similar problem with xmonad, which requires compilation
<tissevert>you'll probably want the gcc-toolchain package in a shell, like jpoiret said
<radomir>dwm already packaged btw. But it doesnt matter since its config is actually the source code.
<tissevert>as well as the dependencis for dwm
<KE0VVT>dwm sounds terrible on Guix.
<tissevert>that's where guix package gets useful : even not to install it directly because you have a local source file, it lets you open a shell with everything needed to hack on it
<tissevert>as simply as: guix shell -D dwm
<KE0VVT>Although, I'd prefer dwl. Wayland FTW.
<tissevert>KE0VVT: how do you run it on guix ? I'm trying to run sway from an empty system (no gdm, no deskop environment, I disabled everything at install to simply get a tty)
<civodul>nckx: thanks! it's similar to what i've observed, which is good
<tissevert>and it's not working terribly great : S
<florhizome[m]>jpoiret: from earlier, calling mixed–text–file in a build phase like (lambda _ (mixed–text–file ... )) gives me an unbound variable error. Also I think vivien indicated it doesn’t actually output something to the local directory.
<vivien>For the error, you are correct that you need to import (guix gexp)
<tissevert>ouch : /
<tissevert>it worked : (
<tissevert>now I'm trapped in sway (I don't know the shortcuts and it's a pain to send ctrl-alt-f1 because I'm in a qemu VM)
<jpoiret>oh yeah, my bad, i thought you wanted to create files outside of that. For build phases you do want to use ports, although source patches and substitute* are probably more readable for more casual guile users
<florhizome[m]>KE0VVT: I’ve seen a guile–dwl on GitHub I think
<vivien>The things that are used most in build phases are substitute*, invoke and wrap-program
<tissevert>why did I ever do that ?
<florhizome[m]>you mean substitute a file thats not there ?
<vivien>substitute* is like sed -i
<vivien>It will replace patterns in the file you want to modify
<florhizome[m]>I haven’t used sed yet
<florhizome[m]>Yes I have been using it
<florhizome[m]>I want just „ ....“ > file
<radomir>florhizome[m], hmm i saw it too. Not sure if it's finished yet. but sounds good. Im still super fresh to this OS so im not sure how does it work actually. Is it like guile config file instead of configuring source?
<florhizome[m]>I haven’t tested it...
<vivien>florhizome[m], I’m not aware of a function that does that, and that’s annoying, but you can invoke bash -c "... > file"
<tissevert>why didn't it ask me about mod1 or mod4 ? T_T
<florhizome[m]>I think that’s where Ports come in technically but it’s uh very technical
<vivien>Maybe: (with-output-to-file "file" (lambda () (invoke ...))) works
<tissevert>anyway, nighty night everyone !
<vivien>But it would surprise me
<florhizome[m]>The difference between invoke and system would be?
<vivien>system isn’t safe because it requires you to quote shell expressions, system* does not throw an exception if the program fails (which is a strong expectation in guix)
<vivien>Not that I’m saying you can’t quote shell expressions, but it’s way harder
<vivien>than simply using system* or invoke
<KE0VVT>florhizome[m]: Guile DWL? Awesome.
<KE0VVT>florhizome[m]: A Guile compositor would be awesome.
<florhizome[m]>KE0VVT: Would love bindings to wayfire.
<florhizome[m]>also there seems to be a module for a tiny wm like thing, on the guile Website.
<florhizome[m]>vivien: noted ! ^^
<florhizome[m]><tissevert> "anyway, nighty night everyone !" <- nighty (:
<vivien>florhizome[m], maybe you could use open-pipe-with-stderr
<vivien>(from (guix build utils))
<dissent>hey guix, attempting to package trayer-srg. should be relatively simple since there is only one dependecy. getting build fails though.
<florhizome[m]>uhm OK
<florhizome[m]>I will have a look.
<dissent>here is the package definition:
<dissent>and here is the fail log:
<jpoiret>dissent: it is not a GNU autotools based configure script it looks like
<jpoiret>you'll have to replace the configure phase with a proper invocation of the configure script
<KE0VVT>Aw, Guix does not have Podman. :-(
<florhizome[m]>to capture the Moment, though:... (full message at
<KE0VVT>What is the smallest size I can make my system partition? I want to keep all data on its own partition.
<dissent>I see the above was made by jgart. What I was working on, though, took stalonetray as the template. Is this the more appropriate format?:
<vivien>florhizome[m], to create a file, do (call-with-output-file "local-file" (lambda (port) (format port "hello :)\n")))
<vivien>The complex thing is to get the output of a command to fill in the file
<florhizome[m]>i thought you thought it didn't Work?
<florhizome[m]>Ah i just want Text into a file
<vivien>Ah ok
<vagrantc>KE0VVT: very hard to predict a minimum size
<florhizome[m]>echo "Text" > File probably
<vivien>That’s harder
<vivien>Believe it or not
<florhizome[m]>why 👀
<florhizome[m]>i recognize there might not even be such a simple command in the regular shell
<florhizome[m]>Not a very expressive one
<vivien>Because spawning processes has a lot of legacy, and you have basically two modes: either run the program, wait for it to terminate, and get its exit code, or start it and play with its input and output ports and jump through more asynchronous hoops to know when it’s finished
<vivien>Of course, you can still (invoke "bash" "-c" "echo \"Text\" > File")
<vivien>But that introduces some new inputs and it’s not very satisfying
<vivien>And, if some part of the command is left to the user, it might introduce undesirable behaviors
<florhizome[m]>Satisfying to me in this instance ist what gets the Script where i need IT to be
<florhizome[m]>actually bash is already an input
<nckx>These are fake-lookingly perfect:
<vivien>(call-with-output-file "the-Script" (lambda (port) (format port "#!/bin/sh\nstuff\n") (chmod port #o755)))
<nckx>(Huge store; probably bigger than any's.)
<vivien>However, what I present here is a way to create a script that will be used as part of the build system, and I’m not sure that’s what you want
<florhizome[m]>vivien: No i need a wrapper Script to Set some env vars when Launched from sddm etc
<florhizome[m]>Also to use dbus-run-session
<vivien>So, you are packaging a program, right?
<florhizome[m]>It's more about it/the conpositor running well by now.
<vivien>But the program is not sddm?
<florhizome[m]>No that's the login manager
<vivien>It’s like a text editor?
<florhizome[m]>It's a compositor
<florhizome[m]>It's Not emacs, there are different programs :D
<vivien>OK so the compositor can’t be started by the login manager because it needs to be wrapped
<vivien>because the compositor needs to be wrapped
<florhizome[m]>Actually you should at least Run wayland compositors with dbus-run-session, just a good Thing to do afaik
<vivien>So when packaging the compositor, you would add a phase after the install-phase. The phase would do 2 things: move the "bin/compositor" to "bin/compositor.real", and create a "bin/compositor" script that would do some wrapping and invoke "bin/compositor.real".
<vivien>These two things are usually done by the wrap-program function in (guix build utils), but I believe it can’t run dbus-run-session
<vivien>(it can’t wrap the compositor with dbus-run-session)
<florhizome[m]>it also needs to find it's plugins, and we might just export more wayland related env vars
<vivien>I’ll leave the details to you, I don’t know much about the wayland stuff ^^
<vivien>To find the plugin paths, you can look at the inputs argument in your phase function
<florhizome[m]>it's good thing!1
<jgart>could we add a default config for stalonetray to the gnu/store?
<jgart>does it make sense to do that?
<florhizome[m]>Then i would have to have them as inputs?
<jpoiret>florhizome[m]: sddm doesn't support wayland yet afaik
<bost>Hey guys, watch how `apt` breaks a Pop!_OS installation (a linux distro for gaming) ... and not having any `--roll-back` like we do!
<bost>The video is getting popular: 1,768,468 views.
<vivien>florhizome[m], yes, the plugins and stuff would be inputs of your package, and you would get their full paths by indexing the inputs argument of your phase function by their names
<florhizome[m]>jpoiret: I start sway from it though. Also it's recommended in man
<vagrantc>you can just start sway from a non-graphical login :)
<Kolev>Insralling on spare disk
<florhizome[m]>vivien: That's kind of the wrong way around, though... The Plugins depend on the conpositor, not the other way
<vivien>Ah, I see
<vivien>That will put you in a pickle
<florhizome[m]>i like pickles
<jpoiret>Also, running dbus-run-session in a wrapper shouldn't be be something that is packaged into the wm itself, but rather as something called from sddm. The last time i checked when I patched gdm for wayland there was an option in sddm (in guix) to add a custom wrapper
<jpoiret>My bad, I got confused with another DM there, of course sddm supports wayland, duh
<vivien>You won’t be able to escape from defining a service for your compositor
<jpoiret>Still though, i'd check (guix services xorg/sddm/whatever) for the sddm service configuration, i think everything's already there
<florhizome[m]>Well for now it's my package :P i want to test it, so i need to set it up some way.
<jpoiret>s/guix/gnu/ (on phone, sorrt)
<florhizome[m]>vivien: oof.
<Kolev>Im on revolution irc too jpoiret
<florhizome[m]>jpoiret: Sddm has a command it launches before a random Session, yes
<florhizome[m]>Some of these vars are special, though and i don't think i can use dbus-run-session like that
<florhizome[m]><vivien> "You won’t be able to escape from..." <- I could just package the script, though?
<vivien>florhizome[m], the manual is not as explicit as I would like it to be (
<vivien>florhizome[m], you could, but you won’t be able to get plugins.
<vivien>If you can, it means you broke sha-256
<florhizome[m]>i think i already do, when i export the specific env vars
<vivien>But you can’t wrap the compositor with the env vars themselves
<vivien>You need a service to run the compositor with the appropriate environment variables set
<vivien>Anyway, I won’t be able to help, it’s 1 am here and I can barely stay awake, good night :)
<florhizome[m]>This is where guix gets straight unusable for "everyday" tbh.
<vivien>You should not be writing services every day ^^
<vivien>That’s a hard task and guix should provide them.
<florhizome[m]>But these are very basic things
<florhizome[m]>I don't want guix to tell me, but to help me.
<florhizome[m]>It doesn't help i need to define a Service for every basic piece of personal configuration...
<vivien>No, you need to define a service for every program that runs as root as a daemon
<florhizome[m]>All the while running system reconfigure to test them.
<vivien>You can also test them in a VM
<vivien>with guix system vm
<Kolev>Cannot run weechat from live installer
<vivien>I’m not sure I 100% understand what you want, because maybe what you are trying to package is a program that will read the configuration options and plugins from the user’s configuration
<florhizome[m]>in this case, maybe, but it's a little much effort. When i'm working on sth hardware related, f.e., though?
<florhizome[m]>For now i install the Plugins in system.. Like xfces
<vivien>I don’t know xfce ^^
<florhizome[m]>It has plugins for it's Panel, they don't Work when installed as user.
<Kolev>Cant install and run tmux in live sistem
<vivien>Will the compositor program be run by root (or a system account) or by a user?
<Kolev>I dint see why the user should not run compositor
<vivien>florhizome[m], if the program is supposed to be run at boot by root, then you need to define a service. If the program is supposed to be run by the user, then the program should read its configuration and loads its plugins from the user’s home directory.
<vivien>(in the latter case, you shouldn’t have to do any wrapping)
<nckx>Kolev: Why can't you?
<Kolev>nckx: idk
<nckx>That's I-can't-help-you-this-way for ‘please share the command you ran & any error messages or other unusual behaviour it produced’ ☺
<nckx>You can paste multi-line output to, but I'm guessing you're not chatting on the same machine.
<Kolev> chatting from mobile nckx
<nckx>What the hell.
<vivien>Kolev, if you haven’t already, run guix pull and apply the setup commands it gives you at the end.
<vivien>Oh nevermind it should not be a problem
<vivien>I see your PATH seems correct
<nckx>No, and pulling would distract from the error.
<nckx>What the hell.
<nckx>I… guess I'd check what /root/.guix-profile/bin contains? Although I've never known ‘which’ to get confused.
<nckx>And I guess maybe ‘guix package -l’ just to see if there's a hint hiding there.
<vivien>And hash wgetpaste maybe?
<nckx>But why would which not find it, vivien? That's the weird thing.
<nckx>It does not give a hoot about your bash's cutesy hash table.
<cyberban`>what's bash's cutesy hash table
<nckx>Maybe the wgetpaste package was briefly broken, not installing an (executable, wrapped) binary? In that case a ‘guix pull’ would help.
<nckx>cyberban`: See (bash)Command Search and Execution, 3.
<cyberban`>ty :)
<nckx>‘command -v’ uses bash's exact algorithm to find commands. ‘which’ is a stand-alone executable that doesn't.
<nckx>Depending on what you want, one is better.
<nckx>There's also ‘type’ which is its own thing (includes shell functions? I forget) & I don't use.
<vagrantc>where is the process for generating the guix-VERSION.tar.* documented?
*nckx AFK a while, good luck Kolev.
<vagrantc>i'm trying "make dist" but ... not sure that's working fully
<M6piz7wk[m]>why does it say that `guix pull` does upgrading of the system when it just pulls the repos
<M6piz7wk[m]>> Download and deploy the latest version of Guix.
***xgqt_ is now known as xgqtd
***xgqtd is now known as xgqt
<singpolyma>M6piz7wk[m]: guix is not the system
<singpolyma>Guix is the command named guix
<M6piz7wk[m]>i know thus why am i asking
<M6piz7wk[m]>seems like bs description of the command
<singpolyma>Why? It's a 100% accurate description of the command
<M6piz7wk[m]>it doesn't do any deployment
<singpolyma>It upgrades the command `guix`
<M6piz7wk[m]>still same version to me
<singpolyma>Sure, it deplys it into the relevant profile for your use
<M6piz7wk[m]>hmm o.o
<singpolyma>I would say "upgrade" vs "download and deploy" but both are accurate
<M6piz7wk[m]>but it doesn't touch the guix command
<M6piz7wk[m]>just the repos
<M6piz7wk[m]>the guix command is upgraded through system reconfigure
<singpolyma>Yes it does touch the guix command. That's all it does
<singpolyma>There are no "repos"
<M6piz7wk[m]>upgrades the derivation, but not the backend then
<M6piz7wk[m]>since the version is same
<singpolyma>What does that even mean?
<singpolyma>It upgrades the command. Makes it a different version of the command
<M6piz7wk[m]>it's just updating the stored locally
<bitspook[m]>It tripped me too. I have guix install in nix, did guix pull, didn't make a difference. Turned out, the system path (something like /root/run) was overriding `$HOME/.config/guix/bin` in my `$PATH`.
<M6piz7wk[m]>singpolyma: hmm if you say so O.o i guess i wasn't in a scenario where it updated the version yet
<M6piz7wk[m]>how is that different from system reconfigure though
<singpolyma>It changes the then that runs when you type `guix` to be a different thing
<singpolyma>system reconfigure is for changing your system. I don't use system so I'm less useful there
*M6piz7wk[m] sent a console code block:
<KE0VVT>Guix seems slower than other systems.
<KE0VVT>Took forever to get to GDM.
<nckx>This is mean and dishonest:
<cyberban`>Yes, how would a DVD rack help?
<nckx>Smooth jazz rollbacks.
<cyberban`>I mean, how would it help with guix taking up lots of space
<nckx>Ahk, I keep confusing DVDs with CDs.
<cyberban`>DVDs are way slower than other types of drive space? and organizing hella DVDs sounds painful vs a few SSDs or HDDs
<nckx>cyberban`: It's called a joke.
*cyberban` laughs
<nckx>Well, I don't want to claim to speak for vivien, but what a way to distort some light-harted chat to make fun of others.
*nckx sad.
<cyberban`>Sorry, didnt mean to be a dick
<KE0VVT>Hm. Syncthing without systemd. That sounds hard.
<nckx>sneek: later tell cyberban: You weren't. If there were gold stars for people who were ‘not a dick, probably’, you'd totally get one.
<KE0VVT>nckx: I'm sorry I'm a dick.
<nckx>Then you get a gold star too.
<M6piz7wk[m]>staph talking about dicks i am trying to focus here -w-
<M6piz7wk[m]>hmph intentionally making me horny so that i can't fix my guix and will have to suffer for another 6 hours what a dirty tactics -w-
<nckx>Putting aside this grandiose ‘6 hours’ claim, why are you suffering?
<M6piz7wk[m]> basically
<M6piz7wk[m]>struggling to figure out how to replace the gdm with anything else
<oriansj>like slim?
<M6piz7wk[m]>also have to wait ages for this system to finish building anything u.u
<M6piz7wk[m]>oriansj: yep
<M6piz7wk[m]>i've used the config from manual
<M6piz7wk[m]>but didn't test it yet bcs it's still building
<M6piz7wk[m]>and i was too tired yesterday to figure out distributed builds
<vagrantc>guix isn't for the impatient, that's for sure. :)
<KE0VVT>Running Syncthing in a tmux session because I don't know how Shepherd and config.scm work.
<M6piz7wk[m]>i am like the definition of impatient -w-
<oriansj>M6piz7wk[m]: here is an explicit guix config: if you wanted total control and a faster setup
<oriansj>and it can be setup by a 1Ghz P3 in less than 2 hours
<KE0VVT>The ncurses installer is nice.
<KE0VVT>Newly installed apps don't have icons.
<oriansj>and I can provide a full steps procedure for setup
<M6piz7wk[m]>oriansj: thanks that seems very helpful
<excalamus>good evening, Guix
<M6piz7wk[m]>is the build distribution just making a /etc/guix/machine.scm file?
<nckx>KE0VVT: :) And about the icons, I think this is due to how most desktop environments assume and cache things. This will eventually be fixed when someone submits a patch to fix their favourite one, but until then they should show up when you next log in.
<nckx>Hi excalamus.
<oriansj>M6piz7wk[m]: here are the steps: (including vm steps to test it before deploying to your machine)
<M6piz7wk[m]>x.x where were you yesterday that would safe so much work x.x
<oriansj>did you wish to download binary substitutes? or are you building only from source for trust reasons?
<nckx>M6piz7wk[m]: Here's roughly how you'd replace the display manager:
<oriansj>because the binary substitutes route is much faster
<M6piz7wk[m]>nckx: i did the slim setup but it kept throwing errors and i couldn't figure out what was causing them yesterday x.x will check once the build finishes (says 96%)
<M6piz7wk[m]>oriansj: yep i should be using those, but it's still building a lot of things
<nckx>I haven't used slim much either.
<nckx>I always enable auto-login for any DM so I don't know what any of them look like 😛 Only that SDDM works, reliably, hence I keep it.
<oriansj>slim works fine IF and only IF you don't plan on using Wayland or sway as your desktop
<oriansj>it works great with i3, xmonad, gnome and kde
<nckx>That was my luck, then.
<oriansj>yeah, it is impossible to get slim to work with wayland or sway; the lightest next option is: lightdm
<oriansj>which does work with wayland and sway
*M6piz7wk[m] 's system halted at 96% upgrading after 4 hours runtime
<oriansj>M6piz7wk[m]: doing it from install disk or setup system?
<M6piz7wk[m]>after guix install iso
<M6piz7wk[m]>i need to setup distributed build this thing lacks the resources for the compilation x.x
<oriansj>the step 4 in the instructions really matters if you are building from source
<M6piz7wk[m]>from binaries, but it's 32-bit and guix seems to lack prebuilds for it
<oriansj>as herd start cow-store /mnt/ will enable you to use the disk space rather than be limited by amount of RAM; which easily could limit your ability to setup your system.
<M6piz7wk[m]>i am past reboot already, but i have issues with gdm and the system failing to do guix pull and system reconfigure
<oriansj>ok, go to the terminal
<M6piz7wk[m]>so ehh how do i setup distributed builds? x.x
<M6piz7wk[m]>oriansj: yep? i have ssh
<oriansj>and the amount of free disk space?
*M6piz7wk[m] sent a code block:
<M6piz7wk[m]>+- 100GB
<vagrantc>you can offload builds to another machine that's running guix ... there's documentation in the manual for setting that up
<M6piz7wk[m]>ah offloading
*M6piz7wk[m] was searching for distributed
<oriansj>well distributed would be the IPFS or GNUNET binary distribution channels but I am not up to date on their progress (last I checked they were not quite ready)
<vagrantc>never quite liked that offloading had to have both machines trust each other to write things to the store
<M6piz7wk[m]>yep offloading should work i think
<vagrantc>ssh somefastmachine "guix time-machine --commit=$(guix describe | awk -F 'commit: ' '/commit/{print $2}') -- build somepackage" ... and then set up guix-publish on the faster machine
<vagrantc>then you only need the slow machine to trust the fast machine ...
<vagrantc>at least, for writing things to the store
*M6piz7wk[m] sent a code block:
<M6piz7wk[m]>i have no idea what any of that means x.x
<vagrantc>it's just a hack to work around what i don't like about offloading
<M6piz7wk[m]>vagrantc: i meant that i don't understand what guix complains about with my config
<vagrantc>ah, your client just posted a URL that i didn't bother to click on
<M6piz7wk[m]>it's long >.>
<M6piz7wk[m]>should be a raw file though
<M6piz7wk[m]>want me to put that on paste debian or something
<M6piz7wk[m]>hmm x.x
<M6piz7wk[m]>it said to do guix pull and reconfigure
*M6piz7wk[m] is doing that
<apteryx>vivien: you may want to enable Btrfs zstd compression if you're using Btrfs; it'll give you a nice extra and perhaps make IO faster in the process.
<M6piz7wk[m]>> process 961 acquired build slot '/var/guix/offload/'... (full message at
<bdju>has anyone managed to track down the issue with the broken audio in qutebrowser yet? issue #45280
<apteryx>does someone know what xorg-server's --with-xkb-output is used for?
<apteryx>(configure flag)
<M6piz7wk[m]>xkb refers to keyboard configuration afaik
*M6piz7wk[m] can't figure out how to set up offloading in a sane way as it needs user input for ssh key and user password
*M6piz7wk[m] nuked /etc/guix/machines.scm and goes to practice patience
<vagrantc>you need to set up passwordless ssh keys
*vagrantc waves
<M6piz7wk[m]>and configure ssh daemon to accept pubkey only
<M6piz7wk[m]>thus the no idea how to do that in secure way
<apteryx>M6piz7wk[m]: the manual says that offloading requires non-encryted keys (passwordless)
<M6piz7wk[m]>yes, but that seems insane to do
<apteryx>I think it just fails on encrypted keys
<apteryx>there's probably a way to have guile-ssh/libssh use the ssh-agent (it may well be the default behavior) -- perhaps something to tweak. If you change the behavior you'd need to adjust the doc and probably output a warning upon use (as it'll hang when the key expires in ssh-agent)
<M6piz7wk[m]>i added it to my todolist and suffer in the meinwhile
<bdju>are ssh keys without a password really that bad if they're unique per each machine?
<wleslie>why would ssh keys without a password be bad?
<wleslie>they are best practice, afaik
<apteryx>no they aren't
<wleslie>go on
<apteryx>they give you some time to lock your remote accesses if the key get compromised (e.g., the laptop gets stolen)
<wleslie>if your laptop gets stolen, and you don't have full disk encryption, and your session is unlocked for some reason, but fortunately for some reason your ssh agent won't just give the theif what they need?
<wleslie>s/and your/or your/
<apteryx>If your laptop is protected by another mean (and I agree that LUKS is a must), my example is kinda moot yes
<apteryx>it just seems to be a good practice in general to put passwords on sensitive stuff
<apteryx>and so saying something like "not putting password on SSH keys is considered best practice" sounded off to my ears :-)
<M6piz7wk[m]><bdju> "are ssh keys without a password..." <- it's bad in case the machine is compromised as the attacker then gets root ssh to all systems
<wleslie>the impression I've gotten is that the cognitive overhead of being asked for passwords on a regular basis leads to workarounds that are worse than the original problem
<wleslie>if the machine is compromised, you just replace PAM with a keylogger and wait
<wleslie>it's rather a case of being on the other side of the airtight hatchway
<M6piz7wk[m]><wleslie> "the impression I've gotten is..." <- i prefer them handled through CI/CD for push-based deployment
<M6piz7wk[m]>but my solution is not stable enough for that
<wleslie>ok, I see, you're configuring offloading
<wleslie>and you fear that if you distribute a key to all the clients that potentially need to offload builds, that one of those will be compromised
<wleslie>or s/a key/many keys/, if you want independent revocation
<wleslie>but the important thing is you don't want those clients to be able to do anything other than request a build?
<wleslie>at least, using a passwordless key
<wleslie>because I guess that can be done, you can have the user accessed by that key be effectively nobody; and you can have a different hostname in .ssh/config to access that server with the correct user and key
<wleslie>e.g. Host guix-build; IdentityFile ~/.ssh/build; User guix-offload; HostName
<apteryx>M6piz7wk[m]: offloading doesn't require root
<apteryx>('guix deploy' does though (or passwordless sudo), but it's something else)
<M6piz7wk[m]>passwordless sudo is still root elevation just with extra steps that increase the complexity of the implementation
<M6piz7wk[m]><wleslie> "but the important thing is you..." <- setting up a non-root user that can only request build would be acceptable solution
<apteryx>M6piz7wk[m]: again, offloading doesn't require root, if thats all you're after
<M6piz7wk[m]>oh how do i set it up to not require root then>
<M6piz7wk[m]>like does the user have to be in some group or something? since it seems to be failing on non-root
<M6piz7wk[m]>ehh like do i have to set up the alternative to nix-build users ?
<brendyn>anyone have an example i can copy from on how to bisect guix to find when a package broke?
<apteryx>M6piz7wk[m]: no, it's like doing 'guix build foo' as your user
<apteryx>it doesn't need root
<apteryx>you specify the user field in your build-machine record
<apteryx>then you 'guix offload test' it
*apteryx goes afk
<efraim>morning everyone!
*apteryx goes bed
<apteryx>efraim: o/
<efraim>I submit my 465G /gnu/store on btrfs with daemon deduplication
<M6piz7wk[m]><apteryx> "you specify the user field in..." <- eh? There are no permissions needed to give the user access to the store?
<efraim>M6piz7wk[m]: here's mine for comparison:
<M6piz7wk[m]>i see.. still kinda uncomfortable as i would prefer to explicitly specify which users can make build requests to the nix daemon
<M6piz7wk[m]>seems like a security issue waiting to happen
<brendyn>i guix gc'd about 500gb the other day
<brendyn>after my ext4 complained about not enough space trying to make symlinks
<vivien>sneek, later tell civodul
<vivien>Hello guix :)
<M6piz7wk[m]>is there a way to deny the user to be able to interact with guix command?
<M6piz7wk[m]>or like prevent them from writting in the store?
<vivien>M6piz7wk[m], a few months ago, someone told me it was possible to change the permission of the guix daemon socket
<M6piz7wk[m]>there is a guixbuild group for /gnu
<M6piz7wk[m]>vivien: where is the socket
<vivien>Ah I understand
<vivien> /var/guix/daemon-socket/socket
<vivien>I was puzzled because the message was censored
<M6piz7wk[m]>that's owned by root:root on my end
<vivien>But in fact, no, it’s just that starting a message with / on IRC does not publish the message
*M6piz7wk[m] confused
<vivien>Anyway, try to change the permission for the socket to: read and write for the group, nothing for the rest, change the group to the group of authorized users, and put yourself into that group
<vivien>(I tried to type only "/var/guix/daemon-socket/socket", but since it starts with a /, my client thought it was a command)
<vivien>(so it did not publish the message, leaving me wondering whether that was censored)
<M6piz7wk[m]>kreyren@leonid ~$ guix shell emacs
<M6piz7wk[m]>hint: Consider passing the `--check' option once to make sure your shell does not clobber environment variables.
<M6piz7wk[m]>guix shell: error: failed to connect to `/var/guix/daemon-socket/socket': Permission denied
<M6piz7wk[m]>seems to work
<vivien>Yay !
<M6piz7wk[m]>why is this not default and set for guixbuild
<vivien>Because then most users won’t be able to install any program, which is bad.
<vivien>(I hope you didn’t accidentally lock yourself out)
<M6piz7wk[m]><vivien> "Because then most users won’t be..." <- which is great? So that only users with the user group can interact with the socket?
<M6piz7wk[m]><vivien> "(I hope you didn’t accidentally..." <- i just did 660 so that only root has access to it
<vivien>Interacting with the socket is required for almost everything, including running guix shell
<vivien>as you saw
<M6piz7wk[m]>why would the non-root user ever needed access to that
<M6piz7wk[m]>like non-root being able to use guix shell seems like a way to inject things in the store
*M6piz7wk[m] created
<kittyblam>yo, is there any quicker way of opening recent build logs then just manually typing the first few letters and then tabbing and whatnot?
<jpoiret>M6piz7wk[m]: users being able to install programs as non-root is actually a *feature* of guix, not a security hole
<vivien>M6piz7wk[m], if you "inject" a file into the store, it can’t appear in an environment variable for another user, for instance
<jpoiret>i'd consider having rogue programs running on your machine a security hole, rather (and I'm not sure they'd use "guix shell" to cause any damage)
<M6piz7wk[m]>jpoiret: i know it's a feature, but why is it sane to allow everyone to use the guix daemon?
<jpoiret>because using the guix daemon cannot tarnish another user's environment, as vivien said
<M6piz7wk[m]>like as a sysadmin i prefer my users to have no rights and require them to request permissions on the system
<M6piz7wk[m]>e.g. I need nano give me access to the socket
<M6piz7wk[m]>So that instead of giving them access to the socket i can install nano for them
<vivien>In other distributions, if you install nano for a user, all users will have nano
<M6piz7wk[m]>not on guix
<vivien>In guix, that’s not the case, so each user can install whatever they want without the other users being bothered
<M6piz7wk[m]>jpoiret: eh why not
<kittyblam>try to ignore M6piz7wk. the other day they where starting random arguments in #fsf.
<M6piz7wk[m]>kittyblam: not random
<kittyblam>anyways, anyone know a more efficient way to open build logs for guix than just manually typing and tabbing through the directory?
<M6piz7wk[m]>vivien: guix daemon can write in root files no? so theory being user trigerring a build that writes in /etc
<M6piz7wk[m]>since afaik that's why nixOS handles the access through a group
<jpoiret>it cannot, build processes are run in namespaces that can't access anything
<vivien>You can only write in /etc if you are doing a system reconfigure, and guix requires you tu use sudo to do thatj.
<jpoiret>they don't have internet access for example, filesystem access
<jpoiret>the way `guix system reconfigure` works is first by letting the daemon build the system's derivation in the store, and then the command itself (ran as your own user) copies everything in the system
<jpoiret>this is why you need sudo to run it
<M6piz7wk[m]>i see
<M6piz7wk[m]>can't user trigger an altered e.g. sed build that then gets cached for root to invoke?
<jpoiret>no, because items in the store are identified by their store name + hash of derivation
<M6piz7wk[m]>but guix prefers the cached derivation no?
<jpoiret>so unless you can cause a meaningful sha256 collision for derivations (if so, then please let us know how :) ), you won't pollute anything
<jpoiret>if you want to change how the build is done, you need to change the derivation, so you'll change the store output
<M6piz7wk[m]>i see and the non-root can't alter the domain name resolution to fool guix into thinking that the latest derivation is the altered one right?
<jpoiret>i don't understand what you mean
<jpoiret>derivations are computed from package declarations in the guix source code
<M6piz7wk[m]>guix is looking for the hashed derivation right? it does that by checking against the guix repo.. So if non-root can alter the domain name resolution it could fool guix into thinking that the altered derivation is the expected hash?
<M6piz7wk[m]>e.g. if the system is using dhcp that could be altered by the router?
<jpoiret>if the derivation changes, the hash of the output of the derivation changes
<jpoiret>also, builds happen in an environment outside of the user's control, so it shouldn't be possible to control anything that happens there
<vivien>If you can alter the git repository for guix, first you need to sign the commits with the maintainer’s key.
<vivien>Even the malicious ones.
<jpoiret>see for the git authentication process
<M6piz7wk[m]>i see, ok seems sane
<M6piz7wk[m]>still would argue for the group to be a good idea for production systems as multiple users doing guix build will probably overwhelm the system resources
<jpoiret>see for more info about the model Guix/Nix follows
<M6piz7wk[m]>and especially if it's something like 5 users needing nano that can be installed for them in a controlled manner?
<M6piz7wk[m]>jpoiret: i read that already thus why i was concerned
<jpoiret>if the 5 users want the same nano, then they'll use the same nano
<jpoiret>without having to build it 5 times
<jpoiret>M6piz7wk[m]: then I don't think you read that carefully because there's most of what we just said in it
<jpoiret>there are example of possible attacks and how this model prevents them from working
<M6piz7wk[m]>i guess.. just seems weird as in production i was always told to revoke everything from the user and give them only what they need
*M6piz7wk[m] can't think of anything else in his threat model so he goes to setup a offloading
*M6piz7wk[m] * can't think of anything else in his threat model so he goes to set up offloading
<jpoiret>in other news, guix time-machine is great! allows me to keep working on master when i'm running core-updates-frozen, with the likes of "guix time-machine -- shell --pure -f /tmp/program.scm -- program"
<vdv>mh even with running the garbage collector and pull & reconfigure regular my filesystem is getting bigger and bigger
<vdv>(beginning with 8 GB, now after a few garbage collecting and pulls 16gb)
<vdv>is there a way to garbage collect all the trash? :D
<jpoiret>guix gc without any arguments should collect all garbage afaik
<vdv>i have hell lot of /var/guix/profiles/system-XX-links 1-20
<jpoiret>vdv: apologies, you should delete old profiles
<vdv>it does not get garbage collected
<vdv>aah how?
<jpoiret>yes, profiles have to get deleted manually (you may want to roll-back to them)
<jpoiret>since they're gc roots, anything installed to those profiles will also never be deleted
<vdv>mh, but i expect them to be garbage collected with the profiles together :D but nvm
<vdv>how do i delete them manually?
<jpoiret>you can use `guix system delete-generations` for the system generations
<vdv>let's try :) ty
<jpoiret>be careful, by default it deletes every generation other than the running one, you might want to keep others for reasons
<jpoiret>also `guix package --delete-generations[=PATTERN]` for user profiles
<vdv>alright ty! that worked :)
<vdv>it would be nice when guix gc would delete all system generations too without the last 3, and with a command line options none or all but one :) but maybe it's just me :D
<brendyn>vdv, thats would not be nice
<brendyn>deleting system generations is actually reconfiguring your operating system essentially. deleting other generations is not collecting garbage
<nckx>You can create, e.g., a ‘guix-gc’ script that invokes, e.g., sudo guix system delete-generations && sudo guix gc -d 1w if that's what you want. Doing it by default would silently destroy data (not ‘garbage’ :) so best not.
<brendyn>garbage are things that aren't used at all by anything
<vdv>mh i'm not using my old generations anymore, just backup the last 3 if something breaks in the new one.. :D but depends on guix system usage i think
<vdv>i'm doing it in a alias atm @nckx but thanks :)
<jpoiret>by default i don't think it should delete valid rollback targets
<nckx>Fine too of course.
<nckx>vdv: Just because it doesn't make sense as a default doesn't mean your use case isn't perfectly valid. But hey, that's what aliases are for.
<jpoiret>can't even see the build failure
<nckx>M6piz7wk[m]: So can #51833 be closed? I can't see a security issue at all, and it seems like calmer discussion prevailed. It would be nice if that happened before opening a sensationalist ‘bug’ report next time.
<nckx>Is that blank for you too?
<jpoiret>i guess i'll have to spin up a cuirass instance and maybe work a bit on it
<xelxebar>nckx: That URL is returning 404
<jpoiret>because i think cuirass itself has been slowing down development on c-u-f
<nckx>I'll report a bug jpoiret.
<nckx>xelxebar: ☝
<jpoiret>i get a plain 500 xelxebar
<jpoiret>a 404 wouldn't be blank
<xelxebar>At least with `curl -LI`, I'm seeing 404
<jpoiret>oh, weird then. Definitely a 500 on my end with firefox
<nckx>jpoiret: Are you sure? Why would Firefox not display the page if its 404 but would if it's 500?
<jpoiret>no but cuirass's 404 page actually displays something (i checked the network tab and it really is 500)
<nckx>You're right though, it's a 500 in FF.
*nckx shrugs.
<xelxebar>Interesting. I see 500 in FF as well...
<nckx>curl -LI sends a HEAD request, FF a GET. That'll be it.
<jpoiret>i'm worried though that i won't be able to replicate the bugs on a local cuirass instance though :(
<nckx>I've noticed that a lot of Guile (and other home-grown in general) Web servers handle HEADs & GETs wildly differently.
<xelxebar>500 with curl -v
<nckx>It's tripped me up whilst debugging TLS certs before.
<nckx>And I've not noticed it on nginx proper.
<M6piz7wk[m]><nckx> "6piz7wk: So can #51833 be closed..." <- it can be closed, i didn't expect people to be willing to discuss it here and i prefer the issue filled to be used as a reference in my threat modeling
<nckx>People are always willing to discuss things here but it has to remain friendly & pleasant, and your style borders on the opposite (sometimes crossing over altogether). Several people have made this clear. I wonder if you could tone it down; it has been distracting for many.
<rekado>I’m building ghc on core-updates-frozen and I feel mocked by the persistent 100% progress bar. Since three hours.
<vdv>since deleting my 20+ system profiles my pull, gc and reconfigure is waaaaay faster
<vdv>ty all
<nckx>vdv: Interesting, I haven't used systems/file systems where it would have that effect (just saves space here), but cool!
<vdv>maybe it checks all the links in some progress? don't know why
<vdv>and someone said the creating of man database after reconfigure is deactivated and you need to activate it manual, but it still automatic rebuilds it at my machine
<nckx>From memory, it should only do that explicitly during GC, but of course the kernel will be doing more work scanning a huge directory even if you give it a name. And how much work depends on the fs and how it's configured (dir_index etc.).
<nckx>(Checking links ☝)
<nckx>That was not a recommendation to use dir_index, I forget if that's the one that can sometimes be problematic or not.
<nckx>vdv: Mm, where did who say that?
<vdv>i search the logs, was a discussion a few days ago
<vdv>relatively new patch to save some time
<jpoiret>i don't think it's in master yet
<vdv>because the db is just for man -k
<nckx>Aside apologies that our Web log search is probably still broken.
<vdv>ah alright
<nckx>Ah, that makes more sense, thanks.
<nckx>Then I'm not confused :)
<xelxebar>Blah, guix pull gets sigkilled on my shiny new vm. 1G of mem is not enough, I guess :/
<nckx>xelxebar: Nope ☹
<xelxebar>What's a reasonable minimum?
<vdv>but it's possible to run the daemon and push to it, am i right?
<vdv>used it on a slow vps if i remember correctly
<nckx>In ~2015 I ran Guix on a VPS with 256M (+swap) RAM but it became unfeasible.
<jpoiret>i feel like if you need to build anything at any point you'll need swap
<vdv>with guix deploy
<nckx>xelxebar: I can't say. You could play around with the -m argument to a QEMU VM to test.
<nckx>‘guix deploy’ is a very good suggestion.
<nckx>But it would make me slightly nervous to run a VM/VPS that can't service itself, so to speak.
<nckx>Probably just me; I'm still stuck in the ‘pet’ camp.
<xelxebar>Yeah, I'm actually starting to write a new deploy host. Just sanity testing at the moment.
<xelxebar>BTW, is there a guile library for working with swagger apis?
<nckx>Better ask in #guile as well but I doubt it.
<bost>Hi. Is there Guile library or a code snippet for reading .git/config files?
<xelxebar>bost: It's basically ini file format, no? However, I don't see anything promising with guix search nor ddg.
<bost>xelxebar: yeah, it seems to have the ini format.
<bost>xelxebar: what is ddg?
<bost>according to the best is the and it's even in the FSF catalog, however not among the guix packages.
*bost seems like I *really* have to learn how to create guix packages. Sigh
<xelxebar>bost: ddg -> duckduckgo :D
<vdv>mh if i inherit the version of a mainpackage and a dependencypackage in one file, how to make the inherited main package recognize the updated dependency within (inputs) ? without including all other inputs at best.. :D
<xelxebar>bost: `guix search '\<INI\>'` turns up some results. In particular, if you're willing to do FFI, then "iniparser" might be worth looking at.
<pinoaffe>could someone take a look at and ?
<vdv>ah like this (inputs (alist-delete "guile (package-inputs gdb)))
<jpoiret>vdv: you may want to use package-input-rewriting from (guix packages)
<vdv>ah thats better :)
<jpoiret>if you're trying to use it locally, if it's for a guix patch then you should write it by hand imo
<jpoiret>like you did
<jpoiret>maybe you already know that but inputs are also not the association lists you might think they are, assq-ref the-inputs "guile" will return a list with guile as its sole member
<jpoiret>that's because it's ("guile" ,guile) and not ("guile" . ,guile)
<xelxebar>I notice that there's a xen package. Is anyone here running guix on top of xen?
<xelxebar>It kind of looks like the package exists, but there's not yet provisioning support.
<drakonis>xelxebar: well... guix as dom0 hasnt been tried or documented yet?
<xelxebar>Yeah, that's what I suspected. dom0 guix would be slick!
<M6piz7wk[m]>please say yes i need it
<M6piz7wk[m]>it is normal for guix to be stuck at `building /gnu/store/...-guix-packages-base.drv...` on 53% for 4 hours
<jpoiret>if I want to send a patch that fixes a bug, should i send it to guix-patches or just reply to the mail to bug-guix with the patch?
<jpoiret>i don't think so. That should be the most computation-intensive task of guix pull though i think
<nckx>jpoiret: Reply.
<nckx>The separation is not that strict in practice (and arguably non-existent in places).
<KE0VVT>I'm using the GNOME configuration provided by the installer. I notice there is a lot of junk printed to the screen during startup. Is there any way Plymouth could cover all of that up?
<KE0VVT>Fedora also has a nice-looking password prompt for LUKS decryption on startup, but Guix does not.
<M6piz7wk[m]>the load indicator is blinking so i guess it's doing something
<M6piz7wk[m]>this is 1Ghz notebook
<jpoiret>ok, thanks! should i use a scissors line to separate the mail from the patch? i've seen people using mime parts and stuff nckx
<jpoiret>my mail-foo is severely lacking
<nckx>My preferences in order: (0) git send-email (1) MIME attachment (99) anything else.
<jpoiret>KE0VVT: we don't use plymouth by default, so no password prompt either
<nckx><Is there any way Plymouth> Sure it could.
<nckx>It's packaged, but that's it.
<nckx>You'll first have to define a static variant to better integrate in the initrd, then hook it up in boot-linux etc.
<jpoiret>hmmmm. This calls for changes to the initrd :) i've been postponing finishing my mail to guix-devel about an operating-system/initrd rework
<vdv>i have (flags '(no-atime))(options "discard")) i n my file-system def, something else adviced to use on a btrfs nvme ssd? :)
<jpoiret>is it a flat btrfs or btrfs in luks?
<nckx>I don't use btrfs but perhaps chattr +C on /var/guix/db before anything is created there (or before copying the contents back & forth) might somehow reduce its fragmentation.
<nckx>OTOH it's 290 extents here without +C, which is not excessive.
<nckx>This is not Guix-specific, though, and there might be other {database,} files that would benefit from that.
<KE0VVT>nckx: Ouch.
<KE0VVT>nckx: “You'll first have to define a static variant to better integr…”
<nckx>What's ‘ouch’ about that?
<nckx>There are various examples, such as most if not all file system tools packages (e2fsprogs, btrfs-progs, … all have static variants).
<nckx>It shouldn't be ‘too hard’ :)
<jpoiret>you'll be able to contribute plymouth support for everyone (yay more guix eyecandy), nothing ouch in that :)
<nckx>If you do get stuck, help is available.
*M6piz7wk[m] :(
<nckx>Not that you hard-need Plymouth to get a prettier boot, by the way; the built-in Linux boot logo support (the thing that prints those ugly penguins by default) can get you most of the way there:
<nckx>The console text is optional, if it bothers one.
*nckx AFK.
<jpoiret>though for the pretty password prompt, that'd be necessary
<bost>I'm reading the "Running Guix Before It Is Installed". It says "Then, run ‘./configure’ as usual.". So I start `./configure`.... and then the next sentence is "Make sure to pass
<bost>‘--localstatedir=DIRECTORY’" !?!?! :-(
<rekado>I have some WIP plymounth stuff. But the debug cycle is just too long to let me finish it.
<jpoiret>bost: ./configure is very fast so no worries, but i agree that this is bad wording
<jpoiret>rekado: debug cycle?
<bost>That's like: step 1. shoot! step 2. make sure you're using live ammo.
<jpoiret>it seems to me that you could just `guix system vm` your way out of there, right?
<rekado>jpoiret: I need to fiddle with the code that generates the initrd, and rebuilding it every time I make a change is tedious.
<bost>step 3. ... or not live ammo. (it depends)
<rekado>there’s a surprisingly large number of derivations that need to be built
<jpoiret>weird. I would've said that only the initrd would need to be rebuilt… i guess i'm wrong on that
<bost>jpoiret: I guess I can't send a patch fixing this wording until I compile everything, right?
<jpoiret>you can just do make doc/, check it's right, send the patch, and compile the rest afterwards
<bost>jpoiret: how can I check if it's right if I can't see it. I mean I need to compile and install my guix for that in the first place. (and that will take some time, I guess)
<avp>Hello Guixers, I just came across this project:
<jpoiret>you can compile just the .info file with `make doc/` and view it with your current info viewer with `info -f doc/`
<bost>jpoiret: ah ok. thx.
<jpoiret>also, you should not need to install your guix imo, just use ./pre-inst-env to test
<jpoiret>(that's in the same info node you were reading)
<avp>According to the author, it can be used for building workflows for CI services that support Docker (like GitHub, GitLab, ...)
<nckx>jpoiret: Don't use (which …) to capture build-time file names to then embed them into a binary or script. That breaks horribly when cross-compiling. Construct a proper PATH by iterating over the inputs.
<nckx>Also, adding glibc as an input makes no sense.
<jpoiret>nckx: we need the locale binary of glibc
<jpoiret>for the other comment, well, whoopsies :p i was looking at other wrap-programs and that's how they were doing it, i had already written the proper code before that
<jpoiret>but now that you're talking about that, of course that'd be wrong
<nckx>They all need to be fixed.
<jpoiret>i'll send a v2. Are we ok on the glibc dependency though?
<nckx>Inputs are not dependencies (I know this is not your claim, but the submitter seems to think they are).
<nckx>jpoiret: Yes that's fine.
<jpoiret>nckx: do you mean that we shouldn't add add inputs for the needed commands, and let the user install them alongside? i don't follow
<nckx>Depends IMO on how hard the programme fails without them, but no, your list is probably fine. I'll defer to you on that.
<nckx>Just to make sure I'm not missing anything: s/paths/path/, right? It's just a path, not some kind of meta list of paths?
<nckx>jpoiret: Changing the build system, if we do, should be done in a separate patch. This does too much. One functional change per commit.
<jpoiret>it is a list of paths if i'm not mistaken, i just map over the binaries (i'll now map over the inputs instead)
<nckx>Well, we set PATH to it, so it should just be a single search path.
<nckx>I mean, I think it already is, just the name is misleading.
<nckx>Not important.
<jpoiret>as to how much it fails without the commands: sed and coreutils are needed for it to start, and iproute, procps and awk are needed for its default displays (otherwise there's nothing in them)
<jpoiret>the wrap-program arguments is specifically made to take lists of paths, which are joined by the specified separator, so i think it's better this way, no?
<nckx>It takes a single path.
<nckx>I think I'm just misunderstanding you.
<nckx>I mean it takes a path which is a list of file names. ‘paths’ to me means a list of lists. You are obviously not meaning it this way.
<jpoiret>oh, so you meant path === list-of-directories?
<nckx>So I think ‘path’ is better but this is really ridiculously minor and distracting that the patch LGTM apart from the build-system switch.
<jpoiret>i agree that the search-path denomination for a list of directories is very misleading, aha
<nckx>Well, it's the standard Unix name (e.g., $PATH 😛), so it's better to be consistent.
<jpoiret>bikeshedding time! now that i'm subscribed to i get to see all the bikeshedding that goes on in the linux mailing lists, and i wonder how they're able to go anywhere that way
<nckx>When young I made the mistake of subscribing to LKML.
<nckx>For, like, a day.
<nckx>Sweet gods.
<jpoiret>i'll just remove the build system change, not worth it now that i think about it (and if they add new thing upstream in the makefile it'd just be stupid to revert that change)
<nckx>jpoiret: It's fine on its own if you can ‘defend’ it! It just shouldn't be mixed into unrelated changes.
<nckx>I just wonder if the gnu-build-system has any drawbacks here and if we might benefit from its default phases. I didn't compare the outputs of both yet.
<jpoiret>ofc, but i cannot :p the me of this morning probably was feeling like changing a build system, but i won't take responsibility for him
<jpoiret>make install is really just cp + chmod
<nckx>With my arguing cap on I'd say that's true of most Makefiles with a gcc call thrown in, but upstream could decide to add something tomorrow, and we'd desync for no good reason.
<nckx>Doesn't mean what you said is untrue.
<nckx>Guile is cool and Guix can tend towards the NIH on occasion but we should probably use Makefiles if present 😉
<jpoiret>yes, let's not overdo it with minimalism and just keep to sane defaults (gee, i wish building this bash script in guix took 0.03 less seconds, said no one ever)
<nckx>jpoiret we are building the most beautiful bikeshed it will be glorious.
<tissevert>hi guix
<nckx>Hi tissevert.
<jpoiret>can anyone run `guix system image -e "(use-modules (gnu system install)) installation-os"` for me? I get an ABI mismatch error for file-system in a clean make local checkout
<jpoiret>whereas when doing `guix system gnu/system/install.scm` it works ok
<nckx>I can't get the bashtop test suite to pass: ‘ERROR: No UTF-8 locale found!’, wonder if that's related.
<jpoiret>with or without the patch? if without, yes that was the initial error
<nckx>Without. I haven't tried wrapping it yet.
<bdju>has anything changed with the neovim package lately? It's still an old version, but one of my vim macros doesn't work the same anymore
<jpoiret>it uses the locale binary from glibc to find locales iiuc
<nckx>But ‘locale’ is in $PATH and glibc-utf8-locales in native-inputs, I don't see how wrapping would fix it.
<nckx>I'll still try, but I wouldn't understand what's going on if it helps.
<jpoiret>how do you know they're in the path in the build env?
<nckx>(display (which "locale"))
<jpoiret>very nice indeed. Sometimes i forget about printf debugging
<nckx>Heh :)
<nckx>It is my cross-language crutch.
<nckx>‘GDB is nice, I guess, probably.’ —nckx
*tissevert is up to date
<jpoiret>unrelated: doesn't grafting break the promise that .drv -> store output is deterministic? If i graft something on top of an already existing package that someone else also uses, won't it also change the version that the other user sees?
<tissevert>over ten minutes Oo there are so many marvels on this chan
<nckx>Wrapping before the 'check phase didn't help.
<nckx>Grafts don't modify existing store items in-place, they create new (copied + grafted) store items with a different hash.
<tissevert>nckx: you said you used sway, do you install it system-wide or in your user profile ?
<nckx>/gnu/store/123vulnerable9-hello-1.0 gets grafted to /gnu/store/321fixed0-hello-1.0. /gnu/store/123vulnerable9-hello-1.0 remains untouched in the store.
<tissevert>I installed it in my packages in a VM but it looks like it didn't take my layout
<nckx>Free for others to use. Until they update their Guix & packages (hopefully soon).
<jpoiret>oh, alright. That means that the dependents need to be grafted as well, right?
<nckx>The entire subtree is grafted.
<nckx>tissevert: Sway is in my system package list and SDDM launches it with (auto-login-session "sway.desktop").
<jpoiret>tissevert: you need to install WMs system-wide if you use a DM, otherwise they won't get picked up. If you start them from a shell though you won't need to
<nckx>The same sddm-configuration contains (xorg-configuration (xorg-configuration (keyboard-layout keyboard-layout)))
<cbaines>Savannah isn't liking SSH for me, seems to prompt for a password. Does something like ssh work for anyone else?
<tissevert>jpoiret: yeah I had gathered that much, but then I read from people coming all the way through, and installing xorg user-wide
<nckx>cbaines: It's not ?
<jpoiret>with the advent of guix home, we could simply move WMs to user profiles. Need it to stabilize a bit first though
<nckx>tissevert: I don't know (and wonder) how they set their keyboard layout.
<tissevert>actually, I'm still struggling with stupid issues with theming, and getting my panel not to fight too much with my WM… so I'm experimenting a bit and considering sway as an option
<lilyp>nckx: apropos grafts, do we have a concrete proposal w.r.t. double grafting?
<tissevert>nckx: probably just setxkbmap
<tissevert>I do it all the time when I'm in hostile territory
<nckx>Not that I'm aware, lilyp, but I haven't been around as much as I'd like. I've been missing things.
<cbaines>nckx, ah, thanks, that seems relevant
<jpoiret>tissevert: you won't like sway very much then :) setxkbmap doesn't work on wayland
<tissevert>no of course it doesn't
<tissevert>which is why I was wondering how knowledgeable people did it
<jpoiret>I just can't bother looking into configuration with intel tearing problems and whatnot, so wayland is the way to go imo
<tissevert>I know my first approach was flawed because I can't get anything remotely useful / pretty to run, except xfce + xmonad
<tissevert>and they're still fighting a bit when xmonad starts
<tissevert>since I was giving sway a very simple spin to see if it ran at all yesterday, I simply noticed that keyboard thing and made a note to ask if it was just the way sway was expected to run, and someone would have answered me to fix this in sway/config (and I'd have been disappointed)
<tissevert>but now I know the "clean way" I expected to work does indeed work
<tissevert>which is a good thing and prompts me to experiment some more
<tissevert>now I'm curious about what kind of tools I can reasonably expect to work in it
<nckx>God doink it people, don't do this:
<nckx>Don't silently hard-code strings and then encode the not-recommended one.
*nckx now looking at… a white terminal, which appears to be the bashtop test suite.
<jpoiret>alright, have to step out for a bit
<tissevert>see ya jpoiret
<jpoiret>just hit the GLIBC_VERSION 2.33 not found error while doing something else, will report on it
*nckx is beginning to dread and/or wonder if ‘the bashtop test suite’ is just ‘start bashtop’…
<jpoiret>nckx: you have to look at the tests/ directory and look at the tests :) it's quite fun
<nckx>I am doing so now.
<nckx>Your amused and slightly evil tone does not bode well. 😉
<nckx>I did not sign up for fun, I do not want fun, fun and bash are never fun.
<nckx>I think I see what you mean.
<tissevert>nckx: may I ask guidance on GTK themes in sway ?
<nckx>I don't use them, sorry.
<tissevert>because you use only Qt applications ? or because your GTK ones look with the default angular windowsy look ?
<nckx>The latter
<nckx>I spend 90% of my time in Emacs or foot. The other % are probably HexChat & Firefox & I don't much care how they look.
<tissevert>ok same look as here, indeed : )
<tissevert>oohh I'm displayed in green ! that's so cool because it matches my name
<nckx>Only when you highlight me, I'm afraid, otherwise you're purple (which does match green quite well IMO, so not all is lost).
<nckx>See? Theming.
<tissevert>; )
<roptat>hi guix!
<roptat>tissevert, you're purple for me too :)
<tissevert>hi roptat !
<tissevert>why do people see me purple ?
<roptat>probably because we use the same software
<roptat>or at least the same algorithm to give color to nicks
<tissevert>this is preposterous, I demand green of the greenest kind
<nckx>Here it's just coincidence; colours are different each session, so you'll eventually be green. And then, you won't. That is life.
<tissevert>let's a define a "good day" as a day when I'm green : )
<podiki[m]>tissevert: is green on Element for me :-P
<tissevert>thank you podiki[m] ! you made my day : )
<podiki[m]>I live to serve
<podiki[m]>speaking of serving, the CI is not serving up build detail pages?
<nckx>Oh, none?
<nckx>I reported one but didn't care to check others:
<podiki[m]>nevermind, did get one
<podiki[m]>not in progress/waiting builds it seems?
<podiki[m]>scheduled builds rather
<podiki[m]>scheduled and started won't show for me
<podiki[m]>I think I noticed soon after the big core-updates-frozen with -batched-changes merge, but could be because I was then checking on builds more
<vdv>sry for logoff spam, setting irssi config.. >.<
<podiki[m]>nckx: added that info to the bug tracker, in case it helps
<vivien>Has someone tried to set up the guix build coordinator?
<Noisytoot>tissevert, You're also purple for me (and green only if you highlight me)
<tissevert>Noisytoot: which I'm going to do at once in order to gain a little greenity
<tissevert>nckx: sddm login screen takes my keyboard layout but it doesn't apply to the wayland session once logged in : (
<PurpleSym>rekado: The testsuite of GHC takes a *very very* long time (multiple hours) and afaik does not contribute to the progress.
<M6piz7wk[m]>hmm still at 53% building after like 9 hours
<M6piz7wk[m]>should i kill it
<M6piz7wk[m]>is guix-packages-base.drv supposed to take this long on low end 32-bit
<M6piz7wk[m]>this is `guix pull` command
<Noisytoot>32-bit on what architecture (x86 or armhf)?
<M6piz7wk[m]>x86 i think
<M6piz7wk[m]>Noisytoot: ^
<M6piz7wk[m]>Intel Atom N280
<M6piz7wk[m]>seems like x86
<Noisytoot>It will probably take a while.
<KE0VVT>M6piz7wk[m]: I once built Chromium on an Intel® Atom® from 2012. It took 24 hours.
<nckx>OK, but 10 *hours* though?
<M6piz7wk[m]>it says 53% this whole time though
<nckx>Is it swapping?
<M6piz7wk[m]>i am concerned that it's just doing error messages in the background in an infinite loop
<nckx>I can't say it's not because we have no idea what it's doing, or indeed what ‘it’ is. You could strace the process that's (one hopes) using 100% CPU to get a rough idea.
<singpolyma>How can I find out how many rebuilds a change would cause?
<nckx>Often: guix refresh -l CHANGED-PACKAGE
<nckx>But there are plenty of gotchas such as inheriting packages not being counted as dependent &c.
<nckx>And implicit build system inputs not being visible.
<singpolyma>What if I change a build system?
<nckx>You could write code that maps over all packages to find the ones that use that build system, I guess. I don't know of a readymade way.
<nckx>fold-packages, to be exact.
<singpolyma>So when the builds are actually done I guess it just doesn't know how many it will do? Just kind of keep building until things are good?
<nckx>What is ‘it’ here? Putting aside grafts for a moment because they complicate things, Guix always knows exactly what it's going to do beforehand, but teasing it out can sometimes take a think.
<nckx>You could, probably, maybe, guix build --dry-run $(guix package -A) before & after & diff the result, which might work.
<singpolyma>I guess, CI? Wherever the rebuilds are done.
<nckx>They are done wherever they happen to be needed? I don't follow.
<nckx>Is this a question about Cuirass, or Guix, …?
<singpolyma>Well, CI is going to actually rebuild the needed-to-be-rebuilt packages, right? In order to have substitutes for them
<singpolyma>So I guess does "it" (CI) know how many packages it's going to build for a given input?
<singpolyma>Sorry, input is loaded here. Uh. Patch. Commit
<nckx>So you care specifically about CI?
<singpolyma>Because CI will be where the main impact of the rebuilds is? Most people will get substitutes and even those who don't are unlikely to have all the need-to-rebuild packages installed
<singpolyma>Also I'm partly thinking about what it would take to do the full CI build on every patch
<nckx>But how many packages need to be rebuilt isn't something you ask the CI. It's just a fact.
<singpolyma>Sure, the CI is just an example of a place that might know, and if CI can know then I could somehow know
<nckx>In the course of its regular operation the CI happens to do the equivalent of the above guix build --dry-run $(guix package -A)
<nckx>and the diff will be missing, and hence built.
<singpolyma>Ok. So CI runs guix in a context where the store has "everything" such that guix build will know not to build stuff it has? Where here everything but at least all the substitutes currently available
<nckx>But the CI is really not relevant here, I think…
<singpolyma>Or, I guess the guys build output can show what will come from substitute or not
<nckx>Think of the CI as ‘while sleep 5m; do guix pull; guix build $(guix package -A); done’ with a fancy UI and error handling. It does not ‘know’ anything worth asking.
<nckx>This is all done by Guix, per user, because it's that Guix that has to decide what to rebuild, not the CI.
<nckx>Only then will it query the substitute server (=CI here). When it already knows exactly which and how many things need to be built.
<singpolyma>Right, and then what I want to know is how many things that would need to be built still need to be built after querying for substitutes
<nckx>Have you read show-what-to-build in (guix ui)? That's where I'd start.
<singpolyma>I will look there, thanks
<singpolyma>nckx: also, thanks for always being such a sport with me. I know it's not easy when us noobs don't even know the right questions to ask
<nckx>You were patient with me as well. It took a while for us to sync :)
<florhizome[m]>Hm i sent a comment to a Patch series, but it doesn't appear
<nckx>It can take a while.
<nckx>Sometimes hours. Depends on the mood of the GNU. All we can say on the Guix side is you're not stuck in moderation.
<nckx>However, in the vast majority of cases, your response should show up on issues.guix in <15min.
<florhizome[m]><tissevert> "nckx: may I ask guidance on..." <- What do you need to know?
<florhizome[m]>There is an article on sways wikipage about it. Basically on wayland you need to set them via gsettings and you can script that.
<florhizome[m]>nckx: ok :)
<florhizome[m]>In order to commit packages, i need to fork guix source code and, apply the changes, and commit, right?
<jpoiret>you don't need to fork
<jpoiret>just clone the repo and add your changes on top. forking is kind of a foundry workflow (github/lab/etc...), whereas here it is patch-oriented (like the kernel)
<KE0VVT>jpoiret: <3 Linux workflow!
<jpoiret>in general, see the "Contributing" section of the manual
<nckx>florhizome[m]: You just landed in the moderation queue.
<nckx>You escaped!
<nckx>Who knows where you were lost before that.
<florhizome[m]>this is way more exciting then I ever imagined when I clicked on send :D
<NicholasvonKlitz>What's the status of Gnome 40/41 on Guix?
<civodul>roptat: (route-add "default" #:via "") fails with "Network unreachable"; compared to "ip r add default via", the scope and protocol in particular are different:
<sneek>Welcome back civodul, you have 1 message!
<sneek>civodul, vivien says:
<KE0VVT>NicholasvonKlitz: I installed Guix with the GNOME config. It was GNOME 3.
<civodul>vivien: perfect, thanks!
<vivien>Mmh the message looks a bit rough, sorry
<civodul>np :-)
<KE0VVT>It was a bit jarring using GNOME 3 again. I am so used to GNOME 41 now.
<vagrantc>there are some upgrades to GNOME 41 packages in core-updates-frozen, which is actively being worked on being merged into master
<vagrantc>but merging core-updates is taking a while
<vivien>rekado said that core-updates-frozen should contain mostly GNOME 40, with exceptions for 41 when things break
*vagrantc did a quick "git grep --log=gnome origin/core-updates-frozen"
<vivien>KE0VVT, core-updates-frozen fails to build many GNOME packages right now, because there are difficulties with libsoup and webkitgtk
<vivien>And the recent meson upgrade :)
<KE0VVT>vivien: Ah, I see.
<vagrantc>sure help fixing things would be appreciated :)
<KE0VVT>I can't even get Jellyfin to see my files after “chown -R jellyfin:jellyfin /srv/jellyfin/”.
<KE0VVT>I can’t code.
<vivien>I have a fix for gnome-tweaks
<vivien>Also, devhelp:
<KE0VVT>It would be nice if GNOME Software worked with Guix.
<vivien>KE0VVT, is discussing it
<roptat>civodul, I see, thanks!
<KE0VVT>vivien: Strange that PackageKit does not support per-user installs, considering Flatpak does.
<nckx>Did Flatpak exist in 2014?
<nckx>Apparently not (released).
<NicholasvonKlitz>Thanks for the info
<vagrantc>how would i disable all the translations in guix/doc/* ? i'd like to workaround the issues i'm having with "make dist" generated tarballs and at least see if other things about guix build correctly.
<roptat>civodul, I think I fixed it, can you check? If it works well, I'll make a release and we can update the guix package
<roptat>vagrantc, if you can change the files, I'd remove the files from info_TEXINFOS in doc/
<KE0VVT>nckx: Ah, so PackageKit was not made with Flatpak in mind.
<nckx>That would seem unlikely.
<aru>doesn't packagekit predate flatpak?
<nckx>That was my point.
<nckx>It seems equally likely that much has changed since 2014, so that adding proper per-user Guix support might now be easier.
<vagrantc>roptat: yeah, i can make patches, thanks!
<roptat>what's the issue with make dist?
<nckx>I wonder if the Nix PKit integration support in 2021 is well-maintained or hardly used.
<vagrantc>roptat: i posted to guix-devel about it ... basically i managed to get "make dist" to build a tarball, but when i build from the tarball a bunch of language-specific guix.*.info files fail to build
<nckx>Seems like it was the latter but might soon become the former:
<vagrantc>it *might* have to do with generating the tarball from a "guix --container --pure shell" on a Debian system ... it doesn't seem to have any locales available except C and POSIX
<vagrantc>despite trying to add glibc-locales, explicitly exporting LC_ALL/LANG etc.
<roptat>vagrantc, that should be ok, we explicitely set that when building the translations
<roptat>could you send me the content of, say, guix.pt_BR.texi?
<roptat>also, I wonder what's the deal with he-config-bare-bones.scm
<henk_guix>Hi Guix!
<roptat>hi henk_guix :)
<henk_guix>Quick question, I'm using with-output-to-file
<henk_guix>hi @roptat, nice to meet you again
<henk_guix>still with the same problem
<vagrantc>roptat: does guix.pt_BR.texi get updated during the build?
<roptat>vagrantc, I'm not sure exactly what's supposed to happen with it, from a dist tarball
<roptat>from a checkout, it's generated, modified with guix/build/po.scm and compiled into a .info
<henk_guix>I find that with-output-to-file but guix build throws "file not found", but that's the point: I want to create a file :D
<nckx>Does the parent directory exist?
<nckx>It could be the file that isn't found.
<henk_guix>good question, it should go to 'bin'
<henk_guix>Thanks @nckx
<henk_guix>I'll try to create it before
<vagrantc>roptat: seems to be generated during "make dist"
<nckx>OK! There's an mkdir-p helper that will create all parents.
<roptat>vagrantc, then it shouldn't be modified afterwards
<KE0VVT>Installing Guix on RHEL is hard. Thanks, NSA/SELinux.
<vagrantc>roptat: the build process runs autoreconf and company ... this always used to work fine.
<vagrantc>roptat: how should i send the guix.pt_BR.texi to you?
<vagrantc>roptat: wormhole ? :)
<roptat>vagrantc, never mind, I think I see what's the issue
<roptat>he-config-bare-bones.scm is not present in the dist tarball, is it?
<vagrantc>roptat: don't see it anywhere, no
<roptat>so that's the issue, I'll fix it in a minute
<vagrantc>probably not added to dist_DATA or soemthing
<vagrantc>ah, home-environment stuff
<vagrantc>i guess even getting "make dist" to be run on CI wouldn't catch this ... though it would catch other issues
<roptat>yep, I added it to OS_CONFIG_EXAMPLES_TEXI
<roptat>give me one more minute to push the fix...
<roptat>you should be able to build a good dist tarball from e95acc0919e5018a715bc62b0a3c980c9715fcc3
<vagrantc>roptat: will test! :)
<vagrantc>my fantasy of a typo checker in guix lint appears to be a false hope ... at least two new "This packages" found their way in since adding it :/
<mahmooz>is it just me or are guix mirrors relatively slow?
<mahmooz>it caps out at 1mb/s
<nckx>Which mirror? I don't think we host any of them ourselves.
<mahmooz>uh no idea im just running reconfigure and its slow at downloading stuff
<cbaines>vagrantc, which lint checker is checking typos?
<nckx>Guix doesn't use a mirror by default, and yes, the default substitute server ( is… slow for… unknown reasons we don't really understand, mahmooz.
<nckx>vagrantc: We don't want you to get bored.
<cbaines> should be a bit faster, providing you're in europe
<mahmooz>im getting frustrated waiting for latex to finish downloading lol
<cbaines>maybe try it anyway, it might be faster even from asia
<vagrantc>cbaines: i added a very crude checker in descriptions
<vagrantc>cbaines: it checks for maybe 4 common typos
<nckx>I *think* there was a Chinese mirror too.
<mahmooz>im in asia but as far as it gets from chinese lmao
<cbaines>vagrantc, ah, cool, I see the warnings :)
<mahmooz>ill try them thx guys
<vagrantc>cbaines: bordeaux as a substitute server has been helping a *lot* with aarch64 substitute availability, huge thanks!
<cbaines>vagrantc, that's good to hear :D
<vagrantc>cbaines: where were you seing the warnings?
<cbaines>vagrantc, I looked here
<vagrantc>cbaines: cool
<cbaines>unfortunately there's lots of warnings :/
<cbaines>I'm not that interested in fixing them either until there's better processes and tooling to stop new issues being introduced
<vagrantc>many of the typos are pretty low-hanging fruit, in anyone wants to get their name in the commit history of guix :)
<vagrantc>i'd like to get them fixed at least to avoid them landing in the released tarballs
<jpoiret>mhmmm funny, the installer cannot be run with `guix system vm` because it expects the --root kernel command line parameter to be a uuid, which is not in that case
<tissevert>florhizome[m]: thanks for the tip
<tissevert>so do you use dconf ? or is there a special interface for gsettings ?
<tissevert>at this point, really any piece of information would be welcome, I'm just trying to assemble a desktop that could run on my old eeePC and which I would find reasonably nice-looking and practical (I like GUIs, I like to be able to drag-and-drop things, to get miniatures for pictures, etc.)
<yewscion>Hey all, quick question, as I am not super familiar with FSDG guidelines: Is BSD 3-clause software allowed in GNU Guix proper? I'm interested in learning to write packages for GNU Guix and eventually contributing those definitions to the main guix repo, and I want to make sure the software I work on packaging is of an allowed license.
<nckx>yewscion: Absolutely! Guix accepts at least all licences listed here:
<yewscion>nckx: Awesome, thanks!
<nckx>For a prettier FSF document (but it's a bit strange that it includes non-free licences IMO; red dotted border is obviously not accepted) see:
<civodul>roptat: awesome, lemme see
<lilyp>I think the nonfree ones are listed so that people who see the word "free" in them don't go assuming the FSF endorses those
<civodul>roptat: yes that works, thank you! \o/
<civodul>roptat: BTW, i saw things like (throw 'no-such-device ...)
<civodul>IWBN if it were (throw 'netlink-error 'no-such-device ...) or similar
<civodul>or even better, SRFI-34/35 style: (raise (condition (&netlink-error ...)))
<civodul>in case you want to squeeze that in the release :-)
<civodul>no rush, though
<roptat>sure, I can do that, thanks for the suggestion
<civodul>i think 'route-add' should have thrown in the case above
<civodul>instead of just printing the error to stderr
<roptat>I'll see what I can do
<roptat>civodul, what should the condition carry? A message? How can I make it translatable?
<vagrantc>roptat: well, make dist fails now ... seemingly due to locale issues or something ...
<roptat>uh, I didn't change that much...
<roptat>what does it say?
<vagrantc>/gnu/store/zxamk4ymhi7x9cp2x17r1kax03c4za54-profile/bin/msgfmt: en@boldquot.po: warning: PO file header missing or invalid warning: charset conversion will not work
<roptat>that doesn't sound too bad, it's just a warning?
<roptat>this po file is generated I think
<vagrantc>warning: charset conversion will not work
<vagrantc>/gnu/store/zxamk4ymhi7x9cp2x17r1kax03c4za54-profile/bin/msgfmt: found 1 fatal error
<vagrantc>immediately after
<vagrantc>i think i managed to workaroudn this before ...
<civodul>roptat: a condition can contain a &message condition, but what matters most from an API viewpoint is a structured condition from which the caller can extract useful info
<civodul>you'd define a small hierarchy of "condition types" with define-condition-type
<civodul>e.g., &netlink-error (at the top) -> &netlink-route-error
<civodul>where the latter specifies the route name or something
<civodul>(i haven't put much thought into what fields each condition type should have!)
<roptat>vagrantc, I'm afraid I never touched en@boldquot.po, I don't know how it's generated or why it has a fatal error
<vagrantc>i suspect it's the lack of availability of the en_US.UTF-8 locale...
<phodina[m]>Hi there, could you please help me locate package which provides the command getent?
<florhizome[m]><tissevert> "so do you use dconf ? or is..." <- I am unsure what the different between scone and gsettings is. What I understand is that gsettings is the original thing. There is a GUI called second editor, that you can use to edit these settings, but haven’t tested it on guix.
<nckx>phodina[m]: glibc
<vagrantc>ls /gnu/store/*/*bin/getent ... depending on the size of your store, could take a while :)
<vagrantc>or find /gnut/store -name getent
<vagrantc>without the spare t :)
*vagrantc goes back to fixing typos
<florhizome[m]>woo my mail has landed! thanks to the GNU! :D
<phodina[m]>Thankfully my I have a small store :-D
<nckx>Hm? It really should have landed minutes after I approved it but yes all hail the GNU.
<phodina[m]>getent is located under glib
<jpoiret>does anyone even use the graphical installer?
<jpoiret>i'm working on it to add luks2 to it, and it seems that there's a bit of a gaping hole in it: it waits until all non-installation devices stop being busy, but the installation device detection is sketchy at best (i don't even think it should work)
<jpoiret>at least in my qemu it systematically fails at that step
<jpoiret>when partitioning at least
<nckx>phodina[m]: No…
<atw>sneek: seen amirouche
<sneek>I last saw amirouche in #guix 3 months ago, saying: e.g. is it possible to request a build job inside qemu ?.
<civodul>jpoiret: to test the installer (or even manual installation), you need a standalone VM image as produced by "guix system image -t qcow2", and you need an additional image to use as the target hard disk
<jpoiret>yes, yes, i've been using this setup
<civodul>you can test parts of the install in "guix system vm", but not the installation itself
<civodul>ok :-)
<civodul>the installer works pretty well IME, but if you find suspicious code, do raise it on the ML!
<jpoiret>non-install-devices claims to detect the installation device using the /proc/cmdline, but (installation-device) only returns /dev/sda2 for example whereas we'd want it to be /dev/sda
<jpoiret>(since the --root parameter is the specific partition and not the device itself)
<jpoiret>i'll see if i can write something better
<jpoiret>the installer may work better when the installation media is reported as read-only
<drakonis>amirouche's changed names btw
<drakonis>goes by amazigh now
<civodul>jpoiret: which is normally the case
<jpoiret>not when you use qemu -hda
<jpoiret>in any case, it should not wait for the root filesystem to stop being busy, read-only or not
<atw>thanks drakonis
<drakonis>welp, today i'm going to do some wild wild stuff like running core-updates-frozen
<rekado>drakonis: I can’t build my system with the current core-updates-frozen
<drakonis>ah, that sucks.
<vagrantc>new 'This packages' typos introduced by ... 729936cfa4766787218c9e5cf683723544f996f0 and 1e1c51a5e5095c20b9d7723c4b0509c5e79592fc ...
<rekado>merging master into core-updates-frozen is important, but the merges introduced some more regressions
*vagrantc waves a "guix lint" at everyone! :)
*rekado builds icecat again
<vagrantc>ok, finally, i figured out how to run "make dist" from a "guix shell" ... guix shell --container --pure --development guix guix git imagemagick perl glibc-locales glibc
<vagrantc>so i don't pollute the environment with my pesky Debianisms
<roptat>civodul, i create a small hierchy of conditions and converted all throws and prints on stderr:
<civodul>roptat: yay, nice, thank you!
<cmack>Is there a way to debug a `guix pull -K` that fails and there is an empty directory in thexpected /tmp build area?
<civodul>looks perfect
<cmack>or does `(values (non-self-quoting 2052 "#<unspecified>"))` look like a familiar error to anyone?
<rekado> does not seem happy with core-updates-frozen
<rekado>I see no logs for
<rekado>logs / details
<vagrantc>This patch on core-updates(-frozen?) breaks "make dist" gnu/ %D%/packages/patches/gd-Revert-fix-303-gdlib.pc-use-Requires-instead-of-Libs.patch \
<vagrantc>long file or whatever
<vagrantc>guess it's easy enough to fix, but a little confused on the process for core-updates* fixes ... where they should go, etc.
<KE0VVT>Any GUI apps written in Guile?
<vagrantc>oh, there are lots of patch-names too long in guix master:
<vivien>KE0VVT, guile-gi is a good start for gtk+.