Re: Progress with automating testing of patches

[Ludovic Courtès]

Hi,

Christopher Baines  skribis:

> Ludovic Courtès  writes:
>
>> I wonder if it’s due to recent changes since I last looked, but I’m a
>> bit confused by the numbers in this example:
>>
>>   https://qa.guix.gnu.org/issue/58186
>>
>> The numbers before/after patches don’t match and the lint warnings (nice
>> addition!) appear to unrelated to the patch at hand.
>>
>> Any idea what’s going on?
>
> I've had an initial look. One important clue is that the basis of the
> comparison [1] differs between data.qa.guix.gnu.org and
> data.guix.gnu.org [2]. The package number differs for example.
>
> 1: 
> https://data.qa.guix.gnu.org/revision/e6777cfa5eb5e9c36eaf7810b42cac0fbcaa367c
> 2: https://data.guix.gnu.org/revision/e6777cfa5eb5e9c36eaf7810b42cac0fbcaa367c
>
> That shouldn't happen, one revision of Guix should have the same number
> of packages regardless of what server looked at it. This being wrong
> explains the bad data on qa.guix.gnu.org, since the comparison being
> done by data.qa.guix.gnu.org is based on bad data.

OK, I see.

BTW, why do we have both data.qa.guix and data.guix?  These are both
instances of the same service, right?

Thanks,
Ludo’.

Re: substitute derivation: also substitute grafts?

[Ludovic Courtès]

Hi,

Ricardo Wurmus  skribis:

> In my scenario I have two machines, one building stuff the other only
> substituting.  The serving machine would be the one deciding whether to
> enforce substitutability or not.

An is it too expensive for that machine to build grafts locally?

Ludo’.

Re: Advanced network configuration

[Ludovic Courtès]

Hi Alexey,

(Cc: Julien, author of Guile-Netlink.)

Alexey Abramov  skribis:

> 1. I have servers with multiple network cards. Let's say, the management
> one and production. both network cards have multiple interfaces, which I
> need to bond into 803.1ad mode. Management bond has a native vlan where
> DHCP should be provided AND another vlan for the management traffic. The
> production interface (after bonding) has another set of VLANs for a
> different type of traffic as well. Currently, there is no way to define
> it without writing a custom service with the iproute2 utility.
>
> I was hacking on guile-netlink and did some progress with setting
> bonds. However current static configuration won't let me build it
> anyway. I have to not only 'link-add' and create a bond, but also amend
> existing interfaces by 'link-set' them as a slave to my newly created
> bond master for example.

I’m sure your improvements to Guile-Netlink would be welcome.

Regarding ‘static-networking’ in Guix, the goal was to allow it to be as
expressive as the underlying netlink interface, but clearly we focused
on the most common use cases.

If you can think of how you’d like to represent these setups in
‘static-networking’ (perhaps a ‘bonds’ field similar to the netplan YAML
snippet you showed?), we (or you :-)) can try and implement it.

> 2. Having a router with Guix at home. I have to run multiple services
> that provision 'networking' which is not allowed right now. The DHCP
> client service is greedy right now and binds to all available
> interfaces. I sent a [1] patch to solve this. However, I cannot define
> dhcp-client and static configuration at the same time anyway.

OK, we could allow users to change the Shepherd service name used by the
DHCP client then.

> These two examples lead me to the following questions:
>
> 1) To configure the network, I have been happily using netplan app
> (debain/ubuntu world). The specification they use can be found here
> [2]. Here is an example:

[...]

> From the example above, you can see that I rename interfaces (i do know
> that udev can do it, but it is easier to do it here). I build bonds and
> VLANs with their IPs. I also set routes and default gateway. Would
> someone be interested in that? I don't see any problems in implementing
> this with guile-netlink. This is basically my proposal on how we can
> improve our static network configuration. What do you think?

I’m all for it!  This should be done in a way that preserves
compatibility with the existing  record as much as
possible.

> 2) In Systemd world there is a notion of 'target' which is used for
> *grouping* units and *synchronization* points during the start-up.
>
> At this moment *I* need to have dhcp-client and static
> configuration. Seems like grouping is a key here. Were there any
> ideas/attempts to make it happen? Or what should I do? 

I’m not sure.  IIUC, a “networking target” here could translate to a
Shepherd service that depends on all the relevant DHCP and static
networking services.  The question the becomes how to express that
grouping conveniently.

Thanks,
Ludo’.

Re: Progress with automating testing of patches

[Christopher Baines]

Ludovic Courtès  writes:

> Hi,
>
> Christopher Baines  skribis:
>
>> Ludovic Courtès  writes:
>>
>>> I wonder if it’s due to recent changes since I last looked, but I’m a
>>> bit confused by the numbers in this example:
>>>
>>>   https://qa.guix.gnu.org/issue/58186
>>>
>>> The numbers before/after patches don’t match and the lint warnings (nice
>>> addition!) appear to unrelated to the patch at hand.
>>>
>>> Any idea what’s going on?
>>
>> I've had an initial look. One important clue is that the basis of the
>> comparison [1] differs between data.qa.guix.gnu.org and
>> data.guix.gnu.org [2]. The package number differs for example.
>>
>> 1: 
>> https://data.qa.guix.gnu.org/revision/e6777cfa5eb5e9c36eaf7810b42cac0fbcaa367c
>> 2: 
>> https://data.guix.gnu.org/revision/e6777cfa5eb5e9c36eaf7810b42cac0fbcaa367c
>>
>> That shouldn't happen, one revision of Guix should have the same number
>> of packages regardless of what server looked at it. This being wrong
>> explains the bad data on qa.guix.gnu.org, since the comparison being
>> done by data.qa.guix.gnu.org is based on bad data.
>
> OK, I see.
>
> BTW, why do we have both data.qa.guix and data.guix?  These are both
> instances of the same service, right?

Yep, but the configuration is different.

data.guix.gnu.org just tracks the master branch, and doesn't delete any
data.

data.qa.guix.gnu.org tracks all branches in the main Guix repository,
plus branches for issues, and regularly deletes revisions where they're
either old or the branch no longer exists.

There's nothing technically preventing just using one instance for both
purposes, it's just operationally I thought it would be easier to split
the concerns across two instances.


signature.asc
Description: PGP signature

Re: substitute derivation: also substitute grafts?

[Ricardo Wurmus]

Ludovic Courtès  writes:

> Ricardo Wurmus  skribis:
>
>> In my scenario I have two machines, one building stuff the other only
>> substituting.  The serving machine would be the one deciding whether to
>> enforce substitutability or not.
>
> An is it too expensive for that machine to build grafts locally?

It’s a matter of time.  Having prepared the environment previously on
another fast machine I’d like to avoid repeating the same work again on
a slow machine.

We needn’t restrict ourselves to substitutions — if “guix copy” could
work without first having to set up SSH that would be an equally valid
solution to this problem.

-- 
Ricardo

Re: Notes from discussion on Quality Assurance from the 10 Years of Guix event

[Tanguy LE CARROUR]

Hi Chris,


Quoting Christopher Baines (2022-09-18 17:55:30)
> Here are some notes I took during the discussion on patch review/quality
> assurance at the 10 Years of Guix event.

Thanks for the notes!

After months not contributing, today, I've started contributing patches
again!
Seems like I've forgotten everything, so I can give you a fresh look
at the process…


>   - Minimise the burden for submitters
> - Lengthy guidance for submitting patches

Actually, the `16.4 Packaging Guidelines` and `16.6 Submitting Patches`
are everything that I've ever looked for.

The only problem is `16.5.4 Formatting Code` that makes use of 
`./etc/indent-code.el`
that was removed back in January.


> - Changelog format

"format" and "content".

I've heard about a magic trick in Emacs, but as a user of "the other editor",
I have to write everything manually.

I guess one could write a command that would detect what has changed and
write the changelog. This could also be used on the reviewer/qa side to
check if the patch actually does what it says it does.


> - Sending patches by email (git send-email)

This one is an easy one!… at least, as long a you only have 1 patch.
For a patch set, one has to generate a cover letter, send it, wait for
a bug id to be assigned then send the rest of the patch set.
Looks trivial, but (too) many times I ended up creating multiple bug
reports for the same patch set. And the fear of messing up the bug report system
was something that discouraged me at the beginning. I still do some
mistake from time to time, but… I do not care any more, because I now
know how to fix them.


> - Delay in feedback for first time submitters

It doesn't actually have to be a human feedback. But being able to know
that everything went well (or not) and what's the status of a patch is
would be great.


> - Learn how to review more patches

Also learn how to review your first patch! Being able to push a "+1"
button in the QA interface might be useful?
For the time being, I don't know what feedback from me could be useful
for a commiter and how to provide it.


> - Doing useful things with little time

Go through the list of "Update to X.Y.Z." patches, have a quick glance
and push the "+1" button?


> Actions:
>  - teams thing for finding out about patches, automate this somehow
>  - generate a web page listing the people and teams
>  - Filtered subscription to patches by team

What the status on this? Where can I learn more about how teams work?


>  - Maybe script making contributions like updating packages
>  - Make a similar tool to Debian's how can I help
>- Try to avoid suggesting updating packages with lots of dependencies

`guix how-can-i-help` would be amazing! Something that would:
- list all the packages in my current profile that can be updated,
  sorted by number of dependent packages; and
- list all the packages in my profile that are currently broken.

Actually, for the second point, I guess I'll figure out when upgrading
my profile. Or maybe `guix weather` can help!?

I guess I'll have to dive more into QA, Data Service, Weather to be of
any help. But if you see anything that requires zero-knowledge just let
me know! 😁

Regards,

-- 
Tanguy

Re: Notes from discussion on Quality Assurance from the 10 Years of Guix event

[Christopher Baines]

Tanguy LE CARROUR  writes:

>>   - Minimise the burden for submitters
>> - Lengthy guidance for submitting patches
>
> Actually, the `16.4 Packaging Guidelines` and `16.6 Submitting Patches`
> are everything that I've ever looked for.

I think the point here is that the Submitting Patches section is quite
long.

> The only problem is `16.5.4 Formatting Code` that makes use of 
> `./etc/indent-code.el`
> that was removed back in January.

The latest version of the manual suggests using guix style, so this is
maybe a problem limited to old versions of the manual?

>> - Changelog format
>
> "format" and "content".
>
> I've heard about a magic trick in Emacs, but as a user of "the other editor",
> I have to write everything manually.
>
> I guess one could write a command that would detect what has changed and
> write the changelog. This could also be used on the reviewer/qa side to
> check if the patch actually does what it says it does.

I think there's room for improvement here in terms of telling people not
to worry about it too much, plus providing more guidance on the format
and common examples.

There's also tooling like the etc/committer.scm script which I don't
know anything about really, but it seems to handle writing this message
in some cases.

>> - Sending patches by email (git send-email)
>
> This one is an easy one!… at least, as long a you only have 1 patch.
> For a patch set, one has to generate a cover letter, send it, wait for
> a bug id to be assigned then send the rest of the patch set.
> Looks trivial, but (too) many times I ended up creating multiple bug
> reports for the same patch set. And the fear of messing up the bug report 
> system
> was something that discouraged me at the beginning. I still do some
> mistake from time to time, but… I do not care any more, because I now
> know how to fix them.

Indeed, this is still an issue.

>> - Delay in feedback for first time submitters
>
> It doesn't actually have to be a human feedback. But being able to know
> that everything went well (or not) and what's the status of a patch is
> would be great.

Yep, and I think we are getting close to being able to do that.

>> - Learn how to review more patches
>
> Also learn how to review your first patch! Being able to push a "+1"
> button in the QA interface might be useful?
> For the time being, I don't know what feedback from me could be useful
> for a commiter and how to provide it.

Yep, I think Arun had some useful ideas on this back in February
[1]. Particuarly including a checklist somewhere (issues.guix.gnu.org or
maybe qa.guix.gnu.org).

1: https://guix.gnu.org/en/blog/2022/online-guix-days-2022-announcement-2/

>> Actions:
>>  - teams thing for finding out about patches, automate this somehow
>>  - generate a web page listing the people and teams
>>  - Filtered subscription to patches by team
>
> What the status on this? Where can I learn more about how teams work?

There's been a few messages to guix-devel. It's not something I know
much about either.

From my perspective, I'd like to be able to use this information in the
qa-frontpage. I think the path to make that happen involves moving the
work currently done through Laminar to create the branches for patch
series in to the qa-frontpage, as that should make it easy to access the
files changed in a patch series.

>>  - Maybe script making contributions like updating packages
>>  - Make a similar tool to Debian's how can I help
>>- Try to avoid suggesting updating packages with lots of dependencies
>
> `guix how-can-i-help` would be amazing! Something that would:
> - list all the packages in my current profile that can be updated,
>   sorted by number of dependent packages; and
> - list all the packages in my profile that are currently broken.

Indeed :)

> Actually, for the second point, I guess I'll figure out when upgrading
> my profile. Or maybe `guix weather` can help!?
>
> I guess I'll have to dive more into QA, Data Service, Weather to be of
> any help. But if you see anything that requires zero-knowledge just let
> me know! 😁

Please let me know if I can help with any of this. The QA frontpage in
particular should have a bunch of easier things to do, and I've got a
rough list of tasks I put together here [2].

2: https://git.cbaines.net/guix/qa-frontpage/about/

Thanks,

Chris


signature.asc
Description: PGP signature

Maintainers meeting notes.

[Mathieu Othacehe]

Hello,

For the last six months or so, the maintainers have been conducting
monthly meetings on Jami.  They are scheduled every first Tuesday of the
month. It is often the occasion to plan some actions and discuss the
administration of the build farm.

The meeting notes are available here:
https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/maintainers/meetings

and the notes for the October meeting are here:
https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/maintainers/meetings/2022-10-04.org

Nothing super fancy, but we will try to post a small note here every
month in case some people might be interested.

Thanks,

Mathieu

Re: Progress with automating testing of patches

[jbranso]

October 1, 2022 1:08 PM, "Ludovic Courtès"  wrote:

> Hello!
> 
> As discussed in Paris, I’m a big fan of qa.guix.gnu.org! I like that it
> shows all the information relevant to packagers and reviewers in a
> concise way.
> 
> I wonder if it’s due to recent changes since I last looked, but I’m a
> bit confused by the numbers in this example:
> 
> https://qa.guix.gnu.org/issue/58186
> 
> The numbers before/after patches don’t match and the lint warnings (nice
> addition!) appear to unrelated to the patch at hand.
> 
> Any idea what’s going on?
> 
> Conversely,  looks fine, for
> example.
> 
> BTW, Emacs users, I have this key binding that I find useful:
> 
> --8<---cut here---start->8---
> (defun ludo-jump-to-guix-qa-url ()
> "Jump to the QA page of the Debbugs issue at point."
> (interactive)
> (let ((url (concat "https://qa.guix.gnu.org/issue";
> (number-to-string (debbugs-gnu-current-id)
> (browse-url url)))
> 
> (define-key debbugs-gnu-mode-map (kbd "C-M-j") 'ludo-jump-to-guix-qa-url)
> --8<---cut here---end--->8---

Would it make sense to add something like this to debbugs?

I just created a debbugs-guix.el file in debbugs.  The update should be
available on elpa by now.

https://issues.guix.gnu.org/56987

> 
> Thanks!
> 
> Ludo’.

Re: enter debugger on failure

[jgart]

Testing