<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" <pkill9>does anyone have an example of running pipewire as a service via guix home? <antipode>shcv: #%output is bogus, either do %output or #$output (and preferably the latter, %output is undocumented and is removed when cross-compiling) ***Spawns_carpeting is now known as Spawns_Carpeting
<ulfvonbelow>it seems that gdm has some issues with not having permission to access /dev/tty7? ***spiceusabtc[m] is now known as Lucybtc[m]
***rgherdt_ is now known as rgherdt
<ulfvonbelow>sddm is also failing - /var/log/sddm.log includes [01:11:56.924] (WW) DAEMON: Auth: sddm-helper exited with 6 <sneek>civodul, you have 2 messages! <sneek>civodul, apteryx says: re gnome importer: gedit: updating from version 40.1 to version 43.alpha -> perhaps too aggressive now? :-/ <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>... to use it in e.g. Emacs or git config. <bost>(setq user-full-name "Alice Doe") <bost>(setq user-mail-address "alice@mail.org") <bost>lilyp: ??? what do you mean by that? <lilyp>user-full-name is a variable defined in ‘C source code’. [...] You can customize this variable. <rekado>ulfvonbelow: I can only say that, yes, gdm works for many of us. I’m using gdm ad gnome on guix system. <ulfvonbelow>rekado: just to double-check, what are the permissions on the virtual terminal you're using? <ulfvonbelow>mine (/dev/tty7) show up as crw--w----, owned by root:tty ***fnstudio_ is now known as fnstudio
<rekado> /dev/tty differs with crw-rw-rw- <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: <ulfvonbelow>/gnu/store/8qifljj6gh5h6wcjypx73p9vm8sb0vvp-xorg-server-21.1.4/bin/X -xkbdir /gnu/store/8mszv7v6kqdyavpvf8zb7kkagaan5vri-xkeyboard-config-2.34/share/X11/xkb -config /gnu/store/sl8c1mzvrkszmj1mn3p2fi5cbpzd3zz3-xserver.conf -configdir /gnu/store/5b1i6kyyfx6zx14ds454d082ypr9nij1-xorg.conf.d vt7 -displayfd 3 -auth /run/user/983/gdm/Xauthority -nolisten tcp -background none -noreset -keeptty -novtswitch -verbose 3 <ulfvonbelow>I use whatever's in %desktop-services, so I assume so <rekado>mine has vt8, and /dev/tty8 happens to be owned by my user account <jpoiret>maybe there's an issue with elogind and it doesn't manage the seats properly <ulfvonbelow>gdm doesn't even get to the login screen, it just displays a "something went wrong, contact an administrator" message on vt7 <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? <Burutsu>jpoiret: yes , guix package --list-installed=font-scientifica works. <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 <sneek>Welcome back efraim, you have 2 messages! <sneek>efraim, antipode says: #$(gexp-input (this-package-...) "another-output") <sneek>efraim, antipode says: Or #+, for native. <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? <jpoiret>apfel: how do you use rust? through guix shell? <apfel>jpoiret: yes, this is correct. <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. <lilyp>awefawefawef: `tar xvf $(guix build emacs --source)' <lilyp>as for telling emacs where its source is, perhaps we should install the sources to some output similar to the debug output used by some packages <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... <antipode>awefawefawef: "guix build --source emacs-next" <antipode>Depending on the package, you get a directory, or a tarball / zip / ... (file) <lilyp>so your issue is that `guix build -S' doesn't return a directory or ??? <awefawefawef>lilyp I think so? and that emacs doesn't seem to know about it by default (find-function-C-source-directory var) <awefawefawef>because then I probably need to update it's location when emacs updates <lilyp>yeah but the issue here is simply that the sources aren't installed as part of emacs <awefawefawef>I would want it to be how the package manager handles all packages <antipode>Most packages don't have a find-function-C-source-directory, so I don't think it makes sense to automatically install the sources of everything (space + network IO savings) <antipode>However, I suppose we could have an emacs-sources package or an emacs:sources output, and adjust find-function-C-source-directory to make it find it when installed. <abcdw>rekado: I have probably unrelated to yesterday's, but similiar build fail for `guix time-machine -- build rust-wayland-scanner`. Could you take a look, please? <jpoiret>a sources output would be the most logical imo <civodul>cbaines: those substitutes for patches give super-power! now i'm frustrated when i don't get them :-) <ardon>Hi guix! If I want to submit a patch for a package's update that doesn't have any releases and is based on Git commits, should I update the revision in the package definition too? <civodul>ardon: hi! yes, the revision serves as a hint to know which snapshot is newer <zamfofex>Is there some way to expose all (or some) entries in the store as subsititutes? <podiki[m]>anyone else have connection troubles to irc today? (i'm via the matrix bridge and haven't received messages, according to the logs) <singpolyma>podiki[m]: yeah, I got disconnected for a bit earlier <podiki[m]>hmmm..not getting messages that I see in the log, maybe need to reconnect <cbaines>civodul, haha, unfortunately there will probably be a few more days delay as bordeaux.guix.gnu.org is still processing the backlog of builds from the recent rust related changes <cbaines>once the qa.guix.gnu.org thing is submitting builds for branches as well, this shouldn't be an issue <cbaines>since then, like ci.guix.gnu.org, it'll have hopefully built things by the time the branch is merged <civodul>with this, it'd make even more sense to have "negative substitutes" <civodul>like you run "guix build foo" and you get "This thing is known to fail to build, try --force" <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: "141.80.167.158" "141.80.167.159" <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 <apteryx>we should at least use debugoptimized <apteryx>hmm, and it is: (build-type "debugoptimized") <zamfofex>acrow: Maybe your ‘umask’ was different accross these two different systems when you installed Guix on them. (Assuming it isn’t Guix System, that is.) <acrow>zamfofex: Actually they are both guixsd... Hmmm... <acrow>zamfofex: What perms do you have on your /etc/guix dir? <acrow>hmmm... so, my more restrictive dir is not unusual. <podiki[m]>is anyone that is connected via matrix receiving messages? <zamfofex>podiki[m]: Not sure if you’ll see this, but if people aren’t receiving messages, they might not be able to see yours. <podiki[m]>I'm reading via the log :-) but yes, good point. though I think in the past we had some connection issue where matrix users were getting messages from other matrix users only <podiki[m]>i'm on another libera chat channel via matrix and it is still working <lilyp>zamfofex: IIRC it's a known problem that hurd fails pretty early in the graphical chain <lilyp>I for one wouldn't trust it to build rust anyway, but that aside do glib, gtk and friends even build on the hurd? <bost>Hi. `sudo guix system --load-path=... reconfigure ...` reports: <bost> guix system: warning: exception caught while executing 'start' on service 'swap-/swapfile': <bost> In procedure swapon: "/swapfile": Invalid argument <bost>Does anybody know what's going on? <lilyp>(If things work on debian, it's probably because they have some patches that we're missing) <apteryx>lilyp: IIRC a graphical environment is available on the Debian Hurd image <lilyp>"a graphical environment" can mean many things from a bare-bones x11 setup to gnome/kde/what-have-you <apteryx>"only about three quarters of the Debian packages has been ported to the GNU/Hurd" -> probably more than there are in Guix <civodul>apteryx: Xorg, LibreOffice, etc. all that is available on GNU/Hurd <civodul>from userland it's hardly distinguishable from GNU/Linux *podiki[m] still exists in a cone of silence <apteryx>one of the strong points of the Hurd is to be mostly compatible with POSIX, hence porting efforts should be minimal <podiki[m]>is there a libera channel for their bridges/reporting a problem? <apteryx>podiki[m]: aren't problems with the matrix <-> IRC bridges matrix problems rather than libera.chat ones? <podiki[m]>libera runs the official bridges I think, but I will investigate (yes, could be on my matrix end for some reason) <lilyp>interestingly, emacs is built with gtk+ <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. ***mark__ is now known as mjw
***tissevert1 is now known as tissevert
<apteryx>we don't yet have a means to run 'guix refresh' on a specific module yet, do we? <apteryx>podiki[m]: I would be surprised if libera.chat manages any matrix component themselves <lilyp>apteryx: easy workaround, add all the variables in a module to your manifest and use -m :) <apteryx>lilyp: this seems to do it: awk '/define-public/{print $2}' gnu/packages/gnome.scm | guix refresh <apteryx>more like: awk '/define-public/{print $2}' gnu/packages/gnome.scm | xargs guix refresh <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>for assistance you can come here <rekado>I’d love to see more work on the hurd <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. <apteryx>podiki[m]: for what it's worth, I use weechat and its relay module to keep multiple machine sync'd rather easily <singpolyma>I need to get around to figuring out how substitutes work so I can make document it <apteryx>it even allows scripting it with Guile <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> <apteryx>lilyp: not exactly painless, as many packages are not public or don't share the same name/variable <apteryx>ah, nevermind, I'm silly, I was using the names as symbols and specifications instead of using packages->manifest directly <zamfofex>How much disc space do all packages take after built? <civodul>mbakke: hey ho! how's 'staging' going? <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 <civodul>i'm a professional O_CLOEXECer at this point <podiki[m]>civodul: no worries! I also have 40+ go packages to clean up and a service for hydroxide (protonmail bridge) to get ready to submit. the service works nicely though, been using it this week <civodul>ah neat, i saw that hydroxide series too <podiki[m]>oh, I meant peroxide, whoops :) hydroxide was from Cairn I think? but same idea (peroxide gives me full imap usage though) <apteryx>civodul: haha! I'm glad this cloexec idea is becoming a thing thanks to your efforts. <apteryx>are you pursuing that in the hope it may help with the login slowness on berlin? <podiki[m]>writing a shepherd service was not too bad actually, managed to figure out how to do the activation part so it should work by default without extra input <apteryx>I remember shepherd taking 30 s when it had to close 1,000,000 (unused) file descriptors on my system when I had raised ulimit <civodul>apteryx: that O_CLOEXEC quest started with those observations of the delays we see on berlin <civodul>it might help indirectly: if we remove the close(2) loop in 'exec-command', then we likely get rid of the code that for some reason causes the delay <civodul>but i still don't know what's going on in the 10s between close(14) and close(15) <civodul>(30s for the close(2) loop is a *lot*!) <civodul>anyway i'll do some testing with Guix System and release that as 0.9.2 i think <Cairn>podiki: Oh, did you finish it up? <Cairn>Still waiting on unmatched-paren to get time for a couple quick questions, but once you post peroxide, I'll try to set up a similar service for as a new patch for hydroxide. <Cairn>That way they can be relatively interchangeable packages. =) <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 <Cairn>Yeah, looks like only source. Correct. <podiki[m]>I see, unmatched did it like I did, separate packages. not sure which is correct...seems there is only one go module though. <podiki[m]>it "builds" as source only then, let me see if the rest works <Cairn>They corrected it to a single package later on <podiki[m]>so that's the problem with these big patchsets, they just sit for so long and people redo the same work or it gets lost in merge conflicts <Cairn>Yeah, it requires a lot of attention to keep track of lots of these <Cairn>Guess Guix just needs more contributors ;P <podiki[m]>but perhaps we need a better plan for patchsets more than a few patches, it is a lot to ask someone to review. let me think and pose some questions to the mailing list later <Cairn>Nice, I'll watch for your post <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