Re: [gentoo-dev] Keywordreqs and slacking arch teams
Am Samstag, 4. Januar 2020, 12:25:07 CET schrieb Michael 'veremitz' Everitt: > On 04/01/20 11:09, Rolf Eike Beer wrote: > > Am Freitag, 3. Januar 2020, 11:00:14 CET schrieb Rolf Eike Beer: > >> Am Freitag, 3. Januar 2020, 03:40:35 CET schrieb Aaron Bauman: > >>> On January 2, 2020 6:35:08 PM EST, Rolf Eike Beer wrote: > Am Freitag, 3. Januar 2020, 00:25:06 CET schrieb Mike Pagano: > > 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. > >>> > >>> Ugh. gentoo-sources is just a patch (trivial) on top of vanilla-kernel > >>> sources of each stable and LTS version. > >> > >> If it's just that I could test them, but this still be no LTS version > >> that I would look at. > > > > So, do you want me to stable a random gentoo-sources (usually the most > > recent one) every few weeks when I just happen to upgrade my machine? > I don't think that works very well with kernel/security-team stabilisation > policies, sadly. > > Is there any possibility you would be able to do a stabilisation run, and > do a reboot cycle on one LTS branch (of choice, eg. most recent) and then > revert to your preferred kernel afterwards? This is annoying, because it usually collides with the nightly runs in some way. Doing the build on the C3600 took ~1d last time, the C8000 is faster, but I still have to time this right. Eike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Keywordreqs and slacking arch teams
On 04/01/20 11:09, Rolf Eike Beer wrote: > Am Freitag, 3. Januar 2020, 11:00:14 CET schrieb Rolf Eike Beer: >> Am Freitag, 3. Januar 2020, 03:40:35 CET schrieb Aaron Bauman: >>> On January 2, 2020 6:35:08 PM EST, Rolf Eike Beer wrote: Am Freitag, 3. Januar 2020, 00:25:06 CET schrieb Mike Pagano: > 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. >>> Ugh. gentoo-sources is just a patch (trivial) on top of vanilla-kernel >>> sources of each stable and LTS version. >> If it's just that I could test them, but this still be no LTS version that I >> would look at. > So, do you want me to stable a random gentoo-sources (usually the most recent > one) every few weeks when I just happen to upgrade my machine? > > Eike I don't think that works very well with kernel/security-team stabilisation policies, sadly. Is there any possibility you would be able to do a stabilisation run, and do a reboot cycle on one LTS branch (of choice, eg. most recent) and then revert to your preferred kernel afterwards? I appreciate this is a rather onerous process on older hardware, but just trying to think of some form of semi-compromise that prevents potential de-keywording, without also suggesting that something that genuinely has issues is either (1) working or (2) supported, if so. I believe Whissi is leading kernel stabilisation requests, on behalf of security- and kernel- teams, so maybe a chat with him may be fruitful. Cheers, veremitz/Michael. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Keywordreqs and slacking arch teams
Am Freitag, 3. Januar 2020, 11:00:14 CET schrieb Rolf Eike Beer: > Am Freitag, 3. Januar 2020, 03:40:35 CET schrieb Aaron Bauman: > > On January 2, 2020 6:35:08 PM EST, Rolf Eike Beer wrote: > > >Am Freitag, 3. Januar 2020, 00:25:06 CET schrieb Mike Pagano: > > >> 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. > > > > Ugh. gentoo-sources is just a patch (trivial) on top of vanilla-kernel > > sources of each stable and LTS version. > > If it's just that I could test them, but this still be no LTS version that I > would look at. So, do you want me to stable a random gentoo-sources (usually the most recent one) every few weeks when I just happen to upgrade my machine? Eike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Keywordreqs and slacking arch teams
Am Freitag, 3. Januar 2020, 03:40:35 CET schrieb Aaron Bauman: > On January 2, 2020 6:35:08 PM EST, Rolf Eike Beer wrote: > >Am Freitag, 3. Januar 2020, 00:25:06 CET schrieb Mike Pagano: > >> 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. > Ugh. gentoo-sources is just a patch (trivial) on top of vanilla-kernel > sources of each stable and LTS version. If it's just that I could test them, but this still be no LTS version that I would look at. Just some background: these machines run CMake and some other software nightly builds, which starts ~3:00 and takes them until the afternoon. I have chroots for stabilization and keywording on them, and the tatt scripts will wait if any process of my buildbot user (that's just the name, not the software) is active. If the nightlies are done, then the tatt scripts will continue and hog the machine. I will do a kernel upgrade usually if the machine crashed anyway, which means every few weeks, and then I go to the most recent version. Eike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Keywordreqs and slacking arch teams
On January 2, 2020 6:35:08 PM EST, 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) for package " >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: >> >> >> 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.
Re: [gentoo-dev] Keywordreqs and slacking arch teams
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) for package " 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: >> >> >> 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 Description: OpenPGP digital signature
Re: [gentoo-dev] Keywordreqs and slacking arch teams
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) for package " 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: > > > 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 Description: This is a digitally signed message part.
Re: [gentoo-dev] Keywordreqs and slacking arch teams
On Thursday, January 2, 2020 3:32:12 PM EST Rolf Eike Beer wrote: > > - Allowed a simple "Add keyword(s) for package " 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: 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 Description: This is a digitally signed message part.
Re: [gentoo-dev] Keywordreqs and slacking arch teams
> - Allowed a simple "Add keyword(s) for package " 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 Description: This is a digitally signed message part.
Re: [gentoo-dev] Keywordreqs and slacking arch teams
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 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 > > > 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
Re: [gentoo-dev] Keywordreqs and slacking arch teams
On Sat, 28 Dec 2019 21:19:18 -0500 Aaron Bauman 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. pgpqWSZPaxxWp.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Keywordreqs and slacking arch teams
On Sat, Dec 28, 2019 at 10:05:02AM -0800, Alec Warner wrote: > On Sat, Dec 28, 2019 at 3:43 AM Kent Fredric wrote: > > > On Sat, 28 Dec 2019 11:35:49 + > > Michael 'veremitz' Everitt 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 wok that AT hate (eg what kensiington did > > with > > > stable-bbot) > > > > > > * with apologies for keyboard/remote-access la 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 Description: PGP signature
Re: [gentoo-dev] Keywordreqs and slacking arch teams
On Sat, Dec 28, 2019 at 3:43 AM Kent Fredric wrote: > On Sat, 28 Dec 2019 11:35:49 + > Michael 'veremitz' Everitt 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 wok that AT hate (eg what kensiington did > with > > stable-bbot) > > > > * with apologies for keyboard/remote-access la 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
Re: [gentoo-dev] Keywordreqs and slacking arch teams
On Sat, 28 Dec 2019 11:40:08 + James Le Cuirot 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. pgp7mS3HF7Z2A.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Keywordreqs and slacking arch teams
On Sat, 28 Dec 2019 11:35:49 + Michael 'veremitz' Everitt 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 wok that AT hate (eg what kensiington did with > stable-bbot) > > * with apologies for keyboard/remote-access la 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. pgphawvJwBwAU.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Keywordreqs and slacking arch teams
On Sun, 29 Dec 2019 00:27:36 +1300 Kent Fredric wrote: > On Sat, 28 Dec 2019 11:14:15 + > Michael 'veremitz' Everitt 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 pgpUl78_P3IXC.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Keywordreqs and slacking arch teams
On 28/12/19 11:32, Kent Fredric wrote: > On Sat, 28 Dec 2019 11:14:15 + > Michael 'veremitz' Everitt 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 wok that AT hate (eg what kensiington did with stable-bbot) * with apologies for keyboard/remote-access la creating typo hell. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Keywordreqs and slacking arch teams
On Sat, 28 Dec 2019 11:14:15 + Michael 'veremitz' Everitt 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 ) pgpG_kX027cdJ.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Keywordreqs and slacking arch teams
On Sat, 28 Dec 2019 11:14:15 + Michael 'veremitz' Everitt 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. pgppjeYD2_M91.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Keywordreqs and slacking arch teams
On 28/12/19 11:05, Kent Fredric wrote: > On Sat, 28 Dec 2019 10:35:09 +0100 > Fabian Groffen 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 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 Description: OpenPGP digital signature
Re: [gentoo-dev] Keywordreqs and slacking arch teams
On Sat, 28 Dec 2019 10:35:09 +0100 Fabian Groffen 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) for package " 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 ) pgpBgVetvsNaY.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Keywordreqs and slacking arch teams
On 28-12-2019 22:27:02 +1300, Kent Fredric wrote: > On Sat, 28 Dec 2019 08:09:33 +0100 > Michał Górny 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 Description: PGP signature
Re: [gentoo-dev] Keywordreqs and slacking arch teams
On Sat, 28 Dec 2019 08:09:33 +0100 Michał Górny 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. pgpRWoCmPMaBI.pgp Description: OpenPGP digital signature
[gentoo-dev] Keywordreqs and slacking arch teams
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 Description: This is a digitally signed message part
