<teddd>I have a problem when running guix environment --pure <teddd>I can't use backspace once I'm inthe shell <teddd>what is the trick to make it work ? <awb99_>I have one app that comes as an appimage. is it possible to execute those on guix? <Guest5374>Hello guix, is there a way to add an environment variable to a system service? <civodul>i think we should revert the whole series quickly <civodul>plus we still haven't recovered from the Guix Home hasty merge <civodul>i'd hope for less rushed working conditions <bsturmfels>Anyone else getting "host verification failed" from Savannah? <roptat>bsturmfels, I don't see that (from my browser) <roptat>I pull from the https url, it's working <roptat>bsturmfels, also just pushed to the ssh url, and it's working <bsturmfels>looks like OpenSSH has deprecated support for SHA1 <drakonis>when is core-updates-frozen getting merged tho? <podiki[m]>wondering too, but still haven't done the world rebuilds right? <Jeremy[m]>Given that it's not a big change (mostly tweaks and bugfixes) it might be worth it to ship 41 in the next release <brendyn>drakonis, I kinda want master to be merged into core-updates-frozen first. it makes it hard to contribute patches because everything will have to be rebased later <giaptx>is possible to run guix time-machine without root ? <giaptx>that morning I can not install Nyxt package by using guix time-machine <giaptx>guix time-machine --commit=a0804f4445 -- package -i nyxt <giaptx>but if I run sudo guix time..., it works and installed on root profile :( <giaptx>In procedure copy-file: Permission denied ***zacque is now known as zacque123
***zacque123 is now known as zacque
<PurpleSym[m]>giaptx: `guix time-machine --commit=a0804f4445 -- describe` works for me. Do you have substitutes enabled? <giaptx>PurpleSym[m]: how to check substitutes enabled? I use default guix binary from Debian 11 <PurpleSym[m]>giaptx: Not sure about Debian itself, but you could check the contents of `/etc/guix/acl`. <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. <jpoiret>to write a news.scm entry, since core-updates-frozen will be merged, the one i'll be referring to will change, right? how do i avoid that/do we just resolve those at merge time? <mothacehe>jpoiret: right, we'll have to wait for the merge before updating news.scm. We can still prepare the patch with a fake commit though. <jpoiret>alright, i'll do that then. Is it okay if I also include a french translation of my own? <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>Yes. pip3 python3 django-admin and more are stored in ~/.guix-extra-profiles/sleepygui/sleepygui/bin/ <jpoiret>ennoausberlin: is that path in the $PATH env variable after sourcing? <jpoiret>the PROFILE_DIR/etc/profile file is pretty simple and should only contain basic env variable sourcing <jpoiret>that's the culprit then, check that there is a line in PROFILE_DIR/etc/profile that does export the new PATH <ennoausberlin>jpoiret: I can not copy the content of this file from the vm, but it starts with export PATH="${GUIX_PROFILE:-/gnu/store/longhash-profile/bin${PATH:+:}$PATH" <PurpleSym[m]>giaptx: No idea what’s going on, sorry 😕 You could try to check your store’s integrity, but beyond that I don’t have any suggestions. <jpoiret>it should work in any case, but did you set GUIX_PROFILE beforehand to the profile directory? <giaptx>PurpleSym[m]: Thanks for your help <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>it's contained as a comment in the profile file <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>Maybe #:use-module (without an S) <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? <civodul>vivien: yes, there's no authentication, so beware! <roptat>we're two ocaml versions behind, but I see at least merlin doesn't build with the latest ocaml <civodul>at ci.guix and another instance here at work, i have nginx routes to return 403 there <vivien>Do you know what URI I should ban? <civodul>you can see that in guix-maintenance.git, under hydra/nginx/berlin.scm <civodul>mothacehe: does Cuirass have a command-line switch to turn it off? <civodul>it might be useful to turn it off by default to avoid bad surprises :-) <civodul>(unless you have an ulterior goal of using Cuirass instances as a botnet, of course :-)) <mothacehe> hehe, nice idea :D. No Cuirass would need some sort of token based authentication or so. Everything is open for now. <roptat>and, I plan to push the new translations this week-end <rekado_>vivien: on ci.guix.gnu.org authentication is done with client certificates; nginx requests the cert for /admin. (At least that’s how I initially set it up.) <teddd>hi, does anyone know how to properly pass otions to a ntfs filesystem in the operating system definition ? <vivien>Anyway, if it’s possible to change the specifications with the web interface, what is the meaning of the static specifications passed in the specifications file? <teddd>I try to pass "umask=000" but I get unkown option error <mothacehe>vivien: the static specifications list is the just a way to get default specifications <mothacehe>they can then be edited/deleted via the web interface <vivien>Does cuirass add these back every time it starts? <vivien>Or does it remember which ones were deleted somehow? <teddd> (options "guid=users,umask=000") <teddd>here is my config if someone has a hint <mothacehe>vivien: each time cuirass is restarted it resets them I think <mothacehe>what works exactly? you did get cuirass to build something? <vivien>Not yet, but I have my static specifications :) <vivien>I guess I’ll have to wait a minute <civodul>mothacehe: could Cuirass somehow distinguish the case where it failed to substitute a .drv file? <mothacehe> civodul: we would need to parse the log file for that I guess <civodul>mothacehe: ah right because it all happens transparently hmm <vivien>The log file does not show an error <civodul>mothacehe: what about, upon failure, checking whether the .drv exists? <civodul>"perfect is the enemy of good", right? <mothacehe>civodul: on the remote-worker side you mean? the issue is that the missing .drv is not necessarily to "root" drv <civodul>mothacehe: but if we can't retrieve a .drv we depend on, we can't retrieve the main drv either, no? <vivien>mothacehe, cuirass should build every minute, right? <mothacehe>specifications are evaluated every 5 minutes by default <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 :( <vivien>I have 2 matching processes for cuirass register, and I don’t have any checkout in the log <vivien>Oh, maybe I know the problem: the channel URL is local (/srv/git/channel.git) <vivien>I’ll try with file:///srv/git... <civodul>mothacehe: in the example above, we're probably missing the .drv we're looking for, aren't we? <civodul>i mean, substitution happens in topological order <roptat>teddd, also, if nobody can answer here, you might get a better chance sending a message to help-guix@gnu.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É <civodul>mothacehe: either we retry, or at least we mark them as "transient failure" instead of "failure", and we provide a way to restart only those <civodul>ideally we could periodically restart those in transient-failure mode <civodul>apteryx: for the patch series, i'd do a single commit reverting it all, with the range of commits mentioned in the log <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 <minikN>Could you think of a way I could trigger it if I wanted to? After all, I'm a Guix noob, maybe I did something that is obvious to you guys so you never mentioned it <podiki[m]>jonsger: perhaps related to the timezone bug in glibc that will be fixed in world rebuild? <vivien>Cuirass is starting to build useful stuff! It has built one of the packages, and now it builds other stuff. <jonsger>podiki[m]: it says: The name org.freedesktop.timedate1 was not provided by any .service files <podiki[m]>minikN: I'm also pretty new. the only issue I ran into was around an ext4 option and grub <Guest5374>* an argument that somehow modifies the environment <mothacehe> Guest5374: sharing the SSH_AUTH_SOCK won't work I guess. A work around could be to fetch local git repositories that are updated via an mcron/system script running from your user account. <Guest5374>mothacehe: .. ok, that's a way. Seems a bit hacky. Why do you think SSH_AUTH_SOCK won't work? I can imagine passing it a socket with right permissions via the environment? <mothacehe>if Cuirass is run via a shepherd service, it won't be able to see the SSH_AUTH_SOCK variable that belongs to your session <Guest5374>mothacehe .. I see what you mean .. but couldn't the permissions of that variable be altered? Also hacky of course <apteryx>is there a way to make 'git am' as lenient as 'patch' ? <apteryx>the amount of patches that don't apply is annoying <apteryx>I see I've bumped the package to 78.13.0 in my reduced rust bootstrap; will try that route on staging <civodul>apteryx: re "git am", i don't know, i always wonder why it won't apply patches that 'patch' handles just fine <apteryx>I think it's more strict; if any text can't be match, I don't think it try to 'fuzz' things. It also won't apply partially a patch, contrary to 'patch' <apteryx>so I often have better luck with the later for older submissions <apteryx>but that means some manual copy-pasting of the commit message and such <apteryx>mbakke: gstreamer 1.20 (stable) planned for the 18 of October. I'll let 1.19 live until then, as this will save some work on that day, if that's OK with everyone. <apteryx>re mozjs; bumping to 78.13.0 worked on staging too <paxton>does anyone have any tips on getting spellcheck working in ungoogled-chromium (on guix system)? i have hunspell-dict-en and aspell as well, but no dice <paxton>spell check -> english (united states) is checked, etc <lispmacs[work]>paxton: is that gnome DE? Maybe worth going to Gnome settings >> Applications and seeing if there is any settings there for chromium <paxton>lispmacs[work], this is emacs/exwm <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 :) <apteryx>hm, actually the feature freeze will be on the 18th of October; that probably leaves 1 month before an actual release. I'll attempt a downgrade to 1.18.5. ***sneek_ is now known as sneek
<vagrantc>i should probably try and package a guix tarball to get the typos fixed in time for the release candidates :) <apteryx>vagrantc: to be clear, the feature freeze mentioned above is that of gstreamer, not guix :-) <vagrantc>sure, but it's a reminder, give all the work on core-updates, i suspect a release not long to follow :) <vagrantc>and i need to get the lint typo spelling stuff in sooner than later ... but some of it is beyond my meagre guile skills <podiki[m]>anyone know what this means on a ./pre-inst-env guix refresh: "error: cannot download for this method: #<procedure git-fetch (ref hash-algo hash #:optional name #:key system guile git)>" <podiki[m]>without it correctly knows the new version, but seems refresh -u won't automatically write the update for git-fetch source? <apteryx>jpoiret: GPL doesn't have a say about non-free *services* <roptat>like, we have youtube-dl and others <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) <singpolyma>Leah might know how to tell which suppliers are good <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 <sneek>Welcome back abcdw, you have 1 message! <sneek>abcdw, ixmpp says: hi, so what's the plan for home, i notice some rde home-services still missing from guix <apteryx>Noclip[m]: anything touching the BIOS is likely to render the system unbootable (bricked) if done wrong <Noclip[m]>How likely is it that such a bios patch bricks my device? <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) <abcdw>sneek: later ask ixmpp We are slightly refactoring Guix Home right now, after that I'll be preparing and moving home services from rde to guix. <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. <wigust>abcdw: yeap, i'll do it in a minute <podiki[m]>git-send-email...if I don't have a local sendmail setup, can the output be dumped as attachments to send through another client? or as plain text to paste? <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>nckx: Every time around 3-4 weeks I reckon <minikN>I mean if I could reproduce a way to get to that broken state that would be something. <podiki[m]>or a mean person sending cosmic rays to you :( <minikN>podiki[m]: At this point you might not be far off <minikN>nckx: Knowing that my RAM is (apparently) in working order, I'm leaning towards the possibility that I'm triggering that myself somehow without recognizing it <Noclip[m]>nckx: Do you know if it's possible to charge the x230t batteries without the laptop? Is there some sort of universal adapter for this? <podiki[m]>minikN: what is the end result, /gnu/store corruption? <Noclip[m]>minikN: Using Btrfs might help with detecting hardware issues. <minikN>podiki[m]: That's the end result, yes. <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] I have most of my stuff on private repos or my nextcloud. The stuff on my pc itself is mostly redundant <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? <Noclip[m]>I don't know if any corruption error within GuixSD is recoverable but most of them probably are. <minikN1>Noclip[m] I ran guix gc --verify=contents,repair which reported all those errors. I can't remember if I ran it with elevated priviledges though. <Noclip[m]>minikN1: I'd recommend running "--verify=contents,repair" next time, this should fix all errors in the store. <civodul>PurpleSym[m]: congrats on the Haskell update! \o/ <Noclip[m]>minikN1: Without elevated priviledges it probably only executed "--verify=contents" and didn't try to repair anything. <minikN1>@nckx: My memory eludes me: Do you happen to remember if I ran the command with sudo? I think I must have tried that if it were that easy. <minikN1>Noclip[m] In any case, guess I have to find out by reinstalling it. Thanks for your help. <minikN1>Noclip[m]: Should avoid using my profiles and install everything with nix? <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. <civodul>Debian & Guix are probably the last ones even trying :-) <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)