IRC channel logs
2025-01-14.log
back to list of logs
<apteryx>I'd expect it to just fetch from git, fail otherwise. <apteryx>and it's been processing ever since: SWH vault: requested bundle cooking, waiting for completion...\nSWH vault: Processing... [...] <zeropoint>unmush: I setup a user on the server that only has read-only permissions on my repos and then gave that user the safe.directory=* permission <zeropoint>not sure if there's a better way to handle, but seems to work fine <unmush>also, unrelated, hash mismatch on boost_1.80_0.tar.bz2 <unmush>I mean I can imagine how you created the user, and I guess maybe some weird user-specific skeleton created the git config file, but how did you get git to use that user? <zeropoint>I created a home service to just create the config file using plain-file <zeropoint>and then in my os definition created the user and used guix-home-service-type <graywolf>What package does provide a mail command? I already have opensmtpd installed, but that provides sendmail, and I need something that accepts -s flag. Any ideas? <graywolf>Just wrapper around sendmail would work, but maybe there already is something before I try to write it <iyzsong>graywolf: mailutils provides a 'mail' command, which need setup ~/.mailrc with "set sendmail=/run/setuid-programs/sendmail" <lechner>graywolf / Hi, can we talk for a moment about your channel authentication emails, please? <graywolf>lechner: Sorry bit late for me (past 3 in the morning), really should go to sleep. Just hoped I would be able to finish smartd-service-type I am writing <graywolf>iyzsong: Hm, thanks, the setup part is a problem though. I guess it is a wrapper time. Well, tomorrow will be. <graywolf>lechner: If it does not need to be real-time, feel free to send any questions via email :) If you prefer real-time, later it is <lechner>graywolf / may i write privately, please? i am afraid to embarrass myself <graywolf>And thanks for the link, seems trivial enough. <sleepy2>hey, does anyone know if the AUR guix package is being maintained? last comment on the package says no (2020) and the package hasnt been updated since 2019 <FrenchNewbie>i'm having an issue with guix system, i tried to install it multiple times, re-downloaded the iso but every time i get a frozen screen after the ssh-keygen RSA keys generation <dariqq>civodul: Thanks :), i guess #68366 and #72697 can be closed as well now? <hako>FrenchNewbie: graphics issue i guess, try to boot with "nomodeset"? <PotentialUser-59>Hi Guix users, I have a question regarding guix home. Is it possible to use guix home without overwriting .profile in my home directory? Instead, perhaps I can source a file manually in my .profile file? <hako>hmmmm I misread it, won't be graphics issue if you can enter the installer in the first place. <FrenchNewbie>afaik they always been provided by default on every linux i tried <Rutherther>amd drivers are provided. What isn't provided is the non-free firmware, and the reason is precisely that it's unfree. Guix channel doesn't offer unfree packages <fsmunoz>Hi! For upgrades, I understand that "$ guix pull && guix package -u" is the way to do it for the user packages; when using Guix SD though, is root just a "regular" user? Intuitively I would expect "sudo guix install foo" to install packages "system wide", but this is (if I understood it correctly) done as part of the "system reconfigure ..." process. Any pointers to the documentation explaining this a bit more welco <Rutherther>fsmunoz: sudo guix install foo installs user packages, as root user <Rutherther>fsmunoz: the only system profile available on every guix system is the system profile, configured by your system configuration, and you apply that configuration by guix system reconfigure. So to update system profile, 1. update guix you will use for reconfigure - ie. guix pull, 2. guix system reconfigure with that guix instance you just updated <divya>efraim: Have you removed rust-zip from crates-io module? That breaks a package of mine. <divya>I see you moved it to rust-compression <rovanion>This is the last update I can find in the issue tracker. <rovanion>PotentialUser-51: The latter. But you could always create an email account for the purpose of submitting patches if exposing your current address is an issue. <PotentialUser-51>And, yes. exposing my current emailadress, is samthing I am not confertable doing <efraim>divya: I see rust-zip-2 and rust-zip-0.6 in crates-compression <divya>Yeah, I was finding them in their old crates-io, fixed. <efraim>I keep trying to find crates to group together to move out of crates-io to try to make that module smaller <FrenchNewbie>but why not propose it as opt-in or with a different iso ? <luca>I doubt. FSF's stance has always been to encourage buying free hardware <luca>free software supporting hardware? idk sounds weird <FrenchNewbie>i need the amd firmware for example or else i'm stuck with nomodeset and only 1 screen <futurile>FrenchNewbie: you're aware of the nonguix repository right? <futurile>well consensus seems to be that directly answering a user question by telling them about nonguix is not "promoting" <futurile>second, I personally don't give the FSF the right to censor me <efraim>We don't encourage the use of the nonguix repository, but we acknowledge it's an important channel for many <luca>yeah there's some ways to use guix in not guix supported ways. There's also installing on a forreign distro <FrenchNewbie>isn't it bad for the distro to be so restrictive ? users could be discouraged by lack of choice <luca>nah, it's pretty cool to `guix install` anything and it to be free. Same neat feature in parabola or trisquel <futurile>FrenchNewbie: there's a complex story here, about what you believe is important for encouraging Free Software. The FSF have a set of guidelines that Guix follows - if you're interested in why the policy is like this, that's the place to start <Altadil>FrenchNewbie: it’s always a tradeoff. IMO, the modularity of Guix (with third-party channel) is a good compromise. <FrenchNewbie>luca i agree, but isn't giving the user choice a more confortable ? <luca>that's what nonguix is, no? <FrenchNewbie>i meant as a opt-in box to check in the installer or easier way to find it at least <luca>yeah, guix's third party channel support is insanely good. I've used other package managers which really complicate this <FrenchNewbie>a disclaimer and reminder on the official docs would maybe have a bigger impact than a paragraph on a "random" github page users have too google out <Altadil>FrenchNewbie: it seems vscodium is free, but hard to package for guix upstream. There are strong requirements for packages, not just the license. That’s also a use-case for third-party channels. <janneke>FrenchNewbie: it's really a matter of perspective. isn't it bad that for a distro to just allow you to install a package and later you discover there is no source available and you've been running an opaque binary blob? <janneke>that's what i mean: it's a matter of perspective <janneke>you remark that you didn't know that you're freedom is being protected by guix <janneke>same as when using another distro you'd probably not have known your freedom was compromised <FrenchNewbie>freedom is a matter of choice too, i don't say that guix is wrong by not endorsing it. <FrenchNewbie>and from my pov, you don't really have real freedom nowadays when your only option in hardware are all proprietary <FrenchNewbie>but if you want to still have a relevant setup and be able to do some work you have to compromise a little bit <FrenchNewbie>admitting this flaw and putting a disclaimer about it in the docs would be more educative to the user <janneke>there's no need to compromise or run non-free software at all <FrenchNewbie>so guix forces me to change my computer if the one i have can't run without nonguix ? <FrenchNewbie>and if i decide not to include it i'm stuck without having microcode security updates <FrenchNewbie>or a video card that can only output to one monitor instead of 3 <Altadil>FrenchNewbie: that’s a weird take… Guix does not force anything at all. In fact, nonguix (and all other channels) use the "official" guix extension mechanism (channels). This extensibility is a design goal, meaning the Guix developers made sure you would not be forced to "submit" to them. <ieure>Adding to this, I've run plenty of Linux, and Guix is the most cleanly extensible of any I've used. It's truly a delight how much leverage I have to make it work how I want. <ekaitz>FrenchNewbie: in fact, guix is free software to the root, meaning you can do with it whatever you like. So "forcing" is just against the principles of what we do <ieure>And how those changes never feel hacky in the way they do on other distros. <FrenchNewbie>i may not be educated enough or misunderstood then, that's the understanding i got from janneke answers + the omitting of this piece of information on the official doc <ferocious_iguana>FrenchNewbie: I don't think it's as big of an issue as people think. Anyone can create a new distro building Guix that packages all the necessary things. This is done all over the place in open source world. <efraim>is gnupg-2.4.7 still using librepgp instead of openpgp? <FrenchNewbie>yeah but i hate that we get so many distros nowadays for X reasons when we could just enhance the inital one with a little more user choice <podiki>exactly, you enhance guix with other channels and/or your own code <FrenchNewbie>it all begin in the installer and settings app (if on GUI) from my pov <podiki>well the installer from guix is for guix, as others stated which follows strict free software guidelines. other installers may choose to follow something else <ekaitz>some are privative software (government stuff) <FrenchNewbie>yeah, i meant it as a more general rule than specifically for guix <luca>ekaitz: does cgit work for you as a channel? <luca>all right, I should check it out. Maybe I misconfigured mine badly <ekaitz>luca: if you only have dumb-http mode it doesn't work well <ekaitz>but you can configure a proper http mode if you want <FrenchNewbie>what would be the hardware needed if i wanted to use guix without nonguix ? <unmush>that's usually going to come down to graphics and wifi hardware <ekaitz>luca: using ssh login happened to work, too <unmush>if you can find wifi hardware that's supported by ath9k or b43-open (the -open part is important, there are some out there that are only supported by b43!), that should work <unmush>(ath9k and b43-open are the names of linux kernel modules I believe) <luca>ekaitz: just git@host:path.git ? <ekaitz>luca: that works, but it's git that serves it hehe <ekaitz>i think i need to improve my config hehe <FrenchNewbie>unmush i see that it is about wireless only, what about graphics ? <unmush>graphics hardware is all over the place. older NVIDIA stuff doesn't require firmware loaded at runtime, but generally has poorer userland support (NVIDIA was quite hostile to nouveau IIRC). AMD's GPUs have excellent userland free software support, but require loading proprietary firmware at runtime. Intel's stuff I'm not too sure about. <unmush>in general, your options are usually to either go really old or go nonguix (or go neither and enjoy your 1024x768 single monitor) <unmush>which may be a legitimate option if you're a fan of the terminal and use smallish screens anyway <FrenchNewbie>i intend to use on rather recent hardware so i might be stuck using nonguix <FrenchNewbie>my testing hardware rn is my work pc so i don't have a lot of room to modify it <FrenchNewbie>i'll comeback next week if i have any issues that are non-nonfree related <unmush>IMO the fact that people trying out fully-libre distributions are often shocked at how much of their hardware is unsupported is a great argument for their existence <unmush>after all, they clearly wouldn't have even known otherwise <unmush>but it does mean we end up being the bearer of bad news to many <FrenchNewbie>but the fact that pros endup using those distributions to run their servers but not apply any pressure to be less "controled" is a paradox to me <unmush>aye, hardware seems to be where the rubber meets the road in that regard <PuercoPop>I was updating my channels and found out rust-rowan was removed. The commit message doesn't delve into why. Does anyone know why it was removed? Was it only included as a dependency for another application? <divya>efraim: Did you remove rust-hamcrest2-0.3? <divya>I don't see it in master or rust-team <divya>PuercoPop: No idea why it was removed, efraim rust-nu-test-support-0.88 needed it, which you removed, but its needed for bottom <divya>Now several things of my channel have just stopped working. <PuercoPop>divya: same here. I tried tracking down a couple of things, but gave up once I realized too many things broke and I don't have proper CI on my channel. <divya>PuercoPop: Me neither, last week I saw a few crates were moved around so I was like I'd wait and fix them, now it looks like some have been removed altogether. <PuercoPop>That said, the rust packaging story in guix is currently evolving so I a lot of crates which results in a lot crates being auto-generated only as a dependency. I'm guessing the real 'application' that depended on them no longer needed them to be built? <PuercoPop>As a more meta point, that has already been brought up in the mailing list multiple times. The changelog format is really not very useful. It tells me what I can already see in the diff, that a package was delete. The commit message should focus on the why not what. I hope guix outgrows that GNUism some day. <podiki>a longer comment in the commit is indeed helpful, but that is separate from the changelog format <podiki>i like to include them for just that reason, so perhaps we should make that explicit (as well as linking to issue reports and such, again some do it some don't) <podiki>some parts of changelog make searching for relevant changes so easy though, most random projects i see have terrible commit messages (or like giant changes squashed to a single commit, very hard to parse then) <PuercoPop>podiki: squash and merge is a capitulation. Admitting that you don't care about commit messages or even commits themselves (just the PR). I'd like us to move in the opposite direction. The Changelog format is required so that means it acts a template. It forces people to write the what. Which is the opposite of what they should be writing <podiki>i agree that changelog can be annoying/less than useful sometimes, but other times it is helpful (searching, making sure you are making changes you intend) <PuercoPop>log -G & -S is enough to search for relevant changes. I found the commit that removed rust-hamcrest using git log -G. Having it in the changelog makes not difference to git <podiki>i still think it is helpful often for searching; even if just that searching on our cgit is often faster to get what i want than a search on github (othertimes the opposite though) <podiki>there are pros and cons to all, but we can agree some more comments (above changelog, below summary line) would be helpful often <PuercoPop>I wasn't even aware cgit had a search functionality 😮. GitHub search is mostly used for site-wide searches nor intra repo ones. I would expect the 'happy path' for developers doing intra-repo search to favor local tools <jmes>Am I correct in understanding that I could extend activation-service to basically get a hook into when I run `guix {home,system} reconfigure`? <muradm>could some one help with commiting 75270? <arjan>jmes: yes but I think the activations also run when booting the system <Rutherther>it does run on booting the system, that's how you can boot to different generations <jmes>arjan, Rutherther: Okay great, thanks! That should work just fine. <jmes>Say if the service extends the profile-service as well, will the activation extension gexp have access to the packages listed in the profile extension? <Rutherther>jmes: what do you mean by that? access in what sense? - where do you intend to use the packages? <jmes>Rutherther: Concretely, I want to extend profile with `flatpak` and I want to run `flatpak update` on activation. Will the "flatpak" command be available to the activation service? <Rutherther>jmes: I am not sure, it's always better to refer to full path rather than rely on PATH env var, if that's what you are asking <jmes>Right, I always forget I can use file-append or something in gexps <arjan>because it is a gexp I guess you have access to all packages available in channels, so you could just refer to the path of the command in the flatpak package output <jmes>Thanks for the help guys. My infantile guix brain is developing slowly. <arjan>yes escatly usinf file-append <arjan>nice that it is developing :3 <arjan>it fixes the build of a python program that is currently broken in both master and python-team <nathan-web>Hello. Can anyone tell me if there is an easy way to see exactly what changed between two system generations? Eg, packages, configurations, services? <Rutherther>nathan-web: I am afraid there is no tool that would summarize it nicely. What you could do is run guix gc --references on the respective store paths, and get those to diff. It could show small changes quite nicely, but for example full system updates are going to be messy. For something nicer you could parse out only names of packages and versions, instead of full hashes (just some splitting by "-") <nathan-web>Rutherther: Thanks. Anything for services, or config? I considered diffing something like `/var/guix/profiles/system/configuration.scm`, but unfortunately that doesn't expand, for example `(operating-system <Rutherther>nathan-web: probably would have to somehow diff the graph from system extension-graph. But it's also probably not going to expand well, would need some modifications <unmush>the question of how to "diff" a directed acyclic graph is actually a pretty interesting one <unmush>I suppose you would start by finding what leaves, if any, the graphs have in common, and work your way up? <arjan>nathan-web: maybe a diff on running "tree -l" on the system output paths would give some relevant information <nathan-web>Is guix system configuration declarative or imperative? That is to say, when I run `guix system reconfigure ...` Does it first produce a declarative system definition (imperatively), or does it just built imperatively straight away? <lfam>The Guix model is declarative, as much as possible, nathan-web <lfam>It aims to build everything and then make it effective in a single step <lfam>I think that with the bootloader it gets a little murky but I'm not sure of the details these days <nathan-web>So after running your config.scm there is no intermediate representation of the entire system configuration - it just builds it while running the config? <lfam>I don't think of the config.scm as something that "is run" <lfam>But in any case, Guix creates the new system generation but does not make it effective until the end. This is why it's possible to do `guix system build` or `guix system reconfigure`. In fact, you could look at the difference between these commands in order to understand what Guix does to make the new generation effective <Kolev>Due to historical reasons, the licensing may be ambiguous, but I think it's freebsd. <Kolev>Part of the PDP-10 ITS revival project. <lfam>It doesn't seem to actually have a license, right? <ieure>Kolev, The murky copyright is likely a problem, but you're certainly welcome to run it through `guix style' / `guix lint' and submit a patch. <lfam>Guix needs something that's more explicit, unfortunately <Kolev>lfam: the package builds and runs. What issues does it have? <lfam>It's not freely licensed, right? <Kolev>OK. I'll keep it in my own channel. <lfam>I mean, I'm happy to be wrong. But all there is is an email from one person to another saying they can use it <Kolev>So no upstreaming the package. Got it. <ieure>I think that's less of an issue than it possibly containing other code with unclear copyright status. <ieure>Anyway, I honestly think niche stuff like this is better to keep in a private channel. It's much easier to update stuff when you can just commit/push instead of sending patches. <ieure>I have a handful of things that I keep in my channel because I think very few others are likely to be interested in them. <ieure>Also retrocomputing-oriented. <arjan>nathan-web: I think some intermediate representation is the build output, which you can also directly get by using "guix system build" or find in "guix system list-generations" <ferocious_iguana>What is the state of Plasma Desktop? It's not available during the installation, but the repository contains Plasma 6.1 and the rest of the KDE software suite. <ieure>ferocious_iguana, I've given it a spin, it works alright, but has some minor issues. <ieure>ferocious_iguana, Specifically, it's missing some KDE packages (at least okular), so you have to install those manually; I haven't been able to get Bluetooth to work; logging in is *much* slower; and for some reason, it holds onto old packages versions after a reconfigure updates them. <ieure>ex. I've done `guix home reconfigure', logged out/back in, and launching LibreWolf runs the version from the previous generation. Stale .desktop file cache? Not sure, but something to look out for. <ferocious_iguana>ieure: good to know, both bluetooth and okular are essential to me :) KDE is such a beast and it seems that it takes a lot of effort for distros to provide a good KDE implementation <ieure>ferocious_iguana, It affects everything, just most visible with LW. <ferocious_iguana>OK, I might know the answer for that - you can try and run `update-desktop-database` after `guix home reconfigure` <potatoespotatoes>does anyone know how to compile qemu for a non-host architecture? the instructions on qemu's website is simple, but the guix derivation is much less so <Rutherther>potatoespotatoes: see the --system and --target arguments <potatoespotatoes>I'm trying to do this in a derivation (I have a arm64 package that depends on an x86_64 binary) <sleep_walker>My e-mail to guix-patches@debbugs.gnu.org had been just returned with "Mail Delivery failed". Is it still the right address to send patches? I sent it via fencepost SMTP... <lfam>sleep_walker: The address is <guix-patches@gnu.org> <lfam>Once you have the bug ticket number, then it's $number@debbugs.gnu.org <lfam>I see, thanks for pointing that out. It's a mistake <lfam>It's too bad the "release" version of the online manual isn't updated to fix bugs like this <sleep_walker>Hmmm, I honestly haven't checked the devel version for that. My guix-fu is rusty and memory vague. <lfam>One shouldn't need fu for this. The manual should just fix such typos. That email address never worked <sleep_walker>is there any blocker to keep kodi on 2 years old version or it's just big chunk of work noone took? <Gooberpatrol66>font-abattis-cantarell has a failing dependency that's keeping me from upgrading. does anyone know what pulls it in or how i can figure that out? <mange>"guix refresh --list-dependent font-abattis-cantarell" reports "gnome-essential-extras@44.10 gnome@44.10 mate@1.28.2", but I don't know the path from that to your packages. <mange>Presumably "guix graph" could help, but it takes packages rather than an operating-system, and I don't know how to get a package graph for an operating-system record. <lfam>What dependency is failing Gooberpatrol66? <ieure>I was moderately wondering something similar the other day, I wanted to see if there was some way to inspect the profile created by my operating-system. <lfam>Gooberpatrol66: I can't find that package <lfam>I assume you mean python-pydevd <lfam>Try this command to see the dependency chain: `guix graph --path font-abattis-cantarell python-pydevd` <lfam>Or, at least, to see one of the dependency chains. Of course there could be multiple but this command only displays one of them <Gooberpatrol66>it just shows that cantarell depends on pydevd which i already know <mange>I assumed that Gooberpatrol66 was trying to find out how font-abattis-cantarell was ending up in their operating-system, so try to remove it from their system. <lfam>Gooberpatrol66: Okay. You had asked how to find out "what pulls it in" and this answers that question <lfam>I would grep the Guix codebase for 'font-abattis-cantarell' and poke around, assuming that mange understands your question <lfam>It looks like this font is used by mate and by the GDM login service <mange>It's used in the three packages I mentioned earlier, but searching the Guix source I can see it's also the default font for the gdm-configuration field gnome-shell-assets. <lfam>All the test failures I see for python-pydevd are timeouts <lfam>Some work on python-team to disable some tests in python-pydevd: <lfam>Yes, that's the login manager <lfam>I'm testing if those commits on python-team fix this <mange>If you reconfigure gdm to use a different font then I *think* you will avoid it, too.