IRC channel logs


back to list of logs

<leoprikler>I use it even in my smallest local packages, it's quite a weird thing
<NieDzejkob>oh, also possible. I haven't had any other experience with large guile projects
<NieDzejkob>(large = >1 file)
<NieDzejkob>nojr: see info "(guix) Invoking guix time-machine" for a solution to the 12 months part ;)
<leoprikler>well, my particular example is 5 modules and a script
<leoprikler>the thing is, that the script needs the module source before install, so...
<leoprikler>were I just targeting Guix, I could probably do without that, though
<leoprikler>because then I could do that during package build
<NieDzejkob>ehh, 504 on again
<janneke>hmm...guix system: error: exception caught while executing 'eval' on service 'root':
<janneke>ah, i need an extra module in the service
***sturm is now known as Guest6584
<NieDzejkob>Adding "autoreconf -vif" into the build of "rw" in graph.scm breaks the build. How is that even possible?
<NieDzejkob>(the exact patch I'm experimenting with: )
*janneke -> zZzz
<NieDzejkob>(motivation: rw 0.8 ships broken symlinks instead of the actual files)
***jonsger1 is now known as jonsger
<ryanprior>On a foreign distribution are you supposed to run `sudo guix pull` in addition to running it as your user?
<nckx>ryanprior: Yes. Unless you changed guix-daemon.service not to run root's daemon.
<ryanprior>Dang, I've never run that. I'm probably running a really crufty old guix daemon. How do I check?
<nckx>ryanprior: var/guix/profiles/per-user/root/current-guix/bin/guix describe… I *guess*?
<nckx>Or just readlink -m /var/guix/profiles/per-user/root/current-guix/bin/guix-daemon, it will contain the version.
<ryanprior>guix describe: error: failed to determine origin
<nckx>Eh, try method two, it's equally guessy.
<ryanprior>Version 1.0.1, so not ancient but not good.
<ryanprior>I guess that's nice to know that Guix will hum along without much problem even if you don't update the daemon, like, ever? But maybe there have been drawbacks?
<nckx>I've always edited /etc/systemd/system/guix-daemon.service to run my user's guix-daemon and left root's to rot, since all my foreign distro's were single-user machines. If your user has sudo, I don't see any security risk.
<nckx>ryanprior: The daemon is quite stable but there have been changes in the past.
<ryanprior>Okay yeah I'm also on a single user machine so maybe it hasn't been a problem then so far.
<anadon>Did `guile-next` get renamed `guile-3` or am I making things up?
<romulas>Put the latest iso onto a usb thumbdrive it doesn't work on UEFI, bug?
<apteryx>anadon: I think it did. guile-3.0
<romulas>Anyone use this with uefi?
<wdkrnls>I have efi on my laptop, but installed long ago. I remember having all sorts of trouble with the first USB stick I used. I switched to another USB stick and had no further troubles.
<pkill9>how do i find the latest guix revision that has substitutes available? my raspberry pi is struggling to run guix pull
<vagrantc>you might be able to query guix data service ...
<vagrantc>but for the most part, i think what youre asking for is not yet feasible without a lot of manual work
<pkill9>i remember civodul made something you could put in channels.scm that did it autonatically
<apteryx>pkill9: I seem to remember that too!
<wdkrnls>How do you even find the revisions?
<wdkrnls>I was thinking: git log | grep ^commit | awk ' { print $2 }'
<wdkrnls>But many of those don't show up in the guix data service.
<wdkrnls>I was think you could use a hack whereby you picked the last revision from yesterday and then updated every day with the revision from yesterday.
<wdkrnls>Not elegant, but unless you want to be continuously upgrading there will always be some period of time where you are potentially behind on security updates.
<wdkrnls>ice-9/boot-9.scm:1669:16: In procedure raise-exception: error: help-string: unbound variable
<wdkrnls>I'm getting that error every time I try and tab complete guix commands from Emacs.
<ryanprior>If I want an old version of a package that used to be in Guix but isn't anymore, I know I can use time-machine to zoom back and grab it. But if I want to mix that with some newer packages, do I have to do something hacky like guix time-machine <hash> -- environment --ad-hoc pkg -- guix environment --ad-hoc otherpkg
<wdkrnls>I'm no expert, but isn't that what inferiors are for?
<ryanprior>Okay, I'd heard of inferiors but thought it was an internal feature, I didn't realize it was intended for end-users. This does look less hacky than what I suggested :)
<apteryx>ryanprior: yes, I've never done so, but you're supposed to be able to use inferiors in a manifest to pin packages to older Guix revisions.
<ryanprior>This kinda looks like it's waiting for a better syntax, and it doesn't seem like it would be usable with the JSON manifest syntax which is too bad, but it at least seems better than the chain-'o-guix-commands hack.
<badair_>"symbol lookup error: /gnu/store/XXX/bin/myblob:
<badair_>"symbol lookup error: /gnu/store/XXX/bin/myblob:
<badair_>sorry, paste error
<jackhill>ryanprior: here's an example of how I've done it:
<jackhill>I factored out some of the boilerplate there since I'm doing it twice in the same manifest.
<badair_>Any idea what causes this? I changed the interpreter on a blob with patchelf, ldd looks fine now, but I get this: "symbol lookup error: /gnu/store/XXX/bin/myblob: undefined symbol: , version GLIBC_2.0". Apologies if this is the wrong place to ask.
<jackhill>ryanprior: so in that manifest, I'll always get nss-certs and glibc-locales from the current guix, but blender and dcmtk come from the pinned commit
***wxie1 is now known as wxie
<ryanprior>jackhill: that makes sense, took me about 4 minutes to read it and figure out what you were going for. Wish it were even clearer, though. Seems like something that could be just plain data and not require writing code.
<apteryx>ryanprior: you could probably come up with macro :-)
<apteryx>sounds fun
<apteryx>then contribute it so that we don't repeat ourselves
<ryanprior>It does in theory, but I have had no luck with writing Guile macros yet. The syntax seems obtuse because I don't get it yet, despite reading a bunch of examples and trying things for a few hours. X.X
<ryanprior>I haven't tried writing this specific macro yet & I eventually will, so third tim'.
<ryanprior>the charm!!
<apteryx>ryanprior: try syntax-rules at first; they're more straightforward. If you already know 'match', you're not far from knowing syntax-rules.
<nckx>badair_: My guess is the binary was built against a different version of glibc than the one you're now using. You can install binutils and run ‘readelf -s /run/current-system/profile/lib/ | grep <the symbol>’ to see if that sounds plausible, i.e. there's a <symbol>@GLIBC_<something else>.
<ryanprior>I've tried syntax-rules in the past and then when I ask for help it's invariably "oh you can't do that with syntax-rules, you need syntx-case"
<ryanprior>But I beat my head against the wall with syntax-case, I just don't get what it wants from me.
<ryanprior>I'm not bad at writing macros in Clojure, elisp, or Racket, but it seems like Guile is on some other shit. I'm sure it's just because I don't understand it yet but I'm reading examples like "wtfff"
<apteryx>eh, I'm not very confident in my syntax-case abilities yet myself :-). syntax-rules can do a lot of things still (such as recursion).
<badair_>nckx: Thanks. The libc version is compatible -- when I leave patchelf alone and just symlink to the expected paths printed by ldd on a throwaway system, the program works. I'm not sure why the error message is "undefined symbol: , " -- I don't recall seeing this "space comma space" thing in the past.
<nckx>Oh, that's a literal? WTF. I thought you were paraphrasing.
<nckx>Nor have I, then.
<badair_>The myblob path is a paraphrase but everything else is not. Thanks anyway!
<jackhill>ryanprior, apteryx: yeah, definitely. I assume that as people use it more, we'll figure out ways to make it nicer to do. Having looked at it again today, I see some things that could be cleaned up.
<jackhill>but I don't yet have a good sense about what Guix should provide. I'd haven't written this type of manifest enough to have any ideas.
<nckx>badair_: Definitely weird. No idea what it could mean, other than ‘patching binaries is fraught and all bets are off’.
*nckx → 😴 , good luck.
<ryanprior>One thing I want jackhill is an option to write a manifest that's just a data structure with no imperative code. edn, toml, json, yaml, recfile, whatever. Just not code with imports and functions and binding variables. I prefer not to have to reason that way about my dependencies.
<ryanprior>I can come up with some example hypothetical manifests in various data formats and send that to the email if you think it would kick off an interesting convo.
<apteryx>ryanprior: I think the chapter 8 of this book is pretty good at giving a better understanding of macros; coming from the creator of syntax-case himself:
<ryanprior>Nice, thanks.
<marusich>Hello, Guix!
<sneek>marusich, you have 1 message!
<sneek>marusich, guix-vits says:
<heil_bel>Hello, Guix.
<heil_bel>I've recently installed Guix on Arch-linux. And installing chromium caused a lot of things to rebuild, even though I enabled substitutes in installation script.
<heil_bel>Does is it mean that that packaged was not yet built on the build farm?
<jackhill>ryanprior: email to with your ideas/to see what other people think sounds reasonable to me. The other option would be and call it a feature request :)
<ryanprior> Great, adding this as a todo.
<jackhill>heil_bel: yes, I think that's right, it looks like the most recent ungoogled-chromium hasn't been build on yet
<jackhill>heil_bel: I checked with `guix weather ungoogled-chromium`
<heil_bel>Oh, that's nice command. Thanks a lot. So here is another question. Can I do guix pull to specific state where everything is available as a binary?
<vagrantc>that presumes everything was ever available :)
<wdkrnls>From what I've read, that's actually a pretty tough problem. I was thinking about taking the git commit from yesterday and building from that.
<jackhill>heil_bel: yes, guix pull --commit=whatever, but the experience of finding out which commit is a good one for you isn't really there yet as far as I know.
<wdkrnls>cd ~/your/code/guix
<wdkrnls>git pull
<wdkrnls>git show master@{yesterday} | cat | grep ^commit | awk '{ print $2 }'
<heil_bel>vagrantc: totally lold :D
<jackhill>also note, that in the future, you'll; get warnings about going back in time (to protect against an adversary foring you to downgrade).
<jackhill>vagrantc: heh :)
<jackhill>seems like the weather is bad for browsers right now, Icecat doesn't have a substitute either.
<heil_bel>jackhill: That's what I've searched for. wdkrnls: Wow.Thanks.
<jackhill>looks like webkitgtk browsers should be good though
<vagrantc>heil_bel: it came up against earlier, that was a thread from over a year ago where an example was posted
<vagrantc>er, came up again...
<vagrantc>heil_bel: it may need to be refreshed for current guix versions
<heil_bel>jackhill: It's not like I want to downgrade. But to make guix pull to not totally newest state.
<vagrantc>i've never used it ... but there you are
<heil_bel>vagrantc: That's nice. I'll search for this. ;)
<vagrantc>just pulling yesterday's commit might actually have less things built than today, since things often get fixed on master ... and things get broken on master too ... so time-based checks aren't necessarily going to serve one well
<vagrantc>but whatever works for you :)
<xelxebar>Have a package with failing tests. Trying to get to the bottom of it, I'm trying to recreate the failing `make check' but starting a --pure environment and running from `make check' from the build directory produces *different* and a lot *fewer* failing tests.
<xelxebar>... Nevermind. I forgot that I tried in a --container environment and it mirrors the build failures exactly.
<marusich>sneek, later tell dftxbs3e I sent an update, though I'm afraid it isn't resolved yet:
***apteryx is now known as Guest53265
***apteryx_ is now known as apteryx
<xelxebar>Okay, so I have a guix environment --pure --container that I'd like to pack into a tar to send to someone. AFAIU, this is possible by taking the $GUIX_ENVIRONMENT/manifest and feeding it to guix pack -m.
<xelxebar>However, guix pack -m /gnu/store/.../manifest is erroring out with "Wrong number of arguments"
<xelxebar>Yeah, doing guix pack -m ~/.guix-profile/manifest fails the same way. :/
<xelxebar>What am I missing?
<xelxebar>Same thing with `guix environment -m'... Are the `manifest' files under profiles not the same as the "manifest" provided to the --manifest option?
<mmmwww>Hello, guys. What can be a reason of long xdg-mime database building on foreign distro(4 mins)? Here are some details and info about my system:
<mmmwww>I've already tried `guix gc` and reinstalled xdg-utils by pacman
***steochio[m] is now known as Sosakum
<xelxebar>mmmwww: I can't offer much insight, but that's a common issue, even on native guix systems.
<guix-vits>xelxebar: same there for ~/.guix-profile/manifest, but it works with the manifests like this:
<mmmwww>xelxebar: What a pity ;(
<guix-vits>mmmwww: You can check the Cookbook, about profiles. Small profiles (one user can have many profiles) seem to build faster.
<mmmwww>guix-vits: Thank's! I'll dive into it
<xelxebar>guix-vits: I'm not sure you understand my problem...
***matijja``` is now known as matijja
<guix-vits>xelxebar: one thing i'd noticed: `guix pack --dry-run -m ./manifest .` returns "guix pack: error: .: unknown package"
<guix-vits>instead of "Wrong number of arguments"
<xelxebar>guix pack -n -m ~/.guix-profile/manifest still gives me "Wrong number of arguments"
<leoprikler>Since you spawned that container using `guix environment`, can you not go back in the command line history and substitute environment to pack?
<leoprikler>for the record `guix environment -m` returns the same error
<leoprikler>I think the difference is in the way, those manifests are read
<leoprikler>$PROFILE/manifest is a serialisation of data, whereas your typical manifest files are guile script
<leoprikler>in particular, I don't think the syntactic sugar to define manifests is present in -m
<xelxebar>leoprikler: Well, I need the *development environment* for <package>, not an environment containing <package>.
<xelxebar>... need *a pack containing* the...
<leoprikler>that sounds like a very weird requirement, but `guix pack` should give you the closure anyway
<leoprikler>i.e. development environment + package
<xelxebar>leoprikler: Really?? Including native-inputs not linked in the final output?
<leoprikler>oh, right
<leoprikler>in that way, you have to use package-inputs from scheme
<xelxebar>I wish to do this because a piece of software I am packaging is failing its tests in an odd way. Am working closely with upstream to troubleshoot but figured a chroot-able tar to share would make life a lot easier
<Kimapr>qtpass can't find gpg
<leoprikler>like (packages->manifest (append-map (cute <> my-package) (list package-inputs package-native-inputs ...)))
<Kimapr>even though it is installed in profile
<guix-vits>Kimapr: pinentry installed too?
<Kimapr>what is that
<xelxebar>leoprikler: This is certainly hitting up against the limits of my guile knowledge. Would there be a way to use the (packages ...) list in the `manifest' file almsost as-is and somehow compile that into a manifest?
<guix-vits>Kimapr: idk, but was needed for generating gpg. It's pops up and asking password..
<xelxebar>That said, if the `manifest' files really are serializations only, it might be a fun project to implement the deserialization.
<leoprikler>Kimapr: QString gpgExecutable = QtPassSettings::getGpgExecutable(Util::findBinaryInPath("gpg2"));
<xelxebar>Anyway... so much yak-shaving. This is already like 10 steps removed from the problem I'm *actually* supposed to be solving.
<leoprikler>ls `guix build gnupg`/bin contains only gpg, no gpg-2
<leoprikler>xelxebar: I think you could do that with a thin wrapper around your manifest
<leoprikler>the thing is, those modules don't appear to be loaded by default when you do -m
<guix-vits>leoprikler, Kimapr: also gpg can be specified in settings that pops up (qtpass).
<Kimapr>qtpass is configured to use `pass` by default
<leoprikler>xelxebar: (call-with-input-file "/path/to/manifest" (@@ (guix profiles) read-manifest))
<guix-vits>Kimapr: the config is in ./.config/IJHack/QtPass.conf; gpgExecutable=/home/guix-vits/.guix-profile/bin/gpg
<leoprikler>hmm, should we add gpg as input to qtpass and substitute* that code?
<leoprikler>or would that get serialized?
<xelxebar>leoprikler: Nice! read-manifest is the magic. Thanks.
<xelxebar>leoprikler: How did you end up finding read-manifest? I tried hamfistedly grepping through the repo without much luck.
<leoprikler>I found the <manifest> record in (guix profiles) and continued reading
<leoprikler>btw. instead of read-manifest, you should almost always use profile-manifest, but eh
<guix-vits>leoprikler, xelxebar: Thanks, this is funny.
<xelxebar>leoprikler: Thanks. I'll have to take a look myself.
***dingenskirchen1 is now known as dingenskirchen
<raghavgururajan>Hello Guix!
<raghavgururajan>mbakke: Do you have any new info regarding
***janneke_ is now known as janneke
***dingenskirchen is now known as 874AAIOJ9
***874AAIOJ9 is now known as dingenskirchen
<apteryx>raghavgururajan: o/
<raghavgururajan>apteryx: o/
<efraim>I took a quick look at qtpass, I wasn't able to fix the gpgExecutable issue even with substitute* but I did fix the lack of icons
<apteryx>efraim: did you substitute the reference leoprikler found with something like: QString gpgExecutable("/gnu/store.../gpg2") ?
<apteryx>did should work, AFAICT
<leoprikler>we don't have gpg2, just gpg
<apteryx>s/gpg2/gpg/ then :-)
<leoprikler>perhaps that's an issue here – if qtpass demands to talk to some "version 2", that we don't have, then it might just throw the same error as if it hadn't found any executable
<apteryx>hm? we have just gpg, but it *is* gpg version 2
<leoprikler>I haven't looked deep enough in the code to see what they do with gpg.
<royball>hello guix. may i be so bold as to close out older bug reports that have already been fixed?
<apteryx>royball: please do!
<apteryx>(if you're sure they're indeed closed :-) and no valid reason to keep them open remain)
<royball>thanks. for the slightly questionable ones, i'll ask first.
<apteryx>great, thank you!
<raghavgururajan>leoprikler,efraim,apteryx: gpg2-->gpg on line 289 in ?
<apteryx>but this might get gpg version 1, if the user installed gnupg@1 in their profile
<apteryx>QString gpgExecutable("/gnu/store/jf0sn40hfsbif8zfp7dfw9avv4mq3frm-gnupg-2.2.20/bin/gpg"); seems better to me.
<raghavgururajan>leoprikler,efraim,apteryx: There is also gpg2 occurance on line 240 in , but it is within if-block to also find just gpg.
<leoprikler>yeah, that autodetect implementation seems benign
<leoprikler>that within qtpasssettings does not
<efraim>apteryx: raghavgururajan I changed both occurances of gpg2 to gpg
<efraim>i also tried ./pre-inst-env guix environment --ad-hoc qtpass gnupg -- qtpass and it didn't pick it up automatically
<efraim>it only autodiscovered git
<efraim>I'll leave qtpass to you guix to play around with, I'm back to banging my head against lyx
<apteryx>which guix does guix deploy uses? From the profile of the remote user profile it uses, I guess?
<janneke>hmm... root@dundal ~# cat /var/run/tor/
<janneke>herd says tor is stopped, but netstat says it's running and icecat agrees
<nckx>Shepherd sometimes loses track of things.
*wigust gets 504 Gateway Time-out nginx on
<civodul>apteryx: "guix deploy" uses the "guix" in "guix deploy" :-)
<civodul>just like "guix system reconfigure"
<civodul>there's no magic here
<civodul>nckx, janneke: could you report a bug?
<civodul>someone mentioned an issue with the tor service
<civodul>but AFAIK Shepherd doesn't "lose track of things" in a general sense, that'd be a serious issue :-)
<janneke>i agree
<civodul>maybe it's something with services is containers
<janneke>i just stumbled on this, i'll have a look; i kinda need tor atm :-P
<civodul>( is always 1)
<janneke>ah, container..right -- that helps
<nckx>civodul: It's lost a running nginx once this ~year. I didn't file a bug because I had no useful information beyond that.
<janneke>civodul: i took the authenticate series for a little test drive, works for me
<civodul>nckx: ok
<janneke>i have this interesting setup where i use a fork with a backport: GUIX_PACKAGE_PATH=guix ~/src/guix/x/pre-inst-env guix time-machine --url=$HOME/src/guix/master --commit=056c5606df7ce0438d8e3cd1af99a21417b8c56b -- environment --ad-hoc mcrl2-minimal
<civodul>nckx: i think we should just not suggest that we're aware that things are broken in a broad sense :-)
<civodul>janneke: cool, thanks for testing!
<nckx>civodul: I'm (somewhat deliberately) clueless about shepherd debugging. Is there a ‘dump worldview’ kind of command I could run if it happens again?
<janneke>still works neat
<civodul>nckx: "sudo herd status" i guess
<civodul>but shepherd is really dumb
<janneke>i was wondering about the --disable-authentication being needed for pull but not time-machine, but it seems to work for me
<civodul>so then, if you have a case like janneke describes, you can just send shepherd.log, "ps aux|grep tor", things like that to see at what time it went wrong
<civodul>janneke: mostly it was a bit more work to do it for time-machine, but we can add it if needed
<civodul>would it be useful to you?
<nckx>civodul: Well, sorry, but it's happened often enough (>4 times over the past 2 years or so) that pkilling things is now high on the debugging list when I get strange output. I was not aware it was even a controversial statement 😉
<janneke>ah, okay -- i don't have (or see) a use case for that right now; but i was a bit worried about my fork, which gave me extra incentive to read the series and test
<janneke>come to think of it, authentication is real good to have, also on my fork
<civodul>nckx: to me it's unhelpful if there are no bug reports
<civodul>i mean, we don't write software and willingly keep it broken, right? :-)
<civodul>so people should not assume that developers are aware of bugs not reported IMO
<janneke>i very much agree
<nckx>I thought there *was* a bug report about it.
*civodul .oO am i grumpy?
<civodul>nckx: dunno, i don't remember it at least
<janneke>civodul: did you see mothacehe's reply on my draft hurd-in-vm -- did i get that idea all wrong?
*janneke was left kinda puzzled
<civodul>janneke: i haven't checked mail, lemme see
<janneke>=> guix-patches
<janneke>i just thought it would be neat to test hurd-in-vm in a vm; reconfiguring my system all the time feels...a bit ugly
<nckx>civodul: Where or what is bug-shep@?
<janneke>nckx: =>
<janneke>use [SHEPHERD]
<guix-vits>... Luke
*nckx .oO Thought Shepherd/dmd was older than Guix.
<janneke>well, it used to be ... but not anymore (/me trying to make an elaborate joke)
<nckx>Worked here.
<janneke>uhuh; -rw-r--r-- 1 root root 30979 Mar 29 2018 /var/log/shepherd.log
<raghavgururajan>efraim: Weird!
<guix-vits>janneke: 30 Kib for 2 years, correct?
<janneke>guess it's grep "localhost shepherd' /var/log/messages now
<janneke>guix-vits: shepherd.log, not touched for 2years ;-)
***dustyweb` is now known as dustyweb
<bdju>anyone here have the pinephone? I'm wondering if some tools related to it will be packaged sometime soon
<bdju>like jumpdrive and pmbootstrap
<guix-vits>bdju: Is it ready for non-hackers to use?
<bdju>hard to say. I am struggling with it a bit myself
<bdju>I got the version with UBPorts and I want to switch to something else pretty soon because it seems disappointing, but I may need some other software to write the new OS image
<bdju>or maybe dd will just work. I am still learning
<bdju>I think several of the distros have working calls/texts now, but so far I have not put my SIM in. I'm just using it on the side while I learn some things
<bdju>maybe needs a bit longer before non-hackers can use it
<nckx>royball: Thanks for bug-sifting!
<royball>nckx: np. looks like a good place to start and learn to be able to start bug-fixing!
<guix-vits>bdju: ah, imagining the working with a portable device with the users able to `ls /`, not that "android/" stuff.
<NieDzejkob>bdju: Want to try packaging them yourself? The Guix documentation about this is pretty good and we're here if you get stuck
<bdju>NieDzejkob: I have had many bad experiences trying to package things, honestly. I want to be able to do it, but I'm not feeling confident.
<bdju>what do I need to get auto-mounting of removable storage working? I have gvfs and I have volume management enabled in pcmanfm settings, but the sd card I just inserted doesn't show up on the side or get mounted. it shows up in blkid output, though, so it's being detected
<guix-vits>bdju: Do you willing to test it with `nautilus`? Maybe some pcmanfm bug.
<NieDzejkob>bdju: for guix specifically, or other distros?
<rekado_>I’m back
<rekado_>looks like I missed a lot of cool hacks
<rekado_>(baby got sick, so I couldn’t be around)
<guix-vits>Hi rekado_.
<janneke>hey rekado_, happy to see you're managing your priorities! i take it all is well now?
<nckx>bdju: I don't use auto-mounting myself, but are you sure gvfs is supposed to handle it on its own? We have a udisks-service that looks like you want it too.
<rekado_>janneke: yeah, the fever just dropped an hour ago and all is well again.
<rekado_>now I just need to figure out when to get all that sleep I missed since Sunday :)
<nckx>Hi rekado_! Bye rekado_!
*rekado_ nods off
<janneke>rekado_: good te hear, it's remarkable what these persons are capable of, sometimes
***MSavoritias_ is now known as MSavoritias
<bdju>nckx: I'm not sure, just thought that gvfs was likely related. udisks does sound familiar. I'll take a look.
<bdju>NieDzejkob: guix system specifically
<bdju>alright, I added the udisks service and did a reconfigure. I may have to log out or something for it to take effect
<NieDzejkob>bdju: huh, I'm sorry to hear that. Would you mind telling us what these experiences were? We'd certainly like to improve. (or perhaps you spoke about it before and you could point me to that - also works)
<bdju>NieDzejkob: I'm just working with not enough knowledge when it comes to packaging and I seem to lack the patience, quickly getting stuck and giving up. lots of things are unclear, like how you determine missing or incorrect info in the recipes and whatnot.
<NieDzejkob>bdju: by info, you mean dependencies, or...?
<bdju>partially, but also I'm not even entirely sure what makes something a regular input vs native-input and how to determine when a use-module is needed. it seems the hello.scm recipe is too barebones to use as an example
<nckx>bdju: Roughly, an input must be native when it needs to run (not just be linked against, provide headers, &c.) at build time. That's where the term comes from: say you're building for aarch64 on your x86 laptop. You want your package to link against an aarch64 ncurses, because it needs to run on your ARM board, but e.g. pkg-config must be ‘native’ (x86) because it needs to be able to run on your laptop.
<bdju>I don't entirely understand
<bdju>also I maybe gave the wrong impression, I've never managed to package stuff for other distros either, I've just only tried for guix, so some of my issues are general after all
<apteryx>civodul: re the guix used by 'guix deploy', I see, thank you. So it's building the system closure locally with my guix, then transferring (deploying) this to the remote system.
<joshuaBPMan>Hey guys...I am using guix system. I am browsing youtube vida (an AGPL+ alternative to youtube). And I am using a VPN (express VPN) via network manager. I do not believe that I am leaking DNS requests...Why is it that youtube and and hooktube all seem to show the same videos that I like to watch? eg: Everytime I go to I see lost of computer-y hardware videos. If I am using a VPN how does youtube
<joshuaBPMan>remember what videos that I like? I am not logged into youtube. Is there a web browser plugin I can use?
<lfam>joshuaBPMan: Presumably most people that use a VPN are into computer stuff
<lfam>I've never visiting until today and front page is all about computers
<lfam>Computers and stuff that computer nerds like
<lfam>If you ever used from your IP then it will remember you
<lfam>There's a plethora of techniques to show you what it thinks you like
<joshuaBPMan>lfam: ahhh.
<lfam>And, I don't watch any computer stuff or related on youtube
<lfam>And I do use youtube all the time
<joshuaBPMan>lfam: I share the same wifi with 2 roommates...
<joshuaBPMan>lfam: thanks.
<lfam>Right, so you are effectively the same person at some level, although not at the cookie level obviously
<lfam>I don't know how the VPN comes into play but you could be separated if you use IPv6, but IPv4 NAT will make you look similar, although youtube / google could still tell you apart
<leoprikler>you can do browser fingerprinting
<lfam>By browser fingerprinting, mouse cursor fingerprinting, times of day, how long you watch videos, how often you pause, et
<lfam>Personally I don't care or find it scary but it's quite an impressive set of tools they've built
<lfam>I wouldn't try to stay anonymous from them if I needed to. I would just stop trying to watch their videos
<mbakke>raghavgururajan: I had forgotten about that bug report and not looked more into it. Did you observe the problem somewhere?
<NieDzejkob>bdju: If you still have the incomplete package definition for the thing you last tried to package, we could work through it together if you wanted.
<leoprikler>tbh I really don't get the advantage of using a VPN in terms of security
<leoprikler>I get, that you may want to circumvent region locks, but that's it imo
<lfam>I guess it depends on your threat model. It (ideally) moves the threat from one entity to another
<apteryx>how easy/difficult is it to share /gnu/store across different machines? Say, for CI purposes (many build slaves). Or would configuring the build slaves to use one another as substitutes be a better idea?
<leoprikler>yeah, but those two entities are an ISP and a pseudo-ISP, so not much is gained here
<drakonis1>apteryx: not difficult
<apteryx>drakonis1: how do you do it? NFS or something else?
<drakonis1>your options are to use a distributed filesystem or a online filesystem
<drakonis1>NFS, ceph or gluster
<drakonis1>depends on whether you want the store to be on a single machine and shared to other machines or distributed between multiple machines
<mbakke>apteryx: all deployments I know of use NFS with a single writer, other nodes communicate with the head node over an SSH socket
<mbakke>apteryx: I think you just need to share /var/guix and /gnu and you're good to go
<mbakke>drakonis1: have you tried running a distributed store?
*mbakke dreams of Guix on CephFS
<drakonis1>ah i wish
<drakonis1>i dont have enough machines to do a distributed store
<drakonis1>wouldnt running a store with ipfs be similar?
<apteryx>mbakke: multiple Guix daemons can connect and write to the SQLite database without any issue?
<mbakke>apteryx: from the perspective of the "head node", requests from SSH is just like any other local Guix client
<apteryx>ah, I had missed your reply above wit the single writer... hm
<drakonis1>apteryx: i'll admit i haven't actually done that, as i do not have a use case for it
<mbakke>apteryx: but I don't think having multiple writers on the sqlite db is safe
<mbakke>it will probably work for a while though :P
<drakonis1>but the solutions do exist
<drakonis1>sqlite isn't built for multiple writers
<drakonis1>its something you embed on a application
<drakonis1>the most it'll happen is that you have to queue for writing
<apteryx>Yeah, that's why I had interrogations regarding sharing /gnu/store usefully.
<drakonis1>ie: "SQLite database is busy"
<drakonis1>wouldn't it be interesting to have different sql backends?
<drakonis1>isnt cuirass capable of handling that?
<drakonis1>parallel and distributed builds
<drakonis1>that is
<leoprikler>guix itself already has offloading, so...
<apteryx>mbakke: I see. I finally grok how it can work in the current state of things (master node with slaves ssh'ing their daemon requests through GUIX_DAEMON_SOCKET)
<drakonis1>nix already does distributed builds by itself
<mbakke>apteryx: there is a blog post about it: :-)
*mbakke finally got around to packaging ganeti \o/
<apteryx>mbakke: eh, thank you
<mbakke>apteryx: eh, you're welcome! :D
<bdju>NieDzejkob: thank you for the offer, I'll think about it.
<mbakke>so 'staging' has 90% substitute coverage on x86_64
<joshuaBPMan>lfam: thanks!
<joshuaBPMan>for the nifo
<lfam>leoprikler: Yeah, but some ISPs are differently-trustable than others. Ultimately I think the only true protection is a government that represents you
<lfam>I've worked to push HTTPS adoption and things like that but it only gets you so far
<joshuaBPMan>lfam: how close is gnunet and IPFS getting to replace the current interwebs?
<joshuaBPMan>Will it ever?
<lfam>I think it's quite far
<lfam>It's more likely the web (not the internet) will just disappear as apps take over
<lfam>I think it's already happened in the rich world to a large degree
<lfam>I don't really know about the non-rich parts of the world but I think they mostly use phones, so probably the same
<[df]>(vaguely relevant) it is rather annoying that the asymmetry of connection speed that was kind of a worthwhile trade-off for ADSL has become the norm
<lfam>And I think it's a shame that the free software movement is taking an absolutist approach to phones, pushing niche OSs and hardware, rather than replacing specific apps on popular platforms. The latter is how the movement started, when it recognized that it had to work piecemeal
<lfam>We got there with servers, almost with the desktop, but with phones we have to start from scratch, more or less
<lfam>[df]: Yes, although I think that residential fiber and 5g wireless is making it better
<lfam>Well, all that we can do is try to improve the situation! Let's keep going :)
<[df]>the real problem with apps I think is that they're closed-by-default: the people building them would have to go to extra effort to make them free and they tend not to, without necessarily having a good reason
<lfam>It's true, but even when they do make them free software, there is a horde of attacks by people who say they aren't free enough, or that the platform makes the effort worthless
<[df]>lfam: actually I was thinking about the 5G 'home broadband' connection I recently signed up to: I keep ~200Mbps down and ~10 up
<lfam>[df]: That's pretty bad and not what mobile 5g is about. It's supposed to enable large groups of real-time video upload
<[df]>I mean, 10Mbps upstream is nothing to be sneezed at obviously :)
<lfam>I mean, large groups of people sending video all at once
<lfam>Like, a stadium of sports fans all streaming at once
<lfam>They need to fix the backhaul and I'm sure they will soon
<[df]>is it a backhaul problem?
<lfam>Well, the 5g radios can definitely do more than that
<[df]>I kinda assumed fibre doesn't really care which way the data is going
<lfam>I don't know the details but I doubt they've replaced the switching infrastructure on many towers yet
<lfam>And in many cases the phone company calls it "5g" but it's not
<lfam>I would check back in 2 years
<lfam>Hardly anyone has a 5g radio in their phone yet
<[df]>well I hope you're right, I get the impression that it has been decided that consumer internet is asymmetric and that's it
<lfam>I think it will improve as 5g spreads. Residential wired is more expensive to change so that will take a while. I actually doubt many places will ever get upgrades. Everything is going wireless
<lfam>This is my optimistic take on the situation :)
<[df]>then we just need to get everyone off CGNAT and onto IPV6 :)
<lfam>IPv6 with privacy extensions
<lfam>My city has a community-based mesh wireless ISP, too
<lfam>It's spreading slowly but steadily throughout the city and I've heard it works well
<lfam>A better world is possible
<[df]>oh that's good news
<[df]>(there's a good chance mine does too but I haven't looked into it tbh)
<lfam>We have to remain open to the idea that the status quo can be completely changed
<lfam>Because otherwise it will never be
<[df]>on this and many other issues
<lfam>On every issue
<[df]>this looks worth a read in my case:
<[df]>ah, rather old :(
<lispmacs[work]>hi, I've been a Gnome 3 user for a while. I added mate-desktop-service-type and was giving Mate a try on the same desktop. However, Mate doesn't seem to be able to access my Gnome keychain, and is not asking to unlock it.
<lispmacs[work]>Is that a bug, or do I need to add something else to my config.scm?
<leoprikler>you need to do something in your config.scm
<efraim>You might need to tweak a configuration somewhere in mate to have it start or unlock or whatever it does with gnome-keyring at login
<leoprikler><- the one who implemented keyring for gdm
*efraim was guessing
<lispmacs[work]>leoprikler: I am looking at Desktop Service section in manual but it is not obvious to me what nees to be added
<leoprikler>you need to adjust the pam-services field of gnome-keyring-service
<leoprikler>it should be `(("some-login-service" . login) ("some-passwd-service" . passwd))
<leoprikler>wait, do you still use GDM?
<lispmacs[work]>leoprikler: yes, gdm
<leoprikler>okay, in that case your login keyring *should* be unlocked – try seahorse
<lispmacs[work]>seahorse does appear to be installed. I'll add it to my config.scm
<leoprikler>no, i mean try executing seahorse
<leoprikler>check whether the default keyring is unlocked
<lispmacs[work]>leoprikler: I meant, does not appear to be installed
<leoprikler>p sure you can launch it from an ad-hoc environment
<lispmacs[work]>okay, I'll do that, standby
<kondor[m]>i'm back
<leoprikler>hmm, a quick google search makes me wonder, whether mate wants to roll their own keyring
<lispmacs[work]>leoprikler: if I run seahorse from an environment shell, I see the "Default Keychain" but it says it is locked. There is an unlock button, but it doesn't seem to do anything
<leoprikler>hmm, so it indeed does appear as if GDM+Mate causes trouble when trying to unlock the keyring
<lispmacs[work]>leoprikler: there is a very recent messages log that says
<lispmacs[work]>couldn't create system prompt: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.keyring.SystemPrompter was not provided by any .service files
<leoprikler>try adding gnome-keyring to your system packages
<lispmacs[work]>that was from gnome-keyring-daemon[721]
<lispmacs[work]>leoprikler: the pacakge itself, not a service?
<leoprikler>the package itself – the service does not install the package, it just references it
<NieDzejkob>I can't get grafts to work. I added a replacement for nghttp2 (, doing ./pre-inst-env guix build nghttp2 shows the new package; hiawatha depends on nghttp2:lib, but when I ./pre-inst-env guix build hiawatha the hash doesn't change and ldd /gnu/store/.../sbin/hiawatha prints the old version of nghttp2
<leoprikler>perhaps that was a mistake on my end
<NieDzejkob>do grafts handle inputs other than "out"?
<leoprikler>I don't see why they shouldn't be able to handle arbitrary outputs
<NieDzejkob>leoprikler: could you try reproducing my nghttp2 issue? maybe I'm missing something dumb
<leoprikler>instead of build hiawatha try environment --ad-hoc hiawatha
<leoprikler>at least that's what I'm doing rn
<leoprikler>it does build nghttp2, but it does not appear to graft
<leoprikler>so yeah, same result
<mbakke>oof, I was about to merge staging, but then discovered this during some last-minute testing:
<mbakke>I've fixed it locally with a graft of Mesas 'staging/20.0' branch + one additional patch ... I think I'll wait for 20.0.8 before merging and graft that.
<bdju>logging out and back in didn't make pcmanfm volume management start working
<bdju>I'll test with nautilus
<lfam>That's still a cool page [df], even if it's old
<romulas>How to I change to the latest linux-libre kernel?
<sneek>Welcome back romulas, you have 1 message!
<sneek>romulas, nckx says: Yes. The installer supports both UEFI and BIOS (or CSM) systems equally.
<romulas>Anyone know?
<mbakke>NieDzejkob: looks like that graft should work
<guix-vits>romulas: Kernels are specified in the system wide config. Arent the latest Kernel is default one?
<leoprikler>romulas: (kernel linux-libre-...)
<leoprikler>IIRC we're stuck on 5.4 rn when 5.6/5.7 are already present in the Guix tree
<romulas>Do I just do a guixpull then restart?
<bdju>removeable drives don't show up in nautilus either. I couldn't find an option to enable volume management, so I'm assuming it's just a default thing.
<lfam>The 5.4 kernel is still default in Guix because the 5.6 and 5.7 kernels have not been configured in a careful way
<lfam>We need help with the task of updating the kernel configurations
<romulas>Okay so I just have to wait for it to become default?
<leoprikler>guix system reconfigure /path/to/config.scm
<lfam>See here:
<leoprikler>5.4.31 is pretty outdated, we're on 4X rn IIRC
<guix-vits>oh, thanks...
<lfam>The 5.4 kernel series is supported by the kernel team until 2025, so it's not considered too old or anything like that. But we need to recruit someone to help manage the upgrades
<romulas>It updated to 5.4.34
<lfam>The latest version of 5.4 in Guix is 5.4.37
<romulas>I noticed I have to change my UEFI to legacy for it to work that is bios mode.
<lfam>Although the upstream latest is 5.4.46. We can at least do that without expert knowledge
<romulas>Good work thus far.
<leoprikler>lfam downloading from
<romulas>What are you thoughts on Zstd?
<lfam>Huh, what am I missing leoprikler? :)
<leoprikler>probably guix pull?
<lfam>We have it packages romulas. Seems to be the state of the art in general-purpose data compression
<lfam>I'm looking at my git tree
<lispmacs[work]>leoprikler: hi, I added gnome-keyring package to my config.scm, did a reconfigure, and rebooted. After reboot, I could see gnome-keyring-daemon running as a process, but am getting the same behavior within Mate.
<lfam>My bad, I was looking at the wrong variable
<lfam>I was looking at deblob-scripts-5.4, which is different
<leoprikler>lispmacs[work]: that's to be expected, I guess
<romulas>You think the next version of guix (the iso) will have KDE as an option on the installer?
<lfam>romulas: Probably not unless somebody starts working on it now
<leoprikler>it appears mate rolls their own fork of the keyring-service, which doesn't play nicely with gnome
<leoprikler>at least that's what I got from mint forums
<lfam>People have been working on KDE but I don't believe we have the full desktop environment yet
<romulas>Interesting, thanks. Ifam.
<romulas>Works good in gnome-boxes can't get it to run on my box because of amdgpu non-free firmware
<mbakke>NieDzejkob: I added an artificial reference on 'nghttp' without the lib output, and that gets grafted
<leoprikler>I think you'd need to copypasta some of the gnome-keyring code and s/gnome/mate to make things work
<romulas>Thanks all.
<mbakke>NieDzejkob: can you file a bug about it?
*mbakke -> afk
<NieDzejkob>mbakke: Will do later today. It would be nice to fix that soonish because I'd be bad if CVE-2020-11080 waited for core-updates.
<guix-vits>leoprikler, lfam: If not Debian, then why not take Parabola's ( ). Currently 5.6, and 86, 64, and armv7h configs are present.
<lfam>It's a good question. I would really like for us to do it ourselves but if we can't it's a good option. We probably can't take Debian's because they don't follow the Free Software Distribution Guidelines that we do
<lfam>I do think we might make some different choices than Parabola but ultimately if we can't do the work, then we can't do the work
<lfam>Learning how to configure the kernel builds according to the FSDG, and then doing it regularly, would be a crucial contribution to the Guix project
<lispmacs[work]>leoprikler: so, then, are we needing a package for mate-keyring-service? Do I need to file a bug report for that?
<guix-vits>(Kernel) Joint efforts? Probably there is not that much options in L. Kernel that Guix depends on (for example, Gentoo's sources have had a small category with only 4 or 5 options). So idk, but doubt that every GNU distro should re-doing the same work.
<lfam>The different linux-libre distros have different values and goals. I do think there is value in re-doing the work.
<mbakke>NieDzejkob: great, thanks
*mbakke sucks at afk
<lispmacs[work]>leoprikler: mate can't access my existing keyring, but doesn't seem to be trying to use another one
<lispmacs[work]>maybe it isn't creating one because it sees the one there it can't use
<lispmacs[work]>I suppose i could try creating a new one and switching to it
<lispmacs[work]>but am a little nervous... depending on Gnome right now for intense production usage
<romulas>Mesa 20.1.1 Released With The Open-Source Driver Stack Being In Good Shape
<guix-vits>btw, Parabola has CONFIG_USER_NS_UNPRIVILEGED=y. Aren't this cool? Also "Full Preemption" instead of "Voluntary" (Gnome was snappy. Arch does good Kernels. Do it mess with HPC-thingy?).
*guix-vits (phoronix vs tor) hates Cloudflare, despite the lecture taken about tokens or whatsnot in the near past.
<romulas>TransCoder: Unsupervised Translation of Programming Languages (Paper Explained)
<lfam>Unprivileged namespaces are cool but fraught with peril. The implementation is not very reliable
<bdju>got a kernel panic when rebooting. had to boot an older generation
<romulas>How did you do that?
<pkill9>how do you generate the guix binary image for installing on another distro?
<pkill9>i want one with up to date guix
<rekado_>pkill9: the manual lists the command for that
<nckx>pkill9: See (guix)Binary Installation
<bdju>romulas: if you mean me, from grub you can select older generations from a list
<romulas>I see
<nckx>‘The binary installation tarball can be (re)produced and verified simply by running the following command…’
<rekado_>pkill9: in my info reader I hit “i” for the index and then “i[nstallation image]RET”
*nckx hits down arrow down arrow … down arrow RET because noob :-/
<nckx>romulas: So the reason I asked about trying another USB drive is that I had the same problem a while ago. Guix didn't even show up in the UEFI menu. There was no corruption. Wrote it to a different drive, worked fine. I don't think there's much we can do about that without some hint of an error message :-/
<nckx>romulas: There are plenty of machines that hard-code something they shouldn't. You could try copying /EFI/Guix/grubx64.efi to EFI/boot/bootx64.efi.
<pkill9>aww, i cant build for armhf on x86-64
<leoprikler>lispmacs[work]: hmm, it appears that our mate package ships gnome-keyring
<leoprikler>which is weird, given that you had to install it on your own again
<leoprikler>btw. wdym if you say "MATE can't access your keyring"
<leoprikler>is there a MATE component, that interacts with it failing or what?
<Kozo>pkill9: You can with qemu-binfmt-service-type, under virtualization service
<pkill9>oh cool, so i just add that service and i can?
<Kozo>pkill9: Yes, there are examples in guix manual under that service of how to add it