IRC channel logs

2022-01-08.log

back to list of logs

<nckx>Dare to dream!
<vldn>Anyway to Download a substitute from the ci manually and put it Into the Store?
<vldn>Wine trys to build even with subs available
<nckx>vldn: Have you tried removing /var/guix/substitute/cache/*?
<nckx>And which wine derivation (.drv) does Guix start to build?
<vagrantc>nckx: i presume you ran make dist on guix system?
<nckx>Yes.
<jlicht>upgrading the apt-installed version of the guix-daemon seems to be entirely undocumented right now; If I'm not mistaken, it involves running guix pull as root, and manually patching the apt-installed guix-daemon systemd service definition
<jlicht>yuck
<nckx>I don't think we support distro packages upstream.
<nckx>guix-install.sh is the official method.
<jlicht>A 'solution' is to have more releases, I guess
<singpolyma>jlicht: I just don't update the daemon
<nckx>We could add a section with all the apts & yums & zyps without much further elaboration. Or maybe the cookbook is better? Dunno.
<singpolyma>I expect I'll get r new version of it with the next Debian release
<nckx>That's almost always safe, but sometimes a <https://git.savannah.gnu.org/cgit/guix.git/commit/etc/news.scm?id=df830ef91a1ea6255b1174520a22122134978d36> happens.
<nckx>Although if it were serious, CVE-serious, I'd expect distros to take action.
<jlicht>nckx: I wasn't implying that we need to document an actual solution/workaround, but perhaps redundantly stating that unsupported installation methods are unsupported might already be enough
<nckx>Hehe.
<nckx>Good point.
<vldn>Yes @ nckx
<vldn>Maybe try guix Shell wine
<vldn>Does it pull the sub For you?
<nckx>vagrantc: I can try writing a CI job that does that, but I'm currently working on fixing the pinebook-pro image.
<nckx>Despite never having seen a Pinebook.
<nckx>So that'll go well.
<vldn>Wine64 and wine needs to be build, wine-minimal ist subbed Like expected
<nckx>vldn: I want to know the exact derivation your Guix is building, so we know if there is a substitute or not.
<nckx>The final /gnu/store/*-wine-6.20 is fine too.
<vldn>The Hash of the wine*drv?
<nckx>Here, ‘guix build -d wine’ returns /gnu/store/lmg6skfk853zjchwjnpkg506b5ig22c7-wine-6.20.drv, and when I remove the -d, guix starts to download a substitute.
<nckx>Yes.
<vldn22>0w0834q3fvdf671xz8dxw7svn29jv6bb-wine-6.20.drv
<vldn22>lpz51mz4q3dz85gpgl94x62sd3x9jili-wine64-6.20.drv too
<nckx>See, berlin doesn't have either of those…
<vldn22>guix weather wine claims that they are available
<nckx>How are you building them?
<podiki[m]>for what is worth, Ihave same drv as nckx (haven't done a pull today)
<nckx>vldn22: Could you share the full build *and* weather command *and* output?
<nckx>AFAICT berlin has the latest wine package, bordeaux doesn't.
<nckx>I'm on a1846e9b9135fe18f2418b983334f4cb7eb3df8b.
<vldn22>i'm on 3a08655d59d857a2aeb03d4215df659e19ee4cff
*nckx pulls to that.
<vldn22>i cancel the build because of qtbase
<vldn22>its taking too long
<nckx>Right, my request for full build output was a bit silly. But do share both commands & the output of the weather one.
<nckx>And the contents of /gnu/store/0w0834q3fvdf671xz8dxw7svn29jv6bb-wine-6.20.drv if you please :)
<vldn22> http://ix.io/3Lre
<vldn22>here the guix weather
<vldn22> http://ix.io/3Lrf here the drv
<vldn22>guix package -m packages.scm
<vldn22>maybe i could pass a version to the package definition to get a sub from a older version?
<nckx>There simply is no substitute on berlin nor on bayfront/bordeaux for /gnu/store/9w22yaxbp0assj4ixvdqix9yqxgd59y3-wine-6.20
<vldn22>so not possible to get another one that is avaiable ?
<nckx>Which exact guix weather command are you running, and which exact command is building wine?
<nckx>I don't see that in the pastes.
<vldn22>that package -m command is for building the wine
<vldn22>but guix shell or guix install wine gives the same output
<vldn22>and simple guix weather wine
<nckx>I'll see which wine derivation I get after pulling to 3a0865.
<Kolev>I hope this works. https://paste.debian.net/1226349
<podiki[m]>wine is perhaps tricky with the i686 parts needed? I notice a difference between guix build or guix shell with things like that, but maybe that is just me and whatever I was doing
<vldn22>yeah guix build ist strangly working
<vldn22>and then the guix package -m command not recognized the built wine
<podiki[m]>when I tried just now (different guix commit), guix build wine will start downloading a sub, but shell will try building something
<sophrosyne>What's a good way to export environment variables in a guix.scm for nix shell?
<vagrantc>jlicht: the guix-daemon stuff is briefly documented in README.Debian in the guix debian package
<nckx>‘guix shell’ builds /gnu/store/0w0834q3fvdf671xz8dxw7svn29jv6bb-wine-6.20.drv; ‘guix build’ builds /gnu/store/lmg6skfk853zjchwjnpkg506b5ig22c7-wine-6.20.drv
<vagrantc>jlicht: in general, there isn't much need to upgrade the daemon, and anything that would need a newer daemon can backport patches
<vagrantc>jlicht: or, as you figured out, override the distro-shipped service.
<vldn22>guix build wine  gives for me /gnu/store/2fjvjvs9ww6r2nn0rscs7ascxasvj5zn-wine-6.20  that package directory
<vldn22>with substitutes
<vldn22>guix install or package -m  gives another one
<vldn22>without subs
<nckx>‘guix package -m’ builds the same as ‘guix shell’: 0w0…
<nckx>(That's the hash, but also my face.)
<vldn22>true
<nckx>Wine is weird, as podiki[m] says, but I don't immediately see *obvious* weirdness in wine.scm that would lead to this…
<podiki[m]>my only guess is something about the cross-arch parts...but no idea in what way
<vldn22>maybe i can blacklist something?
<vldn22>the 32bit parts with wine64
<nckx> https://paste.debian.net/plainh/bb1a1e28 eh.
<vldn22>wine-staging needs building too sadly :(
<nckx>I am stumped.
<nckx>‘guix weather’ is telling the truth, ‘guix build’ proves it, then ‘guix shell’ and ‘guix package’ build a different wine. Cross-sorcery is almost certainly involved but I don't *see* it 😳
<nckx>I also can't think of a quick hack to install wine on vldn22's machine without building it.
<vldn22>just using the one from guix build? :D
<vldn22>that's what i wanted to try tommorow :D
<nckx>I don't know if Wine runs (reliably) without installing it into a profile, but it's certainly something you can try.
<vldn22>yeah maybe some env var magic is needed, we'll see
<vldn22>but there is no way to pull a specific path from the ci to the store?
<vldn22>like /gnu/store/2fjvjvs9ww6r2nn0rscs7ascxasvj5zn-wine-6.20
<nckx>Certainly, but I have to think a sec about what it is… (I use ‘guix copy’ but that's cheating 😛)
<cbaines>guix build /gnu/store/2fjvjvs9ww6r2nn0rscs7ascxasvj5zn-wine-6.20
<cbaines>you can use guix build with store paths, as well as packages
<vldn22>aah, seems convenient :D
<podiki[m]>are there any other examples of this different drv between build and shell?
<nckx>vldn22: guix build /gnu/store/2fjvjvs9ww6r2nn0rscs7ascxasvj5zn-wine-6.20 should work.
<nckx>
<nckx>FML.
<vldn22>thanks too :D
<nckx>:)
<Kolev>My little update script that runs whenever I press the big blue button on my ThinkPad is working!
<nckx>Finally, a use.
<nckx>Here, it triggers a full system backup.
<Kolev>nckx: That's a good idea, too. I'd have it do that, if I had a remote backup loc.
<Kolev>nckx: What is a 'full system backup'?
<nckx>bcachefs snapshot → rsync to my home server of everything but /gnu/store (to save server space, because why).
<nckx>It also runs hourly, so I seldom trigger it manually, but it gives a certain peace of mind to do it after writing the latest masterpiece and only takes ~10s :)
<nckx>Peace of mind being a relative term when you're the kind of person to use bcachefs snapshots, but still.
<vldn22>is bcachefs better or more performant then btrfs?
<vagrantc>nckx: whoah. setting LANGUAGE=en seems to solve the en@*quote issues
<vagrantc>when LANG and LC_ALL are not enough
<nckx>Greeat.
<vagrantc>nckx: the other one appears to be a store reference left in a patch to bind ...
<vagrantc>which looks to be a world-rebuild event, pretty much
<vagrantc>er. .. nevermind
<The_tubular>vldn22 probably, but still not ready for prime time just yet ...
<vagrantc>only 3 packages need to be rebuilt. whew.
<nckx>vldn22: It's promising, but it's also in early development. One can't answer questions like that yet.
<vldn22>xfs seems to be quite fast, but no raid and i hate dealing with inodes :D
<nckx>vagrantc: Fixed.
<nckx>That was a stupid of yours truly.
<vagrantc>nckx: thanks!
<vagrantc>we should be able to be stupid and just throw patches at computers and tell it how stupid we were. :)
<vagrantc>er, have it tell us ...
<vagrantc>e.g. we need the checks we have to actually stop us from taking aim at our feet :)
<nckx>Currently, Guix educates its creators much like babies do.
<nckx>You feed it the wrong thing, it throws up on you.
<nckx>I can't wait until it stomps off to its room all moody and slams the door instead.
<vagrantc>hah!
<vagrantc>sometimes it throws up on someone else much later, holding on to the joy
<vagrantc>but yeah, i guess i'm proposing to move towards the moody door slamming phase
<nckx>guix build --log-file
<nckx>YOU‌ KNOW WHAT YOU DID
<nckx>But yeah, we need more hooks & checks & balances.
<nckx>But… somebody needs to write them.
<vagrantc>right... often comes down to that.
<nckx>‘make dist’ does so much less than I assumed it did.
<vagrantc>maybe you're thinking of "make release" ?
<nckx>Exactly.
<nckx>Thanks.
<vagrantc>nobody's tricked me into running that yet, although ... would probably also be good to have some automated checks on it :)
<nergal>greetings! finally i made it here from xmpp!
<singpolyma>nergal: welcome
<nckx>\o nergal.
<vagrantc>hrm. still seem to have issues with parallel build of make dist
<nckx>vagrantc: I've got too much work lined up but if you're interested, gnu/ci.scm declares all CI jobs. It's not geared at quickly adding "make dist" anywhere, though, it's squarely Scheme-API stuff.
<vagrantc>nckx: i'll glanceat it, thanks for the pointer :)
<vagrantc>seems most similar to the binary-tarball jobs
<nergal>hi, singpolyma, nckx \0
<nckx>Enjoy our ramblings over glorious XML.
<nergal>am struggling with cups-configuration in scheme so far
<nergal>tor-service-type already fails
***jonsger1 is now known as jonsger
<nergal>want to see the config?
<nckx>Sure.
<nergal> https://termbin.com/4viv
<nergal>the issue is cups. i am having trouble with location-access-control configuration
<nergal>wish to configure tor-hidden-service for remote management but tor refuses to run even when reset to original line
<jgart>hi guixers, is cuirass ever used to run the linter like this? https://builds.sr.ht/~whereiseveryone/job/666361
<jgart>updated build manifest with `guix lint -x cve`: https://builds.sr.ht/~whereiseveryone/job/666362
<nckx>nergal: Your CUPS location-access-controls were, er, what's polite for ‘all sort of fucked up’? Easy to fix! :) https://paste.debian.net/plainh/9110bacc
*nckx looks at Tor now.
<nckx>nergal: What's logged in /var/log/tor.log?
<nergal>getting
<nergal> https://termbin.com/3msf
<nckx>Thanks.
<nckx>nergal: What's your use case for browse-web-if? (Just curious.)
<nergal>allow printer control from other operators
<nergal>through browser
<nergal>was i misinterpreting?
<nckx>nergal: ‘Is Tor already running?’ Try ‘sudo pkill tor’ or even ‘sudo pkill -9 tor’, then ‘sudo herd enable tor’ and ‘sudo herd restart tor’. There's something off about how Shepherd keeps track of processes, and sometimes… it doesn't?
<nckx>Disappointing answer, I know.
<nckx>nergal: It advertises the Web interface URL over mDNS. It's just never been clear to me which software uses it, and if it works without further configuration.
<nckx>But as said, was just curious, no opinion because no idea.
<nergal>oh, avahi stuff
<nckx>Yep.
<nckx>‘Browse’ really means ‘Advertise’ in this context.
<nckx>Or ‘Broadcast’ etc.
<nckx>It's confusing IMO.
<nckx>nergal: If tor is really positively certainly not running, something else is listening on 9050.
<nckx>But this seems unlikely to me.
<nergal>tor is not running...could not be started
<nergal>checking ss
<nckx>I'm not talking about the herd service.
<nckx>Check whether there is an actual ‘tor’ process running.
<nergal>nothing on 9050 so far
<nckx>And pgrep tor?
<nergal>`pgrep tor` brings up nothing
<nckx>Then try the two sudo herd commands above.
<nckx>It really should start :-/
<nergal>did. it has not started.
<The_tubular>Wireplumber ... Is this worth it ?
<nergal>i could tmate you
<The_tubular>I've read their git, and don't understand exactly what it does
<nergal>The_tubular, it is worth it on the alpine linux install i have so far
<The_tubular>What is it exactly ?
<The_tubular>Scripts for pipewire that does what ?
<nergal>wireplumber is session management so your applications get their allotment of audio resources
<The_tubular>I haven't even tried pipewire yet, maybe I should.
<nergal>wireplumber is session management for pipewire
<The_tubular>Ohh, so you can turn volume down on application basis ?
<nergal>pipewire is the service atop alsa that does what pulseaudio should have done properly
<nergal>so you can rewire audio manual or automagically
<nergal>plug in a 5.1 and not have it reduced to 2 speaker stereo by default
<The_tubular>Ohh, cool!
<nergal>low latency audio response during play time
<nergal>the only hiccup i have experienced so far is bluetooth and that is because i am systemd-free
<nckx>nergal: If it still claims, with new lines in tor.log, that there's someone else listening on that port, I don't think I can help. That has never happened to me.
<nckx>‘Opening Socks listener on 127.0.0.1:9050’ ‘Opened Socks listener connection (ready) on 127.0.0.1:9050’
<nergal>nckx, https://termbin.com/yz85
<nergal>so a race condition?
<nergal>like it is stumbling over remnant sockets then
<nckx>I don't understand the last message (‘remnant sockets’). About the permissions: Guix should create that directory with the permissions Tor expects: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/services/networking.scm#n1009
<nckx>Which means that it should be safe to delete & try again, and if it keeps happening, that's a bug in Guix.
<nergal>weird. the uid# for tor is attributed to lp
<nergal>tor lost control of /var/lib/tor/keys
<nergal>tor lost control of /var/lib/tor
<nergal>tor lost control of /var/lib/tor/*
<nckx>Sadly, UIDs are not persistent (yet?) so it's possible to end up in that situation.
<nckx>The ‘?’ is almost certain; the question is when.
<nckx>Also, how.
<nergal>changed them and tor now runs
<nergal>i have never run as lp user
<nergal>also lp just went into operation today
<nergal>in the past 15 hours
<nergal>since it is not immutable, could it be due to a rollback?
<nergal>i did a rollback once about 5 days ago
<nckx>It could, or (for example) due to commenting out the CUPS or Tor service whilst debugging, or so, so that one of the lp and tor users vanished and reappeared like leapfrogs from hell, who knows.
<nckx>Hard to tell now.
<nergal>that would be a fitting conjecture
<nergal>showing you the generations would be tmi?
<nergal>that is which must not be revealed publicly?
<nckx>This *will* eventually be fixed, but it's a relatively minor annoyance in the scheme of things (unless someone disagrees with a patch that meets approval 😉).
<nckx>nergal: There's nothing confidential about generations, but I'm personally not that interested in finding out exactly what happened now that you've presumably fixed it.
<nergal>oh? sounds like war?
<nckx>I mean, we know the overarching reason.
<nckx>s/with/by submitting/
<lfam>I feel like there was some recent discussion on the mailing lists about this issue with UIDs
<nckx>It's come up before, so probably!
<lfam>If there's not a tracking bug, we should make one. It's annoying enough that we might as well assign it a number
<nckx>Sure.
<lfam>I feel like it's not a problem on Debian, but maybe I'm just lucky
<nckx>I'm behind on mail again, I haven't seen it yet.
<lfam>Do we think that it's a situation that Guix seems to handle worse than other distros
<nckx>lfam: IIRC they use{,d} a central UID registry for system users like this, most distroes d{o,id}.
<nckx>Not sure about tense because IIRC systemd took part of this over.
<nckx>All very vague, yes.
<lfam>Hm... email
<lfam>There's so much of it
<nckx>lfam: Yes, but only because we haven't even tried addressing it so far.
<nckx>Hah, that applies also to e-mail :)
<lfam>Lol
<nckx>I don't think there's anything about Guix that makes it harder to implement a good fix.
<lfam>It sounds like a good project for somebody
<nckx>I'm partial to the central registry myself. Why not make it reproducible across all systems…
<lfam>It's the kind of thing that comes up on IRC and I have to steel myself to explain it
<lfam>The registry... (%standard-UIDs ...)
<nckx>Meh, I don't think it's embarrassing.
<nckx>Just TODO.
<lfam>It's not that it's embarassing. But rather... too hard to explain because this aspect of the system shouldn't require attention
<lfam>From users, that is
<nckx>'greed
<nckx>This is the kind of thing for which you'd use an intern: go look at all distributions and write a report on how they handle this, so we can see if it's good enough for Guix 😉
<nergal>in alpine and most others uid is managed in /etc/passwd and shadow utilities i think
<nckx>I don't think we're talking about the same thing.
*nckx AFK.
<lfam>nergal: So, do you think that your rollback removed the tor-service?
<nergal>it reassigned the uid value
<nergal>instead of tor in the directory, their was a number, presently assigned to lp
<nergal>instead of tor in the directory, there was a number, presently assigned to lp
<nergal>been trying to have tor-hidden-service function
<nergal>it took days to find out that procedure is upper tier
<nergal>thought it belonged under <tor-configuration>
<lfam>I understand that the UID was re-assigned / re-used
***califax- is now known as califax
<lfam>I'm trying to come up with a hypothesis for why that happened
<lfam>So, I'm wondering: when you rolled back, did the old generation that you rolled back to have the tor service?
<nergal>yes
<nergal>it worked on rollback
<lfam>Okay
<lfam>So, after you first added the tor service, you never switched to a generation without tor?
<nergal>yes. i did about 3 generations without tor after.
<nergal>at one point i did that.
<nergal>there was also an attempt to modify-services %base-service
<nergal>i modified tor in that case
<lfam>Ah, so the tor service was created, then removed, and also was modify at some point?
<nergal>i never changed owner though
<nergal>correct
<lfam>Yeah, this is a known issue with Guix
<lfam>We "lose track" of the UIDs if their user is removed
<lfam>We should try to avoid forgetting about them
<lfam>So, if you add a service, remove it, and add it again, then there might be some old files for the service but the service-user has a new UID
<nergal>think in netbsd, uid, once assigned, were not used again. it has been more than a decade since i netbsd though.
<lfam>Yeah, I never had this problem on my other distro (Debian)
<lfam>So we should look at what these other operating systems do and think about copying them :)
<lfam>It might be a little tricky since Guix generations are supposed to be stateless, but we can find a solution
<lfam>Obviously they are already suffering from statefulness
<nergal>how does one establish a tor-hidden-service?
<nergal>oh, it is its own service?
<nergal>then i keep getting "source expression failed to match any pattern"
<podiki[m]>removing a service in general from a system config doesn't remove e.g. the files it created for instance, right?
<vagrantc>Debian has some reserved users/groups that are static, but many of them are still generated dynamically and you might end up with the same issue
<vagrantc>e.g. mismatched uid/gid
<nergal>the files remain
<vagrantc>(although unless you "purge" the packages, the users and groups will stick around)
<nergal>so far, i see no modification to the directory tree
<nergal>oh
<vagrantc>if you consistently "purge" packages on debian (and derived distributions) you'll get the same issue that guix has
<lfam>I see
<nergal>purge an alpine package removes all files that were installed.
*lfam looks around
*nckx ret.
<nergal>think even /etc/passwd and /etc/group are adjusted
<nckx>Mmm, so this problem isn't specific to Guix, it's just that we don't have a ‘lazy’ default between ‘it's there’ and ‘purge the witch’.
<lfam>We try to be stateless by default
<nckx>Ironic.
<lfam>Yep
<vagrantc>that derned functional paradigm strikes again!
<nckx>If only the UID/GID space wasn't so ridiculously small, we could just use a UUID hashed from the name or something. But that will not end well with 1000 pigeonholes.
<lfam>It's a great project for somebody
<nckx>‘Windows got it right.’
<lfam>What does windows do about this kind of thing?
<lfam>I have no idea how windows handles "processes" or "users"
<nckx>Oh, I don't know, I'm sure they screwed up the implementation 5 minutes after starting it, but they do use UUIDs for this stuff.
<nergal>or sid?
<lfam>Ah
<nergal>they use a registry of users in the hive, yes?
<lfam>libuuid is part of util-linux
<lfam>That's my tip
<nergal>universally unique id gen?
<nergal>what does plan9 do?
<lfam>Yes nergal
<nckx>lfam: Thank… you… for… yes… thanks… *backs away*
<lfam>nergal: https://en.wikipedia.org/wiki/Universally_unique_identifier
*nckx likes turtles.
<vagrantc>to really do it functional, you just assign the uid/gid from your config.
<vagrantc>and maybe have some sanity checking
<vagrantc>kind of annoying to have to ... but ... that would solve the issue.
<lfam>Like, have the user write it in there?
<nckx>That's basically what I'm suggesting, but with Guix providing a central registry for any user/groups it uses as part of its services.
<nckx>Yes, it has drawbacks, but I think the advantage outweighs them.
<lfam>It seems really low-level to have it be a required field
<nergal>but look how yggdrasil simply generates an id though!
<vagrantc>for any given revision of guix, it should be possible to make it consistent with itself, at least.
<nckx>Although I haven't thought through all scenarios like removing a service and recycling its numbers, but that should be rare.
<vagrantc>rare, as in, the case that got us into this discussion? :)
<nckx>lfam: ‘First, choose a UID & GID for CUPS… and Tor… and this obscure thing you didn't even choose’ is a lot to ask of users.
<nckx>vagrantc: No.
<nckx>Nothing to do with this, I'm talking at the distro (source) level.
<vagrantc>wasn't it basically install service1, install service2, remove service1, service2 now has the uid/gid of the original generation?
<nergal>i am unclear on how tor-hidden-service works
<nergal>where does one implant it?
<nckx>Probably (services …)? That's where services go.
<lfam>nergal: https://git.sr.ht/~efraim/guix-config/tree/master/3900XT.scm#L94
<lfam>Try using it like that
<nckx>ou may conveniently create
<nckx> ‘<hidden-service>’ records using the ‘tor-hidden-service’
<nckx> procedure described below.
<nckx>So under ‘hidden-services’ in the tor-configuration.
<nergal> https://disroot.org/upload/LqzKyK7wG4P0wIg9/50c3290f-66be-40bd-baa5-db665e5c9a8b.png
<nergal>able to see that pic?
<nergal>let me not be compound
<nergal>/etc/config.scm:35:13: error: (service tor-hidden-service "ssh" (quote ((22 "127.0.0.1:22")))): source expression failed to match any pattern
<nergal>what am i doing wrong?
<nergal> https://termbin.com/gs9q
<lfam>It doesn't work for me either :(
<nckx>nergal: You have a superfluous ‘service’ call before ‘tor-hidden-service’.
<nckx>(tor-hidden-service "ssh" '((22 "127.0.0.1:22")))
<lfam>Ah
<lfam>Indeed
<nergal>nckx, thanks …
<lfam>Old school type of service
<nckx>t-h-s is an old-style ‘constructor’ procedure, not a new-style ‘service typo’.
<nckx>Ooh
<nergal>finally, tor is running!
<nckx>more irony.
<nckx>Glorious days.
<nckx>See, that only took… er… hm.
<lfam>Now you have to add spellchecker-service-typo
<nckx>I would step on vagrantc's turf with that.
<nckx>this-services-service-type
<nergal>took 7 days max, about 75 woke hours
<vagrantc>hah!
<nergal>now i can retreat to my bed and work on the rest of things horizontally; get some 9 year old non-windows-supported printers chained into the network again
<vagrantc>only ~500 lint fixes for synopsis and description left to go ... jump in anytime anyone! :)
<nergal>and finally host peertube and various other services
<nergal>?
<nergal>sypnosis and description of what?
<nckx>Of packages.
<nckx>The stuff e.g. ‘guix show cups’ shows.
*nckx 's working printer turned 19 this year. They grow up so fast.
<vagrantc>guix lint --checker=synopsis,description
<nckx>It is somewhat ridiculous but I can still buy ink so hell.
*vagrantc looks over at the laserjet5 that's still working
<vagrantc>they literally don't make them like they used to
<nckx>Absolutely.
<nergal>the printer industry is a hell show
<nckx>Absolutely II.
<vagrantc>it's a nice orangish-beige, and paper is prone to jamming if you try to use more than one sheet at a time ... but it still works
*vagrantc wonders where the airquote key went
<nergal>i am maintaining a few 4 year old hp laserjet that behave like that
<nckx>Here the machine/firmware freezes if you print a duplex job with a blank page in it, but that's a CUPS/hplip/cups-filter regression because it used to work. And this baby doesn't download exciting new firmware from trusted HP® servers.
<nergal>it was well accepted that the quality of hardware distributed to developing nations far understamp those of developed nations
<nckx>It still has a centronix port, maybe you need to connect that to you router…
<nergal>keep telling them to "beware the cloud" here. cf, university of kyoto 77TB data loss.
<nckx>Yowza.
<nckx>That is a lot of data loss.
<lfam>Sounds like a big relief ;)
<nergal>out of 29PB i read
<nckx>Somewhere, someone spinned that into a ‘you only lost % of data, we don't owe you compensation’.
<nergal>it was miniscule to them
<nckx>I wouldn't want to print it.
<lfam> https://www.iimc.kyoto-u.ac.jp/services/comp/pdf/file_loss_insident_20211228.pdf
<nergal>was originally 100TB of 10 groups. 23TB recovered for 6 groups. 4 groups lose 77TB.
<lfam>Apparent translation: "We believe that this file loss is 100% our responsibility. We will offer compensation for users who have lost files."
<nckx>I stand corrected.
<lfam>I remember this incident now
<lfam> https://news.ycombinator.com/item?id=29734021
<lfam>"The modified shell script was reloaded from the middle."
<lfam>" As a result, the find command containing undefined variables was executed and deleted the files."
<nergal>afk
<nckx>lfam: :)
*lfam tags #53005 as "serious"
<lfam>Locked out o LUKS after core-updates merge ^
<nckx>Oh my god.
<nckx>Impressive investigation from Simon.
<lfam>Yeah
<nckx>Oh
<nckx>I just read their follow-up.
<nckx>The follow-up was missing from issues.guix because…
<nckx>sneek: later tell rekado: The mumi rsync process froze again. It was still clinging to a pointless after 9+ hours. I killed it. An unconditional 1-hour time-out seems in order.
<sneek>Will do.
<nckx>sneek: botsnack
<sneek>:)
<nckx>sneek: later tell rekado: *pointless life, that is.
<sneek>Okay.
<raghavgururajan>Hello Guix!
*raghavgururajan is back to India (bitter-sweet)
<nergal>ret. just had an encounter with nature and had to film it
<nckx>Hi raghavgururajan!
<nergal>thanks very much nckx
<nergal>will give feedback whenever i am able
<vagrantc>when running tests/guix-hash.sh ... ;;; Failed to autoload git-hash-file in (disarchive git-hash): ... where is (disarchive git-hash) supposed to come from?
<vagrantc>the test fails, too
<vagrantc>looks like there's a git-hash.scm in the "disarchive" package.
<Ribby>Hi guys, I am getting the guix tomorrow. What should I expect? The state of the art over the latest?
<vagrantc>hrm. disarchive seems to be a new dependency of guix ...
<vagrantc>Ribby: not sure what you mean exactly :)
<Ribby>I am getting a usb with a GUiX OS inside. Do you have any advice for a newbie such as me?
<nergal>seems tor-hidden-service creates /var/lib/tor/hidden-service as root:root?
<kitty1>Hello! uwu
<Ribby>Yes, hello.
<vagrantc>Ribby: not sure what to recommend, though much of the guix community is problem asleep at the moment :)
<Ribby>No problem, I just started anyways.
<Ribby>g2g, bye
***breavyn_ is now known as breavyn
<bricewge>Hello Guix!
<asdf-uiop>Hello bricewge !
<asdf-uiop>There isn't a way to search for binary names generated by a package at the moment, right? I searched for 'xdg-open' and found only 'snap' and 'go-github-com-skratchdot-open-golang'. Since 'snap' requires 'xdg-tools', it was pretty easy to figure out where to find 'xdg-open', but it proably isn't always that easy to guess. Couldn't 'build' collect the outputs of a derivation as metadata for 'search'?
<bricewge>ambrevar work on such a feature 2 years ago https://web.archive.org/web/20210415053334/https://ambrevar.xyz/guix-nlnet2020/index.html
<bricewge>There are some threads on the ML about it
<asdf-uiop>Thanks, I'll have a look
<abrenon>hello, guix
<AwesomeAdam54321>hello abrenon
<AwesomeAdam54321>Is there a way to turn off the locale hint on the Guix package manager? My $GUIX_LOCPATH was already added from /etc/profile.d/guix.sh
<abrenon>I see no package for independant (LaTeX) beamer themes, all seem already included in the various packages that install beamer
<abrenon>are there any recommendations to packages beamer themes separately ? (or good reasons for not doing so ?)
<AwesomeAdam54321>s/added/set
<abrenon>AwesomeAdam54321: what "locale hint" ?
<AwesomeAdam54321>abrenon: I installed the Guix package manager on a foreign distro
<PotentialUser-97>Is there a way to have guix environment/shell also provide the unpacked source archive? or any way to easily get the source for a package?
<bricewge>AwesomeAdam54321: The hints goes away when you have the environment variables set correctly
<abrenon>PotentialUser-97: guix build -K keeps the source while building the package
<ennoausberlin>Hi. I wonder what are the steps to apply patches locally on my guix system which are posted on issues,guix.gnu.org
<bricewge>PotentialUser-97: `guix build -S hello`
<PotentialUser-97>Thanks!
<jpoiret>AwesomeAdam54321: if i'm not mistaken, the guix daemon also needs to have access to the locpath
<bricewge>ennoausberlin: It is explain in the manual https://guix.gnu.org/manual/devel/en/guix.html#Building-from-Git
<jpoiret>ennoausberlin: there is no `guix pull` option to do that (yet). I've been meaning to add it but haven't had the time to
<jpoiret>but yes, you'll need a local checkout as bricewge said
<jpoiret>it'd be great to have a guix pull option for that, as people would test new patchsets more easily I reckon
<jpoiret>or even a `guix pull --with-patchset=NNNNvX` which would fetch the mbox from mimu
<jpoiret>i think Xinglu's `guix review` script does something similar
<bricewge>ennoausberlin: Basiclaly `git clone`, `./bootstrap`, `./configure`, `make` and then you can use the built binary with`./pre-inst-env guix`. But you'll need to adjust these commands with options explained in the manual
<ennoausberlin>bricewge So I checkout the git then apply the patch then compile it. The last step would be to run guix system reconfigure with the freshly build guix binary. Is this correct?
<bricewge>jpoiret: That would be a great feature!
<jpoiret>ennoausberlin: yes, don't forget to use `./pre-inst-env guix` instead of `guix`
<jacereda>Also, if you use emacs, read the "Applying email patches in Emacs" from https://ane.iki.fi/emacs/patches.html
<bricewge>jacereda: There is also piem, which integrate public-inbox with variaous emacs modes https://docs.kyleam.com/piem/Applying-patches-contained-in-a-message.html
<ennoausberlin>jpoiret Thank you for clarification. I have to do it more often to get used to it, but I love to start tinkering more deeply with guix.
<ennoausberlin>jacereda I do use emacs. I will have a look. Thank you all
<jpoiret>bricewge: ohhhh, notmuch integration looks interesting!
<ennoausberlin>Probably the patch for gremlin on aarch64 is faster applied to master by the maintainers, but I want to learn these things anyway :)
<jacereda>bricewge: nice, I'll try that
<tex_milan>Hello Guix! I am trying to package ocamlfuse. It needs camlidl, it gets it in its inputs, but compilation fails as it can't find camlidl headers. The headers are in output of camlidl package. Any idea what to try?
<jacereda>no guix package for piem?
<bricewge>No package for it (yet?), I personally don't use Guix to manage emacs packages
<jpoiret>me neither, been planning on switching to guix home + guix emacs packages soon
<jacereda>hmmm, looks like it isn't on melpa
<abrenon>tex_milan: hmmm not really, I've had similar issues in the past and never really understood why
<abrenon>I don't see why it should be in the propagated-inputs if it's a regular compilation, but have you tried that ? (I don't expect it to work, but in case it does, that would be some additional information)
<jacereda> https://inbox.kyleam.com/piem/87bl11lptp.fsf@kyleam.com/
<jpoiret>caml is compiled, it shouldn't need propagated inputs
<tex_milan>jpoiret: no difference
<jpoiret>jacereda: tbh I think software devs are the most qualified people to actually package their own code, but welp
<jacereda>jpoiret: I think they should package at least for one distribution, others will follow and can get hints from the original package. And in the case of emacs packages, I think publishing on *elpa is a must
<jpoiret>yes, that's also what I think! Given that the dev is a Guix user, I think packaging it for Guix would be the best "official" packaging method, but I may be biased
<jacereda> https://git.kyleam.com/piem/tree/.guix.scm
<jpoiret>ohhhh, that's why then :)
<AwesomeAdam54321>It turns out I needed to install glibc-locales
<AwesomeAdam54321>my problem is fixed now
<sash-kan>hi all! which package contains `rpcgen` program? is there an analogue of `libc-dev-bin` that contains `/usr/bin/rpcgen`? https://packages.debian.org/bullseye/amd64/libc-dev-bin/filelist
<bricewge>sash-kan: It's in rpcsvc-proto, I have just ran "rg rpcgen" in the guix repository
<sash-kan>bricewge: what is `rg`?
<bricewge>A `grep` on steroid https://github.com/BurntSushi/ripgrep
<sash-kan>bricewge: thanks!
<sash-kan>p.s. it is very difficult to search for files without something like apt-file.
<mfg>Why isn't autoconf in the environemnt created with `guix shell --pure -D guile'? guile is using the gnu-build-system, so i would expect autotools to be present, right?
<bricewge>sash-kan: Yes, it is known; I just had the same conversation with asdf-uiop 2 hours ago here
<bricewge>mfg: Because the package is using a tarball which contains additional artifact than the git repository
<mfg>ah i see, i'll have to add the missing bits manually then :) thx
<bricewge>It's the case with many packages, it's kind of annoying. And it's frown upon to update packages to use a git repository if it already use a tarball (there are some discussion in the ML about that).
<asdf-uiop>Have there been any thoughts about 'guix pull' options to only update a certain channel? I have tried to create a file with only my local channel, but it requires the 'guix' channel. My next try at a workaround will be copying the current commit from 'guix describe' and pinning it to that. An option to do this natively with 'guix pull' would really ease the process of creating and linting packages for newbies like me who hav
<asdf-uiop>again and again.
<mfg>bricewge: thx for the info :)
<asdf-uiop>Or does the amount of calculation not change when you keep the current guix commit instead of updating it?
<fproverbio>hello guix
<asdf-uiop>hello fproverbio
<rekado_>asdf-uiop: if this is just to add packages for your personal use I’d go with GUIX_PACKAGE_PATH for convenience
<sneek>Welcome back rekado_, you have 2 messages!
<sneek>rekado_, nckx says: The mumi rsync process froze again. It was still clinging to a pointless after 9+ hours. I killed it. An unconditional 1-hour time-out seems in order.
<sneek>rekado_, nckx says: *pointless life, that is.
<rekado_>GUIX_PACKAGE_PATH should point to the root directory of your modules
<rekado_>Guix will consider these modules for all commands
<asdf-uiop>rekado: thank you!
<rekado_>this is great for quickly iterating, but less great for reproducibility
<rekado_>if you intend to publish your packages or share with others it’s still better to use the channel mechanism
<rekado_>but for purely local stuff GUIX_PACKAGE_PATH is faster
<gnoo>hello, while using guix shell --check, i get the following warning: guix shell: warning: variable 'PKG_CONFIG_PATH' is missing from shell environment
<gnoo>it suggests to look at ~/.bashrc and ~/.bash_profile but i haven't changed PKG_CONFIG_PATH in them
<gnoo>my ~/.bashrc is jut 4 lines, one sets PS1, one aliases `ls', one checks if it is interactive and the last one sources ~/.alias
<sash-kan>share your experience: how to search in mail archives? using google / bing / yandex / duckduckgo / some-local-search-engine / etc (grep is nice, of course, but not very smart).
<gnoo>sash-kan: the search feature in mail-archive?
<asdf-uiop>Ok. I planned on contributing them, but I'll still have a look at GUIX_PACKAGE_PATH.
<bricewge>sash-kan: I don't have a good workflow to interact with MLs, so I'm mostly using https://yhetil.org/guix/
<gnoo>i use gmane to see what's trendy
<sash-kan>gnoo: "search feature in mail-archive", in my opinion, does not understand context and no ranking.
<gnoo>i just hope the main few words are in subjects :P although i don't have much experience in MLs
<sash-kan>bricewge: does this engine understand that "make", "build" and "compile" are roughly synonyms?
<bricewge>Nah, it seems pretty dumb, but at least it will search all messages and has a ok UI
<jacereda>Could we have https://debbugs.gnu.org/cgi/bugreport.cgi?bug=48702 applied? That would allow adding emacs-piem.
<tex_milan>How to package program written in rust? do we really need to specify all dependencies in its Cargo.lock again in guix package definition?
<lilyp>tex_milan: not quite, but you need enough #:cargo-inputs to make it work
<gnoo>tex_milan: use guix import crate
<tex_milan>gnoo: thanks!
<florhizome[m]>How can I run a build from a locally defined package that already has a substitute in my store again?
<asdf-uiop>I finished packaging Screamer (https://nikodemus.github.io/screamer). (require 'screamer) works fine when I run it inside a shell generated by 'guix shell rlwrap sbcl sbcl-screamer', but I have no idea how to access it in my regular system.
<asdf-uiop>(a common lisp system)
<vldn>tried guix build --no-substitutes @ florizome?
<florhizome[m]>yes
<florhizome[m]>It seems to only matter for definitions fetched from channels
<vldn>then maybe guix gc -D the substitute @florizome?
<florhizome[m]>thx, I‘ll have a look at that
<vldn>np hope it helps :)@florizome
<viivien>Hello guix! I’m trying to use jekyll. Everything works well, but the "jekyll new" command doesn’t work.
<viivien>More specifically, it tries to execute ruby and this fails.
<viivien>If I run in a guix shell with jekyll and ruby, I get another error.
<viivien>It reads: Bundler: Errno::EROFS: Read-only file system @ rb_sysopen - /gnu/store/zgwawxsky1js7z0i8prmp2p8ybl0yj2k-ruby-3.0.2/lib/ruby/gems/3.0.0/bundler.lock
<viivien>(that’s a specific line that I think is the cause)
<viivien>The lock file does not exist, would it help if it were installed? Can a process lock a lock file in a read-only file system?
<gnoo>can i blacklist a package so it won't be installed? for testing purposes ;)
<singpolyma>gnoo: it won't be installed unless you ask for it...?
<gnoo>it'll be installed as dependency
<bricewge>florhizome: I think you are looking for --check https://guix.gnu.org/manual/devel/en/guix.html#build_002dcheck
<opunix>hey ... i would like to create a custom channel for some personal packages ... but for whatever reasons every time I define a package inside the channel it breaks the guix pull command
<singpolyma>viivien: sounds like a bug in the package. Either the lockfile needs to be included or more of the bundler usage patched out
<vldn>test
<vldn>okay working
<viivien>gnoo, dependencies of installed packages aren’t installed in general. Which one is itQ
<viivien>?
<gnoo>no i mean not in my profile but in the whole system
<bricewge>viivien: Non you can't create a lock file in RO filesystem. It's probably a bug in jekyll packaging, you should probably open an issue or try fixing it
<gnoo>even if it is a dependency, i want to ignore that package
<gnoo>(or a list of packages)
<gnoo>i just want to see how broken stuff gets
<viivien>It’s not about creating the lock file, the question is wether we can lock it if it exists
<viivien>gnoo, then you can inherit the package and rewrite its inputs
<gnoo>but that will only work for a few packages, right? i want to ignore a popular package and rewriting inputs of alot of packages seems hard work :')
<bricewge>I still don't fully understand thunked records. `operating-service-user-services` is a thunked field, can I use `(operating-system-kernel this-operating-system)` in a service record for example?
<singpolyma>gnoo: if you remove an input, presumably the packages will mostly fail to build.
<gnoo>i'm not building anything, i want the equivalent of 'apt remove -f foo' 'pacman -dd -R foo' but for the whole system
<gnoo>xbps-remove -ff foo
<mfg>does the guiz system vm --image-size option take arguments in the form of 8G? or which unit does it use?
<singpolyma>gnoo: inputs only affect build time
<singpolyma>I think what you want is not possible with guix, it's against the while design
<gnoo>oh, ok (as you can tell, i'm very new at guix and guile and scheme and don't really know what to say)
<singpolyma>A package does not have dependencies at install/runtime as you might think if them
<singpolyma>It simply does reference some content which may come from other packages
<singpolyma>So the only way to remove that reference would be to build a version that does not contain it
<gnoo>how is a runtime dependency defined in guix?
<singpolyma>They aren't
<singpolyma>That's what I'm saying
<singpolyma>Packages may reference other packages, but there is not "runtime dependency" metadata
<gnoo>singpolyma: thanks, i read native-inputs and inputs in guix manual and it's a little more clear. i guess there is no way to say 'this package needs foo for running but not for compiling'. and to blacklist a package, i will probably need to make a new package and graft it?
<gnoo>(sadly i don't know how to do those, yet, i'll try again next time after learning scheme)
<sash-kan>and which package contains `asn1_compile` program? `git grep asn1_compile` didn't help: there is one mention of heimdall, but this package, as far as i can see, does not contain `asn1_compile`.
<mfg>well, accoridng to ubuntus packages it is part of heimdall, but heimdall kerberos5 not heimdall the flashing tool
<mfg>in guix heimdall is the name of the flashing tool
<mfg>not sure how kerberos is called though :D
<mfg>sash-kan: it's heimdal with one l
<mfg>nvm, it isn't
<mfg>i can't find the correct package either :(
<sash-kan>mfg: alas, `heimdal` also does not contain `asn1_compile`, as far as i can see.
<mfg>yes, it should though, i guess it's the package missing some configure options
<mfg> https://github.com/heimdal/heimdal/search?q=asn1_compile
<mfg>the heck
<mfg>sash-kan: it's in heimdal, but at libexec/heimdal/asn1_compile
<mfg>so i guess not in PATH
<sash-kan>mfg: thanks! really is. i used `$ find $GUIX_ENVIRONMENT -name asn1\*`, but it doesn't follow symlinks.
<AwesomeAdam54321>Does 'guix pull' download the latest package definitions; if so where are they stored?
<gnoo>~/.cache/guix/checkouts/
<AwesomeAdam54321>gnoo: thanks
<florhizome[m]><singpolyma> "Packages may reference other..." <- well you have propagated inputs which will put the bin directory into path and activate the needed search–paths for the respective package, right?
<jpoiret>gnoo, AwesomeAdam54321: ~/.cache/guix/checkouts/ is only used as a cache directory for git checkouts, nothing more.
<jpoiret>package definitions are part of the guix source code, which on `guix pull` is first downloaded to that cache directory, and then built in the store and added to a new guix profile, then symlinked to ~/.config/guix/current/
<jpoiret>basically, when you `guix pull`, you build the latest available guix source code, and make it your default `guix` profile
<jpoiret>if you want to consult a package definition, you can simply use `guix edit PACKAGE-NAME` which will fire up your $EDITOR with the relevant source file
<jpoiret>(and you'll notice that the source file is in the store, hence read-only)
<gnoo>jpoiret: thanks, i wrongly assumed ~/.cache stores the current definition which will be evaluated everytime it is needed
<AwesomeAdam54321>I'm enjoying using the Guix package manager so far
<AwesomeAdam54321>jpoiret: Thanks for telling me
<lilyp>has anyone experimented with the librem notebooks and Guix?
***Xenguy__ is now known as Xenguy
<rekado_>lilyp: I have the Librem 13v2; been using it with Guix System for years.
<pkill9>does anyone use guix with pinebook pro? and is the pinebook pro a good laptop?
<lilyp>i think pinebook has a wip branch
<Kolev>I want to put Guix on a D16.
<unmatched-paren>hello guix, i'm having problems with linking libwayland-client; my code compiles, but when i run it the dynamic linker claims that libwayland-client.so.0 does not exist. i presume this is something to do with guix because i can't find anything on the internet about this
<unmatched-paren>i'm not using meson or cmake, just a custom ./build script (but it does the same thing when i manually run gcc)
<unmatched-paren>hm, when i do the same thing with meson it works... i guess i'll use meson then
<aru>Hi, is guix able to deal with it if I configured my / to be tmpfs?
<rekado_>Kolev: the server board? I think we’ve done just that.
<grokkingStuff>Hi there! Is there a place where I could request for a package to be added to guix? I tried to install calculix but i couldn't and I'm not sure how to install such a complicated package properly.
<grokkingStuff>I could help provide necessary information about the installation, if it would help!
<grokkingStuff>There's a really nice version here - https://cofea.readthedocs.io/en/latest/fea_software/calculix.html
<grokkingStuff>Is there anyone I could msg or email?
<The_tubular>guix substitute: warning: while fetching https://ci.guix.gnu.org/nar/zstd/66b996c0npcqsj5m560q3f5igw85issx-guix-system-tests: server is somewhat slow
*The_tubular panicks
<bricewge>grokkingStuff: You can add that package to the whishlist of packages https://libreplanet.org/wiki/Group:Guix/Wishlist
<grokkingStuff>Looking through it now, thanks!
<The_tubular>Anyone has a emacs package definition that deletes the "play" and "obsolete" category ?
<The_tubular>I have no clue how to write that
<lfam>Does anyone have a copy of the video mentioned here? <https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/posts/gnu-guix-talk-in-rennes-france-november-9th.sxml#n36>
<The_tubular>Is this scheme ...?
<lfam>It's "SXML". So, XML but with S-expressions
<lfam>Therefore, no
<lfam> https://en.wikipedia.org/wiki/SXML
<lfam>I'm looking for this video in response to this email, which expresses confusion about "profiles": <https://lists.gnu.org/archive/html/guix-devel/2022-01/msg00114.html>
<lfam>I mean, this email: <https://lists.gnu.org/archive/html/guix-devel/2022-01/msg00105.html>
<lfam>I've noticed a lot of confusion on this subject here and on the mailing lists
<lfam>It's somewhat suprising, because it always seemed quite clear to me since I got interested in Guix. But I think that part of the problem is that my introduction to Guix was watching an "intro to Guix" video by civodul from that era, maybe 2015 through 2017. Those videos provide the high-level overview of how Guix works that is harder to find in the manual, unless you are going to read the manual straight through
<lfam>I think it's really important to find one of these old intro videos and present it more prominently
<lfam>I think these videos gave a lot of us old-timers an easy and clear introduction to Guix that is lacking for newcomers
<lfam>I'm also searching the FOSDEM archives but it would be great to find that 2015 video
<aru>does anyone have an example of what to put into config.scm if I have lvm on luks? Just to be double sure things will get opened in the right order
<lfam>We should get a nice example and put it in the Cookbook
<sash-kan>lfam: https://video.fosdem.org/2015/ have you been looking here?
<lfam>I am looking at th FOSDEM videos, but the missing video is not from FOSDEM
<lfam>I asked in the #gnunet channel too
<bricewge>Is the talk in guix-maintenance/talks ?
*lfam looks
<lfam>I watched the 2015 FOSDEM talk "The Emacs of Distros" and I don't think it's the right video for this. It's not enough of a "how Guix works" overview. It's also suprising how much has changed since that time... who else remembers `deco`? :)
<lfam>I wonder if anyone else agrees with my assessment of the problem. That is, there are a lot of new Guix users who don't understand the basics of Guix / functional package management
<sash-kan>lfam: https://web.archive.org/web/20160331104813/https://gnunet.org/guix2015video
<lfam>I got involved with Guix after watching a video on those basics, and that knowledge is what attracted me to Guix
<lfam>Wow, thanks sash-kan!
<lfam>I wonder if they did archive the video. Does it play for you sash-kan?
<drakonis>lfam: iirc nix has a similar problem
<lfam>How would you characterize the issue, drakonis?
<lfam>Ah, the archive.org video is loading now!
<lfam>I think that missing video from Rennes in 2015 is in the 'talks/' directory, but the video itself is not included
<bricewge>It's here also https://www.youtube.com/watch?v=30RzNMJI43U
<drakonis>it is often related to how they see it
<lfam>rekado gave a nice presentation at FOSDEM 2017 but unfortunately the video shows his slides as tiny for the first half
<lfam> https://archive.fosdem.org/2017/schedule/event/guixintroduction/
<lfam>I recall some videos with excellent graphical presentations of "the store", "profiles", etc
<drakonis>is it a means of providing access to packages through a third party?
<bricewge>lfam: I don't know if there "a lot" of new user missing the basics. Personally watching all the talk I could in the beginning helped me quite a bit
<drakonis>for most nix users, its not far from the truth
<drakonis>is it a way to share development environments?
<drakonis>its a lot about how they want to use it
<drakonis>i think working on the cookbook would help
<drakonis>the biggest difficulty is with how they envision using it
<drakonis>guix's overarching goals are incredibly laudable
<bricewge>For sure working an the cookbook will help, but it doesn't attract a lot of people. Just look at the copyright header
<lfam>The recent discussion describes that people don't want to contribute to the cookbook or participate in the development process. Which is fine; we need a way to keep those users and eventually some of them will start contributing
<lfam>I think a good video could help them
<drakonis>that's not the problem
<bricewge>lfam: https://archive.fosdem.org/2019/schedule/event/guixinfra/
<Ribby>Hello, I am getting a usb with guix today :)
<Ribby>It appears there is a marketing discussion taking place in the irc.
<bricewge>Is that Ricardo's talk you were talking about, with the orange slurry?
<drakonis>i figure this is already a beaten horse at this point
<lfam>Welcome Ribby
<drakonis>but the biggest barrier is always making sure everyone can use it
<lfam>Yes, we are discussing some issues about "introducing Guix to new users"
<lfam>bricewge: I will watch it and find out
<lfam>I do think that some of the videos I remember are from the 2014-2017 era, which was when I joined Guix
<Ribby>Oh, well, there's a ebay selling usb with guix inside.
<lfam>But, there may be later videos that are even better
<bricewge>lfam: Where did you get that new user don't want to contribute?
<lfam>Ribby: heh, fascinating
<Ribby>I was about to sign up for fsf to get the trisquel, but I heard it was too ubuntu like.
<lfam>bricewge: Perhaps I'm going too far by saying that they "don't want to contribute". But it seems that they spend a lot of time describing the difficulties but don't try to just jump in
<lfam>It's just a different style than what I relate to
<drakonis>the other big gotcha is with getting started
<drakonis>its almost never related to scheme
<Ribby>I suggest a showcase, just like those sampling stalls in those superstores?
<lfam>For example, bricewge: <https://lists.gnu.org/archive/html/guix-devel/2022-01/msg00115.html>
<drakonis>its making sure that getting in is a smooth experience
<lfam>Like I said, it's a different style. We shouldn't pile on them or disagree with them
<lfam>Some people don't feel comfortable just starting
<Ribby>Is that the main problem? I thought it was how to market guix to the public?
<drakonis>the biggest coplaints i've run into is making sure their computers work with it
<drakonis>being able to run it in more places
<lfam>Ribby: There are different problems. I am discussing one of them
<drakonis>ie: embedded devices and hardware that the fsf might frown upon
<lfam>Yeah, I mean, that's basically a nonissue as far as GNU Guix is concerned. In the sense that we can't really address it
<lfam>We already make sure that you can install whatever kernel and firmware you want, and beyond that, we are stuck
<drakonis>yes and they find it unacceptable that it requires extra repositories
<singpolyma>And there are already other projects interesting in that kind of thing
<drakonis>which well, i can't help with
<lfam>It definitely sucks
<drakonis>well beyond my reach
<Ribby>I heard repositories are just for compressed package updates/upgrades. It wouldn't be compiling. I really like the cmake/make compiling program. I can't say about the other compressed package file formats. I can do .zip via GUI. Not sure about the terminal/TUI yet. Not sure about .tar. I think a tar in a tar might be problematic.
<Ribby>I believe that at least communication and feedback would be necessary. A focus study with a sample set of users, is a smart way to go about before marketing.
<Ribby>*focus group
<Ribby>Sorry about mixing up the jargons.
<bricewge>lfam: Interesting thread, I'll keep reading it
<bricewge>Maybe having more entries in https://guix.gnu.org/en/videos/ with selected talks could help new users?
<lfam>The confusion about profiles is really interesting to me bricewge. I guess it's hard for me to relate to because profiles are *why* I was attracted to Guix. It's not clear why you would choose Guix otherwise :)
<civodul>lfam: looking at https://lists.gnu.org/archive/html/guix-devel/2022-01/msg00105.html, i feel there's a lot of lecturing and rambling that make it hard to understand what the concrete problems are and what could be done to fix them
<lfam>Yes, it's true civodul. But overall it's evidence of confusion :)
<lfam>So I am watching old presentation videos now, to find the best one that I can share with people who are confused
<ss2>Would it be a good idea to collect more of those videos at https://guix.gnu.org/en/videos/?
<lfam>That videos page was repurposed a couple years ago. I'm going to watch those videos as well; maybe they are the right place to point people to
<lfam>So far, I think that rekado's FOSDEM talk from 2017 is pretty good. It's high-level. It's not too long, and it doesn't feature too many obsolete implementation details
<ss2>meant *for that page.
<ngz>I think there could be a paragraph about "profiles" in (info "(guix)Managing Software the Guix Way")
<lfam>It's a good idea.
<lfam>Although I don't usually like videos, I think that video is a good medium for this subject, because profiles have generations that you create and switch between, and it happens over time
<lfam>And it's easy to illustrate *what* a profile is graphically
<ngz>As a side note they are described later on, in (info "(guix) Features"), but it may be too late.
<lfam>I see
<ngz>Also, the description there seems inaccurate: "These profiles are stored within each user’s home directory, at ‘$HOME/.guix-profile’.". But profiles can be created anywhere.
<lfam>Well, it's referring to the default profile
<lfam>For package management, that is
<ngz>I agree, but that's not emphasized in the documentation.
<lfam>Well, it is in the packagement management chapter. We could add the word "default" in the right place
<lfam>There's another important point of confusion that I'm noticing often. People don't necessarily understand that Guix captures the entire dependency graph of a package. I see a lot of people trying to fix problems by garbage collecting and rebuilding
<lfam>It's a fundamental misunderstanding
<lfam>People even try to install a package, hoping it will affect the build of some other package
<rekado_>we can (re-)record intro videos and publish them at /videos
<rekado_>if there’s one or two videos that people think are useful but need a few changes that would be a good starting point
<f1refly>what do I have to do to get ntp-service-type? I don't think it says to import a module in the manual, does it?
<lfam>It's provided by (gnu services networking), f1refly. So, you should import that module in your config.scm if you haven't already
<f1refly>Hm, i already do
<f1refly>weird
<f1refly>no wait, i use the package module
<f1refly>aha!
<civodul>lfam: there's also an index entry for "profile" in "Getting Started"
<lfam>Yeah
<lfam>I haven't looked at Getting Started in a while
<lfam>I might just use that
<lfam>That is, I might just use that to help new users get up to speed. It's been a while since I looked at this chapter
<singpolyma>lfam: it's because guix is so fundamentally different from everything else (except nix). People are used to mutating an environment until it happens to work
<lfam>Yeah, it's true
<ngz>I still think "profiles" ought to get a thorough description deeper in the manual
<singpolyma>It's hard to understand that we only have profiles/environments at the edge for convenience. Guix isn't a profile manager, it's not a venv clone
<ngz>I am under the impression there is too much implicit around that concept.
<Ribby>It's just a suggestion, but teaming up with public programs may help.
<Ribby>As an offer, of course.
<Ribby>Note that public programs do require identification and so forth. As far as I know, this website seems to work. https://pcsrefurbished.com/sales/salesHome.aspx
<Kolev>rekado_: Yeah, the server board. I don't have a lot of money, but I want this computer be powerful and to last.
<nckx>nergal: <will give feedback whenever i am able> Thanks!
<nckx>Morning, Guix.
<bricewge>Would it work to define a default for a service field to be `(operating-system-kernel this-operating-system)` since `this-operating-system` is a macro?
<bricewge>I'm currently reviewing the ZFS service patch and having no default `zfs-configuration-kernel` seems unwieldy.
<alMalsamo>So it's pretty much true that ANY AMD GPU will not have 3D rendering with Linux-libre? RadeonHD driver with no blobs is totally dead?
<singpolyma>Yes, no accelerated 3d without firmware
<lfam>Ribby: Can you clarify how you think that web site will help Guix?
<cbaines>Is there something up with the networking to berlin? I'm seeing guix complain about timeouts connecting to ci.guix.gnu.org, and the SSH connection seems very choppy
<cbaines>I tried running a few wget commands, and I've seen output like: Connecting to ci.guix.gnu.org (ci.guix.gnu.org)|141.80.181.40|:443... failed: No route to host.
<nckx>I couldn't SSH in at all ~30min ago.
<nckx>Still can't.
<cbaines>I did manage to connect via SSH and ran htop, and nothing looked unusual
<cbaines>the connection was almost unusable though
<nckx>rekado_: ?
<nckx>Ah, SSH'ing from within Germany worked…
<rekado_>looks like a network error
<rekado_>I see that other servers on the MDC network also do not respond
<nckx>It's not unusable but it's slightly degraded.
<nckx>Thanks for the confirmation!
<rekado_>I got a terribly slow connection to ci.guix.gnu.org just now
<dissent>hey guix, would image.scm be a good place for an icons package?
<rekado_>can’t connect to any of the other public services
<nckx>dissent: Just as a data point, icon themes tend to go in the file for the desktop environment for which they were originally designed. This is vague (and not always possible), I know.
<lfam>My conection to berlin.gnu.org is often unstable from the US
<nckx>Networking is not the strong point.
<lfam>Well, berlin.guix.gnu.org
<lfam>Otherwise it wouldn't work at all
<Kolev>lfam: Is `berlin` actually in Berlin?
<dissent>nckx: thanks.
<lfam>Yes Kolev
<lfam>See here: https://guix.gnu.org/en/donate/
<lfam>Hm, should we adjust the URLs on that page?
<nckx>Kolev: It wouldn't make much sense otherwise now!
<Noisytoot>I have 100% packet loss to ci.guix.gnu.org
<lfam>Yes, we should. Someone else owns guixsd.org now
<Kolev>I'd imagine the owner could easily find some bad expansions of the "SD" part.
<dissent>newaita reborn (https://github.com/cbrnix/Newaita-reborn) wasn't made for any particular DE. perhaps i'll just throw it into gnome.scm
<lfam>dissent: You could make a new module
<lfam>Unless it's somehow intended for GNOME
<rekado_>I can connect to some of the public services again
<rekado_>maybe someone at the DFG pulled the wrong fiber cable somewhere
<nckx>Noisytoot: I have 0% packet loss — until you try anything other than ICMP :)
<nckx>rekado_: Yup.
<lfam>I can ping ci.guix.gnu.org from here
<nckx>(BTW, ping, that's ‘new’!)
<lfam>Do we need a URL for overdrive1?
<lfam>And does bayfront have a web site?
<nckx>lfam: I'd rather not, if we're discussing this.
<mala>a not entirely unrelated question: I've turned off substitution and am offloading my builds to my remote server. But my remote server is erroring out because it's going to find substitutions to build its packages! Is this a bug, or an option I'm not setting?
<lfam>nckx
<nckx>lfam: They just go stale.
<lfam>Okay, I can just rename it "overdrive1" on the website
<rekado_>indeed, ping is new. Maybe someone finally removed that general firewall rule that I complained about a few months back.
<Noisytoot>nckx: I couldn't install packages either. It works fine now, as does ping.
<nckx>Why couldn't you install packages?
<cbaines>I presume because of the ci.guix.gnu.org networking issues
<nckx>Fine.
<The_tubular>How do I delete a folder in guile ?