IRC channel logs


back to list of logs

<nckhexen>Resume of all things.
<nckhexen>Hetzner tried to ask me for an ID scan, but I've never heard of that.
<nckhexen>lechner: Are you happy with Linode as a mail host?
<lechner>yes, because it runs Guix!
<Andronikos>Interesting. Thanks for the responses.
<lechner>i am for some reason blacklisted with UCEPROTECTL3 (out of eighty or so registries) but no one seems to give a hoot
<nckhexen>Andronikos: Thing is, asking here is going to bias towards people running their mail server on Guix, which is going to bias strongly away from people using EZ-mail software suites.
<nckhexen>lechner: I think that's par for the course. So'm I.
<lechner>nckhexen: that's funny!
<Andronikos>nckhexen: I asked on other channels as well but most time the answer is basically it is a lost war.
<lechner>Andronikos: i actually still read my email on Gmail, but I can't wait to get off
<nckhexen>And that ‘80’ number means we have one free blacklist monitor in common.
<lechner>nckhexen: :)
<nckhexen>Andronikos: People are free to claim that. Those people seem to be so damn *loud* about it though. Wonder what that's about.
<Andronikos>Except Linode do you know other providers that support Guix?
<jonsger>lechner: what size does your VPS has?
<Andronikos>nckhexen: Well I kinda had the same experience myself doing it some years ago. Sometimes you are getting banned instantly and some websites don't even allow having other domains instead of the big ones. But this email was used for everything. I guess if I use it for GNU and other open source stuff it will not be a big issue.
<nckhexen>> some websites don't even allow having other domains
<nckhexen>makes me think we live in entirely disjunct cultures. I've never even *heard* of that, let alone encountered it.
<lechner>Andronikos: I also have one on Letbox but they do not support IPv6 out of the box, so I have to serve my own reverse zone, which they delegate to me after ICANN approval
<Andronikos>lechner: Not supporting IPv6 is weird. I thought IPv6 is cheaper?
<lechner>jonsger: I think it's called nano. It's the smallest with 1G of RAM. Make sure to take a look at my pending (and bitrotting) docs patch, though
<Andronikos>nckhexen: Well it is like the so called decentralized internet is no more. There are some banks that do not allow online banking with Firefox, only Chrome.
<whereiseveryone>which banks are those?
<lechner>Andronikos: beats me. i wondered about that too. i think some of those discount providers you can find on LowEndBox run installations on old Proxmox instances
<Andronikos>whereiseveryone: I don't know it anymore but it was on Reddit under r/firefox. It is not only banks but general there are some huge websites like apple (developer) for example that do not support Firefox anymore.
<nckhexen>Andronikos: All true, but I have never, ever heard of sites restricting e-mail addresses to a fixed list of freemail addresses…
<lechner>nckhexen: i have heard that too, but cannot remember where or whether it survived
<Andronikos>nckhexen: Well that email part that only supports huge companies are some random sites. My point was just that this ridiculous web devs exist.
<nckhexen>‘Huge companies’ = freemail, though. Nobody's work, school, etc. address is going to work. Good luck running any kind of business that way.
<lechner>nckhexen: Maybe I have to correct myself. In April, Gmail started to require SPF records on originating domain when receiving emails, which may have required upgrades for some smaller providers
<nckhexen>Oh, that's good.
<nckhexen>Yay Gmail for once.
<nckhexen>Andronikos: I have been trying to think of a VPS provider that supports Guix ever since you asked, but came up dry.
<nckhexen>Note that running Guix doesn't require support, though. Once you're comfortable installing Guix you can do so from any ‘rescue’ system or Debian ISO provided by almost every provider out there, and the Guix you get is just as fresh.
<Andronikos>nckhexen: You mentioned some days ago that the berlin server uses BTRFS. Could you elobarate why since I just know a little bit of ZFS and those two FS are kinda competitors AFAIK?
<lechner>you are stepping into a trench fight
<nckhexen>Btrfs is simpler to set up, built into Linux, and does everything we need it to.
<nckhexen>I'm not even sure the Guix ZFS service ever got merged?
<lechner>ZFS supporters call it the last word on file systems, or something like that, but it's not totally free i think
<nckhexen>Well, that's just a good-natured wink at the name, to be taken in a spirit of very mild playful competition, nothing more, IMO.
<lechner>it never occurred to me!
<nckhexen>It's complicated. It's totally free, but not GPL-compatible. And then there's a minority view that omg it actually totally is compatible, you guys, come with me to the basement and bring some red string! which further complicates matters.
<nckhexen>It *is* an excellent file system, and compare the features it had and *when* it had them to anything else. It's impressive.
<nckhexen>We just don't need ZFS, we've all used btrfs a lot more, and it works. Sorry if that answer is disappointing.
*nckhexen is certainly no btrfs fanboy. Trust me.
<Andronikos>Well it tells me that BTRFS is usable. I head that it was not prod ready but Fedora uses as default FS now, too. So I guess it would fit as NAS FS as good as ZFS?
<Andronikos>But I guess this depends more of what I need as of one is superior to another.
<nckhexen>Pff. I'm not going to answer ‘as good’. IMO, if your NAS has supported ZFS‌ integration and is designed to work well with it, and especially if you want to do anything beyond a very basic (RAID) layout, use ZFS.
<nckhexen>Btrfs is as good in a subset of things ZFS does, and it took a very long time to get there, and it lost a lot of trust during that time. It still can't do many things. And now I'll stop, lechner was right about popping my head above the trench :)
<Andronikos>Currently I do not have any NAS. I thought about using TrueNAS since it is defacto standard but if I can use Guix I want to use Guix.
<lechner>Andronikos: any old box with a network card will do. it's just about power consumption
<Andronikos>nckhexen: Also could it be that you are german or at least live in germany?
<nckhexen>I get that precise question puzzlingly often.
<lechner>he wants to be german
<lechner>sorry, they
<nckhexen>Do have an odour of the germanic about me?
<lechner>you love berlin, for one
<lechner>like nckhexen, I also like Btrfs. I really admire what they are doing but I did have some (very) poor experiences with their early RAID implementation
<lechner>Andronikos: i am actually the German here
<Andronikos>You mentioned Hetzner earlier which is german and you said something about doing a hw reset on the berlin server so I thought there could be chance. I am german that speaks for my curiosity :)
<nckhexen>I just realised that might just have been because of my nick.
<nckhexen>(The nick is temporary, for spookyween; I'm nckx.)
<lechner>i think it is your tireless dedication to the cause. it's your virtue
<nckhexen>Andronikos: All just coincidences, I'm afraid, but not big ones: I do live quite close to Germany.
*nckhexen forgot about the kittens…
<Andronikos>lechner: Thats a plot twist.
<lechner>we love our hall of mirrors
<Andronikos>Well at least I was right that someone else is german here :D
<lechner>Andronikos: i though you were greek
<Andronikos>cuz of my name?
<lechner>is it your name?
<nckhexen>Berlin is in Berlin because Ricardo, eminent Guixer, works at the <>, and has somehow (I suspect blackmail and possibly worse) convinced them to donate *and* host a ridiculous amount of powerful hardware.
<Andronikos>Nope but Andronikos is a greek name.
<nckhexen>I also thought you were Greek. :(
<nckhexen>And people (when they don't call me German) also think I'm Greek because of my TLD, so I thought we hand a bond there.
<lechner>wow, my heart is bleeding
<lechner>nckhexen: thanks for clarifying your greek connection, btw
<nckhexen>Which does not exist. But you're welcome.
<Andronikos>nckhexen: That is the reason for Berlin. I wondered since normally those things would be hosted at Frankfurt.
<lechner>Andronikos: is that where you are?
<nckhexen>Heh. We might have less network mysteries if it were so…
<Andronikos>lechner: Nope I am near Stuttgart. You?
<Andronikos>Ah I know. Bayern right?
<Andronikos>Ah no that was someone else. It is getting late.
<lechner>Andronikos: Fremont, Calif. Welcome to the mirrors
<lechner>But as a kid a spent a lot of time on the Schwaebische Alb
<Andronikos>What you mean with mirrors? Don't get it.
<lechner>My name is super common in Bavaria though
<lechner>Andronikos: Please do not worry. I am just playing with you. I was born in Berlin and moved to the US for college. Then I got stuck here
<Andronikos>Is it hot in California or just warm?
<lechner>Andronikos: We are drifting a bit off topic and will probably earn a flame in a few minutes, but it's about 22 degrees year round where I am. Not much of a season, for better or worse. Let's stick to Guix or the other folks will lose whatever goodwill they have left for us
<Andronikos>lechner: Sounds nice. Thought about living in California that is why I am asking. Is that with the flame the case since I want to know. On GNU Emacs it is just normal to talk about random stuff so I assumed here as well.
<lechner>sneek: later tell Andronikos: There is also an off topic channel, I think, but people have tolerated much more banter here. Everything is cool & Cali is great
<sneek>Got it.
<lechner>sneek: later tell Andronikos: The Guix devs read the back logs later, and our conversation makes it harder for them to catch up with real bugs
<sneek>Will do.
<nckhexen>sneek: later tell Andronikos: That said: flaming: absolutely not. If someone flames you for talking about the weather, they are out of line, not you.
<nckhexen>sneek: So much work today. Botsnack.
<nckhexen>Good night, Guix.
<bdju>qutebrowser has started crashing my entire sway session upon start. anyone else run into this?
<bdju>I found how to open it without restoring my browser session and I've avoided a crash now
<flatwhatson>hrrm, just got bitten by #$source referring to the parent package definition's source
<flatwhatson>i expected a build phase referencing #$source to work in a package definition inheriting it, but it was grabbing files from the parent definition's sources!
<flatwhatson>very spooky when you're trying to build --with-git-url or --with-branch
<n8henrie>I'm primarily a (neo)vim user and have never used emacs, not once, and am a first-timer with guix and scheme as well. Trying to format my first Guix System config file after reading -- successfully ran `guix package -i emacs-guix` but I can't find `indent-code.el` anywhere. Do I need to install emacs separately from `emacs-guix`?
<n8henrie>And if so, is there a third package required to get `indent-code.el`?
<nanami>You can use `guix style` now
<n8henrie>@nanami wow cool! `guix style -f guix.scm` worked great. Thanks!
<lechner>n8henrie: in emacs, you can also select all (C-x h) and then hit Tab. It works best when you copy the dir-locals.el from the Guix code base. (I think it's okay to select "!" when prompted for the first time.)
<lechner>I have been told to use that for patches
<n8henrie>@lechner -- see my original Q -- I'm still getting emacs command not found after `guix package -i emacs-guix` -- Do I need to install emacs separately? If so, is `guix package -i emacs-guix` just a linter then?
<n8henrie>Also, I'm surprised not to see any vim-ale linters that mention guix / guile / scheme -- is there a linter / formatter for vim users?
<Korven[m]>Okay does anyone know why Guix deletes packages even in an active generation?
<Korven[m]>Because if I do a `guix gc --collect-garbage`, and then do a `guix home reconfigure`, it starts downloading alll the packages
<Korven[m]>which is not what's supposed to happen right?
<Korven[m]>For more info, I'm using guix on a foreign distro (PopOS), and using guix home for my user config management
<unmatched-paren>Korven[m]: after GC it does download a bunch of things, but only those necessary to perform the downloads
<unmatched-paren>like curl, git, subversion...
<unmatched-paren>basically just guix's dependencies.
<Lumine>Good morning #guix
<Lumine>(early bird)
<cnx>it's afternoon here but it wok up the same time yesterday so (-;
<cnx>btw does shepherd have user services
<Korven[m]>unmatched-paren: nope it's downloading everything for me
<Korven[m]>rust, web browser, gtk stuff
<Korven[m]>kitty (my terminal)
<unmatched-paren>cnx: There's Guix Home, which provides user services
<Korven[m]>did i mess something up DX
<unmatched-paren>hmm, actually, it is doing the same for me
<unmatched-paren>that's odd.
<Korven[m]>hmm, indeed it is
<cnx>thanks (
<Lumine>Was going to say that it's normal behaviour but this is guix home, so I'm not so sure. If you just run gc by itself it will basically delete everything up to the current generation.
<Korven[m]>maybe gc doesn't take home generations into account
<Korven[m]>for some reason
<unmatched-paren>Korven[m]: Ah, it's to do with grafts, I think
<unmatched-paren>to build a graft, you need to download the ungrafted version
<unmatched-paren>and you can't substitute a graft
<Lumine>Oh I get it
<Korven[m]>it may be expected, but i don't think is should be the intended outcome
<unmatched-paren>it could be fixed by making grafts substitutable
<Korven[m]>+ i did not figure out how to work around it from the emails, did you? XD
<unmatched-paren>you can't work around it
<unmatched-paren>there are a lot of grafts on master
<Korven[m]>we just live with this?
<unmatched-paren>yes, sadly
<unmatched-paren>until core-updates is merged or grafts are made substitutable
<Korven[m]>time to get off of guix home then-
<unmatched-paren>noooo D:
<Lumine>No, don't leave home!
<unmatched-paren>come back! :)
<Korven[m]>but the rebuilds D:
<unmatched-paren>they're not rebuilds :)
<unmatched-paren>they're substitutes
<Korven[m]>okay, but they still kinda inconvenient
<Korven[m]>esp since I have pretty bad speeds for some of those downloads XD
<cnx>is there a service for xkb options?
<unmatched-paren>cnx: there's a system service, i think
<Korven[m]>Btw, unmatched-paren do you use Guix System or a foreign distro as well?
<unmatched-paren>Korven[m]: I use Guix System
<cnx>thanks (, or should i call you (;
<Lumine>I learned recently that I can now get all my pressure levels on my drawing tablet on Linux, it isn't normalized to 2048 levels which make it stiff as heck. So I ditched a certain unnamed system for good, so I'm on Guix and one other Linux system full time now. :)
<Korven[m]>:) that's nice
<Lumine>Aye, feels nice
<Korven[m]>let's hope I can do that too someday XD
<lilyp>you can do everything with enough wine :)
<Lumine>Well I don't even need Wine as of now. :P
<lilyp>Not even for Genshin Impact? 😜️
<Lumine>Oh hell no
<Lumine>(my name is not a reference for a certain character in Genshin)
<lilyp>color me surprised
<Lumine>It's an abbreviation of my pen name, my calling name is Lumi
<Korven[m]>damn I knew Lumi once
<Korven[m]>she played way too much genshin
<Korven[m]>lilyp: It's not even a wine thing tbf
<Korven[m]>Does anyone know if the tensorflow package has CUDA support?
<Lumine>It seems to have the option turned off by default, checking on tensorflow's configuration.
<lilyp>we don't have a cuda package anyway
<Korven[m]>D: muh tensor calculations
<raghavgururajan>Missed a line in the commit message.
<raghavgururajan>The latest commit won't have the gnu: ... line.
<unmatched-paren>Korven[m]: well, cuda is nonfree, so...
<Korven[m]>my apologies
<lilyp>it would be nice if tensorflow could make use of opencv or something
<Korven[m]>Or if Nvidia opens CUDA up
<Korven[m]>that'd be nice too
<Korven[m]>doubtful,but can dream
<Korven[m]>Anyways, does anyone know where the Guix modules are stored? I'd like to add them to the guile load path so that the guile repl can pick it up (within Emacs)
<raghavgururajan>Did nckx change their nick to nckhexen?
<raghavgururajan>sneek, later tell nckhexen: Thanks for your message. I've recovered and back to 100%. :-)
<sneek>Got it.
<lilyp>Korven[m]: I think you might want to spawn a geiser shell for `guix repl'
<lilyp>but just so you know
<lilyp>~/.config/guix/current is a guix profile
<Korven[m]>I seem to think it's in `.config/guix/current/share/...`
<Korven[m]>Here, there seems to be all the modules for the channels I have
<Korven[m]>not everything apparently
<Korven[m]>so back to square 1
<daviid>tensorflow has a C api, used by aiscm iirc, which works on cpu [or gpu if ...] so, you should be able to use tensorflow even from guile, not sure how much aiscm has of tensorflow, but certainly a good start ...
<daviid>and aiscm is in guix, no?
<daviid>Korven[m]: ^^
<Korven[m]>Well, I can't just tell my professor and teammates we're chucking our existing code out the window in favor of Guile
<Korven[m]>I wish I could, that'd be rad
<Korven[m]>but for personal stuff definitely!
<cnx>ok why does guix system delete-generations *download* stuff
<Korven[m]> that's a new one XD
<lilyp>it's not, you need it to build grub
<lilyp>or more accurately to build the grub configuration
<lilyp>that's why you always delete-generations first and gc after
<lilyp>daviid: aiscm is in guix
<daviid>lilyp: ok, i thought, so those interested may try tensorflow using aiscm and guile...
***maximed is now known as antipode
<cnx>hmmm i think my system and user guix are different, how do i sync them?
<lilyp>cnx: you most often don't; if you run "sudo guix system ..." your user guix will do the job
<lilyp>don't do silly stuff like sudo guix pull or sudo guix package
<cnx>i don't plan to use guix package any way, all i run is reconfigure and it's tiresome having to guix pull for both
<akib`>should i do sudo guix pull before sudo guix reconfigure?
<unmatched-paren>akib`: you should guix pull without sudo
<Korven[m]>don't you need to do sudo -E guix pull to update your guix daemon?
***winter5 is now known as winter
<lilyp>only on foreign distros where guix system does nothing
<lilyp>unmatched-paren: uhm, no?
<Korven[m]>oh okay
<unmatched-paren>lilyp: but wouldn't the ``guix'' used in ``sudo guix ...'' be the user's guix, not root's guix?
<lilyp>well sure, but sudo guix pull still makes no sense on guix system
<nckhexen>Good morning, Guix. Oh look. Confusion. You should not 'sudo guix pull', akib, just 'guix pull'.
<sneek>nckhexen, you have 1 message!
<sneek>nckhexen, raghavgururajan says: Thanks for your message. I've recovered and back to 100%. :-)
<nckhexen>raghavgururajan: \o/
<phodina[m]>Does someone know where to place the following config for Nix daemon?... (full message at <>)
<nanami>should be in system unit, If you are use systemd
<phodina[m]>Well unfortunately no systemd, as I run guix system
<cnx>phodina, you should override the package and add that to preBuild or sth
***jonsger1 is now known as jonsger
<Korven[m]>Does anyone have the medium variant of GNU FreeMono, or any ideas how to make it not look so thin on HiDPI screens?
<Korven[m]>I love the font itself, the regular version just looks so thin
<cnx>no but for fixed width serif i can recommend latin modern mono
<Korven[m]>I tried that, the size of the actual characters in comparison to the `(` seemed a lil small
<Korven[m]>plus I like the font on LaTeX, but didn't really jam with it for coding
<devmsv>so... yesterday I did a guix system delete-generations and guix GC. Now I try to boot laptop and I get a kernel panic :/
***wielaard is now known as mjw
<mothacehe>I ran "herd restart nginx" on Berlin which never completed so I stopped it. Now Shepherd doesn't answer to "herd status" or anything else.
<mothacehe>I guess we are good for a restart
<mothacehe>but "reboot" also hangs as it uses shepherd
<tomterl>I assume this is why appears tp be down? or is it my isp?
<mothacehe>yes that's why
<mothacehe>i restarted the server with a sysrqw
<mothacehe>it should hopefully be back in a few minutes
<tomterl>after `guix install zsh` zsh can't load it's pcre modules; the shells.scm seems to compile with `--enable-pcre`; am i missing something obvious?
<apteryx>perhaps zsh dlopen the pcre library
<apteryx>which hasn't been patched in the zsh guix package definition?
<tomterl>the module is indded not there
<apteryx>not obvious looking at the source, but there's some load_module and co. procedures being defined
<apteryx>mothacehe: it takes about 20 minutes to reboot, so don't sweat it :-)
<lechner>n8henrie: Hi, you want just 'emacs' i think. emacs-guix is an integration package
<lechner>nckhexen: Hi, is your new nick temporary? If so, are you switching IRC tools? To which one, please?
<mothacehe>apteryx: it looks like it was much faster ~ 5 minutes
<mothacehe>maybe the new mount options kicked in?
<peterpolidoro>I am trying to run a Guix GUI package in a container and it fails with an error of not being able to load some gtk icons. Does this mean the package is missing some dependencies that provide the icons?
<peterpolidoro>The error: "Bail out! Gtk:ERROR:gtkiconhelper.c:494:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load /org/gtk/libgtk/icons/16x16/status/image-missing.png: Unrecognized image file format (gdk-pixbuf-error-quark, 3)"
<lechner>Hi, is anyone able to install 'vterm' in Emacs? It does not build locally
<peterpolidoro>yes I run vterm in emacs
<peterpolidoro>with the guix package emacs-vterm
<guile-guest>Hi community, I asked the same question on guile irc but didn't receive answer,
<guile-guest>How to add a guile module to environment using guix package manager? If I do `guix install guile-lzma` package is "installed" but it isn't visible in repl unless I set path to the package guile -L ... -C ...
<lechner>peterpolidoro: thanks!
<lechner>guile-guest: have you tried something like guix shell guile guile-lzma ?
<apteryx>mothacehe: that's great! I didn't expect the new mount options to have an immediate effect (it would if we cleared a lot of files), but I'm happy if it did.
<apteryx>mothacehe, nckhexen efraim tommorow is our monthly meeting, as a reminder :-)
<guile-guest>lechner It works, but why do I need guile package which is available?
<guile-guest>lechner How to install this package on my profile ?
<mothacehe>apteryx: thanks, i will be there :)
<lechner>guile-guest: i would try guix install guile guile-lzma and then update your environment as instructed?
<lechner>guile-guest: you may not need guile in 'guix shell' (unless you use --pure). i just wanted to make sure it works for you
<lechner>guile-guest: your experience with installing packages would get a lot better if you were able to switch to 'guix home'
<apteryx>is someone down for a quick (?) bug hunt? I'd like to fix this ugliness before the release: "fetching CVE database for 2022...[cve]..."
<apteryx>mothacehe: neat! about the pending builds issue, do you know what happened on October 8th? The total count fell from a cliff, eh:
<nckhexen>apteryx: Thanks :)
<nckhexen>mothacehe: That happened to me the other day. Had to hard-reset berlin.
<mothacehe>apteryx: probably a "root" build like gcc for powerpc failed, and all dependant builds were flagged as failed-dependency, but hard to know for sure
<mothacehe>nckhexen: yes i had to use a sysrq :(
<nckhexen>On berlin? We can do that?
<mothacehe>the shepherd issue is reported as #58926
<nckhexen>Thank you!
<nckhexen>I thought it was the same bug Ludo' was hunting down. Plus had my hands full with the CAcert mess.
<mothacehe>echo b > /proc/sysrq-trigger worked
<nckhexen>Oh, OK.
<nckhexen>I couldn't even ^Z the frozen herd or SSH (back) in so that wasn't an option.
<nckhexen>I guess because Shepherd is now responsible for opening sockets instead of sshd?
<mothacehe>yes that would be why
<nckhexen>lechner: Yes, it was temporary, for spookyween, but I don't understand the part about ‘new tools’ at all.
<apteryx>mothacehe: I see! And it resolved by itself when the build was re-triggered?
<nckhexen>IRC? New tools? Sounds illegal.
<mothacehe>apteryx: yes if a build is restarted and becomes successful all the dependants are then flagged from failed-dependecy -> scheduled
<apteryx>GNUtoo: hi! about wipe, I was wondering if it was any different/better than shred from GNU coreutils?
<nckhexen>If this is specifically about powerpc64le, that'll be because there was no hardware building it until a week or so ago.
<lechner>nckhexen: i plan on switching clients and may also need a temporary nick, that's all
<apteryx>mothacehe: just to be clear, failed-dependency builds are included in the "pending builds" ?
<rekado>I built all these GHCs for i686-linux, but … I have no idea how to use them for x86_64.
<rekado>This GHC (/gnu/store/…-ghc-6.12.3/bin/ghc) does not generate code for the build platform
<rekado>am I stuck on i686-linux forever…?
<apteryx>rekado: you mean you can't build it for x86_64-linux natively?
<mothacehe>nope failed-dependency are counted as failed builds (build status >= 1)
<apteryx>mothacehe: OK, I was looking at the page, specifically the "Pending builds" graph.
<GNUtoo>apteryx: wipe is faster as it does only 1 pass by default, and it also report progress by default
<mothacehe>pending builds are builds with -2 status (==scheduled)
<nckhexen>apteryx: They are equivalent. Which also means they are both mostly obsolete, and should come with a big warning, the description as-is makes people think they'll do anything on modern storage.
<apteryx>OK, thanks
<rekado>apteryx: the early GHC versions predate x86_64, so I only got them for i686-linux
<nckhexen>lechner: OK if I PM you about the nick stuff?
<apteryx>rekado: OK! So your bootstrap will have to start on i686-linux and continue on x86_64, right?
<apteryx>does it support being cross-built at some point?
<apteryx>nckhexen: I'll try a docbook Caution tag; is there anything that *does* work reliably on log-based file systems?
<GNUtoo>I use wipe mainly to erase block devices. There is a faster way than wipe that does roughly the same thing but there is no utility for it: you can (ab)use the Linux kernel to write crypto-grade randomness on a block device faster (it's documented in the LUKS manual). So I end up using wipe.
<nckhexen>apteryx: Not just those, but any modern SSD is statistically guaranteed not to ‘overwrite’ anything. And if your threat model is someone bypassing the firmware, which is the threat model of these tools, they become useless.
<minima>hi, should someone want to package what do you reckon the appropriate name would be? 'clojure-http' or 'clojure-clj-http'?
<dgcampea>In the manual, it seems to say that (define-maybe/no-serialization symbol) is the same as (define-configuration/no-serialization test-configuration (mode maybe-symbol "Docstring."))
<dgcampea>is this correct? They seem like different things
<nckhexen>You can ‘wipe’ the whole device but that's still… I dunno. These tools are more about feeling good, frankly, so yeah, that'll make you feel good 🤷
<dgcampea>looks like a copy-paste error from the 'define-configuration' section
<GNUtoo>nckhexen: Indeed, here you can just hope that since what you write is crypto-grade randomness, that you assume that the SSD writes it correctly, and that the data is not just moved in one of the areas that is not visible (these areas do exist)
<GNUtoo>And for an SSD bypassing the firmware is trivially easy
<GNUtoo>It might be a good thing if one day someone writes a free firmware for an SSD
<nckhexen>That would be interesting! I'm not aware of any.
<GNUtoo>With an HDD, work is more complicated as you can't dump the platter data easily
<GNUtoo>For SSDs you just need a chip clip and free software
<GNUtoo>The issue is more making sense of the data, like identifying the scheme used to store the checksums, etc
<GNUtoo>(though HDDs have the exact same issue, it's just that you can't dump the data externally, so you end up having to write code for that, and I didn't look into that stuff but I assume that dumping the data would make writing that code easier in the first place, and here I'm not really interested in data recovery, more into having free firmwares for such devices)
<nckhexen>apteryx: Something built into the file system, so it can target the correct blocks (and consider things like snapshots!). Which means you're at the mercy of the developers (e.g., no such thing on btrfs AFAIK). A workaround would be to set nocow, I guess, but that's not medical advice. As for SSDs (really the same CoW ‘problem’ at a block level), the ‘correct’ way is to use ATA secure erase commands. I won't get into people with tin foil hats
<nckhexen> saying it pings the CIA. You could use wipe + that as a last resort. But if you're *that* paranoid, you shouldn't rely on wipe/shred ‘probably’ working anyway…
<apteryx>nckhexen: the dreaded warning: invalid Texinfo markup
<nckhexen>Argh :)
<GNUtoo>Or wipe the full drive and also encrypt it
<GNUtoo>For ATA secure erase it's the firmware who implements it, so I trust more wipe than ATA secure erase
<nckhexen>Right. That's where we differ.
<GNUtoo>or both to be sure as both work differently: in one case you ask nicely to erase stuff for you, so you trust the firmware, in the other you don't trust anything but hope that by chance stuff are overwritten
<nckhexen>wipe/shred aren't useless, but using them alone is IMO obsolete. They must be combined with something documented to work, and then wipe/shred serve as the tin foil hat :)
<GNUtoo>I use it to wipe USB keys for instance
<GNUtoo>This way someone using my USB key won't be able to copy the data I shared with it before
<GNUtoo>So I'm still at the mercy of firmware attacks but it at least removes part of the problem
<GNUtoo>+ it's a good procedure as it goes both ways: It also makes sure that the data that was potentially put by others is removed
<GNUtoo>And for the use cases, these USB keys are used during install parties
<GNUtoo>so they are passed around and so on
<nckhexen>But you literally told that firmware you don't trust the secret? I don't buy that. That was the mistake. You lost at that moment. The end. Running some tool long after that to ‘erase’ it is just theatre.
<nckhexen>But I'm veering off-topic, sorry.
<apteryx>nckhexen, GNUtoo is this warning stern enough?
<GNUtoo>Ah sorry, I didn't clarify enough
<GNUtoo>If someone at an install party attacks the USB key firmware by reflashing a modified firmware, then I'm not protected at all
<GNUtoo>Though the attack surface would be pretty limited with usbguard
<GNUtoo>Then there is also the threat of the stock firmware not erasing things
<nckhexen>apteryx: Oh! That's more or less exactly what I was hoping you'd write :) Just pointing out that there are some big assumptions nowadays. Not too negative.
<GNUtoo>It doesn't work on ext4?
<apteryx>it's journaled
<apteryx>(log based)
<apteryx>ext3 was too
<abrenon>hey guix
<GNUtoo>log based != journal based
<nckhexen>‘Log structured’ is its own thing though.
<apteryx>ah. then I got that wrong
<GNUtoo>I mean thinkgs like nilfs2 for instance when talking about log based
<GNUtoo>where you have the previous version of the file too
<GNUtoo>It appends new data
<GNUtoo>So if you wipe the file, you still have the old version
<GNUtoo>so AFAIK it should (probabilistically) work on ext4 but not work at all on nilfs2
<nckhexen>It doesn't imply having access to the old data or even remembering where the old data was, but it implies not overwriting the old data until you've written as much as possible elsewhere.
<nckhexen>Log-structured != versioned, although it's often cheap to offer the latter once you have the former.
<nckhexen>I'm going to stop chasing tangents like a derpy dog; sorry.
*apteryx reads
<nckhexen>I think the best *common* modern example would be F2FS.
<GNUtoo>maybe I should modify to "log-structured filesystems"
<GNUtoo>yes indeed
<GNUtoo>I used nilfs2 as an example because the tools enable you to recover the older files
<GNUtoo>So it can even be tested if somebody packages the tools to Guix or use another distro for getting the tools
***nckhexen is now known as jeffbezos
<jeffbezos>…not packaged you say? 🤔
<GNUtoo>guix package -s nilfs # <- For me I didn't find it, so maybe I missed it for some reasons
<GNUtoo>It requires utilities like most filesystems
<GNUtoo>At least for accessing the snapshot
<jeffbezos>I just meant it's the kind of thing I'd package.
<GNUtoo>We also lack other filesystem utilities: reiserfsprogs / reiserfs-utils, reiser4progs, hfsprogs, hfsutils
<GNUtoo>I gathered that list by installing all filesystem utilities and using gparted (view->file system support) to see what was missing
<GNUtoo>Though I don't use these filesystems, so I concentrated more on packaging other things
<GNUtoo>And having the tools is one thing, being able to boot on the filesystem is another, we probably need special support for that too in Guix. We can at least boot on ext4, btfs, f2fs, jfs, xfs
<jeffbezos>GNUtoo: Yes:
<jeffbezos>It's not much work, though.
<GNUtoo>I'd be more interested in being able to boot on loop files for instance
<ae_chep>Is there a good example of a project in development that uses guix?
<ae_chep>(possibly a small one so I can make sense of it)
<GNUtoo>The question here is testing, if what I add isn't maintained automatically and that I don't use it, it's probably not obtimal
<GNUtoo>For things crucial like filesystems it would be important to have some testing somehow
<jeffbezos>Well, that applies to anything.
<GNUtoo>like if people just use them it should work I guess
<jeffbezos>There are file system system (sic) tests, although I don't recall if they cover all file systems.
<GNUtoo>ae_chep: you can use Guix for a lot of things, I use it for automatic testing for instance
<ae_chep>well I have used it to package things but I'm deevloping a project from scratch and want to use guix to setup an environment and get dependencies
<GNUtoo>With Guix I can even cross compile a static version of the tools and use that on the target or even build for big endian and fix the issue we have (we don't support big endian yet in that project)
<GNUtoo>Ah ok, manifest files are probably what you are looking for then
<ae_chep>So, task #1. an environment. I got that setup
<ae_chep>`guix shell` etc. They were easy
<GNUtoo>Bitcoin also (ab)uses Guix environment to be able to build its client in a more trustworthy way
<ae_chep>task #2. I needed the path of a library. I hardcoded the path to the .so file in my source code. When packaging things for guix though we use `substitute*` . I don't know how to make that a part of my dev tooling
<littleme>is it possible to use the libressl to replace all openssl at system? OPNsense have a choice of use LibreSSL to replace whole openssl, so is it possible for guix?
<GNUtoo>Basically they build their stuff normally inside the guix shell. It's probably better to use packages for that though.
<minima>contributor 101 question: there's a 'packages.scm' file where i keep personal package definitions; from time to time i want to create a PR for having those packages merged in guix, if of interest
<minima>what i end up doing is to copy snippets over from my 'packages.scm' to a guix repo checkout
<GNUtoo>ae_chep: Your question #2 is vague: it probably depends in some way on the build system you are using (like autotools, cmake, make, etc)
<ae_chep>GNUtoo: I don't have one at the moment
<minima>how do i retest the package once i've copied and pasted it in the repo?
<GNUtoo>ae_chep: and also *why* you need that path, for instance if it's for ld_preload you might really need it, if not it is usually done automatically
<GNUtoo>ae_chep: how do you build the software then? running the compiler (gcc?) manually?
<jeffbezos>minima: Assuming you've run ./bootstrap && ./configure && friends, just use ./pre-inst-env guix build PACKAGE, et al.
<jeffbezos>From the top level of the Guix Git repository.
<minima>thanks jeffbezos - let me try that
<jeffbezos>You don't even need to commit your changes.
<minima>uh, i lost you
<minima>ah i see, i just create a patch, you mean?
<jeffbezos>No, I meant the opposite. You don't need to ‘git commit’ any edits you make to files.
<jeffbezos>You can just edit, save, test, and loop.
<GNUtoo>You can just edit the files, save them, run make, and test
<minima>hrm, sure, but what if i want to have them merged in guix? like, upstream?
<GNUtoo>I'm not sure if it works if you don't run make
<jeffbezos>It does.
<GNUtoo>oh nice
<jeffbezos>minima: Sure, then you commit. I was answering only the ‘retest’ question.
<GNUtoo>All the utilities work out of the box too? Like guix lint, guix style, etc?
<ae_chep>GNUtoo: Yes, I manually execute things at the moment. I am using a language that has an interpreter and we can imagine that interpreter and some libraries are my dependencies. I can drop into a guix shell and execute my program
<jeffbezos>They should!
<jeffbezos>GNUtoo: ☝
<minima>jeffbezos: oh i see, ok, brilliant, got it then
<GNUtoo>jeffbezos: Nice, thanks a lot
<GNUtoo>ae_chep: ok, that all depends on the language, libraries are usually handled either by the program build system (like a Makefile) or by the language itself transparently
<ae_chep>yes, only thing the tool (the language) cares is that it knows the full path to them
<GNUtoo>ae_chep: Though sometimes you need to mess with it like when you have local libraries or that you want to do fancy stuff like plugins
<ae_chep>it's all very raw at the moment
<jeffbezos>GNUtoo: There are some edge cases, that you won't encounter when ‘just’ packaging, that *require* running ‘make’ again. But Guix should tell you when it detects that. In all other cases, you run ‘make’ to get rid of the ‘warning: file blah.scm is newer than blah.go’ messages that start to pile up after a while.
<jeffbezos>But it's optional.
<GNUtoo>ae_chep: usually there is a way to autodetect the libarry path
<GNUtoo>Many languages use variables like PYTHONPATH, or LD_LIBRARY_PATH, etc
<ae_chep>yes, well we don't have those :)
<ae_chep>not yet at least
<GNUtoo>Ah I see it's a new language then?
<ae_chep>yes yes, new and raw at the moment and I'm learning both it and guix by developing a project using the two
<GNUtoo>The easiest way would be to add something like PYTHONPATH or LD_LIBRARY_PATH
<ae_chep>I remember when packaging other things for guix, we would substitute a `cp` with the value of `which cp`
<GNUtoo>And somehow set these automatically
<GNUtoo>for cp it depends on the use case, cp just work in Guix
<GNUtoo>but 'cp' uses what is in the path, and 'which cp' uses a fixed cp, so only the later is reproducible
<GNUtoo>Packages usually want reproducibility so they substitute cp
<GNUtoo>btw, if you write a compiler one day, it's really important to keep being able to build it with another language than the language it targets
<GNUtoo>It makes sure that people don't need to blindly trust a compiler binary when building the compiler
<ae_chep>Well the language already has a compiler and an interpter in (bqn, cbqn)
<GNUtoo>( )
<GNUtoo>Note that for PYTHONPATH Guix also has special support for it, it uses GUIX_PYTHONPATH instead to avoid conflicts with other distributions when Guix runs on other distributions
<GNUtoo>And somehow Guix manages GUIX_PYTHONPATH
<ae_chep>Oh I remember guix knows how to handle certain paths
<GNUtoo>So when you create a guix shell it will set that up somehow if I recall well
<ae_chep>we'll eventually get a path under which we can place our libraries too but we're not there yet
<GNUtoo>So that leaves 2 options:
<GNUtoo>(1) package things in guix and add suport for the paths of bqn / cbqn
<ae_chep>Until then, if you have ffi calls (and need to point out to an .so file) you need absolute paths
<GNUtoo>(2) set paths locally in the Guix shell
<GNUtoo>And people probably do both somehow because usually you have a combinaison of packages for the dependencies and local stuff for what you work on
<GNUtoo>I've no idea how to mix both in a Guix shell though as I never had the use case, personally I use packages like that instead:
<GNUtoo>It takes the source code in the current directory and packages it
<ae_chep>my BROWSER variable must be broken as it doesn't open
<GNUtoo>Though it only works with guix build, not guix package -i, so you can't install the resulting code but you can run automatic tests on them during build, so for me it's good enough
<ae_chep>hm, a %local-source that you later refer to
<GNUtoo>And here is a library that depends on another (none are packaged in guix):
<tribals>Hi, folks
<ae_chep>Is this preferable to `url-fetch` with a path to current directory?
<jeffbezos>Hiya tribals.
<antipode>ae_chep,GNUtoo: You probably need to substitute with (search-input-file inputs "bin/cp") instead of (which "cp"), for cross-compilation.
<GNUtoo>I've no idea, I just managed to make it work and it was already very hard given all my constraints
<GNUtoo>Here it builds software for Android too for instance, and it needs a more up to date android guix build system than the one in Guix
<GNUtoo>More classical situations are easier than this one
<antipode>(If this is a response to me -- I don't know the context, there are situations where thing slike (which "cp") is appropriate)
<GNUtoo>It was probably a comment on my guix.scm file
<tribals>I broke my remote guix machine. I still able to `ssh` to it, but nothing is available: ls, cd, etc... I suspect there is no proper link from /run/current-system to whatever it need to be. I broke it by executing `guix delete-generations`.
<tribals>When I `ssh` to it, I get error: "-bash: /run/current-system/profile/etc/profile: No such file or directory"
<tribals>Is there a way to recover?
<GNUtoo>(I use (which "python3") there)
<antipode>tribals: What does $PATH say?
<GNUtoo>antipode: thanks
<tribals>antipode: /run/setuid-programs:/home/<user>/.config/guix/current/bin:/home/<user>/.guix-profile/bin
<GNUtoo>ae_chep: ah no it was probably for you
<antipode>tribals: You can try running /run/current-system/profile/bin/, assuming it exists.
<antipode>* bin/ls
<tribals>Amendment: I broke it by executing `guix system delete-generations`
<GNUtoo>anyway thanks a lot for the info
<ae_chep>Okay I need to catch up
<antipode>* /run/current-system/profile/bin/ls
<GNUtoo>ae_chep: it's just that if you substitute something like cp in a script, you need to think about cross compilation too and substitute it with the target cp, not the builder cp
<tribals>antipode: no, there is no `/run/current-system`
<ae_chep>target cp and not builder cp, makes sense. I got it
<GNUtoo>ae_chep: in my case I substitute python3 for running tests, that runs on the builder, so it's fine, but if I needed to package a shell script, I would need to remember to substitute cp by the right one
<antipode>tribals: Can you run 'guix'?
<antipode>I.e., say, "guix --help"?
<GNUtoo>And cross compilation is also super useful as if it works, it can be used to make official images like the pinebook images that are downloadable officially on
<tribals>antipode: no
<ae_chep>No I don't know if I saw `cp` in your files. I remember seeing them about in a bunch of guix packages though
<ae_chep>I know I wrote a few
<antipode>So, does /home/<user>/.guix-profile exist?
<antipode>I mean, "guix system delete-generations" shouldn't delete Guix itself.
<tribals>antipode: Yes, but there is no guix here. Is not it contains only packages installed by means of `guix package -I` and packages from `(operating-system (packages ...) ...)`?
<antipode>I should have said ~/.config/guix/current
<antipode>Also, it does _not_ contain packages from (operating-system (packages ...)), those packages be going into /run/current-system/profile
<tribals>antipode: that's the problem: there is no `.config/guix` as well
<antipode>(user and system profiles are separate)
<tribals>antipode: got it
<antipode>tribals: Do any other files exist in $HOME?
<tribals>Whoa! I'm able to `sudo -i`! And there *is* `guix`!
<tribals>antipode: I didn't produced many files in $HOME yet, but definitely there are some files. But I can't `ls` to prove/disprove that
<tribals>There is no `ls` in root's profile as well. Having only guix, can I restore system?
<midwrx>i found this by google dorking
<antipode>tribals: "guix shell ls -- ls whatever"
<antipode>"sudo guix system reconfigure /wherever/your/configuration/is.scm"
<tribals>guix shell coreutils
<tribals>guix: shell: command not found
<antipode>tribals: You can (ab)use tab-completion to emulate *: echo $HOME/*
<antipode>* tab-completion -> glob expansion
<tribals>antipode: interesting hack ))
<antipode>tribals: I assume you in the past ran "guix pull" for the root user and then never updated it?
<antipode>("guix shell" is 'new')
<tribals>antipode: that may be the case, going to try `guix pull`
<antipode>If you want to do 'ls' first, you can do the older "guix environment --ad-hoc coreutils -- ls'
<antipode>('guix shell ls' was bogus, 'ls' is in coreutils)
<tribals>antipode: tried to `guix system {describe,list-generations}` - neither worked. Will try again after `guix pull` completes
<apteryx>midwrx: o/
***justHaunted is now known as DeliriumTremens_
<dsmith-work>Howdy guixers. I'm considering a change to the bot. It uses a
<dsmith-work>"metaphone" to look up nicks in the "seen" and "tell" tables, and it's very buggy.
<dsmith-work>The change would be to just strip any trailng #\_ or #\' that IRC clients tack on when de-duplicating nicks.
<dsmith-work>The current code:
<dsmith-work>What do ya think?
<civodul`>littleme: you can at least use --with-input=openssl=libressl
***civodul` is now known as civodul
<civodul>so we're going to add a replacement for OpenSSL 3.0 tomorrow, right?
*civodul catches up
<ae_chep>GNUtoo: I am able to build teh package how I want now. Thank you for the references
<lizog>hello guix! zig's 0.10 release is around the corner (with the new self-hosted compiler!), and i've submitted a pr for zig so that we don't need an extra patch file ( to pack it.
<lizog>however, the new version of zig depends on llvm-15, which is unfortunately not available in guix, at the moment.
<lizog>i personally would like to pack llvm-15, but as a guix newbie, also lack knowledge of llvm, it might be too much for me.
<lizog>would like to know if anyone could lead the process, and it might also be benificial to other projects as well.
<csepp>lizog: you might have more luck asking this on guix-devel, there is less guarantee that someone who can help happens to be on IRC.
<csepp>although asking on IRC is not a bad idea either.
<csepp>there is also the new etc/teams.scm file, you could look at that to see which team might be able to help you.
<lizog>csepp: thanks for the suggestion, i'll take a look
***DeliriumTremens_ is now known as justache
<dsmith-work>Survey of nick uniqifier chars. {he}xchat is #\_, erc is #\`. Any others?
<jeffbezos>dsmith-work: Probably better to (also) ask in #libera.
<dsmith-work>jeffbezos: Great idea
<lechner>dsmith-work: Emacs's circe uses #\-
<lechner>didn't see them in #liber
<lechner>actually, they were there. sorry
<guile-guest>lechner thanks for the suggestion `guix home` and help
<lechner>guile-guest: happy to help!
<mirai>Can someone help me with service definition writing? I am getting 'source expression failed to match any pattern in form (define-configuration ...' (
<tribals>I re-created my remote machine as I was not able to recover it. But what I'm not understanding is how I supposed to update guix? Exclusively using `guix system reconfigure`? Or `guix pull` is allowed as well?
<jeffbezos>‘guix system reconfigure‘ only applies changes (which can include updates), but doesn't update by itself. That's indeed ‘guix pull’'s job.
<ae_chep>what does `patch-shebangs` consider as a binary? I have a file with `#!/usr/bin/env foo` at the top that has a `+x` mode, and no change happens to it
<dsmith-work>lechner: Thanks
<jeffbezos>ae_chep: Is ‘foo’ in $PATH?
<ae_chep>it's an input?
<jeffbezos>Could you share the actual package?
<ae_chep>there is nothing in the package to see. `(build-system copy-build-system)` ``(("termbox2" ,termbox2) ("bqn" ,cbqn)))` . ``(#:install-plan (("code.bqn" "bin/myexe")) ...` . And finally `head -n code.bqn` : `#!/usr/bin/env bqn`
<ae_chep>Not "nothing". This is certainly something :)
<unmatched-paren>ae_chep: btw you can use (list cbqn termbox2) instead of `(("termbox2" ,termbox2) ("bqn" ,cbqn))
<minima>hey, while building a local guix checkout (as per, precisely when running 'make'), i get this error:
<minima>any idea what that could be due to? shall i try and build a slightly older commit to see if that helps?
<ae_chep>I needed to alias "cbqn" as "bqn" (as "bqn" is the correct name of the executable produced by package "cbqn")
<unmatched-paren>minima: do ``make clean-go''
<unmatched-paren>ae_chep: that's not quite how inputs work :)
<ae_chep>okay, that's actually true. I aliased it once though and I don't remember why
<ae_chep>in a seperate package
<jeffbezos>ae_chep: Does copy-build-system include patch-shebangs?
*jeffbezos doesn't know…
<ae_chep>It does
<ae_chep>but *ahem* changing the input definitions like unmatched-paren said actually made the shebangs work
<unmatched-paren>ae_chep: ...that's very strange
<minima>unmatched-paren: cool, thanks! i've launched the build again now, hopefully it'll go through this time
<ae_chep>I think I was providing the inptu incorrectly so it wasn't able to find `bqn` in the shebang and not patching it? That's how I took it
<unmatched-paren>changing the label shouldn't change the way the default build phases work
<ae_chep>:/ okay true, `(inputs ...)` does not change it. I'll go back about 10 steps and try to reproduce my inability to patch shebangs because I seem to be able to consistently do it now
<tribals>jeffbezos: okay, I understand that in order to use new package definitions, services and so I need to update guix (usually with `guix pull`). But, after reconfiguring a fresh system, `guix` comes from system as well (`/run/current-system/...`). And there is no .config/guix currently. So, is it safe to do it this way? What happens if I run `guix pull` from regular user right now? (don't want to try it)
<stevenroose>Hello. I just tried to install Guix on a new (Framework) laptop and it ran into a bug that seems to be documented in issues already. The installation process errors and exits. In the issues I found, people suggested trying latest instead of 1.3.0 (that release is over half a year old).
<stevenroose>However, when trying latest, there is a GRUB error. Something with "verification requested but nobody cares", falling back into grub rescue.
<stevenroose>Are there a list of installer images where I can maybe pick one from a month ago randomly that might not be buggy?
<jeffbezos>tribals: Fresh as in you've just installed and never pulled guix? Running ‘guix pull’ isn't mandatory, but strongly recommended, because the system guix is probably very old. You are *expected* to run ‘guix pull’ as your regular user after installing.
<tribals>jeffbezos: okay, thank you
<jeffbezos>stevenroose: From searching, that seems to imply ‘secure’ boot is enabled. Is it? Can you disable it? Guix doesn't support it.
<stevenroose>jeffbezos: Hmm, I manually enable the USB boot image in the secure boot and that worked for the first installer. But OK, let me try disable it entirely. It gets into GRU though.
<jeffbezos>tribals: Just for completeness: it is perfectly normal to have never run ‘guix pull’ as root on a system. I never have. Unless you have good reason to.
<jeffbezos>stevenroose: I don't have a Framework or any UEFI machines, so I'm just going by what I find. It's not something I can reproduce, so can't do more.
<stevenroose>jeffbezos: aha that worked, awesome! Thanks!
<jeffbezos>That was quick! Happy :)
<stevenroose>Btw, sorry for your loss on the name collision ;)
<tribals>jeffbezos: this is what struggled me all the guix way. For example, when I run `guix system reconfigure` as regular user, which guix is used? (I bet it is "my" guix, from regular user profile). What does it affect? Or, when I run `guix deploy` (which I view as equivalent to `guix reconfigure`, but remotely) - again, which guix is used? What does it affect, too?
<jeffbezos>The answer for both is the same, so this applies to both: when you run ‘guix system reconfigure’, your (user) Guix is used. But, because ‘system reconfigure’ needs root privileges to modify your boot loader, it will fail. So you run ‘sudo guix system reconfigure’. Your user's Guix version is *still* used! It's just given root privileges.
<jeffbezos>That's why it's not useful to have a ‘root guix’ in most cases.
<jeffbezos>It will only sow confusion.
<jeffbezos>You don't need to run ‘guix deploy’ as root if you have your SSH keys set up correctly though.
<minima>i got 4 fails when running 'make && make check' in 'master' - i suppose that that's either known already (ofc) or it's due to my local (mis)configuration?
<tribals>jeffbezos: thank again ^_^
<minima>i'm also scratching my head as i'd love to run 'make authenticate' at this stage but that throws 'Error 127' - do i need to be on a guix system for that?
<minima>guix doesn't seem to be available in the 'guix environment guix --pure ...' i'm in?
<jeffbezos>Does it not mention which command isn't found?
<jeffbezos>One failure here so far: FAIL: tests/build-emacs-utils.scm
<minima>jeffbezos: oh yes, it does, '/bin/bash: line 2: guix: command not found'
<minima>weird, tests/build-emacs-utils.scm didn't throw a FAIL here
<minima>mine were store-database, store, and guix-build-branch (4 FAILS total)
<minima>oh wait
<minima>that's marked as SKIP in my checkout
***mark__ is now known as mjw
<efraim>apteryx: I'll try to make it tomorrow, I'll be in Venice at the reproducable-builds meetup
<jeffbezos>minima: Use ‘guix shell guix’ for ‘make authenticate’, but you'll probably need to add some more packages if you want to --pure (untested).
<jeffbezos>I was still on ‘make check’, sorry for any confusion.
<jeffbezos>My FAIL was not using --pure above, but not really, because with --pure it's just SKIPped.
<minima>jeffbezos: hey, thanks! shell (instead of environment) did it! i just had to add make as a dep
<minima>should this be reported in the manual by the way?
<minima>using shell i was able to launch 'make authenticate'
<jeffbezos>Yes, ‘from there on’ does seem to imply it will work inside the previously started ‘guix shell -D guix --pure’:
<jeffbezos>Someone correct me if I missed something.
<jeffbezos>Otherwise, yes, I think a report would be welcome minima.
<minima>jeffbezos: hm... i see, i was looking at '' and that seems to report 'environment' instead of 'shell'
<minima>i'm not sure how the manual versions (mine vs devel) relate to the guix repo - this is probably fine, but happy to file a bug report if not
<jeffbezos>The non-devel manual is ancient. I have a patch to swap 'em but — surprise! — it got bogged down in stuff that should probably have been a separate patch anyway (versioned manuals, so you can visit /1.3.0, /1.4.0, … at will).
<jeffbezos>minima: But my point was, that ‘guix shell -D guix --pure’ will *still* not provide ‘guix’.
<minima>oh i see, multiple levels of glitches ahah
<jeffbezos>The manual thing isn't really a glitch, just a choice that didn't work out in retrospect.
<minima>(and, if i may add a minor consideration, i think i'd have a preference for '--development' over '-D')
<jeffbezos>Sure, me too. That's a matter of taste but you could try your hand at a doc/guix.texi patch and impose your will that way :)
<jeffbezos>It's one of the few perks.
<minima>ok, cool, that's tempting
<jeffbezos>Haha yes it worked.
<minima>but other than the '-D' thing, any of the other things that might be worth a bug request?
<minima>s/request/report ahah
<jeffbezos>To be clear, I meant a bug report to add ‘guix’ to the environment xor add a line above ‘make authenticate’ that exits the previous, guixless, one and spawns one with guix. Not *just* s/-D/--development/.
<jeffbezos>I haven't encountered any ‘make check’ failures here (still running) so can't comment on that.
<minima>i'm rerunning make check now (from within a 'guix shell' env instead of 'guix environment' - although not sure that could make any diff)
<jeffbezos>If both were --pure, it shouldn't®.
<jeffbezos>That said, plenty of host-specific stuff leaks through --pure.
<jeffbezos>Mounts. Kernel. Moonphase.
<minima>indeed - store-database just exploded in front of me
<jeffbezos>PASS: tests/store-database.scm
<jeffbezos>Just shop around until it passes.
<minima>store ditto
<tissevert>hello guix
<tissevert>anyone managing to load pulseaudio modules ?
<jeffbezos>minima: Anything clueful in the corresponding log file? (Just s/.scm/.log/ the test name)
<tissevert>is there anything specific to do for it to work ? (what with the location in the store)
<jeffbezos>minima: Oh, I forgot to say I'm running Guix System. Not that that should be a hard requirement, but obviously any hidden assumptions are more likely to be met.
<tissevert>(on guix system, of course)
<minima>jeffbezos: oh! this is amazing!! yeah i found the culprit, for at least one of the FAILS... unbelievable... i git cloned the repo in another filesystem then migrated to a new computer
<minima>for some reason some of the paths being checked are absolute...
<minima>very weird, but at least we found the cause of the FAIL
<minima>i.e. totally depending on my local setup
<unmatched-paren>minima: i wonder if ./configure sets those paths?
<unmatched-paren>so you'd need to run ./configure again to regenerate them
<minima>unmatched-paren: cool, i think i did it (i.e. configure) earlier - but redoing it now to make sure
<minima>sorry, do i need to --reconfigure or something?
<minima>or just plain './configure'?
<unmatched-paren>just ./configure --localstatedir=/var
***Dynom_ is now known as Guest7164
<jeffbezos>Wonder what happened here:
*jeffbezos restarts it.
<jeffbezos>minima: All tests passed here, so none should be ‘expected’ to fail (that aren't already XFAIL).
<minima>nope still failing (tests/store.scm) - logs say '/home/alice/staging/guix-repo/test-tmp/store/001g29arf93fw61x77413dicaw85nwzb-texlive-hyphen-afrikaans-59745-checkout-builder' not found in store - that's because it should be '/home/bob/...'
<unmatched-paren>that's very odd.
<minima>i totally blame it to my local setup - so i suppose we can just move on - although i'd be curious to know where exactly that bit of info (alice vs bob) is stuck...
<minima>oh maybe i can simply nuke 'test-tmp'?
<unmatched-paren>maybe make clean?
<minima>yeah - it must be that... rerunning make check now
<minima>oh right... 'make clean', sorry
<lispmacs[work]>hi, after the latest update, Gnome terminal keyboard shortcuts have changed, and they seem to be no longer editable
<lispmacs[work]>I'm trying to change "Next Tab" away from "Ctrl-Tab" back to what I had it on, which was "Ctrl-Page_Down
<lispmacs[work]>can't find a setting for this in the global shortcut settings
<minima>all tests pass now - sorry, a make clean did it
<minima>thanks for all the help unmatched-paren jeffbezos
<unmatched-paren>no problem!
<minima>so the loop now is: hack (eg create a new package def), test, fix, repeat?
<minima>super, tx
<unmatched-paren>make check shouldn't be run often, by the way. it tests things like system services and the main guix functionality, which you aren't usually going to touch
<minima>got it, so i'm supposed to run another make command or to limit 'make check' to a specific package?
<jeffbezos>Oh inverydeed. ‘test’ above as in test your package, not run the entire test suite.
<unmatched-paren>no, make check doesn't test any packages
<jeffbezos>minima: Don't run the Guix test suite at all. Just build your package.
<jeffbezos>./pre-inst-env guix build PACKAGE…
<unmatched-paren>just use guix lint, guix build, and guix shell
<unmatched-paren>with pre-inst-env, yes.
<minima>right, build... i see, thanks
<jeffbezos>If your package includes a test/check/… make target, it should be run as part of the build.
<minima>cool, sorry, i've done this few times and not recently, so i'm a bit rusty
<jeffbezos>That's what this place is for.
***winter is now known as ^-^
<minima>and is there any established workflow when it comes to actually using my newly created package in my system?
***^-^ is now known as winter
***winter is now known as winterqt
***winterqt is now known as winter
<unmatched-paren>minima: you may want to make your own channel while you wait for the patches to be merged
<minima>what i've been doing so far is using '--load-path' against a local folder, but that's separate from the checkout and...
<minima>unmatched-paren: oh yeah... if i understand it correctly that involves copying the definitions back and forth between the repo checkout and the local channel?
<unmatched-paren>jeffbezos: were i to write a patchset that adds support for applying arbitrary patches to channels, and adds a procedure for fetching a list of patches using an issue number and optionally a patchset version, do you think it would be accepted?
<unmatched-paren>(you're nckx, right? :))
<unmatched-paren>minima: sadly, yes
<minima>unmatched-paren: excellent, that's fine, thanks - just wanted to make sure i wasn't missing something obvious
<ennoausberlin>Hi guix. After guix pull a new python-build-system is mentioned. Where can I find more information about that?
<unmatched-paren>ennoausberlin: hi! the new build-system is pyproject-build-system. the python-build-system only supports, but pyproject-build-system supports pyproject.toml, pytest, tox, etc.
<unmatched-paren>previously if you wanted to use those you'd need to modify the build phasse
<jeffbezos>No idea who this ‘nckx’ is but they sound cool. I think they'd at least be intrigued by your patch and not dismiss it out of hand. Certainly the first part, unmatched-paren.
<unmatched-paren>jeffbezos: The second part is meant to be used like this: (channel ... (patches (append (debbugs-patchset 12345 #:version 2) (debbugs-patchset 54321))))
<unmatched-paren>i think the patches field would be significantly less useful without (debbugs-patchset ...)
<unmatched-paren>the point here is to make it much easier to use WIP patchsets
<jeffbezos>Okido. FWIW I think it's likely to be accepted in some form, but that's just me.
<unmatched-paren>i mean, i guess someone could just dowwload the patchset and use local-file, but that's wooooork.
<ennoausberlin>unmatched-paren: That would be nice. I created several python packages, but other I left stale, because I could not figure out, how to build it with the existing build system
<jeffbezos>unmatched-paren: As long as the procedure has debbugs in the name, I'm for it. Maybe guix-debbugs-patchset and then I really can't object :)
<jeffbezos>Thanks. This is a very good idea.
<jeffbezos>I mean, it's not a workflow I'd personally use, but it clearly will help others, which is what Jeffrey Bezos is all about.
<two[m]>what is the recommended way to install stack?
<unmatched-paren>two[m]: stack isn't in guix yet
<jeffbezos>What is Stack?
<ae_chep>haskell stack?
<jeffbezos>Haskell Tool Stack?
<ennoausberlin>by the way. Congrats to the working rust build on aarch64. I was missing ripgrep and fd-find for so long
<unmatched-paren>Yeah, it's a haskell package manager
<unmatched-paren>because one isn't enough(tm)
<Korven[m]>from the looks of it neither are two
<jeffbezos>And just in case you thought that at least made it unambiguous:
<jeffbezos>At least call it phackage or something searchable.
***mirai_ is now known as mirai
<mirai>Can someone help me with service definition writing? I am getting 'source expression failed to match any pattern in form (define-configuration ...' (
<unmatched-paren>mirai: loglevel, lualibs, and ssl-port need docstrings
<mirai>unmatched-paren: how should I insert a link in the description?
<unmatched-paren>mirai: use @url
<unmatched-paren>@url{URL, TEXT} or @url{URL}
<mirai>can I put docstring for lualibs as "See @url{}" ?
<mirai>error: account-service-type: unbound variable
<mirai>what module provides this?
<unmatched-paren>try guix system search
<mirai>hmmm... for (service-extension shepherd-root-service-type <...>) I see that some of the existing services use (compose list custom-shepherd-service) and others just use custom-shepherd-service directly
<mirai>what does each of those mean?
<tissevert>who runs pulseaudio in herd ? parent process is one but no service called "sound" or "pulse" or anything resembling shows up in herd status
*jeffbezos doesn't.
<tissevert>s/who/what contraption/
<jeffbezos>It doesn't sound like it's part of upstream Guix? We have no such contraption.
<tissevert>but… I never touched the sound in my guix system
<tissevert>it just worked by itself
<tissevert>and apparently pulse was involved and I suddenly needed to install pavucontrol
<tissevert>I was very enthusiastic about this but since it came with guix and everything just worked, I didn't worry too much
<tissevert>now I need to turn the thing off and I don't even know how ^^
<podiki[m]>I think pulse is just via dbus? or a separate start script it provides (start-pulse-x11 or something?)
<podiki[m]>probably included via destkop-services I would guess
<podiki[m]>(the package)
<tissevert>so it just gets started on demand ?
<tissevert>but then how to cleanly shut it down ?
<tissevert>I 'pactl exit'ed it
<jeffbezos>tissevert: Pulse has been in %desktop-services for 2 years, nothing should have ‘suddenly’ changed…
<tissevert>and by the time I manage to issue a ps faux to confirm death, the corpse was walking again
<tissevert>nothing has
<jeffbezos>I assume it's restarted.
<tissevert>except now I'm getting interested in it
<podiki[m]>yes, via dbus service as I understand it
<podiki[m]>as in requested by something else
<jeffbezos>I mean, it would be pretty bad if your sound server died and just stayed dead until you reboot…
<jeffbezos>(Or invoke some magic that no user will know.)
<tissevert>yes, but on the other hand there must be a way to tell my sound server that I'm most displeased with it and that I want to run it manually for some time
<tissevert>I'm worried of "automagical" stuff
<jeffbezos>Anyway, Guix has never had a PulseAudio Shepherd service. Don't waste time looking for one. You'll never come back.
<tissevert>: )
<podiki[m]>dbus may drive you crazy then
<podiki[m]>(it can for other reasons as well)
<tissevert>which is why I know so little about it : )
<jeffbezos>Maybe you should wait for Pipewire to become just a little better supported. I haven't tried it yet but it seems to please the folks who don't like PA that much.
<jeffbezos>Some absolute madpersons use it even today, or so I've heard.
<tissevert>but… I don't wanna wait, I just want to play with synthetizers, and record some analog instruments too
<tissevert>yeah, I read about pipewire too, but I wouldn't even know how to run it under guix
<jeffbezos>I have a system without PA for that, just with jack. I say ‘have’; haven't booted it in months.
<tissevert>how did you do that ?
<tissevert>I could so live with jack only
<tissevert>hmmm… can it handle hotplugged external USB soundcards ?
<jeffbezos>Uh, I really can't say how I configured it anymore… but since I wasn't interested in smoooth desktop integration (browser sounds etc.), just synth fun, it wasn't hard. Something like the example given in (guix)Sound Services looks like a good start.
<jeffbezos>tissevert: <USB> Don't know, don't have any.
<jeffbezos>I don't do anything remotely that professional :)
<jeffbezos>tissevert: I think I understand your earlier question now. Yes, there is a ‘pulseaudio-service-type’. But not all system services are Shepherd services. They compose the system, but don't ‘run’ like a systemd service would. This one sets up configuration files, nothing more.
<tissevert>ok, now I understand
<tissevert>I had seen the etc-file-something in guix system edit but failed to understand this wasn't running anything
<tissevert>and so… what prevents your system from spawning a pulseaudio process from dbus ?
<tissevert>it's trying all its might but fails because jack has grabbed the sound device ?
<jeffbezos>Yeah, it's a common confusion (and I should have realised sooner it was to blame). Service != daemon != ‘service’ on other distros.
*jeffbezos just got a spam mail from ‘DHL’ with an *ISO* attachment. And it is in fact an ISO (well, UDF) image! Wild.
<tissevert>or there's a way to ask it politely never to start ?
<tissevert>yeah, definitely the confusion I had made
<tissevert>I was still thinking in terms of — not systemd but — runit services
<jeffbezos>I bet there is but it'll be by writing PA-style configuration, in something like the daemon-conf field.
*tissevert suddenly had an epiphany
<tissevert>this is a halloween nick, right ?
<tissevert>'cause its scary and all ?
<tissevert>very good one, I was wondering why you'd done that
<tissevert>also, ISO attachment is probably the worst-ass "trick or treat" ever received
<jeffbezos>Yeah, going to poke around it now. I don't expect anything exciting, probably just a lone EXE in there to bypass some spam superficial filters.
<jeffbezos>spam →.
<jeffbezos>tissevert: Try "autospawn = no" in client-conf.
<jeffbezos>(Documented in pulse-client.conf(5) 🤷 untested.)
<tissevert>thanks !
<jeffbezos>D'oh. ‘# CONFIG_UDF_FS is not set’. That's an anti-climax.
<jeffbezos>p7zip to the rescue: 2022-10-31 17:13:01 ..... 750592 750592 RETEFPAD.EXE
<jeffbezos>Yawn. rm.
<tissevert>bullseye for the long shot
<jeffbezos>Sorry, this was terribly off-topic.
<tissevert>pulse is now down
<jeffbezos>'t Is the season, however, for zombies.
<tissevert>: )
<jeffbezos>Does it stay down?
<tissevert>it does ! (I had no trouble turning it down, the problem I had was seeing it remain in its grave)
<tissevert>ok so now I can at least maybe hope to get a full jack system someday or something
<tissevert>but this is an adventure for another day
<tissevert>thanks for the support and happy halloween ! : D
<jeffbezos>Thanks. You too!
<minima>hey, i'm trying to define a package for clj-http (clojure):
<minima>if i build it, i get this error that says 'Could not locate clj_http/conn_mgr__init.class, clj_http/conn_mgr.clj or clj_http/conn_mgr.cljc on classpath.'
<minima>i assume that's a missing dep, so i thought of adding in java-httpcomponents-httpclient as a propagated input
<minima>but that didn't help
<minima>oh well, scrap that... it's looking for a clj file so it was naive of me thinking that a java dep would solve this
*minima back to debugging
<vivien>Minetest update!
<minima>ok, i was able to make some progress with clj-http, latest iteration:
<minima>the current error is: it can't find 'org.apache.http.impl.nio.conn.PoolingNHttpClientConnectionManager' - which, in turn, i don't seem to be able to find in any existing java package (my criteria for searching being: add a random java dependency and see if that helps)
<minima>'java-httpcomponents-httpcore-nio' was a promising candidate, but won't do unfortunately
<minima>hm, i might need this
***Noisytoot is now known as [