IRC channel logs
2023-05-11.log
back to list of logs
<bdju>so is sway broken on master right now? <bdju>is there a way to install an older version of just the sway package? not sure how many times I'd have to roll back everything to get a working one... <graywolf>Hello Guix :) I have a question, is one supposed to send polite ping to patches that seem trivial and are not merged (yet)? If yes, what would be fair time span? <graywolf>I do not want to impose, but at the same time I would like them not to be forgotten. <oriansj>bdju: yeah, I just wish packages were tested prior to being merged into master; even basic things like making sure the darn thing can build <graywolf>Will sent patch when I get to it, but it is 2k+ lines, so it might take a while. <graywolf>The author promised to revise it, but I would recommend taking it down until it is re-done. The current state of the Czech translation is honestly just embarrassing in some places, flat out wrong in others. It does not shine good light on the Guix project. IMO. <guixfren>I'll have to read the Guix docs around contributing, but I can do some work on Czech translations if necessary <ulfvonbe`>is it not intended for it to be possible to mix inferior and regular packages ina package definition? <ulfvonbe`>e.g. in my manifest I have some packages defined, but want their dependencies to come from an older guix <ulfvonbe`>so I rewrite it so that those inputs are <inferior-package> objects <ulfvonbe`>now package->manifest-entry complains that it has no properties field <nebulasurfer>I am considering switching to Guix, and I have just a couple questions <nebulasurfer>I want to use pipewire, pipewire-pulse, pipewire-jack, etc. Does pipewire work well? <nebulasurfer>I have a proprietary DAW that I unfortunately have to use to open years of music composition files. (Renoise is what I use) <nebulasurfer>It's not free software. Is there a path forward for me to get builds/binaries working on Guix? <lemos[m]>got further with the package i am updating, tho, some dependencies are fetched through meson wrap, can i fetch them while building? <lemos[m]>they can also be added as a subproject manually, but i couldn't find how could i do it, in gentoo, i have a big src_prepare for this package <rekado>apteryx: oh, that’s surprising. Something wrong with it? <apteryx>nope, just couldn't get nginx to reload nor restart <apteryx>and it's needed to take into account the new /etc/ssl-ca CA <apteryx>mumi still requires some hand holding to start? <apteryx>nginx didn't restart; probably the anonip stuff <apteryx>seems the files under /var/run/anonip are FIFOs as should be <rekado>I would have appreciated a note, because now my screen session is all gone :-/ <rekado>that’s why *guix.gnu.org is offline, including issues.* <apteryx>I've cleared /var/run/anonip/* in case, but it seems to be something else. <rekado>if shepherd doesn’t tell you enough consider running nginx manually to see if it has anything more to say <apteryx>the new CA no longer has a ca.crl file. I'll remove it. <apteryx>will communicate to sysadmin along a better patch to Cuirass doc <apteryx>updated cuirass authentication doc/script sent to 63375@debbugs.gnu.or <apteryx>we should really automate the bits remaining <sneek>Welcome back civodul, you have 1 message! <sneek>civodul, dthompson says: oh! I was using set-session-transport-port! so I'll have to try updating and switching to set-session-transport-fd! thanks for the heads up!! <efraim>I thought I'd take a look at updating rust to 1.68 but rustfmt wants to ldload some libraries from the #$output:out prefix but tries to use its #$output:rustfmt prefix instead :/ <civodul>namespace-related puzzle: what can explain a sequence like stat(x) = ENOENT; exec (); stat(x) = EACCES ? <civodul>IOW, how can the same process say ENOENT for a file before exec, and EACCES right after exec? <jpoiret>civodul: do you have a minimal reproducer for that? <bdju>managed to get sway to start, I used --with-commit= to upgrade to one release newer than guix had and managed to start it. but I also managed to get system upgrades to go through after finally skipping enough packages, so unsure what all did it. <bdju>so if anyone else has an issue starting sway I guess I would recommend this: guix install sway --with-commit=sway=68d620a8fd70d70eb91c58dcfafc4af16c58379d <bdju>still unable to resolve conflicts and install flashgbx until gajim's build failure is fixed but at least I'm not stuck in a TTY anymore <jpoiret>we could upgrade to 1.8.1 (and also upgrade wlroots) <bdju>at one point yesterday I crashed to TTY and then couldn't log in to the TTY at all, after user/pass it went back to prompting for user. then once I thought to restart the shepherd services for my TTYs from my phone I was able to log in and get to a shell. then starting sway gave some errors about mesa and such and wouldn't start at all <bdju>I got a picture of my monitor of the errors, I'll upload/link it in a minute here. haven't reopened my browser yet (hopefully that won't crash everything) <civodul>jpoiret: turned out to be unrelated to namespaces: the syslogd service was calling 'umask' in PID 1, which leads to a race condition when services are started in parallel <civodul>as in, some services might see the "wrong" umask <janneke>after autoconf, automake, now guile-gnutls doesn't cross build <civodul>janneke: i think jpoiret was looking into it :-) <civodul>we fixed a bug but the cost was the introduction of another one <jpoiret>I can open a pr upstream, we'll see if (eval-when ...) is the preferred solution for upstream <civodul>upstream and downstream are very close to one another :-) <jpoiret>bdju: that's a known mesa problem, have you updated recently? I think mesa now has the crocus driver <bdju>I have *now* updated recently. before I hadn't been able to in a few days due to many packages failing to build (after some hours and skipping like 20 packages I managed to get upgrades to finish) <bdju>I did not test the older sway after getting other upgrades to finish to see if that worked, I was trying everything I could think of at once. sorry <janneke>jpoiret: just "found out" (someone mentioned to me yesterday) that you updated the hurd, amazing and thanks! <janneke>jpoiret: i also noticed that you explicitly disabled rump, have you tried/considered building with rump? <jpoiret>janneke: it doesn't boot anymore though! <jpoiret>and no, I haven't tried, I wanted to make minimal changes only <jpoiret>I don't really know how to debug a running Hurd though, it seems that the exec server isn't starting <cbaines>unfortunately it looks like I've done something wrong :/ <macrocreation>Anyone here in the UK available for a meetup? I managed to build my first package - freeswitch! <macrocreation>I want to get some tips on some ideas where I can use inherits to enable people to build versions that enable/disable specific modules etc. <janneke>jpoiret: ah booting yeah, found that too...oh well <macrocreation>the IRC is great- but even better is a hacking session with an expert that I can learn from. <janneke>jpoiret: making minimal changes makes sense! <macrocreation>Also are there any archives to this IRC. Someone made suggestions on how I could improve my package definitions and I can't find the old part of the chat <jpoiret>is help2man needed? I've never needed it <jpoiret>maybe nobody uses it and it's been broken for a while <jpoiret>arf, my sysconfdir is /usr/local/etc, probably because I pulled with a badly-configured guix checkout. since `guix pull` always inherits this, looks like i'll need to do a weird dance to sort it out :( <jpoiret>cbaines: is there a way to view .drvs directly in browser? <jpoiret>I was going to use `guix substitute` but since my sysconfdir is borked I don't want to make it worse <cbaines>jpoiret, the data service can display derivations if it knows about them <jpoiret>ah, no sorry, not drvs but builder scripts <cbaines>those are just provided through substitutes <cbaines>I haven't attempted any helpful display as the builder can be anything, but I should probably try to detect the common Guix case and display the script with some automated formatting <jpoiret>ah, kinda forgot i can just do `guix build` to get it instead of manually substituting it <jpoiret>no, don't worry about it it's just me being an airhead <chomwitt_>i found an error in xinit package 's startx script. Startx calls an X server bin using a path in xinit's package. Unfortunately /gnu/store has readonly permissions. how can i correct this ? <zamfofex>chomwitt_: I think you can specify ‘-configdir’ and ‘-modulepath’ to ‘startx’ after ‘--’. <chomwitt_>zamfofex, thanks. i am having a look at package sx thats seems to be similar to startx . in doesnt work i'll try the startx arguments <civodul>jpoiret, janneke, cbaines: re guile-gnutls, the gnutls-cross.patch was inadvertently dismissed, which is why it's now failing <civodul>i'll re-add it if nobody beats me at it <cbaines>ah, I see it, I wonder how I got rid of that <janneke>ah, that's where the deja-vu came from <evilsetg[m]>I asked about it yesterday, my icedove crashes with an error regarding an undefined symbol in glibc. I was told to update my system and local packages, then reboot. I did that but still get the error. Does anybody know more about it? Is there anything else I could try? <jpoiret>itd: The error seems to be the "Too many heap sections" message <cbaines>jpoiret, Guile-GnuTLS/Git circular dependency would probably cause "Too many heap sections" becaues the DAG then isn't a DAG and Guile goes in loops until it uses up the heap <zamfofex>Hello, Guix! I know I asked this fairly recently, but it was at a time I think people were mostly asleep. But if it isn’t a big bother, could anyone take a look at reviewing/merging <https://issues.guix.gnu.org/63088>? It adds Lc0 (a chess engine). <jpoiret>that's rigth, it's exactly that commit! itd: is there a reason you're trying to pull this exact commit? <itd>jpoiret: not really, no. just noticed the issue in my cuirass, found the existing issue, and wondered if it makes sense to report the issue (again) <next4th>zamfofex: re lc0, looks good to me, i'm applying it. <evilsetg[m]>jpoiret: yes I do, but only to add some shepherd user services. I did reconfigure that just yesterday at well. <chomwitt_>is dbus a default service or i must added in my system config ? <zimoun>civodul: about #63393 and libstdc++ / gcc-toolchain, thanks for the review. <zimoun>About gcc-final, I am suggesting to not use gcc-final for gcc-toolchain but gcc-11. As we are already doing for all the other gcc-toolchains, as gcc-toolchain@7 or @12 <chomwitt_>apteryx, during installation i didnt choose any gui desktop and thus desktopservices is not in my config.scm <chomwitt_>for example i see that a login manager is in the default but i dont wont one <apteryx>chomwitt_: you'll have to add a dbus-root-service-type to your system services <civodul>zimoun: independently, i'm in favor of not adding gcc:debug <civodul>zimoun: the reason for using gcc-final rather than gcc-11 is to avoid duplication, save disk space <apteryx>zimoun: are you still interested in getting commit rights? we can try to finish that now if you have time <chomwitt_>that command list some services i guess. dbus is among them. Should it also list the name that i have to insert to my config.scm to enable it? <civodul>ACTION notices openjdk is being rebuilt, wonders why <chomwitt_>i guess it's the dbus-root-service-type you wrote. but just wonder <apteryx>chomwitt_: yeah, 'guix system search' is useful to find existing services <apteryx>then to know how to use them, info guix -> i dbus-root-service-type RET <apteryx>civodul: is being on savannah necessary to become a committer? I remember that yes, but I forgot what is the interaction with the authentication code <civodul>apteryx: yes, one needs a Savannah account with an SSH key to have push right <civodul>one also needs to be in .guix-authorizations and have their key in the 'keyring' branch <apteryx>I see. So Savannah is authentication for push rights, and GPG in keyring is for guix's own auth mechanism <apteryx>zimoun: ^ you'll need to create a savannah accout if you haven't already, and upload your SSH public key there. <apteryx>upload your GPG one too, as it's a reliable/trusted place to retrieve it from <chomwitt_>apteryx, adding dbus-core-service-type , system reconfigure throws an 'dbus-root-service-type' unbound variable error <apteryx>you'll have to import the (gnu services dbus) module <cbaines>I'm going to run ulimit -c unlimited as I think that's helpful, but do let me know if that's wrong <apteryx>did you know that we can vote for bugs on Savannah? could be fun to let people vote for issues they'd like solve on our Mumi tracker <apteryx>weird, our pre-push hooks fires when pushing commits for the keyring, but there's no Make targets there, so 'authenticate' fails <apteryx>rm ~/src/guix/.git/hooks/pre-push to work around that <apteryx>comes back on the next 'make' anyway <GNUtoo>Hi, while looking at guix source I found functions like package-direct-inputs and specification->package, however they both operate on the packages of current-system, is there a way to get the dependency of the package of another system (like i686-linux when you run x86_64-linux) ? <civodul>iyzsong[m]: hi! the package definition of oneDNN looks suspciously short, no? <zimoun>civodul: duplication, about what? The deduplication avoids that, no? <civodul>zimoun: not entirely; users would end up with two slightly different variants of GCC 11 <podiki[m]>(I think the matrix bridge is down, not sure if messages get sent through but none coming out to matrix currently) <apteryx>civodul: was there not something like having to repush a GPG key when resigning it with a refreshed expiryÉ <GNUtoo>(i686 desktop usage is horribly broken right now to the point that it's probably easier to fix from an x86_64 system but then my scripts to detect which packages have problematic dependencies is broken there because it uses the functions I mentionned above, though I'm also open to other ways to get that info as well) <apteryx>I'd like te welcome zimoun as a new committer! Congratulations, Simon! <podiki[m]>congrats zimoun! I think I always assumed you were a committer already with all the great work you do <evilsetg[m]>At anyone with shepherd knowledge: I am trying to modify the default-environment-variable parameter at runtime. I want this so my emacs service gets the DISPLAY variable set when running via a shepherd service. With systemd I would call a systemctl --import environment when starting a graphical session. I found about the eval action so I tried to change default-environment-variables like that but I guess this does not work because the <evilsetg[m]>eval happens within a save-module-excursion. Is something like this possible at the moment? I really would like to inform my home-shepherd that it is running in a graphical session. <podiki[m]>which reminds me I need to renew my key today.... <zimoun>Cool, thanks! Now I have the pressure :-) <mrvdb>what is the action needed, if any, for warnings like "warning: 'texlive-latex-atveryend' is deprecated, use 'texlive-atveryend' instead" ? <GNUtoo>ACTION guesses that it's just some information that tells you that these packages were renamed <GNUtoo>so you could look if you use them directly in your setup (like if you have texlive-latex-atveryend inside your system.scm or in some manifest, you'd need to rename them at some point) <GNUtoo>For me it also shows that information even if I don't use them directly (I just use 'texlive') <mrvdb>dont use them directly, just as deps of texlive I guess <GNUtoo>Some people use guix shell to make their LaTex document reproductible so maybe they use them directly <evilsetg[m]>podiki[m]: I can see all messages from the irc logs also on matrix. But what you describe has happened to me once before as well. Maybe rejoining helps? <podiki[m]>evilsetg[m]: thanks, let me try. been a while since the bridge had issues, but yeah it happens occasionally <mrvdb>GNUtoo: am I correct than that these warning disappear automatically as dependencies are renamed over time? <GNUtoo>I guess so, my supposition is based on the fact that I didn't install these packages, so I just think it's just some information that is always displayed <GNUtoo>It also make sense as you could use them in a manifest and not use that manifest every day <janneke>well, my system with childhurd builds, at last \o/ <zimoun>civodul: what do you mean by “end up”? I do not see the cons. Anyway, I got your point. I will answer in the patch submission. <jpoiret>mrvdb: there's a patch in the MLs for that, nothing from your side <jpoiret>some package names were deprecated but we didn't rename them in Guix itself <podiki[m]>evilsetg[m]: didn't work for me unfortunately <podiki[m]>any other matrix users receiving messages from the irc end? just wondering if it is a more widespread bridge problem <GNUtoo>btw, matterbridge is packaged in Guix so maybe it could be used to workaround issues temporarily. <GNUtoo>Note that it still needs improvements (dependencies are vendored and there is no service) <GNUtoo>I'm also not sure it does matrix but it does a lot of protocol so it's likely to have matrix support as well <podiki[m]>I guess I could always bridge locally (I'm on my own matrix server) <pmf[m]>I'm having the same issue. Leaving and rejoining didn't help. I'm also on my own matrix server. Other IRC-bridged rooms seem to be working fine. <podiki[m]>pmf: thanks. I'll open upstream issue then unless someone here can send a restart command to the bridge (not sure if it is separate per room or for all libera) <evilsetg[m]>@podiki I I am in two #guix matrix bridge channels. One is #guix:libera.chat. This one does have problems. The other I joined via `!join #guix` In a room called 'Libera chat irc bridge status'. That one still works. <podiki[m]>huh, interesting, didn't know there were different ways to join <patrickt>Hello! Hope you are well, I am very excited by the prospect of Guix, it's a brilliant approach and the syntax is preferred to Nix! I recently ran an installation of SD with the 1.4.0 installer and selected Xfce for the desktop environment, however, when trying to insert a USB, it must be manually mounted. I tried looking for documentation on how to set up `auto-fs <apteryx>Another freshy enabled committer is jpoiret; congratulations :-) <civodul>hey, congrats zimoun & jpoiret! long overdue! 🎉 <patrickt>* set up `auto-fs`, but I didn't find anything in my search. My question is how does one configure software that doesn't have built-in structures exposed for Guix? (not sure if it makes sense as a question, just trying to understand how to configure software without configuration files as with other distros) <civodul>Z572[m]: oh nice! you should send a note to guix-devel <podiki[m]>yes welcome jpoiret! another long overdue addition I would say :) <Z572[m]>civodul: licheepi 4a, i sended,but not display in guix-devel <jpoiret>patrickt: this might be an issue with XFCE in particular, since udisks should be set up by default <jpoiret>weird, users added through the installer are in "wheel" by default as well <jpoiret>patrickt: in general, if something is not in Guix yet, you would need to write a service definition for it. Depending on the complexity of the thing you're trying to use, it might vary from very easy to very hard, but it's usually quite easy <efraim>rekado: python-pytest-enabler is also in gnu/packages/check <patrickt>podiki: Thanks for the tip, hmm, seems like I even missed some messages. <patrickt>Thanks jpoiret for such a detailed reply!! <jpoiret>cbaines: where can I find your public key? It seems that the one on savannah isn't the one you use to sign your messages (or maybe my MUA is not properly configured) <efraim>civodul: it looks like the vnstat tests commit broke cuirass <bdju>I've hit an issue recently with the nheko matrix client where my backspace key doesn't work in the chatbox. Has anyone else run into that? <cbaines>jpoiret, I think the key on Savannah should be the correct one <cbaines>although I "use" Emacs for email, which is to say I don't know how any of this works <cbaines>(my own emails show up to me as "Undecided", and I have no idea why) <jpoiret>the key I got from savannah is expired, maybe you've renewed it but haven't uploaded it there yet? <rekado>efraim: ah, crud. Thanks for letting me know. <apteryx>rekado: the 6 x 8 TB SSDs are connected to the PERC of node 129, right? <apteryx>do you have experience with the PERC hardware RAID? <cbaines>jpoiret, ok, I think I've updated the key <cbaines>and if anyone knows if there's a way in mu4e to verify message signatures, let me know! <civodul>mfg[m], efraim: thanks for the heads-up! <podiki[m]>rekado: there is some way to verify/sign message in mu4e but I'm not savvy, did look it up once <podiki[m]>rekado: and there were some quirks to it, I know I messed up my email signatures when doing the commit access emails <patrickt>mfg: Glad I saw your message, I have the exact same issue <patrickt>guix pull works perfectly again, much appreciated :) <jpoiret>is `Signed-off-by:` necessary when you push someone else's patch? Is the commit author + committer info not enough? <zimoun>jpoiret: See 22.8.2 Commit Policy <zimoun>« When pushing a commit on behalf of somebody else, please add a Signed-off-by line at the end of the commit log message—e.g., with git am --signoff. This improves tracking of who did what. » <jpoiret>zimoun: do you know of a piem option to add those sign-offs automatically? <zimoun>no, I am also looking for one. Adding an alias in .gitconfig is not doing the job for me. <cbaines>I have magit configured to add the signoff line when I apply patches <jpoiret>zimoun: piem-am-args looks like the way to go :) <cbaines>when you've got the relevant menu up that shows the --signoff option in Magit, you can toggle it on, then C-x C-s to save that as the default <jpoiret>cbaines: the thing is that we use piem. How do you get the mbox? <jpoiret>something to easily get mboxes from various sources <johnjaye>my irc settings render your name as tsch. hello tsch <johnjaye>technically i have the nicklist display still. but it just kind of stays on the A's all the time. <johnjaye>vagrantc: small terminals means tough decisions have to be made. <apteryx>seems the core-updates merge broke a few system tests; I know two: jami and xvnc <rekado>podiki[m]: sorry, what’s that about mu4e? <jpoiret>adding `--signoff` to piem-am-args works for me <zimoun>it fails for #60788. Well, “b4 am 87cz4ftq5z.fsf@gmail.com” fails for me. <zimoun>jpoiret: do you experiment the same? <jpoiret>since we had some trouble with the vnstat tests earlier today <zimoun>yes, just “b4 am 87357fjyuc.fsf_-_@gmail.com” fails but “b4 am 87cz4ftq5z.fsf@gmail.com” (contrary to what I said) <zimoun>both msgid are from the same thread. <rekado>podiki[m]: sorry, I still don’t know the context. Have I been involved in a conversation about signatures? <podiki[m]>ah sorry that was cbaines, hit the wrong name! <podiki[m]>cbaines: see ^ for some mu4e signing/verifying message info but I haven't set mine up properly <cbaines>that information doesn't seem to work for me podiki[m] <cbaines>I think I've found out how to enable verification though <cbaines>setting mm-verify-option to known seems to work <podiki[m]>cbaines: ah yes, that seems to do something. now I just gotta test my signing, there's too many similar options (I think all via gnus) <podiki[m]>now I see "bad signature" not sure why (maybe have to verify/trust the key somehow?) <mirai>is there some fundamental reason why can't /etc/services be provisioned within a build environment? <apteryx>perhaps explained in Eelco Dolstra's thesis, if there is one <mirai>it's a simple “database” file containing known services tcp/udp ports, doesn't seem to depend on networking <apteryx>I think it's used by the resolver in libc, which is not functional in the container anyway, so perhaps having teh file would be moot? <mirai>jpoiret: did you change your git email configuration regarding the X via guix patches via … ? <mirai>apteryx: guile netdb uses it <mirai>and by resolver, you mean getaddrinfo? <lilyp>joke: you don't restart pulseaudio, pulseaudio restarts you <jpoiret>mirai: no, but now all my patches contain the From: line to avoid misattribution <jpoiret>basically, since debbugs changes some DKIM-protected headers, either you disable DKIM or you end up with debbugs rewriting your From: to pass DKIM <jpoiret>(that's only if your DKIM policy is quarantine or refuse) <elb>is that why I don't reliably get replies to my debbugs emails, I wonder? <jpoiret>no, the Reply-To header should be properly set <jpoiret>well, maybe it does contribute to it, but I haven't experienced this issue <elb>I get maybe 1/2 to 2/3 of the replies that go to tickets I open <elb>which is annoying when someone asksf or info and I don't know <jonsger>sudo herd restart user-proccesses does the thing, but it kicks you even out of your sway session :P <jpoiret>user-processes kills just about every user process, right? <jonsger>I guess, but pulseaudio seems one of them. runs as your user <jonsger>jpoiret: congrats on becoming a commiter, btw :) <guixfren>taking a proper look at the contributing guidelines has been on my todo list for far too long <jpoiret>thanks! just pushed for the first time (very scary) <attila_lendvai>python-daemon fails to build. updating it to v3.0.1 leads to two failed tests with: AttributeError: 'Exception_TestCase' object has no attribute 'instance' (and the other with 'types'). any hints? <apteryx>mirai: I guess getaddrinfo is the main API of the resolver bits yes; though I'm no expert. <apteryx>what do you mean about git email configuration? <apteryx>perhaps the effect of using X-Debbugs-CC ? <Kabouik>It seems there are a bunch of packages that won't install on aarch64 because they depend on vulkan-loader-sdk, which won't build: https://0x0.st/HNPQ.png <Kabouik>I'm sorry I am on a mobile device and cannot easily copy text to pastebin it. 
