<nckx>dftxbs3e: Lookin' good! My patch, at least, didn't change the GCC hash on other arches so can be upstreamed relatively quickly.
*nckx has bad lag and is following along on logs.guix.gnu.org :-/
<nckx>fnstudio: I'm not much help on foreign distroes, but can you elaborate on ‘tweaked things locale-wise’? Which changes did you make? Is this tmux from Guix (I assume so)? Are all your Guix packages up-to-date? Is GUIX_LOCPATH set?
<nckx>My (Guix System's) mosh suddenly refused to connect to servers due to locale problems a few days ago. A reboot fixed it. I wonder if something was changed.
<nckx>dftxbs3e: Do you host your tarballs somewhere? Depending on my evening I can build & compare.
<fnstudio>nckx: yes, right, so _tweaked things_ = i kept getting this locale-related warning/hint when launching guix commands; so i installed glibc-locales and glibc-utf8-locales both as root and as my normal user and (after a reboot and some random attempt that i didn't fully understand) that was sorted
<fnstudio>nckx: however, i then realised that my system was broken in some other way
<nckx>fnstudio: What is LC_ALL otherwise? (Also see what $ locale says, I guess.) By the way, glibc-utf8-locales is a subset of glibc-locales so you shouldn't need both, but it shouldn't cause this kind of problem either.
<nckx>It would really be nice if someone with more foreign distro experience were to chime in. I can help with most bugs but not the weird ones 🙂
<fnstudio>nckx: i'm now removing the subset version then, just in case...
<fnstudio>(is there an equivalent to apt remove --purge in the guix world by the way? or is it just guix remove?)
<nckx>fnstudio: Just guix remove. --purge apparentely deletes configuration files too, which Guix doesn't track or otherwise involve itself with at all.
<fnstudio>i suspect the issues with urxvt and tmux are cascading effects of the above
<andrew>Hi. Hours after having troubleshooted an Alacritty starting issue on Sway, I've discovered that libxbkcommon.so and libwayland-client.so aren't linked into the Alacritty binary, causing it to fail to launch under pure Wayland environment. Does anyone know what could cause this?
<andrew>Wayland and xkbcommon are listed as inputs of the Alacritty package
<guix-vits>andrew: is `guix weather alacritty` returns 0% for You too?
<guix-vits>and "0.0% (0 out of 1) of the missing items are queued"?
<guix-vits>tissevert: There was an old joke: "And if Wayland session crashes, then all the apps crash too. Unlike Xorg. And when i asked why, they said it's just a protocol, not a server. And when i'd said "i not geve a ****", they asked: "what is Your troubles?"
<andrew>nckx: I gave a quick glance to the Alacritty package recipe and I'm honestly dumbfounded by the complexity of it. In any case, to run it on Sway with xwayland disabled, I had to set LD_LIBRARY_PATH to $(guix build wayland)/lib:$(guix build libxkbcommon)/lib. This is as hacky as it could get
<kmicu>thread 'main' panicked at 'Failed to initialize Wayland backend: NoCompositorListening', /build/alacritty-0.4.3-vendor.tar.gz/winit/src/platform_impl/linux/mod.rs:545:28 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
<kmicu>Cool, I’m not on wayland so that’s not a bug. 😺
<nckx>It's just missing the two directories you pasted above, where it would have found the library.
<tissevert>it's a good thing that I get to read about service composition again, because I had clearly not understood everything the first time I read the manual when I was pondering whether to install or not
<nckx>I'd like to patch in the full patch like we already do for libGL.so, but since this is a transitive mess, I don't know where (and I don't know enough about Rust to find out).
<tissevert>although I'm really not sure I want to invest that amount of time, after more than several weeks of struggling and not only a basic system working ^^'
<nckx>I can't even find the part of rust-wayland-client that would dlopen a .so :-/
<guix-vits>tissevert: The services can be used in easier way (especially if some already exist, like gdm). But one'll need to check the differences manually with the new version of service definitions (in git).
<andrew>nckx: Oh wow. This must be the first time I'm ever credited with coming up with a solution to a software bug! :o Thanks for tackling this for me!
<nckx>andrew: :) So you run pure Wayland? Guix System?
<guix-vits>tissevert: with my configs, this should be a `(services (append %my-base-services %my-desktop-services (list (service gdm-service-type))))`
<tissevert>what should ? I'm under the impression that you're trying to help me figure how to run gdm at boot : S ^^
<guix-vits>... and, by default, the gdm-service-type is included in %desktop-services.
<andrew>nckx: Exactly!.. Well. I reckon I'll have to make an exception for certain software that is incompatible with Wayland at some point, but , for as long as I can, I'll be running pure Wayland on my Guix System box
<tissevert>yeah, I know, that's why I'm so puzzled the default «example» configuration would yield something so instable that re-starting a basic system service would «crash» the system
<tissevert>and I was wondering if maybe people here had an explanation, if there was a good reason why it should be the case
<guix-vits>tissevert: Ah. Maybe post Your system config at paste.debian.net?
<tissevert>if maybe I had not understood the relation between *-service-type values in guile and the entries that appear in the output of a «herd status»
<dftxbs3e>tissevert, it feels like you are angry at the GNU Guix project, it's a rolling release GNU/Linux distribution much like Arch Linux, if there's a bug, everyone's more than happy if it can be fixed, otherwise, it's just that it hasnt yet
<nckx>andrew: I just switched a few days ago, so most things are still running under Xwayland (including my status bar), but good to know it's feasible. I don't think I need anything that can't be convinced to run under Wayland proper.
<tissevert>dftxbs3e: on the contrary : I just wished I could reach a point when the thing is usable enough and I can start being useful to the community
<tissevert>but I've spent more than 3 weeks at it and I'm starting to worry this was a pure loss ^^
<str1ngs>atleast when thing break in guix, you can --roll-back \o/
<dftxbs3e>tissevert, I am glad you want to contribute. GNU Guix is still in heavy development, so I don't think it makes sense to address it this kind of criticism
<tissevert>guix-vits: that's a really nice suggestion, thanks. I won't paste it, it's even versioned on my server
<andrew>For example, installing qtwayland to a user's profile doesn't make the wayland Qt platform plugin visible to Qt applications..
<andrew>or the fact alone that Qt theming is not currently possible under Guix System (for now)
<fnstudio>sorry very briefly on my locale problem again, suppose that you want to change your locale in guix (on a foreign system), is it just a matter of editing the LC_ALL, LC_CTYPE, LANG env variables or am i expected to launch any other locale-gen kind-of commands?
<lfam>fnstudio: One big difference between Guix and Debian is that, with Guix, package management is per-user. Whereas on Debian, packages are managed for the entire system. So, each user can do their own `guix pull` and install their own packages
<ryanprior>I used to do per-project package management the Debian way using debootstrap and chroot =D
<ryanprior>I'm definitely happier doing it with Guix today. My tools of choice evolved from debootstrap -> lxc -> lxd -> docker -> guix, all chasing more or less the same dream
<guix-vits>tissevert: So the default config makes "restarting xorg-server makes the box completely unusable with a blank tty, no keys allowing to go back to a regular tty and the CPU going into a rage". Pity. Strange.
<tissevert>guix-vits: well it seems to me that I'm close enough from the default config that it would do that but I thought that would be most unlikely and several people here could attest it wasn't the case
<tissevert>I'm still trying to figure out what light the GDM service definition could shed on this but I really have a hard time understanding what does get executed in the end from the guile definitions
<tissevert>tried to re-run it, found out it wasn't doing anything but now I had duplicate stray GDM processes
<tissevert>I killed everyone, started xorg-server manually to get GDM back (that worked)
<tissevert>and now that I was a bit more comfortable thinking I had at least a slight idea what could be going on, I thought it would be a great idea to simply get a snapshot of what was running
<tissevert>stop GDM and make another snapshot, to observe in detail what was running and what wasn't in both situations
<fnstudio>lfam: ooops sorry for the delay; re guix' per-user nature, yes that makes sense and i suppose it's a source of great flexibility, thanks for mentioning that
<tissevert>turns out for me, stopping GDM completely locks the box and I was almost relieved that pressing the power button once was handled correctly and made the computer halt after a bit less than 10s.
<fnstudio>i'm now upgrading (`guix package -u`) in case that fixes my locale issue
<pkill9>i tried an older revision of guix and it's still doing it
<str1ngs>andrew: ah I've been using shepherd long before Guix existed :)
<lfam>It's definitely annoying and counter-intuitive that removing a package from your profile can require new software
<dftxbs3e>andrew, There's an NLnet grant for GNU Guix GUI tools, given the language (Scheme), it is ideal for automated language transformations, so I hope the best
<pkill9>lfam: i don't think it's downloading stuff it requires though, why would mesa be required?
<lfam>But, building a profile requires some programs. The question of which programs are required for any operation in Guix is determined by the version of Guix that is effective, controlled with `guix pull`
<str1ngs>dftxbs3e: theres' a grant for that. maybe I should apply haha
<lfam>If you ran `guix pull` since the last time you did something with the profile, there is a chance that the programs used to build profiles has changed
<lfam>In that case, you'll need to get those programs
<lfam>I actually think there is a bug report about this particular annoyance
<dftxbs3e>str1ngs, NLnet really gives grants easily, apply if you've got any interesting idea - anyways they don't take much risk because they only give the money when actual individual milestones for the bigger task are completed.
<lfam>As for why mesa is required, I don't know for sure, but mesa is depended on by thousands of programs
<joshuaBPMan>lfam: I can start the shepherd now, but $ herd start vpn gives me this error: error: connect: /home/joshua/run/shepherd/socket: No such file or directory
<dftxbs3e>str1ngs, this would be really helpful! I'm thinking packages, and then configuration management, this could include GNU Shepherd or GNU Guix service configuration
<dftxbs3e>emacs-guix is only available to Emacs users
<dftxbs3e>A tool like YaST but for GNU Guix would be really awesome, especially the "configure your own system" part. Also to deploy them remotely with guix-deploy.
<str1ngs>dftxbs3e: I was hoping to add many of these things to nomad. Since nomad is someone of an application framework. Pretty much like emacs but in scheme. Accept graphical controls are first rate.
<str1ngs>okay, you can't configure shepherd user services with Guix at all. though you really don't need to. put them in ~/.config/shepherd/init.scm
<andrew>str1ngs: Sorry, I wasn't sure what user services meant in the context of Guix System. One more question and I promise to stop spamming questions regarding Shepherd. Will my user service be automatically started if the init.scm file is present in ~/.config/shepherd or do I need to start it manually with the herd start command?
<pkill9>lfam: shouldn't all the inputs required to produce a guix profile be installed along with guix itself?
<str1ngs>andrew: I think herd start is enough to start your user services. since shepherd is already running. though you might need to test this. I'm not on guix system right now. if not just calling shepherd as a user will start your shepherd users services
<lfam>pkill9: Perhaps... but what a profile "is" is partially determined by what you have installed
<lfam>Like, there are different profile hooks that are created based on what is installed
<str1ngs>if some one can test herd status works on a guix system without manual starting sheperd for the user. that would be usefule.
<pkill9>lfam: maybe the inputs required to build a profile could be registered as gcroots with a command? could thsat work?
<lfam>pkill9: "Gcroots" are store items that are protected from being garbage collected. I can imagine some scenarios where that would help avoid downloading things but it's not clear to me how it would help with the problem of "removing a package from my profile requires downloading or building something else"
<pkill9>it would prevent the garbage collector removing them, so you wouldn't need to download them again
<pkill9>tbh i just need to know which inputs are required and get them on guix pull
<andrew_guix>nckx: For some unknown reason I received an empty message from you
<nckx>andrew_guix: Weird. It was just: Wrapping alacritty worked. Any name/e-mail you'd prefer over ‘Reported by andrew in #guix.’ before I push?
<nckx>Using /msg was just a habit; this information will of course be public in the commit log.
<andrew_guix>nckx: I reckon I can't receive private messages since I'm not a registered user on Freenode :( As for the commit log message, you can feel free to take all the credit for fixing it. Andrew is not my real name
<pkill9>it's just that i didn't know what i was trying to achieve, other than 'get it working'
<pkill9>nckx: i think all you need to do is put this in ~/.config/pulse/default.pa: https://paste.debian.net/plain/1159936 and make sure pulseaudio, and all clients using jack, are using jack2's libjack libraries, which you can do in the short term by running them with LD_LIBRARY_PATH set to $(guix build jack2)/lib
<pkill9>those are the main things i remember doing
<pkill9>and jack2 can start/stop jack with jack_control start and jack_control stop
<pkill9>when i set it up like that, i can play music with mpv, and run jack_control start, and mpv will switch to jack and continue playing
<lfam>Maybe there are Git servers that have optimized that use case
<drakonis>i'm going to go out in a limb and say it might be due to feeling like they should participate on the new hotness
<vagrantc>lfam: interestingly, the git is structured such that there is no history between releases ... e.g. there's a tag with precisely one commit for each release.
<vagrantc>lfam: so a shallow clone *might* actually be relatively efficient
<nckx>PotentialUser-80: It's hard to say anything without logs or exact messages, but everything you've said so far sounds like a bad/flaky network connection. If you run the same ‘guix system init ...’ command several times, does it always die on the same errors? (Hint: you can force it to download one thing at a time with -M1, which makes things more deterministic.)
<lfam>Hm, that may be more efficient. I think the servers should be able to reach objects from a tag more efficiently
<lfam>I don't remember the details of the problems now
<nckx>PotentialUser-80: You're not using a sneaky proxy that modifies HTTP responses, are you?
<lfam>But, the easy thing would be to raise some funds to buy more storage and host the tarballs forever, like at kernel.org
<vagrantc>lfam: the other thing i think would be interesting is to actually systematically compare the linux-libre tarballs against what guix's tarballs generated using the linux-libre deblobbing scripts produce ...
<lfam>I think that, in terms of security, we all are living in glass houses
<vagrantc>lfam: no, but i saw you propose the idea :)
***jonsger1 is now known as jonsger
<lfam>I'd like to wait to push it until we have new kernels, to avoid unnecessary rebuilds. But maybe we should look into changing those other names?
<lfam>Back to security, look at how much exploits cost. Sad to say but iOS and ChromeOS are probably the only OS vendors I would say are serious about security, if we define it as protection against 3rd party code execution or snooping
<vagrantc>i didn't bring it up in the discussion, but i think guix's priority on deterministic/reproducible builds and bootstrapping are *huge* benefits to free software ... i daresay i consider reproducibility and bootstrappability preconditions for actual software freedom
<lfam>Our world is way more focused on adding features
<lfam>Right, it's another level of making free software practical, which is important
<vagrantc>lfam: it seems mhw cranks out new updates so regularly, i'm not sure it's worth waiting, per se
<drakonis>practical free software is the route to victory
<lfam>I'd like to coordinate with mhw about queuing kernel updates so that they are already built when they hit the master branch. He used to do this on hydra.gnu.org
<lfam>I think it's best if nobody has to build their own kernel
<vagrantc>i don't quite understand the deblob scripts relationship, but apparently they argued that running deblob-check against the tarball might have also caught my issue (which was really just a typo on the hash update)
<drakonis>thus the policy to not take those packages
<lfam>There's one case where I made a personal commitment about how I would package the program, and they were grateful. This did not happen with Debian, and as a result they quit developing their program. Then, we all lost
<kmicu>lfam: there was a CVE for X11 ~week ago and pkill9's ‘guix package remove jack’ triggers downlaoding of x11 and packages that depend on it. guix/scripts/package.scm shows that it grafts by default and iiuc --no-grafts has no effect on it.
<apteryx>nckx: yeah, cars mostly. But could be used anywhere you need a resilient serial protocol.
<lfam>I see kmicu, that makes sense. However, the problem of "removing a package requires downloading some other things" can occur with or without grafts. It has to do with `guix pull` having updated the set of available software
<kmicu>lfam: pkill9 provided logs so it was pretty clear it only downloads x11 stuff.
<nckx>apteryx: Can you ‘sudo modprobe vcan’ and play around with virtual interfaces?
*apteryx wonders we should store a defconfig instead of the full .config in linux-libre: 236K /gnu/store/whzp4bzwzm0x5ifzfpbyg9dv7vhqfv3b-linux-libre-5.7.14/.config
<lfam>Although I made the 5.7 configs and am working on the 5.8 config, I am totally new to this. I'm doing it because it needed to be done and I felt some motivation, not because I'm an expert. So all advice welcome
<lfam>It does appear that the linux-libre config includes support for devices without free drivers, and that we enable them. But my understanding is that they won't actually work
<apteryx>right. I don't feel strongly about it, I just wanted to point that it's redundant. If it's actually useful to those working on linux-libre, then it's a good reason to keep it.
<lfam>I don't have a citation for the claim that they are supposed to work if installed by the user, but I'm going to keep that precedent
<vagrantc>lfam: yeah, so having such drivers is just a waste of build time ...
<nckx>apteryx: It's very useful for me as a *user*, albeit one interested in kernels & other low-level stuff. But then so is being able to grep guix.git's configs (which I don't use) for support here. Otherwise I'd first have to ‘expand’ them through a full kernel tree or something. But if making *those* minimal would ease maintenance I'd gladly give that up.
<lfam>Sure, but how much? And how much time will be wasted changing it?
<lfam>I would say that human time is worth more than computer time by a very large factor