IRC channel logs
2024-11-26.log
back to list of logs
<resu>does anyone know where I can find a simple barebones example of adding a simple shepherd-sevice to a homeconfig? <resu>im trying to add (hey launch 'emacs --daemon' real quick) to my homeconfig and I dont need it to be that complicated <ieure>resu, You want to nuke most of the start lambda and just the use (fork+exec-command ...) bits. Best practice is for the configuration to take the package as an argument so the user can change out which one it uses. <resu>welp ima just copy paste that and hack it till it works lol <Kabouik>I am getting "guix system: error: aborting reconfiguration because commit f99ada4123de1eadf668d34dac2d726407634549 of channel 'guix-past' is not a descendant of 5fb77cce01f21a03b8f5a9c873067691cf09d057" when trying to guix system reconfigure even though guix-past is not explicitly listed in my channels.scm. What am I missing? <mange>Kabouik: Channels can declare dependencies in their .guix-channel file (documented at "(guix) Declaring Channel Dependencies" in the manual). Does one of your channels depend on guix-past? <Kabouik>I use my private channel (which doesn't depend on guix-past), nonguix, guix-emacs, guix-cram and guix-gaming-games. I assume guix-cran may need guix-past, it would make sense for it. <mange>Looks like guix-gaming-games references it. <Kabouik>Good find, I'll try disabling it and see if it helps. I might report an issue later (though not sure if the issue would be with it or with guix-past itself). <futurile>civodul: are you intending to hacking on something to automate doing package updates then? (reading from your mastodon) <efraim>I saw that thread too, it sounds like even just automated patches that have to be manually applied for package bumps would be a large step forward <rekado>futurile: we already have a couple of pieces for this. We're using "guix refresh" with automatic committing for guix-cran and guix-bioconductor, and a few months ago there was an automated "latest" jobset on an instance of Cuirass that would build automatically updated packages. <rekado>going forward I think we need more specialized teams that benefit from these kind of tools to *regularly* update their package collections. <rekado>(because something like the python-team would just never get anything done considering the ridiculously large package collection they are nominally in charge of) <rekado>for R packages I'm periodically updating the full collection with the help of "guix refresh -t cran -u", and it's been going really well. <rekado>improving the importers / updaters would go a long way towards achieving this goal <futurile>rekado: It would be great to be to remove a lot of the cut-n-pasting and faffing around from that sort of thing. Leave more time for figuring out the issues that do come up. <efraim>also it would help keep packages up-to-date without checking on them individually <futurile>rekado: I guess the amount of resource we have for CI is starting to become a limiting facotr <futurile>efraim: yeah totally. Lots of the minor Cargo updates could easily happen <rekado>futurile: are we even using all of the servers behind ci.guix.gnu.org? They used to be the very model of the concept of "work/life balance". <futurile>rekado: I don't really understand the architecture around QA/CI - what I do know is that QA is days/weeks behind processing master regularly - and can't seem to process the other branches we have <efraim>rekado: I think cbaines's QA system showed us how it could be even better <futurile>rekado: I've been trying to nudge people to merge their branches more often - long running branches are bad/costly - but every time I look CI/QA hasn't processed yet <futurile>and yet look at the branches on QA: Rust team is not processed <efraim>not for aarch64, it's always way behind <rekado>I've said it months (years?) ago: I'd be okay with replacing Cuirass for a system that works better. Perhaps cuirass still has a place for smaller environments, but the state of the build farm at ci.guix.gnu.org makes me sad. <futurile>I think really it's something to do with QA<-->CI relationship and work being done. From the perspective of a packager 'QA' is the interface to know if something has build successfully. Chris said on a call the other day that it's the amount of memory that's needed to process all the derivations. <rekado>It makes me sad that these servers only become older, aging through their best years without us getting much use out of them. <rekado>the QA system is great. The build coordinator is reliable and gets stuff done with fewer resources. <rekado>I don't see a point in keeping Cuirass when we have another system that works better. <futurile>Would it improve the resource utilisation? (I don't have a mental model to understand the limitations we have) ATM it seems CI is available, but QA can't successfully use it <civodul>rekado: re serenity, there is 1 (one) queued x86_64-linux build <rekado>futurile: yes, they are independent. The servers behind ci.guix.gnu.org do not get build tasks from QA. <rekado>if ci.guix.gnu.org is either unused due to unknown bugs or unused because it already completed all tasks --- would it not make sense to donate some of the servers to bordeaux/QA? <civodul>the problem with these two CI stacks is that they’re not interchangeable <civodul>the Coordinator is awesome, but it needs to be fed by a Data Service instance <civodul>so for smaller setups, Cuirass is easier to get going i think <cbaines>things were meant to be more interoperable than they currently are <cbaines>Cuirass was meant to be able to share build information with the data service <civodul>yeah, things went wrong at some point <cbaines>the build coordinator doesn't need a data service instance, although there's currently no direct alternative <futurile>cbaines: from my "as a packager" assertion that QA is the interface I deal with - what would speed up my perception (reality?) of patches being processed? <efraim>cbaines: is that offloadable? like if we gave some berlin machines to make that happen? or even just reassigned some berlin machines? <cbaines>there's a combination of issues behind that, but hosting is part of it. I'm renting the Hetzner VM that data.qa.guix.gnu.org is using, but more RAM and disk space is needed to process revisions faster <rekado>cbaines: would it help if we took one of the big nodes behind ci.guix.gnu.org and used that to replace the Hetzner VM? <rekado>I understand that hosting at the MDC is not ideal. <cbaines>efraim, rekado yes, any machine with more than 32G of RAM would be an improvement <efraim>We'd have larger problems when networking at MDC occassionally goes down, but we'd get a very large boost in all the things <cbaines>(and anything to also move the hosting from me would be appreciated, as that's something I've been trying to shift for a while now) <efraim>even the "smaller" machines in berlin have 128 GB of ram <rekado>load average on that machine is 0.0. <rekado>we can exclude it from the list of nodes for ci.guix.gnu.org, but I'd need guidance on what to do with it afterwards. <rekado>I obviously should not decide this unilaterally, so we better discuss among the Guix sysadmins over email. <futurile>cbaines: would the data service need to be "moved" or can it be clustered - or some of the workload offloaded - across some machines? <rekado>but if we do decide to go forward with this I'd be happy to help <futurile>would be great to get more processing - then I can nudge more people to regularly merge their branches ;-)) <cbaines>futurile, moving would be easiest, there's the possibility of spreading things across multiple machines but that's not something that I've attempted yet <civodul>it’s a bummer that qa.guix hasn’t been able to build patches for weeks <rekado>ACTION sends email to the sysadmins <futurile>cbaines, rekado: OK, so who's sending an email to sysadmins? heh <civodul>if we go that route, we can take a couple more x86_64 MDC machines and move them to qa.guix, too <civodul>but we should consider the MDC machines as gone within a year or two, as discussed in June <rekado>there are no plans to remove them, but it would be good to avoid getting tied even more closely to the MDC data center. <rekado>in the long term we should find alternatives <civodul>right, they’ll stop working at some point, the MDC might want to make space in its data center, etc. <futurile>we really need a long-term sponsor, and/or some way of buying services - which means having banking that works etc etc <efraim>As we discussed at FOSDEM last year, I'm still not hearing a better idea than a Guix castle with a build machine dungeon <civodul>futurile: one thing i’d like is to make sure we have something new to show/discuss at the Guix Days <civodul>i don’t want to rehash the governance, release, build farm, Foundation discussions just to realize we haven’t moved <futurile>civodul: yeah makes sense. I've reviewed a bunch of projects (that are 'like' us) and how they made decisions. I'm going to send that after the survey finishes. <futurile>and I have a proposal - to be written up - on how to bootstrap where we are to using a process. Because actually I think mostly people "in" the project know we need "a" process, it's probably not that important what it is initially - but we have to bootstrap to something - and can iterate from there <civodul>yes, i think we should not try to come up with the “perfect” thing on the first attempt <civodul>it should be easy to improve on what we have :-) so let’s do the simple things first <futurile>oh you think a bunch of geeks will try to wordsmith or design a perfect imaginery world? ;-) <unmush>I've managed to bootstrap mono up to the latest release, 6.12.0.206, but I'm at a bit of a loss as to how to proceed from there. This is because, to put it bluntly, the msbuild world is utterly resistant to packaging. I haven't managed to bootstrap msbuild yet, so I've been using mono's xbuild, but everything I have tried so far has resulted in errors complaining about nuget packages missing, and often it will insist on trying to <unmush>download packages itself even when they are available both in MONO_PATH and MONO_GAC_PREFIX. Additionally, it seems to be widespread practice to bundle binaries in git repositories (mono itself is guilty of this) <unmush>it is apparently commonplace to instruct the build system to download and use specific versions of specific compilers, too <efraim>send the patches and save that for later :) <mccd>Is there a specific package I need to install to make libgcc accessible? I'm getting the error /tmp/go-build4194766676/b001/exe/main: error while loading shared libraries: libgcc_s.so.1 when running a go generate command. Not sure if the error is with go or guix <unmush>efraim: that's what I had in mind, but I'm trying to make it possible to remove #:tests? #f on the latest mono package before I send the patches, but mono has a external/xunit-binaries submodule... <efraim>does/did debian package mono? I often check them for things like forcing packaged versions of dependencies <unmush>it looks like debian sidesteps the xunit dependency by only testing the runtime <unmush>and I don't think I got an answer from the last time I asked, so I'll ask again: do we still want one-patch-per-package when adding a big bootstrap sequence? <graywolf>Hello :) I know that we have a "guix binary" for a download described as "Self-contained tarball providing binaries for Guix and its dependencies, to be installed on top of your Linux-based system.". How is it created? Is that just literally `guix pack -R guix`? Or is there some special command to build it? <graywolf>Good to know. Looking at the installer script, there is no way to feed it custom binary, correct? So I will have to follow the manual installation steps. <jlicht>graywolf: the setsid makes the shepherd-managed-processes linger for me after logout (and logging in yet again eads to all daemons running multiple times), so it might not (yet) be exactly what we are looking for <ekaitz>so yeah, it looks like we have a new committer now <ekaitz>civodul: efraim just suggested me to become a guile commiter too haha but we have to go step by step <civodul>for lightening, it would make a lot of sense <ekaitz>yeah... but lightening is maintained in a separate repo... isn't it? <ekaitz>and the rest of it... i should try, but also I'm not a very seasoned schemer either so we'll go slowly <civodul>many patches are against libguile, which is mostly C <ekaitz>yep, that's the the language i know best idk why <civodul>it’s still the one one has to know at some point :-) <ekaitz>i'll think about guile commit access, now you made me think <ekaitz>ACTION thinks about how much he enjoys life <civodul>for Guile we should write down rules regarding what goes where, API/ABI stability requirements, etc. <civodul>so that new people can come in and review + apply patches <ekaitz>also i don't think the commit access request is documented... <jlicht>futurile: for ekaits to review/commit :P? <futurile>jlicht: totally - got a big pile right here - let-me-see-how-do-I-grab-all-patches-from-debbugs-and-export <divya>Hello, I recently got a new PC build using Ryzen 7 5700G on a MSI B550M-A Pro motherboard. I tried installing Guix using my own configuration, and it did get installed but the login greeter didn't appear only an underscore kept blinkimg. I tried other TTYs and could login but no graphics, even though I did install xf86-video-amdgpu system-wide. After a few times of failing this, I tried to do the <divya>graphical installation umand default configuration which has now got me stuck in the same login screen after installation, althougj in a different way, <ekaitz>futurile: remember i'm still a human being, and I have limits <efraim>that's exactly the type of thing a robot would say <futurile>ekaitz: pfffh you're a code athlete, limits are to be surpassed! <ekaitz>true, also i have some of my own patches on the queue... :) <futurile>heh heh - typical, you've only been a committer for 10 seconds and I already can't get you to review my patches ;-PPPP <ekaitz>we all laugh now, but wait until i screw up when committing things <jlicht>ACTION will watch your career with great interest <futurile>divya: I don't know about that error; but since you said it was new hardware, have you tried any other Linux distro on it - in case there's a hardware thing going on? <efraim>its a 5700G? is the G for on-chip graphics? <ieure>divya, Not sure what your image is, there are no errors in that. <divya>futurile: Indeed in my last 5 hours of repeatedly trying to reinstall distros. I got Arch installed, and it booted fine. <divya>efraim: Indeed. it's for integrated graphics <ieure>I have a machine with Ryzen 5850U and built-in graphics, it gave me a GUI out of the box. <divya>ieure: The image shows that when trying to login, Guix just gets stuck there. It doesn't do anything and I can't switch TTYs. <divya>Trying to reinstall again, let's see. <divya>ieure: What exactly does the argument do? <ieure>divya, The second stops the wrong CPU frequency scaling driver from loading, which prevents the better one from working. <futurile>mentioning robots I think Wilko Meyer is a robot army or something - they've sent 704 patches! <divya>Another new installation got stuck again, ugh. <divya>Added nomodeset to the GRUB argument <divya>No idea why this happened though <unmush>off-topic public service announcement: C-u C-SPC in emacs is the best thing since sliced bread. <old>unmush: nice I did not know. Now I can jump back to my mark after kill-ring-save it <unmush>it's especially nice in combination with the mark-saving that isearch does automatically <csantosb>unmush: I confirm, I could not live without C-u C-SPC, that I discovered recently after 10 years of emacs <csantosb>I wonder how many of these gems still around ... <graywolf>To what degree should I am to make a new configuration type I am writing type safe? While the configuration infrastructure *can* express it, I do not look forward to generating many types in the spirit of float-0-to-100, float-0-to-1000, inf-or-int-0-2147483647 etc. <ieure>graywolf, Use your judgement. I don't think there's a hard and fast rule about this. On the one hand, as you mention, it's a good amount of work to define all these predicates; on the other hand, you don't want to generate a config file a program will reject. <ieure>graywolf, If you do define more precise types, I'd recommend that you make them more semantic than `float-0-to-100'. You want it to describe how it's used over what it is. <ieure>(This is just my personal opinion) <ieure>Or perhaps "what it is, in context." So if you had, say, a type for the sound level in an audio subsystem, I'd call that `volume-percent' over `float-0-to-100'. <graywolf>Hm I am not sure I agree. If I see in documentation that (wayland-edge-pixels-pointer) should be set to int-0-to-2147483647 type, that tells me more than the fact that (wayland-edge-pixels-pointer) should satisfy type/wayland-edge-pixels-pointer or whatever I would call it. <lechner>or should that be the name or the variable? <ieure>Well, I... don't agree with that prior art. :) <graywolf>Arguably having type per field would make the code generation easier I guess <graywolf>Geez this well be my biggest guix patch yet. I pity the poor soul would will review the diff adding those few thousand lines. <ieure>Since the predicates are just procedures, you can readily alias and compose them. ex (define (int-32bit-unsigned? x) (and (int? x) (pos? x))) (define wayland-edge-pixel-pointer int-0-to-2147483647) <ieure>(Yes I know int-32bit-unsigned? isn't right) <futurile>OK, so we have about 700 responses to the Guix User/Contributor survey. I've emailed the majority/many of people the people who have sent patches in the last two years to make them aware of it. I guess I'll leave it up until the end of this week. So IF you haven't take it yet .... *now* is the time! <ieure>I did it the day it launched. :) <futurile>also now I have to go through 700 sets of comments heh heh heh <fear> <civodul>how’s the user/contributor ratio among respondents? <futurile>I've emailed about 300 people individually who contributed patches to Guix over the last two years, a few more to go so we'll get more contributors I hope <futurile>civodul: we had 229 people say they're contributors; and 43 previous contributors - so far <futurile>so I think that's pretty good - it looks like we get between 80-100 'new' contributors a year - determined by a person sending a patch for the first time <csantosb>futurile: according to your email, 76 patches in 2023 by yours truly 🤔 ... seems a lot to me <rynn>A new committer (congrats ekaitz!) and Guix-Hurd in the same week? Quite the good week for GNU/Guix. <futurile>csantosb: it's not fully correct in the sense that if you send from two different email addresses it doesn't know that <csantosb>futurile: Wow, I was not aware of that ... thanks for the survey, anyway ! <civodul>futurile: oh, so it did reach lots of users-not-contributors people, nic! <futurile>csantosb: that puts you up portion of contributors for the last two years for sure - basically a lot of people send 1-5 patches; anything over 25 a year is significant - unless you are called Wilko Meyer who is some sort of robot patch monster machine :-) <futurile>csantosb: "upper portion" I meant to say <futurile>civodul: yeah I think the user list, and attention a "few" times on Mastodon definitely helped - weekends for sure. <futurile>didn't manage to get it onto LWN, Hackers News or Lobste.rs etc which was a bit disappointing, but maybe next time <futurile>I'm sure we will have missed lots of users still - always they way - but we've got a good collection of views and experiences I reckong <csantosb>futurile: most of them are trivial updates, emacs packages and the like; Wilko deserves heaven/hell for his achievements 🥴 <efraim>not gonna lie, I was looking for the 1000+ option for number of patches <csantosb>futurile: the survey message is in Lobste.rs too ? <unmush>at what point is it okay to just stop keeping track of which subdirectories go with which licenses and just say "here's a bag of 12 licenses, figure it out"? <futurile>efraim: hah hah - yeah if we had your number the rest of the bar graph would be teeny! <futurile>csantosb: no I couldn't get anyone interested to post it to lobste.rs (you're not supposed to post your own stuff), I tried asking on their channel but didn't get any response <unmush>also is there a particular license in (guix licenses) for "GPL with class-path exception"? <csantosb>futurile: this is not my own stuff, so there it is now <podiki>anyone familiar with managing keyrings for a channel? <podiki>when trying to push a new key it fails as trying to do guix git authenticate says the commit isn't a decendent of the channel's introductory commit <podiki>which seems fine right, since it is a different branch? <graywolf>podiki: you can verify using git merge-base --is-ancestor <podiki>isn't the point of keyring being an orphan branch to disconnect from main branch? though this was pre-guix git authenticate i think? <csantosb>As an aside note, the long lasting broken guix image on sr.ht build machinery should be alive again tonight <graywolf>Ooh you mean pushing the keyring branch itself? <anemofilia>Do someone here know why shepherd fails to build when using the shepherd channel, but builds sucessfully when I -L my local copy of it? <graywolf>Yeah I tend to get the warning for it as well, always wanted to look into that but never got to it <podiki>graywolf: i assume it would be fine, but i guess it is running as a pre-push hook so i can't push. but don't want to change this for the repo in general. i can change it back but wondering if i'm missing something obvious <hapst3r>how do you guys use the treesitter-modes of major-modes such as yaml-ts-mode (as opposed to yaml-mode)? <podiki>i guess git push --no-verify should skip the hook <Rutherther>hapst3r: could you elaborate on what you want to know about the ts modes? <noe>futurile: why not advertise the survey in etc/news.scm? <futurile>noe: honestly the answer is I didn't think of it <futurile>yeah, it's too short if I'm taking it down on Sunday <ieure>I don't know if you're planning one for next year... but doing it on some kind of regular schedule seems like a possibly good idea. <futurile>I guess it depends on how useful and how much work overall it is heh <jonsger>futurile: how many replies do we have currently? <maximed-web>For the guix survey, do v2 patches count, and if it's a lot of 'do thing small change, repeat for every relevant package' patches, do they count separately ? <futurile>jonsger: yeah, just on 700 in total, ~370 user and ~229 contributor <futurile>maximed-web: I think v2 patches count, it's more a general sense of have you sent 5 or 500 patches :-) <maximed-web>even without v2 I reach 100+ patches (especially if the repair shop didn't take their sweet time), but that's akin to salami slicing (except not really, since they are grouped together and there is no ranking-by-patch-count) <maximed-web>so, it might be a bit misleading to report it that way <ieure>Gonna count not only every patch version but each patch in a series. More lines of code is better, right? <makx>finally crcked and took the survey. was bored enough on this train <futurile>makx: thanks, appreciate it - and hope it kept the train boredom at bay a bit :-) <podiki>futurile: we could still add a news entry, sunday is ~5 days from now <look>Hi, I have something thats bothering me in my cuirass configuration for a while, a bit of a nitpick. I'm trying to use a channel (defined as a variable) inside the %cuirass-specs g-exp, but its not working: https://paste.debian.net/1336980/ <look>Any help would be appreciated :) <podiki>comments welcome, will push later today <gabber>how do we declare a package being specific for a certain architecture? <rekado>podiki: news items have no expiry. Someone upgrading 6 months from now will get this news entry without a reference date. Perhaps it would be good to include the year. <podiki>rekado: oh good point. though i guess we could always remove a news entry? what happens then? <gabber>is the #:target #f flag the indication that cross compilation wouldn't work for a package? <csantosb>podiki: not sure news is the best place for ephemeral announcements, think emacs' news <noe>How do I use my local checkout of guile with guix? I want to build guix-qa-frontpage with it, so I guix shell -D for the dependencies but it says incompatible bytecode version :/ <noe>Same thing: if I modify a guile dependency of guix-qa-frontpage, say guix-data-service, how do I use the local version of guix-data-service with my local version of guix-qa-frontpage ? <gabber>i am trying out mumi to make some patch reviews but mumi fails applying patches: "error: cannot convert from y to UTF-8". can i resolve this manually? <gabber>can i apply the patches in the series by hand somehow? <noe>gabber: what I do is download them using the download icon on issues.guix.gnu.org then use “git am ~/Downloads/XXXX.mbox” <gabber>i just found the line in the patch where it says "charset=y" (: <noe>I saw this happen multiple times and I wonder if its from people saying y when git format-patch asks for the format <gabber>to your question: what exactly are you trying to do? replace the guile dependency of a single package or use some other version of guile for all of guix? <gabber>noe: this could very well be the case <noe>Replace the guile dependency, but ideally without rebuilding it all because it takes ages <noe>I found a hacky solution: “../qa-frontpage/pre-inst-env ./meta/guile ../qa-frontpage/scripts/guix-qa-frontpage” <noe>now if I want to use a local guix-data-service I don’t know what I’m going to do <noe>also this command is inside two guix shells already <gabber>is this undocumented wizardry or have i just overlooked that wonderful thing in the docs? <janneke>while attempting a fresh install, acl fails to build: linking *-polkit-1 ... operation not permitted <noe>ekaitz: congrats on the commit access! your work on risc-v is impressive