Re: Repology and outdated packages
kias...@disroot.org schreef op di 07-06-2022 om 18:39 [+]: > So without demanding more maintainer time, for now I just convince myself > that: > - key toolchains such as Rust and Go are not always up to date, thus blocking > the > upgrade of several packages In my experience with antioxidant, not-up-to-date Rust toolchains do not prevent upgrading packages -- in the process of resolving build failures, I updated some crates. This never resulted in a ‘you need an new toolchain error’. At worst, I had to disable the "unstable", "nightly" or "generic-simd" features of the crate. There are a lot of outdated crates in Guix, but AFAICT this is unrelated to the newness of the toolchain. I don't know about Go. Greetings, Maxime. signature.asc Description: This is a digitally signed message part
Re: Repology and outdated packages
kias...@disroot.org schreef op di 07-06-2022 om 18:39 [+]: > - we package their dependencies separately (eg Rust crates, Go modules), > these are a significant portion of Guix that cannot be constantly updated > easily > - the Guix 1.4 release is coming soon so more time may be spent debugging > that instead of updating the package archives [...] > However I hope that faster package reviews can mean we stay updated faster > without compromising package quality. FWIW, antioxidant removes most of the complexity of Rust's dependency system, which should help with packaging and reviewing. No need to package old versions to satisfy Cargo and making sure the old version builds, has an appropriate synopsis/description, doesn't introduce malware, ... Theoretically (currently untested!) faster build times, no need to package Windows or redox crates. The cost is that, as you seem to write, that the dependent might not support the old version of the dependency, but updating is something upstream needs to do eventually anyway, and (antioxidant) in theory (untested) supports working with multiple versions. There's also the option of making some compatibility changes in the Guix version of the dependency (undoing a removal of a function, or adding some aliases, etc.). Greetings, Maxime signature.asc Description: This is a digitally signed message part
Re: Teams
On 2022-06-04, Ricardo Wurmus wrote: > As a first step I’d suggest collecting teams, setting up the email > aliases, and updating the website to show the existing teams. Here’s > a draft of three teams: I'm almost afraid to volunteer... but maybe architecture specific teams? If I were to put my very highly optimistic hat on, I might be up for aarch64, riscv64 and armhf... live well, vagrant signature.asc Description: PGP signature
Re: Repology and outdated packages
Hello, kias...@disroot.org writes: > I've been watching the Repology page for Guix and I've noticed that > we've dropped to 51% outdated packages > [https://repology.org/repository/gnuguix]. We used to be at 40% > outdated packages a few months ago. Repology hasn't been able to caught Guix package updates for a while now. As a consequence, many packages are marked as outdated in Repology even though they are not. Regards, -- Nicolas Goaziou
Repology and outdated packages
Dear Guix, I've been watching the Repology page for Guix and I've noticed that we've dropped to 51% outdated packages [https://repology.org/repository/gnuguix]. We used to be at 40% outdated packages a few months ago. I know that rolling release distros don't have to have the latest packages but this is not the best representation of Guix, especially when our friend NixOS claims they have the largest and most updated package collection [https://nixos.org/blog/announcements.html#nixos-22.05]. So without demanding more maintainer time, for now I just convince myself that: - key toolchains such as Rust and Go are not always up to date, thus blocking the upgrade of several packages - we package their dependencies separately (eg Rust crates, Go modules), these are a significant portion of Guix that cannot be constantly updated easily - the Guix 1.4 release is coming soon so more time may be spent debugging that instead of updating the package archives - the Guix branching model of staging/core-updates means we could say Guix is an LTS rolling release distro, which there aren't that many of However I hope that faster package reviews can mean we stay updated faster without compromising package quality. WDYT?
Re: Teams
On Sun, Jun 05, 2022 at 11:51:20AM +0200, zimoun wrote: > Hi Ricardo, > > > > * R team > > Simon Tournier > > Ricardo Wurmus > > In addition, add me to: > > * Julia team I can do the Julia team too. -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: emacs-guix (upstream) needs more love: a survey of repositories, homepage and issues
Hi Ludo' Sorry for taking a while to send a reply! On Monday, May 30th, 2022 at 8:33 AM, Ludovic Courtès wrote: > Hello Kaelyn, > > Kaelyn kaelyn.al...@protonmail.com skribis: > > > > First, we need to cherry-pick relevant commits from gitlab.com. Any > > > takers? If you Giovanni or anyone else is willing to help, we can grant > > > commit access so we share the work. Another way to help is by listing > > > commits that should be applied. > > > > > > Volunteers? > > > > I'd be happy to help with the efforts! > > > Yay! > > > I just took a few minutes and checked both repos out into a single > > working tree, and there aren't many commits unique to each > > repository. The official savannah repo has 5 commits since they > > diverged, with the 3 oldest looking like variations of the 6 oldest in > > the gitlab repo. Likewise, not counting the 6 just mentioned, there > > are 4 unique commits in the gitlab repo. Those 4 commits are: > > > > * c9aef52 - (gitlab/master, gitlab/HEAD) elisp/ui-package: Add > > 'guix-package-use-name-at-point' variable (12 months ago) > > * e5ff0e5 - elisp/ui-package: Fix an error on package name read (12 months > > ago) > > * 8ce6d21 - Rename 'guix-search-…' to 'guix-packages-…' commands (1 year, 3 > > months ago) > > * fbc2bbc - elisp/ui-package: Use thing at point for > > 'guix-packages-by-name' command (1 year, 3 months ago) > > > Awesome. > > Would you be willing to coordinate work on Emacs-Guix for some time? > If so, I’m in favor of granting you commit access so you can first push > these four commits, and eventually apply patches that are submitted or > fix bugs here and there. > > If Giovanni or Théo wants to do that, that’s fine too. What we need is > to make sure one of us/you can commit some time going forward to at > least protect Emacs-Guix from bitrot, and ideally help improve it, as > time permits. > > WDYT? While my time can sometimes be a little spotty short-term, I am willing to coordinate work on Emacs-Guix and at least protect it from bitrot. Right now, I'm still fairly new to Emacs and am still working on my setup and learning & integrating things like using Emacs-Guix or M-x debbugs-gnu, but I also wish to both get more involved with Guix and improve my Emacs development and debugging skills. I'll also be happy to push those four commits once I work out my local build and testing (i.e. getting the tests to pass locally with a clean tree to see if my cherry-picking of the commits are the reason tests are failing.) > Bug reports would still go to https://issues.guix.gnu.org, which you > > can access from the comfort of your Emacs with M-x debbugs-gnu. :-) I really need to try that out! :) Cheers, Kaelyn > Thanks, > Ludo’.
Re: maradns reproducibility fixes and the merits of picking a random number
Hi, Vagrant Cascadian skribis: > But there's one nervous-making issue this revealed; maradns embeds a > random number at build time ... allegedly for systems that don't have > /dev/urandom... see > maradns-3.5.0020/deadwood-3.5.0020/src/Makefile.ubuntu2004: > > # Since some systems may not have /dev/urandom (Windows, *cough* *cough*), > we > # keep a randomly generated prime around > > So it's got some code to generate a random number at build time and > embed it in the binary. Now, if there's anything I know about good > practices about random numbers, this sort of thing is generally a very > large red flag! It also makes the package build differently every time! Woow. Reproducibility work lets you uncover issues you wouldn’t think of! Ludo’.
Re: On commit access, patch review, and remaining healthy
Hi Efraim, Efraim Flashner skribis: > As someone who has never used debbugs or emacs I find it daunting to try > to add it into my workflow. Currently I am subscribed to guix-patches > and I dump it into my guix-devel mailing list. I read my mail using mutt > and will just pipe the patches to git to apply them and try them out > that way. After years and years of this I'm pretty happy with this > aspect of my workflow, but finding older patches can be more > challenging. And in our case older can be only a week old. The manual mentions the two web interfaces in addition to Emacs: https://guix.gnu.org/manual/devel/en/html_node/Debbugs-User-Interfaces.html Do you or would you use them to keep track of pending patches? Perhaps a CLI taking advantage of mumi’s HTTP interface (or using Guile-Debbugs) would work better? Like: mumi new # list new issues mumi fetch 1234 # fetch patches of issue #1234 mumi close 1234 … WDYT? Ludo’.
Re: maradns reproducibility fixes and the merits of picking a random number
The upstream website says: "People like MaraDNS because it’s ... remarkably secure." [1] Since many distributions have the same issue, upstream could perhaps offer the patch as a build switch to enable a build-time seed only when needed. Sounds like the safest option. Maybe we could change the code that uses that number to naise an exception or abort? This seems like the best option to me, as well: either add a flag to explicitly enable embedding a constant, or remove the code entirely and replace it with a build failure (or runtime failure, if a build failure is not possible). It seems like a mis-feature to me to embed a constant seed, and invites silent misconfiguration which will lead to security breaches. -bjc
Re: On commit access, patch review, and remaining healthy
On Fri, Jun 03, 2022 at 09:37:36PM +0200, Ludovic Courtès wrote: > Hi, > > Brian Cully skribis: > > > Ludovic Courtès writes: > > > >> If you are using Emacs, does debbugs.el have > >> shortcomings that make it a problem to review patches? > > To be clear, the question was directed primarily at current committers. > > > 1) It’d be nice if ‘M-x debbug-guix’ existed. I (briefly) looked at > > making such a command, thinking it’d be relatively straight-forward to > > just copy ‘debbugs-gnu’ and tweak some variables, but when it looked > > like it was going to take more than 10 minutes just to figure out how > > it was all put together I gave up as I can’t really dedicate time to > > it right now. > > Try: C-u M-x debbugs-gnu. From there you can choose ‘guix’, > ‘guix-patches’, or anything else (info "(guix) Debbugs User > Interfaces"). > > > 2) IMHO, the documentation for debbugs is pretty poor. It mostly > > relies on GNUS documentation for things like mode help; and while this > > makes sense, GNUS is a big, complex package (which is why I use mu4e > > instead of it), and it really raises the barrier for understanding > > debbugs quite a lot. > > I find the Debbugs User Guide, plus the docstrings and all, to be good > (info "(debbugs-ug) Top"). > > I use Gnus though so maybe there are issues I just don’t experience. > > > 3) Even after reading all the documentation I could find, it doesn’t > > seem to work very well for an issue-tracker workflow. I still don’t > > know how to simply reply to a ticket. Let alone how to apply a patch > > to my tree (I did see documentation for how to do that to the Emacs > > source tree, but that’s not very useful — also, the key combinations > > feel very obtuse and hard for me to remember). > > > > So, right now, I just use it to browse, since I find it easier than > > mumi, but everything else happens with external tools. It’s very > > possible my n00b is showing right now and it’s easier to work with > > than it seems at first blush, but I’d say that means the documentation > > needs some dedicated, non-GNUS-oriented love. It would be very helpful > > if there were a HOWTO, like we used to do in the old days, with how to > > use it for simple tasks, and stick it in the info documentation and on > > the web. > > Interesting. Since I already used Gnus before, I didn’t have much to > learn when I started using debbugs.el. > > I know some people here use debbugs.el with other email clients like > mu4e, so perhaps they can comment? We could add guidance in the manual. As someone who has never used debbugs or emacs I find it daunting to try to add it into my workflow. Currently I am subscribed to guix-patches and I dump it into my guix-devel mailing list. I read my mail using mutt and will just pipe the patches to git to apply them and try them out that way. After years and years of this I'm pretty happy with this aspect of my workflow, but finding older patches can be more challenging. And in our case older can be only a week old. -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: On commit access, patch review, and remaining healthy
Hi, On Mon, 06 Jun 2022 at 23:43, Ludovic Courtès wrote: > I can think of two ways to reassure committers: > > 1. By having clear reviewer check lists (you’d do that if you tick all > the boxes, you’re fine); As pointed earlier by Arun in «Public guix offload server» [1], this check list would imply some rebuilds and it can be difficult depending on the resource at hand by the committer who reviews. 1: https://yhetil.org/guix/878rynh0yq@systemreboot.net > 2. By improving automation—nothing new here: if there was a tick that > says “applies without merge conflicts” and another one that read > “builds fine”, anyone could lightheartedly hit the “merge” button. >From my understanding, one of the issue is where the committers push vs where the users pull. Basically, the push happen on master and the changes are directly available to the users. On one hand, it is nice because the things are delivered faster. On the other hand, a tiny change can break many workflows – it is or could be a reason for refraining pushing. More eyes who review help, for sure. But it is not straightforward as we are often discussing. :-) More tools can also help, but AFAIK, nothing is fully ready right now. What remain is: not push to the production branch. :-) Maybe, we could push to a branch “unstable” **automatically** merged every week to the branch “stable” and by default user pull “stable”. One week let the time to build by the CI, check everything is fine and fix otherwise. It reduces a bit the pressure on the committers, IMHO. We – from core developers to user just wanting the things done – are all pulling the same branch. This branch cannot satisfy in the same time all the constraints; is the current push/pull branch model satisfying the best optimum with the resource and tools at hand? Cheers, simon
