Guix Hurd at… Guix@Paris! [Was: GNU Hurd at Guix days]
Dear Guix, Yesterday, during the Guix@Paris S02E05 we talked about what happened during Guix Days 2024 and… about the Hurd session. I demoed my shiny new ChildHurd offload-able setup and… some one did the setup live on his laptop, reconfigured and built it’s first package for `i586-gnu` in less than 5 min! Thanks to all those who, over the years, have helped to bring the entry cost down to such a low level it's almost indecent! May 2024 be the year of the Hurd! 爛 Regards. -- Tanguy
Re: [fr] Moment de convivialité Guix@Paris en février
(Warning: this email is in french because the meeting is supposed to be held in French… and in person.) Bonjour Guix, Merci à ceux qui se sont déplacés hier soir pour participer au Guix@Paris S02E05 ! … et à celui qui a eu le courage et la patience de participer *via* la vidéo conférence. … merci d’avoir rendu cette soirée pa-ssio-nnante ! Je ne suis pas sûr d’avoir tout compris, mais c’était vraiment super intéressant ! Au plaisir de recommencer le mois prochain ! Excellent début de journée et fin de semaine ! -- Tanguy
Re: Guix Days: Patch flow discussion
On 2/6/24 05:39, Steve George wrote: > I agreed to organise some 'patch review' online sessions in the next couple of > weeks. > > Organising a basic process is a good topic for that online session. For > example, elsewhere in the thread someone mentions some tags we could use > consistently so maintainers can find patches that have been reviewed easily. > It > would be great to agree those - try them for a bit - and document them in a > 'howto' so that everyone uses the same process. Have these been announced somewhere yet (eg, with url & exact time)? If not will being subscribed to the help-guix list and/or checking the Guix blog be sufficient to receive notification? As someone who has sent patches in the past and intends to continue sending more in the future, I'd like to do my part to keep the project in a good state. However, I am new to interacting with large FLOSS projects so I'm nervous about causing more problems than I solve if I just start doing things.
How to file Mumi bugs
Hi, An effort is under way to bring Mumi [1] and Debbugs [2] closer together. It's like a giant tongue twister! Bugs filed against Mumi are in the process of being re-assigned from 'guix' to the 'mumi' package in Debbugs. For the time being, those bugs may not show up in Mumi anymore, but only in Debbugs. They may appear in Mumi again in the future. Please continue to submit patches and bug reports intended for Guix the way you have. Those filings are not affected. For issues with Mumi or its command-line tool, however, please send bugs to sub...@debbugs.gnu.org with a first line that reads Package: mumi Filing instructions are also available here: https://debbugs.gnu.org/Reporting.html Please do not send Mumi bug reports to bug-g...@gnu.org anymore. For help, please reply narrowly to this message (i.e. pick a list). Thank you! Kind regards on behalf of the Debbugs and Mumi maintainers, Felix [1] https://debbugs.gnu.org [2] https://issues.guix.gnu.org [3] https://debbugs.gnu.org/Reporting.html
Re: %base-packages and default grub theme depend on rust
Efraim Flashner writes: Hi, > 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? That would be nice. FWIW, I shortly attempted to get rid of rust for building a hurd-vm on my `wip-sans-rust' branch, branched off core-updates https://gitlab.com/janneke/guix/-/commits/wip-sans-rust/?ref_type=heads a7b2251c6e gnu: grub-minimal: Remove rust dependency. 6406eefe2a gnu: libsoup-minimal: Remove rust dependency. 753c872fb7 squash! gnu: qemu-minimal: Remove rust dependency. 417cbc8aa7 gnu: qemu-minimal: Remove rust dependency. f3b5d38664 gnu: guix-icons: Remove rust dependency. adf9ceeb2f gnu: Add guile-rsvg-sans-rust. but didn't get anywhere really in the end. Greetings, Janneke -- Janneke Nieuwenhuizen | GNU LilyPond https://LilyPond.org Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com
Re: %base-packages and default grub theme depend on rust
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? -- 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
patch workflow without emacs (Was: Re: Guix Days: Patch flow discussion)
On Mon, Feb 05, 2024 at 10:50:36PM +, Steve George wrote:
> Hi Hartmut,
>
> Apologies, my reply-to went a bit mad and I sent you empty emails :-(
>
> You said:
>
> > The current mail-based workflow is too complicated for new and
> > occasional committers. This is the main reason I gave up reviewing patches.
> >
>
> In the case of *reviewing patches* can you give some examples of:
>
> 1. Some patches from others you reviewed?
> 2. The steps you went through to undertake that review?
>
> If for example, you started to review a simple update to a package how do you
> aproach it?
>
> It would be great to hear directly from someone doing 'reviewing' on the
> specifics. Apologies, if this is going over old ground.
First step is choosing a package to review. I normally start with ones
that are emailed to me directly as part of the rust-team.
I now have an email thread with between 20 and 150 patches to review. (I
start by looking through some of them manually to see if they look like
they're following conventions, ie: 1 change per patch. Assuming they
generally look good,) I start with the first patch and, from mutt, I
pipe the patch to 'cd ~/workspace/guix; git am -S -s'. I then compare
the commit message to the contents of the patch, looking at it in 'tig',
a TUI git interface, and will adjust the patch and/or the commit message
as necessary. Then I try to build the package(s) changed by the patch
set so far. When I'm happy with how it looks I'll pipe the next patch
from mutt to check out.
Once I reach the end of a patch series, or after a bunch of patches,
I'll look through the set I've applied to make sure I'm still happy with
them as a whole (update the package and then remove it?) and then
continue on. At the end, when I'm happy with it, I'll reply to the
first or last email, detail a bit what changes I've made, and tell them
that I've applied the patches. I then save the email in my drafts folder
and move on to the next patch series I'm going to look at. At the end,
after rebasing everything on top of wherever the branch moved to while I
was working, I'll push my branch to Savannah and then send off the
emails.
If I come across a patch that I'd like changes to before committing I'll
either add them inline ('v' in mutt to see the parts of the email,
choose the part with the patch, 'g' to reply-all, and then add them
inline), or I'll apply it and then reply to the original email with the
diff ('git diff -p > ~/changes-to-.diff', attach in reply email) and
some text in the header about the changes. I then throw out my local
changes since they're either where I can recover it from the email or in
my git stash.
If I choose a package from qa.guix.gnu.org to review I'll pick one and
note the number. I go to my checkout, 'git fetch --all' to refresh my
checkouts¹, open it with tig, switch to the branches view (with 'r'),
find the patchset (guix-patches/issue-X), and then with 'C' I'll
cherry-pick all the patches from the patchset in one go. I then look
them over one at at time in tig like above, and I'll make any changes to
either 'squash' or 'fixup' onto specific patches later when I go over it
with 'git rebase -i'.
Some notes: I've never figured out how to use emacs, much less emacs and
debbugs. My only interaction with debbugs is to open or close bugs; I
do not know how to look at user tags, or any other tags, in debbugs,
although I would guess that it might be possible from the web frontend.
Similarly, I don't know if a bug has been closed by someone else, I just
assume it to be so when a patch is applied or if I see it said so in an
email. I use vim-fugitive (and editorconfig I guess) as my only plugin
for working with git.
¹ https://git.guix-patches.cbaines.net/git/guix-patches is the location
where the patchsets are stored in a git repo
--
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
