1 |
On Fri, Nov 25, 2016 at 08:27:12PM +1100, Michael Palimaka wrote: |
2 |
> On 25/11/16 17:51, Jason Zaman wrote: |
3 |
> >> Automation |
4 |
> >> ========== |
5 |
> >> |
6 |
> >> It's easy to forget to check that all the required dependencies are in |
7 |
> >> stable before filing a stabilisation test, but this wastes the actioning |
8 |
> >> developer's time. I have prepared a bot that repoman checks the list of |
9 |
> >> atoms and flags the bug appropriately. This allows easy filtering out of |
10 |
> >> broken requests. |
11 |
> > |
12 |
> > This part would need to take into account DEPENDS ON in the bug too. |
13 |
> > When I file my xfce lists I dep on the gnome stable bug since I need |
14 |
> > the gtk stuff and if that isnt taken into account, repoman would just |
15 |
> > die. |
16 |
> |
17 |
> The bot will either try its best to take into account bug dependencies, |
18 |
> or otherwise just give up and skip such a bug. |
19 |
> |
20 |
> > I just realized there is another rare issue that we may have to take |
21 |
> > into account. Some sets of packages *must* be stablized in lockstep. For |
22 |
> > regular sets of packages like eg xfce if you leave off a bunch of the |
23 |
> > extras its no big deal. |
24 |
> > Eg for SELinux, the policy packages must all be stabilized all at |
25 |
> > once because they depend on each other (I think perl is like this too?). |
26 |
> > |
27 |
> > We would need a way for maintainers to ask for testing without actually |
28 |
> > committing. The maintainer can wait till everything is done and commit |
29 |
> > everything at once himself. Some flag to make the tatt script skip the |
30 |
> > step would be enough I think. |
31 |
> |
32 |
> Do you have a bug number handy so I can double check how the process |
33 |
> normally looks? |
34 |
|
35 |
SwifT and I both run stable machines so we always just stabilize SELinux |
36 |
stuff ourselves so dont have a bug number, no. |
37 |
|
38 |
its pretty much just: |
39 |
cd sec-policy/ |
40 |
ekeyword amd64 x86 */*-2.20151208-r6.ebuild |
41 |
git add . |
42 |
repoman full |
43 |
repoman commit -m 'sec-policy: Stabilize selinux policy 2.20151208-r6' |
44 |
|
45 |
every single selinux policy package {,R}DEPENDs on |
46 |
=sec-policy/selinux-base-policy-${PVR} |
47 |
which in turn deps on |
48 |
=sec-policy/selinux-base-${PVR} |
49 |
and we always do everything with the same revision at the same time |
50 |
otherwise you get lots of weirdness. For us, each arch could be done |
51 |
separately (no point tho), the main part is that committing the packages |
52 |
in a random order or even alphabetical doesnt really work. |
53 |
|
54 |
How aware of deps do we want to make such a tool? Having it figure out |
55 |
the right order seems like a lot of work. Or we could force the script |
56 |
to follow the order defined in the package list and then its up to the |
57 |
maintainer. Then also if there is a failure either abort completely or |
58 |
continue with the rest that it can (a. la --keep-going). |
59 |
|
60 |
-- Jason |