| 1 |
On Sun, Dec 16, 2018 at 2:40 PM Jeroen Roovers <jer@g.o> wrote: |
| 2 |
> |
| 3 |
> On Fri, 14 Dec 2018 12:03:52 -0800 |
| 4 |
> Matt Turner <mattst88@g.o> wrote: |
| 5 |
> |
| 6 |
> > Thanks. What do we want to do about -304? |
| 7 |
> |
| 8 |
> It's not on the list above because it's a "legacy driver", not a |
| 9 |
> "short lived" branch[1]. It's not relevant in this context what happens |
| 10 |
> to the 304 branch, the context being a cleanup of intermediate branches |
| 11 |
> that were abandoned and surpassed by "long lived" branches. |
| 12 |
|
| 13 |
I understand. This was just a convenient place to ask a related question. |
| 14 |
|
| 15 |
> > It still requires xorg-server-1.19 which I'd like to drop due to a |
| 16 |
> > security vulnerability. After the listed versions are gone, -304 will |
| 17 |
> > be the only thing keeping 1.19 in tree. |
| 18 |
|
| 19 |
It's bug https://bugs.gentoo.org/669588 |
| 20 |
|
| 21 |
> I see no open security bug report for this. If we had one of those, then |
| 22 |
> we could write a package.mask entry for both xorg-server and |
| 23 |
> nvidia-drivers with a reference to the security issue, or add the |
| 24 |
> branches that are now masked for removal. That way people can plan |
| 25 |
> their hardware's obsolescence properly or shift to a different driver. |
| 26 |
|
| 27 |
I guess my question to you is whether you think it's okay to mask -304 |
| 28 |
for removal or whether there are enough users that we should keep it |
| 29 |
under package.mask? |
Archives