Keywordreqs and slacking arch teams

classic Classic list List threaded Threaded
50 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Keywordreqs and slacking arch teams

Michał Górny-5
Hello,

The Python team ends up filing a lot of keywordreqs due to new
dependencies.  Many of them end up open for many months, and start
listing obsolete package versions.  Then an arch team wakes up...
and adds keywords to a version that's supposed to be removed already.
Or complains that the package list is outdated.

I think it's generally a reasonable assumption that keywordreq should be
applied to the newest version of a package, unless the keywordreq
explicitly says otherwise (in the comment).  It's not helpful that
stable-bot requires us to fill specific versions here.

I don't think it's fair to expect package maintainers to keep package
versions up-to-date in this case.  I can take the blame if the package
list becomes outdated, say, in 1 months.  If the arch team can't keyword
something in 6 months, I blame them, and I believe it should be their
responsibility to update the keywordreq.

Otherwise, we're creating a silly workflow where I keep putting
an effort into keeping the keywordreq up-to-date, hoping that one day
arch teams might actually act upon it.

How can we improve this?

--
Best regards,
Michał Górny


signature.asc (631 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Keywordreqs and slacking arch teams

Kent Fredric-2
On Sat, 28 Dec 2019 08:09:33 +0100
Michał Górny <[hidden email]> wrote:

> How can we improve this?

Every time this kind of issue comes up, I can't help feeling we need
some sort of tool more advanced than what we currently have.

Something that maintains persistence of keyword demands similar to how
the current bot does, but more ...

Its the sort of thing I get tempted to implement myself, but get too
horrified about the prospect of working with portage internals to do it.

attachment0 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Keywordreqs and slacking arch teams

Fabian Groffen-2
On 28-12-2019 22:27:02 +1300, Kent Fredric wrote:

> On Sat, 28 Dec 2019 08:09:33 +0100
> Michał Górny <[hidden email]> wrote:
>
> > How can we improve this?
>
> Every time this kind of issue comes up, I can't help feeling we need
> some sort of tool more advanced than what we currently have.
>
> Something that maintains persistence of keyword demands similar to how
> the current bot does, but more ...
>
> Its the sort of thing I get tempted to implement myself, but get too
> horrified about the prospect of working with portage internals to do it.
Hmmm, interested to hear what kind of things you're thinking about here.

I feel it would help if we would have the ability to at least
compile/test ebuilds automatically.  Not sure how helpful qemu could be
there, but I know things like compiling for things like arm (RPi) works
reasonably well.

Thanks,
Fabian


--
Fabian Groffen
Gentoo on a different level

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Keywordreqs and slacking arch teams

Kent Fredric-2
On Sat, 28 Dec 2019 10:35:09 +0100
Fabian Groffen <[hidden email]> wrote:

> Hmmm, interested to hear what kind of things you're thinking about here.

A lot of the "Work" of filing a keyword request is modelling all the
consequential keywordings that have to take place.

If there was say, a web based UI, that:

- Automatically determined which packages are ready for stabilization
  due to all their dependencies already being stable (and maybe with
  automatic cooldown-from-testing detection )

- Automatically determined which packages can be keyworded without
  additional work due to all their dependencies being keyworded

- When requesting keywording/stabilization, automatically determined
  what all the consequences are and what else needs to be keyworded to
  satisfy it

- Allowed a simple "Add keyword(s) <y..> for package <x>" interface,
  that intelligently created an issue and a target list, and then once
  the list was built, constantly ensured the list to be valid, or
  determined automatically when sub-work was completed and reducing the
  published list automatically, and then responded to potential issues
  based on changes in git, ( as opposed to being only triggered when
  the bug was touched )

Most of the "pain" and legwork required by maintainers would go away.

As it is, I feel a lot of us are reproducing a lot of logic that is
rather routine and could be automated.

But the overall idea here is to orient the point of keyword-requests in
some way to focus on the primary objective, where the developer
indicates their intent, and the system's job is to facilitate that
intent coming to fruition, pointing out problems on its own.

( I have somewhat hacked together some perl scripts for myself for some
of these tasks, but the command-line interface is not ideal for this
workflow, and the code is not in a condition I can share it, and I
don't think perl is the right language to address this problem with )


attachment0 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Keywordreqs and slacking arch teams

Michael 'veremitz' Everitt
On 28/12/19 11:05, Kent Fredric wrote:

> On Sat, 28 Dec 2019 10:35:09 +0100
> Fabian Groffen <[hidden email]> wrote:
>
>> Hmmm, interested to hear what kind of things you're thinking about here.
> A lot of the "Work" of filing a keyword request is modelling all the
> consequential keywordings that have to take place.
>
> If there was say, a web based UI, that:
>
> - Automatically determined which packages are ready for stabilization
>   due to all their dependencies already being stable (and maybe with
>   automatic cooldown-from-testing detection )
>
> - Automatically determined which packages can be keyworded without
>   additional work due to all their dependencies being keyworded
<snip>

I know I'm gonna be shot down in flames, because $heresy, but here is where
a package 'database' would actually work quite well, because you can
trivially create a query that pulls this data out, and sorts it by package
category or maintainer or whatever you like ..

Ok, let the flamewars begin ...


signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Keywordreqs and slacking arch teams

Kent Fredric-2
On Sat, 28 Dec 2019 11:14:15 +0000
Michael 'veremitz' Everitt <[hidden email]> wrote:

> I know I'm gonna be shot down in flames, because $heresy, but here is where
> a package 'database' would actually work quite well, because you can
> trivially create a query that pulls this data out, and sorts it by package
> category or maintainer or whatever you like ..
>
> Ok, let the flamewars begin ...

There's no real problem with a package database, however, the real
limitation is in the ebuild source format, which ultimately means any
such database needs a lot of bash-sourcing hell to simply stay
up-to-date ( any time an eclass changes, the interpretation of every
ebuild that uses it also changes, necessitating some pretty fun(1) code )

And that winds you up fighting with portage internals.

So simply, in order for somebody like me to actually implement such a
thing, a precursory step is to rewrite enough portage to do just that.

But I haven't (yet) gotten around to that.


1: Not actually fun.

attachment0 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Keywordreqs and slacking arch teams

Kent Fredric-2
In reply to this post by Michael 'veremitz' Everitt
On Sat, 28 Dec 2019 11:14:15 +0000
Michael 'veremitz' Everitt <[hidden email]> wrote:

> I know I'm gonna be shot down in flames, because $heresy, but here is where
> a package 'database' would actually work quite well, because you can
> trivially create a query that pulls this data out, and sorts it by package
> category or maintainer or whatever you like .

Oh, and once upon a time, there was actually a trick you could do to
make portage keep its metadata caches in an SQLite database, which had
its benefits, and I even had a rough tool I wrote in ruby and shared on
the old (defunct) wiki that helped do quick database queries.

But the trick actually makes portage slower in multiple ways, and it
never really got widespread love.

( Though I would argue how the data was stored was also inadequate for
a lot of other tasks one might want to do with a database, like,
keeping DEPEND stored in its string format )

attachment0 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Keywordreqs and slacking arch teams

Michael 'veremitz' Everitt
On 28/12/19 11:32, Kent Fredric wrote:

> On Sat, 28 Dec 2019 11:14:15 +0000
> Michael 'veremitz' Everitt <[hidden email]> wrote:
>
>> I know I'm gonna be shot down in flames, because $heresy, but here is where
>> a package 'database' would actually work quite well, because you can
>> trivially create a query that pulls this data out, and sorts it by package
>> category or maintainer or whatever you like .
> Oh, and once upon a time, there was actually a trick you could do to
> make portage keep its metadata caches in an SQLite database, which had
> its benefits, and I even had a rough tool I wrote in ruby and shared on
> the old (defunct) wiki that helped do quick database queries.
>
> But the trick actually makes portage slower in multiple ways, and it
> never really got widespread love.
>
> ( Though I would argue how the data was stored was also inadequate for
> a lot of other tasks one might want to do with a database, like,
> keeping DEPEND stored in its string format )
Note:  we're nnot acttually talking about replacing portage here, just
creating a tool ((((thiink php script web tthingy)) that will do some of
the pre-screeninng worrrrk that AT hate (eg.... what kensiington did  with
stable-bbot)

* with apologies for keyboard/remote-access lagggg creating typo hell.


signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Keywordreqs and slacking arch teams

James Le Cuirot
In reply to this post by Kent Fredric-2
On Sun, 29 Dec 2019 00:27:36 +1300
Kent Fredric <[hidden email]> wrote:

> On Sat, 28 Dec 2019 11:14:15 +0000
> Michael 'veremitz' Everitt <[hidden email]> wrote:
>
> > I know I'm gonna be shot down in flames, because $heresy, but here is where
> > a package 'database' would actually work quite well, because you can
> > trivially create a query that pulls this data out, and sorts it by package
> > category or maintainer or whatever you like ..
> >
> > Ok, let the flamewars begin ...  
>
> There's no real problem with a package database, however, the real
> limitation is in the ebuild source format, which ultimately means any
> such database needs a lot of bash-sourcing hell to simply stay
> up-to-date ( any time an eclass changes, the interpretation of every
> ebuild that uses it also changes, necessitating some pretty fun(1) code )
>
> And that winds you up fighting with portage internals.
>
> So simply, in order for somebody like me to actually implement such a
> thing, a precursory step is to rewrite enough portage to do just that.
>
> But I haven't (yet) gotten around to that.
>
>
> 1: Not actually fun.
Doesn't https://packages.gentoo.org already have such a database?
Unfortunately a3li used Elasticsearch, which no one understands, but
it's a start.

--
James Le Cuirot (chewi)
Gentoo Linux Developer

attachment0 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Keywordreqs and slacking arch teams

Kent Fredric-2
In reply to this post by Michael 'veremitz' Everitt
On Sat, 28 Dec 2019 11:35:49 +0000
Michael 'veremitz' Everitt <[hidden email]> wrote:

> Note:  we're nnot acttually talking about replacing portage here, just
> creating a tool ((((thiink php script web tthingy)) that will do some of
> the pre-screeninng worrrrk that AT hate (eg.... what kensiington did  with
> stable-bbot)
>
> * with apologies for keyboard/remote-access lagggg creating typo hell.

But, doing that requires viewing realised copies of ebuilds, which
requires interpreting eclasses and variable interpolation, which
requires bash sourcing, which requires a mountain of portage hell.

Yes, sharing the stable-bot logic would probably be fine.

But it doesn't use a database AFAIK, it would likely just be making use
of the MD5Cache (either directly, or indirectly via portage APIs)

But I won't be volunteering, because I won't touch python.

attachment0 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Keywordreqs and slacking arch teams

Kent Fredric-2
In reply to this post by James Le Cuirot
On Sat, 28 Dec 2019 11:40:08 +0000
James Le Cuirot <[hidden email]> wrote:

> Unfortunately a3li used Elasticsearch, which no one understands, but
> it's a start.

And I've used ES enough to say I would rather never use it again.

attachment0 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Keywordreqs and slacking arch teams

Alec Warner-2
In reply to this post by Kent Fredric-2
On Sat, Dec 28, 2019 at 3:43 AM Kent Fredric <[hidden email]> wrote:
On Sat, 28 Dec 2019 11:35:49 +0000
Michael 'veremitz' Everitt <[hidden email]> wrote:

> Note:  we're nnot acttually talking about replacing portage here, just
> creating a tool ((((thiink php script web tthingy)) that will do some of
> the pre-screeninng worrrrk that AT hate (eg.... what kensiington did  with
> stable-bbot)
>
> * with apologies for keyboard/remote-access lagggg creating typo hell.

But, doing that requires viewing realised copies of ebuilds, which
requires interpreting eclasses and variable interpolation, which
requires bash sourcing, which requires a mountain of portage hell.

Yes, sharing the stable-bot logic would probably be fine.

But it doesn't use a database AFAIK, it would likely just be making use
of the MD5Cache (either directly, or indirectly via portage APIs)

But I won't be volunteering, because I won't touch python.

You could of course work together with someone else to write the tool?

-A
 
Reply | Threaded
Open this post in threaded view
|

Re: Keywordreqs and slacking arch teams

Aaron Bauman-2
On Sat, Dec 28, 2019 at 10:05:02AM -0800, Alec Warner wrote:

> On Sat, Dec 28, 2019 at 3:43 AM Kent Fredric <[hidden email]> wrote:
>
> > On Sat, 28 Dec 2019 11:35:49 +0000
> > Michael 'veremitz' Everitt <[hidden email]> wrote:
> >
> > > Note:  we're nnot acttually talking about replacing portage here, just
> > > creating a tool ((((thiink php script web tthingy)) that will do some of
> > > the pre-screeninng worrrrk that AT hate (eg.... what kensiington did
> > with
> > > stable-bbot)
> > >
> > > * with apologies for keyboard/remote-access lagggg creating typo hell.
> >
> > But, doing that requires viewing realised copies of ebuilds, which
> > requires interpreting eclasses and variable interpolation, which
> > requires bash sourcing, which requires a mountain of portage hell.
> >
>
> > Yes, sharing the stable-bot logic would probably be fine.
> >
> > But it doesn't use a database AFAIK, it would likely just be making use
> > of the MD5Cache (either directly, or indirectly via portage APIs)
> >
> > But I won't be volunteering, because I won't touch python.
> >
>
> You could of course work together with someone else to write the tool?
>
> -A
Ah, you found the Achilles heel. It is much easier to postulate on the mailing
list, use big words, and then say you just won't do that thing because
tools/languages such.

Perl though...

--
Cheers,
Aaron

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Keywordreqs and slacking arch teams

Kent Fredric-2
On Sat, 28 Dec 2019 21:19:18 -0500
Aaron Bauman <[hidden email]> wrote:

> Ah, you found the Achilles heel. It is much easier to postulate on the mailing
> list, use big words, and then say you just won't do that thing because
> tools/languages such.
>
> Perl though...

FTR: Even though I'm good at Perl, I wouldn't use it for this task.

There are a lot of reasons behind this.

But at least one of them would be if I wrote it in Perl, I'd have
nobody else contributing either.

And IME, that's fair enough.

attachment0 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Keywordreqs and slacking arch teams

A Schenck
In reply to this post by Michael 'veremitz' Everitt
On 12/28/19 3:14 AM, Michael 'veremitz' Everitt wrote:

> On 28/12/19 11:05, Kent Fredric wrote:
>> On Sat, 28 Dec 2019 10:35:09 +0100
>> Fabian Groffen <[hidden email]> wrote:
>>
>>> Hmmm, interested to hear what kind of things you're thinking about here.
>> A lot of the "Work" of filing a keyword request is modelling all the
>> consequential keywordings that have to take place.
>>
>> If there was say, a web based UI, that:
>>
>> - Automatically determined which packages are ready for stabilization
>>   due to all their dependencies already being stable (and maybe with
>>   automatic cooldown-from-testing detection )
>>
>> - Automatically determined which packages can be keyworded without
>>   additional work due to all their dependencies being keyworded
> <snip>
>
> I know I'm gonna be shot down in flames, because $heresy, but here is where
> a package 'database' would actually work quite well, because you can
> trivially create a query that pulls this data out, and sorts it by package
> category or maintainer or whatever you like ..
app-portage/kuroo manages an SQLite database of packages without any
bash sourcing craziness, but defers to `emerge` to do the actual install
/ uninstall work and parses stdout and stderr from it.  DB schema is
described at
https://sourceforge.net/p/kuroo/code/HEAD/tree/kuroo4/trunk/src/core/portagedb.cpp#l219
and there are queries for packages by category / subcategory, installed
/ updateable status, and search string there.  Code to walk the main
tree from md5-cache and fill in those tables starts about
https://sourceforge.net/p/kuroo/code/HEAD/tree/kuroo4/trunk/src/core/scanportagejob.cpp#l135
.  Back before burnout there was some hope of porting it to a 'unified
portage API' that dol-sen wanted to build for other portage tools to
use, but that never came to fruition.  Most of this code is 15 years old
though, and I've only done the bare minimum to keep it working-ish as
portage and the tree have changed.
>
> Ok, let the flamewars begin ...
>

-A

Reply | Threaded
Open this post in threaded view
|

Re: Keywordreqs and slacking arch teams

Rolf Eike Beer
In reply to this post by Kent Fredric-2
> - Allowed a simple "Add keyword(s) <y..> for package <x>" interface,
>   that intelligently created an issue and a target list, and then once
>   the list was built, constantly ensured the list to be valid, or
>   determined automatically when sub-work was completed and reducing the
>   published list automatically, and then responded to potential issues
>   based on changes in git, ( as opposed to being only triggered when
>   the bug was touched )

As someone who does both keywordings and stabilizations regularly on hppa and
sparc I think I must share a bit of my experiences:

-some arches are regularly forgotten to be CC'ed, which happens for the above
arches quite regularly as they are exp

-if I need to do a bug at a later point when I want to newly stabilize a given
package for a new arch it is extremely helpful if

  - the package list was not reduced on a later point because parts were
already handled

  - arch specifications for packages are reduced to the absolute need, i.e.
especially not given if the arch list would match the initial CC list

I use tatt for my work, and that automatically sorts out all packages that
have non-matching package list. Sure, there could be improvements for several
things in tatt, but that is IMHO absolutely right the way it is. So if you
give all arches and I later decide to do the same bug on an additional arch
then it will not do a single package.

So if you want my work easier, then
-don't forget to CC exp arches
-don't clean the package list only because packages are already done
-let tatt run on your dev box, or preferably in a new chroot yourself, on your
package, and fix all the broken dependencies and stuff there yourself. Your
amd64 laptop is still way faster than my crowded C8000, and doing a roundtrip
through the bugtracker until you find time to fix it will just make you think
of "slacking arch teams" next time.

Thanks,

Eike

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Keywordreqs and slacking arch teams

Mike Pagano
On Thursday, January 2, 2020 3:32:12 PM EST Rolf Eike Beer wrote:

> > - Allowed a simple "Add keyword(s) <y..> for package <x>" interface,
> >
> >   that intelligently created an issue and a target list, and then once
> >   the list was built, constantly ensured the list to be valid, or
> >   determined automatically when sub-work was completed and reducing the
> >   published list automatically, and then responded to potential issues
> >   based on changes in git, ( as opposed to being only triggered when
> >   the bug was touched )
>
> As someone who does both keywordings and stabilizations regularly on hppa
> and sparc I think I must share a bit of my experiences:
<snip>

hppa is making us keep old kernels around [1].  Should the kernel team be
doing more to get your attention then CC'ing hppa on all of the kernel
STABLEREQ bugs [2]?

[1] https://packages.gentoo.org/packages/sys-kernel/gentoo-sources
[2] https://bugs.gentoo.org/700416

Mike

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Keywordreqs and slacking arch teams

Rolf Eike Beer
Am Freitag, 3. Januar 2020, 00:25:06 CET schrieb Mike Pagano:

> On Thursday, January 2, 2020 3:32:12 PM EST Rolf Eike Beer wrote:
> > > - Allowed a simple "Add keyword(s) <y..> for package <x>" interface,
> > >
> > >   that intelligently created an issue and a target list, and then once
> > >   the list was built, constantly ensured the list to be valid, or
> > >   determined automatically when sub-work was completed and reducing the
> > >   published list automatically, and then responded to potential issues
> > >   based on changes in git, ( as opposed to being only triggered when
> > >   the bug was touched )
> >
> > As someone who does both keywordings and stabilizations regularly on hppa
>
> > and sparc I think I must share a bit of my experiences:
> <snip>
>
> hppa is making us keep old kernels around [1].  Should the kernel team be
> doing more to get your attention then CC'ing hppa on all of the kernel
> STABLEREQ bugs [2]?
I only run vanilla-sources since there are still lot of cache corruption
problems in hppa kernels, or whatever makes them flaky.

Linux pioneer 5.4.6-parisc64 #1 SMP Fri Dec 27 10:23:09 CET 2019 parisc64
PA8800 (Mako) 9000/785/C8000 GNU/Linux
Linux voyager 5.4.6-parisc #1 Fri Dec 27 15:46:43 CET 2019 parisc PA8600 (PCX-
W+) 9000/785/C3600 GNU/Linux

So _I_ personally would say just drop old kernels, but that is in no way
authorative.

Eike

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Keywordreqs and slacking arch teams

Michael 'veremitz' Everitt
On 02/01/20 23:35, Rolf Eike Beer wrote:

> Am Freitag, 3. Januar 2020, 00:25:06 CET schrieb Mike Pagano:
>> On Thursday, January 2, 2020 3:32:12 PM EST Rolf Eike Beer wrote:
>>>> - Allowed a simple "Add keyword(s) <y..> for package <x>" interface,
>>>>
>>>>   that intelligently created an issue and a target list, and then once
>>>>   the list was built, constantly ensured the list to be valid, or
>>>>   determined automatically when sub-work was completed and reducing the
>>>>   published list automatically, and then responded to potential issues
>>>>   based on changes in git, ( as opposed to being only triggered when
>>>>   the bug was touched )
>>> As someone who does both keywordings and stabilizations regularly on hppa
>>> and sparc I think I must share a bit of my experiences:
>> <snip>
>>
>> hppa is making us keep old kernels around [1].  Should the kernel team be
>> doing more to get your attention then CC'ing hppa on all of the kernel
>> STABLEREQ bugs [2]?
> I only run vanilla-sources since there are still lot of cache corruption
> problems in hppa kernels, or whatever makes them flaky.
>
> Linux pioneer 5.4.6-parisc64 #1 SMP Fri Dec 27 10:23:09 CET 2019 parisc64
> PA8800 (Mako) 9000/785/C8000 GNU/Linux
> Linux voyager 5.4.6-parisc #1 Fri Dec 27 15:46:43 CET 2019 parisc PA8600 (PCX-
> W+) 9000/785/C3600 GNU/Linux
>
> So _I_ personally would say just drop old kernels, but that is in no way
> authorative.
>
> Eike
Is it viable at all to test gentoo-sources or would it be better simply to
unkeyword?


signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Keywordreqs and slacking arch teams

Aaron Bauman-2
In reply to this post by Rolf Eike Beer


On January 2, 2020 6:35:08 PM EST, Rolf Eike Beer <[hidden email]> wrote:

>Am Freitag, 3. Januar 2020, 00:25:06 CET schrieb Mike Pagano:
>> On Thursday, January 2, 2020 3:32:12 PM EST Rolf Eike Beer wrote:
>> > > - Allowed a simple "Add keyword(s) <y..> for package <x>"
>interface,
>> > >
>> > >   that intelligently created an issue and a target list, and then
>once
>> > >   the list was built, constantly ensured the list to be valid, or
>> > >   determined automatically when sub-work was completed and
>reducing the
>> > >   published list automatically, and then responded to potential
>issues
>> > >   based on changes in git, ( as opposed to being only triggered
>when
>> > >   the bug was touched )
>> >
>> > As someone who does both keywordings and stabilizations regularly
>on hppa
>>
>> > and sparc I think I must share a bit of my experiences:
>> <snip>
>>
>> hppa is making us keep old kernels around [1].  Should the kernel
>team be
>> doing more to get your attention then CC'ing hppa on all of the
>kernel
>> STABLEREQ bugs [2]?
>
>I only run vanilla-sources since there are still lot of cache
>corruption
>problems in hppa kernels, or whatever makes them flaky.
>
>Linux pioneer 5.4.6-parisc64 #1 SMP Fri Dec 27 10:23:09 CET 2019
>parisc64
>PA8800 (Mako) 9000/785/C8000 GNU/Linux
>Linux voyager 5.4.6-parisc #1 Fri Dec 27 15:46:43 CET 2019 parisc
>PA8600 (PCX-
>W+) 9000/785/C3600 GNU/Linux
>
>So _I_ personally would say just drop old kernels, but that is in no
>way
>authorative.
>
>Eike

Ugh. gentoo-sources is just a patch (trivial) on top of vanilla-kernel sources of each stable and LTS version.

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

123