<vivien>I wanted to do some GUI stuff, but then I remembered my brain is not wired to program any GUI better than a window with a big "hello world" button in the middle.
<lilyp>To be fair, Guile-GI needs to laboriously import everything if you actually use a higher-level library like Gtk, it's not even fun.
<SeerLite[m]>Hi! I think I found a bug: When using any display manager other than GDM and setting the user shell to zsh, $PATH doesn't have the directories /run/setuid-programs and /run/current-system/profile/sbin inside the session. PATH is correct when logging in from a TTY so I don't think the problem is zsh. Can anyone else reproduce this or is it just me? Thanks :)
<lilyp>what's in your zprofile and is it being run?
<SeerLite[m]>There's a single `source /etc/profile` line. Just checked that file and I see that that's where the PATH is set with those dirs. Must mean it's not being run inside the session... But I'm not sure why
<brendyn>But I noticed the last time someone updated KDE they did many packages in a single commit. Seems logical because once you update one thing, 30 other things are broken until they are updated anyway.
<brendyn>Is there a convenvient tool for checking if an input to a package is probably extraneous?
<lilyp>brendyn you could diff the package with that input vs. without it
<lilyp>there's probably going to be false positives though, like RUNPATHs et al
<civodul>brendyn: you can check "guix gc --references $(guix build pkg) | grep the-dependency"
<civodul>if it's supposed to be a run-time dependency, it should be there
<ss2>hello, I want to get into writing services. Which service would be easier to read through, and maybe to build upon?
<brendyn>ss2, session-environment-service-type is a pretty simple start. it just creates a file /etc/environment
<brendyn>ss2, the general pattern seems to be to start with define-record-type* to make a record of the configuration details needed by the user. then you define the service with (service-type ...), creating any helper functions you need on the way
<makx>Is Vagrant Cascadian in here? They posted abnout "dynamic loading of modules from initrd" on the issuetracker (#48266);
<makx>on that note, does anyone know how to figure out dependency chains that enable one to minimise the number of modules that need to be put into initrd to get the eMMC to work? I spent a couple of hours yesterday trying to find a more structured way than "try and error"
<attila_lendvai>random note: hrm... package hashes are independent of the git commit metadata. i'm amending stuff by replacing an identical commit that was created by someone else, and the hash remains the same.
<brendyn>attila_lendvai, I think the .git dir gets deleted
<attila_lendvai>brendyn, most probably, but it's somewhat surprising to me. makes sense in a way, but then it ignores stuff like commit signatures... i guess authentication should happen earlier in a separate step.
<jlicht>attila_lendvai: authentication here is/(should?) be done by the package author/reviewer; after that, file contents are 'pinned' by the hashes in the package definition
<makx>civodul: It doesn't suggest otherwise, but also doesn't press the point ;)
<vivien>I see you wrote "they need the ability to customize it experiment with it" in the conclusion, but in the introduction, it seems that the reason to want source code is to see it (the sentence starting with "We want to make sure our users can see the source code that corresponds to the code they run;…"), I would have added a couple of words for a modified versions here.
<hjklambda>Hello! when I try to build python it fails with the log having "while setting up the build environment: executing `/gnu/store/...-guile-bootstrap-2.0/bin/guile': Exec format error", I took a look at the file and it had a shebang line pointing to some bash in the store, then I tried to execute this bash and it failed with "cannot execute binary file: Exec format error"
<civodul>hjklambda: hi! what command did you type, and on what system?
<brendyn>Running into the need to have <filesystem> and thus gcc-9 lately
<hjklambda>civodul: 'guix build $pkgs --with-input=pulseaudio=alsa-lib --with-input=ffmpeg=ffmpeg-small --no-substitutes -v2 -M4' with pkgs begin a variable containing the packages I have installed. My system is x86_64
<makx>should guix-daemon automatically detect a local guix publish?
<makx>can I somehow tell whether my guix publish is visible?
<attila_lendvai>where can i read/look about what happens when multiple packages install the same file into their bin/ output? e.g. how is the conflict resolved when merging into /home/user/.config/guix/current/bin ?
<attila_lendvai>i'm thinking about idris emitting both an bin/idris-1.2.3 and also symlink it to bin/idris
<roptat>if two packages provide the same file, guix will chose one version, arbitrarily
<rekado>attila_lendvai: see (guix build union), “union-build”.
<rekado>by default it uses “warn-about-collisions”, which picks the first of any colliding files.
<attila_lendvai>thank you! i was hoping for it being smart about version numbers... :/
<dstolfa>civodul: have you posted it on hackernews/lobsters?
<acrow>Yes, I do too. I'm trying to think of people I know of that might help facilitate changes that might drive guix adoption and recognition of the need for reproducible software. I'll be forwarding your link provided you are comfortable with that.
<civodul>i think what's intesresting here is to get feedback from people who're not "sold to the cause"
<radvendii>what are you looking for feedback on? I'm an avid Nix user but not sold on guix (only just started experimenting with it)
<dstolfa>civodul: i don't really have any of those accounts -- they are a distraction and i'd rather spend that time with family
<civodul>radvendii: if you want just tell us what you think of the post :-)
<civodul>it's not so much about Guix than it's about packaging practices in general
<radvendii>I think it makes the case well for high-security or high-reliability environments. The kind of applications that would also worry about using ECC memory. I'm not sure it makes the case for everyday users
<radvendii>which maybe isn't a bad thing. the arguments that appeal to those two groups tend to be different
<rekado>PurpleSym: that “guix gc --repair” bug is pretty annoying.
<rekado>even when I run the daemon with “--disable-deduplication” I still cannot get it to repair broken directories.
<rekado>I … just “herd stop guix-daemon” and then start the daemon manually. I’m unaware of bug 47115.
<jackhill>rekado: ah, yes, so it sounds like you're only running it that way for short periods of time. When I tried to run it that way for longer, it didn't really seem usable because of that issue.
<jackhill>civodul: oh the notion of which libraries were included and not, could it be for license complience reasons, and excluding copyleft libraries becasue when they aren't produced reproducably it's hard to provide the scripts that control the compilation and instalation?
<jackhill>would be interesting to know if our pytorch package works on the ppc64le port. I'm betting one can't get it pre-build for that archetecture from pypi :)
<radvendii>I have a VM running `guix build` that keeps failing with "Killed". I figurd it was an OOM problem, but it still happens even with 8GB of memory assigned
<radvendii>is guix just that memory hungry, or is something else going on?
<civodul>radvendii: thanks for your feedback; re "making the case for high-security", it's interesting because i don't see it that way: there's security, yes, but to me these are just basic transparency requirements that should sound familiar in a scientific context
<radvendii>civodul yeah I think scientific contexts are high-reliability contexts, so this applies. But like, for an average every day person why should they care?
<radvendii>Also I think it's a fairly new thing that scientists care about code reproducibility. Lots of papers have been published without even open sourcing the code, no?
<radvendii>(i'm no expert on this, i just remember noticing that years ago and being frustrated)
<civodul>radvendii: that's true, but there's at last awareness that this is a problem
<civodul>your question about "average person" is a good one, though i can't really answer it because i despise that concept
<civodul>the idea that there'd be an elite who cares about and deserves feature X
<vivien>That’s a chance to make them think about source code, which is good :)
<jackhill>radvendii, civodul: I know why I care, but maybe that doesn't resonate with everyone: the pypi approach might work now for my particular situation, but it could become a hassle for me in the future for any variety of reasons, and may prevent me from experimenting with future improvements to my computation environment. I value avoiding future pain highly and am willing to put in more work now to avoid it.
<civodul>right, that's in part an education problem
<radvendii>and i think for someone who doesn't care, this doesn't make the case that htey should
<jackhill>Other probably value different things. Also maybe of note, I'm not responsible for bringing in grant money
<vivien>It’s hard to tell what people care about, because they can lie to you
<civodul>it's hard to adopt a perspective that's at odds with one's own perspective
<civodul>which makes it hard to make the case for "someone who doesn't care", i guess
<vivien>Have you noticed how hard it is to talk about freedom outside of the computer to people you barely know? Or maybe it’s just me ^^
<vivien>Maybe they appear not to care, but they still care a bit
<dstolfa>radvendii: i think it's just about phrasing. suppose you phrased this as: "guix allows you to give your full system to a developer with the click of a button, ensuring that reporting and solving your bugs is quick and efficient"
<dstolfa>it would be a much more interesting feature than talking about reproducability, science, etc to regular users (even though i think it matters more in science)
<dstolfa>we would need some tooling for the above to happen, but all it really needs to do is pick up your config and profiles with the bug report and send it off
<radvendii>yeah, that's a much better framing i think for developers
<dstolfa>radvendii: another thing worth pointing out... at least for me. `guix environment --ad-hoc jupyter ... --container --network` is much more convenient to me than `podman pull && podman create ... && podman start` or worse yet, having to write a dockerfile and so on
<radvendii>yeah. it's super relaxing to use nix/guix by comparison
<dstolfa>one thing i wish i had in guix was a redhat-style kernel. i would replace every system i have on rhel in a heartbeat
<podiki[m]>I definitely feel more relaxed knowing all the important stuff is in a config file, my dotfiles, (and data in home only)
<podiki[m]>I dread having to recreate a home server, with the various little tweaks and config files spread out who knows where
<radvendii>well, i have increased the VM's memory to my system memory, 16GB, and now I'm getting "Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS"
<vivien>... and not knowing what service is still active, and what was paused when I got distracted, and what I could not figure out how to run.
<vivien>Declarative configuration for a server is really useful ^^
<radvendii>yeah. at the system-configuration level there's also the advantage of being able to piggy back on other people's work
<dstolfa>vivien: so long it's not TOO declarative, as is sometimes the case with ansible :)
<radvendii>i wonder if the ease of setting up services can prompt a resurgence of self-hosted / federated software
<roptat>mh, there are other distros that target exactly that, but I don't think any is extremely successful (yunohost might be the most successful)
<roptat>and there's the limitation that you need to know guile in order to really customize services, whereas yunohost might be more limited in options, but all you have to do it click on a few buttons on a web interface to customize your services
<vivien>I must say that we are not in the best spot to target self-hosting, because we don’t have much of the whole NPM situation
<civodul>GSaaSoI: "guix search as a service over IRC"
<jackhill>civodul: reguarding the security argument: at least at my institution, the people who work in the IT Security Office are so far afield that I doubt they could even understand the argument about building from source, much less reject it. I was recently asked to install some non-free software to run as root to improve security… I suspect I'll get out of this requirement since they won't be able to produce
<jackhill>a version of the software that works with Guix :)
<civodul>jackhill: heh, i've also seen things along these lines
<radvendii>I ran `guix import go -r github.com/tweag/trustix/packages/trustix`
<radvendii>and then am running `guix build -f guix.scm --cores=1` on that file
<radvendii>well, i added the package name at the bottom of the file so it actually builds the right thing
<jackhill>oh, guix import go. I haven't tried it, let me see…
<jackhill>radvendii: still on the import step, do you also get: ‘guix import: warning: Failed to import package "github.com/cncf/udpa/go"’. ?
<nckx>raghavgururajan: So… Bluetooth, short answer: mine doesn't work with Linux-Libre. Rotation button, long answer: it doesn't ‘do anything’ out of the box (not even sure how that would work), you need something listening to the button press and do the right thing, depending on what you want the button to do (cycle? toggle?) and how (X? Wayland? etc.).
<jackhill>hmm, I'm on master at commit 00e3a3a177b9e0369a7b4b3d179e8d76e2764082 maybe I need to pull
<radvendii>yeah i just did a `guix pull` like 20 min ago lol
<nckx>But it's usable, as is the actual tablet sensor (= the lid sensor, except it knows if you closed the lid screen-up or -down).
<nckx>raghavgururajan: …actually, I'm currently running without the front bezel (don't ask) and have never used this machine with the original O$, so I don't know how it's supposed to behave, I just made it up. There are two buttons that both look like ‘rotate’ to me; the green one works: https://www.tobias.gr/buts.png
<nckx>I didn't find a way to get events for the other one, but I didn't try hard; I don't need 2 buttons.
<rekado>hmm, is there another way to repair corrupt items in the store?
<rekado>I guess I could download, unpack, and copy over…
<dstolfa>ix: i think the main problem is that someone would have to implement a way to generate unit files, and ironically, it might be less work to just support parallel boot and a couple of other things for shepherd depending on what you need
<dstolfa>if you need a full fledged system bus and all that, then it's less work to generate unit files, for sure.
<dstolfa>but if it's just a few simple things from systemd, it might be relatively easy to put them into shepherd
<ix>And i think it'd be pretty easy to switch out, codewise, they don't have very different interfaces
<dstolfa>ix: i certainly think it'd be cool to support different inits with guix, but don't really have time to work on any of it at the moment. i'd happily look at your patch, though!
<ix>Just curious if its in the crosshairs for the devs though, or if the plan is shepherd all the way
<ix>If not, I might see how hard it'd be to translationally swap out for my system, and if that works at least i'm a PoC
<dstolfa>my understanding is that the main init will remain shepherd, as given time, it's fairly easy to massage it into being much more robust and supporting the commonly requested things. shepherd is *extremely* simple and the codebase is small. but that doesn't mean we couldn't have different backends :)
<Guest2565>Is there a command to generate a texi template about a service and its configuration structure?
<nckx>That's what I feared, Noisytoot. My update is still running (which is fine—one was long overdue, so thanks, I guess :)
<nckx>Guest2565: Not quite that, but there's a ‘generate-documentation’ helper used in various (gnu services) that I've never investigated more closely.
<nckx>Noisytoot: You may well be doing it already since it's obvious, but if you have the time, could you ‘bisect’ your package set?
<ss2>hello, I'm having problems with emacs-guix right now. I just pulled to 6eded1a04186e3118b293486b038c994e05efedf, and now any package listing fails with similar message as such: 14 (eval (#<procedure 7f62b89c4c30 at <unknown port>:21:16 ()>) #<directory (emacs-guix) 7f62b9b63820>)
<rekado>jackhill: I used the online configurator to generate a JSON file, so I wanted to use qmk tools to convert that to source code. But it looks like I can also download the full source code on the configurator.
<jackhill>rekado: oh neat, I wanted to do everything locally out of principle. I agree that having the qmk helper would be a good addition to Guix :)
<rekado>yeah, I’d like to do everything locally as well, but I’m the newbiest noob that ever noobed.
<jackhill>As would getting the configurator to run, but that probably involves JS. What I really want is to build my firmware as a derivation
<rekado>(I just want dvorak with tap/hold modifiers on the home row)
<rekado>the librem’s keyboard is just too uncomfortable
<iskarian>rekado, can you try "python -m pip install ."?
<jackhill>For what it's worth editing the C macros/arrays turned out to be less hard than I feared. Often I get new hardward and don't use it for a while because it takes me forever to get it set up. Yay pragmatism. Anyways I'm veering offtopic and it sounds like iskarian has actaully helpful suggestions. Just wanted to offer moral support for doing keyboard hacking in guix.
<iskarian>(you might need to add python-pip as a dependency)
<rekado>iskarian: doesn’t work. It still tries to look for dependencies on the network.