<PurpleSym[m]>giaptx: That looks alright. Not sure why Guix is not simply fetching the substitutes for you and tries to build. Any reason you need this specific commit?
<PurpleSym[m]>apteryx: I merged wip-haskell. You can remove it from CI. Thank you :)
<giaptx>PurpleSym[m]: I want to upgrade nyxt 2.1.1 -> 2.2.0. Should I choose a good commit to make sure guix will fetch?
<jpoiret>mothacehe: alright, I added a warning that the `wayland?` default will change by delaying it and sanitizing it, should I also update the documentation as if the change had already occured? I was thinking instead that we could change the default now along with the documentation and just warn users that the default has changed for the next 2 months
<jpoiret>it's 1) less confusing imo 2) on core-updates-frozen so introducing a breaking change for some configurations is more acceptable when merging (not so sure though)
<PurpleSym[m]>giaptx: The normal workflow would be to `guix pull`, which just fetches the latest commit from master, and then to `guix package -u`, which updates all installed packages. You can also omit the `--commit` on time-machine, which would give you the latest version.
<mothacehe>jpoiret: that would mean that every GDM user will have a warning at reconfigure for two months, right?
<jpoiret>unless they do set `wayland?` to something other than default, but yes. The same would happen if we warn users _before_ the change though
<jpoiret>I don't really think there's a perfect solution, but if we warn users after the change, at least the documentation changes will be in place as well and they can refer to that
<mothacehe>seems fair to me, let's see what people think on the mailing list :)
<lilyp>I think we should keep the number of breaking changes forced by core-updates as low as possible.
<jpoiret>alright, i'll work on the doc and send the patch then! (the 'X Window' node is getting obsolete though now)
<mothacehe>yes we would need to introduce a new wayland section
<lilyp>I'm willing to bet that lots of people will have troubles with unaccounted edge cases anyway, best to do damage control
<jpoiret>lilyp: is there any other time we could introduce breaking changes? the change in question can be reverted by just setting (wayland? #f) in the config
<jpoiret>it's just that GDM being Wayland native by default would be a better out of the box experience
<lilyp>For the wayland thing we could set an arbitrary date, e.g. now + 6 months
<jpoiret>alright, and so warn all GDM users that the default will change on `that-fateful-day`?
<jpoiret>at least those that use the default value
<jpoiret>i think i'll just send a mail to the mailing list and we'll agree on how to go forward from there (bug, or patch? I've already written the warning anyways)
<lilyp>Personally, I'd opt to announce now (via news entry maybe) that the flag has been introduced and that it might become the default in the future.
<lilyp>Then when said future arrives, we warn about the recent change for those who haven't noticed yet.
<giaptx>PurpleSym[m]: I don't want to use guix pull, because after pulling the emacs-guix is break :(. So I just want to upgrade nyxt by using guix time-machine
<PurpleSym[m]>giaptx: I see. Perhaps it’s a bad revision and you can just omit `--commit`?
<ennoausberlin>Hello. I follow the Basic setup with manifests chapter of the guix cookbook. I was able to create a manifest file and to install it into an extra profile. It is listed with guix package --list-profiles. But if I source it, the binaries are not available. Did I miss a step?
<jpoiret>are the binaries present in profile-dir/bin?
<ennoausberlin>jpoiret: GUIX_PROFILE point to /home/enno/.config/guix/current
<jpoiret>if you set GUIX_PROFILE, the environment variables will be setup with PROFILE_DIR/bin and such, rather than using /gnu/store/the-profile-in-the-store/bin so it's easier to know if your profile's dirs have been added to the path
<jpoiret>maybe try `hash -r` after sourcing the profile
<ennoausberlin>jpoiret: So if I understand you correctly: To activate a certain profile I have to - in my case - set GUIX_PROFILE to say /home/enno/.guix-extra-profiles/sleepygui/sleepygui and only afterwards source $GUIX_PROFILE/etc/profile
<jpoiret>oh, right, i understand what was happening! since GUIX_PROFILE was already set to something else, the OTHER_GUIX_PROFILE/etc/profile script tried to add $GUIX_PROFILE/bin to the PATH instead of the absolute store name, but since GUIX_PROFILE was set to the old one it wasn't considering the right profile
<ennoausberlin>jpoiret: I somehow ignored the comment in the profile file. My fault. These concepts are new to me. It may take some time until I am used to them. If I follow the cookbook, then multiple profiles can be active at the same time?
<jpoiret>yes, GUIX_PROFILE is simply a way to make your environment variables look cleaner, but they don't matter once the etc/profile files have been sourced iirc, so you can just follow the same procedure multiple times to activate different profiles (note that the last profile will prevail over the other ones if they contain the same binaries for
<ennoausberlin>jpoiret: Now I got the picture. Thank you for the clarification. As I see now, everything is exactly described in the cookbook, but as non native speaker dense documentation is sometimes hard to grab. Thank you
<jpoiret>hmmmm, about writing the news entry in eg french, do i refer readers to "(guix) X Window" (in english) which has been updated or "(guix.fr) Système de fenêtrage X" which hasn't?
***xgqtd is now known as xgqt
<attila_lendvai>my general impression of the doc is that it's a free-flowing, somewhat verbose text that requires more effort to scan/parse than it could be if it were less about grammatically correct sentences, and more about structure (bullet lists, warning panels, quoted code, etc)
<ennoausberlin>Hello. Is it possible to include a channel in the systems config.scm declaration? I'd like to have flatwhatson by default included
<jpoiret>ennoausberlin i don't think there's a way to do that yet, as channels are merged into the guix installation on `guix pull` only iirc, so when you run `guix system reconfigure config.scm`, your guix installation already contains the channels
<jpoiret>that's why you can just #:use-modules (your channel module)
<vivien>So, I’d like to set up the Cuirass service. I specified a specifications, but the web page shows no specifications. Also, it seems that the web interface lets me add specifications, without any form of authentication!
<roptat>finally took the time yesterday to push most waiting ocaml patches from the list, plus some additional updates :)
<vivien>Is it the normal way cuirass works? Does anyone have a working cuirass configuration that does use the specifications given in the configuration and not accept new specifications without authentication?
<roptat>teddd, your message got kinda lost in the matrix storm, and I don't know how to help you, sorry. it looks like you're doing things correctly, although I'm not sure umask makes any sense for an ntfs file-system?
<vivien>mothacehe, it looks like cuirass reports heap, threads and file descriptors every 10 minutes
<vivien>However, /var/log/cuirass/ is still empty and it does not appear to build anything :(
<roptat>teddd, also, if nobody can answer here, you might get a better chance sending a message to firstname.lastname@example.org (the first message is moderated by a human, so it can take up to 24 hours to get through)
<mothacehe>civodul: oh then yes, I see what you mean! We could probably use that to detect those failures. But then whould we retry? If the publish server is already congested, this won't necessarily help.
<apteryx>for reverting a bunch of commits, do we prefer a single commit with the reverted changes, or one revert per commitÉ
<minikN>nckx podiki[m] in case you're interested, I ran the memtest86 yesterday, took about 6 hours in total for four passes. 0 errors, however on two of zhe four passes I got the warning that my RAM "may be vulnerable to high frequency row hammer bit flips". But according to their docs, that doesn't sound link a valid indication for a bad module.
<podiki[m]>minikN: I'm guessing that is a pretty general warning of that type of attack, shouldn't affect stability. Not sure what else you can test, maybe something that stresses power and disk writes?
<minikN>podiki[m]: Running out of ideas as well. I already ran a test nckx suggested (forgot the name) to verify the ssd didn't cause it.
<minikN>Don't know but something tells me this isn't hardware related.
<podiki[m]>yeah, the only thing I can think of is perhaps unstable power supply or something related to e.g. ssd controller from motherboard
<podiki[m]>but anyway, if it was hardware, you would see it eventually somewhere else
<jonsger>hm, I'm using Gnome on core-updates-frozen and I can't set my timezone in Gnomes Settings to Berlin,DE. It gets always reset to London, UK
<paxton>curiously i have another machine with the same package manifest and on the same guix generation that it *is* working on, also on emacs/exwm, but haven't been able to look closely enough into the config differences etc to see what could be causing it to work on one and not the other
<mbakke>apteryx: sounds good, thanks for checking :)
<jpoiret>alrighty then! off we go (i was under the impression that it wasn't open-source and had been building some elf rpath patching tools to make it play nice with guix, guess this was all for nothing aha)
<apteryx>jpoiret: the GNU Affero GPL says something about non-free services in the sense that a software licensed under such license cannot be used as a software as a service unless the source (including any modifications) is made available
<podiki[m]>to answer my own question: doesn't seem like "refresh -u" does anything for git-fetch (though seems like it wouldn't be a hard addition?)
<podiki[m]>anyway, turns out these packages have releases too, no need to git-fetch
<Noclip[m]>nckx: IIrc you have a Thinkpad x230 tablet, right? Do you have by chance any experience with getting a replacement battery for it?
*nckx literally just turned it on to check #guix ☺ No, I haven't. I've been *extremely* lucky with the 3 that I've bought over the years, and they all came with Lenovo batteries in excellent condish.
<nckx>I'd actually like to know what you find out, Noclip[m], because I've have been worrying about what to do when they do degrade.
<nckx>Apparently the after-market brands are… generally shit?
<nckx>minikN: This is not good. You're right that rowhammer isn't relevant here. How long did you use the installed systems before this started happening?
<podiki[m]>buying after market batteries in general seems pretty hit or miss (fingers crossed good on the random one for a dell laptop, so far better capacity than the original)
<Noclip[m]>nckx: There seem to be a lot of after-market brands but the big issue with all of those is (according to what I've read in many places) that the x230t has a bios whitelist which prevents any non-original batteries from being recharged by the laptop.
<singpolyma>Noclip[m]: if you libreboot it I expect that issue goes away
<singpolyma>I've heard these earlier Thinkpad X line systems are unbrickable, but I dunno what extra hardware you need for recovery in the worst case
<apteryx>you should understand the risks and what recovering would entail (no expert, but probably something like a flash programmer or a new BIOS chip, which is hopefully sitting on a socket rather than soldered)
<apteryx>I think programming the BIOS for libreboot on a x200 for example could be done without unsoldering anything, so on such system if something goes wrong with the software, you should be able to reflash what was there before starting to recover
<apteryx>rekado might be able to tell more, I think they've gone through the process themselves
<Noclip[m]>Until a few days ago I thought getting a replacement battery for an old thinkpad would be super easy but it looks like the opposite is the case.
<podiki[m]>the wrinkle is that I use protonmail for these emails, so I'd need the bridge setup I guess. would be easier to just use the webmail client
<podiki[m]>(I have other emails, but trying to keep things organized)
<apteryx>mbakke: it could be neat to have a way to annotate in the package definitions a the upstream release version scheme (such as even minor vesion == stable release) so that 'guix refresh' wouldn't misguide us :-)
<jpoiret>podiki[m] i am exactly in the same boat as you, i'm currently looking to package the bridge
<jpoiret>in the meantime, i've been sending plaintext patches by just pasting the contents of `git format-patch`
<podiki[m]>I see flatpak has the bridge, and these are flatpak patches I'm submitting...:p
<minikN>Noclip[m]: I was on btrfs the 3rd time it happened. I ran thr scrub test as well as other test, all returned with no error
<Noclip[m]>minikN: Mhh, that means the corrupted data has been written and read correctly to/from the filesystem.
<minikN>podiki[m]: That being said, I don't know for how long my store had been broken, I just ran gnu gc --verify once the install cmd returned errors, but I guess that doesn't mean that pulling from a broken channel, like I described yesterday or the day before actually caused the corruption (?). Might have been like that before and I only noticed then
<Noclip[m]>minikN: So you ended up with corrupted files?
<minikN>Noclip[m]: No Idea, way out of my comfort zone here. All I know is that I've had this situation 4 times the past 3 months, but every check I run tells me my hw is ok
<Noclip[m]>Or were there missing files or something else entirely?
<minikN>Noclip[m]: Sec, let me get to my pc, on phone rn
<Noclip[m]>minikN: You should probably find out how exactly the store broke.
<Noclip[m]>minikN: And keept using Btrfs: If this is caused by faulty hardware then it's very likely that it doesn't only affect the gnu store but also everything else you've stored on your connected drives.
<Noclip[m]>minikN: Ohh and keep good backups of all your important data on several external drives!
<podiki[m]>store corruption at least should be "easy" to fix since it is all generated by guix; but yes annoying if it keeps happening and you need to regenerate it all
<minikN1>Noclip[m] Having a hard time connecting on my bnc atm, so here I am
<Noclip[m]>minikN1: If you can you should consider using another computer for backup replication and scrubbing as a computer with bad ram could corrupt all connected storage devices.
<minikN1>So in short, this has happened 4 times now. First two on ext4, then once on btrfs, when on ext4 again (inbetween I always did a complete sdd wipe and reinstall). At some point, I don't know how, my store gets corrupted (I run guix gc --verify and it pops ups with endless errors saying hashes are wrong and also this:
<minikN1>Noclip[m] Yesterday i triggered it by (I believe) pulling from a broken channel (I added a package definition to my channel that had an error). After I pulled it errored out saying it couldn't build the package cache derivation, then all of a sudden the guix install command would always return "unknown package manifest"(or something along those
<minikN1>lines) for every package, then I ran the gc command and found out what I just told you
<Noclip[m]>minikN1: The fact that Btrfs scrubbing didn't return any errors should mean that neither your SSD nor it's connectors (cables and adapters which connect the SSD to the motherboard) caused the issues.
<vagrantc>hrm, seems like building guix on debian i386 with guile-3.0 has a different error altogether ...
<minikN1>Noclip[m] Well, hardware failure was the leading opinion here. I changed fs -> same thing happens, I changed ssd -> same thing happens. Every hw check I was suppose to run says I'm good. So beats me really
<podiki[m]>with git format-patches should I just copy that into an email or attach? which is preferred?
<jpoiret>hmmmmmmmm seems like go is a pain, i won't package proton-bridge in the end (lol @ the gopherjs dependency, this is just an IMAP/SMTP server for christ's sake)
<jpoiret>podiki[m] i just copy them plaintext into the email (remember to select plain text on the right of the protonmail compose window)
<podiki[m]>jpoiret: got it, thanks. I do plaintext by default whenever I can anyway. (really should get protonmail in my mu4e setup...)
<Noclip[m]>minikN1: Actually I don't think it's a hardware issue. Maybe it could still be a RAM issue but this seems very unlikely especially because you already tested your RAM.
<minikN1>Noclip[m] If it's not a hardware issue I should be able to reproduce it somehow. I wiped my ssd again yesterday and haven't installed it again yet. But I guess I could reproduce the same situation I had again
<Noclip[m]>minikN1: I got an idea: Use Btrfs and install the Nix package manager in addition to the (already installed) guix package manager: Nix should be the piece of software which has the most similarities with guix so if the issue is not caused by guix itself then it should most likely also appear in nix. This of course means that you not just need to install nix but you also need to use it on a regular basis.
<Noclip[m]>minikN1: If it happens next time then don't wipe your disk directly but instead leave it untouched and report the issue here.
<Noclip[m]>People can (probably) only help you at diagnosing the issue if the raw data and all the logs are still available.
<Noclip[m]>minikN1: Also you probably won't need to wipe your entire disk just because the gnu store corrupted.
<minikN1>Noclip[m] I talked to some people here every time it happened (and before I wiped). That's how the hw issue opinion came to be.
<jpoiret>podiki[m] tbh it is the one thing that's still making me consider having my own mail server rather than protonmail: needing the bridge to send mail the Usual Way™
<Noclip[m]>IIrc guix can clean the store on it's own with just a simple cmd command.
<minikN1>Noclip[m] But what about my guix profiles and channels? Remember, last time it may have gotten triggered by my channel. Wouldn't work then when using Nix
<minikN1>Noclip[m] Really? Someone should have told me that :o
<Noclip[m]>minikN1: Unless you completely mess up your partition table or filesystem itself you usually don't need to wipe your entire disk.
<Noclip[m]>minikN1: I never wiped my ssd in this laptop, not even after I bought the device: I just resized the preinstalled Windows partition and then installed Linux.
<minikN1>Noclip[m] I'm still new to Guix. After reporting my issue here I was under the impression a corrupted state is not recoverable. No one told me otherwise.
<Noclip[m]>minikN1: Are you use Guix System or just the guix package manager on top of another distro?
<minikN1>Noclip[m]: Another (totally offtopic question). Do you know how I would give my main user write access to a drive I added as a file-system record in my config.scm (Other than using chown that is)? Is there a special way in Guix to do that?
<Noclip[m]>minikN1: I cannot imagine how your custom profiles/channels could lead to a corrupted store. I don't know enough about guix to say this for sure but I don't think it should be possible to corrupt the store by using custom profiles/channels.
<Noclip[m]>minikN1: Also I only recommend using nix for diagnostic purposes and didn't mean that you should replace guix with nix. (You can use nix on top of GuixSD!)
<Noclip[m]>minikN1: That depends on the used mount options, the filesystem on the drive and the current permission layout.
<Noclip[m]>minikN1: If your access is currently blocked by the permission layout then the easiest way to get access is by changing the permission layout (with chown and chmod for example).
<jpoiret>who had the brilliant idea that you could import specific commits in go??? this is just a big f-u to distribution maintainers
<jpoiret>"hm yes let me replace the standard go library with this version from github with a specific commit, all without stating why"
<jpoiret>i guess trying to package qt go bindings was a doomed idea from the beginning
<jpoiret>i'm trying to package protonmail-bridge. arch aur cheats by just `go get`ing this. Looks like most distributions just don't package go libs and let go just build everything itself without packaging.
<singpolyma>jpoiret: isn't fetching a particular commit pretty easy in guix anyway?
<jpoiret>it is, just that you can have version mismatches that do not even follow any sort of semantic versioning
<jpoiret>package 1 wants commit a, package 2 wants commit b, let them fight
<jpoiret>in the end i realized that gopherjs doesn't have any version for go 14 anyways so i don't think i'll be able to package it (unless i also update go to 17, which for obvious reasons i'm not going to do)
<Noclip[m]>minikN1: You're talking about "/mnt/games"? You need to use chown and chmod there.
<jpoiret>is there a Guix policy that would prevent just using go to fetch the go package and all of its dependencies in one guix package? i agree that vendoring is terrible, but at least since they're using precise versioning everything should always hash to the same value anyways
<cbaines>jpoiret, that would mean the information Guix has about dependencies would be wrong, and that would have knock on effects on features like --with-input for example. Generally if they're separate bits of software, they should be packaged separately.
<jpoiret>since go statically links everything anyways, this'll just duplicate the source downloading compared to the current "package everything separately" solution
<jpoiret>cbaines i mean, not even giving go dependencies in (package (inputs))
<jpoiret>but it's true that then we would not have --with-input
<singpolyma>Best choice: add support to the go importer for this kind of import, then use it
<jpoiret>yes but then, should it fall to the maintainer to check if packages work with newer versions of dependencies (developers in go don't bother to check since they vendor everything), or maintain a separate version of every package for every other package that depends on it?
<apteryx>jpoiret: one go guix package that bundles everything would somewhat defeat the purpose of using guix, which allows to keep track of what sources got used for a build and inspect dependency relationships
<apteryx>(granted, some go packages are currently packaged like this, short of being able to do better, due to lack of go module support in the go build system for example)
<cbaines>jpoiret, pretty much, that's one thing a distro/package manager generally does. Of course, running the upstream test suite is very helpful when doing this
<jpoiret>hm, that's one hell of a task then, given that golang.scm is ~9kLOC
<cbaines>jpoiret, it's a trade off. I think it's preferable to keep the number of versions a package to a minimum generally (ideally just the latest one).
<cbaines>even if you had packages for lots of versions of each package, you'd still have to consider which versions things should use (even if that's copying some lockfile somewhere)