Re: [gentoo-dev] Re: Stabilisation procedure

[Daniel Campbell]

On 11/22/2016 12:06 AM, Alice Ferrazzi wrote:
> On Sat, Nov 19, 2016 at 12:55:09AM -0800, Daniel Campbell wrote:
>> On 11/17/2016 01:07 PM, Robin H. Johnson wrote:
>>> On Thu, Nov 17, 2016 at 03:05:41PM +0100, Kristian Fiskerstrand wrote:
> Isn't it implied that any stabilisation is approved by the maintainer?
> Has it ever been acceptable to go around stabilising random packages?
>

 Explicit > Implicit when we're updating things anyways.

 There are scenarios where e.g Security is calling for stabilization ,
 I'll add some info to the draft security GLEP with some requirements for
 when this can happen without maintainer involvement as well..

 Ultimately maintainer is responsible for the state of the stable tree
 for the packages they maintain and should be taking proactive steps for
 this also for security bugs, it doesn't "always" happen like that.
>>>
>>> The interaction of this proposal and the prior discussion of allow
>>> maintainers to document the maintenance policy of given packages is
>>> where it would really come into play.
>>>
>>> Using two packages for examples:
>>> app-admin/diradm: I am the upstream author as well as the package
>>> maintainer. I care about it being marked stable. I'd prefer the normal
>>> policy of other people asking me (with timeout) before touching it.
>>>
>>> app-admin/cancd: It's a very obscure package that I put in the tree
>>> because I needed it, but I haven't personally used it in many years. 
>>> I fix the packaging if it's broken only.
>>> I'm inclined to mark it with 'anybody-may-bump/fix/stabilize'.
>>>
>> Agreed. For most of my packages, I really don't mind since we're all
>> working on Gentoo together, but it'd be super helpful if I was simply
>> notified in the event that a package I maintain has gotten a security
>> bump, patch, or stabilization. Sure, 'git log' and 'git blame' can
>> explain a few things, but if I was going to edit a package, I have the
>> maintainer's e-mail available right there in metadata.xml. To me it's a
>> courtesy that should be a requirement by default, while devs that don't
>> care can use whatever means we agree upon to indicate that they don't care.
>>
>> This creates a "contact first" practice, which it seems we want to
>> encourage. If someone isn't responsive and/or away, that complicates
>> things, but if it's a security concern or the last blocker in a big
>> stabilization effort (looking at you, tcl 8.6...), then it makes sense
>> to just go ahead and make the bumps necessary.
> 
> What about maintainers that are away without writing it in their
> maintainer bug ?
> After how many days of no replay can be fair to touch their package ?
> 
>>
>> -- 
>> Daniel Campbell - Gentoo Developer
>> OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
>> fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
>>
> 
> 
> 
We have a formal dev-away practice, requiring little more than literally:

ssh m...@dev.gentoo.org; echo "Away for vacation. Back in a week" >
~/.away; exit

A dev can add more details to the file if they want to. If they're gone
and can't be reached at all, then I think a week is enough time for a
developer to check their mail and get (or make) enough time to either
update their dev-away status or otherwise indicate how they feel about a
change that needs their feedback.

Maybe the maintainer-bug case is different if we're talking
proxy-maintainers, but that's a good question; one that maybe p-m should
make on its own before we aim for a global, concrete policy.

I think the requirement for contact is all we should really settle on
formally; the rest being handled in wetware where it belongs. :)
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: Userkit.eclass

[Daniel Campbell]

On 11/23/2016 01:08 AM, Michał Górny wrote:
> On Wed, 23 Nov 2016 09:44:33 +0100
> Manuel Rüger  wrote:
> 
>> I have not started to write it, but I am considering it and rather want
>> to gather feedback on my idea first.
>> I am aware that https://wiki.gentoo.org/wiki/GLEP:27 exists, but as of
>> right now I haven't seen anyone working on it. The goal of this eclass
>> is to improve user/group handling without touching the PMS.
>>
>> tl;dr: Userkit eclass will improve the user handling by externalizing
>> the configuration to variables that can be set from outside of the ebuild.
>>
>> Userkit.eclass will inherit user.eclass and require bash arrays
>> USERKIT_USER and USERKIT_GROUP for configuration.
>> I will export a pkg_setup with the corresponding setup (basically
>> calling enewuser and enewgroup). It will provide get_user, get_uid,
>> get_group, get_gid and get_home functions.
>> This would allow to do something like "fowners $(get_user):$(get_group)
>> foo".
>>
>> If ${CATEGORY}-${PN}_user and ${CATEGORY}-${PN}_group are set, these
>> will replace the contents of USERKIT_USER and USERKIT_GROUP, allowing
>> the user to fully define everything user/group related.
> 
> How does that all map to multiple users/groups? How does that map to
> USE-conditional users/groups? How does that map to users/groups shared
> between multiple packages?
> 
> Besides, this sounds a lot like games.eclass... will developers be
> required to patch upstream software now to force support for using
> custom users/groups?
> 
>> What happens if the ebuild wants to create multiple users/group?
>> Currently, I want to ignore that case and focus on the 80% ebuilds that
>> can profit from such an eclass.
> 
> Do you have specific numbers? I don't see 80% of ebuilds caring about
> users/groups. I don't see the problem you are trying to fix.
> 
> Is it one of those problems that someone thinks it's awesome to make
> everything declaratory, and add tons of middleware to make the
> declaratory work somehow for the most common use cases?
> 
I think the use-case here is ebuilds that need to create a user and/or
group (www-servers/lighttpd is a good example; alongside pretty much
anything else that needs to run as a separate user and serves
something). In lighttpd's case we don't currently support the ability to
declare which user and group lightty uses; the lighttpd user and
lighttpd group will always be created. Later configuration of users and
groups can be worked with, and iirc we recently patched the initscript
so it handles that use case.

I could see a use-case for someone wanting to install a given daemon or
server with a specific user and/or group. I'm not sure this is the right
approach (nor do I know what is), but I think we have room to think
about a solution; ideally one that is dead-simple to implement and
doesn't have a ton of edge-cases.

What is QA's current policy on user/group creation, btw?
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Last rites: app-emulation/open-vm-tools-kmod

[Mike Gilbert]

# Mike Gilbert  (25 Nov 2016)
# Modules are now part of app-emulation/open-vm-tools.
# Removal in 30 days.
app-emulation/open-vm-tools-kmod

Re: [gentoo-dev] Packages up for grabs

[Mathy Vanvoorden]

>
> AFAIK they are not intended to be installed as compiled code at all.
> You are supposed to bundle them, or otherwise compile them from sources
> along with your project.
>
>
You are correct, apparently they changed their stance on this some time ago
as you can read here:

https://github.com/google/googletest/blob/master/googletest/docs/FAQ.md#why-is-it-not-recommended-to-install-a-pre-compiled-copy-of-google-test-for-example-into-usrlocal

They also no longer support the autotools scripts that are provided with
the source code as you can read in the README:

https://github.com/google/googletest/blob/master/googletest/README.md#legacy-build-scripts

There are quite some packages depending on them so they can't just be
last-rited. Maybe the best solution is to leave them in their current form
(perhaps update the SRC_URI) and not accepting package updates to 1.8,
instead asking upstream packages that depend on them to include them in
their source distribution.


br,
Mathy

[gentoo-dev] [warning] the bug queue has 86 bugs

[Alex Alexander]

Our bug queue has 86 bugs!

If you have some spare time, please help assign/sort a few bugs.

To view the bug queue, click here: http://bit.ly/m8PQS5

Thanks!

Re: [gentoo-portage-dev] [PATCH] repos.conf: support strict-misc-digests attribute (bug 600128)

[Zac Medico]

On 11/24/2016 02:24 PM, Robin H. Johnson wrote:
> 
> On Wed, Nov 23, 2016 at 11:04:54PM -0800, Zac Medico wrote:
>> The current GLEP 60 draft specifies that non-strict handling of MISC
>> digests should be supported.
> In my followup post about how it should work, I noted that in non-strict
> mode, a non-fatal warning should be issued for the mismatch of Manifest
> and existing MISC file.
> 
> You take the approach here of just not checking the MISC files, with a
> default of checking them anyway.
> 
> The non-fatal warning variant enables keeping the check enabled without
> breaking the tree.
> 
> Do I need to codify that into a GLEP update to get traction?

I question the usefulness of producing warnings that people probably
want to ignore anyway, but I suppose we could make the
Manifest.checkTypeHashes method implement this behavior internally.
-- 
Thanks,
Zac

Re: [gentoo-portage-dev] [PATCH] unpack: fix txz unpack support (bug 600660)

[Zac Medico]

On 11/24/2016 11:07 AM, Brian Dolbec wrote:
> On Thu, 24 Nov 2016 10:46:21 -0800
> Zac Medico  wrote:
> 
>> Since txz unpack support was added in commit
>> daa65a336102050396482f08c77524fe99e48c9f, it has been non-functional,
>> as follows:
>>
>> phase-helpers.sh: line 521: ___eapi_supports_txz: command not found
>> unpack portage-2.3.2.txz: file format not recognized. Ignoring.
>>
>> Fixes: daa65a336102 ("Add tentative EAPI6 .txz unpack support")
>> X-Gentoo-Bug: 600660
>> X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=600660
>> ---
>>  bin/phase-helpers.sh | 7 +--
>>  1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/bin/phase-helpers.sh b/bin/phase-helpers.sh
>> index d55165c..9e4e6a2 100644
>> --- a/bin/phase-helpers.sh
>> +++ b/bin/phase-helpers.sh
>> @@ -518,8 +518,11 @@ unpack() {
>>  "suffix '${suffix}'
>> which is unofficially supported" \ "with EAPI '${EAPI}'. Instead use
>> 'txz'." fi
>> -if ___eapi_supports_txz; then
>> -__unpack_tar "xz -d" ||
>> return 1
>> +if ___eapi_unpack_supports_txz; then
>> +if ! tar xof "$srcdir$x";
>> then
>> +__helpers_die
>> "$myfail"
>> +return 1
>> +fi
>>  else
>>  __vecho "unpack ${x}: file
>> format not recognized. Ignoring." fi
> 
> looks good, thanks
> 

Pushed:

https://gitweb.gentoo.org/proj/portage.git/commit/?id=d5851278daea670910cdcf1f8864b9c4494d0b31
-- 
Thanks,
Zac

Re: [gentoo-dev] Packages up for grabs

[Michał Górny]

On Fri, 25 Nov 2016 12:25:37 -0500
Mike Gilbert  wrote:

> On Fri, Nov 25, 2016 at 10:06 AM, Thomas Kahle  wrote:
> > Hi,
> >
> > I'd like to pass on maintainership of
> >
> > dev-cpp/gtest
> > dev-cpp/gmock
> >
> > I don't use them and I don't even remember how I came to maintain
> > them.  These two are among the packages that have googlecode in
> > their SRC_URI, so this is a bit urgent.  Upstream has moved to
> > github and merged the two packages:
> >
> > https://github.com/google/googletest
> >
> > The next and only thing on the agenda is to bump and unify the
> > two ebuilds to version 1.8.0 which was released in August.
> > Anyone?  
> 
> Whoever picks this up might want to consider switching to cmake, and
> installing static libs instead of shared libs.
> 
> The current ebuild installs shared libs with libtools default soname
> version (0). The cmake build doesn't even bother with that and
> installs bare .so files.
> 
> I don't think they are intended to be used as systemwide shared libraries.

AFAIK they are not intended to be installed as compiled code at all.
You are supposed to bundle them, or otherwise compile them from sources
along with your project.

-- 
Best regards,
Michał Górny



pgpuseFXF8SyI.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Packages up for grabs

[Mike Gilbert]

On Fri, Nov 25, 2016 at 10:06 AM, Thomas Kahle  wrote:
> Hi,
>
> I'd like to pass on maintainership of
>
> dev-cpp/gtest
> dev-cpp/gmock
>
> I don't use them and I don't even remember how I came to maintain
> them.  These two are among the packages that have googlecode in
> their SRC_URI, so this is a bit urgent.  Upstream has moved to
> github and merged the two packages:
>
> https://github.com/google/googletest
>
> The next and only thing on the agenda is to bump and unify the
> two ebuilds to version 1.8.0 which was released in August.
> Anyone?

Whoever picks this up might want to consider switching to cmake, and
installing static libs instead of shared libs.

The current ebuild installs shared libs with libtools default soname
version (0). The cmake build doesn't even bother with that and
installs bare .so files.

I don't think they are intended to be used as systemwide shared libraries.

Re: [gentoo-dev] Packages up for grabs

[Mathy Vanvoorden]

Hi,

I use them so I don't mind (proxy) maintaining them.

gr,
Mathy


--
Met vriendelijke groeten,
Best regards,

Mathy Vanvoorden

2016-11-25 16:06 GMT+01:00 Thomas Kahle :

> Hi,
>
> I'd like to pass on maintainership of
>
> dev-cpp/gtest
> dev-cpp/gmock
>
> I don't use them and I don't even remember how I came to maintain
> them.  These two are among the packages that have googlecode in
> their SRC_URI, so this is a bit urgent.  Upstream has moved to
> github and merged the two packages:
>
> https://github.com/google/googletest
>
> The next and only thing on the agenda is to bump and unify the
> two ebuilds to version 1.8.0 which was released in August.
> Anyone?
>
> Cheers,
> Thomas
>
> --
> Thomas Kahle
> http://dev.gentoo.org/~tomka/
>
>

[gentoo-dev] Packages up for grabs

[Thomas Kahle]

Hi,

I'd like to pass on maintainership of

dev-cpp/gtest
dev-cpp/gmock

I don't use them and I don't even remember how I came to maintain
them.  These two are among the packages that have googlecode in
their SRC_URI, so this is a bit urgent.  Upstream has moved to
github and merged the two packages:

https://github.com/google/googletest

The next and only thing on the agenda is to bump and unify the
two ebuilds to version 1.8.0 which was released in August.
Anyone?

Cheers,
Thomas

-- 
Thomas Kahle
http://dev.gentoo.org/~tomka/



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: Improving the stabilisation process - part 1

[Michael Palimaka]

On 25/11/16 21:00, Jason Zaman wrote:
> On Fri, Nov 25, 2016 at 08:27:12PM +1100, Michael Palimaka wrote:
>> On 25/11/16 17:51, Jason Zaman wrote:
 Automation
 ==

 It's easy to forget to check that all the required dependencies are in
 stable before filing a stabilisation test, but this wastes the actioning
 developer's time. I have prepared a bot that repoman checks the list of
 atoms and flags the bug appropriately. This allows easy filtering out of
 broken requests.
>>>
>>> This part would need to take into account DEPENDS ON in the bug too.
>>> When I file my xfce lists I dep on the gnome stable bug since I need
>>> the gtk stuff and if that isnt taken into account, repoman would just
>>> die.
>>
>> The bot will either try its best to take into account bug dependencies,
>> or otherwise just give up and skip such a bug.
>>
>>> I just realized there is another rare issue that we may have to take
>>> into account. Some sets of packages *must* be stablized in lockstep. For
>>> regular sets of packages like eg xfce if you leave off a bunch of the
>>> extras its no big deal.
>>> Eg for SELinux, the policy packages must all be stabilized all at
>>> once because they depend on each other (I think perl is like this too?).
>>>
>>> We would need a way for maintainers to ask for testing without actually
>>> committing. The maintainer can wait till everything is done and commit
>>> everything at once himself. Some flag to make the tatt script skip the
>>> step would be enough I think.
>>
>> Do you have a bug number handy so I can double check how the process
>> normally looks?
> 
> SwifT and I both run stable machines so we always just stabilize SELinux
> stuff ourselves so dont have a bug number, no.
> 
> its pretty much just:
> cd sec-policy/
> ekeyword amd64 x86 */*-2.20151208-r6.ebuild
> git add .
> repoman full
> repoman commit -m 'sec-policy: Stabilize selinux policy 2.20151208-r6'
> 
> every single selinux policy package {,R}DEPENDs on
> =sec-policy/selinux-base-policy-${PVR}
> which in turn deps on 
> =sec-policy/selinux-base-${PVR}
> and we always do everything with the same revision at the same time
> otherwise you get lots of weirdness. For us, each arch could be done
> separately (no point tho), the main part is that committing the packages
> in a random order or even alphabetical doesnt really work.
> 
> How aware of deps do we want to make such a tool? Having it figure out
> the right order seems like a lot of work. Or we could force the script
> to follow the order defined in the package list and then its up to the
> maintainer. Then also if there is a failure either abort completely or
> continue with the rest that it can (a. la --keep-going).

Most tools I've seen address this by keywording the entire list of
packages first, then doing the commit(s). tatt splits the entire process
into multiple stages (build the package, build revdeps, keyword the
ebuilds, git commit, ...) which can be run individually to maximise
control to the person running it.

That said, not everything needs a fancy tool. Your SELinux process looks
pretty good the way it is.

Re: [gentoo-dev] Re: Improving the stabilisation process - part 1

[Kent Fredric]

On Fri, 25 Nov 2016 20:05:55 +1100
Michael Palimaka  wrote:

> I'm not sure what you mean. A standardised format and a bot to repoman
> check lists in this format is part of my original post.

Ah. I didn't take enough care reading it and mostly replied on the earlier part.

Good to see we reached similar conclusions through different avenues.

(NB: I find "too long didn't read" coming at the bottom of a post not too 
productive
because people who feel an article was too long to read tend to not read to the 
bottom
just in case somebody put a TL;DR there. I always find that data to be better 
presented
head-first, in a "read this first to get the general gist of it, then keep 
reading if you care
about details" format, that way you hit your target audience sooner)


> > But at this point we're dove tailing good ideas into a fundamentally 
> > limited system
> > where we probably should have some dedicated interface (and tools) to 
> > automate and
> > verify these things.  
> 
> A dedicated portal for handling this type of thing would of course be
> preferable, and work is ongoing on such a tool. However, completing and
> rolling out such a system could take a very long time. Improvements to
> the stabilisation process via Bugzilla can be rolled out in very little
> time.
> 
> Let's not block incremental progress in favour of a perfect solution
> that doesn't exist yet.

Agreed. I'm fine with this as a concept as an initial staging.

> > 
> > Automating the *tests* is a contentious idea to some extent, but I doubt 
> > we'd see opposition
> > for the idea of "throw repoman at it at least and make sure it doesnt' 
> > barf"   
> 
> That depends on how you define 'test'. This proposal (part 1) deals
> exclusively with repoman, primarily to make sure that we don't waste
> time working on requests where the maintained failed to include all
> required atoms.
> 
> A future proposal will certainly involve fully-automated build testing
> of all requests, allowing effort to be better focused on runtime
> testing. I'm unsure how that could be controversial.

I'm not saying *I* have a problem with this, but I've gotten the over-all vibe
from some people that "autostabilizing all the things is bad" and I wanted to 
demark
this action as being somuch the opposite of that that even those people are 
unlikely to complain.

Because the subset of tests that only prove *repoman* integrity can't ever be
imagined sufficient in themselves to mark anything as "stable" or "working",
and so it forces people somewhere to do due diligence manually.

Hence, the general vibe is the fear that the abundance of automation will usurp
due diligence as people use that automation as the *only* indicator of "do we 
flip the flag" or not.



pgpksQzOuqspE.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: Improving the stabilisation process - part 1

[Jason Zaman]

On Fri, Nov 25, 2016 at 08:27:12PM +1100, Michael Palimaka wrote:
> On 25/11/16 17:51, Jason Zaman wrote:
> >> Automation
> >> ==
> >>
> >> It's easy to forget to check that all the required dependencies are in
> >> stable before filing a stabilisation test, but this wastes the actioning
> >> developer's time. I have prepared a bot that repoman checks the list of
> >> atoms and flags the bug appropriately. This allows easy filtering out of
> >> broken requests.
> > 
> > This part would need to take into account DEPENDS ON in the bug too.
> > When I file my xfce lists I dep on the gnome stable bug since I need
> > the gtk stuff and if that isnt taken into account, repoman would just
> > die.
> 
> The bot will either try its best to take into account bug dependencies,
> or otherwise just give up and skip such a bug.
> 
> > I just realized there is another rare issue that we may have to take
> > into account. Some sets of packages *must* be stablized in lockstep. For
> > regular sets of packages like eg xfce if you leave off a bunch of the
> > extras its no big deal.
> > Eg for SELinux, the policy packages must all be stabilized all at
> > once because they depend on each other (I think perl is like this too?).
> > 
> > We would need a way for maintainers to ask for testing without actually
> > committing. The maintainer can wait till everything is done and commit
> > everything at once himself. Some flag to make the tatt script skip the
> > step would be enough I think.
> 
> Do you have a bug number handy so I can double check how the process
> normally looks?

SwifT and I both run stable machines so we always just stabilize SELinux
stuff ourselves so dont have a bug number, no.

its pretty much just:
cd sec-policy/
ekeyword amd64 x86 */*-2.20151208-r6.ebuild
git add .
repoman full
repoman commit -m 'sec-policy: Stabilize selinux policy 2.20151208-r6'

every single selinux policy package {,R}DEPENDs on
=sec-policy/selinux-base-policy-${PVR}
which in turn deps on 
=sec-policy/selinux-base-${PVR}
and we always do everything with the same revision at the same time
otherwise you get lots of weirdness. For us, each arch could be done
separately (no point tho), the main part is that committing the packages
in a random order or even alphabetical doesnt really work.

How aware of deps do we want to make such a tool? Having it figure out
the right order seems like a lot of work. Or we could force the script
to follow the order defined in the package list and then its up to the
maintainer. Then also if there is a failure either abort completely or
continue with the rest that it can (a. la --keep-going).

-- Jason

[gentoo-dev] Re: Improving the stabilisation process - part 1

[Michael Palimaka]

On 25/11/16 17:51, Jason Zaman wrote:
>> Automation
>> ==
>>
>> It's easy to forget to check that all the required dependencies are in
>> stable before filing a stabilisation test, but this wastes the actioning
>> developer's time. I have prepared a bot that repoman checks the list of
>> atoms and flags the bug appropriately. This allows easy filtering out of
>> broken requests.
> 
> This part would need to take into account DEPENDS ON in the bug too.
> When I file my xfce lists I dep on the gnome stable bug since I need
> the gtk stuff and if that isnt taken into account, repoman would just
> die.

The bot will either try its best to take into account bug dependencies,
or otherwise just give up and skip such a bug.

> I just realized there is another rare issue that we may have to take
> into account. Some sets of packages *must* be stablized in lockstep. For
> regular sets of packages like eg xfce if you leave off a bunch of the
> extras its no big deal.
> Eg for SELinux, the policy packages must all be stabilized all at
> once because they depend on each other (I think perl is like this too?).
> 
> We would need a way for maintainers to ask for testing without actually
> committing. The maintainer can wait till everything is done and commit
> everything at once himself. Some flag to make the tatt script skip the
> step would be enough I think.

Do you have a bug number handy so I can double check how the process
normally looks?

[gentoo-dev] Re: Improving the stabilisation process - part 1

[Michael Palimaka]

On 25/11/16 18:51, Kent Fredric wrote:
> On Fri, 25 Nov 2016 14:40:36 +0800
> Jason Zaman  wrote:
> 
>> One way would be to use a plain text attachment with a standardized
>> filename. If there are updates to the list then the new should obsolete
>> the old and the script can pull non-obsoleted ones.
>> The problem then is how do you search for them properly? put them all
>> in the title anyway? then its duplicated.
>>
>> When i do big lists of packages the title is eg "XFCE Stabilization for
>> Nov 2016" which is not duplicated and okay.
>> For single packages the title is just "cat/pkg-1.2.3 stablereq" so then
>> we duplicate anyway?
> 
> If you standardized the format / filename, you could have some process
> that monitors bugzilla and indexes its contents and computes overlaps,
> and provides per-arch aggregates grouped by bugs.
> 
> Then the "tester" would get it in the format:
> 
> =cat/pn-VERSION  #4145 #678345
> =cat/pn-VERSION  #4145
> =cat/pn-VERSION  #678345
> 
> Having it in a standardized form would also potentially make it 
> repoman-checkable
> via automation:
> 
> Just like our current QA bots do, a QA Bot could fetch the 
> keywording/stabilization
> "recipie" and locally apply the requisite changes, and then do a basic 
> repoman sanity
> check to ensure coherence.

I'm not sure what you mean. A standardised format and a bot to repoman
check lists in this format is part of my original post.

> But at this point we're dove tailing good ideas into a fundamentally limited 
> system
> where we probably should have some dedicated interface (and tools) to 
> automate and
> verify these things.

A dedicated portal for handling this type of thing would of course be
preferable, and work is ongoing on such a tool. However, completing and
rolling out such a system could take a very long time. Improvements to
the stabilisation process via Bugzilla can be rolled out in very little
time.

Let's not block incremental progress in favour of a perfect solution
that doesn't exist yet.

> 
> Automating the *tests* is a contentious idea to some extent, but I doubt we'd 
> see opposition
> for the idea of "throw repoman at it at least and make sure it doesnt' barf" 

That depends on how you define 'test'. This proposal (part 1) deals
exclusively with repoman, primarily to make sure that we don't waste
time working on requests where the maintained failed to include all
required atoms.

A future proposal will certainly involve fully-automated build testing
of all requests, allowing effort to be better focused on runtime
testing. I'm unsure how that could be controversial.

[gentoo-dev] Re: Improving the stabilisation process - part 1

[Michael Palimaka]

On 25/11/16 17:40, Jason Zaman wrote:
> On Fri, Nov 25, 2016 at 05:54:41PM +1300, Kent Fredric wrote:
>> On Fri, 25 Nov 2016 06:41:20 +1100
>> Michael Palimaka  wrote:
>>
>>> Example atom list from a bug with amd64, arm, and x86 in CC:
>>>
>>> =app-foo/bar-1.2.3   # will be stabilised on amd64, arm, and x86
>>> =app-foo/baz-2.3.4 amd64 x86 # will be stabilised on only amd64 and x86
>>
>> I was doing this in the past, but there's a reason I stopped:
>>
>> Bugzilla-enforced wordwrap ( at least, this is very strict on the 
>> bugzilla-email relay )
>>
>>> =app-foo/bar-1.2.3   # will be stabilised on amd64, arm, and x86
>>
>> Could become more like 
>>
>>> =app-foo/bar-1.2.3   # will be stabilised on amd64, 
>>> arm, and x86
> 
> One way would be to use a plain text attachment with a standardized
> filename. If there are updates to the list then the new should obsolete
> the old and the script can pull non-obsoleted ones.
> The problem then is how do you search for them properly? put them all
> in the title anyway? then its duplicated.

While I personally think the additional field is adequate, I'm more than
happy to support attachments as well. Suggestions for the standardised
filename? Alternatively, it would easy to add a flag to the interface to
mark an attachment as a stabilisation list.

> When i do big lists of packages the title is eg "XFCE Stabilization for
> Nov 2016" which is not duplicated and okay.
> For single packages the title is just "cat/pkg-1.2.3 stablereq" so then
> we duplicate anyway?

Yes, every atom should be referenced either in the special field (or as
per above in an attachment), even if that means duplicating the title.
It's a very minor effort on the part of the person filing the bug, but
it will guarantee that we can always find the atom list in the same
place every time.

Of course, we can't *force* anyone to use the new field if they don't
want to. They might find themselves wondering why their request ends up
on the bottom of the queue however. :-)

Re: [gentoo-dev] new eclass: tmpfiles.eclass round 3

[Michał Górny]

On Wed, 16 Nov 2016 16:37:15 -0600
William Hubbs  wrote:

> # @FUNCTION: tmpfiles_process
> # @USAGE: tmpfiles_process   ...
> # @DESCRIPTION:
> # Call a tmpfiles.d implementation to create new volatile and temporary
> # files and directories.
> # Specific files and directories can be listed, but if they are not, all
> # tmpfiles.d files will be processed.

This contradicts the code. And I'd prefer the code, since allowing
empty list will only encourage developers to be lazy, and I'm not
really convinced that unconditionally running every tmpfiles.d file
(esp. that user may be overriding some of them) at runtime is a good
idea.

> tmpfiles_process() {
>   debug-print-function "${FUNCNAME}" "$@"
> 
>   [[ ${EBUILD_PHASE} == postinst ]] || die "${FUNCNAME}: Only valid in 
> pkg_postinst"
>   [[ ${#} -gt 0 ]] || die "${FUNCNAME}: Must specify at least one 
> filename"
>   [[ ${ROOT} == / ]] || return 0
> 
>   if type systemd-tmpfiles &> /dev/null; then
>   systemd-tmpfiles --create "$@"
>   elif type opentmptmpfiles &> /dev/null; then

You have double 'tmp' here.

>   opentmpfiles --create "$@"
>   fi
> }

Also, I'm wondering if we should have any specific error handling here.
Maybe we should ewarn if something fails? Mike?

Also, possibly 'else' branch with big fat warning if for some reason
dependencies are missing?

-- 
Best regards,
Michał Górny



pgp_8f520aL4q.pgp
Description: OpenPGP digital signature