Re: QA is back, who wants to review patches?

[Ian Eure]

Christopher Baines  writes:


[[PGP Signed Part:Undecided]]
Hey!

After substitute availability taking a bit of a dive recently, 
the
bordeaux build farm has finally caught back up and QA is back 
submitting

builds for packages changed by patches.

QA also has a feature to allow easily tagging patches (issues) 
as having
been reviewed and ready to merge (reviewed-looks-good). You can 
do this
via sending an email and QA has a form ("Mark patches as 
reviewed") on

the page for each issue to help you do this.

I'd encourage anyone and everyone to review patches, there's no 
burden

on you to spot every problem and you don't need any special
knowledge. You just need to not be involved (so you can't review 
your

own patches) and take a good look at the changes, mentioning any
questions that you have or problems that you spot. If you think 
the
changes look good to be merged, you can tag the issue 
accordingly.


When issues are tagged as reviewed-looks-good, QA will display 
them in
dark green at the top of the list of patches, so it's on those 
with
commit access to prioritise looking at these issues and merging 
the

patches if indeed they are ready.

Let me know if you have any comments or questions!



Wanted to check things out, but it’s giving the same error message 
on every page:


   An error occurred

   Sorry about that!
   misc-error

   #fvector->list: expected vector, got ~S#f#f

Also, the certificate for issues.guix.gnu.org expired today.

Is there a plan to improve the reliability Guix infrastructure? 
It seems like major things break with alarming regularity.


 — Ian

Re: Guix Days: Patch flow discussion

[Clément Lassieur]

On Sun, Feb 11 2024, Felix Lechner via "Development of GNU Guix and the GNU 
System distribution." wrote:

> Hi Clément,
>
> On Sun, Feb 11 2024, Clément Lassieur wrote:
>
>> On Sun, Feb 11 2024, Felix Lechner via "Development of GNU Guix and the GNU 
>> System distribution." wrote:
>>
>> Each email has its own message id, so how would you group them?
>
> As author, I'll respond.

Oh sorry Felix, I'm tired

> I was thinking of the In-Reply-To: or the
> References: fields from RFC 2822. [1]

Ok thx.

> Kind regards
> Felix
>
> [1] https://datatracker.ietf.org/doc/html/rfc2822#section-3.6.4

Re: Guix Days: Patch flow discussion

[Development of GNU Guix and the GNU System distribution.]

Hi Clément,

On Sun, Feb 11 2024, Clément Lassieur wrote:

> On Sun, Feb 11 2024, Felix Lechner via "Development of GNU Guix and the GNU 
> System distribution." wrote:
>
> Each email has its own message id, so how would you group them?

As author, I'll respond. I was thinking of the In-Reply-To: or the
References: fields from RFC 2822. [1]

Kind regards
Felix

[1] https://datatracker.ietf.org/doc/html/rfc2822#section-3.6.4

Keyboard layout in GRUB (Was: On the road to the next release: testing the installer)

[Development of GNU Guix and the GNU System distribution.]

[unable to locate Romain's original message]

Hi Josselin,

On Sat, Feb 10 2024, Josselin Poiret wrote:

> The idea would be to ... make sure that keyboard-layout-config appears
> first in the generated config.

I do not suffer from the issue described here but rewrote the bootloader
code locally for more flexibility (and may be able to contribute
it). Could we simply move the reference to keyboard-layout-config here
up by a few lines?  [1]

On a side note, should issues like this be discussed in bugs on
Debbugs/Mumi?

Kind regards
Felix

[1] https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/bootloader/grub.scm#n515

Re: Guix Days: Patch flow discussion

[Clément Lassieur]

On Sun, Feb 11 2024, Felix Lechner via "Development of GNU Guix and the GNU 
System distribution." wrote:

> Hi Josselin,
>
> On Wed, Feb 07 2024, Josselin Poiret wrote:
>
>> The fact that you have to wait for Debbugs's response after the first
>> mail to get the proper mail to reply to means that we can't automate
>> sending whole patchsets
>
> Could a modified version of Debbugs group submissions by Message-IDs
> instead of bug numbers? Would it allow subsequent emails to be sent
> before the initial message was acknowledged?

Hi Josselin, what do you mean?  Each email has its own message id, so
how would you group them?

Cheers
Clément

Re: Guix Days: Patch flow discussion

[Development of GNU Guix and the GNU System distribution.]

Hi Josselin,

On Wed, Feb 07 2024, Josselin Poiret wrote:

> The fact that you have to wait for Debbugs's response after the first
> mail to get the proper mail to reply to means that we can't automate
> sending whole patchsets

Could a modified version of Debbugs group submissions by Message-IDs
instead of bug numbers? Would it allow subsequent emails to be sent
before the initial message was acknowledged?

Kind regards
Felix

Re: Guix Days: Patch flow discussion

[Vagrant Cascadian]

On 2024-02-07, Josselin Poiret wrote:
> The fact that you have to wait for Debbugs's response after the first
> mail to get the proper mail to reply to means that we can't automate
> sending whole patchsets, and have to resort to hacks like the CLI `mumi`
> tool uses.  I can't just send a patchset and be done with it, I have to
> wait a couple minutes.

Well, that is a conflict between guix policies/practices and
debbugs.

Debbugs handles sending multiple patches in a single email just fine,
which can be done on the initial submission.

That has downsides with regards to threading, but given all the current
limitations, I wonder if the downsides of having to wait for the initial
bug number to land are worth the cost of having to implement a
user-interface tool (mumi CLI) to workaround it.

That said, the tool already exists... but not everyone is aware of it or
for whatever reason is not necesarily using it.

Are there other downsides to allowing a multiple patches in a single
email?

Ideally the technology would fit whatever practicies guix would like to
implement... but then we have what we have right now.

live well,
  vagrant


signature.asc
Description: PGP signature

Re: ice-9 match penalty depending on pattern?

[Simon Tournier]

Hi,

On mer., 07 févr. 2024 at 10:41, Carlo Zancanaro  wrote:

>> Why not?  Do I miss something in the implementation of ’match’?
>
> The only reason I can think of would be if these matches are sometimes
> provided improper lists, which need to fail these match conditions. That
> seems unlikely to me, but it should be clear from looking at the other
> match clauses in each case.

Well, I have not pruned the list returned by just grepping. :-)  And I
have just grepped with the term ’head’, ’tail’ and ’\.\.\.’

Somehow, my question is twofold:

1. Is the “expensive” check worth for such case:

  (match paths
((head tail ...)
 (if (visited? head)
 (loop tail visited result)
 (call-with-values
 (lambda ()
   (loop (references store head)
 (visit head)
 result))
   (lambda (visited result)
 (loop tail
   visited
   (cons head result))
(()
 (values visited result)

seen in ’topologically-sorted’ procedure from (guix store) module.

2. Is the “expensive” check worth for such multi-cases:

  (match sexp
((? string? str)
 (let ((prefix "swh:1:dir:"))
   (if (string-prefix? prefix str)
   (cons (string-drop str (string-length prefix)) ids)
   ids)))
((head tail ...)
 (loop tail (loop head ids)))
(_ ids))

seen in ’lookup-disarchive-spec’ from (guix lint).

Well, I am not saying to rely on ’car’ and ’cdr’.  Instead, I am asking
what is the idiomatic Guile pattern matching for Guile?

My main concern is about chasing the unnecessary checks for making Guix
a bit faster. :-)


Cheers,
simon

Re: Guix Days: Patch flow discussion

[Maxim Cournoyer]

Hi,

Kyle Meyer  writes:

> Hi Ricardo,
>
> Ricardo Wurmus writes:
>
>> Hi Josselin,
>
>>> They both can co-exist with debbugs, and for now the patchwork instance
>>> of QA is not usable for status tracking (because it is not meant to be
>>> used as such for now).  One can already use both of them, but using both
>>> supercedes debbugs, and gets rid of its limitations.  I've been using
>>> b4/lei with the yhetil public-inbox instance, with piem.el as an
>>> interface, and it's really useful.  With a properly configured b4, one
>>> could simply run `b4 shazam some-msg-id` and it would automatically
>>> apply the corresponding patchset.
>>
>> I’m interested in adopting this workflow.  Where can I find more
>> information on how to configure this?
>
> In 889a6204f8 (doc: Add some guidelines for reviewing, 2023-11-07),
> Maxim added some b4 configuration to Guix's etc/git/gitconfig that
> points at yhetil.org.  With that setup, running 'b4 shazam MESSAGE-ID'
> from a Guix checkout should work.

Indeed!  It should perhaps be more prominently documented, probably as
an new 'Reviewing patch work flows' section in the Guix Cookbook that
could be linked from our already lengthy Contributions section.

'b4 shazam' is probably the most trouble-free way to apply patches; it
even selects the latest revision it finds in the issue thread.  To make
finding a message-id easier, I've also recently added a 'Copy
Message-ID' button to the Mumi interface; try it visiting any issue,
e.g. .  The message-id of any message
can be easily copied to your clipboard via the new button.  From your
Guix checkout, you'd then run:

--8<---cut here---start->8---
$ b4 shazam 'cover.1707383694.git.h.goe...@crazy-compilers.com'
Looking up 
https://yhetil.org/guix/cover.1707383694.git.h.goe...@crazy-compilers.com
Grabbing thread from 
yhetil.org/guix/cover.1707383694.git.h.goe...@crazy-compilers.com/t.mbox.gz
Checking for newer revisions
Grabbing search results from lore.kernel.org
Nothing matching that query.
Analyzing 29 messages in the thread
---
  [PATCH 1/28] gnu: Add ruby-test-unit-ruby-core.
  [PATCH 2/28] gnu: Add ruby-excon.
  [PATCH 3/28] gnu: Add ruby-ipaddr.
  [PATCH 4/28] gnu: Add ruby-net-ftp.
  [PATCH 5/28] gnu: Add ruby-fake-ftp.
  [PATCH 6/28] gnu: Add ruby-net-sftp.
  [PATCH 7/28] gnu: Add ruby-net-telnet.
  [PATCH 8/28] gnu: Add ruby-pairing-heap.
  [PATCH 9/28] gnu: Add ruby-stringio.
  [PATCH 10/28] gnu: Add ruby-stream.
  [PATCH 11/28] gnu: Add ruby-rgl.
  [PATCH 12/28] gnu: Add ruby-sfl.
  [PATCH 13/28] gnu: Add ruby-specinfra.
  [PATCH 14/28] gnu: Add ruby-serverspec.
  [PATCH 15/28] gnu: Add ruby-time.
  [PATCH 16/28] gnu: Add ruby-google-protobuf.
  [PATCH 17/28] gnu: Add ruby-googleapis-common-protos-types.
  [PATCH 18/28] gnu: Add ruby-grpc.
  [PATCH 19/28] gnu: Add ruby-vagrant-cloud.
  [PATCH 20/28] gnu: Add ruby-vagrant-spec.
  [PATCH 21/28] gnu: Add ruby-vagrant-spec-helper-basic.
  [PATCH 22/28] gnu: Add ruby-hashicorp-checkpoint.
  [PATCH 23/28] gnu: ruby-childprocess: Update to 4.1.0.
  [PATCH 24/28] gnu: Add ruby-libvirt.
  [PATCH 25/28] gnu: Add ruby-fog-core.
  [PATCH 26/28] gnu: Add ruby-fog-json.
  [PATCH 27/28] gnu: Add ruby-fog-xml.
  [PATCH 28/28] gnu: Add ruby-fog-libvirt.
---
Total patches: 28
---
 Base: using specified base-commit a4464bd0975c811f18af98f69032b29bddda5b81
Application de  gnu: Add ruby-test-unit-ruby-core.
Application de  gnu: Add ruby-excon.
Application de  gnu: Add ruby-ipaddr.
Application de  gnu: Add ruby-net-ftp.
Application de  gnu: Add ruby-fake-ftp.
Application de  gnu: Add ruby-net-sftp.
Application de  gnu: Add ruby-net-telnet.
Application de  gnu: Add ruby-pairing-heap.
Application de  gnu: Add ruby-stringio.
Application de  gnu: Add ruby-stream.
Application de  gnu: Add ruby-rgl.
Application de  gnu: Add ruby-sfl.
Application de  gnu: Add ruby-specinfra.
Application de  gnu: Add ruby-serverspec.
Application de  gnu: Add ruby-time.
Application de  gnu: Add ruby-google-protobuf.
Application de  gnu: Add ruby-googleapis-common-protos-types.
Application de  gnu: Add ruby-grpc.
Application de  gnu: Add ruby-vagrant-cloud.
Application de  gnu: Add ruby-vagrant-spec.
Application de  gnu: Add ruby-vagrant-spec-helper-basic.
Application de  gnu: Add ruby-hashicorp-checkpoint.
Application de  gnu: ruby-childprocess: Update to 4.1.0.
Application de  gnu: Add ruby-libvirt.
Application de  gnu: Add ruby-fog-core.
Application de  gnu: Add ruby-fog-json.
Application de  gnu: Add ruby-fog-xml.
Application de  gnu: Add ruby-fog-libvirt.
--8<---cut here---end--->8---

and done!

-- 
Thanks,
Maxim

Gaming on Guix

[Tobias Alexandra Platen]

I am a libre game developer and I plan to package my game that I am
currently working on for Guix. On the long term I also want to make a
scalable distribution service that one can self host and which allows
paying for games using GNU Taler. Once the user has payed they can get
substitutes, if they don't want to pay, they still have the freedom
to build the game from source. I propose the name GNUtris for this
service. 

First I will make a home page using haunt for my game. Then I start
packaging ist dependencies, starting with libsurvive, which is needed
to use the Valve Index. Then I package the rest of the software,
needed to run the game. Finally I setup a sales/crowdfunding page,
this will be the harded part of my project. I heard that Taler will
soon go into production in the Euro zone.

PS: I try to avoid Steam, Nonguix and the Guix Gaming Channels

Re: Guix Days: Patch flow discussion

[Steve George]

On  9 Feb, Edouard Klein wrote:
> 
> Skyler Ferris  writes:
> 
> > 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.
> 
> Same here.
>

Hi Skyler & Edouard - you haven't missed an announcement :-) I'll get it 
organised next week and will mail out here - plus I'll email you both directly 
as you've both shown interest.

Thanks,

Steve / Futurile

Re: QA is back, who wants to review patches?

[Andreas Enge]

Am Fri, Feb 09, 2024 at 04:08:45PM +0100 schrieb Tanguy LE CARROUR:
> I’m "reviewing" `[bug#68997] gnu: lightning: Update to 2.2.3`… please
> find another one! 😁

Now that you jump to complicated and not even yet built by QA packages,
you are safe from my competition :)

Andreas