<shcv[m]>one problem with gexp / macros is that they make debugging a bit tricky...
<shcv[m]>when trying to install pypy, it fails when loading the install phase. I think the problem is that the generated pypy-7.3.5-builder file contains `(copy-recursively dist-dir out)` expanded from `(copy-recursively dist-dix #%output)` with `out` as a raw symbol; all other occurrences of out in the file are in string form ("out"). The resulting error is "Unbound variable: out"
<civodul>oh, 408 people here, isn't it a new record?
<ulfvonbelow>as far as I can tell, gdm and sddm both try to access /dev/tty7 read-write, which fails because they're run as the gdm and sddm users, respectively, not root. I have no idea why it ever /would/ work. I assume gdm and sddm are working for everyone else?
<bost>Hi. Is there some proper way how to define and use user's full name and email?
<bost>lilyp: the thing is, user's full name can or needs to be specified on multiple places: for guix system - in the user-account -> comment, for emacs - the user-full-name, for git - in the .gitconfig. I'd like to define it only once (for guix system) and then just refer to this definition somehow
<rekado>ulfvonbelow: I don’t know which of these ttys is used by gdm
<ulfvonbelow>according to ps auxww, the X invocation looks like this:
<Burutsu>Hi, I wrote this font package https://clbin.com/DTwA9 but fc-list does not find the font. What am I doing wrong? The fons seems to be installed on /gnu/store/*-font-scientifica-2.3/share/fonts/truetype. If I copy the files on .local/share/fonts, fc-list detecs them.
<ulfvonbelow>my guess would be that the component of gdm that runs as root puts up the error message
<jpoiret>Burutsu: did you install it to your profile?
<awefawefawef>I'm trying to look at some emacs C functions but emacs doesn't know the source dir (it was a substitute, not build), is the source code downloaded when you don't build? would it be possible to download the source code, & have emacs know where it is without having to build emacs?
<efraim>you can run `guix build emacs --source` and it'll download the source. Not sure about the rest of your question though
<apfel>hi there, does somebody use rust on guix? is there a way to tell cargo to use the local guix version of autocfg? CARGO_REGISTRIES_MY_REGISTRY_INDEX=file://$GUIX_ENVIRONMENT/share/cargo/registry does work for other dependencies but not autocfg for some reason ...
***wielaard is now known as mjw
<VesselWave>Hey everyone! Should I split guix package update and it inherits to separate commit?
<apfel>jpoiret: but, i now use the git packages for development and the guix packages for packaging
<jpoiret>do you remember to use `guix shell rust rust-[whatever dependencies you want]`?
<jpoiret>you need to include the rust in the same guix shell invocation, otherwise the env vars won't be set properly
<awefawefawef>I used `guix build emacs` and it returned an emacs dir in /gnu/store/, but I can't find the source code there? I used `guix build emacs --source` and it returns a .tar.gz which idk what to do with. I want it to get the emacs source code and other code (elisp share, etc.) in the same /gnu/store/ dir (or just let me know where the source code is
<awefawefawef>downloaded to so I can let emacs know... It seems ridiculous to have to extract the source to somewhere then tell emacs then update that whenever I update emacs...
<apfel>jpoiret: i use a manifest file which defines my guix shell environment. But for some reason it did not work. But thanks anyway.
***Dynom_ is now known as Guest4969
<antipode>Nevermind the build failure, pushed a commit building everything antioxidant again
<kajiya_>Hey there everyone! I have an unusual question about chrony. When you do a ``do-release-upgrade`` on ubuntu, there's a pop up during upgrade along the lines of "Modified configuration file. A new version (/usr/share/chrony/chrony.conf) of configuration file (etc/chrony/chrony.conf) is available, but the version installed currently has been locally modified..."
<kajiya_>Is there a config snippet I could drop in ``etc/chrony.d/`` or ``chrony.conf`` that would suppress this pop up? Thanks in advance.
<antipode>kajiya_: It looks like you got the wrong channel, this is #guix, not #ubuntu.
<awefawefawef>lilyp thanks, but that extracts the source code, which I can do just by downloading it from a git repo whenever, I want it to be in the /gnu/store dir, uncompressed, and without requiring local building of emacs, done automatically when updating, etc. guix. I would like this because if it was like that for all programs, then the source code would
<awefawefawef>always be accessible in the same way w/o needing to build, bc there often is no reason to build from source (and stuff like browsers takes forever). this seems like the obvious way package managers should work but idk how to get it to work on arch or guix yet...
<zamfofex>civodul: Is there anything that I could be able to do to help move the situation regarding Hurd substitutes forward? I remember when trying to use Guix on the Hurd at some point (on a VM), packages such as GNOME (among other smaller/simpler ones) couldn’t be built (even though they seem to work fine on Debian). I feel like setting up substitutes would make it easier to find build failures and fix them.
<rekado>zamfofex: we already have a childhurd service, but I’m not sure if we run it the build farm.
<rekado>I see that we only have two servers set up to run a childhurd: "126.96.36.199" "188.8.131.52"
<rekado>that’s defined in the maintenance git repo in hydra/modules/sysadmin/build-machines.scm
<podiki[m]>nope, not receiving messages via matrix bridge :(
<acrow>Looking around I see on one machine /etc/guix with perms 755 and on another machine /etc/guix has 511. What is desired/intended? I don't think I was so foolish as to adjust this... so maybe there are some variations, no?
<apteryx>seems our default meson buildtype is debug
<lilyp>that said, if you do find failures to particular packages, those ought to be easy enough to fix by looking at what debian does (or doesn't if it's also broken there :P)
<mbakke>apteryx: while resolving a polkit merge conflict, I noticed the setuid substitution for polkit-agent-helper-1 was removed in e8f4e1808563eb3c1cd28d419a1f349412af4a0d: is it no longer necessary?
<zamfofex>lilyp: I’d love to be able to help more extensively, but I don’t know what I should do. I wish there was some way to know which packages don’t work so that I could be able to investigate fixing them, but currently there is no way other than trying to build all packages locally, it seems.
<mbakke>apteryx: I re-added it in 884548b476f2ee27c01cb0c9ad93c0cf9d33fa5e since I had tested that version of polkit pretty well after my initial screw-up :-)
<mbakke>let me know if you think it should be otherwise
<podiki[m]>(I think the matrix bridge is fully working again)
<lilyp>zamfofex: you'll have to build the failing packages one way or another :P
<lilyp>but point taken, the bootstrap can be painful
<zamfofex>Yeah. Ideally, I’d be able to look at a list of packages failing to build on ci.guix.gnu.org or some such. Even more ideally, I’d be able to use the Hurd and come across installation failures that I could try to fix!
<lilyp>there should be a hurd vm lying around somewhere, at least for 1.3.0
<zamfofex>I mean, I *was* able to install the Hurd (on a VM as well as on bare metal), though the issue I ran into was that it had no network at all on bare metal, and on the VM, I had to wait nearly infinite time for it to actually build packages from source (and eventually come to fail).
<apteryx>mbakke: hm, that looks more like an omission to me
<apteryx>although perhaps we should adjust our service instead of patching X packages
<zamfofex>I think cross‐built packages are available to it as substitutes, but not native builds, and the native vuilds were frequently failing.
<zamfofex>I wish I could contribute to Guix more actively, but I feel like I’d need assistance figuring out something to work on at my skill level. My current interests regarding Guix include the Hurd, bootstrapping, and also maybe spending some effort figuring out how to bring more npm packages to Guix. (I have revived an npm import script that I found around, and I have been playing around with it.)
<rekado>zamfofex: your interests are perfect for carving out your niche in Guix
<rekado>if I can assist with the build farm I’d be happy to help
<zamfofex>Also note (regarding npm): I feel like most npm packages wouldn’t need a custom build step, so even though popular packages might have hundreds of transitive dependencies, I wouldn’t imagine most of them actually have a custom build step, so they’d just work with an automatic import.
<zamfofex>rekado: Thank you for offering to help! I was once able to offload builds to a childhurd. I wanted to figure out how to make those build outputs available as substitutes.
<rekado>we can add the childhurds as build nodes to the build farm.
<rekado>they would transfer finished builds to the head node, which then serves them via guix publish
<singpolyma>zamfofex: there's a bunch of npm stuff in guixrus too so be sure to check over there. I'd love to see a full importer instead of the helper script I use right now, but I'm not 100% sure how possible it is because there's no standard source format.
<zamfofex>rekado: I was going to say: “I never quite understood Cuirass’ interface nor how it is meant to work, nor do I think I’d need most of its features. I wanted to be able to have a way to enlist outputs to expose as substitutes from the store (or just expose the entire store).” But if you can offer to make substitutes available on ci.guix.gnu.org, that’d be splendid, I feel!
<podiki[m]>mbakke: ah you are right, I got your messages since you're on matrix. Darn.
<rekado>zamfofex: you don’t need cuirass to share substitutes. All you need is “guix publish”, which publishes the contents of /gnu/store.
<zamfofex>singpolyma, davidl: Thanks for showing interest! I can share the script I adapted, if you want. Currently I run it as e.g. ‘guix repl npm-import.scm > lodash.scm’ (though lodash is kinda cheating, having no dependencies). I’m currently waiting for this issue to resolve to continue pursuing this more actively: <https://issues.guix.gnu.org/53414>
<podiki[m]>apteryx: I have tried (successfully) to consolidate almost all messaging on matrix...though if this ends up being the norm for bridged libera I'll have to use something else (maybe my own bridge)
<podiki[m]>civodul: when you get a chance could you see my questions on 56677; I should finish up that fhs container patch
<civodul>podiki[m]: sure! it's actually been on my to-do list since i came back from vacation
<podiki[m]>on that topic, anyone here have some familiarity with go packaging in guix? I had a few packages I had to make separate packages for additional files they had for some reason, not sure the right way it should have been handled
<podiki[m]>civodul: thanks for the update on the fhs container patch, I'll try to get that wrapped up soon!
<mbakke>civodul: last I checked staging was doing pretty good on x86_64, but aarch64 is lagging pretty bad (even on 'master', so maybe we can ignore it...)
<mbakke>haven't checked i686 in detail apart from a superficial glance at the weather which was OK
<mbakke>I'm running it locally FWIW with no problems so far (since the polkit kerfuffle)
<Cairn>podiki: Out of curiosity, what additional files are you talking about?
<Cairn>I see you made multiple packages for protonmail-go-crypto. Is that it?
<podiki[m]>Cairn: right. i'm not sure the namespaces/organization of go to understand if that was correct or not, other than it works
<podiki[m]>and now that I think about it, if it is correct, it should all be simple packages with inherit and just the change to import-path
<Cairn>Those subdirectories (not sure the right term) should all be made available by the parent package. So you should just be able to make a package with import-path set to "github.com/ProtonMail/go-crypto".
<civodul>mbakke: yeah a couple of aarch64 machines are MIA
<Cairn>I got tripped up by this early on, but I was pleased to find that the solution was this simple.
<podiki[m]>hrm, I'll have to try again, I was confused with the openpgp directory and some naming in that module, was strange
<Cairn>Thanks for sharing by the way. I'll start looking into the service. I'm not really a programmer so it'll take a day or two to wrap my head around it, haha.
<podiki[m]>I mostly copied/guessed my way to the service with lots of trial and error. mostly it is in other services we have in guix already, but figuring out the right way for peroxide
<podiki[m]>I want to change where the certificate goes so all users can see it to connect (e.g. with mbsync) without other commands
<Cairn>I won't solidify anything then until I see you post a patch to the mailing list. But I'll try out peroxide as it currently stands =)
<podiki[m]>it should work just including the files somewhere (e.g. use --load-path) and (service peroxide-service-type) in your system config. it will generate the certificates, but regular users can't read /etc/peroxide to view them. i'll fix that though
<podiki[m]>ah, protonmail-go-crypto won't build at the root directory since "there are no go files" there, only in the subfolders....
<Cairn>Did you check out unmatched-paren's version in the aerc patchset? That version worked for me.
<podiki[m]>ah it is an "only source" package maybe, like x-crypto
<cbaines>civodul, I'm not sure the ci.guix.gnu.org ARM problems are due to lack of hardware. bordeaux.guix.gnu.org only has two ARM machines building things, one Overdrive and one HoneyComb LX2, and it seems to be keeping up