<florhizome[m]>tissevert: Pretty sure there are other solutions, too, but haven’t tried. <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 <jpoiret>you can backport the patch on master if you want <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 <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 :) <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>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 <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>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 <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 <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>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 <vivien>The things that are used most in build phases are substitute*, invoke and wrap-program <vivien>It will replace patterns in the file you want to modify <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? <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 <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]>also there seems to be a module for a tiny wm like thing, on the guile Website. <vivien>florhizome[m], maybe you could use open-pipe-with-stderr <dissent>hey guix, attempting to package trayer-srg. should be relatively simple since there is only one dependecy. getting build fails though. <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. :-( <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?: https://termbin.com/ua8r <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 <vagrantc>KE0VVT: very hard to predict a minimum size <florhizome[m]>i recognize there might not even be such a simple command in the regular shell <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 <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 guix.gnu.org'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 <vivien>So, you are packaging a program, right? <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 <jgart>could we add a default config for stalonetray to the gnu/store? <jgart>does it make sense to do that? <jpoiret>florhizome[m]: sddm doesn't support wayland yet afaik <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 :) <florhizome[m]>vivien: That's kind of the wrong way around, though... The Plugins depend on the conpositor, not the other way <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. <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], you could, but you won’t be able to get plugins. <vivien>If you can, it means you broke sha-256 <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]>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 <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]>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>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 paste.debian.net, but I'm guessing you're not chatting on the same machine. <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 <nckx>No, and pulling would distract from the error. <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. <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. <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. <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 ***xgqt_ is now known as xgqtd
***xgqtd is now known as xgqt
<singpolyma>Why? It's a 100% accurate description of the command <singpolyma>Sure, it deplys it into the relevant profile for your use <singpolyma>I would say "upgrade" vs "download and deploy" but both are accurate <M6piz7wk[m]>the guix command is upgraded through system reconfigure <singpolyma>Yes it does touch the guix command. That's all it does <singpolyma>It upgrades the command. Makes it a different version of the command <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 <KE0VVT>Guix seems slower than other systems. <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. <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. <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. <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]>struggling to figure out how to replace the gdm with anything else <M6piz7wk[m]>also have to wait ages for this system to finish building anything u.u <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. <oriansj>and it can be setup by a 1Ghz P3 in less than 2 hours <KE0VVT>Newly installed apps don't have icons. <oriansj>and I can provide a full steps procedure for setup <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. <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? <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 <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]>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 <vagrantc>you can offload builds to another machine that's running guix ... there's documentation in the manual for setting that up *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 <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 <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] 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. <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? *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 <apteryx>M6piz7wk[m]: the manual says that offloading requires non-encryted keys (passwordless) <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? <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? <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 <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>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 10.0.0.17 <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]>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>you specify the user field in your build-machine record <M6piz7wk[m]><apteryx> "you specify the user field in..." <- eh? There are no permissions needed to give the user access to the store? <M6piz7wk[m]>i see.. still kinda uncomfortable as i would prefer to explicitly specify which users can make build requests to the nix daemon <brendyn>i guix gc'd about 500gb the other day <brendyn>after my ext4 complained about not enough space trying to make symlinks <M6piz7wk[m]>is there a way to deny the user to be able to interact with guix command? <vivien>M6piz7wk[m], a few months ago, someone told me it was possible to change the permission of the guix daemon socket <vivien>I was puzzled because the message was censored <vivien>But in fact, no, it’s just that starting a message with / on IRC does not publish the message <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]>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 <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 <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 <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]>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 <vivien>In guix, that’s not the case, so each user can install whatever they want without the other users being bothered <kittyblam>try to ignore M6piz7wk. the other day they where starting random arguments in #fsf. <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 <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 <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>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. <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 <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>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 <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 <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>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>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. <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 <jpoiret>because i think cuirass itself has been slowing down development on c-u-f <nckx>I'll report a bug jpoiret. <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>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 ci.guix.gnu.org 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. <nckx>It's tripped me up whilst debugging guix.gnu.org 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 <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>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 <vdv>because the db is just for man -k <nckx>Aside apologies that our Web log search is probably still broken. <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 :/ <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 <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 seems like I *really* have to learn how to create guix packages. Sigh <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. <vdv>ah like this (inputs (alist-delete "guile (package-inputs gdb))) <jpoiret>vdv: you may want to use package-input-rewriting from (guix packages) <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>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]>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>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 <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 <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: “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. <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: https://www.tobias.gr/guix-boot-logo.png <nckx>The console text is optional, if it bothers one. <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 <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/guix.info, 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) <jpoiret>you can compile just the .info file with `make doc/guix.info` and view it with your current info viewer with `info -f doc/guix.info` <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. <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>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 lwn.net 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. <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. <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")) <nckx>/gnu/store/ksy2b6fwfmz40gjajvspl87ia4vsfzj7-glibc-2.31/bin/locale <jpoiret>very nice indeed. Sometimes i forget about printf debugging <nckx>It is my cross-language crutch. <nckx>‘GDB is nice, I guess, probably.’ —nckx <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 cbaines@git.savannah.gnu.org 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 <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>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>which is why I was wondering how knowledgeable people did it <jpoiret>I just can't bother looking into X.org 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>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>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>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>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>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). <roptat>tissevert, you're purple for me too :) <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]>speaking of serving, the CI is not serving up build detail pages? <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]>is guix-packages-base.drv supposed to take this long on low end 32-bit <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]>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. <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. <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? <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>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>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]>In order to commit packages, i need to fork guix source code and, apply the changes, and commit, right? <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) <jpoiret>in general, see the "Contributing" section of the manual <nckx>florhizome[m]: You just landed in the moderation queue. <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 <sneek>Welcome back civodul, you have 1 message! <KE0VVT>NicholasvonKlitz: I installed Guix with the GNOME config. It was GNOME 3. <vivien>Mmh the message looks a bit rough, sorry <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 <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>It would be nice if GNOME Software worked with Guix. <KE0VVT>vivien: Strange that PackageKit does not support per-user installs, considering Flatpak does. <nckx>Did Flatpak exist in 2014? <nckx>Apparently not (released). <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/local.mk <KE0VVT>nckx: Ah, so PackageKit was not made with Flatpak in mind. <nckx>That would seem unlikely. <aru>doesn't packagekit predate flatpak? <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 <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>Quick question, I'm using with-output-to-file <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. <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? <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? <roptat>so that's the issue, I'll fix it in a minute <vagrantc>probably not added to dist_DATA or soemthing <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>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? <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 (ci.guix.gnu.org) is… slow for… unknown reasons we don't really understand, mahmooz. <nckx>vagrantc: We don't want you to get bored. <cbaines>bordeaux.guix.gnu.org 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 :) <vagrantc>cbaines: bordeaux as a substitute server has been helping a *lot* with aarch64 substitute availability, huge thanks! <vagrantc>cbaines: where were you seing the warnings? <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>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. <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 :-) <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>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... <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>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. <vagrantc>ls /gnu/store/*/*bin/getent ... depending on the size of your store, could take a while :) *vagrantc goes back to fixing typos <nckx>Hm? It really should have landed minutes after I approved it but yes all hail the GNU. <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 <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>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 <jpoiret>in any case, it should not wait for the root filesystem to stop being busy, read-only or not <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 <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 <cmack>Is there a way to debug a `guix pull -K` that fails and there is an empty directory in thexpected /tmp build area? <cmack>or does `(values (non-self-quoting 2052 "#<unspecified>"))` look like a familiar error to anyone? <rekado>ci.guix.gnu.org does not seem happy with core-updates-frozen <vagrantc>This patch on core-updates(-frozen?) breaks "make dist" gnu/local.mk: %D%/packages/patches/gd-Revert-fix-303-gdlib.pc-use-Requires-instead-of-Libs.patch \ <vagrantc>guess it's easy enough to fix, but a little confused on the process for core-updates* fixes ... where they should go, etc. <vivien>KE0VVT, guile-gi is a good start for gtk+. 
