<tribals>Tried to use Wayback Machine, unfortunately (and expected), tarballs are not archived. No sure I can find exactly same tarball on other URL... <nckx>Pretty sure that logs.guix link had an URL, you might need to scroll down a bit. Archive.org actually has a surprising number of random tarballs, but it's luck of the draw. G'night. <patched[m]>Yesterday I spoke about guix freezing just post-boot, no matter the generation I used. I followed some notes on recovering using chroot from another partition with the help of notes kindly provided by apteryx. Disabling elogin-service "solves" it. I do wonder if it is connected to this issue: https://issues.guix.gnu.org/55444 <lagash>Hello Guixers! I believe I asked sometime ago if there were any publicly-accessible Guix "shell services" akin to, say, SDF or OpenShells, and some folks here were considering it - any updates or progress? <apteryx>patched[m]: hey, glad to know you found the culprit service! <apteryx>that's funny I think i have something in store for that <apteryx>but I had kept from finishing it because I thought it was not solving a real problem <apteryx>if I have some time tonight, I'll try to revive the patch set ***aeka` is now known as aeka
<Gooberpatrol66>there's 115 webkit* objects in my store, and most of them i built myself <Gooberpatrol66>i moved most of my gentoo packages to guix, thinking it would build faster, but it's actually slower because i have the -webkit useflag set to off globally in gentoo <oriansj>Gooberpatrol66: eww and lynx is always an option <Gooberpatrol66>i don't actually have it installed, it's pulled in by other programs <jgarteee>when trying to clone on ubuntu I get the above error <jgarteee>any thoughts on what the issue might be? <ulfvonbelow>whenever I reconfigure, some directories in /var/run get their permissions all messed up. /var/run/dovecot becomes owned by knot:knot, and /var/run/knot becomes owned by root:root (should be owned by knot:knot). Any idea what's causing this? <ulfvonbelow>out of curiosity, is there a well-defined order in which activation services run? <bjc>i don't think so, past making sure dependencies are started before their dependents ***lukedashjr is now known as luke-jr
<dust_>Is there a Discourse site for Guix ? <PotentialUser-42>Hi. Its me again. I want to define a package for python-ttkthemes. When I just use the pypi importer it complains that the tkinter module is not found. Do I have to specify a python variant on native or propagated inputs? <iyzsong-w>PotentialUser-42: i think if it fails when 'guix import' then you have to write the package definition by hand, if fails when build the imported definition, then you can add 'python:tk' (maybe) to its inputs <reyman>Hi @mesaoptimizer did you have some success with keyboard problem at boot when grub is crypted ? <ulfvonbelow>hey #guix, I think I found out what was causing those weird /var/run permissions issues <ulfvonbelow>if you go look at %dovecot-activation in gnu/services/mail.scm, you'll see that it defines mkdir-p/perms <ulfvonbelow>turns out the activation service evaluates those snippets via `primitive-load', not by executing them in a new guile process <ulfvonbelow>so when it defines mkdir-p/perms, the local-to-current-module definition overrides the one from (gnu build activation) for all later activation snippets <ulfvonbelow>and the version in %dovecot-activation has a copy-paste bug, where the author forgot to replace "/var/run/dovecot" with `directory' <ulfvonbelow>so when knot's activation snippet calls mkdir-p/perms, it makes knot the owner of dovecot's run directory, and of course, doesn't change the owner of knot's run directory, so it gets left as root <fnstudio>hi, there's this guix (on a foreign distro) installation that i'm trying to upgrade after 6 months something, but the upgrade gets stuck at the 'check' phase <ulfvonbelow>when you say "stuck", do you mean it errors out or it simply sits, apparently forever? <fnstudio>i left it there the whole day before killing it yesterday, it must have been 6h <ulfvonbelow>two things to try: --verbosity=3, to see where the build is at, and 'sudo strace -p <frozen-pid>' <fnstudio>great, trying with verbosity first, will update here, kthanks! <fnstudio>there seem to be some errors in the emacs-deferred package <fnstudio>which are now shown thanks to the increased verbosity <fnstudio>the most worrying of such errors is a "wrong number of arguments" <ulfvonbelow>when you say "trying to upgrade", do you mean upgrading packages ("guix upgrade" or "guix package -u") or upgrading guix ("guix pull")? <fnstudio>upgrading the packages, sorry, i should have made that clearer <fnstudio>well yeah, i'd think so, i've run guix pull - anything else i should check? <ulfvonbelow>you could triple-check with 'guix describe', but if guix pull succeeded, it should indeed be up to date <fnstudio>yeah, it says generation 6, today's date, current, a guix hash, it refers to the master branch and specify the commit number <ulfvonbelow>fnstudio: I see a similar problem when I try building emacs-deferred on my end. Perhaps the package is broken at present. If you know what package is using it, you could keep from upgrading it using --do-not-upgrade <fnstudio>oh this is super helpful!! thanks so much <ulfvonbelow>I sometimes have to do that for updating profiles with lots of packages installed <fnstudio>and it super nice to know it's not strictly an issue with my installation <fnstudio>lol works like a charm now, it's crunching packages and derivations <PotentialUser-42>iyzsong[m] I will give it a try. I saw colon notation and backtick notation at some examples but a python:tk example was not found by grepping other guix packages. Thank you <efraim>PotentialUser-42: depending on the style try ("python:tk" ,python "tk") or (list python "tk") <PotentialUser-42>efraim I put this into the package definition and it works. Thank you. (inputs `(("python:tk", python "tk"))) ***furrymcg1e is now known as furrymcgee
<nckx>pashencija[m]: So it still happens exactly like described in the opening post? <pashencija[m]>In procedure struct-vtable: Wrong type argument in position 1 (expecting struct): #f <nckx>I wonder if the Guix package needs to be updated. <pashencija[m]>Current derivation includes the commits they say to fix the issue <nckx>Guix has a ‘guix’ package. Sometimes a bug in Guix is fixed but the ‘guix’ package not updated to contain that fix. <nckx>> Current derivation includes the commits they say to fix the issue <nckx>* I mean, how did you verify that? <nckx>pashencija[m]: Well, in this case it's as simple as noting that there have been no commits at all since the 2 commits given as ‘fix’. <nckx>So by definition, the ‘guix’ package does not yet contain them. <nckx>Thanks, but I'm not sure what to do with that info. Anyway, I'll try to reproduce the failure here first. <mekeor[m]>do messages like those of pashencija actually flood irc? <pashencija[m]>nckx: Commit id in guix descibe matches commit id with "fix" <nckx>pashencija[m]: Yes. How are you running the test. <nckx>You said ‘the derivation’ contained the fix? <nckx>I'm running the test suite now. <nckx>I am running ‘guix pull’ on said device. <nckx>If that's not how to reproduce it, if I need to do something else, lmk, but AFK briefly for now. Let's leave the bug report as it is as long as we're actively on it. <pashencija[m]>run `guix system image --system=aarch64-linux -e '((@ (gnu system install) os-with-u-boot) (@ (gnu system install) installation-os) "pinebook-pro")' --skip-checks --verbosity=3` <civodul>oh actually it was closed earlier today <nckx>That points towards the ‘guix’ package by the way. <civodul>right, the 'guix' package needs to be updated to get the fix <nckx>17 May 17:32:59<nckx> pashencija[m]: Well, in this case it's as simple as noting that there have been no commits at all since the 2 commits given as ‘fix’. <nckx>17 May 17:33:12<nckx> So by definition, the ‘guix’ package does not yet contain them. <nckx>17 May 17:31:12<nckx> Guix has a ‘guix’ package. Sometimes a bug in Guix is fixed but the ‘guix’ package not updated to contain that fix. <nckx>Updating the ‘guix’ package is a ritual dance best not performed lightly or fully clothed, I need to double-check how to do it without breaking anything again. <nckx>I can't sacrifice you, you're our test case. <nckx>civodul: Does the ‘update guix twice rule’ apply here, since it's a system image? I'd say yes? ***Lightsword_ is now known as Lightsword
***distopico_ is now known as distopico
***yjftsjthsd31 is now known as yjftsjthsd3
<abrenon>nckx: here, take that, I don't need it 🐐 <unmatched-paren>abrenon: see, there's strategy to goat sacrifice; there might be a _more_ cursed problem to work on, and we don't want to waste the goat <abrenon>ok, let's assume we're working in classical logic and not linear logic, that way we can use it as many times as we want <nckx>I want to clarify that no goats are harmed during the production of Guix. The goats are asked to waste/sacrifice an hour of their life reading about NFTs, and it's not fun, but they're fine. <nckx>Also, afterwards there's ice cream. <abrenon>let's patch the "yes" command to output 🐐 instead <nckx>(There is a farm nearby selling goat milk ice cream and it's surprisingly good, but not on topic.) <abrenon>which one ? classical logic or patching yes ? <unmatched-paren>patching yes, but then i realized that yes accepts a different string as a parameter <nckx>I've been sufficiently traumatised by younicks that I expected it to asplode. <nckx>But: infinite goats are disastrous for goat value, hence why we need goat NFTs. <abrenon>also, if this become public we're going to change what herding means <abrenon>we're shifting paradigms there people, moving fast and breaking things (especially pens) <nckx>guix substitute: error: TLS error in procedure 'handshake': Error in the pull function. <nckx>Grr, even build nodes aren't safe from it. <nckx>unmatched-paren: Goat overflow? <nckx>pashencija[m]: I'm testing the pinebook build with Guix 0adc984 on aarch64 hardware by the way, feel free to pull & do the same. <nckx>If it still fails I'll just update it again, the goat shortage having been solved. <unmatched-paren>nckx: i'm afraid some Big Satan company just patented goat sacrifice <KarlJoad`>There has to be a way to see the resulting type of an expression that uses the file-append function? I need a user to specify a full path to a binary for a field in a define-configuration. <unmatched-paren>nckx: they got it through by adding loads of extra information to make it look unique <bjc>type? isn't the result of ‘file-append’ always a string representing a path? <nckx>My gut says ‘network bork’, interrupt it is. <KarlJoad`>bjc: When I run `(file-append coreutils "/bin/cat")`, I end up with a "#<file-append #<package coreutils...> "/bin/cat">" <bjc>ah, sorry. i thought you meant after running the derivation <bjc>you need to lower results of the file-append operation to a procedure which you can execute in the store monad <bjc>i think i have a sample around somehwere. let me see if i can dig it up <KarlJoad`>I ask because I don't quite understand how my serialization function is leaving an unevaluated gexp in the final output. <bjc>the gexp is only evaluated in the store monad <bjc>iirc, you can do something like: (run-with-store (open-connection) (lower-object coreutils "/bin/cat")) to see the final path <KarlJoad`>Gotcha. Still the output type of the file-append operation is what is tripping me up. <bjc>i'm going to be a bit vague because i'm not clear on the specifics, but my understanding is that you can't actually know the path output of ‘file-append’ until you run it, because its input derivations and their dependencies have to be built first in order to calculate (in this case) core-util's hash <bjc>so on the host side, all you get are these gexps that are effectively promises (like, in the futures sense) <bjc>the promises are resolved by running them through the store <bjc>that looks like it should work. what's the problem? <KarlJoad`>"Invalid value for field command: #<file-append #<package coreutils...> "/bin/cat">" <bjc>that happens when you use ‘guix home reconfigure’? <KarlJoad`>Happens with `./pre-inst-env guix home build`. <bjc>i don't have a gnu/home/services/mail.scm -- is that something you're building? <bjc>ok, so without knowing much about this, i'd say the likely problem is that ‘serialize-password-command’ isn't being run on the build side <KarlJoad`>I don't even know if it gets that far. I get an error almost immediately. <bjc>you need to have the configuration create a gexp that gets passed to the builder for evaluation <nckx>pashencija[m]: ‘guix pull’ has aborted with the above TLS error twice now, I assume it's just an artefact of the network here. I'll let you test it. <KarlJoad`>That's what I was thinking too. Which is why I need to figure out the proper type define the command field for. <bjc>if you just want to test in the repl to see if everything computes properly, you can use (run-with-store) and (lower-object) or (build-derivations)/(built-derivations) <bjc>but i can't really help you with how to define the config -- i haven't gotten that far in what i'm doing myself <KarlJoad`>bjc: Once I get the type figured out, I want the build to fail, so I can get a backtrace and figure out the exact ways the serialize-password-command is being called. <bjc>good luck. the backtraces you get out of guile can be pretty rough a lot of the time <nckx>Now find the next bug please kthx. <nckx>pashencija[m]: Just out of curiosity: are you building pinebook images on the pinebook? <roptat>I'm having some troubles running "guix system init" for a new machine <roptat>it's aarch64, and it seems to be failing when installing the bootloader <nckx>Uhm, it's not what pashencija just posted… right? <roptat>(I worked around the guix test issue by using a different guix package and disabling acl management) <pashencija[m]>pashencija[m]: The goal is to build raspberry pi image. I already have the system that boots with some manual operations (like partitioning sd card) <nckx>…hmno, that's only tangentially boot-loader related, nvm. <KarlJoad`>nckx: I have been looking at the Pinebook. What was battery-life like? <nckx>KarlJoad`: Presumably you meant pashencija[m]. I don't have one. <nckx>Yeh, I remember your bug now pashencija[m]. <pashencija[m]>KarlJoad`: Awesome. I get 5 hours or so with my normal c++ development job <nckx>Nice. Does that include a reasonable amount of local compilation? <pashencija[m]>I do not recommend mac as it's totally not open source and not guix <pashencija[m]>nckx: Yes. But don't forget compilation cannot really load cpu <roptat>I wonder how I can debug this issue? <KarlJoad`>pashencija[m]: Do you have the regular Pinebook or the Pinebook Pro? <nckx>I see. I'm used to laptops with 16G+, good point. <KarlJoad`>Guix, I always wondered, why does ^L show up in the source files occasionally? <bjc>it's an old emacsism to separate logical sections of the source <bjc>you can set a mode to navigate by them. i can't remember how, though, since i never use it <bjc>so does emacs without the mode <nckx>Why is it an emacsism? Surely form-feeds predate emacs. <nckx>Wikipedio sez: Editors like Vim and Emacs understand such sections and have shortcuts for moving among them. <bjc>mostly because i only ever see it in emacs code ;) <roptat>when installing, it gets either the bootloader-installer or the bootloader-disk-image-installer, depending on which one is present, but they don't take their arguments in the same order <roptat>I wrote a disk-image-installer, but added it as the installer <nckx>bjc: I think it survived longer in Lisp than elsewhere, Lisp being a bit more… old skool in more than one respect. But it was used in real-world (GNU?) C as well. <nckx>Ah, the same article says it might be a GNU C thing. <bjc>i'd definitely buy it being a gnu thing <nckx>It is very GNU, isn't it :) <nckx>Paginate your C files please. <bjc>the gnu coding standards have always struck me as quirky and bizarre. i'd say it has something to do with their age, but similarly aged code (or older, even) isn't so weird to my eyes <bjc>i've always wondered if it was because of gnu's roots in mit and lisp <roptat>ah well, except the bootloader was installed in the wrong place :/ <roptat>do we have anything like that? I need to install a part of the bootloader in /dev/mmcblk2boot0 and another part in /dev/mmcblk2boot1 <nckx>bjc: I could buy that GNU C style was written deliberately to make Lisp look good. <roptat>they correspond to areas before /dev/mmcblk2 where I need to install the bootloader. The installer already contains code to install two files at different offsets that corresponds to these devices, but installing to an offset from /dev/mmcblk2 installs it too far (and inside the first partition :/) <nckx>I had to read that a few times. I still don't pretend to understand. So installing to /dev/mmcblk2boot0 doesn't get the offset right either? <roptat>I need to install a file at offset 0 of /dev/mmcblk2boot0 and another at offset 0 of /dev/mmcblk2boot1 <roptat>well, I'll install the bootloader on the SD card ^^' <KarlJoad`>bjc: I got my "typing" figured out. Now I am trying to understand how to lower the file-append. Shouldn't Guix handle the append, creating a single string, so the builder (which just writes a file) does not have to do anything? <bjc>calling ‘lower-object’ on something returns a procedure, which needs to be run in a store context for evaluation <bjc>so you can /call/ (lower-object foo) anywhere, but in order to get something useful out of it, you need to (run-with-store … (lower-object …)) <KarlJoad`>So Guix-home is getting the file-append with coreutils already expanded. I must manually call lower-object to get a full string out of it for myself? <bjc>‘home-configuration’ is expanded by the build-side, and during its expansion it recursively expands all the lowered gexps inside it <bjc>the gexp compiler has two halves: lower-object and expand-object. lower-object can happen anywhere, and produces procedures which get passed to the build side <bjc>expand-object runs those procedures on the build side <bjc>so home-configuration turns into a gexp (containing other gexps) which get lowered, then passed to the builder, which recursively expands them <Lembrun>Is everybody using https for their custom channels? I do have one that uses the file:/// uri , and when I do a sudo guix reconfigure system, it complains about the directory not being owned by the same user <bjc>KarlJoad`: i'm not sure why you're getting the struct representation in your output file. it'd depend on how things are moving around inside of home-msmtp-service-type <Lembrun>I do guix pull, then I I for example change my operating-system config so I do sudo guix system reconfigure /etc/config.scm <unmatched-paren>btw, does anyone know if it's safe to move /etc/config.scm to somewhere in $HOME? <nckx>unmatched-paren: Of course. <nckx>The permissions matter (if you care), not the location. <unmatched-paren>nckx: good. i have a git repo in ~/conf, so i want to move my system config there <nckx>It's related to a libgit2 update, it's not normal behaviour, that's all I know. I use file:// everywhere but haven't hit it (yet), possibly because I'm woefully negligent updating things lately. <nckx>unmatched-paren: I have the ‘opposite’ in that /etc/guix is a git repo, but it's fine either way. <nckx>I don't really know why all activity just stopped. <bjc>KarlJoad`: i'm out of my depth, but my suspicion is that your config serialization needs to return a gexp (and, in fact, probably a mixed-file since that appears to be what you're effectively doing) ***aeka- is now known as aeka
<bjc>right now i think it's being evaluated on the host side, because it's unquoted <bjc>were i you, i'd have a go at making it just wrap (mixed-file) <bjc>sorry, i mean: (mixed-text-file) <nckx>I don't get that CVE. ‘Git is teh vulnerables! If you can write to /home or /, you can pwn users’ — well, yes, by definition, surely, no? <KarlJoad`>bjc: mixed-text-file returns a display with all the arguments passed to it used in a single big string-append operation on the build-side. The build script has the gexp struct as literal text, not as something to be evaluated. <bjc>it should return a file-like-object, no? <bjc>the file-like itself, when expanded, will just spit out bare strings and evaluated expressions like a giant string concatenation of sorts, though <KarlJoad`>The host-side can return a file-like object I think, so long as the builder evaluates it to yield a string. ***makx_ is now known as makx
*nckx will return guile-git to using libgit2-1.3 if nobody stops them soon. <tbss[m]1>The software with names for exemple open foss and floss are acepted in guix? <Telc[m]>is this related to the magit build failure too? <bjc>since the contents of mixed-text-file aren't expanded until build (since it's a file-like, and therefore a gexp), a call to (file-append) inside it should, at that point, get you what you want <nckx>tbss[m]1: Sure. The licence matters, not the name (within common sense). <tbss[m]1>Its the discird clone,but wirh integration with discord <bjc>KarlJoad`: in fact, i'm looking at my home config which does precisely this: (zshrc (list (mixed-text-file "zshrc" … "source" (file-append zsh-autosuggestions "…")))) <KarlJoad`>bjc: That's what I was thinking too. That is why I was thinking it might be the with-output-to-string. <bjc>that wouldn't work on the host side <Lembrun>Completely unrelated but is anyone using waybar? I'm trying to use a different font than fontawesome since some icons are missing (due to 4.7.0 only on guix), but the pango markup that I use in the waybar config do not get applied. <bjc>i use waybar and i just use normal emoji rather than font-awesome <bjc>font-awesome causes more problems than its worth imho *nckx uses emoji too (Noto), if that's still useful. <bjc>i wish swaybar were more capable. i've been wanting to ditch waybar for a while <nckx>Newer font-awesomes are non-free so it's not promising anyway. <bjc>i'm also using noto for emoji <Lembrun>I tried replacing it with material design but my config must be missing something <nckx>bjc: I have a bash script to fill in a few fields swaybar proper lacks, like CPU frequency and network bandwidth, it does the job. <Lembrun>if you know a better font that is not emoji, I do find emojis for volume etc kinda ugly <nckx>Emoji's not a font. There are several different emoji fonts; if you like one and it's Free and not in Guix, you can plonk it in ~/.local/share/fonts, or (much better yet) package it for Guix :) <bjc>nckx: i interact with waybar a fair amount, and that's where swaybar falls behind. i can't remember the exact issues, maybe clicking on things? but swaybar doesn't do it and waybar does <bjc>didn't google just release a free font pack for emoji that are just line art? that'd be pretty useful for a waybar <nckx>Telc[m]: I don't think it's directly related (there should be only one user in use in the build environment), but who knows… More likely to be another breaking change IMuninformedO. <apteryx>nckx: the ritual dance should be 'make update-guix-package' with a checkout matching origin/master <apteryx>(and committing/pushing the resulting diff) <apteryx>and the 'guix' package should still build of course <nckx>Mkay, I prefer the manual but otherwise equivalent route. <nckx>The ‘double’ dance I remembered is now explained in a helpful comment which is nice, it's mainly for changes that break the installer-installed system. <nckx>Where updating ‘guix’ is not enough. We need to go deeper. <nckx>Oh, Guix. Rebuild dependents of guile-git? Sure can do. Currently building webkitgtk. *nckx guesses it's due to the bad substitute situation in general. <bjc>i guess the substitutes are still significantly behind? <nckx>Shockingly so, apparently, or so I learnt earlier in this channel. <nckx>I thought some builds were still getting through somehow. <nckx>tbss[m]1: Can you elaborate? *unmatched-paren currently building the `guix` package ***xMopxx is now known as xMopx
<apteryx>re-reading myself, I really meant Cuirass, not Craps, in case that's not obvious <nckx>(So, yeah, saw that thread :) <Lembrun>Isn't that good? it's a substitue right? <Lembrun>Not too shabby with a custom kernel, It does takes 40-50mn to compile on my old thinkpad *unmatched-paren is not sure how to customize the kernel package on guix <nckx>unmatched-paren: Depends on what you mean by customising. I maintain my own kernel package, but simple .config tweaks should be easy as Lembrun has written by now. <lilyp>on a scale from nothing happened to everybody hates me, how bad did my sudden need to murder my PC affect guix git tree? <lilyp>ugh the usual, thing just froze without even the possibilty of getting an SSH into it <Lembrun>quick guix shell --container --pure -D gcc-toolchain ncurses bison bc flex openssl@1.1.1l util-linux make autoconf coreutils sed diffutils bash grep libelf findutils elfutils gawk crypto++ perl gzip kmod to get make menuconfig working and play around with the kernel, I don't think you're supposed to have coreutils as it is supposed to be in gcc-toolchai nalready but I get missing exe without it <nckx>lilyp: I… think you're good? Or I'm looking in all the wrong places, as is my wont. <Lembrun>oh and you need to patch some shebangs <nckx>I don't have coreutils in mine. <nckx>Complicated scripts for the win. <nckx>But at least it adds Qt depending on the make target… which I never use. *nckx silently deletes some stuff. <nckx>Lembrun: “coreutils […] is supposed to be in gcc-toolchain already” uhm… no? <Lembrun>nckx: Maybe, I thought I read that somewhere <Lembrun>Yeah just read the definition it's not included in it, my mistake <nckx>Maybe in a bug report titled ‘gcc-toolchain includes coreutils omg wtf’ 🤷 <nckx>I'm sure something like that happened once and somebody thought it was API. <nckx>I forget the bug report, but I'd like to remind folks that Hyrum's law does not magically create an obligation to *cater* to the offender. <nckx>lilyp: So why would your SSH misadventures affect Guix.git? I'm very curious. <nckx>(Not offender… er… ‘enjoyer’?) <lilyp>There was a nonzero chance that I'd cut the power right in the middle of a git operation <bjc>git's order of operations should mean that you can't corrupt anything with a power cut <lilyp>Without any feedback, visual or otherwise from the machine in question. <nckx>I wondered the same thing about a well-placed ^C once, because it seemed to effectively push without sending notification mails, and nefarious thoughts started to fill my mind. <bjc>the last thing git does is update the head pointer. mostly because that's the last thing it can do <lilyp>For the record, I did once achieve a bad state with a well-placed ^C <bjc>hmm. i'd be curious how that happened <nckx>Plus, user-space semantics can get… wobbly once a hard power cut is involved. Your buggy consumer ATA firmware might not give a shit about git's order of operations. <bjc>if your hard drive is writing things out of order everyone's got bigger problems <nckx>It was kind of a huge deal. <bjc>even zfs expects your hard drive to do stuff in the order specified, at least across sync boundaries <nckx>I honestly don't remember, and my point was more general than that. Plenty of ordering bugs have been fixed in the kernel over the years, for example. <lilyp>sync boundaries can get arbitrarily large <bjc>i'd classify that as "bigger problems" ;) <nckx>‘Consumer hardware’ is the Biggest Problem, I don't disagree. <lilyp>especially with a system like Guix where you don't need to abuse a syscall to do package management <lilyp>oh and yeah, it's a good old nvidia graphics card acting up since day 1, what else is new? *unmatched-paren looks at their UEFI firmware with its irritating efivar-wiping behaviour <nckx>(I'm not saying Enterprise Hardware is any or much better, but the price does include helpful primal scream therapy with a poor junior sales rep.) <bjc>enterprise hardware comes with the "helpful" property of support <luishgh>hi guix, does anyone know how to use home-xdg-mime-applications (from guix home)? or know a public git repo using it. <meena>why is guix package -u burning up my computer? <nckx>Is bordeaux authorised by default yet? <meena>The following derivations will be built: (many) <nckx>If not, answer probably related. <nckx>meena: The main CI system (A.K.A. berlin, A.K.A. ci.guix.gnu.org) has been having tummy troubles for a good while now, meaning few if any new substitutes are available. There's an independent server at bordeaux.guix.gnu.org which you can use with --substitute-urls, but I don't know if its key is added to the ACL by default yet. <nckx>That key is #7D602902D3A2DBB83F8A0FB98602A754C5493B0B778C8D1DD4E0F41DE14DE34F#. <nckx>It's not as beefy as berlin, but it should reduce many to fewer. <meena>and there's no failover yet? <nckx>Your Guix fails over if you've added and authorised both servers (or as many as you like). <nckx>Simply cnaming ci.guix.gnu.org to bordeaux.guix.gnu.org, so to speak, is not how things work or possible. <nckx>It's up. It's just criminally idle. <meena>i should probably plug my laptop in… this is draining the battery like it's getting out of fashion <meena>I'm not saying CNAME is the the solution. I have no idea what the solution would be. <meena>but having every single user do the same dance is not the solution. <nckx>I know you're not, it was a metaphor. <nckx>That is not what I suggested. <nckx>I missed apteryx's reply. Makes sense at first glance. Don't have time to implement it right now. <nckx>I'm a bit weary about turning the wget && gpg --verify && use flow of the script into wget this && wget that && wget foo though. Esp. with this & that being keys. <meena>what kin of keys are these anyway? <nckx>meena: I'll assume your familiar with Guix & its ‘substitutes’. Substitute servers, by design, serve arbitrary trusted binaries, so Guix only accepts binaries that have been signed by the private key matching a public key present in (admin-only) /etc/guix/acl. <meena>uh! uh! uh! what if! what if!!! everybody's builds could be used as binary packages? bittorrent style?? <nckx>ci.guix & bordeaux.guix don't share keys. <nckx>That's possible, but not implemented. <nckx>Last I heard IPFS was the tech to jour, but it's all the same problem. <nckx>meena: You have to trust each build machine with full root access to your machine, yes. <nckx>Because they can give you a bash binary and your Guix is all ‘I guess that's what I'd get if I compiled bash myself, thanks, no need to check’. <nckx>It is very important that the binary is not not-bash. <nckx>Because bash does not, yet at least, mine bitcoin. <nckx>Nobody wants packages to ship their thousands of build scripts in fish. <nckx>Our message timing might be off. Of course fish doesn't mine bitcoin 😉 If it did we'd patch it out and not just change the wallet address, promise. <meena>i… don't have a wallet address… <meena>well, once upon a long time, when i thought it was cute, i had a dogecoin wallet, for like 4 hours <meena>but then my computer did what it's doing right now, and i thought you know what? screw this. <meena>i'd rather compile operating systems, than calculate hashes <nckx>I had an Ethereum wallet with actual Etherea in it before it was worth anything. Literally threw it away. The end. <nckx>I could have owned apes. <bjc>in the very early days of bitcoin i managed to mine a few of them. it was so long ago that it was actually possible to do this on a home computer <bjc>i thought "neat, but folding@home is probably a better use" and have long since lost that wallet <vagrantc>and this is how an artificially scarce resource becomes "valuable" <nckx>Anyway, decentralised substitutes are possible, and reproducible builds mean you can validate a binary obtained from party A with a signature from party B (so you only trust B). But that's about improving distribution, B still has to finish building its version before you can use A's. In this scenario, B is down. <bjc>i take comfort in knowing i drove the price up that much more for someone rich guy *nckx never bothered with bitcoin; eth's scriptability was at least technically *interesting* to me then; bitcoin really isn't. <meena>nckx: as i learned in a zoo visit the other day: apes have to wear a diaper, cuz they'll poop everywhere in your house. And, as soon as they turn teenagers, they become violently unhinged, and need to be given to someplace that can actually take care of them. <meena>i'm sure this could be turned into a metaphor, but we can also just take it as-is. <bjc>i'm still of the opinion that you could cleave the knot by saying "as long as all build hashes are equal, the build results are fine", and in the case of hash conflict, force a blessed builder to build it and publish the correct hash <nckx>You are saying that Bubbles, like crypto, was unsustainable? <bjc>it's still vulnerable to concerted attack, but it'd be harder <meena>bjc: it'd also do something for verified builds, eh? *nckx wonders whatever happened to Bubbles, but knows better than to look it up, also, topics. <bjc>i suspect that most of the time most builds would pass muster and it'd alleviate a lot of the load on the blessed builders <bjc>i think bubbles got sent to one of those sanctuaries that turned out to be actually not that great for the chimps <nckx>Oh jeez. See, I don't want to know… (thanks though). <bjc>i remember watching a documentary on what happened to all those apes who "learned to speak" when the funding ran out. it's very depressing <vagrantc>bjc: i think we have some plausible numbers for how many packages are identical on the two official build farms <bjc>i really need to remember to use the data service <bjc>although maybe today is not the day i remember =) <bjc>what's "unknown" mean? <nckx>bjc: Not enough builds to compare (i.e., < 2). <vagrantc>75% is a little disappointing, really ... i think i'm going to have to put my reproducible builds hat on and actually tackle this for a while <bjc>pashencija[m]: did you set up a memfs /tmp? <nckx>pashencija[m]: Yah, 3.9 GiB is not enough. <nckx>You need to untmpfs /tmp, or set TMPDIR to something else in guix-daemon's environment. <vagrantc>debian's got ~95% on a larger pool of packages, with intentionally varying things that guix normalizes <bjc>vagrantc: i wasn't sure what to expect. other than guix, the only other systems i know that are even trying reproducible builds are the bsds <bjc>debian's doing it too? <vagrantc>it's a bit of a relief that it's common enough now that people aren't calling it "that debian thing" :) <bjc>yeah, that's really heartening <bjc>nice to see tor there, too <vagrantc>tor and bitcoin kind of inspired the efforts in debian, which inspired other efforts <bjc>for all of its many faults, the crypto people do still manage to get some things right <vagrantc>and then there were things like guix and nix that were kind of doing it all along <vagrantc>(and there were some historical reproducible builds efforts in GNU toolchains in the early 90s) <vagrantc>now if we can just get reproducible builds and bootstrappable builds noticed in all this hype around supply chain security... <meena>every distro is trying to get closer to reproducible builds… *vagrantc dances happily! <nckx>Bootstrappable builds are a yuge deel. <nckx>And it's so underreported. *meena usually hangs out in FreeBSD land and her Linux mucking is restricted to Desktop <ss2>hey nckx & bjc got my system fixed the other day. Just wanna say thanxs. Was the old ssd bailing out. Migrated, cleaned the Store, done. <nckx>Hah, ‘glad’ to hear that :) <unmatched-paren>what i don't get is why reproducible builds is sponsored by the "Google Open Source Security Team" when Google literally makes vast seas of money from proprietary software <unmatched-paren>{Reproducible,Bootstrappable} Builds is literally about "if your software is not auditable, it is insecure". <ss2>up until then I under appreciated the Store's capabilities. That it survived a faulty disk says a lot. <nckx>ss2: I find it almost reassuring, for lack of a better word, when bizarre behaviour & bitflips *does* turn out to be due to bad hardware, for once. <bjc>google makes vast sums of money on proprietary software built on the infrastructure of free software made by volunteers *nckx awards 1 guixcoin to bjc. <meena>nckx: as opposed to space radiation? <ss2>woo, bit flips I can't be sure. I did a memtest that failed, but could never reproduce it individually or with both RAMs back in place.. <bjc>nckx: can i buy a picture of an ugly guix with that? <nckx>Trick question. There are no ugly guix. *meena looks into mirror… <ss2>In Guix you'd rather see several mirrors stacked behind each other that you look at until you find your most fitting that suits your needs. <ss2>Mirror declarations! <nckx>‘Maybe it was space radiation…’ <nckx>Are you sure? They look like 2 separate tmpfses to me. <bjc>pashencija[m]: yes, sorry if that wasn't clear from the earlier responses <unmatched-paren>nckx: "guixcoin" haha, did you seriously think those fan noises while guix was running were from compiling software? <nckx>Regardless, whilst tmpfs itself isn't a problem, 3.9G isn't enough to build some packages. <nckx>/kick unmatched-paren (We discussed divulging such secrets) <vagrantc>unmatched-paren: you say that as if google is one entity with one mind <vagrantc>unmatched-paren: there are people within google who see reproducible builds as genuinely valuable and essential for security *vagrantc issues disclaimer that vagrantc is paid by some of those funds <nckx>pashencija[m]: Did you not see my earlier reply about TMPDIR? <nckx>Wi-Fi's extremely choppy here. <unmatched-paren>nckx: stupid question: how do you write the slash without it actually executing the command? <nckx>Dunno if it's a ‘standard’. <nckx>I mean, / itself is interpreted by your client, so how to avoid that is not a protocol-level thing. <nckx>A dozen people a year show up desperate ‘how to do that "* nckx does a thing" thing?’ and you're the first asking how to avoid it. <nckx>By the way, I sort of took matters into my own hands and am ‘guix build’ing some big packages on berlin… <nckx>That smell you smell is desperation. <dlowe>often irc clients will have /quote that sends a raw line to the server <nckx>pashencija[m]: Fail, or success, depending on what you wanted to achieve. <nckx>Which is the lesson all along. <nckx>The thing with /quote is that it's counterintuitively named for most people. They expect /quote foo to *not* execute command foo. <KarlJoad`>Is there a known issue with texlive's texdoc not working on Guix? <meena>well, rebuilt half of KDE, and poppler and Okular for nothing. ***pushcx_ is now known as pushcx
<meena>still can't display a ć in notes. <meena>let's see if emacs does better! <nckx>I've basically started a guix build $(world) now. Might as well use those 2.5k cores for something. <vagrantc>are there issues with bordeaux too? otherwise that should be spitting out a few substitutes ... <nckx>I don't use or follow bordeaux myself. ***ChanServ sets mode: +o nckx
***ChanServ sets mode: +o litharge
***litharge sets mode: +b *!*@2001:470:69fc:105::2:1198
***ChanServ sets mode: -o nckx
***litharge sets mode: -o litharge
***stikonas_ is now known as stikonas
<nckx>(You might not want to visit that link! I don't think it is legitimate!) <littlebobeep>meena: every distro is not trying to get closer to reproducable builds <hnhx[m]>> Note: only interested people should apply, drop a message let's get started <nckx>You're lucky I didn't kick you. <hnhx[m]>imagine using fed honeypots like telegram <Fuchs>I'd recommend to not re-post spam, chances are that anti spam mechanisms might start targetting you <nckx>Please, for the love of our lord & saviour captain obvious, please do not repeat spam verbatim hnhx[m]. <nckx>And not just for your own sake. <nckx>You repasted it verbatim. <nckx>Well, you are on IRC, so :) <Fuchs>they are using the matrix bridge, but it's also not advisable there to directly interact with it *littlebobeep trusts oliver <hnhx[m]>hnhx[m]: I don't really like IRC, I prefer matrix because it supports end to end encryption, also the multimedia support and voice calls with screenshare is nice to have. <nckx>I mean, when did a Judith ever lie to anyone? <littlebobeep>So is the only test of reproducability just seeing if hashes differ between ci. and bourdeau. ? <nckx>hnhx[m]: Anyway, yeah, bit of a ‘know your audience’ fail with the t.me link… <apteryx>littlebobeep: you can build it locally; guix build --check <apteryx>typically with --no-grafts unless you are into verifying the reproducibility of a grafted build <nckx>hnhx[m]: True, but here I only have 8 cores and 16 GiB of RAM, so most clients are a little slow. <hnhx[m]>I dont understand who would ever use telegram when matrix and IRC, heck even GNU Jami exists. <nckx>hnhx[m]: You often appear to reply to yourself here (”hnhx[m]> hnhx[m]: I don't really like IRC, I prefer…”), is that also only on this side of the bridge? <hnhx[m]>littlebobeep the clients are not the issue <hnhx[m]>the issue is with the closed source server <nckx>In fairness to littlebobeep I did think it was a ‘mobile’ thing. <littlebobeep>hnhx[m]: you could use verifiable e2ee with a telegram client and anonymize your connection to the server, you just need to find a way to receive the SMS confirmation to another number, but that only happens once. <cbaines>vagrantc, there's been some hicups with bordeaux, but it's working OK I think <cbaines>I'll send out an update email this week <littlebobeep>nckx: No, the problem is telegram-desktop does not have e2ee, but I think telega.el does, I never tried but it says it does. <nckx>I tried to create a Telegram account once and it insisted on a mobile number, so I insta-binned it as sus malware. <nckx>No legitimate reason to ever ask for that. <hnhx[m]>I don't really want to go trough all that hassle when I can just host my own matrix homeserver lol <Aurora_v_kosmose>Is there a general term for onboarding into a bootstrapped ecosystem? Like what binary seed project is doing with regards to gcc requiring gcc to build. <littlebobeep>hnhx[m]: the cliens being FLOSS means you can have e2ee verifiable <nckx><hnhx[m]: for me it looks okay> OK then. You're the only [m] user I've ever noticed doing so, maybe a client issue, or who knows. <hnhx[m]>element isn't part of the Guix repos, and tbh I wouldnt really use it anyway since its written in electron. <apteryx>uh, magit is broken due to emacs-libgit failing <hnhx[m]>maybe it displays like that because I have set a nickname on matrix? <hnhx[m]>I dont want to appear as @admin:matrix.beparanoid.de so thats why I set hnhx. <nckx>Your secret identity is safe with us 👍 <nckx>apteryx: Does it still fail after 665dd82? <hnhx[m]>btw why doesnt Guix have its own IRC server? <hnhx[m]>I heard bad things about libera.chat, afaik it blocks tor connections. <nckx>We don't, and I doubt it, but you probably need to be authenticated. <Noisytoot>I couldn't find a Matrix client that supports end-to-end encryption and is packaged in Guix. Nheko used to work but stopped working. <hnhx[m]>Noisytoot: nheko works fine for me, whats the issue for you? <Noisytoot>hnhx[m]: After I log in it just loads forever (or at least for as long as I've kept it running). <nckx>hnhx[m]: Missed the ‘why’, sorry. Because the only Guixperson nuts enough to ever proclaim ‘we should administer our own ircd! that will be fun!’ is probably me, and even I think ‘no thanks’ after thinking about it a few seconds longer. <Noisytoot>You should run your own ircd and link it to pissnet. *nckx still needs to join pissnet. <Noisytoot>Although UnrealIRCd isn't packaged yet and has a weird build system. <littlebobeep>Noisytoot: package emacs-ement in Guix uses libolm for e2ee <nckx>I'd really like to see anyone claiming Libera is ‘bad’ for… not accepting unregistered Tor connections do give that a go. Just for fun. That would be fun to see. To film. <Aurora_v_kosmose>You effectively need to rely on some friend or on luck to find a Tor node they don't know of. <noisytoot[m]>Nheko just started working, but took a long time to load <nckx>I don't pretend to know if convenient + secure is a thing. <nckx>If someone else has solved it, it *is* a pity for the premier chat provider of Free software not to follow. <Noisytoot>Hackint allows registration from Tor but requires you (or more likely your computer) to solve a Hashcash challenge. Pissnet (or at least two pissnet servers) allows anonymous connections from Tor if you use a publicly available onion auth key, which so far no spambots have worked out how to do. <nckx>(Not to point out the obvious, but just to bring it back to the original question: 100% no way in spam hell that a Guix IRC server would *ever* offer anything close to what Libera does offer over Tor, so it's still moot.) <nckx>Still need to erect an official #guix presence on Pissnet. 