<apteryx>debug symbols taking 976 MiB for qtbase... is this to big to enable on core-updates? <apteryx>ah! Qt is build with both shared and static libraries. I can probably reduce this by a lot by preventing the static libs from being built. <NieDzejkob>apteryx: I've already sent a patch to enable debug symbols on qtbase <apteryx>did you disable static libraries as well <apteryx>OK :-) I'll try this atop your patch. <apteryx>I thought it may be useful to add the -no-strip configure option, otherwise Qt strips on its own (I'm not sure at what time!) ***catonano_ is now known as catonano
<apteryx>I guess we can tell by checking the size of the debug output of qtbase on staging :-) <apteryx>if it`s smaller than the 976 MiB I found out in my tests, something`s off. <kkebreau>Is anyone here running a kernel with module loading completely disabled? <kkebreau>Or without support for loaded unsigned modules? <mroh>kkebreau: most of the time it's much better to ask for information instead of asking for people, because you might get help even if nobody is running that setup. ***terpri_ is now known as terpri
<brendyyn>noob question. how do i apply patches in emacs with magit such that it actually commits it rather than just apply the diff to the files <str1ngs>brendyyn: W a a . from magit-status . though those take mail patches not diff patches <str1ngs>brendyyn: I believe W a a using git am. if you are familiar with that. <brendyyn>I downloaded the patch via issues.guix.gnu.org by clicking the download icon <brendyyn>then I use W a a. it just puts all the changes into the files and they come up as Unstaged Changes <str1ngs>brendyyn: what issue number are you trying to apply? <brendyyn>apply patches -> patch. I was doing plain patch by mistake <str1ngs>brendyyn: actually that was my mistake. W a a is not the same as w w apologies <apteryx>NieDzejkob: so I asked in #qt, and the .a we get no matter we use -no-static or not (it's off by default), are internal libraries necessary to build other qt modules (such as qtsvg), so we can't do without. <apteryx>also I just built qtbase on staging and the debug output weights 976M. All good, nothing to do. Thanks! <brendyyn>chromium failed to build after a couple hours :( <brendyyn>why do module imports need a #:use-module on every single line? isn't there a simple #:use-modules that lets one list them all? <pkill9>does snorenotify not work for anyone else? <pkill9>test notification doesn't work, and snoresend times out *raghavgururajan still snapping out of sleep <peanutbutterandc>Can somebody please explain to me why I can't seem to be able to define a (debug) procedure and just (add-after 'unpack 'debug ,debug) in (modify-phases in (arguments in a package definition ? <pkill9>my guess is maybe try making everything in the debug procedure a symbol if you havent <peanutbutterandc>Because I could not put _debug_ procedure there, directly, I'm using (lambda)... you'll have to ignore the _debug_ procedure for now... <efraim>peanutbutterandc: do you mean like (invoke "ls") ? <peanutbutterandc>efraim, for some reason, it didn't work the one time I tried that. I'll try that again, then <efraim>do you have coreutils in the environment? <efraim>I think I found a bug in the 1.0.1 release, using guix-0.13.0 with a few modifications to update/add packages so configure passes on 1.0.1 <civodul>efraim: you're doing heroic investigations :-) <efraim>0.13.0 -> 1.0.1 would make re-adding mips64el much easier, maybe running guix pull from 0.13.0 against the 1.0.1 release tarball will work better <efraim>now building ghostscript, i wonder if --no-grafts works on guix pull <efraim>peanutbutterandc: what if you put (invoke "ls") or (system "echo $PATH") right after the lambda <efraim>in case something's wrong with some of the other guile-y lines <civodul>it has many dependents, but most are small packages <efraim>civodul: sounds like my justifications for doing perl packages sometimes <efraim>that reminds me, I should try to actually get into the rust BoF in debconf <efraim>looks like --no-grafts doesn't work on guix pull <peanutbutterandc>efraim, Oh wow. I get /path-not-set (with (system "echo $PATH"))..... that explains it <efraim>I normally start my debugging after the 'unpack phase <peanutbutterandc>but before that... if it is possible, I would like to know why I'm unable to `(add-after 'standard-proc 'debug ,debug-proc) ... it appears to me that guile/scheme syntax rules should allow that... <peanutbutterandc>I see.... I'm trying to see what each phase does. Just so. I don't even know why. <peanutbutterandc>so I'm trying to see how the build environment is before anything else has happened... and I'd like to see how things come about in that. <peanutbutterandc>but currently it's the `(add-after 'proc 'debug ,debug-proc) issue that is bugging me (now that I can see that PATH was not set in that phase) <efraim>i'd try (add-after 'proc ,debug-proc) and see if that works. Otherwise I'd look at guix/build/*-build-system.scm and see about copying the formatting of phases from one of there <peanutbutterandc>efraim, Ah! fixed it! You were right when you suggested that I quote all the expressions inside of the procedure definition. Thankfully, I only had to quote '(lambda ...) and it works! <efraim>of course now I want to know if (add-before 'set-SOURCE-DATE-EPOCH 'debug _debug_) and not-quoted lambda would work :) <peanutbutterandc>efraim, I just tried that out, again. And no sir, it didn't work. neither `(... (add-before 'stuff 'debug ,debug-proc) ...) nor `(... (add-before 'stuff 'debug debug-proc) ...) <civodul>i can see how this error could happen, but it's surprising it can happen on Guix System <civodul>("GuixSD" is now known as "Guix System" :-)) <NieDzejkob>PotentialUser-77: what does 'echo $GUIX_LOCPATH' say? <efraim>civodul: needing to use --fallback for nss-certs <civodul>PotentialUser-77: could you run "sudo herd status guix-daemon", get the PID shown there, and do "cat /proc/THAT-PID/environ | xargs -0 echo"? <civodul>to me, the issue is definitely solved on Guix System <PotentialUser-77>this is vanilla guixsd image, install > guix pull > reconfigure, bam nss-certs breaks at 48% each time <PotentialUser-77>cat /proc/<pid>environ .... > GUIX_LOCPATH=/gnu/store/n79c.....-glibc-utf8-locales-2.29/lib/locale LC_ALL=en_US.utf8 *mothacehe Just added Linux module compression support! <civodul>PotentialUser-77: could you check whether that directory in GUIX_LOCPATH actually exists? <civodul>i have to go but i'll reconnect soonish <civodul>would be nice to get to the bottom of it <civodul>also, would be nice to have a bug report at bug-guix@gnu.org rather than superuser.com :-) <civodul>no account needed, it's plain email :-) <PotentialUser-77>ok i can fling an email there to make it a bit more formal, but any help would still be appreciated <PotentialUser-77>out of curiosity, how do you handle no-free software with your installs? ie most commercial dev requires something non free (elasticsearch, etc). guix takes a pretty hardline approach to non-/free <guix-vits>Kimapr[m]: "Authenticating channel 'guix', commits 9edb3f6 to 5fe12be (__4,925__ new commits)..." <guix-vits>Maybe try: pull to older version, reboot, then try pull again? <leoprikler>PotentialUser-77: You can use Guix channels for non-free software (both your own and some, that are already out there), but you should refrain from discussing them here. <mothacehe> Kimapr[m]: I tried to time-machine to your current revision (9edb3f) and ran a "guix pull" command, but it works fine. I'm wondering what's going on. <guix-vits>Can someone confirm that elogind-service breaks boot on aarch64? <guix-vits>The error said something about "freezer" filesystem. <civodul>mothacehe, Kimapr[m]: same here: "guix time-machine --commit=36a1925 -- time-machine -- describe" works for me <civodul>(36a1925 is the right starting commit, according to the "host version" bit) <guix-vits>Kimapr[m]: Once after update i'd some error messages, and services didn't start. That was, afair, a guile2 -> guile3 update. I was adviced to simply reboot. Just Your transaction is 4000 commits long, so? <Kimapr[m]>I don't think rebooting right after 'guix pull' would change anything. 'guix pull' doesn't change any services which would probably require the reboot. BTW i'm on Guix System, not Guix On Foreign Distro <leoprikler>On foreign distros `guix pull` as root updates the daemon IIRC <Kimapr[m]>so i have to guix pull and guix reconfigure and then restart? <Kimapr[m]>Oh wait what, it just works now that i specified commit manually <Kimapr[m]>pass '-net user,model=virtio-net-pci' to your run-vm.sh, assuming it is made with 'guix system vm' <Kimapr[m]>Arguments to the script are just passed to qemu <civodul>nckx: hey! did you eventually manage to reconfigure berlin? <nckx>Creepy, I'd just logged in here. Er, ‘good morning Guix’. 😳 <nckx>guix-vits: If you tell me exactly what to add (just (elogind-service)?) I can test it on a headless aarch64 box. They're just sitting idle here. <Noclip>What is the best way to find the latest version of a package which is available as binary? <civodul>nckx: ah right, do you remember which .drv that was? <guix-vits>nckx: Hello. Yes, (service elogind-service-type) in config.scm was enough for me. <nckx>civodul: No, I'll pull again. *nckx had searched the manual for elogind-service-type but it doesn't occur. Needs to be added. <guix-vits>for version in `guix show linux-libre| recsel -p version| awk '{print $2}'`; do echo $version; guix weather linux-libre@$version; done <guix-vits>* for version in `guix show linux-libre| recsel -p version| awk '{print $2}'`; do echo $version; guix weather linux-libre@$version| grep 'substitutes available'; done <nckx>civodul: /gnu/store/lgan8wzz6rz5rqliccmv769wh3qfz0bw-guix-1.1.0-19.0c50d72.drv → /var/log/guix/drvs/lg/an8wzz6rz5rqliccmv769wh3qfz0bw-guix-1.1.0-19.0c50d72.drv.gz <nckx>tobias.gr/said-guix-log.gz <nckx>Actually, tobias.gr/said-guix-log.txt, since otherwise you might's well ssh into berlin & zcat yourself. <leoprikler>hmm, no matter what I try to pass to the VM, dns works, but ping does not <leoprikler>[and neither do the applications I'm actually trying to test] <nckx>leoprikler: Don't use ping to test the networking. ICMP isn't emulated. *nckx adds caveat ‘or didn't used to’, since Guix changes for the better rapidly. <nckx>efraim: I didn't even spot it ☝ <civodul>weird, that one built fine on my laptop <fnstudio>hi, `guix install python` gives me `python3` but there doesn't seem to be trace of a `python` (tout court) executable in my path <fnstudio>am i expected to create a symlink manually or am i missing anything else? <nckx>fnstudio: guix install python-wrapper = python + the compatibility link. <civodul>nckx: /gnu/store/lgan8wzz6rz5rqliccmv769wh3qfz0bw-guix-1.1.0-19.0c50d72.drv successfully built on berlin, go figure <nckx>Does mailutils fail its test suite on aarch64 elsewhere? <nckx>Also, why does my system.scm pull in mailutils in the first place... ***guix-vits is now known as sneeek
***sneeek is now known as guix-vits
<civodul>ah now cuirass fails to build: no code for module (guix zlib) <mothacehe>civodul: oh didn't know we were using (guix zlib) in Cuirass. <civodul>mothacehe: it's a missing propagated-inputs *civodul visits many rabbit holes today <civodul>i wonder what it is i was initially trying to do <peanutbutterandc>How do I (copy-file (guix build utils) multiple files that match a certain wild-card pattern? <nckx>It was emacs ♪ it's always emacs ♫ <nckx>If this means that emacs(-no-x) is broken on aarch64, that's bad. <nckx>☝ controversial hot take. <peanutbutterandc>NieDzejkob, :( I was so hoping there was a (glob) procedure on whose return value I could (map). But okay. Find files. Thank you very much. <nckx>But using regexes, The Better Blob. <nckx>You wouldn't map on copy-files; use for-each whenever you throw away the ‘result’. <nckx>I've been reading too much linux-libre. <peanutbutterandc>"blub" "de-blub" (: for-each, yes... for side-effects, for-each. for values map. I read that somewhere. <nckx>map works but just looks weird. <peanutbutterandc>guix build utils functions.... what kind of regex are they taking? Basic regexes? And not shell wild-cards, right? <nckx>By ‘shell wild-cards’ I presume you mean globs, so no. <str1ngs>peanutbutterandc: map returns the continuation of the lambda and returns a list which can be useful. for-each does not. <peanutbutterandc>str1ngs, Hey there! Hmm... I haven't yet read up on continuations. Might take me another book or so. But yeah... for-each does not return anything... I kinda' read that somewhere <nckx>peanutbutterandc: find foo -name "*.h" → (find-files "foo" "\\.h$") <nckx>Scheme makes regexes [even more of] an adventure™. <peanutbutterandc>nckx, Hmm... in guix repl, I just tried (find-files "." ".go") and it returned all .go files from the current directory <nckx>But it would also return ‘goose’ and ‘engorged’. <str1ngs>peanutbutterandc: continuation is the tail of the expression. aka the return value. you can try with (map (lambda (x) x) '(1 2 3 4 5)) . here you see x is the continuation in the lambda vs (for-each (lambda (x) x) '(1 2 3 4 5)) which returns nothing of course. <nckx>Don't eat foie gras people. <civodul>nckx: +1 (though i don't get the connection with regexps :-)) <nckx>peanutbutterandc: Yep! . matches any character in regex, so to match a literal . you need to write \. - but then comes Guile demanding an escape tax, so you write \\. <str1ngs>NieDzejkob: we were taking about the difference of map vs for-each. maybe I did not explain well? <nckx>civodul: Random association with ‘engorged goose’ above, no relation. <civodul>mothacehe: after all, Cuirass does use (guix zlib) directly <peanutbutterandc>str1ngs, So basically continuation is what I was looking for when I was trying to write tail-recursive procedures !? <str1ngs> peanutbutterandc: correct. though I'm no scheme export so I could be missing some nuance in naming. <civodul>mothacehe: we still need to have guile-{l,}zlib in propagated-inputs of 'guix' tho, right? <str1ngs>Noclip: if you did guix pull there is one in ~/.cache/guix/checkouts/ . but I would not use those directly. better to clone your own. <mothacehe>civodul: cuirass-0.0.1-43.f2984c7 now builds correctly, sorry for the breakage *nckx takes a turn at reconfiguring. <civodul>i feel like we're making great progress :-) <mark_penguin>How do i set up a permanent network connectionon guixsd? <peanutbutterandc>Is it just me, or does everybody else's ./pre-inst-env guix build sth seem to always remake a lot of unrelated .scm files (saying that the - untampered - scm files are newer than the compiled .go files)? o.O <kkebreau>peanutbutterandc: Not just you, I think mine does that too. <kkebreau>To anyone who was online around 14 hours ago, I got the module-less kernel working! <kkebreau>No modification to the Guix code base necessary, just a raw-initrd. <guix-vits><fat>I were a kernel-no-modules man like You... Then i got an arrow in a knee.</fat> <peanutbutterandc>Is there a way to fix that? I'd really like it if I could only have guix deal with the changed files only <Noclip>I'm only using "git log" on the cached repository so I don't think cloning is needed here. <kkebreau>peanutbutterandc: Besides running `make` in the repository again, I'm not sure. <kkebreau>Usually when I get that message, the .scm files were technically updated by a `guix pull`, and so make the .go files out of date. <joshuaBPMan>Hey guix! I totally got nginx reverse proxy working sweet! <str1ngs>Noclip: git read operations should be okay I agree. though I'm not sure how to make sure you are using the checkout as used in guix describe. you can make sure the hashes match with git log | head -1 | awk '{print $2}' I guess. <peanutbutterandc>kkebreau, Even after running `make` the issue does not seem to be resolved for me.... and I am on a local branch.... <kkebreau>Hm, that's never happened on my machines. I wonder what it could be. <peanutbutterandc>Also, perhaps it'd be great if everytime ./pre-inst-env runs and a .scm file is compiled into a .go file, that'd be it: a cache like thingy like normal guile uses <peanutbutterandc>or maybe ./pre-inst-env does some timey-wimey thingy? o.O I should probably look into the file <str1ngs>peanutbutterandc: using make before ./pre-inst-env should do that. <str1ngs>./pre-inst-env should only cache build modified files <peanutbutterandc>str1ngs, That really is strange... it hasn't done that for me. I wonder if that is because I ran `make` on one branch, and then branched to create another one? o.O <str1ngs>peanutbutterandc: yes that might change the timestamps of the scm files <str1ngs>that's just a huge assumption my part. might want to double check yourself. <peanutbutterandc>str1ngs, Hmmm... does kinda' seem to make sense... but I should probably go and read up on git internals and branching before I can wrap my head around the matter <str1ngs>peanutbutterandc: I think guile will check the time on .scm vs .go and determine if it needs a cache build or not. <peanutbutterandc>str1ngs, Yes, sir. I think that part is correct. I remember reading something like that in the manual. It's the branching changes time-stamp part which, though plausible, kinda' sounds difficult to me... because I remember reading that branches in git are just basically pointers... so.... <str1ngs>peanutbutterandc: you just make a new branch, not switch to a branch with modifcations? <peanutbutterandc>str1ngs, No, sir. Just switched. But I might have forgotten something. I will try and experiment with it sometime. <str1ngs>also if you branch sometime in the past and have pulled say master. you might need to merge the original master into your branch. <str1ngs>which might change timestamps anyways 🤦 <peanutbutterandc>str1ngs, Hmm... I'll look into the matter. Sorry I'm causing you to facepalm. <ArneBab_>I finally found a way to treat my installed packages as a manifest — I hope this will get me more reliable updates with fewer missing substitutes: guix pull && guix package -I | cut -f 1,3 | sed 's/\t/:/' | xargs guix install <nckx>".*" means ‘0 or more occurrences of any character. <str1ngs>peanutbutterandc: oh my facepalm was not due to you. I was thinking how it might not be possible to avoid some rebuilding. though it might not be needed. <peanutbutterandc>str1ngs, Ah... I see. Well, I'm glad my face-palms-received-in-#guix balance is still 0. (: <nckx>Yeah, if there are several subtly different regex dialects (and I don't actually know which one Guile uses, hm) but there's no such thing as a seperate ‘Guile regex’. <apteryx>Guile just uses the ERE, extended regular expression type <apteryx>POSIX extended regular expressions, to quote the manual <peanutbutterandc>I see. Thank you very much. Are there any resources that you'd recommend me to brush up my regexes? I once heard of something called 'regex-golf'... I should probably go look that up too <nckx>apteryx: Thank you for the system list patch. Not an issue with it, but your (systems (list "x86_64-linux" "i686-linux")) example makes me curious: what happens when i686-linux is missing and I offload, say, Wine? Is i686 ‘implied’ by x86_64 as I think it used to be? <mothacehe>civodul: indeed, the error is "In procedure -: Wrong type argument in position 1: #f" <mothacehe>civodul: evaluations on guix-master are also lagging :( <Noclip>How can I find out which revision an installed package is based on? <nckx>it's basically buggered. <apteryx>nckx: any x86_64 machine should be able to build for i686, if this is what you are asking <civodul>mothacehe: so those are likely due to the guile-ssh bug that reconfiguring should fix <civodul>very little is getting built right now, i think <str1ngs>Noclip: guix always using the described hash. unless you mean installed packages? <nckx>apteryx: My question is (I guess) why you explicitly list i686 now and if it's strictly required. <civodul>uh "Database worker unresponsive for 5 seconds." in cuirass.log <mothacehe>Yeah recent addition of mine to detect pending queries. Posted a MR on guile-sqlite3 so that we can log every query and their duration. *nckx restarted reconfigure with -c64 after watching kernel build log saunter by. Now it's running. <apteryx>nckx: ah, this is a good question. I guess because explicit is better than implicit? But it could be argue both ways. Perhaps some x86_64 processors are very slow to build for i686 (hypothetical) and you wouldn't want them to offload these builds. <str1ngs>Noclip: that is a bit more challenging. you can see with guix upgrade -n if anything is not based off of the guix describe hash. <str1ngs>Noclip: though probably you might just want to guix upgrade after pull then it's less of an issue. <nckx>apteryx: But even if you removed the i686 they still would, right? Because I think that's what happens now. <nckx>apteryx: No disagreement on explicit-vs-implicit, and I assumed as much 🙂 <apteryx>mothacehe: for the build-machine systemS field patch, I think it won't have an effect even if merged to master until we upgrade the 'guix' package which is the one used by the guix-daemon service, correct? <nckx>apteryx: Or does your patch make it more strict? I didn't read all of it yet. <mothacehe>nckx: Thanks, although I'm not sure what mutex is held! <apteryx>nckx: my patch doesn't do much at all, except allowing to list more than one system per build-machine record. <nckx>Kernel's almost done, with some luck a reconfiguration is nigh. <Noclip>str1ngs: I think I will try something else. <apteryx>it's mostly just sugar to keep your /etc/guix/machines.scm file tidy instead of duplicating the entries just to support multiple system types per machine. <apteryx>mothacehe: OK, I'll look into merging it later today and then bump our Guix so that it takes effect. <mothacehe>apteryx: great, thank you! The reconfiguration will hopefully be working by that time :p <str1ngs>Noclip: I'm not sure there is anything better then using guix upgrade. in fact you will probably run into issues avoiding guix upgrade at some point. <apteryx>mothacehe: np. Thanks for your reactiveness! <Noclip>str1ngs: There are no binarys for ungoogled-chromium available so I assume upgrading would fail anyways after burning my laptop for a long time. <apteryx>I sometimes get this: guix deploy: error: failed to deploy $machine: failed to start Guile on remote host '$host'. Then I retry... and it succeeds! <nckx>Berlin has been reconfigured and cuirass{,-web} & guix-{daemon,publish} restarted. <nckx>Like a less intelligent version of civodul earlier, I kind of forgot what this was for & what the exact next step/check is. <str1ngs>Noclip: understandable, in time that should resolve it's self. maybe there is away to avoid upgrading a package. <apteryx>mothacehe: hmm, my local guix used to do 'guix deploy' has the fix, so unless the remote Guix needs it as well, I'm unsure. <str1ngs>Noclip: you can alway guix pull --roll-back if the current guix pull is not to your liking. <nckx>[without context] There's --do-not-upgrade <package>... <nckx>At least berlin is heavily loaded! Multiple somethings are happening! \o/ <str1ngs>nckx: thanks that work with guix upgrade? seems it's not listed in --help ***terpri__ is now known as terpri
<nckx>str1ngs: It does but only super-recently, like since y'day. <Noclip>str1ngs: "guix package --do-not-upgrade=chromium -u" <Noclip>str1ngs: It's also listed in the manual. <str1ngs>I was using guix upgrade --help for reference. guix package --help is more informative :) <Noclip>str1ngs: I didn't know that "guix upgrade" accepts options. I thought one would have to use "guix package -u" if options are needed. <Noclip>In case anyone needs a pre-build version of ungoogled-chromium, "Commit: eb09a99f81a38edaa4fd43634dcf73f8851832f4" has one. <guix-vits>Noclip: If someone want Chromium, why not use at least a keyboard-driven one (qutebrowser)? <str1ngs>hmmm which video chat does not work with webkitgtk? <guix-vits>Am mean, that stock Chromium isn't that good with keyboard, so.. <str1ngs>none of them are good with emacs like keyboard bindings. that's why I created nomad anyways. <jackhill>Ungoogled-chromium is also the only browser in Guix that has support for Webauthn with a USB tokens. I still need to figure out why our Icecat doesn't work. <str1ngs>jackhill: I'll look into webrtc and webkigtk thanks for the details. <Noclip>guix-vits: Does qutebrowser support webrtc? <jackhill>str1ngs: cool! I was getting ready to add it to the allowed user agents in a BigBlueButton instance that I controlled, but then I saw the tests and thought, "huh, maybe its true that it doesn't work" <nckx>peanutbutterandc: I'd noticed last week but, while I technically have access to that repo, I have no idea how GitHub mirrors work. <str1ngs>jackhill also will look into webauthn regards to webkitgtk <msavoritias[m]1>Epiphany was slow on some sites for me. That is why I downloaded qutebrowser <str1ngs>msavoritias[m]1: reddit.com is a good example of poor webkitgtk performance. <str1ngs>msavoritias[m]1: if you want to compare the two. <jackhill>web browsers seem to require much more C++ knowledge than I have (which is almost none ☺). <nckx>peanutbutterandc: I think mbakke will know more (they set it up) but they aren't here now. <str1ngs>jackhill: more so with qtwebeninge. webkitgtk is mainly C <guix-vits>Noclip: For me: Ipv6 -- no, Reflexive connectivity -- no. <str1ngs>jackhill though in nomad we use sweet sweet guile scheme now :) <str1ngs>nope webkitgtk is C interface. gtkmm is C++ bindings to gtk+ <nckx>peanutbutterandc: Thank you for the report and we should fix this if we can, but note that this mirror is entirely un{official,supported}. <guix-vits>Noclip: guix weather seem to not show any substitutes for qutebrowser, because it uses a qt-webengine. Itself it is just a Python (so no compile on substitute servers). <guix-vits>So before updating, look for qt-webengine substitutes. <terpri>str1ngs, by that you mean that webkitgtk is webkit-based, but has a C-based API? <str1ngs>leoprikler: probably glibmm is C++ got glib. <str1ngs>terpri: correct the API to webkitgtk is C base. like most things GTK <peanutbutterandc>nckx, No worries, at all, maintainer! (: I'd also like to be able to help out someday. For the time being I'll work on fixing/updating packages. <terpri>(webkit itself is definitely not mainly c, but i haven't used webkitgtk before) <str1ngs>leoprikler: sorry I meant C++ bindings for glib. <str1ngs>that's beside the point the interface is in C. the rest you can treat like a black box. <peanutbutterandc>how do I get the hash for a git checkout again? `git hash -rx .` only? o.O <jackhill>except if you need to add a feature of fix a bug :) <terpri>also re: jitsi, jitsi displaying a warning doesn't mean it's broken for any particular browser, it's just doing User-Agent checking for some reason <civodul>apteryx: i get this "failed to start Guile" error as well with the "fixed" guile-ssh <terpri>fsf's own jitsi server doesn't "work" (meaning it blocks access) with gnu icecat, lol <terpri>we disabled that check for hcoop's jitsi instance <nckx>peanutbutterandc: Apologies if I've asked you in the past, but what's the reason you were using/browsing that mirror? <terpri>bavier[m]1, sure, i'll make sure it's forwarded after it's a real service in the near future (right now it's just a test instance on a temporary VPS) <terpri>i don't think i have access to the patch atm <terpri>also i can set up rooms on the test instance (sans User-Agent test) if someone wants to try jitsi with an uncommon browser <peanutbutterandc>nckx, oh... `git blame` is easier/neater on that mirror. So... I wanted to see some recent changes in a .scm file <terpri>(dunno why so many sites are seemingly going back to User-Agent testing and not feature testing...there are a number of banking sites etc. where i'm forced to use chromium instead of icecat) <nckx>Oh for the love of. Another wild rabbit runs past and scurries down a new hole: ‘Could not prepare Boot variable: No space left on device’ <nckx>peanutbutterandc: You mean you prefer GH's Web interface to running git locally or using Savannah's (if it even support blame, no idea)? OK. <bavier[m]1>terpri: thanks! I think they'd appreciate it, and I'd hope a feature-testing patch could make it's way to upstream eventually. <peanutbutterandc>nckx, Oh, no... I do have a local git checkout. But I was making some local changes that I didn't want to stash. GH is just a tab away.... Hmm.... I haven't really checkout out savannah's git <terpri>bavier[m]1, np, on TODO list now. should be just a week or two before it's an official service, no major issues so far (some oddities with youtube streaming, but that's not relevant to the fsf instance) <peanutbutterandc>I see... I might be too n00b for normal git-web interface... I kinda' prefer Gittea/Gitlab/GH interface to default git web.... *terpri still watching sourcehut progress <nckx>peanutbutterandc: It's not you. The interface (cgit) is spartan compared to others but doesn't offer super 1337 powers in return. It's just light(er) on resources. <terpri>gitweb, cgit, gitlab, gitea, kallithea, sourcehut, apache allura (what sourceforge uses, lol)...too many options :( <nckx>(IIRC the ‘log plain’ column supports more options like ‘blame’ but they have been turned off.) <nckx>Nobody should blame (heh :-/) you for using a much better interface, especially when you don't have a choice. <terpri>sourcehut (sr.ht) is *very* modular, which makes me hopeful that it'll be hackable for unusual setups like hcoop.net, without being as complex and heavyweight as gitlab etc. <bavier[m]1>terpri: I was just browsing hcoop's pages, hadn't heard of it before; looks nice. <terpri>15 years of fully free-software cooperative internet hosting :) <terpri>(and with guix support likely coming soon!) <terpri>"All features work without JavaScript" :) <apteryx>civodul: OK :-/. Probably something else then. <civodul>apteryx: perhaps we should test with guile-ssh 0.12.0 <nckx>‘Disclaimer: This website is maintained by SourceHut.’ Honsely, we knew that just by looking at the One Big Green Column. Still, I'm always happy to see any project benchmarking itself. *apteryx goes out for lunch <pancak3>just to confirm, everyone is happy with the current linux-libre kernels right? Because I was forced to lock my kernel to 5.4 due to problems, but now even the latest 5.4 kernel is being quite mean to me. <BlackMug>does guix package manager rely only on GPG? <pancak3>guix-vits: I haven't tried that one. Maybe it'll work. But it's annoying because 5.4.3something worked :/ <pancak3>at least they're forking openBSD. FreeBSD is too mainstream for me <Noclip>Will guix ever support electron apps? <nckx>BlackMug: Instead of/in addition to what? For which purpose(s)? <BlackMug>GPG contains tons of security flaws or needed features many articles talked about that <leoprikler>Noclip, if you're willing to deal with the clusterfuck that is JS packaging, you might soon call yourself the person, who packaged them ;) <BlackMug>thus Age/Rage or Signal are good alternatives, Signal for example used in OpenBSD <Noclip>leoprikler: I've never packaged anything ... <guix-vits>gnu/packages in git tree (it called a tree?) <nckx>BlackMug: Guix verifies package sources using checksums (hashes), not signatures. The packager verifies the source integrity (many upstreams do use GPG for this, but you can just as well use signify or whatever, this is outside of Guix) then registers the sha256 hash (other algorithms are supported but not used in practice). Then they push that hash as part of a GPG-signed git commit, which is verified when you ‘guix pull’ (similar to apt update). <Noclip>leoprikler: So JavaScript issues are the reason for electron not being available? <efraim>I wonder if we can attack it similarly to how we package rust. Throw a lot of sources together and build them all so we get the one desired package. <leoprikler>It's not quite as easy as that, because you need to recreate the entire npm tree (see node-build-system) <Noclip>So npm isn't bootstrapable or what are you trying to say? <ArneBab_>civodul: and sr.ht is actually funded! (I’m paying for my account) <nckx>It's not a direct answer to your question and it's 5 (wow) years old, but it's a good background to start from. <samplet>I think if we had a solution for TypeScript the rest of the JavaScript ecosystem would be (very painfully) bootstrappable. <samplet>All the module system comparability stuff can be done in Rust or is directly supported by modern runtimes. <Noclip>nckx: How did they solve the problem for nixpkgs? <samplet>Noclip: They likely use a lot of pre-built JavaScript artifacts. <pkill9>does anyone know of an application for creating menus in the style of the playstation3/playstation4 (xcross media bar)? <nckx>Noclip: But they didn't, not really. But I'm the wrong the wrong person to ask about modern Nix. <apteryx>civodul: shouldn't Guile already properly format an exception message, instead of throwing the format string and its args? <BlackMug>nckx i see, but this issue as well addressed to apt that it uses GPG which is bad crypto tool <nckx>Your accusations are too vague to address. <leoprikler>If I gpg untrusted content en masse, I may leak secrets. <nckx>‘Somebody wrote a bad about GPG on the Internet, discuss’ isn't something I can meaningfully do. <BlackMug>i see, maybe better this way: GPG posses alot of insecurities, can there be a will to change this within guix? <vagrantc>while gpg has it's issues, there's really not a better alternative at the moment ... some in development, sure. <nckx>BlackMug: Which insecurities, and how are they excercised in Guix? Guix verifies GPG-signed commit messages. <leoprikler>Guys, X.509 has issues. We better stop HTTPS right now. <civodul>Noclip: AIUI, Nixpkgs simply ships pre-built JS files (same problem with Java, etc.) <vagrantc>leoprikler: try gender-neutral language :) <nckx>gnupg's user interface is a liability in itself, but I don't *think* that affects us. It's more likely an upstream makes a silly while signing their tarball, but Guix doesn't verify tarball signatures, and upstreams are free to switch to something else without affecting Guix in any way. *str1ngs replaces HTTPS with his quantum network. <leoprikler>vagrantc: I would have said "Guix" or people if I was being serious, but thanks for the reminder. <civodul>let's not confuse GPG the implementation and OpenPGP :-) <nckx>BlackMug: That's just a list of links. Which vulnerability, specifically, concerns Guix? <vagrantc>most of those are about user interface issues, not the underlying functionality <nckx>The opening paragraph really sets the tone. ′Very bad! Boo! We can't explain why, do your own research below.’ <civodul>i think there's a lot to be said about OpenPGP itself, but we'd have to be more specific <civodul>perhaps instant messaging is not the best medium for that :-) <BlackMug>nckx i didnt said there are vulnerabilities affecting guix but there are insecurities which can be later used to be worst scenario <Noclip>Does guix depend on any pre-built binarys except of the ones needed for bootstrapping guix? <pkill9>would functionality to allow `guix environment --container` to take store paths be accepted? <pkill9>i.e. it would add the store path along with all it's references <civodul>Noclip: not for Java, not for Rust; there are still a few exceptions with pre-built binaries, such as GNU/MIT Scheme, Bigloo, and probably others <pkill9>sandboxing installed applications <civodul>(well, these are not "binaries" but "generated source") <leoprikler>pkill9 wouldn't it be easier to just add the packages to your manifest/package list? <pkill9>leoprikler: then it will download newer version <pkill9>anyway i can expose /gnu/store and run the application directly, so doesn't really matter anyway <civodul>Noclip: the goal is to get rid of non-sources, but it's a long-term effort, and not just ours <leoprikler>Okay, assuming this is not what you want, you could use inferiors or an old guix pull generation [assuming you don't want to share all of /gnu/store] <Noclip>civodul: Would it be "against the rules" to add pre-build binarys to guix until the dependency issues are solved? <Noclip>(If those binarys are 100% free software.) <vagrantc>how do you demonstrate they're free software if you can't build them? *nckx screams, tries to put the worms back in the can, but is eaten by the worms, dies. <leoprikler>you should try to package the earliest version that builds with something else *vagrantc mourns the loss of nckx and watches innumerable software updates in guix lag <apteryx>hmm did I just goofed something: fatal: reference is not a tree: 537080fad8dfa63df2f1d0b0d046a28077d56a56 <BlackMug>nckx i didnt went into the effect of guix itself but for GPG e.g no perfect forward secrecy, The cryptography itself like RSA is not security future , key size...etc *nckx respawns with full health, and a question: <nckx>Does anyone use Guix System on an X230? <vagrantc>BlackMug: most of those problems are fundamental to cryptography <pancak3>BlackMug: Have you tried incognito mode? Works for me <BlackMug>vagrantc i know thus better alternatives shall be a good way for the future <janneke>meaning, i have guix system on a x220 <vagrantc>BlackMug: all algorithms are not future-proof *raghavgururajan sees effect of using IRC in Gajim <vagrantc>BlackMug: key sizes will eventually all be broken on any algoritm <Noclip>nckx: I'm also on the X230T but I'm not using guix system. <vagrantc>BlackMug: forward secrecy is not really relevent for signatures, only encrypted messages ... and signatures are the only thing relevent for software distribution <nckx>BlackMug: PFS is irrelevant to Guix. Key size (I actually read that link and laughed at the triviality of it) is irrelevant to Guix. Future-proofness... add and use new algorithms, this affects every single signature scheme ever, including $your_favourite. <nckx>Noclip: Well, me, yes, correct 😛 *vagrantc high-fives the new nckx <Noclip>Why are there so many X2**T users in this chat? 😂 *pancak3 cries holding my T420 *apteryx bumps again, this time's the good one. *raghavgururajan 's X200-T is sexy because it has ExpressCard slot and stuff <str1ngs>I switched from x200 to pinebook prot. though I use a thinkpad wirless keyboard. <BlackMug>vagrantc i know because i only read about GPG didnt read the effect of it on Guix, thus my first question is it possible to replace it <nckx>My UEFI has been complaining for the longest time about a full NVRAM. Now a reconfigure refused to install GRUB until I removed some boot entries using efibootmgr (there goes my ATAPI CD boot option ☹). I wondered if this was somehowe linked to Guix System use. <BlackMug>nckx interesting, is there the link in the docs how guix working with gpg? <nckx>No, there are no dump-* files I can delete. <vagrantc>BlackMug: the current use of openpgp in guix is git signatures of commits and releases ... the released tarballs could easily be signed by something else ... not sure if git supports signatures using other encryption schemes <samplet>For JavaScript, I think if we had a careful and principled approach with only one or two binaries it would be okay. (Like we do with Haskell, for example). <nckx>BlackMug: I hope civodul has time to answer that because it recently changed completely and I'm not sure. But all we do is commit signature verification. We don't call out to gnupg at all. *vagrantc is disappointed to hear there are more binaries in guix <BlackMug>vagrantc i see, git still rely on SHA1 yes? <BlackMug>nckx sure no problem i will look into it and see what i can find <vagrantc>BlackMug: yes, though signed tags mitigate the limitations of sha1 somewhat <nckx>If you can read Scheme at all, I strongly recommend looking at the actual code. In fact that's the only valid way to do this, anything else is just armchair amateur crypto. <nckx>raghavgururajan: GPT. Haven't used MBR in years. *vagrantc reclines into a big armchair <nckx>(Would that affect nvram usage? That's... interesting.) <rekado>GHC is a big fat blob and to my shame I haven’t made any progress in bootstrapping it. <samplet>rekado: I’ve read your blog post about HUGS. It was a serious effort. No shame needed! :) <BlackMug>alright will check it out, one last question did guixsd now support static IP implementation in the installation process? someone worked on it? <nckx>raghavgururajan: I don't have a problem with GRUB, it's completely right to abort installation, since my NVRAM *is* full. The UEFI (while booting) agrees. <nckx>In fact it's been warning me for months so it uses a lower threshold than Linux. <rekado>I had collected notes for a second blog post, but that route led me nowhere to write home about so I didn’t <nckx>Which is interesting, the reverse seems far more common. <Noclip>nckx: Is your boot partition not big enough? <nckx>My disk is fine. This is purely about EFI NVRAM (‘variable storage’ or whatever the marketing name is). <rekado>I wanted to build the GHC 4 RTS and use *that* with Hugs to interpret GHC 4 to compile itself. <nckx>It has nothing to do with partitions or file systems. <rekado>and then move on with a boring chain from GHC 4 all the way up to the latest version. <samplet>My completely made up estimate is that any major bootstrapping issue (.NET, GHC, JavaScript, Scala, Ada, OCaml, ...) could be solved with about a year of full-time work. <nckx>raghavgururajan: So does half of the Internet, unfortunately, so the level of ‘help’ I find during a Web search is disheartening. <samplet>Which is hard to do with volunteers.... <nckx>The other half is just ‘mount /sys/firmware/... and delete dump-* files thank me later’ which is useless too. *raghavgururajan says "Keep Calm and Coreboot It" <nckx>I don't understand why I'd be hit with this. I do a lot of weird stuff (separate /boot, bcachefs, homemade kernel patchez...). I don't do anything of it *near* the UEFI level. <nckx>raghavgururajan: X230Ts are physically hard to flash, I think we've discussed this before, and I don't know anyone I could pay/trust to do it for me. <nckx>Unfortunately. I'd love to use Linux to boot Linux. <rekado>samplet: yes, perhaps. The GHC work looks doable, it just takes a lot of time. <raghavgururajan>nckx: May be time to throw away UEFI shit and flash the ROM with Coreboot+SeaBIOS setup? <BlackMug>btw until now there is prohibition by guixsd to work on Qubes due to the fact it needs static IP <bluekeys>nckx: A bit late, but I was running guix on x230 for a while *nckx secretly gets a kick out of constantly saying ‘Linux’ without people being able to pedant. <nckx>I think I mailed them but never got a response :-/ <rekado>BlackMug: I don’t understand this sentence. <nckx>(Don't quote me on that until I grep my sentbox.) <bluekeys>but now i'm using qubes and guix is on debian in a qube and guix is on a server <rekado>do you mean Guix System can’t work on Qubes? “it needs static IP” — what is “it” here? <raghavgururajan>nckx: That's odd. I was interacting with them regarding VPS, a while ago. May be try in #vikings <bluekeys>BlackMug: Do you mean Dom0 guix on qubes? <BlackMug>rekado guixsd doesnt support configuring the IPs or proceeding with offline installation <BlackMug>either there is internet or no move forward <BlackMug>and this is not how Qubes templates work <rekado>BlackMug: you can build a system (without the installer) <nckx>bluekeys: And no boot-time warnings (‘The variable storage is about full, hit F1 to...’)? I'm starting to think it is just me. <rekado>and you can certainly configure static IPs with Guix. <BlackMug>bluekeys no, like for example if you want to test guixsd in Qubes using guix.iso like any other distro available <nckx>Problem is that even a reset from the UEFI set-up doesn't fix it, so I'm getting a bit worried. <BlackMug>rekado yeah possible but not user friendly at all <BlackMug>anyway can someone sign this feature request, or bug because it mandatory request internet access which bad idea <nckx>BlackMug: You can send a mail to bug-guix at gnu dot org which will open a bug number. This is a feature request (‘wishlist’), not a bug, but it's a perfectly valid one. <vagrantc>i would guess the installer doesn't have enough on the .iso itself to do a full install without network <vagrantc>or at least more than a very minimal install (e.g. what's on the installer itself) <nckx>The installer should be able to deploy a **minimal** system (and you must take that very literally) without having to download sources. <BlackMug>vagrantc 4.7GB not enough for installer ? <nckx>Our installer is CD-size, not DVD-size, if anyone remembers those sizes by heart. <BlackMug>700 something MB for CD, even that too large for just installation of a distro <nckx>I don't know if we'd have the resources to create huge-ass installers but it's not that hard for others to create & host. <vagrantc>you could build a custom installer that has more already on it, but out-of-the-box is minimalist <Noclip>vagrantc: Creating a custom installer shouldn't be a problem with guix, right? <vagrantc>Noclip: if you're comfortable with guix and guile, no <nckx>BlackMug: Reducing the size of the installer is an extremely low-priority goal. Basically, whoever actually cares gets to submit the patches. <BlackMug>nckx ok increase the size but provide ability to install it without internet <nckx>Noclip: And if you are, it's almost trivial. <nckx>BlackMug: Well, my last message applies to that too, really. It's a valid request - just don't hold your breath for someone to rush to squash it unless it actually bites them. <nckx>Running a distro without network access isn't a common use case now. <BlackMug>i agree, but to solve 2 things like Qubes case and static IP internet <nckx>I'm not familiar with Qubes but it looks very kewl. <nckx>Well, I haven't tried it, I mean. <Noclip>vagrantc: Can't you just recreate an already configured copy of your system on the vm? I thought that is one of the core features of guix system. <vagrantc>Noclip: sure, though that might take some work to get to boot from USB or CD or whatever <nckx>Noclip: You can base an installer on your current system, but there are some services that a ‘live CD’ needs that your desktop won't be running, like a writable union FS, … <nckx>Guix doesn't randomly slap them onto the side. *nckx thinks that's a good thing btw. <nckx>You could write a procedure that does so. <BlackMug>Thanks guys for the great support and chit chat <f> <bluekeys>ncxk: I think my connection died. No errors. But i use skulls bootloader and it was a 1.0 install of guix <apteryx>I can't reconfigure because of QEMU test failures: qemu-system-i386: /tmp/guix-build-qemu-5.0.0.drv-0/qemu-5.0.0/target/i386/kvm.c:2695: kvm_buf_set_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed. <apteryx>I just reported the QEMU test failure <nckx>raghavgururajan: Oh, thanks for asking, I'd asked the same question. <nckx>It's a pain to flash but I like the tab. *nckx has never got an e-mail as a PDF through a pastebin before. Feels an urge to print it out. Then take a photo and upload it somewhere. <nckx>‘File sharing Web site’. <nckx>You saying my ‘scp something to my server then plonk the link into #guix’ is somehow not the cutting edge of sharing tech. *raghavgururajan loves XMPP 💕 <civodul>vagrantc: re binaries, don't be disappointed: presumably nobody does better <civodul>it's an opportunity for improvement! ;-) <nckx>raghavgururajan: So disroot runs an XMPP bridge to IRC? <civodul>with a few more jannekes and rekados and dannyms & co., the bootstrapping issue will soon be solved <raghavgururajan>nckx: Yep! It is XMPP Transport for IRC, deployed at irc.disroot.org <raghavgururajan>Bridge means something else, though folks accidentally use the word in the sense of transport. :-) <nckx>I have no idea what a bridge is. It's something that makes random [m]s appear 🤷 <raghavgururajan>nckx: Yeah, bridge represents synchronization. Applies primarily for MUC (Multi User Chat). For example, a bridge can be established between IRC and Matrix. In this setup, both IRC channel and Matrix room separately exist; but are synced. <terpri>i believe xmpp calls protocol interoperability thingamajigs gateways; matrix calls them bridges <raghavgururajan>The [m] suffix for some members represents that they are Matrix users and are connected to IRC channel via Matrix Transport for IRC. <nckx>This I know in my heart to be true. *raghavgururajan uses XMPP for almost everything: SMS/MMS, IRC, Matrix and Telegram. :-D *terpri uses IRC for almost everything: IRC, IRC, and IRC <nckx>Oh thank god. I'll just say gateway from now on and always be right. <nckx>YIL, while brushing up on my Dovecot. <str1ngs>in 2020 trumps means a whole other thing :P <apteryx>interesting. that QEMU 5 commit is from more than 3 months ago: 2020-05-08. <apteryx>Perhaps only that machine I'm working from causes the test suite to fail (kvm related). <nckx>I'm building one with and one without faeddf293, just in case. <nckx>I admit to skipping qemu in my rebuild-all-dependents test because it froze my laptop :-/ <terpri>lol yeah i was a bit confused when i saw that on the dovecot feature list <nckx>First you think April fools, then you realise it's real. *nckx has now borrowed berlin to build qemu, since it has just a bit more RAM and a successful build will benefit everyone. <jonsger>nckx: I once used delta chat with is similar to CoI but it was pretty beta back then <vagrantc>civodul: definitely guix does better than anywhere else ... i just didn't realize there were any other than the bootstrap binaries :) <terpri>you can expect some SML bootstrap binaries submitted in the future too :/ *vagrantc claps for delta chat *raghavgururajan attemps to package Delta Chat into Guix <nckx>Meanwhile, my MUA doesn't even support IMAP IDLE and probably never will, but go ahead and create multiple CoI protocols I guess. <nckx>I'll just sit here refreshing. <jonsger>raghavgururajan: I think its electron, have fun :P <jonsger>was the reason why I abandoned it :P <jonsger>has someone a script to copy all locally build packages/derivations via `guix copy` to a remote host? <nckx>find /gnu/store -mindepth 1 -maxdepth 1 -exec guix copy --to=... {} \; ? <nckx>It runs guix copy on each top-level /gnu/store/* item, one by one. <nckx>Using + instead of \; seems to work and is probably faster. <jonsger>nckx: but I only want the ones I built locally because those are missing on berlin, so I don't have to built them on all of my devices <fnstudio>hi, consider someone coming from a "python background" who <fnstudio>hi, consider someone coming from a "python background" who's familiar with `pip install requirements.txt` within a virtualenv <nckx>jonsger: How would you know what was built locally? <fnstudio>i suppose part of that process can be handled slightly differently (and more generally) with guix, eg with a guix environment (if i got that right) <jonsger>nckx: so there should be a post build hook or an option to guix build <apteryx>nckx: the drv is this one: /gnu/store/xkw86xzrqamn9kjihkdwrfiadvmxrxh1-qemu-5.0.0.drv <nckx>I don't see the logical leap in ‘so’ but OK. <apteryx>seems the CI is not building it according to 'guix weather' <fnstudio>is the process of migrating from a requirements.txt to a guix environment possible and automatic? in other words, if a package exists under pypi, how safe is it to assume that i can find its counterpart under guix? <raghavgururajan>sneek, later tell civodul: Regarding the blog-post stuff from Oliver, I have e-mailed a link containing newer version of the article. Just letting you know here. :-) <kkhind>why is guix still using gnome 3.34 instead of 3.36? <jonsger>kkhind: because no one took the effort to update it <jonsger>GNOME updates are quite a bunch of work <nckx>apteryx: Who knows when the CI will get to it. Best not to wait. *raghavgururajan has update whole GNOME stack to 3.36, among the works in wip-desktop <nckx>apteryx: Built fine on berlin. <nckx>They've left, but let's hope they read the logs. <rekado>raghavgururajan: that’s great news! <rekado>I didn’t know wip-desktop included a GNOME upgrade. <sneek>civodul, you have 1 message! <sneek>civodul, raghavgururajan says: Regarding the blog-post stuff from Oliver, I have e-mailed a link containing newer version of the article. Just letting you know here. :-) <nckx>How did you guess my fursona. What's the relationship between yours and the wip-gnome3.36 branch above, raghavgururajan? <nckx>I was wholly unaware of the wip-gnome3.36 branch because I was following your work. <terpri>talking about webapp freedom issues in #hcoop: <terpri><terpri> (a modest proposal: transpile guix to js or compile to wasm, then define free web apps as specialized OS declarations (or services running on a minimal web platform "OS"), then...) <raghavgururajan>nckx: Even I had no idea that wip-gnome3.36 before few weeks ago, when I cherry-picked MozJS-68 patch. <nckx>IKR? Finally, the correct reaction. <vagrantc>civodul: it's just basically a mail client made to look like a chat application <nckx>Everyone else here was like ‘oh, yawn, that old thing’. *vagrantc uses deltachat on replicant <nckx>Is the ‘several-second delay’ an issue in practice? <nckx>I know some people on whom it would be an improvement. <raghavgururajan>But that brached focused on only upgrade. I was focusing on improving pack-defs, enabling missing features, adding missing dependencies, fixing bugs etc. <nckx>Oh, I know (in fact I wasn't aware that your branch included upgrades until you told me). <civodul>vagrantc: Pierre N. did some work to get mu4e or one of these newfangled Emacs email client look like a chat thingie <civodul>i think that's why they don't quote messages when replying *civodul .oO does issues.guix.gnu.org qualify as a "COI client"? <nckx>Which ones fail for you? <vagrantc>build of /gnu/store/gp9d47kf8b4vw9xcmvacv9zvv37zifhw-mailutils-3.10.drv failed <nckx>Oh, I thought this was in response to something I said earlier. *rekado has to play with terraform these days <nckx>3.10 fails on aarch64, 3.9 segfaulted on x86_64, sigh. <vagrantc>nckx: locally i do ... just wondering if it's a known issue <vagrantc>also updating to the current git rather than my crazy local branch ... but i doubt anything i've done locally is the issue ... seems to have started with mailutils 3.10 <nckx>vagrantc: I ‘reported’ the same thing earlier, but haven't opened a bug yet. <nckx>It has nothing to do with your crazy branch. <civodul>apteryx: just saw your smart GDB trick, neat! <vagrantc>checking whether build environment is sane... configure: error: newly created file is older than distributed files! <vagrantc>janneke: i haven't tested weather your bash-mesboot0 hack works to not rebuild the world ... but clever! *vagrantc is largely hopeing someone else will fix it :) <civodul>vagrantc: BTW, on another topic, did you see guile-{l,}zlib? <nckx>sneek: later tell guix-vits: I added (service elogind-service-type) to my system configuration and rebooted. System works fine. elogind is running. <civodul>i had some thoughts about you and Debian packaging :-) <vagrantc>civodul: i've seen some failures regarding zlib in some capacity recently ... but just finally got a working build <vagrantc>civodul: debian packaging of guix? that is notably what caused me to find the bug in bash-mesboot0 ... packing up a fresh tarball with make dist <vagrantc>really want to get it uploaded ... all of the dependencies are in place for even using guile 3 in debian experimental, or guile 2 in debian unstable/testing <vagrantc>(just waiting for guile-gnutls to switch to guile3 in unstable/testing) <vagrantc>but it's been a while since i've tried building it <jonsger>civodul: I would be in for a CI hackathon, not sure how much I can help but :P <vagrantc>civodul: but what were you thinking regarding guile-*zlib ? <civodul>vagrantc: i was thinking it would give you some more work :-) <vagrantc>civodul: making it a dependency to build guix? <vagrantc>so far most of the guile dependencies haven't been too bad *vagrantc is so tempted to just upload guix 1.0.1 and disable all the failing tests <vagrantc>civodul: ok, thanks for the heads up regarding new dependencies <vagrantc>civodul: there's typically an arbitrary delay (sometimes hours, sometimes months, sometimes even years) to get stuff into debian... <civodul>all that said, i'm excited to see more and more Guile libs out there <nckx>raghavgururajan: Did you mean to give me a heart attack by using that shortener? Because you did :-/ <nckx>(I know you know the owner, but still. 😛) *nckx removes alert on nxnt. <nckx>raghavgururajan: Know, not are. <kristofer>sudo mtr ci.guix.gnu.org: 3. 71.152.199.124 <80% packet loss. substitutes are awfully slow. any ideas? <nckx>Unfortunately substitutes are known to be slow in parts of the world and we're not sure why (beyond ‘probably very bad peering’). <kristofer>I've not really experienced this until the last few days <nckx>The packet loss doesn't seem significant. <nckx>It's quite common for networks to be virtualised (MPLS etc.) and for intermediate ‘hops’ to report nonsense. <nckx>If you're actually losing packets at the end (141.80.238.11) that's another matter. <nckx>Yeah, you're not alone. I'm sorry. <civodul>nckx: hey, looks like reconfigure completed on berlin? <nckx>17:40 <nckx> Berlin has been reconfigured and cuirass{,-web} & guix-{daemon,publish} restarted. <civodul>i was wondering if we were running the latest & greatest <nckx>Cuirass is still running... 🤞 *raghavgururajan hopes someone noticed how he subtley planted Scheme in that request <nckx>kristofer: The issue has been reported regularly here, but I didn't find any actual bug reports (https://issues.guix.gnu.org/search?query=slow). It would be nice to have one. Ideally including as much info about your location/connection as you're willing to share. <nckx>‘It would be nice’... I can be subtle too. <nckx>The Web interface doesn't support opening new bugs yet, one needs to e-mail bug-guix at gnu dot org. <vagrantc>what's this guile-hall thing? is it really needed to build guile-zlib? <leoprikler>To be fair to the deltachat devs, they are not the only messenger that's a huge convoluted dependency hell <leoprikler>though admittedly the typescript bootstrap makes things a little worse <leoprikler>but Telegram's desktop app is a similar mess despite being written in C++/Qt <nckx>I think you fixed a bug like this before. Before I go hunting, does it look familiar? <nckx>Well, bug: bcachefs returned something slightly different from what was expected IIRC. <civodul>nckx: hmm i don't remember seeing that <nckx>I don't understand why that would matter since I'm building with /tmp on tmpfs. <hendursaga>Has anyone gotten a SoloKey to work? Or even YubiKey? On Icecat, using Webauthn? *civodul tries "make check TESTS=tests/guix-package.sh" <nckx>Ah, thanks, appreciated. I'm currently assuming it's something local but would be nice to know. <hendursaga>I might have to add some custom udev rules, but the traditional directory, /etc/udev/rules.d/, does not exist... <leoprikler>I think you should try packaging one of the python alternatives <leoprikler>We do have emacs-telega, which works very well, for example ;) <leoprikler>Great industry wisdom has it, that you can find millions of people willing to pack dozens of LOC per second onto any given JS program through a simple advertisement on stackoverflow. <leoprikler>You just don't have that kind of engagement when writing for the GNOME ecosystem. <leoprikler>looking at the toml, that's a huge dependency hell again tho *raghavgururajan + Zopiclone = zzZ <vagrantc>guile-zlib seems to build fine without guile-hall ...