<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
<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
<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
<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>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
<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 ^^
<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.
<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)
<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]>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.
<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)
<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>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
<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>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.
<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
<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>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.
<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.).
<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.
<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>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>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?
<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
<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.
<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>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
<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.
<civodul>(i haven't put much thought into what fields each condition type should have!)
<roptat>vagrantc, I'm afraid I never touched email@example.com, 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.
<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
<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