Re: Teams
Hi, On Sun, 2022-06-05 at 11:51 +0200, Andreas Enge wrote: > Hello, > > Am Sat, Jun 04, 2022 at 02:07:15PM +0200 schrieb Ricardo Wurmus: > > 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: > > if something like this makes sense, I would be interested in joining > a team > around algebra.scm and maths.scm. Or maybe a C team :) I like the Teams idea. It might help me focus and add just enough accountability. I'd add myself to an algebra.scm and maths.scm team. `~Eric signature.asc Description: This is a digitally signed message part
Re: Repology and outdated packages
June 8, 2022 at 9:38 PM, "Ludovic Courtès" mailto:l...@gnu.org?to=%22Ludovic%20Court%C3%A8s%22%20%3Cludo%40gnu.org%3E >
wrote:
> Guix is *potentially* even more up-to-date than NixOS thanks to
> ‘--with-latest’ and ‘--with-branch’! \o/
I do use --with-latest for testing package upgrades. But it is tedious to type
$ guix build X --with-latest=X
in order to test the latest package.
What would be nice is if
$ guix build --latest X
is an equivalent command. Certainly a shell script could take care of that:
guix-build-with-latest() {
guix build "$1" --with-latest="$1"
}
but having it done in guix itself would be convenient.
> Seriously though, we could take better advantage of the tooling that we
> have: ‘guix refresh’, ‘guix graph’, and the corresponding APIs. With
> that, we can write code that automatically tries out package updates and
> prepares patches, for instance. We could even largely automate “update
> trains” (what we’re doing with master/staging/core-updates).
It could be an option to guix refresh, for example
$ guix build --latest X --export-patch
would build X with the latest version and export a patch with an appropriate
commit message (like marking failed builds with DRAFT). This would help users
contribute without having to clone the git repo.
Re: Repology and outdated packages
June 7, 2022 at 6:47 PM, "Nicolas Goaziou" mailto:m...@nicolasgoaziou.fr?to=%22Nicolas%20Goaziou%22%20%3Cmail%40nicolasgoaziou.fr%3E > wrote: > 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. Another point of Repology is that binary up-to-dateness (latest/not) is less granular than "package is X versions behind latest". Guix is usually only a version or 2 behind in many projects which is fresh enough for me.
Re: Repology and outdated packages
Hi, Ludovic Courtès writes: […] > Seriously though, we could take better advantage of the tooling that we > have: ‘guix refresh’, ‘guix graph’, and the corresponding APIs. With > that, we can write code that automatically tries out package updates and > prepares patches, for instance. We could even largely automate “update > trains” (what we’re doing with master/staging/core-updates). Maybe it's ok to push directly packages with #:tests #true and a low number of triggered builds by the update. Also, we probably should run the make check-system TESTS="XYZ" tests if a service depends on an updated package. Oleg. signature.asc Description: PGP signature
Re: Teams
Hello, Ludovic Courtès writes: > Vagrant Cascadian skribis: > >> 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? > > There could also be an “embedded” team for people who take care of > packages like U-Boot, cross-compilation to ARM, platform definitions, > and all these things you’re familiar with. I'm assuming the teams are for committers, so because of that and also — or even especially — because of my time availability I would be interested in being a lurker/occasional helper on an embedded team, if it would be possible to have such a thing. >> If I were to put my very highly optimistic hat on, I might be up for >> aarch64, riscv64 and armhf... > > That too! Ditto for ppc64le and even aarch64 teams. -- Thanks Thiago
Re: Repology and outdated packages
Hi! kias...@disroot.org skribis: > 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]. Guix is *potentially* even more up-to-date than NixOS thanks to ‘--with-latest’ and ‘--with-branch’! \o/ https://guix.gnu.org/manual/devel/en/html_node/Package-Transformation-Options.html Seriously though, we could take better advantage of the tooling that we have: ‘guix refresh’, ‘guix graph’, and the corresponding APIs. With that, we can write code that automatically tries out package updates and prepares patches, for instance. We could even largely automate “update trains” (what we’re doing with master/staging/core-updates). Ideas for a motivated hacker! Ludo’.
Re: Teams
Vagrant Cascadian skribis: > 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? There could also be an “embedded” team for people who take care of packages like U-Boot, cross-compilation to ARM, platform definitions, and all these things you’re familiar with. > If I were to put my very highly optimistic hat on, I might be up for > aarch64, riscv64 and armhf... That too! Ludo’.
Re: Merging ‘staging’?
Hey Efraim, Efraim Flashner skribis: > On Mon, Jun 06, 2022 at 11:17:47PM +0200, Ludovic Courtès wrote: >> Hi, >> >> Ludovic Courtès skribis: >> >> ‘guix weather -s i686-linux’ says 89% (which is underestimated, because >> it wrongfully checks for all the packages, including unsupported >> packages), which sounds good. >> >> We have to check for AArch64 & co. Any takers? >> >> Overall it seems to me we should be able to merge ‘staging’ within a >> couple of days. Thoughts? > > Currently ci.guix.gnu.org isn't building any of the aarch64 packages, > and it looks like it hasn't since about May 26th. Once those start > building again I expect we'll see it's doing well. Minus perhaps the > rust stuff since I'm not sure the offload build machines can handle > that. Hmm the situation is bad indeed: --8<---cut here---start->8--- $ ./pre-inst-env guix weather -s aarch64-linux -c200 computing 18,932 package derivations for aarch64-linux... looking for 19,704 store items on https://ci.guix.gnu.org... https://ci.guix.gnu.org 17.1% substitutes available (3,360 out of 19,704) at least 22,303.1 MiB of nars (compressed) 24,029.2 MiB on disk (uncompressed) 0.006 seconds per request (114.2 seconds in total) 172.5 requests per second 5.3% (870 out of 16,344) of the missing items are queued at least 1,000 queued builds aarch64-linux: 840 (84.0%) x86_64-linux: 84 (8.4%) powerpc64le-linux: 72 (7.2%) armhf-linux: 4 (.4%) build rate: 143.62 builds per hour i686-linux: 99.96 builds per hour x86_64-linux: 31.51 builds per hour aarch64-linux: 25.66 builds per hour powerpc64le-linux: 3.14 builds per hour 729 packages are missing from 'https://ci.guix.gnu.org' for 'aarch64-linux', among which: 14236 libxft@2.3.3 /gnu/store/2smylcjq5cppxcrj2mn229hlmh6bf7w4-libxft-2.3.3 10066 icu4c@69.1 /gnu/store/n9nx5rmnhdf3hdswhvns31diayq9vfq2-icu4c-69.1 7723 jbig2dec@0.19 /gnu/store/lrpczm2m0agx0x5rp6kmn8c46mc85l35-jbig2dec-0.19 6552 libxt@1.2.1 /gnu/store/rqqkla9kqjq3182gdqynkq2jb4jf2bl5-libxt-1.2.1-doc /gnu/store/82pzzkny0gwdfkfa5zvnyy4vbzxqnwyy-libxt-1.2.1 4555 openblas@0.3.20 /gnu/store/wc8cbkcvgqkdf65fj7drb82plkf8igyw-openblas-0.3.20 4231 libxfixes@6.0.0 /gnu/store/h70i9gyvif5kzpw7a8bdaxhw7sqiv7wz-libxfixes-6.0.0 3788 libxrandr@1.5.2 /gnu/store/9gqkb75sr60lxic9a3nx543a6wxz0866-libxrandr-1.5.2 3320 libxkbfile@1.1.0 /gnu/store/kk0xk8j8ffgxvfs5kz1vxp2ipz28xwh4-libxkbfile-1.1.0 3297 xcb-util@0.4.0 /gnu/store/n2x5kvy5zxbnh28ak7rbvw6brp97z1c9-xcb-util-0.4.0 3279 xcb-util-wm@0.4.1 /gnu/store/hhasmz0l5f10f9nfg0nx378c7bcgf9v0-xcb-util-wm-0.4.1 3263 libxres@1.2.1 /gnu/store/5mpjhsyq2bbri006g7lh6h82239s8fb8-libxres-1.2.1 1383 xprop@1.2.5 /gnu/store/61x7vscvrz8zqda73dlq5x35anhz8f8k-xprop-1.2.5 1381 xdg-user-dirs@0.17 /gnu/store/gab0ycim14xflaxzp8arg8hfapx73z3l-xdg-user-dirs-0.17 1368 docbook2x@0.8.8 /gnu/store/cclsrji5p14aj8bg3kmhkj5532k7l5m4-docbook2x-0.8.8 1286 perl-net-ssleay@1.92 /gnu/store/cn77pic9249j7h002a9701v0xzpi28yk-perl-net-ssleay-1.92 1179 emacs-minimal@28.1 /gnu/store/c768r60pj3f2af2ysbjqdnlxwpgwmmpp-emacs-minimal-28.1 1121 go-std@1.17.9 /gnu/store/fqdkzg6nlzhj93ysjqxrmqsz8srq2l9r-go-std-1.17.9 1021 ruby-activemodel@6.1.3 /gnu/store/12gm34s68siqdfagc16ldjdp03klc5xw-ruby-activemodel-6.1.3 1005 ruby-shoulda-matchers@2.8.0 /gnu/store/zcbdlp0qqb3axsmfvd8rdmn70kwdiw11-ruby-shoulda-matchers-2.8.0 1001 ruby-webmock@2.3.2 /gnu/store/jfrng4404avghlkyxw2y5hqpdn8v3mih-ruby-webmock-2.3.2 976 ruby-sawyer@0.8.2 /gnu/store/w0aaby4lvdcz0dr5006mx2ik6l1v2s5l-ruby-sawyer-0.8.2 634 jikes@1.22 /gnu/store/nwkrhbzbd8s9dysgik58af93b2kjm4w3-jikes-1.22 622 nss-certs@3.71 /gnu/store/01k1v00g7vc7n90y5yr9bacrnr3ml46p-nss-certs-3.71 576 texlive-latex-cmap@59745 /gnu/store/zdws0y31a1hhgxb80qc2lx4smmp9pmgc-texlive-latex-cmap-59745 558 libxft@2.3.3 /gnu/store/2smylcjq5cppxcrj2mn229hlmh6bf7w4-libxft-2.3.3 491 xmodmap@1.0.10 /gnu/store/rm8ww2flazqypwiagizbbsslv0g86h67-xmodmap-1.0.10 489 ucd@14.0.0 /gnu/store/f3hkrqnsj9dadliaixrlh17z4c9bsjfl-ucd-14.0.0 400 jbig2dec@0.19 /gnu/store/lrpczm2m0agx0x5rp6kmn8c46mc85l35-jbig2dec-0.19 317 icu4c@69.1 /gnu/store/n9nx5rmnhdf3hdswhvns31diayq9vfq2-icu4c-69.1 309 libxt@1.2.1 /gnu/store/rqqkla9kqjq3182gdqynkq2jb4jf2bl5-libxt-1.2.1-doc /gnu/store/82pzzkny0gwdfkfa5zvnyy4vbzxqnwyy-libxt-1.2.1 290 libxfixes@6.0.0 /gnu/store/h70i9gyvif5kzpw7a8bdaxhw7sqiv7wz-libxfixes-6.0.0 272 libunwind-julia@1.3.1 /gnu/store/i8c1hpdxdjb86vn4bqjiml5gad6mnrw5-libunwind-julia-1.3.1 268 ocaml@4.14.0 /gnu/store/zvz0xlwm7mvipr7c8q15fw7r6r25nn4s-ocaml-4.14.0 256 mailutils@3.15 /gnu/store/6c5sd4z84p8mbck8b5vn4vd6s05mkbrc-mailutils-3.15 246 libxrandr@1.5.2
Re: On commit access, patch review, and remaining healthy
Efraim Flashner skribis: > On Tue, Jun 07, 2022 at 05:11:48PM +0200, Ludovic Courtès wrote: [...] >> 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? You didn’t reply to that one but I suppose it’s “no”. > Of the little bit I've seen of debbugs I think I really want is to have > a mailbox folder with just the patches and bugs in it (finally set this > up yesterday) and to have the threads automatically marked as read after > the bug has been closed. I don't know anything about usertags to make > use of them, so it's not something I've ever missed. > > Since I've now split the mailboxes I have less than 300 unread messages > from guix-devel and almost 7000 unread in my shared guix-patches/bugs-guix > mailbox. I would gladly trade that mailbox for something in the terminal > that connected to debbugs directly for the autoupdating of closed bugs > and would still allow me to pipe the patches themselves to apply them to > the git repo. > > It might be what I'm looking for is a minimal emacs config that is just > a frontend to debbugs and lets me use all my normal tools (vim, msmtp, > etc.) for everything else. Well, you could do use Emacs + debbugs.el to browse the list of bugs, but coming up with a simple CLI is doable. Ludo’.
Re: aarch64 workers appear to have stalled on ci.guix.gnu.org
Hi Tom, Tom Fitzhenry skribis: > Per https://ci.guix.gnu.org/eval/364633?status=pending , there are ~5k > scheduled jobs, all aarch64-linux. > > Per https://ci.guix.gnu.org/workers, all workers report being idle. > > Thus, it looks like the aarch64 builders have stalled. It looks like ‘cuirass-remote-worker’ needed a kick on these boxes, which Mathieu and I did earlier today (‘herd restart …’). Most of them are busy right now. Thanks for the heads-up! Ludo’.
Re: maradns reproducibility fixes and the merits of picking a random number
On 2022-06-08, Efraim Flashner wrote: > On Tue, Jun 07, 2022 at 07:20:25AM +0200, Julien Lepiller wrote: >> On June 7, 2022 5:24:22 AM GMT+02:00, Felix Lechner >> wrote: >> >On Mon, Jun 6, 2022 at 6:50 PM Vagrant Cascadian >> > wrote: >> >> >> >> So, Debian's maradns package just removes this embedding of a "random" >> >> number, and I've basically adapted their patches to build reproducibly >> >> on guix too... by basically embedding the same "random" number every >> >> single build! > > I have to say I was shocked to not see 4 as the random number¹. ... > ¹ https://xkcd.com/221/ In an alternate reality, I did consider 4 for the reasons you alluded to, but ruled it out because it was not a random prime number. :) >> >There may be more than one opinion, but as the maintainer of a TLS >> >library in Debian I think it is a questionable tradeoff. At a minimum, >> >it would be preferable to use the version number instead of a fixed >> >constant for all releases. >> >> Consider that even without the patch, each distro will build maradns once >> and distribute the package to their user. Every user gets the same binary >> with the same "random" number. So even if it's chosen at build time, it >> won't really help. >> >> In our case, it only means users who don't use substitutes get a random >> number, others get the same number that the build farm picked at random. >> Fixing a number doesn't sound like it's gonna change a lot for these users. > > This is something we can work with. We can just mark the package as > '#:substitutable? #f' and then everyone will have to build it > themselves. It still won't really be reproducible, but everyone will > actually have their own special random number. This actually seems like the best approach in the short term! Leaving time to work out a better fix long-term, probably by working with upstream... Thoughts? >> >MaraDNS does not support DNSSEC so the program may not use entropy for >> >keys. Either way, I'd rather use an unreproducible build than, >> >accidentally, a known number series to encrypt secrets. Can one patch >> >out the constant entirely so it is no longer available? >> > >> >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? Yeah, seems worth taking this or similar ideas upstream... live well, vagrant signature.asc Description: PGP signature
Re: maradns reproducibility fixes and the merits of picking a random number
On 2022-06-09, Arun Isaac wrote: > Hi Vagrant, > >> 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! > > Wow, great find! Has this issue been reported to maradns upstream? If > upstream fixes it or provides us a compile flag to disable this > "feature", it would be even better in the long run. That does sound like the best long-term approach, definitely! Will take the issue upstream... live well, vagrant signature.asc Description: PGP signature
Re: maradns reproducibility fixes and the merits of picking a random number
On 2022-06-08, Liliana Marie Prikler wrote: > Am Montag, dem 06.06.2022 um 18:49 -0700 schrieb Vagrant Cascadian: >> p.s. Obviously, I picked the best random number. > I beg to differ. >> +-RandomPrime: RandomPrime.c >> +- $(CC) -O3 -o RandomPrime RandomPrime.c >> +- >> +-DwRandPrime.h: RandomPrime >> +- if [ -e /dev/urandom ] ; then ./RandomPrime > DwRandPrime.h ; >> fi >> ++DwRandPrime.h: >> ++ echo '#define MUL_CONSTANT 1238145941' > DwRandPrime.h > This does not satisfy requirement #221: chosen by a fair dice roll. > Randomness can therefore not be guaranteed. I will admit to "Obviously, I picked the best random number." as a joke. Hard-coding any supposedly random number seems awfully wrong to me! This is a not particularly great patch to make it compile reproducibly, on the *assumption* that number will not actually be used in practice, because it *supposed* to only be used when /dev/urandom is not available. I would love to see better patches that make fewer assumptions! FWIW, This is effectively the same embedded random number used in the Debian patch, although the maradns packaging in Debian basically comes to the same result by copying files around rather than patching them directly. live well, vagrant signature.asc Description: PGP signature
Re: Mummi wishlist: API using Message-ID
> As long as the script shows it's trying and explains why it takes > time, it should be fine. It could offer a --continue option too :) Yeah, my thoughts exactly. Definitely beats the two-step manual process that we have to endure now.
Re: Move switch-symlinks to (guix build utils)
Hi Maxime, Thanks for the explanation! I am working on a patch. I'll send something soon. Regards, Arun
Re: maradns reproducibility fixes and the merits of picking a random number
Am Montag, dem 06.06.2022 um 18:49 -0700 schrieb Vagrant Cascadian: > p.s. Obviously, I picked the best random number. I beg to differ. > +-RandomPrime: RandomPrime.c > +- $(CC) -O3 -o RandomPrime RandomPrime.c > +- > +-DwRandPrime.h: RandomPrime > +- if [ -e /dev/urandom ] ; then ./RandomPrime > DwRandPrime.h ; > fi > ++DwRandPrime.h: > ++ echo '#define MUL_CONSTANT 1238145941' > DwRandPrime.h This does not satisfy requirement #221: chosen by a fair dice roll. Randomness can therefore not be guaranteed.
Re: maradns reproducibility fixes and the merits of picking a random number
Hi Vagrant, > 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! Wow, great find! Has this issue been reported to maradns upstream? If upstream fixes it or provides us a compile flag to disable this "feature", it would be even better in the long run. Regards, Arun
Re: maradns reproducibility fixes and the merits of picking a random number
Efraim Flashner 写道： I like the idea of forcing the program to segfault if it looks for /dev/urandom and it isn't there more than distributing a randomized prime number. +4 Or error out nicely. Don't let's ship such ‘features’. Kind regards, T G-R signature.asc Description: PGP signature
Re: Merging ‘staging’?
On Mon, Jun 06, 2022 at 11:17:47PM +0200, Ludovic Courtès wrote: > Hi, > > Ludovic Courtès skribis: > > ‘guix weather -s i686-linux’ says 89% (which is underestimated, because > it wrongfully checks for all the packages, including unsupported > packages), which sounds good. > > We have to check for AArch64 & co. Any takers? > > Overall it seems to me we should be able to merge ‘staging’ within a > couple of days. Thoughts? Currently ci.guix.gnu.org isn't building any of the aarch64 packages, and it looks like it hasn't since about May 26th. Once those start building again I expect we'll see it's doing well. Minus perhaps the rust stuff since I'm not sure the offload build machines can handle that. -- 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: maradns reproducibility fixes and the merits of picking a random number
On Tue, Jun 07, 2022 at 08:11:54AM -0400, Brian Cully via Development of GNU Guix and the GNU System distribution. wrote: > > > > 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 I like the idea of forcing the program to segfault if it looks for /dev/urandom and it isn't there more than distributing a randomized prime number. -- 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: maradns reproducibility fixes and the merits of picking a random number
On Tue, Jun 07, 2022 at 07:20:25AM +0200, Julien Lepiller wrote: > > > On June 7, 2022 5:24:22 AM GMT+02:00, Felix Lechner > wrote: > >Hi, > > > >On Mon, Jun 6, 2022 at 6:50 PM Vagrant Cascadian > > wrote: > >> > >> So, Debian's maradns package just removes this embedding of a "random" > >> number, and I've basically adapted their patches to build reproducibly > >> on guix too... by basically embedding the same "random" number every > >> single build! I have to say I was shocked to not see 4 as the random number¹. > >There may be more than one opinion, but as the maintainer of a TLS > >library in Debian I think it is a questionable tradeoff. At a minimum, > >it would be preferable to use the version number instead of a fixed > >constant for all releases. > > Consider that even without the patch, each distro will build maradns once and > distribute the package to their user. Every user gets the same binary with > the same "random" number. So even if it's chosen at build time, it won't > really help. > > In our case, it only means users who don't use substitutes get a random > number, others get the same number that the build farm picked at random. > Fixing a number doesn't sound like it's gonna change a lot for these users. This is something we can work with. We can just mark the package as '#:substitutable? #f' and then everyone will have to build it themselves. It still won't really be reproducible, but everyone will actually have their own special random number. > > > >MaraDNS does not support DNSSEC so the program may not use entropy for > >keys. Either way, I'd rather use an unreproducible build than, > >accidentally, a known number series to encrypt secrets. Can one patch > >out the constant entirely so it is no longer available? > > > >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? > > > >Thank you for your hard work on Guix! As a newbie I'll say, what a > >great distro. Thanks, everyone! > > > >Kind regards, > >Felix Lechner > > > >[1] https://maradns.samiam.org/ > > > ¹ https://xkcd.com/221/ -- 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
On Tue, Jun 07, 2022 at 05:11:48PM +0200, Ludovic Courtès wrote: > 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? Of the little bit I've seen of debbugs I think I really want is to have a mailbox folder with just the patches and bugs in it (finally set this up yesterday) and to have the threads automatically marked as read after the bug has been closed. I don't know anything about usertags to make use of them, so it's not something I've ever missed. Since I've now split the mailboxes I have less than 300 unread messages from guix-devel and almost 7000 unread in my shared guix-patches/bugs-guix mailbox. I would gladly trade that mailbox for something in the terminal that connected to debbugs directly for the autoupdating of closed bugs and would still allow me to pipe the patches themselves to apply them to the git repo. It might be what I'm looking for is a minimal emacs config that is just a frontend to debbugs and lets me use all my normal tools (vim, msmtp, etc.) for everything else. -- 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
On Tuesday, June 7th, 2022 at 10:42 AM, Kaelyn wrote: [snip] > > > 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.) I want to give a quick update: I have successfully built and run "make check" for my local branch with the four cherry-picked commits, plus one addition commit to fix the build (an emacs script used for local builds was passing an argument to guix-emacs-autoload-packages, which was refactored to not take arguments in guix commit 47b3b4c2aa from 2019). With my extra commit, I think the branch should be ready to push. Cheers, Kaelyn
Re: On commit access, patch review, and remaining healthy
Hi Ludo' Ludovic Courtès writes: [...] > OK, understood. > > 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); also a description of the review process used by you and other experienced patch reviewers could be much useful: it's more /how/ do you check al the aspects of a patch (it's not only running "guix lint" obviously) than /what/ do you check, IMHO maybe this could be a specific chapter of the cookbook, maybe some experienced patch reviewer could make a sort of (reharshed) "live patch review" video of some patch representing interesting "class of patches" reviewers may encounter (upstream updates, changes in Guix package structure, patches to fix building issues...) if available I'd also attend a paid "Contributing Guix" course, since it would be /very/ useful to my work... but that's out of scope here, I think > 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. OK but this can also be achieved now without automation, just by commenting the patch submission so that committers can "reuse" the work already done by others; a check-list can help for sure: could it be auto-generated by debbugs via a mail-template on receiving a message in the patch-list? > #2 is going to take time I’m afraid, but at least #1 is actionable > (‘guix lint’ should help, too). > > WDYT? Are there other possibilities that come to mind? is it possible to automate "guix lint" (and add it as git hook before commit?) only for the package(s) specific to a patch-set? [1] [...] > And yes, we should take advantage of the WhereIsEveryone meetups and > guix-mentors to get to know each other, to help each other, and to > demystify the whole thing. I'd not miss the chance to someway document important things said during meetings/IRC/email-messages useful to demystify the whole thing: I know it's more work for some of you, but hopefully for less work in the future [...] Thanks! Gio' [1] that is: is there a command that given a patch is able to give us a list of affected guix packages? -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
Re: On commit access, patch review, and remaining healthy
Hi Arun, Arun Isaac writes: > Tooling aside, at least for me, I think there is an important emotional > and psychological aspect to patch review. Maybe others share it too. So, > I'll speak up. Thanks a lot for your speak up! > Guix has very high coding standards Do you think other software distribution do have less high coding standards? [...] > but that means that there is a high cost of failure please can you expand on this? What is that cost of failure? > and a pressure to live up to that high standard. This means that even > if I'm 99% sure of a commit, I tend to leave it to others because of > that nagging 1% doubt I have about some trivial aspect of the > patch. The 1% doubt could even be about really trivial things like > indentation or the name of a variable. In other words, perfectionism > causes paralysis. generally speaking I really understand your feeling (the "impostor syndrome" as Ludo' say) but please do not be paralyzed by this feeling, do /not/ have fear to make a mistake, we (pluralis majestatis :-D ) are not here to judge you specifically speaking, IMHO in cases like this you should send an email-reply to that bug (patch) explaining the 1% you are unsure of > This excessive self-doubt is created by feeling like one doesn't > "belong" in the elite community of Guix hackers I undestand there are many meanings of "elite" [1], but if it's an elite it is /for sure/ a very open group of persons [...] Thanks! Gio' [1] https://www.merriam-webster.com/dictionary/elite -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
Re: On commit access, patch review, and remaining healthy
Hi Simon and all, just a quick note about myself: I'm (still) not contributing with patch reviews (and in general contributing too little) because in this period of my "work life" I have little time, but things will hopefully change... IMHO the curent tooling is helpful and usable with a little bit of studying (git, patch management, guix lint et al...) and effort, obviously more tools could help more users (debbugs for vim (?!?), mumi CLI) but the real hard work is not at the interface level, it's at "content" level AND at "machine power" available resources IMHO the whole process should not be automated more than this (I mean, more than making as easy as possible patch application using the reviewer preferred tools): review is a human-only job after all... let's just say reviwers are giving their fair contribution to the verification of code above stage0... at a higher level (stage99? :-) ) zimoun writes: >> 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. I can confirm that without a local offload build server Guix package development and review is unpractical: one of the first things I had to do in order to not negatively impact my working evironment was to buy a (used) machine and set it up as a local offload build server, that improved my (rare, as I said) work on guix package devel a lot. Maybe we should clarify this in the contributing section of the manual? Maybe we should warn users that to contribute you /first/ have to get enough machine CPU+memory power, possibly on an offload server (used computers can do great things)? IMHO local distributed build for patch review purposes is better than a centralized one, also as a sort of reproducibility test, no? > 1: https://yhetil.org/guix/878rynh0yq@systemreboot.net AFAIU quickly reading that thread (dated 2021-10-20) a public offload build server "as is" is too much a security risk: interested people should re-read that thread, Tobias Geerinckx-Rice explained very well the threat model. I would never use a shared offload build server or one not on bare-metal AND under my direct physical control Ludo' told us it should be possible to use a remote daemon without mutual trust between machines (id:87o8782g6q@gnu.org) and that we could have an HTTP bridge or API: what's the situation today? Anyway, I'd prefer a third build farm to cross-challenge substitutes than a public shared offload build server. :-O [...] > What remain is: not push to the production branch. :-) Maybe, we could > push to a branch “unstable” AFAIU this have little to do with patch review, unless you imply that committers can push to "unstable" with "less patch review" :-D > **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. This means that if the fix is not committed (rebased?) in that weekly timerfame the problematic patch is automatically pushed to stable without a fix; also we'll have that problematic commit in stable anyway (affecting users like me that are "pinning" specific channels?), unless we rebase "unstable"... "manually": am I wrong? With a patch-dedicated git branch the reviewer can work at his preferred pace on that patch, rebasing /when/ (not if) needed, without the risk a problematic commit will be auto-committed. ...and yes: IMHO a linear git history avoiding merges is very useful. > It reduces a bit the pressure on the committers, IMHO. It raises a bit the pressure on the maintainers, IMHO :-) IMVHO there is no effective "workarond" from proper patch review work. I understand there is a certain "entrance barrier" to become patch reviewer, but I'm afraid we cannot lower it more than the current situation except for the offload build server and more tolling options. [...] Than you founders! Thank you maintainers! Thank you committers! ...and than you Simon and all for this constructive discussions! Happy Hacking! Gio' P.S. when considering how much easy or difficult is to contribute to Guix as a software distribution we should also look at the contribution workflow model and tooling of other distributions, rolling and not-rolling (e.g. Opensuse, Debian): AFAIU we are not so bad at this compared to others (except probably the number of "package maintainers") :-D -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
