IRC channel logs
2023-04-23.log
back to list of logs
<TristanCottam[m]>Hi guys! I'm creating a package for a Minetest mod which is forked from another one, but kept the same name as the original. Should I name both packages the same? How should I distinguish the fork's package variable from the original's? <bjc>i'd say if it's a distinct package, it should be named with the name of the fork in it <bjc>it doesn't have a community name? like foo-authorname? <TristanCottam[m]>I thought about appending the fork author's username to the package name, but it doesn't feel right <TristanCottam[m]>bjc: No, the fork is only available as part of a modpack, and uses the exact same name. <bjc>maybe use the modpack along with the base mod name, then? <podiki[m]>sounds like you get one of the joys of computing: figuring out what to name something :-) <bjc>it can always be renamed later, and aliases set up so people don't break their configs <podiki[m]>is it the case that the original is abandoned? then you can switch the source to this one and note it in commit and package def that it is a maintained fork <TristanCottam[m]>bjc: I thought about that, something like `minetest-compost-techage` (rather than `minetest-techage-compost`, which sounds more like a variant of `minetest-techage`). <bjc>if ‘techage’ is the name of the modpack, i'd go with the latter, so that you get more specific as you traverse the names from left to right <bjc>minetest has techage has compost <TristanCottam[m]>On a side note, what version should I give to git-version when the project doesn't have a single tagged release? <bjc>TristanCottam[m]: there are examples around the packages, but istr it being base-version+commitid <bjc>like if there's a version 0.8 before the commit 12345, you could use the version 0.9+12345 <bjc>but i'd poke through existing packages first to verify that. come to think of it, there may be documentation about this scenario that i've forgotten about <bjc>man, crates-io.scm is 75,000 lines long. it takes forever to compile <TristanCottam[m]>What I do is use `git-version`, which formats the version number, revision, and commit accordingly. But what should I do when there aren't any tagged releases in the project's repository? What should I specify as the version number? I thought of either `"0"` or `""`, but I don't know if there's any standard way of doing this. <TristanCottam[m]>I'll look for existing packages which deal with the same situation, thanks for your time! <apteryx>ACTION is getting closer to have a nice solution to the etc/teams.scm issue in #58813 <bjc>i found a second web server framework inside my terminal emulator <spiderbit>hmm wanted to ask why I can't load a stumpwm but found the solution since I logged in here <spiderbit>the load-module does not work for whatever reason but the latter does <spiderbit>I notice that not all stumpwm contrib modules are packaged <spiderbit>especially swm-clim-message looks interesting <spiderbit>sbcl-mcclim is packaged which should be the only dependency needed but whatever not so important yet can download and load it manually <jgart[m]>spiderbit: feel free to send a patch for the missing stuff <spiderbit>jgart[m] not yet there need to be more advanced in using guix first <spiderbit>I am also a clisp noob, my strength is so far emacs-lisp <spiderbit>I barely have now a somewhat ok system after burning nearly everything down I used before at the same time exwm -> stumpwm, nixos -> guixsd, I still fight to get a good emacs-buffer-list replacement in stumpwm and other problems. <spiderbit>ok so stumpwm kind of uses fuzzy search but you need to do spaces where you want to jump to some other place in the match <spiderbit>ordoflammae[m] kind of did that but it's a hack and not perfect <ordoflammae[m]>Wdym it's a hack? It seems like that's exactly what those programs are intended for. <spiderbit>well I had the same problem with matching in rofi I have now in direct stumpwm <jgart[m]>If not it is a bug somewhere. It looks like the Guix package includes all the dependencies. <spiderbit>well I tried different approaches... don't remember exactly what the problem with the normal rofi list was <ordoflammae[m]><spiderbit> "ok so stumpwm kind of uses fuzzy..." <- Ah, I see, sorry, I was misunderstanding. I actually like that form of searching. <ordoflammae[m]>Now, what would be cool would be to get emacs to communicate with stumpwm to seamlessly switch between windows in Stump and buffers in Emacs. <spiderbit>it does not give me enough control I think to use normal -show window <spiderbit> there is still a problem, because the window titel are extremly long it finds multiple matches even for long substrings. Can I limit the characters per Colums or in this case the title so instead of {w} {t} something like {w}:10 {t}:20 or so. <spiderbit><- the author said that is niche so I need to make a custom list <spiderbit>but I need to sort the list differently and I wonder if the default in stumpwm let's me not do that more easy <spiderbit>heck this can't even switch between 2 entries that have the same title <spiderbit>so let's say class firefox, title youtube.com <spiderbit>exwm solves that by just adding some modification I think it would be just a (2) behind the name <spiderbit>stumpwm puts by default pull-from-windowlist a number before the matches <spiderbit>but it's another layer so probably harder to code to my likings <spiderbit>also rofi as it is can't differenciate between last visible window and last invisible window <spiderbit>so instead of switching back on a tile between 2 windows <spiderbit>it switches places with the other one if I used it before <jgart[m]>Should we include them all in the vis package closure? <apteryx>yay, 'git config sendemail.headerCmd etc/teams.scm cc-members-header-cmd' with my modified git, and now it adds X-Debbugs-Cc transparently <apteryx>that's going to help notifying teams painlessly <ChocolettePalett>That's crazy: guix installer can't establish internet connection, but I can ping everything from tty2 using ping..... <apteryx>there's some file you can touch to placate it when such issue occur <dust88>Does conda work in Guix destro ? <dust88>When I run programme in conda env I get "No such file or directory". <jgart[m]>Should guix search be able to filter the query to only search in a particular channel that you are subscribed to? <jgart[m]>For example, what if I am subscribed to five guix channels and I want to search in only two of the 5 channels? <jgart[m]>How should the guix search and channels.scm API accommodate this? <jgart[m]>By channels I mean guix/channels.scm and maybe guix/discovery.scm as well. <bjc>oh my god. alacritty built <jgart[m]>We are thinking about implementing this feature for toys to have better filtered search with filter keywords but it might be cool to have this supported in a simple way from the Guix API itself: https://toys.whereis.みんな/ <jgart[m]>bjc: What version of alacritty did you build? <bjc>the one that works with core-updates sway <bjc>i'm about to install it and see if it actually works <bjc>thread 'main' panicked at 'internal error: entered unreachable code', /tmp/guix-build-alacritty-0.12.0.drv-0/source/guix-vendor/rust-winit-0.28.3.tar.gz/src/platform_impl/linux/wayland/window/mod.rs:333:77 <bjc>oh well, i knew i had more to do anyway, but hopefully the end is in sight <bjc>it does work as an x client, just not wayland, so that narrows it down some <bjc>my diff is almost 5k lines right now <podiki[m]>late night pull to core-updates and reconfigure....why not :) <jgart[m]>everyone that successfully gets the latest release version of a rust end-user program merged into GNU Guix should get a medal of honor <podiki[m]>well that was easy (helped that i built all my profiles and system before switching) <podiki[m]>though not updating all user profiles at same time caused some reboot hangs or I was impatient <podiki[m]>and now a couple of fonts look different...not sure why <spiderbit>ok that took me longer than hoped but I added numbers to windows with the same name with rofi :) <spiderbit>my nice elisp (concat) -> (concatenate 'string ...) <spiderbit>that is not optimal code, again I am a clisp noob <jgart[m]>spiderbit: that prints all your window info to stdout? <jgart[m]>or the window info you're querying for from xwin-to-window <ChocolettePalett>Okay, so my building of something failed during Guix installation process. What should I look for in the logs? <ChocolettePalett>No, I'm installing Guix System, and the build after guix system init... failed <lilyp>did you correctly set up the cow-store etc.? <jgart[m]>ChocolettePalette: Can you paste the complete fail log over HTTP? <andreas-e>podiki[m]: Congratulations on your up to date system :-) I also noticed a different font for one of my users. <jpoiret>great, firefox failed to build during the night because ENOSPACE :( <jpoiret>i think i can live without ykman for a bit, so i'll reconfigure after that <jpoiret>ah damn, I guess this is for the next glibc update then, but that's pretty rough <andreas-e>jpoiret: I have it, but it is in the :static output of glibc. <jpoiret>no, you should only have librt.so.1 in the glibc 2.35 <jpoiret>meaning we can't link against librt with only :out <jpoiret>all of librt's functionality is now provided by libc.so, which is why it's still left as a stub to keep compatibility with linking scripts. <jpoiret>there are a couple of libraries like this, and someone decided to keep the empty .a in out in that case (since yes, they don't weigh anything so might as well include them). This way, you can statically link librt and thus not have it refer to the empty .so file <PurpleSym>andreas-e: That’s indeed good news regarding GHC 8.10 on i686 – although I have no idea *why* the patch works. I didn’t test with 9.2 yet, that’s something for today 😉 <PurpleSym>(Only explanation so far: Python’s regex engine is broken on i686.) <jpoiret>So apparently i need more than 13G to build firefox. This is a joke. <jpoiret>I don't want to go back to icecat but looks like i'll have to <atka>jpoiret: you might be able to use zram to compile <jpoiret>I don't want to guix GC the rest, nor spend 1h30 again just for it to fail <andreas-e>PurpleSym: Feel free to push a first patch for ghc@8.10, then it would already be available on the build farm for the next step. <PurpleSym>andreas-e: I’ll move it into a snippet and push it later. <jpoiret>Reconfiguring right now, some sacrifices had to be made <ekaitz>hi! how do you run the tests of the guix codebase? I found a small bug and I want to report it properly <andreas-e>jpoiret: It looks like you are back. So everything went well? <jpoiret>andreas-e: not really, but that's more related to icecat <jpoiret>I can't get by bitwarden extension working <minima>hi, i recently started noticing a problem with emacs and guix where newly installed emacs packages don't get picked up by existing emacs instances; i think someone mentioned the fact that emacs path makes use of separate subfolders now and that this might get in the way of the path being correctly refreshed on running instances? <minima>not sure whether i got that right by the way <jpoiret>looks like i'll have to build firefox myself today then <minima>i've been looking at git logs for 'guix/build/emacs-build-system.scm' and the MLs; i see there's been some discussion around this in the past couple of years <minima>i suppose those are the places to start from <minima>*picked up = already running emacs sessions don't seem to be able to see/load the new package <_jdb>I am running Guix system in a virtual machine and want to share mounts from my host to the guest Guix system using the `-virtfs` qemu option. <_jdb>I noticed that during a `guix system reconfigure`, the build attempts to `stat` the `device` path specified for the `9p` `type` file system. As far as I'm aware, there isn't a file for this kind of mount that exists in the file system? I can work around it by using a relative path as the `device` path and ensuring that the directory exists relative <_jdb>to the invocation of `guix system reconfigure` but I'm wondering if the `stat` is intended? <PotentialUser-34>Hi, I have noticed the mesa version available in Guix is quite old. Is there a packaging effort already underway to get a recent one ? If not, do you think this could be done by a beginner like myself ? <jpoiret>PotentialUser-34: newer mesa will drop this week if everything goes well <PotentialUser-34>Great news ! Thanks. Where can I look to check for such things ? (upcoming packages in general) <jpoiret>the mailing lists are a good place to check <jpoiret>it's been slated for inclusion in core-updates because it's such a big change (causes a lot of rebuilds) <jpoiret>seems like c-u is working properly on my machine <jpoiret>now that i have firefox working and not icecat, that is :) <jpoiret>anyone know if the rust-team is planning to work on antioxydant? <bjc>icecat is broken for you? <jpoiret>yeah, but that's because i use a bunch of extensions. Notably, I couldn't get the bitwarden extension to work <jpoiret>could be nice if we could switch to eg librewolf instead <jpoiret>not to fault the icecat developers, but keeping up with upstream requires a tremendous amount of work unfortunately <bjc>i can imagine. just doing alacritty has made me crazy <ekaitz>andreas-e: is there any simple way to only launch the test I want? <ekaitz>I tried with make check TEST_NAME but it didn't work <lfam>make check TESTS=tests/guix-pack-relocatable.sh <jpoiret>the 6k lines of per-package modifications is ... something else <AwesomeAdam54321>I needed to cut dependency cycles in Rust packages, update a patch for rust-trybuild and now it works <efraim>AFAIK I have alacritty-0.12 working on the rust-team branch <efraim>now I'm going through my ~4000 lines of diff to see what to keep and what to toss <bjc>does it work in wayland? <bjc>and i wish we could have coordinated, because i just got it building last night, too, so it feels like a lot of effort was wasted =/ <efraim>I'm running sway, so I assume so <andreas-e>ekaitz: This may depend on the exact setup of the tests in the package. Sometimes it is enough to do a "make check" for recompilation (which you can stop as soon as the tests start to be executed), then "cd tests" and run the test you want, which is simply an ELF binary. <jpoiret>if so, we could maybe resurrect the effort <jpoiret>let's wait until the rust team successfully merges their branch though, after c-u <AwesomeAdam54321>jpoiret: Yes, after using rust-1.65 in antioxidant I'm expecting that rust-arbitrary now builds <jpoiret>bjc: btw, I would suggest foot as a good replacement :p it has practically no dependencies <bjc>i switched to foot yesterday, actually <bjc>what all that work on alacritty mostly did was convince me that i never want to use alacritty again <bjc>did you know there's (at least) two web server frameworks in its dependency tree? and a library that has a "friendly warning" that it may start network listeners when your application starts? <AwesomeAdam54321>bjc: I'm mostly bewildered how two web server frameworks even made it in there <bjc>it's rust. everything is in there <lfam>Is there a comfortable way to download a big patch series as a single file? <lfam>Or, what's the easiest way to apply a big patch series that doesn't require installing any packages <ngz>efraim: Is there by any chance a documented process on how to package for Rust nowadays (assuming it has changed since the Rust team creation)? <bjc>cargo is like a modern lisp machine, where everything is a giant ball of interconnected state/crates, and you pass around programs by sending memory dumps <bjc>though, in this case, the memory dump is just a complete archive of crates.io <efraim>ngz: no real change in how the packaging works. Once core-updates is done we should have a faster turn around on updates though since most of rust is self contained <ngz>efraim: Could you explain what you do mean by "Rust is self contained"? I don't understand how it relates to "having a faster turn around on updates". <lfam>efraim: Is Rust still a lowish-level dependency via librsvg? <lfam>mirai: Does the package not have a configure script, nor a test suite? <lfam>mirai: In general, these phase deletions should have some explanation <mirai>it doesn't have a ./configure script <mirai>the makefile looks hand crafted <mirai>*supposedly* it declares a .PHONY test target <mirai>but there's no definition of it anywhere <mirai>nope, the tests are a relic in the Makefile <mirai>lfam: I think the comments could be added by committer in this case (rather than issue yet one more ML roundtrip to what amounts to 3 comment lines for a 2021 submission) <lfam>But, in the future, please remember to address these issues <mirai>but thanks for the reminder! <mirai>I've completely forgot about that part 😅 <lfam>mirai: Of course, the patch doesn't apply <mirai>lfam: it's the copyright header <mirai>ah, the patches weren't sent with a prefix <mirai>I linked specifically to the latest one (reply #7) <jpoiret>thanks! I'm running on c-u right now :) <jpoiret>no problems for me, apart from ykman missing <civodul>i'm attempting to fix Jupyter, but it's a whole bunch of Python <mirai>are maven apps buildable with guix? <apteryx>ACTION is nearly done fixing up teams.scm to notify automatically via git send-email <mirai>ACTION would like a ./teams.scm who-maintains <path-to-file> command instead of having to format-patch and do get-maintainer 0000-....patch <lfam>Personally, if I start getting a lot of emails sent directly to me asking for help, I will remove myself from all teams <lfam>It sounds like too much for a volunteer <mirai>I've been hesitant on creating and adding myself to some teams since that'd invariably mean lots of inbound mail <mirai>coupled with the fact that I haven't settled on a way to organize my mail yet (it's all on inbox! atm) <lfam>I already get hundreds of Guix emails a day. But since they are not personally addressed to me, I have no problem ignoring them <mirai>but I thought on setting some regex rules in thunderbird to tag interesting mails received through yhetil NNTP gateway <lfam>Teams and more organization is still a good idea <apteryx>you can now just use 'git send-email' and forget about the minutiae <apteryx>just make sure to run 'etc/teams.scm configure-git' once <bjc>what happened to tasty-sandwich? <bjc>i miss the links to issues <mirai>bjc: I haven't seen lechner for a while <jgart[m]>lfam: The issue is that we are all volunteers including people without commit access but we depend on people with commit access to merge our patches. If a good majority of people with commit access are only interested in working on their own patches 95% or greater of their volunteer time then it becomes very difficult for others without commit access to contribute to GNU Guix in an efficient manner because there is not enough review pipeline. This <jgart[m]>also burdens other people with commit access who are actually doing the bulk of the review work while others only work on what they are interested in which is not patch review. And not everyone without commit access gets the same attention to their patches being reviewed equally by people with commit access. Some just get left to the wayside because people want to only review patches by people they know or work on their own stuff and not review. <mirai>though he's still occasionally posting on the MLs so I guess a lack of time perhaps? <jgart[m]>On top of that, the manual has a premature note actively discouraging applying for commit access due to the project moving towards an improved automated patch review that will probably not arrive at a level needed to remedy the above problem within a projected ETA: <jgart[m]>> However, note that the project is working towards a more automated patch review and merging system, which, as a consequence, may lead us to have fewer people with commit access to the main repository. Stay tuned! <jgart[m]>I think that the manual should not mention that discouraging note until the automated patch review is in place at a level that does not still require people to actively apply for commit access because patch review is too slow in their areas of contribution interest. <ngz>jgart[m]: I always found this last sentence odd. But, frankly, I think it is a good thing that not every committer is spending their time on patch review. Reviewing is very important, but it's only a part of the tasks that needs to be done for the Guix project to move one. <bjc>in its current state, the project needs more committers. probably a lot more. there are so many patches languishing <mirai>ngz: what are the other tasks? <mirai>my unimaginative mind tells me that guix moves forward by… patches? whether they come from committers or not <ngz>mirai: Of course. But jgart[m] is talking about committers only looking at their own patches. It's necessary somehow. <AwesomeAdam54321>mirai: The problem is that there are lots of patches but not enough people to review and commit them <lfam>jgart[m]: The reality is that people need to be compensated for the level of work required <mirai>bjc: the moment when you write a patch and find out that someone wrote something similar years ago but was never merged 🙃 <lfam>Most of us have to work for a living and thus can only contribute a small amount of time <lfam>It's not an easy problem to solve. How does the project grow large enough to attract funding? I don't know <bjc>mirai: i submitted a patch for core-updates that fixed a broken build. someone else patched it separately a day or two ago. my patch is still open <bjc>there's a bigger problem here and it's debbugs <bjc>that wasted my time and someone else's because my patch wasn't even looked at <lfam>There's also an unspoken expectation that every patch must be reviewed and eventually accepted, which I think stands to be examined <jpoiret>also, the impression that committers only work on their own stuff 95% of the time is quite biased: more often than not that 95% of the work is very important work <mirai>the thing about committers is that it's something that can be just bought or hired on demand <lfam>But, having said that, we should still institute teams and continue building around them. It could have a big impact <jgart[m]>I don't think that is an expectation. Patches can easily be denied for obvious reasons where it makes sense to. <ngz>bjc: c-u works is pretty intense these days, so, unfortunately, I think this is bound to happen. Note that you can close your bug. <jpoiret>the committers who have been working on staging/core-updates have sunk a ginormous amount of time into it, work that doesn't "appear" to users often <mirai>because to be a committer involves learning quite a lot of how “guix” works which is very much “tribal knowledge” <jpoiret>i don't want to disparage any fellow users or contributors, but getting very niche packages into guix might not be the priority <lfam>Like, everyone involved knows that there is a big review backlog and it's a problem. But, what does that mean for committers? To what degree should we prioritize Guix over other things our lives? <mirai>busfactor.txt (I should update it soon as some points have been completed) <jgart[m]>jpoiret: I think that niche packages are perfect for channels <jpoiret>yes, I agree. But we still have way too many packages in Guix that maybe could be on channels instead <jgart[m]>Channels should be encouraged more and will help GNU Guix upstream if used correctly. <jpoiret>but like lfam mentioned, i hope that the move to teams and feature branches will help <jgart[m]>There's some pretty cool software that is also very niche <jgart[m]>It makes total sense for it to be in waggle <jpoiret>to be perfectly honest, one of the reasons I haven't applied for commit access yet is because of the expectations that are put on them <lfam>Well, as a committer, I can say there may be hopes for what we do, more than expectations <jgart[m]>jpoiret: What expectations are you referring to? <lfam>We are not badgering each other to do more owrk <jpoiret>expectations that the endless flow of patches will get reviewed eventually. Just thinking about it makes me anxious <jgart[m]>The bar is pretty low on expectations regarding patch review of others work ;() <mirai>jgart[m]: I'd rather not have the guix interpretation of NPM or cargo to be a part of the “common” guix setup in a few years forward <jgart[m]>In reality those expectations are not enforced actively so might not be a problem <mirai>provided the channels are kept at some “sane” level, sure <jgart[m]>unless they change the policy for people with commit access <mirai>but proliferating it to the point of cargo/npm = pls no <jpoiret>lfam: ah no, I didn't mean to say that committers are putting these expectations on others, but rather that there is an "ambiant" feeling of responsibility for the whole patch queue <lfam>Yes, that is true jpoiret. We all notice it and do what we can <jpoiret>it's not a complaint about committers by any means though! <lfam>We should probably start encouraging niche packages to go to channels instead. I don't think a distro needs every single program on Github to be successful. That's not what makes an operating system succeed <lfam>And when you compare Guix to similar projects (Linux comes to mind), a large number of Linux contributors are paid for their work <bjc>what about debian? that seems more analogous <jgart[m]>I think that Guix does not have enough active volunteers to package and continuously maintain "the world" as of today. <lfam>In Debian, reponsibility is extremely narrow. Each person only handles a few packages <lfam>Also, the pace of work is very slow in Debian <ngz>It's difficult to tell someone their package is too niche to be included in core. Also, someone interested in a given niche software may become a committer later. <lfam>For this reason, I don't think that Guix is comparable to Debian <jpoiret>lfam: also they don't necessarily have the same standards as we do regarding packaging <jpoiret>mirai: do *not* look at the number of open PRs on nixpkgs, please do not do this <ngz>Besides, channels are not properly advertized. It would mean much duplication in package definitions. <jgart[m]>I don't want to use Debian's old packages. <jpoiret>jgart[m]: Debian sid has very new packages <jgart[m]>We need to be able to filter our queries on a given channel <jpoiret>I think there's also another way to look at the situation: we could acknowledge that in the end, Guix is a project run by hobbyists mostly, and that it doesn't have the resources to chew on too much at once. <mirai>jpoiret: eeeh, “we're ~2.88x better than them regarding that, basing on the 1423 active bugs in guix-patches” 😂 <jpoiret>mirai: also, there is absolutely ZERO interaction on most PRs, just CI bot messages and then a Github merge notification, that's it <lfam>Yeah, jpoiret. I don't know if I agree or not with that, but we should remember that everyone involved thinks of their involvement in a different way <lfam>Some people just care about one package or one language, some people care about the Guix tool itself, some people care about GNOME, etc <jpoiret>lots of packages actually do not build reproducibly, just shell out to cargo/npm/whatever <lfam>It's hard to get people to do lots of work outside their area of interest <mirai>jpoiret: methinks that lowering the barrier/burdens on becoming acquainted with the codebase will lead to more committers being in the long run since it becomes “cheaper to train” a volunteer <lfam>Yeah, we should do whatever we can to help with that <jpoiret>mirai: right, but i don't think volunteers would suddenly appear anyways <lfam>Something I've noticed over the years is that a lot of contributors only care about a narrow scope, and basically tune out when you ask them to care about how their thing fits into the entire distro <lfam>It needs to be easier to grok the big picture <jpoiret>lfam: I wonder how other distros cope with that <jpoiret>i was exactly hoping for the teams system to help with this <lfam>I would look at Linux, again. I'm not sure anything else compares to Guix except for maybe Nix? <jpoiret>specifically: each team maintaining their own part of the documentation, explaining how their own stuff works <mirai>it's suggesting “do more work” to solve the problem of “too much work” but it makes sense, if we see it as an “investment” <lfam>Linux has strict hierarchical structure and strong guidelines for correctness <lfam>Guix always pushed correctness, but with a flat-ish structure. I think we've outgrown the structure <lfam>It remains to be seen if we can do it as a volunteer project <lfam>I'm optimistic. The good things about Guix are too good <jgart[m]>I think that we should be looking more for a middle ground between Michael Forney and their philosophy of package maintenance in oasis linux and striving for the Fitzcarraldean Debian package portfolio epic that we have stepped into <civodul>lfam: Rust seems to have done great work wrt. teams; Nix has some of that too <wdkrnls>Dear Guix, I am very thankful for all the amazing tools the community is making and providing for everyone for free to advance the cause of increasing the level of honesty in the world. <lfam>Is it a Herzog reference? <jpoiret>yeah, I'm very impressed by the rust team <lfam>Yes, we need to stop pulling the steamship over the mountain <jgart[m]>One way to do that is by focusing our package portfolio <lfam>I was just talking about Burden of Dreams yesterday. It may surpass Fitzcarraldo? <jpoiret>civodul: ah, you meant the team system that Rust has, not our rust team <jgart[m]>There's probably a better word. I don't want to sound like a stock trader <jgart[m]>Rust teams have "funding from God" though <wdkrnls>I want to get better up to speed with Guile so I can develop new Guix packages faster. <wdkrnls>I saw there was a Guix patch for integrating a Scheme LSP server into Emacs. <wdkrnls>I tried it, but could not get it to work. <jgart[m]>wdkrnls: Run away from that. There be dragons that won't help you <jpoiret>wdkrnls: if that's the LSP i'm thinking of, for guile it's basically just a wrapper around what geiser uses, ie. you can just use geiser for the same result <msavoritias>Pushing for channels more would also help the rebuild the world thing everytime a python package needs to be updated right? <jgart[m]>I recommend to start with the humble REPL and grep <mirai>unrelated but I think we should rethink of how the word “service“ is used in Guix, it's hair pulling how the term is used for shepherd services and … guix services? (which shepherd services are a also considered as one) <jpoiret>msavoritias: I don't think that would help much, packages deep in the dependency tree can't really be outsourced <jgart[m]>msavoritias: I think we need a "smaller Python world" or core Python <msavoritias>Yeah. Like if all the leaf applications werent there the rebuild would take less <wdkrnls>I am mainly looking for M-. (e.g. to view the source of a procedure at point). <jgart[m]>That is, the jupyter package vendors a ReacJS application in the Guix package <mirai>I'm not too enthusiastic about the idea of fracturing the package subsystem, the “to install some package X, add this random channel from the interwebs to your guix system” <jgart[m]>When do we allow that in a contributed patch and when not? <jgart[m]>The manual does not mention our reactjs policy <mirai>where X is some obscure package, with obscure being left open to interpretation <spiderbit>I am just slightly depressed that there is no alternative to TRAMP outside of emacs, and I am to stupid to somehow get the text from ido-find-file to show it in rofi :D <jgart[m]>mirai: I think we need to have a well defined scope for our package collection <spiderbit>mirai well it's the free software world? so there is already a limitation right? <jgart[m]>We will end up being in the maintenance burden position we are currently in always <lfam>Any neko / hashlink users around? <wdkrnls>The idea of increasing the level of beaurocracy in Guix proportionally to the number of leaf packages or on the compilation time of those leaf packages on a reference computer in Paris makes sense to me. <mirai>jgart[m]: I'm predicting that what ends up happening is parting from the mono repo approach but in the end the “curated”/official repos will still being maintained by the same crew so the net change is... negligible? <spiderbit>I think there is 2 ways either support the (free) "world" or support external package managers, right? <mirai>jgart[m]: I'm afraid that this is one of the questions à la Loki's wager <mirai>since someone could for the laughs, generate some kiloquantities of “useless/trivial“ packages and push for acceptance into guix <andreas-e>mirai: I am happy that we package the world ;-) <andreas-e>Maybe we need a bit less package entanglement. I think we have too many packages that cause world rebuilds. <lfam>I'm currently making it so that Apache HTTPD doesn't have thousands of dependents <mirai>but going to the opposite direction is also untenable, and the “middle” position being that the criteria for “non-triviality” of a package being nearly undefinable <andreas-e>Like that we recently noticed that valgrind is an input of lz4 is an input of subversion is needed for many texlive packages, as an input to R. <andreas-e>So valgrind being there, but breaking on powerpc kills all of R. <jpoiret>andreas-e: yes, this really is untenable <jpoiret>but this is something that once again creates yet more work. Guix contributors are basically fighting against the flow of the world here. <lfam>It's bad even just on x86_64 <jpoiret>developers don't care about their funny Go CLI app bringing in hundreds of dependent packages, all pinned to specific versions <msavoritias>Maybe we are just missing the tooling and the onboarding part <jgart[m]>I don't want to think about installing xclip when installing vis so that the system copy works... <lfam>Shouldn't the clipboard tools be provided at the system level? <andreas-e>I also think we need more volunteers, and more committers. <jgart[m]>msavoritias: 1+ to missing better tooling <jpoiret>msavoritias: onboarding certainly leaves something to be desired <ngz>so less patch review since time is not extensible :) <msavoritias>True. But lets not forget that guix is in its infancy <jpoiret>but as usual, better onboarding requires more work, work that takes time and coordination <andreas-e>ngz: By the way, thanks for all the patch review you do :) <lfam>Here's a mess. Currently Apache HTTPD has thousands of dependents, but literally zero of the packages that depend on it keep a run-time reference to it. <ngz>andreas-e: *blush* yw! <jpoiret>jgart[m]: yes, but that's work. No cheating! <mirai>lfam: you'd think that go, nodejs (and rust?) would perhaps consider making or expanding their standard libraries to include banalities like left-pad which end up being useful for many people <jpoiret>who writes documentation in their free time? <jgart[m]>But less so for Guix because of lack of time <msavoritias>I like writing docs. Hence me saying if there is a team ^^ <mirai>msavoritias: I have an interest in this topic <AwesomeAdam54321>msavoritias: there isn't one yet, but feel free to send a patch making one <lfam>mirai: It's not that I think the Go libraries are trivial, but rather that Go handles dependency management on its own, and most Go applications bundle all their source code in a way that would be easy for us to use, and with the correct versions <jgart[m]>jpoiret: pk is the documentation assistant <jpoiret>mirai: but they probably don't want to maintain a bloated stdlib either. The main problem is that there has been a growing disconnection between devs and distributions <bjc>rust, go, et al expanding their libraries wouldn't help that much, tbh. while a few packages get referenced a lot, the problem is that most packages aren't, there are just a *lot* of them and a culture of dependency maximization <lfam>Like, it's a self-inflicted injury if we don't use bundled dependencies of Go applicatoins <jgart[m]>ok I have to stop sh*tposting now til soon! <mirai>but I wouldn't claim that I'm a part of that team (even if it existed) <mirai>msavoritias: though I tend to take a look at documentation patches (or send them) <podiki[m]>lfam: I contributed neko/hashlink/haxe, though I haven't used it much so far <lfam>podiki[m]: It doesn't keep a run-time reference to the httpd used while building. I'm considering making it a native input and applying '#:disallowed-references (,httpd)'. That means that, if it needs to use httpd, it will have to be provided separately, by installing them alonside each other. Does that sound okay? Do you know if it actually uses httpd <lfam>I'm speaking of neko, specificallly <jgart[m]>Last thing I'll leave people with, do we have our current "milestones" or important goals listed somewhere that is not in some random thread on the mailing list? For example, if niche packages are not of the biggest priority, then what is? and where can new guix users who want to make high impact in the project quickly find the big goals in one place summarized? In other words, do we have onboarding docs to quickly aid with those bigger goals for <jgart[m]>Or is that tribal knowledge that will only be known after a lot of time put in (i.e. years) <mirai>guix services aside, my patches tend to either be doc fixes or tech debt reductions <reyman_aw>do you know if it's possible to chmod a folder into source origin block when packaging, i have problem with read only permission ? <jgart[m]>I think that the bus factor is real for guile <Grimpper>Hello. How do you guys manage to get MESON to find libraries that do not provide PKG-CONFIG files? <jgart[m]>might not be something to worry about currently ;() <reyman_aw>i use url-fetch to decompress a tar-gz, then i need to set some folder to 755 using chmod, i try (chmod "./quarto-cli-1.3.8" #o755) <mirai>but those are my views on the topic so a bias is expected :) <wdkrnls>For those random threads, it would seem like documenting how to search through them with public-inbox tools would be very helpful. I saw a random thread about that at one point. However, Guix has shown me how weak my e-mail foo is. <mirai>Grimpper: one way is to write the wrap files for these libraries (and put them on wrapdb while you're at it) <jgart[m]>also, the core thesis of guix is to use a real language. So, I think that improving the community around the real language should be high priority for us <lfam>reyman_aw: Take a look at the example in 'gnu/packages/nvi.scm'. Let us know if you need help finding it <jgart[m]>the real language that we have chosen, that is <bjc>this may be an unpopular opinion, but i think guile is guix' biggest weakness <bjc>not scheme, but guile specifically <lfam>reyman_aw: If you enter the 'gnu/packages' directory, you can find a few examples with `grep -rI -A15 snippet | less` and searching for 'chmod' <jgart[m]>bjc: Yes, not Scheme but Guile the implementation is our baby <bjc>guile is a hot mess and i have serious doubts it will ever be much better <Grimpper>@mirai: I've never seen what those wrap files are. Could you provide a reference where guix uses them for me to look into? <mirai>bjc: what's the problem with Guile as Scheme impl? <mirai>Grimpper: the wrap files are a meson thing <bjc>guile can't even give you a useful backtrace. it's awfut to work with <mirai>check their documentation and the wrapdb repo for examples <jgart[m]>It's impossible to do what we are doing today with any other Scheme implementation without putting in an obscene amount of hours to re-implement everything in another Scheme so ya, Guile <msavoritias>I have heard people refer to it as just an extension language <bjc>guile's documentation is largely very bad <mirai>bjc msavoritias : those are valid grievances, yes but I don't think they fully justify jettisoning Guile <bjc>i don't think guile necessarily can be punted, but i do think it's a big problem <mirai>would using Chicken or <your preferred alternative here> solve them? <bjc>have you tried mis-spelling ‘license:asl2.0’ as ‘license:apl2.0’ in a package definition? guile is actively harmful in trying to get error reasons out of it <jgart[m]>I said there's a bus factor risk in guile and also that we need to improve the community and documentation story around Guile. That's all I said. Those are two big elephants in the room to eventually deal with currently <mirai>jgart[m]: 'that' ? I've lost the context sorry <Grimpper>mirai : okay I see the wrap thing. Is there any other option? I'm packaging Hyperland. From what I see NIX is not using wrap files. My issue is with the udis86 dependency. I have it already packaged in GUIX but I don't understand how nix solves the dependency since it does not provide the pkg-config files. Does anyone know whats going on here (not <jgart[m]>I mean it all depends how long we expect Guix to be around which in turn depends on global warming as a superset of our Guix worries but GW is out of scope for this thought experiment <lfam>ACTION reboots successfully on core-updates <ngz>Grimpper: I think there already is a pending patch for hyperland (see bug#59434) <mirai>Grimpper: well, using wraps would solve the problem at its root (technically the root would be to get upstream library to ship a pkg-config file), be distro agnostic and reusable <jgart[m]>Has anyone used the mumi graphql API yet? <spiderbit>is there a reason, that there no gvfs-mount file installed with gvfs? <jgart[m]>Maybe I should write a blog post for Arun about using it or bug him more about it <jpoiret>i have tried, but the graphql implementation doesn't really follow the standard <jgart[m]>btw, if anyone has the time to review the ticket in the above kolam repl example it would be much appreciated: 62977 <mirai>lfam: unrelated but I've sent a patch that addresses a security issue with our nginx + php service (#62678) <jgart[m]>just a hash bump courtesy of guix refresh -u <Grimpper>ngz : excuse my dumbness but I cannot seem to find the issue you refer to. Could you paste the link? <jgart[m]>mirai: random question: have you used `guix deploy` with nginx to deploy your website somewhere? <mirai>jgart[m]: never used guix deploy, I've been using configure and either manually or scripted rsync transfers <jgart[m]>Should we standardize a deploy.scm file like we do for guix.scm and manifest.scm? <jgart[m]>So that we enter a directory with a deploy.scm and just run guix deploy and then it does the majic like guix shell does <jgart[m]>maybe we add a flag to specify the host IP we are deploying to <jgart[m]>I'm lazy like that and appreciate these type of features/CLI experiences <rekado>the machine record contains the host name <f3n1x>i do have 'kitty' terminal package listed in my guix home configuration. I can run 'kitty', fine. Now, for whatever reason, i would like to remove it. Why does guix says 'error: package 'kitty' not found in profile' ? thanks, thanks, thanks <rekado>f3n1x: “guix home” uses a manifest; you can’t use “guix remove”. <rekado>instead just reconfigure your home <jgart[m]>> the machine record contains the host name <jgart[m]>rekado: I know, why not put getopt in that machine record field and let it do it's thing? <jgart[m]>Does mumi's GraphQL API have a way to query for all failing package builds and their respective bad commit hash or should I be looking at cuirass's REST API? Or should I just RTFC? I'm tired at the moment of reading code... <f3n1x>I'm puzzled/stucked in this scenario: i have 'mybinary' package in the ~/.local/bin folder. .local/bin is in my user's PATH. Why does guix say 'command not found' when typing '$ mybinary ' ? What am i missing ? Thanks, thanks, thanks <efraim>ngz: sorry, I pop in and out. by 'rust is self contained' I mean that most of the packages covered by the rust team don't directly affect other packages so there shouldn't really be much breakage when things change. Just massive amounts of rebuilds <podiki[m]>lfam: I don't know but I trust you! I can try it out later and see (some packages there can be updated too) <f3n1x>jgart[m]: when i feel like tired of reading code then i tell myself thinks like "... umh, time to have a break? Let's have a walk ? " :D <jgart[m]>It requires a walk but maybe not complementary <jpoiret>f3n1x: what does `command -v mybinary` say? <ngz>efraim: Thank you for your answer. Is there any particular topic being focused on by the Rust team, or is it "just" about updating a large number of Rust libraries? I didn't look at the branch yet. <f3n1x>ACTION typo error, i was willing to say '/opt/' rather tha '~/.local/bin' ! <f3n1x>jpoiret: 'command -v hugo ' says, '/opt/hugo' <podiki[m]>lfam: looking again at neko, it is deprecated but still used (maybe just for libraries, haxe maybe doesn't actually need it to build?); so I think your change shouldn't be a problem? <PotentialUser-34> Sorry for noob question : how does one enable video codecs in Guix ? By default, I can read audio files just fine, but for video, I only get sound. I tried the naive option of running vlc with guix shell, to test making many packages available (like dav1d, libvpx, etc.) but it did not work. <mirai>PotentialUser-34: gst-pluging <mirai>there are various gst-plugins <mirai>about AV1 / AVIF, your luck can vary since some programs rely on shared-mime-info to figure out the MIME type and the decoder to use <mirai>and the shared-mime-info package in guix is outdated <mekeor[m]>hello. i've been using a local guix channel for quite some time. but i just realized, i could also just use the GUIX_PACKAGE_PATH variable instead. i would not need to 'guix pull' anymore, after changes to my custom packages. are there any serious disadvantages (of that env-var) i should consider? <rekado>channels are made with reproducibility in mind <rekado>GUIX_PACKAGE_PATH complicates this <mekeor[m]>i find typing -L all the time cumbersome. i guess, for my personal usage, reproducibility doesn't matter that much. thanks! i'll use the env var. :D <PotentialUser-34>As a follow-up on my video codec issue, it turns out video codecs are actually fine, I am lacking hardware decoding. Setting VLC to software decoding allows it to play video files correctly, but only as long as you don’t try to resize (video freezes if you do e.g. to make it fullscreen). <jpoiret>someone said vlc wasn't great recently <jpoiret>for hw decoding i don't think there are free drivers <PotentialUser-34>Would you know how to set it to software decoding ? I tried using it but cannot figure out what option to use ? <PotentialUser-34>mirai thanks, I try that one, but it still complains about GPU stuff, saying it failed to open VDPAU backend (that’s for HW decoding, right ?) <PotentialUser-34>[vo/gpu/wayland] GNOME's wayland compositor lacks support for the idle inhibit protocol. This means the screen can blank during playback. <PotentialUser-34>[vo/gpu/opengl] Failed to set up VT switcher. Terminal switching will be unavailable. <mirai>with a pastebin site, like paste.centos.org <mirai>it has to do with what --vo you're using <mirai>my guess is that all vo's mpv can use are failing in your system <dcunit3d>if i've got a guix channel locally, is there any way to update it without committing? or if it's pushed to a git remote, can i easily maintain multiple branches? <dcunit3d>if there is a master and a develop branch, what's the best way to manage merging into master? do i need to sign all the commits to develop, then sign the merge into master? <dcunit3d>or should i have a guix build workflow to test changes to packages locally? <dcunit3d>also, i have a yubikey 4 and a yk5, but the yk4 doesn't support ECC. so my master key is rsa 4096 and it has 6 subkeys (auth/enc/sign for rsa4096 and nistp384). this is probably a mistake i guess, but will i encounter any issues with this? it looks like i can add each subkey's fingerprint to the .guix-authorizations file. is that right? or does it need to be the master key's fingerprint? <zacchae[m]>I noticed a lot of symbols have missing fonts. e.g. C-x 8 RET in emacs shows mostly missing symbols. Including the "copyleft" symbol. "guix search font" doesn't give anything too obvious. <rekado>there are still a number of broken packages on core-updates; maybe my profile is unusual <rekado>fixed the cross gccs and geda-gaf <dcunit3d>oh, nevermind, copyleft is missing for me as well <bjc>c-u just got a master merge like an hour ago or so <rekado>libfive is broken, as is kaldi, and thus vost <rekado>and I had fixed linphone-desktop before, and now it’s broken again… <rekado>commit f2166cfacea03dcc399d1858d27ff473ebfc0679 broke it