[gentoo-dev] News Item: OpenAFS no longer needs kernel option DEBUG_RODATA

[gentoo-dev] News Item: OpenAFS no longer needs kernel option DEBUG_RODATA

[NP-Hardass]

[-- Attachment #1.1: Type: text/plain, Size: 1748 bytes --]

This is the first draft of a news item describing a packaging change for
OpenAFS so that we no longer require the DEBUG_RODATA be turned off.
Given the security implications of the previous setting of having
CONFIG_DEBUG_RODATA=n, we thought it prudent to ensure that OpenAFS
users get notice of the change in a manner that they are not likely to
miss (unlike a message in a phase that can be missed/hidden/squelched).


Title: OpenAFS no longer needs kernel option DEBUG_RODATA
Author: NP-Hardass <NP-Hardass@gentoo.org>
Author: Andrew Savchenko <bircoph@gentoo.org>
Content-Type: text/plain
Posted: 2016-07-23
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: <=net-fs/openafs-kernel-1.6.18.2
Display-If-Keyword: amd64
Display-If-Keyword: ~amd64-linux
Display-If-Keyword: ~sparc
Display-If-Keyword: x86
Display-If-Keyword: ~x86-linux

As a result of bug #127084 [1], it was determined that OpenAFS's kernel
module required that the kernel's data structures be read-write
(CONFIG_DEBUG_RODATA=n).  Upon reviewing the latest version of OpenAFS
with Linux kernels 3.4-4.4, it has been determined that this condition
is no longer necessary to ensure that OpenAFS builds and loads into the
kernel.

Starting with net-fs/openafs-kernel-1.6.18.2, this condition is no longer
forced in the ebuild. Considering the security implications of having
CONFIG_DEBUG_RODATA turned off, it is highly advised that you adjust your
kernel config accordingly.  Please note that the default setting for
CONFIG_DEBUG_RODATA is "y" and unless you have another reason for keeping
it disabled, we highly recommend that you re-enable CONFIG_DEBUG_RODATA.

[1] https://bugs.gentoo.org/show_bug.cgi?id=127084


-- 
NP-Hardass


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] News Item: OpenAFS no longer needs kernel option DEBUG_RODATA

[Michael Orlitzky]

On 07/20/2016 01:13 PM, NP-Hardass wrote:
> Display-If-Installed: <=net-fs/openafs-kernel-1.6.18.2
> 
> ...
> 
> Starting with net-fs/openafs-kernel-1.6.18.2, this condition is no longer
> forced in the ebuild. 

Might not that version bound might backfire if someone upgrades before
reading the news? People who pull from git often don't necessarily get
the news in a timely fashion.

Would it be simpler to ewarn in the ebuilds (for e.g. a year) if
DEBUG_RODATA=n?

Re: [gentoo-dev] News Item: OpenAFS no longer needs kernel option DEBUG_RODATA

[Austin English]

[-- Attachment #1.1: Type: text/plain, Size: 2362 bytes --]

On 07/20/2016 12:13 PM, NP-Hardass wrote:
> This is the first draft of a news item describing a packaging change for
> OpenAFS so that we no longer require the DEBUG_RODATA be turned off.
> Given the security implications of the previous setting of having
> CONFIG_DEBUG_RODATA=n, we thought it prudent to ensure that OpenAFS
> users get notice of the change in a manner that they are not likely to
> miss (unlike a message in a phase that can be missed/hidden/squelched).
> 
> 
> Title: OpenAFS no longer needs kernel option DEBUG_RODATA
> Author: NP-Hardass <NP-Hardass@gentoo.org>
> Author: Andrew Savchenko <bircoph@gentoo.org>
> Content-Type: text/plain
> Posted: 2016-07-23
> Revision: 1
> News-Item-Format: 1.0
> Display-If-Installed: <=net-fs/openafs-kernel-1.6.18.2
> Display-If-Keyword: amd64
> Display-If-Keyword: ~amd64-linux
> Display-If-Keyword: ~sparc
> Display-If-Keyword: x86
> Display-If-Keyword: ~x86-linux
> 
> As a result of bug #127084 [1], it was determined that OpenAFS's kernel
> module required that the kernel's data structures be read-write
> (CONFIG_DEBUG_RODATA=n).  Upon reviewing the latest version of OpenAFS
> with Linux kernels 3.4-4.4, it has been determined that this condition
> is no longer necessary to ensure that OpenAFS builds and loads into the
> kernel.

The second sentence reads awkwardly to me. Was this recent discovery a
result of OpenAFS changes, or from a re-audit of the source?

If it's the former, I'd use something like:
As of openafs-1.6.18.2, it is no longer necessary to disable
CONFIG_DEBUG_RODATA for the OpenAFS module to build and be loaded by the
kernel.

If the ebuild doesn't block on kernels < 3.4, of course warn about that
as well.

For the latter it is okay, but still a bit akwardly worded.

> Starting with net-fs/openafs-kernel-1.6.18.2, this condition is no longer
> forced in the ebuild. Considering the security implications of having
> CONFIG_DEBUG_RODATA turned off, it is highly advised that you adjust your
> kernel config accordingly.  Please note that the default setting for
> CONFIG_DEBUG_RODATA is "y" and unless you have another reason for keeping
> it disabled, we highly recommend that you re-enable CONFIG_DEBUG_RODATA.
> 
> [1] https://bugs.gentoo.org/show_bug.cgi?id=127084


-- 
-Austin
GPG: 00B3 2957 B94B F3E1


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] News Item: OpenAFS no longer needs kernel option DEBUG_RODATA

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1723 bytes --]

On Wed, 20 Jul 2016 15:12:01 -0400 Michael Orlitzky wrote:
> On 07/20/2016 01:13 PM, NP-Hardass wrote:
> > Display-If-Installed: <=net-fs/openafs-kernel-1.6.18.2
> > 
> > ...
> > 
> > Starting with net-fs/openafs-kernel-1.6.18.2, this condition is no longer
> > forced in the ebuild. 
> 
> Might not that version bound might backfire if someone upgrades before
> reading the news? People who pull from git often don't necessarily get
> the news in a timely fashion.
> 
> Would it be simpler to ewarn in the ebuilds (for e.g. a year) if
> DEBUG_RODATA=n?

We already do this in openafs-kernel-1.6.18.2.ebuild:

    if use kernel_linux && [[ ${REPLACING_VERSIONS} < "1.6.18.2" ]]; then
        ewarn "As of OpenAFS 1.6.18.2, Gentoo's packaging no longer requires"
        ewarn "that CONFIG_DEBUG_RODATA be turned off in one's kernel config."
        ewarn "If you only turned this option off for OpenAFS, please re-enable"
        ewarn "it, as keeping it turned off is a security risk."
    fi

The rationale for the news item in addition to ewarn message is
following:

1. This change is very important, many people may miss elog
messages: there are too many of them. Frankly, on a system with 2200+
packages this is just not possible for me to read all stuff (so I
usually ignore einfo stuff :)). Thus having several channels to
distribute this information will be a good idea.

2. This change affects a kernel. On large updates the kernel is
usually one of the first things to be updated. So this news item will
allow users to configure their kernel properly from the start and
avoid useless reconfiguration and recompilation of the kernel later.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] News Item: OpenAFS no longer needs kernel option DEBUG_RODATA

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 3123 bytes --]

On Wed, 20 Jul 2016 14:14:23 -0500 Austin English wrote:
> On 07/20/2016 12:13 PM, NP-Hardass wrote:
> > This is the first draft of a news item describing a packaging change for
> > OpenAFS so that we no longer require the DEBUG_RODATA be turned off.
> > Given the security implications of the previous setting of having
> > CONFIG_DEBUG_RODATA=n, we thought it prudent to ensure that OpenAFS
> > users get notice of the change in a manner that they are not likely to
> > miss (unlike a message in a phase that can be missed/hidden/squelched).
> > 
> > 
> > Title: OpenAFS no longer needs kernel option DEBUG_RODATA
> > Author: NP-Hardass <NP-Hardass@gentoo.org>
> > Author: Andrew Savchenko <bircoph@gentoo.org>
> > Content-Type: text/plain
> > Posted: 2016-07-23
> > Revision: 1
> > News-Item-Format: 1.0
> > Display-If-Installed: <=net-fs/openafs-kernel-1.6.18.2
> > Display-If-Keyword: amd64
> > Display-If-Keyword: ~amd64-linux
> > Display-If-Keyword: ~sparc
> > Display-If-Keyword: x86
> > Display-If-Keyword: ~x86-linux
> > 
> > As a result of bug #127084 [1], it was determined that OpenAFS's kernel
> > module required that the kernel's data structures be read-write
> > (CONFIG_DEBUG_RODATA=n).  Upon reviewing the latest version of OpenAFS
> > with Linux kernels 3.4-4.4, it has been determined that this condition
> > is no longer necessary to ensure that OpenAFS builds and loads into the
> > kernel.
> 
> The second sentence reads awkwardly to me. Was this recent discovery a
> result of OpenAFS changes, or from a re-audit of the source?
> 
> If it's the former, I'd use something like:
> As of openafs-1.6.18.2, it is no longer necessary to disable
> CONFIG_DEBUG_RODATA for the OpenAFS module to build and be loaded by the
> kernel.
> 
> If the ebuild doesn't block on kernels < 3.4, of course warn about that
> as well.
> 
> For the latter it is okay, but still a bit akwardly worded.

This discovery is a result of ebuild audit in the first place.
While discussing another issue of OpenAFS [1], we noticed user
report that it works fine with GRSecurity CONFIG_PAX_KERNEXEC,
which is more strict variant of vanilla's kernel
CONFIG_DEBUG_RODATA. So natural question was: do we really need
that ancient 10-years old limitation these days?

Thanks to NP-Hardass hard testing we know that we don't need it and
for quite a while, testing was limited to linux-3.4 due to
manpower issues or technical limitations I suppose, so older
versions are likely to work too, just not verified to do so. We
don't know exactly when and where this issue was fixes aside from
the fact that it was done a long time ago.

It is likely to be a fix in the OpenAFS, but I can't find or grep
anything relevant in its ChangeLog (though it is easy to miss
message in 10 years long log). So as a precaution a wide range of
kernels was tested. What the second sentence is trying to say is
that we built and tested all kernels within 3.4 - 4.4 range and
verified that it works fine.

[1] https://bugs.gentoo.org/show_bug.cgi?id=586244

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] News Item: OpenAFS no longer needs kernel option DEBUG_RODATA

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1150 bytes --]

On Thu, 21 Jul 2016 00:22:36 +0300
Andrew Savchenko <bircoph@gentoo.org> wrote:

> On Wed, 20 Jul 2016 15:12:01 -0400 Michael Orlitzky wrote:
> > On 07/20/2016 01:13 PM, NP-Hardass wrote:  
> > > Display-If-Installed: <=net-fs/openafs-kernel-1.6.18.2
> > > 
> > > ...
> > > 
> > > Starting with net-fs/openafs-kernel-1.6.18.2, this condition is no longer
> > > forced in the ebuild.   
> > 
> > Might not that version bound might backfire if someone upgrades before
> > reading the news? People who pull from git often don't necessarily get
> > the news in a timely fashion.
> > 
> > Would it be simpler to ewarn in the ebuilds (for e.g. a year) if
> > DEBUG_RODATA=n?  
> 
> We already do this in openafs-kernel-1.6.18.2.ebuild:
> 
>     if use kernel_linux && [[ ${REPLACING_VERSIONS} < "1.6.18.2" ]]; then

Few important QA notes:

1. < is lexicographical comparison, so e.g. 1.6.2.2 < 1.6.18.2 gives
false,

2. REPLACING_VERSIONS can have more than one value,

3. Finally, '' < 1.6.18.2 gives true, so it is also printed for initial
install.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

[gentoo-dev] Re: News Item: OpenAFS no longer needs kernel option DEBUG_RODATA

[Jonathan Callen]

[-- Attachment #1.1: Type: text/plain, Size: 1610 bytes --]

On 07/21/2016 01:12 AM, Michał Górny wrote:
> On Thu, 21 Jul 2016 00:22:36 +0300
> Andrew Savchenko <bircoph@gentoo.org> wrote:
> 
>> On Wed, 20 Jul 2016 15:12:01 -0400 Michael Orlitzky wrote:
>>> On 07/20/2016 01:13 PM, NP-Hardass wrote:  
>>>> Display-If-Installed: <=net-fs/openafs-kernel-1.6.18.2
>>>>
>>>> ...
>>>>
>>>> Starting with net-fs/openafs-kernel-1.6.18.2, this condition is no longer
>>>> forced in the ebuild.   
>>>
>>> Might not that version bound might backfire if someone upgrades before
>>> reading the news? People who pull from git often don't necessarily get
>>> the news in a timely fashion.
>>>
>>> Would it be simpler to ewarn in the ebuilds (for e.g. a year) if
>>> DEBUG_RODATA=n?  
>>
>> We already do this in openafs-kernel-1.6.18.2.ebuild:
>>
>>     if use kernel_linux && [[ ${REPLACING_VERSIONS} < "1.6.18.2" ]]; then
> 
> Few important QA notes:
> 
> 1. < is lexicographical comparison, so e.g. 1.6.2.2 < 1.6.18.2 gives
> false,
> 
> 2. REPLACING_VERSIONS can have more than one value,
> 
> 3. Finally, '' < 1.6.18.2 gives true, so it is also printed for initial
> install.
> 

If you want to do a package version comparison, you probably want to use
the function version_is_at_least() in versionator.eclass.  The primary
version comparison function in that eclass was written to be a complete
implementation of the version comparison algorithm in PMS.  Maybe
eventually we'll get a version comparison function in PMS so we won't
have to resort to the wonderfully complex bash functions in that eclass :).

-- 
Jonathan Callen


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 847 bytes --]

Re: [gentoo-dev] News Item: OpenAFS no longer needs kernel option DEBUG_RODATA

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1364 bytes --]

On Thu, 21 Jul 2016 07:12:12 +0200 Michał Górny wrote:
> On Thu, 21 Jul 2016 00:22:36 +0300
> Andrew Savchenko <bircoph@gentoo.org> wrote:
> 
> > On Wed, 20 Jul 2016 15:12:01 -0400 Michael Orlitzky wrote:
> > > On 07/20/2016 01:13 PM, NP-Hardass wrote:  
> > > > Display-If-Installed: <=net-fs/openafs-kernel-1.6.18.2
> > > > 
> > > > ...
> > > > 
> > > > Starting with net-fs/openafs-kernel-1.6.18.2, this condition is no longer
> > > > forced in the ebuild.   
> > > 
> > > Might not that version bound might backfire if someone upgrades before
> > > reading the news? People who pull from git often don't necessarily get
> > > the news in a timely fashion.
> > > 
> > > Would it be simpler to ewarn in the ebuilds (for e.g. a year) if
> > > DEBUG_RODATA=n?  
> > 
> > We already do this in openafs-kernel-1.6.18.2.ebuild:
> > 
> >     if use kernel_linux && [[ ${REPLACING_VERSIONS} < "1.6.18.2" ]]; then
> 
> Few important QA notes:
> 
> 1. < is lexicographical comparison, so e.g. 1.6.2.2 < 1.6.18.2 gives
> false,

Thanks, fixed.

> 2. REPLACING_VERSIONS can have more than one value,

While it can indeed, I see no way for this to happen if package
hasn't and never had multiple slots.

> 3. Finally, '' < 1.6.18.2 gives true, so it is also printed for initial
> install.

Fixed.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] News Item: OpenAFS no longer needs kernel option DEBUG_RODATA

[Michał Górny]

Dnia 22 lipca 2016 13:00:42 CEST, Andrew Savchenko <bircoph@gentoo.org> napisał(a):
>On Thu, 21 Jul 2016 07:12:12 +0200 Michał Górny wrote:
>> On Thu, 21 Jul 2016 00:22:36 +0300
>> Andrew Savchenko <bircoph@gentoo.org> wrote:
>> 
>> > On Wed, 20 Jul 2016 15:12:01 -0400 Michael Orlitzky wrote:
>> > > On 07/20/2016 01:13 PM, NP-Hardass wrote:  
>> > > > Display-If-Installed: <=net-fs/openafs-kernel-1.6.18.2
>> > > > 
>> > > > ...
>> > > > 
>> > > > Starting with net-fs/openafs-kernel-1.6.18.2, this condition is
>no longer
>> > > > forced in the ebuild.   
>> > > 
>> > > Might not that version bound might backfire if someone upgrades
>before
>> > > reading the news? People who pull from git often don't
>necessarily get
>> > > the news in a timely fashion.
>> > > 
>> > > Would it be simpler to ewarn in the ebuilds (for e.g. a year) if
>> > > DEBUG_RODATA=n?  
>> > 
>> > We already do this in openafs-kernel-1.6.18.2.ebuild:
>> > 
>> >     if use kernel_linux && [[ ${REPLACING_VERSIONS} < "1.6.18.2"
>]]; then
>> 
>> Few important QA notes:
>> 
>> 1. < is lexicographical comparison, so e.g. 1.6.2.2 < 1.6.18.2 gives
>> false,
>
>Thanks, fixed.
>
>> 2. REPLACING_VERSIONS can have more than one value,
>
>While it can indeed, I see no way for this to happen if package
>hasn't and never had multiple slots.

Wrong. PMS specifically requests you to account for such a possibility.

>
>> 3. Finally, '' < 1.6.18.2 gives true, so it is also printed for
>initial
>> install.
>
>Fixed.
>
>Best regards,
>Andrew Savchenko


-- 
Best regards,
Michał Górny (by phone)

Re: [gentoo-dev] News Item: OpenAFS no longer needs kernel option DEBUG_RODATA

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1029 bytes --]

On Fri, 22 Jul 2016 13:14:23 +0200 Michał Górny wrote:
> Dnia 22 lipca 2016 13:00:42 CEST, Andrew Savchenko <bircoph@gentoo.org> napisał(a):
> >On Thu, 21 Jul 2016 07:12:12 +0200 Michał Górny wrote:
[...]
> >> Few important QA notes:
> >> 
> >> 1. < is lexicographical comparison, so e.g. 1.6.2.2 < 1.6.18.2 gives
> >> false,
> >
> >Thanks, fixed.
> >
> >> 2. REPLACING_VERSIONS can have more than one value,
> >
> >While it can indeed, I see no way for this to happen if package
> >hasn't and never had multiple slots.
> 
> Wrong. PMS specifically requests you to account for such a possibility.

Common sence must prevail over formal approaches. While PMS is
great, it is not perfect in all possible aspects, and this one is
one of them.

I see no point in trashing ebuilds with dead code that will never
be used. Though if there will be a PMS or eclass function with
"proper" implementation, I don't mind, since extra code will be
moved from ebuild elsewhere.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] News Item: OpenAFS no longer needs kernel option DEBUG_RODATA

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1442 bytes --]

On Fri, 22 Jul 2016 16:41:56 +0300
Andrew Savchenko <bircoph@gentoo.org> wrote:

> On Fri, 22 Jul 2016 13:14:23 +0200 Michał Górny wrote:
> > Dnia 22 lipca 2016 13:00:42 CEST, Andrew Savchenko <bircoph@gentoo.org> napisał(a):  
> > >On Thu, 21 Jul 2016 07:12:12 +0200 Michał Górny wrote:  
> [...]
> > >> Few important QA notes:
> > >> 
> > >> 1. < is lexicographical comparison, so e.g. 1.6.2.2 < 1.6.18.2 gives
> > >> false,  
> > >
> > >Thanks, fixed.
> > >  
> > >> 2. REPLACING_VERSIONS can have more than one value,  
> > >
> > >While it can indeed, I see no way for this to happen if package
> > >hasn't and never had multiple slots.  
> > 
> > Wrong. PMS specifically requests you to account for such a possibility.  
> 
> Common sence must prevail over formal approaches. While PMS is
> great, it is not perfect in all possible aspects, and this one is
> one of them.
> 
> I see no point in trashing ebuilds with dead code that will never
> be used. Though if there will be a PMS or eclass function with
> "proper" implementation, I don't mind, since extra code will be
> moved from ebuild elsewhere.

So are you officially refusing to follow the PMS based on your idea of
'common sense' and ignoring the specific reasons it was written like
that? I should put my QA hat on, and request official action upon your
refusal.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] News Item: OpenAFS no longer needs kernel option DEBUG_RODATA

[Ciaran McCreesh]

On Fri, 22 Jul 2016 16:41:56 +0300
Andrew Savchenko <bircoph@gentoo.org> wrote:
> On Fri, 22 Jul 2016 13:14:23 +0200 Michał Górny wrote:
> > Dnia 22 lipca 2016 13:00:42 CEST, Andrew Savchenko
> > <bircoph@gentoo.org> napisał(a):  
> > >On Thu, 21 Jul 2016 07:12:12 +0200 Michał Górny wrote:  
> [...]
> > >> Few important QA notes:
> > >> 
> > >> 1. < is lexicographical comparison, so e.g. 1.6.2.2 < 1.6.18.2
> > >> gives false,  
> > >
> > >Thanks, fixed.
> > >  
> > >> 2. REPLACING_VERSIONS can have more than one value,  
> > >
> > >While it can indeed, I see no way for this to happen if package
> > >hasn't and never had multiple slots.  
> > 
> > Wrong. PMS specifically requests you to account for such a
> > possibility.  
> 
> Common sence must prevail over formal approaches. While PMS is
> great, it is not perfect in all possible aspects, and this one is
> one of them.
> 

And this is a perfect example of why so much stuff in Gentoo is subtly
broken... Things are usually more complicated than you think, buggy code
usually works well enough that the mistakes aren't noticed in most
cases, and too many developers are far too convinced of their own
competence. You need to appreciate that you do not have a complete
understanding of what is going on, your "common sense" is leading you
astray, and that that API was designed the way it was out of necessity.

> I see no point in trashing ebuilds with dead code that will never
> be used. Though if there will be a PMS or eclass function with
> "proper" implementation, I don't mind, since extra code will be
> moved from ebuild elsewhere.

Slots are not the only way in which you can end up with multiple
installed versions of the same package. Another way is if there's a
fatal error during certain parts of the upgrade process.

-- 
Ciaran McCreesh

Re: [gentoo-dev] News Item: OpenAFS no longer needs kernel option DEBUG_RODATA

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1062 bytes --]

Hi,

On Fri, 22 Jul 2016 14:57:36 +0100 Ciaran McCreesh wrote:
> On Fri, 22 Jul 2016 16:41:56 +0300
> Andrew Savchenko <bircoph@gentoo.org> wrote:
[...]
> > I see no point in trashing ebuilds with dead code that will never
> > be used. Though if there will be a PMS or eclass function with
> > "proper" implementation, I don't mind, since extra code will be
> > moved from ebuild elsewhere.
> 
> Slots are not the only way in which you can end up with multiple
> installed versions of the same package. Another way is if there's a
> fatal error during certain parts of the upgrade process.

If setup is broken to the point when several version within single
slot are installed (or are reported to be installed), then:

1) There is no way to tell which version is valid and all of them
may be invalid. That's why REPLACING_VERSIONS is of no use at all
in such situation.

2) System is severely broken and mistakenly shown (or not shown)
ewarn message will be the least problem for a user of such system.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] News Item: OpenAFS no longer needs kernel option DEBUG_RODATA

[Ciaran McCreesh]

On Sat, 23 Jul 2016 17:23:48 +0300
Andrew Savchenko <bircoph@gentoo.org> wrote:
> On Fri, 22 Jul 2016 14:57:36 +0100 Ciaran McCreesh wrote:
> > On Fri, 22 Jul 2016 16:41:56 +0300
> > Andrew Savchenko <bircoph@gentoo.org> wrote:  
> [...]
> > > I see no point in trashing ebuilds with dead code that will never
> > > be used. Though if there will be a PMS or eclass function with
> > > "proper" implementation, I don't mind, since extra code will be
> > > moved from ebuild elsewhere.  
> > 
> > Slots are not the only way in which you can end up with multiple
> > installed versions of the same package. Another way is if there's a
> > fatal error during certain parts of the upgrade process.  
> 
> If setup is broken to the point when several version within single
> slot are installed (or are reported to be installed), then:
> 
> 1) There is no way to tell which version is valid and all of them
> may be invalid. That's why REPLACING_VERSIONS is of no use at all
> in such situation.
> 
> 2) System is severely broken and mistakenly shown (or not shown)
> ewarn message will be the least problem for a user of such system.

Uh, nope. The PM can recover from that situation, so long as people
don't go around writing broken ebuilds that make unwarranted
assumptions that the spec specifically tells them not to make. Don't
get into the habit of writing broken code.

Or to put it another way: you are wrong, and you don't know enough
about the situation to understand why you're wrong, and you clearly
have no interest in learning, so just do as you're told.

-- 
Ciaran McCreesh

Re: [gentoo-dev] News Item: OpenAFS no longer needs kernel option DEBUG_RODATA

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 3579 bytes --]

On Sat, 23 Jul 2016 15:38:26 +0100 Ciaran McCreesh wrote:
> On Sat, 23 Jul 2016 17:23:48 +0300
> Andrew Savchenko <bircoph@gentoo.org> wrote:
> > On Fri, 22 Jul 2016 14:57:36 +0100 Ciaran McCreesh wrote:
> > > On Fri, 22 Jul 2016 16:41:56 +0300
> > > Andrew Savchenko <bircoph@gentoo.org> wrote:  
> > [...]
> > > > I see no point in trashing ebuilds with dead code that will never
> > > > be used. Though if there will be a PMS or eclass function with
> > > > "proper" implementation, I don't mind, since extra code will be
> > > > moved from ebuild elsewhere.  
> > > 
> > > Slots are not the only way in which you can end up with multiple
> > > installed versions of the same package. Another way is if there's a
> > > fatal error during certain parts of the upgrade process.  
> > 
> > If setup is broken to the point when several version within single
> > slot are installed (or are reported to be installed), then:
> > 
> > 1) There is no way to tell which version is valid and all of them
> > may be invalid. That's why REPLACING_VERSIONS is of no use at all
> > in such situation.
> > 
> > 2) System is severely broken and mistakenly shown (or not shown)
> > ewarn message will be the least problem for a user of such system.
> 
> Uh, nope. The PM can recover from that situation, so long as people
> don't go around writing broken ebuilds that make unwarranted
> assumptions that the spec specifically tells them not to make. Don't
> get into the habit of writing broken code.

Oh, nice: strictly follow PMS no matter what, right? Then let me
remind you that not so long time ago I advocated for strictly
following PMS [1,2], which _allows_ || ( A:= B:= ) construct [3].

But I was _enforced_ by QA to _violate_ PMS and remove the valid
syntax blocks [4]. This decision was made because of $reasons:
- we lack ||= operator;
- || ( := ) behaviour is not implemented properly in existing PM;
- "it doesn't make *any* sense";
- other valid and unquestionable $reasons ...

So the result is that common sense and practical considerations
take over PMS. And what we have in the REPLACING_VERSIONS case?
It doesn't matter that such situation never happened and will
likely never happen, but one must follow PMS strictly no matter
what. Such attitude is not fair at least.

> Or to put it another way: you are wrong, and you don't know enough
> about the situation to understand why you're wrong, and you clearly
> have no interest in learning, so just do as you're told.

I don't deny that I may be wrong on this matter, but I demand a
proof, an experimental one. And I see no such proof, only
theoretical considerations without any practical confirmation.

Do we ever had such case like multiple versions of the same
single-slotted package installed or recorded as installed in the
real world? I'm not sure even in this, but I may assume that it may
happen one day.

Do we have any proof that PM can recover from such situation,
where VDB is a mess and installed files can also be a mess? I'm not
sure in this at all.

Do we have any test suits for portage (as the most popular PM
implementation) for such cases? I doubt this, I can find none. I'm
not sure if such tests are implemented in other PM test suits too.

[1] https://archives.gentoo.org/gentoo-dev/message/abd0c82b058aa0109c12050ae837fba0
[2] https://bugs.gentoo.org/show_bug.cgi?id=586238#c1
[3] https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-780008.2
[4] https://bugs.gentoo.org/show_bug.cgi?id=586326

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] News Item: OpenAFS no longer needs kernel option DEBUG_RODATA

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1593 bytes --]

On Fri, 22 Jul 2016 15:49:55 +0200 Michał Górny wrote:
> On Fri, 22 Jul 2016 16:41:56 +0300
> Andrew Savchenko <bircoph@gentoo.org> wrote:
> 
> > On Fri, 22 Jul 2016 13:14:23 +0200 Michał Górny wrote:
> > > Dnia 22 lipca 2016 13:00:42 CEST, Andrew Savchenko <bircoph@gentoo.org> napisał(a):  
> > > >On Thu, 21 Jul 2016 07:12:12 +0200 Michał Górny wrote:  
> > [...]
> > > >> Few important QA notes:
> > > >> 
> > > >> 1. < is lexicographical comparison, so e.g. 1.6.2.2 < 1.6.18.2 gives
> > > >> false,  
> > > >
> > > >Thanks, fixed.
> > > >  
> > > >> 2. REPLACING_VERSIONS can have more than one value,  
> > > >
> > > >While it can indeed, I see no way for this to happen if package
> > > >hasn't and never had multiple slots.  
> > > 
> > > Wrong. PMS specifically requests you to account for such a possibility.  
> > 
> > Common sence must prevail over formal approaches. While PMS is
> > great, it is not perfect in all possible aspects, and this one is
> > one of them.
> > 
> > I see no point in trashing ebuilds with dead code that will never
> > be used. Though if there will be a PMS or eclass function with
> > "proper" implementation, I don't mind, since extra code will be
> > moved from ebuild elsewhere.
> 
> So are you officially refusing to follow the PMS based on your idea of
> 'common sense' and ignoring the specific reasons it was written like
> that? I should put my QA hat on, and request official action upon your
> refusal.
 
No, but I do ignore threats, at least for the time being.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] News Item: OpenAFS no longer needs kernel option DEBUG_RODATA

[Andreas K. Huettel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Am Freitag, 22. Juli 2016, 15:57:36 schrieb Ciaran McCreesh:

> > > Wrong. PMS specifically requests you to account for such a
> > > possibility.
> > 
> > Common sence must prevail over formal approaches. While PMS is
> > great, it is not perfect in all possible aspects, and this one is
> > one of them.

[snipping irrelevant blather]

> Slots are not the only way in which you can end up with multiple
> installed versions of the same package. Another way is if there's a
> fatal error during certain parts of the upgrade process.

1) If a package only ever had one slot, it cannot ever have two versions 
installed at the same time. That guarantee (of only ever one slot) can be 
given for the portage tree (sic). Obviously it doesn't work for overlays, 
but there are many things we don't care about for overlays. [A]

2) If a package manager leaves two versions of a non-slotted package 
"installed" somehow, that package manager is fundamentally broken and its 
author should forever refrain from specifying anything. It's not our job to 
work around Paludis failure modes. [B]


[A] Let's say there are overlays which package StarOffice, Go-OOO and some 
other random OOO fork. Do I have to block them all because of file collisions 
then?

[B] The package manager could be broken to leave some random files on the 
system too... maybe we need some more blockers or specific error handling in 
all ebuilds?



- -- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.1

iQJ8BAEBCgBmBQJXk+oFXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDMjhGQ0IwRjdCRUQxMzdBQUNCMDJEODlB
NDRDRjM3M0U3RUU5OUU0AAoJEKRM83Pn7pnkQwQQAM88pp4BmTT3CyrQ41QyAFOj
iPvhL2Qxv22Zp5hJB0lKatElsJkswDKGZiXbQvjvUqCaaywy9IbtjatNEnsLC7ku
CNgFNmbasAAp2E8LC/y10FiF2Uf/mWOr/b9D+22UrgiK82geXiRG1zpJR5pb9wDU
SyHX/GS308SSwgUoTYu8T8j7fAZy22632ve82LXOsvdCfLxQp6HwGKiDrVeKFg+b
xc9OFW7NKWZwzMCb0nKErNjaO9SuH+ZDK9jB3oERjMNRiihiI6VEmLSnyIKNyEt0
R6xLWQXSYmekjLBYogK2p+pG8LxKj00utlfGePhWoF0RJ0Z/U38sb4S78zAXh9mW
Dc+nurOBqE0y7so9NZMUXwyqvZqja9eGh2uJwnu6yRxG1D1F/ZAIa6YDjeBCH9vX
wLAzxzvpeB2GxQD2HE8QFmMdq87h3PPBY8mFodi4R1me3wt3av+OEuGGlM1L0HyX
WQ2ScxpABCrlY66ThZDG5mgiflYQxcQREtbwgXQYFblP/PVsm0wSkidcqj96eab6
YXqSgl4nplHQpG17PgyxRU2b6++38asyXQ8oD6cbPkciHvJS9mrDRbGCFtlzOnm5
q8FbP+5TtJRGSrpVSCuQBGVTW23uvhpObhw+JoGKKPW9J/VhCNzGBhoOMrEvldOy
aB8qXiP0UYzCvsBBwqVj
=/Qrt
-----END PGP SIGNATURE-----

[gentoo-dev] Re: News Item: OpenAFS no longer needs kernel option DEBUG_RODATA

[Duncan]

Andrew Savchenko posted on Sun, 24 Jul 2016 00:30:39 +0300 as excerpted:

> Do we ever had such case like multiple versions of the same
> single-slotted package installed or recorded as installed in the real
> world? I'm not sure even in this, but I may assume that it may happen
> one day.
> 
> Do we have any proof that PM can recover from such situation,
> where VDB is a mess and installed files can also be a mess? I'm not sure
> in this at all.
> 
> Do we have any test suits for portage (as the most popular PM
> implementation) for such cases? I doubt this, I can find none. I'm not
> sure if such tests are implemented in other PM test suits too.

Think of how a package is upgraded (by portage, I don't know enough about 
the others to describe the process for them).  The package is built, then 
installed to a temporary location, then "qmerged" from the temporary 
location to the live filesystem, replacing the previous version's files 
and recording the new one in the installed-package database, then the old 
version is unmerged and its record removed from the installed-package 
database.

What happens if there's a crash in either the qmerge or old-version 
unmerge steps?

Right, now there's parts of two versions in the installed-package 
database, and who knows what files from each on the live filesystem.

I'm not a portage dev so won't comment on the test suite angle, but 
portage has been able to handle this with the user simply redoing the 
upgrade (whether from binpkg or full rebuild) for many years now (singe 
before I became a gentooer in 2004, I know as I had some faulty hardware 
at the time and regularly crashed during build and installs, which was 
likely before REPLACING_VERSIONS was a thing), and given the number of 
installations out there and the stress of parallel-building some packages 
while others are installing, the code to handle this is GOING to get 
regularly tested.

This needs to continue to work, thus the PMS rules, and ebuilds that are 
unprepared to deal with it aren't going to help.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] Re: News Item: OpenAFS no longer needs kernel option DEBUG_RODATA

[Duncan]

Andreas K. Huettel posted on Sun, 24 Jul 2016 00:04:53 +0200 as excerpted:

> 1) If a package only ever had one slot, it cannot ever have two versions
> installed at the same time. That guarantee (of only ever one slot) can
> be given for the portage tree (sic). Obviously it doesn't work for
> overlays,
> but there are many things we don't care about for overlays. [A]

This is incorrect.  It arguably /might/ be correct if systems were 
guaranteed never to crash in the qmerge or old-version unmerge phases, 
but... the package manager must be able to deal with and recover from 
such crashes, and portage has done so for well over a decade, at least.  

(When I became a gentooer in 2004 I had faulty hardware, and the system 
would regularly crash during merges, sometimes repeatedly.  When I 
rebooted, all I had to do was restart the merge, and portage could pick 
up the pieces and deal with it, even back then.)

> 2) If a package manager leaves two versions of a non-slotted package
> "installed" somehow, that package manager is fundamentally broken and
> its author should forever refrain from specifying anything. It's not our
> job to work around Paludis failure modes. [B]

Not if it's the hardware that's broken, not the PM.  A good PM must be 
able to recover from the crash, and sort things out from it on a second, 
or third or tenth, attempt to actually get the upgrade done, this time 
/without/ crashing part way thru.

And broken ebuilds that can't deal with the situation don't help matters 
at all. =:^(

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] News Item: OpenAFS no longer needs kernel option DEBUG_RODATA

[Ciaran McCreesh]

On Sun, 24 Jul 2016 00:30:39 +0300
Andrew Savchenko <bircoph@gentoo.org> wrote:
> Oh, nice: strictly follow PMS no matter what, right? Then let me
> remind you that not so long time ago I advocated for strictly
> following PMS [1,2], which _allows_ || ( A:= B:= ) construct [3].
> 
> But I was _enforced_ by QA to _violate_ PMS and remove the valid
> syntax blocks [4]. This decision was made because of $reasons:
> - we lack ||= operator;
> - || ( := ) behaviour is not implemented properly in existing PM;
> - "it doesn't make *any* sense";
> - other valid and unquestionable $reasons ...
> 
> So the result is that common sense and practical considerations
> take over PMS. And what we have in the REPLACING_VERSIONS case?
> It doesn't matter that such situation never happened and will
> likely never happen, but one must follow PMS strictly no matter
> what. Such attitude is not fair at least.

No. You have simply failed to understand the reason || ( A:= B:= )
doesn't work. It may superficially appear correct, but you either need
to think carefully about the implications, or just accept wisdom from
people who have. I remind you that PMS does not explicitly prohibit a
dependency upon =A-1 =A-2 where A is not slotted, either: it's a
nonsense dependency, but syntactically valid.

Please stop trying to use your common sense in areas where you lack the
intuition and experience to have accurate common sense.

> Do we ever had such case like multiple versions of the same
> single-slotted package installed or recorded as installed in the
> real world? I'm not sure even in this, but I may assume that it may
> happen one day.

Yes, this happens with failures on uninstalls and upgrades.

> Do we have any proof that PM can recover from such situation,
> where VDB is a mess and installed files can also be a mess? I'm not
> sure in this at all.

Yes, things have been designed quite carefully to allow this to happen.
You recover by installing a new version, and using it to replace the
two installed versions simultaneously.

> Do we have any test suits for portage (as the most popular PM
> implementation) for such cases? I doubt this, I can find none. I'm
> not sure if such tests are implemented in other PM test suits too.

Portage doesn't exactly have many tests...

-- 
Ciaran McCreesh

Re: [gentoo-dev] News Item: OpenAFS no longer needs kernel option DEBUG_RODATA

[Ciaran McCreesh]

On Sun, 24 Jul 2016 00:04:53 +0200
"Andreas K. Huettel" <dilfridge@gentoo.org> wrote:
> 1) If a package only ever had one slot, it cannot ever have two
> versions installed at the same time. That guarantee (of only ever one
> slot) can be given for the portage tree (sic). Obviously it doesn't
> work for overlays, but there are many things we don't care about for
> overlays. [A]

Outright wrong, as has already been explained in this thread several
times.

> 2) If a package manager leaves two versions of a non-slotted package 
> "installed" somehow, that package manager is fundamentally broken and
> its author should forever refrain from specifying anything. It's not
> our job to work around Paludis failure modes. [B]

This is not a Paludis issue. It happens with Portage too. The install
sequence is carefully designed to install the new version of the
package, and then remove the old one (and if you think about it for a
few seconds, you can see that it *has* to be this way). If an error or
ctrl+c occurs at the wrong point, both versions remain installed, and
importantly, there is a safe way to recover from this.

-- 
Ciaran McCreesh

Re: [gentoo-dev] News Item: OpenAFS no longer needs kernel option DEBUG_RODATA

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2304 bytes --]

On Sun, 24 Jul 2016 00:04:53 +0200
"Andreas K. Huettel" <dilfridge@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> Am Freitag, 22. Juli 2016, 15:57:36 schrieb Ciaran McCreesh:
> 
> > > > Wrong. PMS specifically requests you to account for such a
> > > > possibility.  
> > > 
> > > Common sence must prevail over formal approaches. While PMS is
> > > great, it is not perfect in all possible aspects, and this one is
> > > one of them.  
> 
> [snipping irrelevant blather]
> 
> > Slots are not the only way in which you can end up with multiple
> > installed versions of the same package. Another way is if there's a
> > fatal error during certain parts of the upgrade process.  
> 
> 1) If a package only ever had one slot, it cannot ever have two versions 
> installed at the same time. That guarantee (of only ever one slot) can be 
> given for the portage tree (sic). Obviously it doesn't work for overlays, 
> but there are many things we don't care about for overlays. [A]
> 
> 2) If a package manager leaves two versions of a non-slotted package 
> "installed" somehow, that package manager is fundamentally broken and its 
> author should forever refrain from specifying anything. It's not our job to 
> work around Paludis failure modes. [B]
> 
> 
> [A] Let's say there are overlays which package StarOffice, Go-OOO and some 
> other random OOO fork. Do I have to block them all because of file collisions 
> then?
> 
> [B] The package manager could be broken to leave some random files on the 
> system too... maybe we need some more blockers or specific error handling in 
> all ebuilds?

So, to summarize: we should dump PMS and get back to caring only what
Portage seems to do for a few developers with big mouths, because
adding a single 'for' loop is so complex you can't handle it?

Instead you prefer wasting hours of time of others to discuss ignoring
the specification rather than doing things properly. If you don't like
PMS, start the procedure for changing it. Or dump it altogether. But
stop this nonsense of 'we use this spec that was written specifically
for us but random developers can ignore random points because they
can'.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] Re: News Item: OpenAFS no longer needs kernel option DEBUG_RODATA

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 2917 bytes --]

Hi,

On Sun, 24 Jul 2016 03:00:40 +0000 (UTC) Duncan wrote:
> Andrew Savchenko posted on Sun, 24 Jul 2016 00:30:39 +0300 as excerpted:
> 
> > Do we ever had such case like multiple versions of the same
> > single-slotted package installed or recorded as installed in the real
> > world? I'm not sure even in this, but I may assume that it may happen
> > one day.
> > 
> > Do we have any proof that PM can recover from such situation,
> > where VDB is a mess and installed files can also be a mess? I'm not sure
> > in this at all.
> > 
> > Do we have any test suits for portage (as the most popular PM
> > implementation) for such cases? I doubt this, I can find none. I'm not
> > sure if such tests are implemented in other PM test suits too.
> 
> Think of how a package is upgraded (by portage, I don't know enough about 
> the others to describe the process for them).  The package is built, then 
> installed to a temporary location, then "qmerged" from the temporary 
> location to the live filesystem, replacing the previous version's files 
> and recording the new one in the installed-package database, then the old 
> version is unmerged and its record removed from the installed-package 
> database.
> 
> What happens if there's a crash in either the qmerge or old-version 
> unmerge steps?
> 
> Right, now there's parts of two versions in the installed-package 
> database, and who knows what files from each on the live filesystem.
> 
> I'm not a portage dev so won't comment on the test suite angle, but 
> portage has been able to handle this with the user simply redoing the 
> upgrade (whether from binpkg or full rebuild) for many years now (singe 
> before I became a gentooer in 2004, I know as I had some faulty hardware 
> at the time and regularly crashed during build and installs, which was 
> likely before REPLACING_VERSIONS was a thing), and given the number of 
> installations out there and the stress of parallel-building some packages 
> while others are installing, the code to handle this is GOING to get 
> regularly tested.

I agree with you, but REPLACING_VERSIONS has nothing to do with
such recovery.

1) It appeared only in EAPI 4, approved on 2011-01-17. Recovery
from hardware crashes forked well long before.

2) If you will look into the tree, in the absolute majority of cases
REPLACING_VERSIONS is being used to determine whether informational
messages should be shown to a user or not. Such messages usually
include some upgrade hints or howtos; and REPLACING_VERSIONS check
is required to avoid showing them to unaffected users. It has
absolutely nothing to do with the error recovery done by PM itself.

3) I also had a broken hardware (faulty memory) for a few years and
portage and other software recovered quite fine despite numerous
segfaults. So I have the experience :)

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] Re: News Item: OpenAFS no longer needs kernel option DEBUG_RODATA

[Ciaran McCreesh]

On Sun, 24 Jul 2016 10:05:23 +0300
Andrew Savchenko <bircoph@gentoo.org> wrote:
> I agree with you, but REPLACING_VERSIONS has nothing to do with
> such recovery.

Yes, it does. Specifically, what we want is for developers to get into
the habit of writing safe, clean code, even if they think they don't
need to care about it in some particular situation because they can't
think of how it would go wrong. It's the same as getting into the habit
of sticking || die on things.

> 1) It appeared only in EAPI 4, approved on 2011-01-17. Recovery
> from hardware crashes forked well long before.

Before this, you could use has_version in pkg_*, and it would tell you
the *old* version of the package that was installed. The phase order
changed a while ago, and broke this, so REPLACING_VERSIONS was the
replacement.

Again, the situation is complicated, there's a lot of messy history
behind this, and if you don't know it all, just do what the spec says
and stop wasting everyone's time by arguing.

> 2) If you will look into the tree, in the absolute majority of cases
> REPLACING_VERSIONS is being used to determine whether informational
> messages should be shown to a user or not. Such messages usually
> include some upgrade hints or howtos; and REPLACING_VERSIONS check
> is required to avoid showing them to unaffected users. It has
> absolutely nothing to do with the error recovery done by PM itself.

Don't get into the habit of writing code that makes unnecessary
assumptions that will come back and screw users over in unexpected
situations. It's easy to do this the right way, so at this point I can
only conclude that you're persisting in trying to do it wrong just to
avoid admitting that you made a mistake from ignorance. It's OK to be
wrong sometimes (and this is why code review exists), but it's not OK
to continue to argue that you were right out of stubbornness.

-- 
Ciaran McCreesh

[gentoo-dev] Re: News Item: OpenAFS no longer needs kernel option DEBUG_RODATA

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1686 bytes --]

Hi,

On Wed, 20 Jul 2016 13:13:49 -0400 NP-Hardass wrote:
> This is the first draft of a news item describing a packaging change for
> OpenAFS so that we no longer require the DEBUG_RODATA be turned off.

This is a second try with rewording of the first paragraph, since
it was suggested that it is a bit awkward.

Title: OpenAFS no longer needs kernel option DEBUG_RODATA
Author: NP-Hardass <NP-Hardass@gentoo.org>
Author: Andrew Savchenko <bircoph@gentoo.org>
Content-Type: text/plain
Posted: 2016-07-23
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: <=net-fs/openafs-kernel-1.6.18.2
Display-If-Keyword: amd64
Display-If-Keyword: ~amd64-linux
Display-If-Keyword: ~sparc
Display-If-Keyword: x86
Display-If-Keyword: ~x86-linux

As a result of bug #127084 [1], it was determined that OpenAFS's
kernel module required that the kernel's data structures be
read-write (CONFIG_DEBUG_RODATA=n). With recent OpenAFS versions
this limitation is no longer required. We tested the latest version
of OpenAFS with Linux kernels from 3.4 till 4.6, and determined that
OpenAFS kernel module works fine with CONFIG_DEBUG_RODATA=y.

Starting with net-fs/openafs-kernel-1.6.18.2, this condition is no
longer forced in the ebuild. Considering the security implications
of having CONFIG_DEBUG_RODATA turned off, it is highly advised that
you adjust your kernel config accordingly.  Please note that the
default setting for CONFIG_DEBUG_RODATA is "y" and unless you have
another reason for keeping it disabled, we highly recommend that
you re-enable CONFIG_DEBUG_RODATA.

[1] https://bugs.gentoo.org/show_bug.cgi?id=127084

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[gentoo-dev] Re: News Item: OpenAFS no longer needs kernel option DEBUG_RODATA

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1863 bytes --]

On Mon, 1 Aug 2016 14:08:57 +0300 Andrew Savchenko wrote:
> Hi,
> 
> On Wed, 20 Jul 2016 13:13:49 -0400 NP-Hardass wrote:
> > This is the first draft of a news item describing a packaging change for
> > OpenAFS so that we no longer require the DEBUG_RODATA be turned off.
> 
> This is a second try with rewording of the first paragraph, since
> it was suggested that it is a bit awkward.
> 
> Title: OpenAFS no longer needs kernel option DEBUG_RODATA
> Author: NP-Hardass <NP-Hardass@gentoo.org>
> Author: Andrew Savchenko <bircoph@gentoo.org>
> Content-Type: text/plain
> Posted: 2016-07-23
> Revision: 1
> News-Item-Format: 1.0
> Display-If-Installed: <=net-fs/openafs-kernel-1.6.18.2
> Display-If-Keyword: amd64
> Display-If-Keyword: ~amd64-linux
> Display-If-Keyword: ~sparc
> Display-If-Keyword: x86
> Display-If-Keyword: ~x86-linux
> 
> As a result of bug #127084 [1], it was determined that OpenAFS's
> kernel module required that the kernel's data structures be
> read-write (CONFIG_DEBUG_RODATA=n). With recent OpenAFS versions
> this limitation is no longer required. We tested the latest version
> of OpenAFS with Linux kernels from 3.4 till 4.6, and determined that
> OpenAFS kernel module works fine with CONFIG_DEBUG_RODATA=y.
> 
> Starting with net-fs/openafs-kernel-1.6.18.2, this condition is no
> longer forced in the ebuild. Considering the security implications
> of having CONFIG_DEBUG_RODATA turned off, it is highly advised that
> you adjust your kernel config accordingly.  Please note that the
> default setting for CONFIG_DEBUG_RODATA is "y" and unless you have
> another reason for keeping it disabled, we highly recommend that
> you re-enable CONFIG_DEBUG_RODATA.
> 
> [1] https://bugs.gentoo.org/show_bug.cgi?id=127084

No comments for a week => submitted.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]