Re: Guix Days: Patch flow discussion
Hello Dan, thanks for your thoughts! I think I will restrict my replies to guix-devel to keep them in one place; the following are just my personal opinions. Am Thu, Feb 29, 2024 at 03:41:41PM + schrieb Daniel Littlewood: > Something that is not obvious to me when people refer to reviewing patches, is > whether this is purely a matter of adding new packages to the main guix > channel, or of reviewing changes to the system in general, or both. As a > novice, I can imagine becoming comfortable as a package reviewer much more > quickly than as a reviewer of core patches to the system. Both! And indeed what you write is correct, reviewing packages is easier than services, which is probably easier than other changes. (Personally, I feel confident only with packages.) Of course then people should only review things they are comfortable with. > It's also not obvious to me whether you mean exactly "reviewing a backlog of > existing patches" or additionally "increasing the amount of patches submitted > and applied". I feel like both are probably good things but I can't tell what > you're focussing on exactly. If lots of gems were imported from other repos > like RubyGems and PyPi, which as I understand it is currently a > partly-automatic partly-manual process, would that be considered a win? What > about increasing version coverage among those packages that are covered? The discussion was about the backlog; in particular also about negative feelings by contributors of patches that take a long time to be applied. Of course adding more packages is also a welcome activitiy (but only makes sense if enough of them are applied in the end...). We concentrated on "reviewing" to ease the burden of "committers", since reviewing is open to anybody. > One point brought up here is about tooling. I wonder whether there is any > scope > for fully automatic review. I do not think so. Quality is an important aspect of Guix; for instance, we ask for non-marketing descriptions, which would be difficult to test automatically. We already have "guix lint", which does some of the work. And there are fully automated channels such as for CRAN, but which then are potentially of a lesser quality. Notice that "easy" packages are also easy to review; most of the time, there is not much to do about the result of "guix import pypi ...". Things become more tricky when phases need to be added, to understand what is going on, and then I usually also look at comments (or criticise their absence). > I think some people are just scared off socially by the idea of having to > join a > meeting in order to learn how to do reviews well. Agreed, there should not be any "having to join a meeting". The idea of organising one comes from the goal of making the activity more social and less boring. Apart from that, you can start today and need not wait for a bug squashing party :) Andreas
Re: You're invited to the first patch review session!
Am Thu, Feb 29, 2024 at 05:10:56PM + schrieb Daniel Littlewood: > * I think the meeting is at 18:00 UTC, which is the same as 18:00 GMT, > which is the same (on March 7th) as 18:00 London time > Meetup also says 18:00 GMT. Yes, that is the plan! Andreas
Re: Creating 2024 internship page
Hello, Am Thu, Feb 29, 2024 at 12:28:29AM +0100 schrieb Gábor Boskovits: > I had a look at the libreplanet today and tried to add an internship page for > 2024, but it look like I have no permission to create a page in the guix > group. > It also shows me the group main page as protected. Can someone arrange access > for me or create the page and send me the link. It looks like I can edit pages > without any issue once they are created. I do not know where I gathered this magical power, but I can create pages; here it should be: https://libreplanet.org/wiki/Group:Guix/Outreachy-2024 Strangely, it is not (yet?) referenced from the main page https://libreplanet.org/wiki/Group:Guix but I hope it can get you going. Andreas
Re: Rust team branch merged
On Thu, Feb 29, 2024, at 02:11, Efraim Flashner wrote: > * Most of the packages in rust-apps have been upgraded. > * rav1e was upgraded from 0.6.6 to 0.7.1 > * dav1d was upgraded from 1.0.0 to 1.3.0 > * libaom was upgraded from 3.5.0 to 3.8.0 Thanks for updating these AV1 video packages!
LWN: A look at Nix and Guix
Hi everyone, LWN published an article about Nix and Guix: https://lwn.net/SubscriberLink/962788/4127dcbb2cf72474/ It raises our public profile, although I am a bit more enthusiastic than the author. I think we are the next Debian. Do we have a PR department? Just kidding... Kind regards Felix P.S. LWN requires a subscription but they encourage the distribution of free links to project mailing lists. [1] That way, potential subscribers can sample their content. If you find LWN interesting, please ask your employer for a subscription to LWN. [1] https://lwn.net/op/FAQ.lwn#slinks
Re: [fr] Moment de convivialité Guix@Paris en mars
Bonjour Thomas, Quoting Thomas Ieong (2024-02-29 14:49:36) > Ca fait un moment que j'ai envie de venir mais les dates s'accordaient > pas, j'ai enfin du temps ;) Comme quoi, il ne faut jamais se décourager ! À dans 2 semaines alors. -- Tanguy
Re: [fr] Moment de convivialité Guix@Paris en mars
Salut, Ca fait un moment que j'ai envie de venir mais les dates s'accordaient pas, j'ai enfin du temps ;) Au plaisir ! -- Thomas Ieong
on the bug tracker (Re: Guix Days: Patch flow discussion)
Hi Josselin, Josselin Poiret writes: [...] > One thing I would like to get rid of though is debbugs. given that a significant part of the Guix infrastructure is provided by the GNU project, including the bug/issue tracker, and I don't think that GNU will replace https://debbugs.gnu.org/ (or the forge, Savannah) with something else, I suggest to concentrate the Guix community efforts in giving contributors better user interfaces to Debbugs, e.g Mumi (web and CLI) instead of trying to get rid of it. In other words: the "problem" it's not the tool, it's the *interface*. Please also consider that if (I hope not) the Guix would decide to adopt a different bug/issue tracker system then Someome™ will have to administrate it, and currently there are other pieces of core infrastructure that need more resources, e.g. QA. Speaking of interface features, I simply *love* the email based interface provided by Debbugs [1]; also the web UI is not bad, and the Mumi one (https://issues.guix.gnu.org/) it's even better. But I'm curious: what bug tracker would you suggest instead of Debbugs? Let's see what some "big players" are using... > It causes a lot of pain for everyone, eg. when sending patchsets, it > completely breaks modern email because it insists on rewriting > DMARC-protected headers, thus needing to also rewrite "From:" to avoid > DMARC errors. I don't understand what "completely breaks modern email" means: please could you point me to a document where this issue/bug is documented? > I've been following the Linux kernel development a bit closer this past > year, and while there are things that need to improve (like knowing the > status of a patchset in a maintainer's tree), they at least have a lot > of tools that I think we should adopt more broadly: you mention: b4/lei and patchwork but they are not bug/issue trackers. the Linux kernel community is using https://bugzilla.kernel.org/; RedHat, Fedora, OpenSUSE and SUSE are also using Bugzilla Arch Linux have adopted GitLab issues Other alternavives: https://en.wikipedia.org/wiki/Comparison_of_issue-tracking_systems ...or: https://en.wikipedia.org/wiki/Bug_tracking_system#Distributed_bug_tracking I personally like the idea that the bug/issue tracker is _embedded_ (integrated?) in the DVCS used by the project, Git in Guix case. For this reason I find Tissue https://tissue.systemreboot.net/ an interesting project for *public* issue/bug tracking systems, also because Tissue is _not_ discussion-oriented: this means that discussions are managed "somewhere else", because «It's much better to have a clear succinct actionable issue report. This way, the issue tracker is a list of clear actionable items rather than a mess of unreproducible issues.» [2] Happy hacking! Gio' [...] [1] https://debbugs.gnu.org/server-control.html [2] https://tissue.systemreboot.net/manual/dev/en/#section11795 -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
Re: %base-packages and default grub theme depend on rust
Efraim Flashner writes: > On Thu, Feb 08, 2024 at 02:33:35PM +0200, Efraim Flashner wrote: >> On Mon, Jan 29, 2024 at 05:36:52PM +0100, Ludovic Courtès wrote: >> > Hi, >> > >> > Vagrant Cascadian skribis: >> > >> > > This is because the default grub theme generates a .png from an .svg >> > > ... using guile-rsvg, which uses librsvg, which uses rust ... >> > >> > How about using a guile-rsvg variant that depends on ‘librsvg-2.40’, the >> > last version written in C? >> > >> > That’s easy to do and would address the immediate problem. >> >> I bet we could switch it to use guile-cairo. Also, is guile-png too low >> level? > > My experiments with this didn't show it as possible. > > I like vagrant's idea about using the older librsvg for the guile-rsvg > used here, or just pre-generating the png itself and adding it to the > guix-artwork repo and using it from there. FWIW, I tried to take a stab at this and made some progress https://gitlab.com/janneke/guix/-/commits/wip-sans-rust/ --8<---cut here---start->8--- gnu: grub-minimal: Remove rust dependency. gnu: libsoup-minimal: Remove rust dependency. squash! gnu: qemu-minimal: Remove rust dependency. gnu: qemu-minimal: Remove rust dependency. gnu: guix-icons: Remove rust dependency. gnu: Add guile-rsvg-sans-rust. --8<---cut here---end--->8--- but qemu-minimal is kinda obnoxious to build without documentation (which depends on rust!). -- Janneke Nieuwenhuizen | GNU LilyPond https://LilyPond.org Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com
