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

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

[Christopher Baines]

[-- Attachment #1: Type: text/plain, Size: 2199 bytes --]

Here are some notes I took during the discussion on patch review/quality
assurance at the 10 Years of Guix event.

Discussion:
- Find out how others review patches
  - Julian
    - Subscribe to guix-patches
    - Look at subjects
    - If not OCaml/Java/Maven, ignore email
    - If obvious issues can be seen, reply suggesting improvements
    - Run guix lint/build dependents
    - There are language/area specific things that are good to know
      about when reviewing patches

- How the process works
  - How we can improve quality of Guix, avoid breakages
  - How we can simplify the workflow for reviewers
  - Minimise the burden for submitters
    - Lengthy guidance for submitting patches
    - Changelog format
    - Sending patches by email (git send-email)
    - guix lint archive error
    - Delay in feedback for first time submitters

  - Problems
    - Already broken packages when applying updates

- How to help?

- Motivation to do more
  - Debian: How can I help tool?
- Learn how to review more patches
- Doing useful things with little time


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

 - Improve the qa.guix.gnu.org site
 - look at moving Mumi, QA Frontpage, ... on to Savannah
 - List infrastructure projects on a web page

 - More detailed guidance on the review process
 - Guidance for reviewers, e.g. don't ask for patch submitters to fix
   other problems
 - Split the guidance for submitting patches in to sections (bronze,
   silver, gold)
 - Give specific guidance for different tasks, so don't run lint if
   you're upgrading a package
 - Have some "trusted reviewer" status
 - Arrange focused time per month/week when people try to review patches
 - How should reviewers get patches merged when they don't have commit
   access?
 - 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

 - work out what is getting in the way of patches getting to the mailing
   list/debbugs
   - Put a warning about delays

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]

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]

[-- Attachment #1: Type: text/plain, Size: 4493 bytes --]


Tanguy LE CARROUR <tanguy@bioneland.org> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]

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

[Tanguy LE CARROUR]

Quoting Christopher Baines (2022-10-05 18:51:52)
> Tanguy LE CARROUR <tanguy@bioneland.org> 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.

You mean the 17 point list?! 😅



> > 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?


I read it there: <https://guix.gnu.org/manual/en/html_node/Formatting-Code.html>:

```shell
./etc/indent-code.el gnu/packages/file.scm package
```

If the online manual is considered an old version, where should I look
for the current documentation? Devel?

It seems to be up to date there, indeed:
<https://guix.gnu.org/en/manual/devel/en/guix.html#Formatting-Code>

```shell
./pre-inst-env guix style package
```


> >>     - 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.

```shell
$ ./pre-inst-env guix refresh -u csvkit
# […]
gnu/packages/wireservice.scm:205:13: csvkit: updating from version 1.0.5 to version 1.0.7...
# […]

$ guile etc/committer.scm
gnu: csvkit: Update to 1.0.7.

* gnu/packages/wireservice.scm (csvkit): Update to 1.0.7.
[master 715de68b73] gnu: csvkit: Update to 1.0.7.
 1 file changed, 2 insertions(+), 2 deletions(-)
```

Mind=blown™ 🤯

Thanks!!!


> >> - 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/

Added to my "to watch" list.


> 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/

First, I'll have to do my homework and read everything that's related to
QA and DataService. I'll let you know as soon as I've found something
useful to bring to the table.


-- 
Tanguy

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

[Tanguy LE CARROUR]

Hi Chris,

Quoting Tanguy LE CARROUR (2022-10-05 16:01:40)
> Quoting Christopher Baines (2022-09-18 17:55:30)
> > […]
> >  - 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

Just to let you know that, even if I haven't written `guix
how-can-i-help` (yet), I've just written a `guix-refresh-all` that tells me:

```console
$ guix-refresh-all
gnu/packages/freedesktop.scm:2164:13: udiskie would be upgraded from 2.3.3 to 2.4.2
gnu/packages/wm.scm:1584:13: sway would be upgraded from 1.6.1 to 1.7
gnu/packages/wireservice.scm:205:13: csvkit would be upgraded from 1.0.5 to 1.0.7
gnu/packages/mail.scm:610:13: neomutt would be upgraded from 20211029 to 20220429
gnu/packages/mpd.scm:445:13: cantata would be upgraded from 2.4.2 to 2.5.0
gnu/packages/mail.scm:1326:13: notmuch would be upgraded from 0.36 to 0.37
gnu/packages/rust-apps.scm:190:13: bat would be upgraded from 0.20.0 to 0.22.1
gnu/packages/wm.scm:1704:13: swaybg would be upgraded from 1.0 to 1.1.1
gnu/packages/terminals.scm:1334:13: alacritty would be upgraded from 0.9.0 to 0.16.0
gnu/packages/gnupg.scm:830:2: pinentry-gtk2 would be upgraded from 1.2.0 to 1.2.1
gnu/packages/linux.scm:8793:13: wireplumber would be upgraded from 0.4.11 to 0.4.12
gnu/packages/libreoffice.scm:1059:13: libreoffice would be upgraded from 7.3.5.2 to 7.4.2.3
gnu/packages/mpd.scm:112:13: mpd would be upgraded from 0.23.8 to 0.23.10
gnu/packages/linphone.scm:801:13: linphone-desktop would be upgraded from 4.2.5 to 4.4.10
gnu/packages/messaging.scm:2171:13: profanity would be upgraded from 0.13.0 to 0.13.1
gnu/packages/gnome.scm:3060:13: libnotify would be upgraded from 0.7.9 to 0.8.1
gnu/packages/gnupg.scm:287:13: gnupg would be upgraded from 2.2.32 to 2.3.8
gnu/packages/rust-apps.scm:455:13: fd would be upgraded from 8.1.1 to 8.4.0
gnu/packages/curl.scm:66:12: curl would be upgraded from 7.79.1 to 7.85.0
gnu/packages/terminals.scm:929:13: go-github-com-junegunn-fzf would be upgraded from 0.25.0 to 0.34.0
gnu/packages/xorg.scm:1767:13: setxkbmap would be upgraded from 1.3.2 to 1.3.3
gnu/packages/file.scm:65:13: file would be upgraded from 5.41 to 5.43
gnu/packages/ncurses.scm:45:13: ncurses would be upgraded from 6.2.20210619 to 6.3
```

So now, I know what I'll do tomorrow! 😅

This is no magic scheme, it's just an alias for:

```console
$ guix package -I | awk '{print $1}' | tr '\n' ' ' | xargs guix refresh 2>&1 | ag -v "already" | ag -v "failed" | ag -v "no updater" | ag -v "warning"
```

Yeah, I know… ugly! But, it does (part of) the job! 😎

Happy hacking!

-- 
Tanguy

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

[zimoun]

Hi Tanguy,

On Tue, 18 Oct 2022 at 18:19, Tanguy LE CARROUR <tanguy@bioneland.org> wrote:

> ```console
> $ guix package -I | awk '{print $1}' | tr '\n' ' ' | xargs guix refresh 2>&1 | ag -v "already" | ag -v "failed" | ag -v "no updater" | ag -v "warning"
> ```
>
> Yeah, I know… ugly! But, it does (part of) the job! 😎

Well, if you are using a manifest file, you can directly pass it to
’guix refresh‘.  Otherwise,

    guix package --export-manifest > /tmp/my-pkgs.scm
    guix refresh -m /tmp/my-pkgs.scm 2>&1 | ...

And even, being in a checkout of Guix,

    guix refresh -m /tmp/my-pkgs.scm --update

and then give a look at the script etc/committer.scm.


Cheers,
simon

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

[Tanguy LE CARROUR]

Hi Simon,

Sorry it took me so long to answer, but I've been struggling for the
past week with the upgrade of Poetry!! 😱
It requires updating `python-virtualenv` and `python-lockfile` and
suddenly a **LOT** of packages needed to be rebuilt/updated. #dependencyHell!
But that will definitively be the topic of a different thread…


Quoting zimoun (2022-10-19 11:57:15)
> On Tue, 18 Oct 2022 at 18:19, Tanguy LE CARROUR <tanguy@bioneland.org> wrote:
> 
> > ```console
> > $ guix package -I | awk '{print $1}' | tr '\n' ' ' | xargs guix refresh 2>&1 | ag -v "already" | ag -v "failed" | ag -v "no updater" | ag -v "warning"
> > ```
> >
> > Yeah, I know… ugly! But, it does (part of) the job! 😎
> 
> Well, if you are using a manifest file, you can directly pass it to
> ’guix refresh‘.  Otherwise,
> 
>     guix package --export-manifest > /tmp/my-pkgs.scm
>     guix refresh -m /tmp/my-pkgs.scm 2>&1 | ...

I'm not using manifest (anymore). I used to, but for the time being, I'm using
`divenv` + `guix shell` and I'm quite happy with that setup.


> And even, being in a checkout of Guix,
> 
>     guix refresh -m /tmp/my-pkgs.scm --update
> 
> and then give a look at the script etc/committer.scm.

That would create more patches than I could process I guess. I like the
idea of cherry-picking from the "need to be updated" list.
But `etc/committer.scm` is definitively a tool I was missing! Thanks!

Regards,

-- 
Tanguy

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

[zimoun]

Hi Tanguy,

On dim., 23 oct. 2022 at 17:40, Tanguy LE CARROUR <tanguy@bioneland.org> wrote:

>>     guix package --export-manifest > /tmp/my-pkgs.scm
>>     guix refresh -m /tmp/my-pkgs.scm 2>&1 | ...
>
> I'm not using manifest (anymore). I used to, but for the time being, I'm using
> `divenv` + `guix shell` and I'm quite happy with that setup.

Note that the first command above creates the manifest for you.
Usually, it works well enough. :-)

Well, ’direnv’ + ’guix shell’ but you have a manifest, no?  I mean how
does ’guix shell’ know what to provide inside this new shell?

For what it is worth, I have used similar workflow but I have been bored
to run “guix pull”, do some stuff unrelated to ’project’, then later be
back on ’project’ and then have failures.  Instead, my workflow is
splited into 2 ways depending on my phase of the Moon.  Either, I create
a profile inside the project directory.  Either, I use channels.scm +
manifest.scm and often run via ’guixify’ script (see below); e.g.,

    guixify foo # run foo using the Guix environment
    guixify     # enter in the environment

Maybe, ’direnv’ would do a better job.  The good point is that
channels.scm and manifest.scm are included in the Git tree of the
project.  And they can be re-used with ’guix pack -f docker -m
manifest.scm’ to generate Docker pack that I can share with colleagues.

--8<---------------cut here---------------start------------->8---
#!/bin/sh

guix time-machine -C channels.scm  \
     -- shell --pure               \
     -m manifest.scm               \
     -- $@
--8<---------------cut here---------------end--------------->8---



Cheers,
simon

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

[Tanguy LE CARROUR]

Hi Simon,


Quoting zimoun (2022-10-24 09:34:09)
> On dim., 23 oct. 2022 at 17:40, Tanguy LE CARROUR <tanguy@bioneland.org> wrote:
> 
> >>     guix package --export-manifest > /tmp/my-pkgs.scm
> >>     guix refresh -m /tmp/my-pkgs.scm 2>&1 | ...
> >
> > I'm not using manifest (anymore). I used to, but for the time being, I'm using
> > `divenv` + `guix shell` and I'm quite happy with that setup.
> 
> Note that the first command above creates the manifest for you.
> Usually, it works well enough. :-)

I guess the "problem" is that I'm a "pipe person". I just don't like
having to create a temp’ file.
But I agree that your solution is more elegant.


> Well, ’direnv’ + ’guix shell’ but you have a manifest, no?  I mean how
> does ’guix shell’ know what to provide inside this new shell?

I used to have a `manifest.scm` file. I even used to (silly me!) commit it
into the repository along side the project's code.
I recently realized that it was easier to only have a git-ignored
`.envrc` file containing:

```
use guix-shell python python-wrapper python-jedi poetry […]
```

The other project's dependencies are (still) managed by Poetry, so the
list passed to Guix shell is quite short.

Not that `guix-shell` is a custom function, for Direnv `guix` function
still uses `guix environment`. But this would also work:

```
use guix --ad-hoc python python-wrapper python-jedi poetry […]
```

For some projects that are not dev project, I sometimes use a
`manifest.scm`. I guess it also depends on the Moon phase. In those rare
cases, my `.envrc` contains the following:

```
use guix-shell -m manifest.scm
```

Which can be abbreviated to `use guix-shell`, because it auto-magically
loads the `manifest.scm` or `guix.scm` file present inside the folder.

Regarding the `guix.scm` file, I recently decided to also move them out
of the code repository of the (personal) projects I needed to package
for Guix, because they don't actually belong with the code. They now live in
a dedicated repository that I added to my Guix channels.


> For what it is worth, I have used similar workflow but I have been bored
> to run “guix pull”, do some stuff unrelated to ’project’, then later be
> back on ’project’ and then have failures.  Instead, my workflow is
> splited into 2 ways depending on my phase of the Moon.  Either, I create
> a profile inside the project directory.  Either, I use channels.scm +
> manifest.scm and often run via ’guixify’ script (see below); e.g.,
> 
>     guixify foo # run foo using the Guix environment
>     guixify     # enter in the environment

Thanks for sharing! I used to have the same kind of setup, but…


> Maybe, ’direnv’ would do a better job.

I wrote a `profile` function for Direnv that was doing the job of
loading the environment.

```
use profile the-profile-for-my-project
```

I also had a `guix-all-profile` command that would executing the same command
on all my profiles. Basically looping over them to `--upgrade` or `--delete-generations`.

But I found it easier to use Guix shell.


> The good point is that channels.scm and manifest.scm are included in the Git
> tree of the project. And they can be re-used with ’guix pack -f docker -m
> manifest.scm’ to generate Docker pack that I can share with colleagues.

My colleagues use Debian. We agreed that I would not pollute the repo
with my Guix files if they would not commit their Debian support files. 😅

Regards,

-- 
Tanguy

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

[kiasoc5]

On Wed, Oct 19 2022, 11:57:15 AM +0200
zimoun <zimon.toutoune@gmail.com> wrote:

> and then give a look at the script etc/committer.scm.

Didn't know this existed. This should definitely get a mention in the
Guix manual.

-- 

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

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 3512 bytes --]

On Tue, Oct 18, 2022 at 06:19:18PM +0200, Tanguy LE CARROUR wrote:
> Hi Chris,
> 
> Quoting Tanguy LE CARROUR (2022-10-05 16:01:40)
> > Quoting Christopher Baines (2022-09-18 17:55:30)
> > > […]
> > >  - 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
> 
> Just to let you know that, even if I haven't written `guix
> how-can-i-help` (yet), I've just written a `guix-refresh-all` that tells me:
> 
> ```console
> $ guix-refresh-all
> gnu/packages/freedesktop.scm:2164:13: udiskie would be upgraded from 2.3.3 to 2.4.2
> gnu/packages/wm.scm:1584:13: sway would be upgraded from 1.6.1 to 1.7
> gnu/packages/wireservice.scm:205:13: csvkit would be upgraded from 1.0.5 to 1.0.7
> gnu/packages/mail.scm:610:13: neomutt would be upgraded from 20211029 to 20220429
> gnu/packages/mpd.scm:445:13: cantata would be upgraded from 2.4.2 to 2.5.0
> gnu/packages/mail.scm:1326:13: notmuch would be upgraded from 0.36 to 0.37
> gnu/packages/rust-apps.scm:190:13: bat would be upgraded from 0.20.0 to 0.22.1
> gnu/packages/wm.scm:1704:13: swaybg would be upgraded from 1.0 to 1.1.1
> gnu/packages/terminals.scm:1334:13: alacritty would be upgraded from 0.9.0 to 0.16.0
> gnu/packages/gnupg.scm:830:2: pinentry-gtk2 would be upgraded from 1.2.0 to 1.2.1
> gnu/packages/linux.scm:8793:13: wireplumber would be upgraded from 0.4.11 to 0.4.12
> gnu/packages/libreoffice.scm:1059:13: libreoffice would be upgraded from 7.3.5.2 to 7.4.2.3
> gnu/packages/mpd.scm:112:13: mpd would be upgraded from 0.23.8 to 0.23.10
> gnu/packages/linphone.scm:801:13: linphone-desktop would be upgraded from 4.2.5 to 4.4.10
> gnu/packages/messaging.scm:2171:13: profanity would be upgraded from 0.13.0 to 0.13.1
> gnu/packages/gnome.scm:3060:13: libnotify would be upgraded from 0.7.9 to 0.8.1
> gnu/packages/gnupg.scm:287:13: gnupg would be upgraded from 2.2.32 to 2.3.8
> gnu/packages/rust-apps.scm:455:13: fd would be upgraded from 8.1.1 to 8.4.0
> gnu/packages/curl.scm:66:12: curl would be upgraded from 7.79.1 to 7.85.0
> gnu/packages/terminals.scm:929:13: go-github-com-junegunn-fzf would be upgraded from 0.25.0 to 0.34.0
> gnu/packages/xorg.scm:1767:13: setxkbmap would be upgraded from 1.3.2 to 1.3.3
> gnu/packages/file.scm:65:13: file would be upgraded from 5.41 to 5.43
> gnu/packages/ncurses.scm:45:13: ncurses would be upgraded from 6.2.20210619 to 6.3
> ```
> 
> So now, I know what I'll do tomorrow! 😅
> 
> This is no magic scheme, it's just an alias for:
> 
> ```console
> $ guix package -I | awk '{print $1}' | tr '\n' ' ' | xargs guix refresh 2>&1 | ag -v "already" | ag -v "failed" | ag -v "no updater" | ag -v "warning"
> ```

I'd like to suggest swapping out the ag options for a grep option:
grep -v -E '(already|failed|no updater|warning|redirection)'
_should_ work, but I haven't tested that myself yet.

> Yeah, I know… ugly! But, it does (part of) the job! 😎
> 
> Happy hacking!
> 
> -- 
> Tanguy
> 

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Tanguy LE CARROUR]

Hi Efraim,


Quoting Efraim Flashner (2022-10-19 21:31:15)
> On Tue, Oct 18, 2022 at 06:19:18PM +0200, Tanguy LE CARROUR wrote:
> > Quoting Tanguy LE CARROUR (2022-10-05 16:01:40)
> > > Quoting Christopher Baines (2022-09-18 17:55:30)
> > […]
> > This is no magic scheme, it's just an alias for:
> >
> > ```console
> > $ guix package -I | awk '{print $1}' | tr '\n' ' ' | xargs guix refresh 2>&1 | ag -v "already" | ag -v "failed" | ag -v "no updater" | ag -v "warning"
> > ```
>
> I'd like to suggest swapping out the ag options for a grep option:
> grep -v -E '(already|failed|no updater|warning|redirection)'
> _should_ work, but I haven't tested that myself yet.

Right! Those multiple `-v` looked weird!
Thanks to your suggestion, I now have:

```console
$ guix package -I | awk '{print $1}' | tr '\n' ' ' | xargs guix refresh 2>&1 \
  | ag -v '(already|failed|no updater|warning|redirection)'
```

Regards,

-- 
Tanguy

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

[zimoun]

Hi Tanguy,

On dim., 23 oct. 2022 at 17:48, Tanguy LE CARROUR <tanguy@bioneland.org> wrote:

> ```console
> $ guix package -I | awk '{print $1}' | tr '\n' ' ' | xargs guix refresh 2>&1 \
>   | ag -v '(already|failed|no updater|warning|redirection)'
> ```

This pipe is equivalent to,

    guix package --export-manifest > /tmp/my-installed-packages.scm
    guix refresh -m /tmp/my-installed-packages.scm 2>&1 \
     | ag -v '(already|failed|no updater|warning|redirection)'

which is, IMHO, more Guixy. ;-)


Cheers,
simon