IRC channel logs
2025-10-21.log
back to list of logs
<apteryx>sneek: later tell civodul yes, I'm aware of the validate-runpath trick (add a global runpath to the libraries to everything), but it's suboptimal: a) new users will no know how to handle with the problem, likely to disable the whole phase b) even if you know about the problem, it's sometimes confusing whether it's a bug in the build system of the package or just a loadable plugin that should be ignored/placated via the a) trick <apteryx>sneek: later tell civodul ... and c) one could argue is not proper to have loadable plugins have a RUNPATH and d) it looks like we perhaps can have some basic heuristic and/or a hint when validate-runpath can't reasonably assume something <apteryx>Interesting: "objcopy: Unable to recognise the format of the input file `/gnu/store/xnhsyzqi5hmdaavkljnzpscfkf7cnyby-guile-3.0.9-debug/lib/debug/gnu/store/4z9x7hhsafjry9fbichdciw1gghm2mms-guile-3.0.9/lib/guile/3.0/ccache/ice-9/and-let-star.go.debug'" <deedend>Folks, would a dell optiplex 7070 i5 9500 32Gb ram and 512Mb NVMe SSD be good as a guix build machine/nextcloud server/xmpp server? For ~355AUD shipped. Does it have enough power for the job, and is it reliable to stay on 24/7? I would add 2x3.5" 4Tb HDD maybe externally for the nextcloud storage <iamawack1>I've got a few simple PR's that add and updae packages, but it's been like a week and they're just sitting there, no reviewer. Should I try to pro-actively search out more reviewers? Or should I just leave my PR's waiting in the Codeberg, doing something else instead (like review oher people's PRs or make new contributions). <efraim>feel free to ping people. worst that happens is they ignore the pings. <csantosb>iamawack1: Do your pr relate to a team ? You may also provide the pr #id here, just the relevant reviewer is around <Deltafire>looks cool, shame Mutter doesn't support the required protocols :( <Deltafire>deedend: i've got an older optiplex, i find it's decent build quality and fairly reliable (although i get occasional GPU freezes from the radeon card in it) <deedend>Deltafire: i went ahead and bought it. I hope I'll be able to set up at least a nextcloud instance, to start with <tux1c```>what is the policy of python packages whose dependencies are pinned to an older version of a python package? is it fine to just patch the '==' to '>=' (given that it builds with the newer minor version of the dep)? <tux1c```>deedend: I'm running a nextcloud instance on an old NUC, I bet your machine will face no problems <tesseract>why doesn't icecat package state minor update versions? for example icecat version is 140.4.0esr . i got icecat update today but it still has the same version number <ieure>tesseract, If you got an update with the same version, it's not a version update. <ieure>tesseract, Probably the package was rebuilt because of an input changing; or the package was changed without updating the version. <tesseract>i mean, it should state a different version number even though it is fix or something <ieure>tesseract, An input is a piece of software needed to build another piece of software, similar to a dependency in another distro. When any package in Guix changes, all packages which take it as an input are rebuilt against the update. <ieure>tesseract, Guix is based on Nix, the Nix paper explains all this. <ieure>tesseract, You got a new *build* of icecat. A new build != a new *version*. <iamawacko>re my question about getting PR's reviewed from the 20th, one of them got tagged team-rust, but the others I don't think they're connected to a team. <iamawacko>#3413 is a simple 3 line PR that updates gammastep, if anyone here wants to review it. <iamawacko>In #3411, I update git-crypt to the newest version with only 2 lines changed. I use git-crypt all the time, especially in my Guix configs repo, so I'd love it if I could use the one from Guix repos. It's a simple PR, there's no associated team, I'd love it if someone spared a minute on Codeberg to check it out. <iamawacko>And finally #3412 adds a Rust package I love to use, lok. I just used the Rust import and it seemed to work perfectly, so like the others this should be easy to review. It does fall under team-rust, and it's tagged as such. I don't really know how the existance of a team changes how pull requests work. <iamawacko>Thanks for taking time out of your day to read these IRC messages, even if you don't review my PR's. <Deltafire>iamawacko: 20th as in yesterday? normally takes a week or 2 at least <iamawack1>yesterday as in the discussion I had here yesterday, not that I opened those PR's yesterday. I opened the pull requests right about 2 weeks ago, and yesterday when I was talking about it here they said I should try posting about my PR's here (and if that doesn't work, try getting peoples attention over Codeberg). <iamawack1>My PR's are even labeled "Good First Issue", so they should be simple enough for anyone to review. <iamawack1>I read the channel logs even if I'm not online, btw <iamawack1>I'd love any kind of feedback on my pull requests <sham1>Patience. The project is run by volunteers and these things can take time <iamawack1>to quote a wise-one, "feel free to ping people. worst that happens is they ignore the pings" <ieure>I do not think that's the worst that happens, or good advice. <Rutherther>I would consider people hating me worse than they ignoring me xD <andreas-e>iamawack1: Which ones are your pull requests? <andreas-e>The problem is that patience might not be enough. We are getting more issues and pull requests than we can handle; the queue keeps growing. <andreas-e>Mechanically, some of them will never be treated. <Rutherther>but they also said that they read the logs when they leave <ieure>ACTION waves at iamawacko through a time machine <Rutherther>but filtering PRs on "good first issue", there is #3411 #3413 from iamawacko, that sounds very similar to iamawack1 <andreas-e>ieure: Well then, I would consider this a failed ping. <ieure>Rutherther, "~iamawacko@host-62-133.ininloc.indianapolis.in.us.clients.pavlovmedia.net" <andreas-e>Okay, I will have a look. The first one is even a simple update. <iamawack1>andreas-e: I mentioned the PR numbers earlier today, but #3412 is the last one with no review <iamawack1>Rutherther: yep, iamawacko is me. The display name is iamawack1 because at one point I lost internet, so I have a phantom that I'll need to deal with eventually. <iamawack1>andreas-e: And I've been trying to help out with that qeue and review other's PR's, and talking in issues. I'm new to Guix, so I can only do so much. That it was just a simple update was what made me reach out after just two weeks, it should be quick to review. <iamawack1>Rutherther: At least people hating me is engagement, I think being ignored is worse. I read the logs on my phone, I can't be on IRC all day <ieure>iamawack1, I appreciate your enthusiasm and willingness to contribute, but I would recommend not coming in as hot as you have been. <ieure>iamawack1, Review + push is contingent on someone being around who uses/cares about the PR noticing it and having time. Smaller patches don't necessarily get reviewed faster. <ieure>*uses/cared about the package the PR is for <Deltafire>i think the average wait time for simple PR is multiple weeks at the moment - months for complex ones or ones with a lot of dependants <iamawack1>ieure: Thanks for all the advice, it's definitely very different here compared with my experience with the AUR, or contributing to Rust projects. I don't imagine I'll be doing this kind of thing in the future, now that I've got more knowledge and experience. <Rutherther>Deltafire: I don't think that is really accurate. It depends on what PR it is, specifically who would be interested in it / which team it is for etc. <andreas-e>iamawack1: Help in reviewing is definitely appreciated! <andreas-e>Deltafire: It just varies a lot. I just pushed a simple update that came in an hour ago. Other issues end up being forgotten, because every day more things arrive on the top of the heap. It is a bit LIFO. <Rutherther>Deltafire: oh, you said average. So that can definitely be correct, not sure what I was thinking. <iamawack1>Thanks everyone for all of the input, advice, and reviews! All of my PR's have been reviewed, and I know what to work on now. <andreas-e>Rutherther: I also agree with your statement that it depends on the team. And on the quality of the patch. Sometimes I have enough energy to quickly build a package with a perfect patch, but not enough to engage in lengthy explanations on how to improve a messy patch. <Rutherther>andreas-e: oh? I feel lilke it's totally opposite for me, just building a package it very boring for me, while explaining every detail of what I think could be improved to someone who has submitted a messy patch is quite an entertainment for me :D <andreas-e>Okay, we are all different! Explaining how to make better commits is definitely useful. But I often find it too boring, since it is always the same things: follow the commit message style; prepare one commit per package; use "./etc/committer.scm"; do not run "guix style", at least not in the same commit; etc. <Rutherther>yeah, I agree the commit messages as well, I meant more the changes to scheme code <ekaitz>about "prepare one commit per package" we should talk... why do we do this?