<nckx>jgart: Sending commands in the message body to NNN@debbugs would not work, it would just send a literal ‘close 53330’ reply. See <https://debbugs.gnu.org/server-control.html> for the available commands and the ‘control server’ address that accepts them.
<lfam>It was some of the oldest (if not the oldest) code in Guix
<nckx>lfam: Interesting, I didn't know that factoid :-) IIRC it was also unusual in requiring a locally running nix-daemon, rather than the ‘fetch and parse the nixpkg from GitHub’ that people expected from other importers.
<Ribby>I was figuring if a person relying on free internet service, needs to get on the boot installation's updates, what would be the options? I'm not going to blame for the situation in grasping straws.
<lfam>It might not work in the Guix installer, however. It requires an external kernel module that our installer doesn't include
<lfam>We should add the module to the installer for the future
<xelxebar>rekado_: Hey! Thanks for your pointers yesterday. I reproduced the missing Euler font error within a container. (FWIW, I'm already running on a guix system anyway, though).
<Ribby>The real question is if there is any wifi that could help download updates during a boot OS installation? Ethernet is obvious to go. Even a person relying on free internet service, ought to know how to use these cables for the boot updates.
<lfam>I don't think there is any computer that comes with a supported wifi chip built-in
<xelxebar>rekado_: Still just a pebcak issue? If not, I'll file a report.
<Ribby>Of course, I am not sure if wifi can access private networks during the boot. Things could get very complicated. In fact, I am not sure how much use wifi would be compared to a direct ethernet connection. I suppose that maybe one cannot connect to the router or another client that allows download?
<lfam>So, on version-1.4.0, we updated python-tomli. This package has ~4800 dependents. But at least several hundred of them now fail to biuld
<rekado_>xelxebar: please file a bug report and Cc me. Thank you!
<Ribby>Is there a ethernet cable variant that can connect to another computer with internet access? I think such a device would be more useful than a wifi. It would be at least much faster than wifi. The only downside is that another computer would be preferably your owns!
<Ribby>Otherwise, I guess you can unplug the public service's ethernet cable from their workstations. It sounds a bit unethical since you are using service without registered user authentication, but nevertheless, free direct internet service!
<nckx>lfam: Was the version-1.4 merge really the final rebuild?
<lfam>I want other people to try their hand at them
<lfam>What I was doing before was not sustainable for me
<Ribby>vagrantc: So the base OS files are on the servers and the boot install is just the core, bare bones, or installer? There is no OS without the server updates/upgrades then? I get that guix development is a ambitious feat. No doubt about it.
<lfam>If our security team is completely staffed by volunteers, it needs to have several of them.
<nckx>lfam: Just the volume or do you think your workflow was, in retrospect, flawed? What I'm doing here is certainly inefficient, but then I hardly ever graft things. I think it's been literal years.
<lfam>It was the unrelenting regularity... IMO, that's something that should be done by somebody that is paid, or by a team of volunteers spreading the work
<nckx>Even having to type ‘define-package…inherit…replacement’ is, honestly, a bit stupid. A waste of human time.
<lfam>Well, it's Scheme. I'm sure that somebody could write a script to handle it
<lfam>Anyways, to summarize, I burnt out on doing it as a volunteer.
<lfam>I would be ecstatic to be on-call for it if it was funded
<lfam>I would also join a team of volunteers. Already I still push security updates
<nckx>Somebody could. Nobody did. Doesn't bode well. I agree that dumping it all on one person at a time leaves nobody in the end.
<lfam>So, the only difference from before in terms of my work is that you can't count of me
<tribals>I'm trying to use host guix-daemon from within `guix shell --container`. I've first tried to share daemon socket only, this doesn't work - I can't install package. Then I've tried to share the whole /var/guix. It doesn't work either - still can't install package. But surprising thing is that after doing that I've noticed that passing whole /var/guix breaks my default profile on the host!
<v1dl00fyuq6f[m]>the line below seems identical, but it's checking for `python` executable not for `python3`
<nckx>‘your arrow should be pointing from’, not ‘to’.
<v1dl00fyuq6f[m]>s/the line below seems identical, but it's checking for `python` executable not for `python3`/the line below seems identical, but it's checking for `python` executable not for `python3`/
<Ribby>usb ethernet adapter cannot connect to another computer with net to get net? It seems that it is only useful for computers without ethernet ports. A special/unlikely scenario, since most hardware stays in the case intact instead of outside.
<apteryx>it stillp passes its test suite after all, and tomli is just a toml parser
<vagrantc>Ribby: there's nothing special about a bridged connection, it's just networking.
<lfam>apteryx: I couldn't tell from the upstream bug report if they were too careful or if there was really some issue. I did notice that it's not enough to relax the requirements in setup.py: There's a run-time check as well
<apteryx>i've pushed that fix already by the way (for black)
<dumbdemic[m]>Is there a cli command to view the contents of a package scheme file in my channels ie the scheme file stumpwm when I install via `guix install stumpwm`? Or is this available on a website somewhere?
<numerobis>@abrenon: Thanks! For now I'm trying to use it, but at some point when I have spare time I may try to package it. On a different subject, is it "safe" to upgrade the system after not doing so for about a year, or should I expect certain things to break?
<abrenon>experience on other system would suggest pessimism, but I've recently seen a message on the mailing list from people amazed to see they could upgrade their system without a hassle after a very long time (was it one or two years ? it was long anyway)
<abrenon>in any case you need to update guix itself first, with guix pull, and if that works I see no reason why the following reconfigure should fail
<abrenon>you may perhaps have issues with the little amount of stateful stuff needed, I once had issues with GDM because of what was left in /var/lib
<abrenon>(but I think it was a left-over from an install of another distro because I had it on the first boot, it wasn't after an upgrade)
<abrenon>also, good news: packaging and using is essentially the same thing, there's a little overhead of cleanup and social interactions to get it accepted to the official repos, but the definition you'll need to try it is the package itself
<jpoiret>one thing you'll have to do is reboot right after `guix system reconfigure` to let the newer guix daemon start
<lilyp>v1dl00fyuq6f[m]: yes, pardon my inclusive language
<v1dl00fyuq6f[m]><lilyp> "v1dl00fyuq6f: yes, pardon my..." <- so GDM sources the `~/.bash_profile` before session startup to make the variables available there?
<attila_lendvai>guix pull fails for me with "failed to start SSH session: Unable to exchange encryption keys", even though ssh works from the same account to the same server. is guix pull going through a different lib? i'm trying to use it with a ed25519 key.
<abrenon>v1dl00fyuq6f[m]: I'm not sure, I think it actually dependson the X session chosen from GDM
<abrenon>ohhh ? that's good to know, thanks for the pointer (it'll be useful when I have become a hacker and use emacs for everything like WM 😉)
<attila_lendvai>lilyp, what shall i do in such a situation? sending a patch to guix-patches is quite a hurdle only to increase a version number, and then potentially getting forgotten in the inflow to guix-patches... is that nevertheless the generally expected way in such a case?
<lilyp>attila_lendvai: just submit your patch as [PATCH core-updates], but remember to check whether core-updates already has it first
<attila_lendvai>lilyp, ok, will do the dance then. it doesn't have it, according to git show core-updates:gnu/packages/ssh.scm
<mbakke>mothacehe: oh indeed, my config had "console=ttyS0" in kernel-arguments, removing that made boot output appear on the graphic console ... I'm fairly certain console=ttyS0 did work previously on GTK, but can live with this quirk.
<abrenon>ohhh python-dbusmock isn't available and failed to build locally : (
<apteryx>there were some fixes yesterday that probably fixed it; have you tried 'guix pull'?
<abrenon>command "python" "-c" "import setuptools, tokenize;… failed with exit code 1 (shouldn't it be python3 ??)
<apteryx>builds fine here; with guix at 547625504c5560d66ac80405129ffb938f5200db
<abrenon>apteryx: I've pulled right before, I never reconfigure without pulling
<yewscion>Hey All, I've looked online and I've come up empty-handed for some info: I've recently been getting a guile error (`Throw to key `match-error'`) when I try to `guix pull` my personal repository. I can't figure out what has changed; If I disable authentication it works fine, but I'd rather not do that to work around the issue. What problems might
<wnklmnn>gnome-music seems to be missing python aswell :)
<mbakke>efraim: removing sitecustomize from the bootstrap sounds like a good idea; probably you'll need to add (old-style) PYTHONPATH as a native-search-path
<nij->Hi! I'm confused with how guix home works in principle. I assume the point of it is to provide a "stateless" home, in the sense that the home-config file is used as a source of truth declaring the home.
<nij->However, most of the time we need to express the dotfiles in other langs, like bash. If I put all bash codes in the home-config file, I'd need to do lots of silly escaping.
<nckx>apteryx: …good moin to you too, as well, by the way! :)
<apteryx>if I instead open the email manually from the menu (File -> Open -> Saved Message...) it works
<nckx>So I want to personally apologise for giving v1dl00fyuq6f, banned here as M6piz7wk last December, a second chance and waiting too long whilst they happily headed down the same dark road that led them there. It was probably clear to many how inevitable that was long before it was clear to me. Sorry.
<nckx>Now they've been banned not just from #guix but from Libera, and the Guix ban is permanent.
<notmaximed>nij-: You could put your "guix home" configuration in a dedicated directory together will files included with 'local-file', and put all that under version control (e.g. git, regularily making tarball copies, ...).
*mbakke pushed a bunch of post-merge fixes, apparently Python patch upgrades includes setuptools, which is currently in disarray
<kennyballou>mbakke: is this why gnome-music and down are failing? I think the bottom was python-dbusmock(?)
<nij->notmaximed: That makes sense. And it's definitely more declarative than using gnu-stow.
<nij->If I do that, and if I change the content of say my bashrc source file. Would guix home be clever enough to detect the change and generate a new build?
<notmaximed>nij-: Unless something has changed, it's more like guix (including "guix home" and "guix system") in general is too dumb to know that things don't have to be build again if no file was modified
<notmaximed>"guix shell" is as exception: if the manifest wasn't modified, it reuses an old build result (even if any 'local-file' it uses were modified)
<mbakke>kennyballou: the gnome-music failure seems unrelated looking at its log file ... I can't test myself atm as I'm still waiting for 5 Rust compilers to build
<notmaximed>Anyway, unless your 'local-file' things are millions of lines long or something, you probably don't have to worry about the time 'guix home' takes to intern the file
<mbakke>kennyballou: looking at some other commits, I think the problem is that its native-inputs lack 'python', as it is no longer propagated from Meson
<kennyballou>mbakke: okay, thanks. I'm barely digging into it, but is there a way to exclude it from the gnome service? I don't actually want it, and there's probably other gnome packages I don't need/want
<lfam>I just fixed gnome-music kennyballou and mbakke
<nckx>porcupirate: No, you'll have to (replace 'configure …) and call the configure script yourself. If it doesn't accept CONFIG_SHELL it probably won't accept the majority of ‘standard’ (autotools) anyway.
<dongcarl>I figured out that the mingw-w64 builds are failing because of the newly introduced `--enable-compressed-debug-sections=all` flag to the base binutils... However, I'm not sure why it's failing
<ytc>sometimes, while a guix update is working it suddenly pauses. and i have to cancel the process and re-run the command. do you have that problem either?
<SeerLite[m]>vldn: I guess you could but I'm not sure if it's good practice. I don't see any packages in the guix channel that do it like that
<SeerLite[m]>ytc: Does it happen when it's downloading substitutes? Like after downloading one it suddenly stops? That happened to me a few times when I first installed Guix but haven't had that problem since
<ytc>SeerLite[m]: no, it usually does that in the "make" process.
<ytc>it halted again. i should wait for the substitutes i guess.
<SeerLite[m]>Hey so what's done when a (Rust) package requires a version of a dependency that's older than the one available in Guix? Just force it to use the newer version? Alacritty wants bitflags<1.3.0 but Guix has 1.3.2
<nckx>SeerLite[m]: What does ^version mean in Rust?
<SeerLite[m]>Alacritty asks for an older version of nix, which doesn't have the "1.1" patch
<SeerLite[m]>So to fix this what I have to do is patch Alacritty to use a newer nix
<porcupirate>Scummc is frustrating. Which is better: make a hidden package that installs everything to a tarball, then make a public package that extracts that tarball to the package's output, or make a package with an install phase that copies everything from a particular directory with a name that depends on the compiler version and target?