Re: [gentoo-dev] Re: Revisions for USE flag changes

[Michael Orlitzky]

On 08/14/2017 08:01 AM, Jason Zaman wrote:
> 
> I'll give an example where revbumps are significantly inferior to 
> --changed-use.
> 
> ...  With --changed-use, only the people who need it (ie selinux
> users) will rebuild and everyone is happy (selinux users because the
> program now works and non-selinux users because they did not rebuild
> for no reason).

But this benefit exists only for Portage users, and can only be obtained
by throwing the others under the bus.

(If you change RDEPEND, you need to create a new revision anyway:
https://projects.gentoo.org/council/meeting-logs/20151011-summary.txt)

Re: [gentoo-dev] Packages up for grabs: app-forensics/* and other forensics@g.o packages

[Gokturk Yuksek]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

Michał Górny:
> Hi,
> 
> Due to the Forensics project [1] being disbanded, the following
> packages are now up for grabs. Please note that some of the
> packages will probably be taken by former project members.
> 
> app-admin/integrit app-forensics/afflib [o] app-forensics/air 
> app-forensics/autopsy app-forensics/chkrootkit [o] 
> app-forensics/cmospwd app-forensics/examiner app-forensics/galleta 
> app-forensics/libewf [o] app-forensics/lynis 
> app-forensics/mac-robber app-forensics/magicrescue 
> app-forensics/memdump app-forensics/pasco app-forensics/rifiuti
> [o] app-forensics/rkhunter app-forensics/scalpel [o] 
> app-forensics/sleuthkit [o]

I'm taking this one. It's actually active with a new version released
8 days ago.

> net-mail/libpst [o] sys-apps/dcfldd sys-block/disktype
> 
> The 6 packages marked [o] are outdated according to repology. Most
> of the packages also have bugs open.
> 
> [1]:https://bugs.gentoo.org/626500
> 

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEv2SYNjDGGh+3Be4QhPgC5cCIzjMFAlmTtokACgkQhPgC5cCI
zjP3GwgAvqgYeUc0UEvOvcQS9FM5CSUQt7qQl9GuQd1Wr3uLVO9SAn0ZbjFDfGWY
DVMag2X2yzM3ZDoa75yC5LQFLJc5PrQt7qmXck2G/gWLhloqWGnFLrjqDfBobDp0
4cSBt3yH/Z++y5HVx/n7J8yY8qopheqKUnPIPeSfdnnVeV/+iYiCqzkcB+hfaWQd
M3SclMXfh148OkBYHN5wvJXYHZFYaLxPR/19Qq7/mq6x/v2L69Z66JtxfrNkB5AF
Fyddhf3Os9293NKXd/ig5IwTLuQ7jsfQ+Uc5laIQ4lfO1FmszWBGqf4sEhlJ/dTC
9IB/SPTa3oalQrOOper3/OFmrw7Igg==
=+Pel
-END PGP SIGNATURE-

[gentoo-dev] Re: [FRC] News item: Changing USE flags for >=app-backup/bacula

[Duncan]

tomjbe posted on Tue, 15 Aug 2017 19:49:33 +0200 as excerpted:

>  think we can find a proper formulation for the use flag description in
> metadata.xml, e.g.:
> 
> director - Installs the backup director additional to the default file
> daemon.
> storage-daemon - Installs the storage daemon additional to the default
> file daemon

FWIW, "additional to" is understandable, but AFAIK nonstandard (sounds 
like ESL/English-as-a-second-language, using grammar from the first).

The phrase "in addition to" works much better to my eye/ear.

Or just use "plus", if "in addition to" makes it too long...

-- 
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] [FRC] News item: Changing USE flags for >=app-backup/bacula

[M. J. Everitt]

On 15/08/17 18:49, tom...@gentoo.org wrote:
> I think we can find a proper formulation for the use flag description in
> metadata.xml, e.g.:
>
> director - Installs the backup director additional to the default file daemon.
> storage-daemon - Installs the storage daemon additional to the default file
> daemon.
>
> Thomas
>
>
s/additional to the default file daemon.//

MJE



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] New item for sys-kernel/hardened-sources removal

[Francisco Blas Izquierdo Riera (klondike)]

El 15/08/17 a las 18:08, Ulrich Mueller escribió:
>> On Tue, 15 Aug 2017, Francisco Blas Izquierdo Riera (klondike) wrote:
>> Updated the news item following comments from dilfridge, mrueg and
>> floppym. Also made it display to users of hardened profiles.
> Some very minor comments:
>
>> Author: Francisco Blas Izquierdo Riera (klondike) 
> Format of the line is "Real Name ", so I'd suggest to
> drop the nick in parentheses, especially since it is there in the
> e-mail address anyway.
>
>> Because of that we will be masking the hardened-sources on the 27th of
>> August and will proceed to remove then from the tree by the end of
>> September. [...]
> s/then/them/
>
>> As an alternative, for users happy keeping themselves on the  stable
>> 4.9 branch of the kernel minipli, another Grsec user, is forward
>> porting the patches on [3].
> I had difficulties parsing this sentence. Insert a comma after
> "kernel"? Also there is spurious whitespace before "stable".
>
> Ulrich

Thanks for your input, I have addressed your comments on the attached
news item.

I have also added a note regarding the other PaX related packages as
these won't stil be removed.


Klondike

Title: sys-kernel/hardened-sources removal
Author: Francisco Blas Izquierdo Riera 
Posted: 2017-08-19
Revision: 3
News-Item-Format: 2.0
Display-If-Installed: sys-kernel/hardened-sources
Display-If-Profile: hardened/linux/*

As you may know the core of sys-kernel/hardened-sources have been the
patches published by Grsec.

Sadly, their developers have stopped making these patches freely
available [1]. This is a full stop of any public updates and not only
stable ones as was announced two years ago[2].

As a result, the Gentoo Hardened team is unable to keep providing
further updates of the patches, and although the hardened-sources have
proved (when using a hardened toolchain) being resistant against
certain attacks like the stack guard page jump techniques proposed by
Stack Clash, we can't ensure a regular patching schedule and therefore,
the security of the users of these kernel sources.

Because of that we will be masking the hardened-sources on the 27th of
August and will proceed to remove them from the tree by the end of
September. Obviously, we will reinstate the package again if the
developers decide to make their patches publicly available again.

Our recommendation is that users should consider using instead
sys-kernel/gentoo-sources.

As an alternative, for users happy keeping themselves on the stable
4.9 branch of the kernel; minipli, another Grsec user, is forward
porting the patches on [3].

Strcat from Copperhead OS is making his own version of the patches
forward ported to the latest version of the Linux tree at [4].

The Gentoo Hardened team can't make any statement regarding the
security, reliability or update availability of either those patches
as we aren't providing them and can't therefore make any
recommendation regarding their use.

We'd like to note that all the userspace hardening and MAC support
for SELinux provided by Gentoo Hardened will still remain there and
is unaffected by this removal. Also, all PaX related packages other
than the hardened-sources will remain for the time being.

[1] https://grsecurity.net/passing_the_baton.php
[2] https://www.gentoo.org/support/news-items/2015-10-21-future-support-of-
hardened-sources-kernel.html
[3] https://github.com/minipli/linux-unofficial_grsec
[4] https://github.com/copperhead/linux-hardened

signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] New item for sys-kernel/hardened-sources removal

[Francisco Blas Izquierdo Riera (klondike)]

El 15/08/17 a las 17:50, R0b0t1 escribió:
> Where was this decision discussed?
https://archives.gentoo.org/gentoo-hardened/message/62ebc2e26d91e8f079197c2c83788cff

And many other threads in that list for example, those are just blueness
(the package maintainer) conclussions.
> The last available kernel is
> apparently receiving long term support, there may not be any reason to
> remove it.
Not by the original upstream, and definitively not in the way in which
Grsec used to (manually cherrypicking security related commits and not
just those marked as security related).

Although minipli's kernel patches are good and I personally recommend
them, this is not something the Gentoo Hardened team will do. Also they
probably should be renamed something else.
> If it isn't broken and creating work yet I'm not sure why
> anyone cares.

Go to #gentoo-hardened and see how there is people asking about this
again and again :P




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [FRC] News item: Changing USE flags for >=app-backup/bacula

[tomjbe]

Quoting Rich Freeman (2017-08-15 14:16:14)
> On Tue, Aug 15, 2017 at 5:19 AM,   wrote:
> > Quoting Michał Górny (2017-08-15 08:43:07)
> >> On wto, 2017-08-15 at 06:55 +0200, tom...@gentoo.org wrote:
> >> > Quoting Rich Freeman (2017-08-15 00:29:19)
> >> > >
> >> > > I guess to make it a bit more explicit, would it make sense to have 3 
> >> > > flags:
> >> > >
> >> > > client - install the client   (or consider calling it file-daemon 
> >> > > instead)
> >> > > director - install the director
> >> > > storage-daemon - install the storage daemon
> >> > >
> >> >
> >> > That would be best, but it is not supported by their (autoconf based) 
> >> > build
> >> > system (and would require a complete rewrite of it). The actual USE flags
> >> > mostly mirrors the switches from the configure script. You can not set 
> >> > them as
> >> > you like, they are not orthogonal E.g. the file deamon (client) will be
> >> > installed unconditionally.
> >> >
> >> > The configure script itself is very brittle atm and needs an urgent 
> >> > overhaul.
> >> > Discussion with upstream goes a long way, but they do not want to change 
> >> > it
> >> > because of the need to retest it on very different systems. No good 
> >> > situation.
> >> >
> >> > A possible idea may be to drop the 'no/client' flag completely. If 
> >> > neither
> >> > 'director' nor 'storage-daemon' is active all that is left would be the
> >> > file daemon.
> >> > What do you think?
> >>
> >> WFM. If the flag doesn't do anything except for disabling the two other
> >> flags, then there's no place for such a flag.
> >>
> > And here comes the problem. USE="bacula-nodir bacula-nosd" does not produce
> > the same set of files as USE="bacula-clientonly". But I will recheck if the
> > difference is of relevance for normal gentoo user.
> 
> It is probably worth understanding the difference.  However, if the
> user sets both -director and -storage-daemon you could also enable
> bacula-clientonly, unless there is some reason somebody might want two
> of those and not the third.
> 
I just tested the different use flags settings as well as directly the
different configure switches. Here is what happens for configure:

* Deactivation of storage-daemon drops the related files.
* Deactivation of director ist ignored by the build system, the director is
  build anyway (One more bug in their build system).
* Activation of clientonly drops both the related files for director and for
  storage daemon.

The ebuild does fix some of the differences:

* +bacula-nodir and +bacula+nosd drops most of the files for these
  functionality, but keeps some more (mostly irrelevant) files over
  +bacula-clientonly.

So from gentoos point of view having nodir and nosd is nearly the same as
having clientonly. That would allow to drop the clientonly flag and keep only
the controling flags for director and storage-daemon.
> >
> >> >
> >> > The downside of that idea is that we diverge from baculas documentation 
> >> > which
> >> > explicitly state that there is a 'clientonly' install.
> >> >
> >>
> >> Upstream install documentation is not relevant to Gentoo. The flag
> >> descriptions in metadata.xml are.
> >>
> > Right. But if we drop a "clientonly" than there is no hint in metadata.xml 
> > how
> > to get only the file daemon alone. Some einfo output or similar come to 
> > mind.
> >
> 
> You could use einfo.  However, if the docs say what the other two
> flags do then it seems pretty obvious that if you turn them both off
> you end up with only the file daemon.
> 
I think we can find a proper formulation for the use flag description in
metadata.xml, e.g.:

director - Installs the backup director additional to the default file daemon.
storage-daemon - Installs the storage daemon additional to the default file
daemon.

Thomas

Re: [gentoo-dev] New item for sys-kernel/hardened-sources removal

[Ulrich Mueller]

> On Tue, 15 Aug 2017, Francisco Blas Izquierdo Riera (klondike) wrote:

> Updated the news item following comments from dilfridge, mrueg and
> floppym. Also made it display to users of hardened profiles.

Some very minor comments:

> Author: Francisco Blas Izquierdo Riera (klondike) 

Format of the line is "Real Name ", so I'd suggest to
drop the nick in parentheses, especially since it is there in the
e-mail address anyway.

> Because of that we will be masking the hardened-sources on the 27th of
> August and will proceed to remove then from the tree by the end of
> September. [...]

s/then/them/

> As an alternative, for users happy keeping themselves on the  stable
> 4.9 branch of the kernel minipli, another Grsec user, is forward
> porting the patches on [3].

I had difficulties parsing this sentence. Insert a comma after
"kernel"? Also there is spurious whitespace before "stable".

Ulrich


pgpAXxhALC0OE.pgp
Description: PGP signature

Re: [gentoo-dev] New item for sys-kernel/hardened-sources removal

[R0b0t1]

On Tue, Aug 15, 2017 at 10:01 AM, Francisco Blas Izquierdo Riera
(klondike)  wrote:
> Hi!
>
> I'd like to get this one up by Saturday so that we can proceed with
> masking and removing of the hardened-sources after upstream stopped
> releasing new patches.

Where was this decision discussed? The last available kernel is
apparently receiving long term support, there may not be any reason to
remove it. If it isn't broken and creating work yet I'm not sure why
anyone cares.

Re: [gentoo-dev] New item for sys-kernel/hardened-sources removal

[Francisco Blas Izquierdo Riera (klondike)]

El 15/08/17 a las 17:01, Francisco Blas Izquierdo Riera (klondike) escribió:
> Hi!
>
> I'd like to get this one up by Saturday so that we can proceed with
> masking and removing of the hardened-sources after upstream stopped
> releasing new patches.
>
> This is my first time writting a news item so all input will be appreciated.
>
> As for the rationale behind this, we need to clearly inform users as to
> the options available for hardening their system kernels after the
> removal of the hardened-sources.
>
> Sincerely,
> Klondike
>
Updated the news item following comments from dilfridge, mrueg and
floppym. Also made it display to users of hardened profiles.

Title: sys-kernel/hardened-sources removal
Author: Francisco Blas Izquierdo Riera (klondike) 
Posted: 2017-08-19
Revision: 2
News-Item-Format: 2.0
Display-If-Installed: sys-kernel/hardened-sources
Display-If-Profile: hardened/linux/*

As you may know the core of sys-kernel/hardened-sources have been the
patches published by Grsec.

Sadly, their developers have stopped making these patches freely
available [1]. This is a full stop of any public updates and not only
stable ones as was announced two years ago[2].

As a result, the Gentoo Hardened team is unable to keep providing
further updates of the patches, and although the hardened-sources have
proved (when using a hardened toolchain) being resistant against
certain attacks like the stack guard page jump techniques proposed by
Stack Clash, we can't ensure a regular patching schedule and therefore,
the security of the users of these kernel sources.

Because of that we will be masking the hardened-sources on the 27th of
August and will proceed to remove then from the tree by the end of
September. Obviously, we will reinstate the package again if the
developers decide to make their patches publicly available again.

Our recommendation is that users should consider using instead
sys-kernel/gentoo-sources.

As an alternative, for users happy keeping themselves on the  stable
4.9 branch of the kernel minipli, another Grsec user, is forward
porting the patches on [3].

Strcat from Copperhead OS is making his own version of the patches
forward ported to the latest version of the Linux tree at [4].

The Gentoo Hardened team can't make any statement regarding the
security, reliability or update availability of either those patches
as we aren't providing them and can't therefore make any
recommendation regarding their use.

We'd like to note that all the userspace hardening and MAC support
for SELinux provided by Gentoo Hardened will still remain there and
is unaffected by this removal.

[1] https://grsecurity.net/passing_the_baton.php
[2] https://www.gentoo.org/support/news-items/2015-10-21-future-support-of-
hardened-sources-kernel.html
[3] https://github.com/minipli/linux-unofficial_grsec
[4] https://github.com/copperhead/linux-hardened

signature.asc
Description: OpenPGP digital signature

[gentoo-dev] New item for sys-kernel/hardened-sources removal

[Francisco Blas Izquierdo Riera (klondike)]

Hi!

I'd like to get this one up by Saturday so that we can proceed with
masking and removing of the hardened-sources after upstream stopped
releasing new patches.

This is my first time writting a news item so all input will be appreciated.

As for the rationale behind this, we need to clearly inform users as to
the options available for hardening their system kernels after the
removal of the hardened-sources.

Sincerely,
Klondike

Title: sys-kernel/hardened-sources removal
Author: Francisco Blas Izquierdo Riera (klondike) 
Posted: 2017-08-19
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: sys-kernel/hardened-sources

As you may know the core of sys-kernel/hardened-sources have been the
patches published by Grsec.

Sadly, their developers have stopped making these freely available [1].
As a result, the Gentoo Hardened team is unable to keep providing
further updates of the patches, and although the hardened-sources have
proved (when using a hardened toolchain) being resistant against
certain attacks like the stack guard page jump techniques proposed by
Stack Clash, we can't ensure a regular patching schedule and therefore,
the security of the users of these kernel sources.

Because of that we will be masking the hardened-sources on the 27th of
August and will proceed to remove then from the tree by the end of
September. Obviously, we will reinstate the package again if the
developers decide to make their patches publicly available again.

Our recommendation is that users should consider using instead
sys-kernel/gentoo-sources.

As an alternative, for users happy keeping themselves on the  stable
4.9 branch of the kernel minipli, another Grsec user, is forward
porting the patches on [2]. The Gentoo Hardened team can't make any
statement regarding the security, reliability or update availability
of those patches as we aren't providing them and can't therefore
make any recommendation regarding their use.

We'd like to note that all the userspace hardening and MAC support
for SELinux provided by Gentoo Hardened will still remain there and
is unaffected by this removal.

Finally we'd like to send a sincere thank you to Brad Spengler and
the PaX Team for making their hardening patches freely available all
this time.



[1] https://grsecurity.net/passing_the_baton.php
[2] https://github.com/minipli/linux-unofficial_grsec

signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [FRC] News item: Changing USE flags for >=app-backup/bacula

[Rich Freeman]

On Tue, Aug 15, 2017 at 6:25 AM, Kristian Fiskerstrand  wrote:
> On 08/15/2017 02:21 PM, Rich Freeman wrote:
>> For example, could you say that a client-only install that still
>> installs the X11 components is "minimal?"
>
> Its somewhat context dependent, for an X application this doesn't
> necessarily constitute additional dependencies for the system (think
> desktop profile), whereby an application that is primarily used on
> servers suddenly needing some graphics processing dragging it in is
> likely wrong.
>
> That said, the use flag description isn't more detailed than "minimal -
> Install a very minimal build (disables, for example, plugins, fonts,
> most drivers, non-critical features)", so I'd say it is appropriate
>

I'm not actually sure what you're advocating here.

My suggestion is to avoid minimal entirely, because for a package like
this it is just going to be confusing because there are so many
different optional features and disabling any of them could be
situational.  It is probably also worth nothing that minimal is itself
a negative flag.  I really question whether we ought to have it at
all.

If you're suggesting to use minimal for bacula, then what specifically
should it actually enable/disable in this particular case?

For reference, the current IUSE is:
IUSE="acl bacula-clientonly bacula-nodir bacula-nosd examples ipv6
libressl logwatch mysql postgres qt4 readline +sqlite ssl static tcpd
vim-syntax X"

There are a lot of features one might debate toggling with "minimal"
in that list.

-- 
Rich

Re: [gentoo-dev] [FRC] News item: Changing USE flags for >=app-backup/bacula

[Kristian Fiskerstrand]

On 08/15/2017 02:21 PM, Rich Freeman wrote:
> For example, could you say that a client-only install that still
> installs the X11 components is "minimal?"

Its somewhat context dependent, for an X application this doesn't
necessarily constitute additional dependencies for the system (think
desktop profile), whereby an application that is primarily used on
servers suddenly needing some graphics processing dragging it in is
likely wrong.

That said, the use flag description isn't more detailed than "minimal -
Install a very minimal build (disables, for example, plugins, fonts,
most drivers, non-critical features)", so I'd say it is appropriate


-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [FRC] News item: Changing USE flags for >=app-backup/bacula

[Rich Freeman]

On Tue, Aug 15, 2017 at 5:45 AM, Kristian Fiskerstrand  wrote:
> On 08/15/2017 11:33 AM, tom...@gentoo.org wrote:
>> Quoting Kristian Fiskerstrand (2017-08-15 10:37:39)
>>> On 08/15/2017 12:29 AM, Rich Freeman wrote:
 On Mon, Aug 14, 2017 at 5:55 PM, Michał Górny  wrote:
> On pon, 2017-08-14 at 21:58 +0200, Thomas Beierlein wrote:
>> * 'bacula-clientonly' becomes 'clientonly'
> This is still negative logic in disguise. clientonly = noserver.
>>>
>>> Can the "minimum"-use flag be utilized here?
>>>
>> Sounds reasonable and is worth thinking about. At least we could define the
>> meaning of "minimum" here in metadata.xml.
>>
>> But, looking through portage there seems to be no "minimum" use flag anymore.
>> Seems it got dropped for some reasons.
>>
>
> typo; "minimal"...

The meaning of the minimal flag varies considerably throughout the
tree.  It is common only because its meaning morphs from package to
package.

For example, could you say that a client-only install that still
installs the X11 components is "minimal?"

-- 
Rich

Re: [gentoo-dev] [FRC] News item: Changing USE flags for >=app-backup/bacula

[Rich Freeman]

On Tue, Aug 15, 2017 at 5:19 AM,   wrote:
> Quoting Michał Górny (2017-08-15 08:43:07)
>> On wto, 2017-08-15 at 06:55 +0200, tom...@gentoo.org wrote:
>> > Quoting Rich Freeman (2017-08-15 00:29:19)
>> > >
>> > > I guess to make it a bit more explicit, would it make sense to have 3 
>> > > flags:
>> > >
>> > > client - install the client   (or consider calling it file-daemon 
>> > > instead)
>> > > director - install the director
>> > > storage-daemon - install the storage daemon
>> > >
>> >
>> > That would be best, but it is not supported by their (autoconf based) build
>> > system (and would require a complete rewrite of it). The actual USE flags
>> > mostly mirrors the switches from the configure script. You can not set 
>> > them as
>> > you like, they are not orthogonal E.g. the file deamon (client) will be
>> > installed unconditionally.
>> >
>> > The configure script itself is very brittle atm and needs an urgent 
>> > overhaul.
>> > Discussion with upstream goes a long way, but they do not want to change it
>> > because of the need to retest it on very different systems. No good 
>> > situation.
>> >
>> > A possible idea may be to drop the 'no/client' flag completely. If neither
>> > 'director' nor 'storage-daemon' is active all that is left would be the
>> > file daemon.
>> > What do you think?
>>
>> WFM. If the flag doesn't do anything except for disabling the two other
>> flags, then there's no place for such a flag.
>>
> And here comes the problem. USE="bacula-nodir bacula-nosd" does not produce
> the same set of files as USE="bacula-clientonly". But I will recheck if the
> difference is of relevance for normal gentoo user.

It is probably worth understanding the difference.  However, if the
user sets both -director and -storage-daemon you could also enable
bacula-clientonly, unless there is some reason somebody might want two
of those and not the third.

>
>> >
>> > The downside of that idea is that we diverge from baculas documentation 
>> > which
>> > explicitly state that there is a 'clientonly' install.
>> >
>>
>> Upstream install documentation is not relevant to Gentoo. The flag
>> descriptions in metadata.xml are.
>>
> Right. But if we drop a "clientonly" than there is no hint in metadata.xml how
> to get only the file daemon alone. Some einfo output or similar come to mind.
>

You could use einfo.  However, if the docs say what the other two
flags do then it seems pretty obvious that if you turn them both off
you end up with only the file daemon.

-- 
Rich

[gentoo-portage-dev] [PATCH 2/2] Add post-postinst checks for a few missed cache updates

[Michał Górny]

Add postinst-qa-check.d checks for missed desktop, mime-info and GTK+
icon cache updates. In all of the cases the checks simply look for any
installed files that are newer than the cache.

This check has some limitations: it assumes that mtime is not preserved
when copying files to D, it can't distinguish whether the files
were installed by the current package (it reports all new files since
the last cache update) and it can't distinguish between the update
on postinst and postrm. However, it's certainly a step forward and will
help find a few bugs.
---
 bin/postinst-qa-check.d/50gnome2-utils | 38 
 bin/postinst-qa-check.d/50xdg-utils| 65 ++
 2 files changed, 103 insertions(+)
 create mode 100644 bin/postinst-qa-check.d/50gnome2-utils
 create mode 100644 bin/postinst-qa-check.d/50xdg-utils

diff --git a/bin/postinst-qa-check.d/50gnome2-utils 
b/bin/postinst-qa-check.d/50gnome2-utils
new file mode 100644
index 0..68e21cb74
--- /dev/null
+++ b/bin/postinst-qa-check.d/50gnome2-utils
@@ -0,0 +1,38 @@
+# check for missing calls to gnome2-utils regen functions
+
+gnome2_icon_cache_check() {
+   local d f files=() find_args
+   for d in usr/share/icons/*/; do
+   # gnome2_icon_cache_update updates only themes with an index
+   [[ -f ${d}/index.theme ]] || continue
+
+   find_args=()
+   # if the cache does not exist at all, we complain for any file
+   # otherwise, we look for files newer than the cache
+   [[ -f ${d}/icon-theme.cache ]] &&
+   find_args+=( -newer "${d}"/icon-theme.cache )
+
+   # (use -mindepth 2 to easily skip the cache files)
+   while read -r -d $'\0' f; do
+   files+=( "${f}" )
+   done < <(find "${d}" -mindepth 2 -type f "${find_args[@]}" 
-print0)
+   done
+
+   if [[ ${files[@]} ]]; then
+   eqawarn "QA Notice: new icons were found installed but GTK+ 
icon cache"
+   eqawarn "has not been updated:"
+   eqatag -v gnome2-utils.icon-cache "${files[@]/#//}"
+   eqawarn "Please make sure to call gnome2_icon_cache_update()"
+   eqawarn "in pkg_postinst() and pkg_postrm() phases of 
appropriate pkgs."
+   fi
+}
+
+gnome2_utils_postinst_check() {
+   cd "${EROOT}" || die
+   gnome2_icon_cache_check
+}
+
+gnome2_utils_postinst_check
+: # guarantee successful exit
+
+# vim:ft=sh
diff --git a/bin/postinst-qa-check.d/50xdg-utils 
b/bin/postinst-qa-check.d/50xdg-utils
new file mode 100644
index 0..4bc7bee9a
--- /dev/null
+++ b/bin/postinst-qa-check.d/50xdg-utils
@@ -0,0 +1,65 @@
+# check for missing calls to xdg-utils regen functions
+
+xdg_desktop_database_check() {
+   local d f files=()
+   for d in usr/share/applications; do
+   [[ -d ${d} ]] || continue
+
+   find_args=()
+   # if the cache does not exist at all, we complain for any file
+   # otherwise, we look for files newer than the cache
+   [[ -f ${d}/mimeinfo.cache ]] &&
+   find_args+=( -newer "${d}"/mimeinfo.cache )
+
+   # look for any .desktop files that are newer than the cache
+   # and that have any mime types defined
+   while read -r -d $'\0' f; do
+   files+=( "${f}" )
+   done < <(find "${d}" -name '*.desktop' "${find_args[@]}" \
+   -exec grep -lZi '^MimeType=' {} +)
+   done
+
+   if [[ ${files[@]} ]]; then
+   eqawarn "QA Notice: .desktop files with MimeType= were found 
installed"
+   eqawarn "but desktop mimeinfo cache has not been updated:"
+   eqatag -v xdg-utils.desktop "${files[@]/#//}"
+   eqawarn "Please make sure to call xdg_desktop_database_update()"
+   eqawarn "in pkg_postinst() and pkg_postrm() phases of 
appropriate pkgs."
+   fi
+}
+
+xdg_mimeinfo_database_check() {
+   local d f files=()
+   for d in usr/share/mime; do
+   [[ -d ${d} ]] || continue
+
+   find_args=()
+   # if the cache does not exist at all, we complain for any file
+   # otherwise, we look for files newer than the cache
+   [[ -f ${d}/mime.cache ]] &&
+   find_args+=( -newer "${d}"/mime.cache )
+
+   while read -r -d $'\0' f; do
+   files+=( "${f}" )
+   done < <(find "${d}" -name '*.xml' "${find_args[@]}" -print0)
+   done
+
+   if [[ ${files[@]} ]]; then
+   eqawarn "QA Notice: mime-info files were found installed but 
mime-info"
+   eqawarn "cache has not been updated:"
+   eqatag -v xdg-utils.mime-info "${files[@]/#//}"
+   eqawarn "Please make sure to call 
xdg_mimeinfo_database_update()"
+   

[gentoo-portage-dev] [PATCH 1/2] Support post-postinst QA checks

[Michał Górny]

Extend the QA check mechanics in Portage to support post-postinst QA
checks. They are like post-install QA checks, except they are run after
pkg_postinst(), and so they can be used to verify that necessary
postinst actions were performed (e.g. regenerating caches).
---
 bin/misc-functions.sh  | 57 ++
 pym/portage/package/ebuild/doebuild.py |  5 ++-
 2 files changed, 61 insertions(+), 1 deletion(-)

diff --git a/bin/misc-functions.sh b/bin/misc-functions.sh
index 079369313..18cddea21 100755
--- a/bin/misc-functions.sh
+++ b/bin/misc-functions.sh
@@ -256,6 +256,63 @@ install_qa_check() {
rm -f "${ED}"/usr/share/info/dir{,.gz,.bz2} || die "rm failed!"
 }
 
+postinst_qa_check() {
+   local d f paths qa_checks=()
+   if ! ___eapi_has_prefix_variables; then
+   local EPREFIX= EROOT=${ROOT}
+   fi
+
+   cd "${EROOT}" || die "cd failed"
+
+   # Collect the paths for QA checks, highest prio first.
+   paths=(
+   # sysadmin overrides
+   "${PORTAGE_OVERRIDE_EPREFIX}"/usr/local/lib/postinst-qa-check.d
+   # system-wide package installs
+   "${PORTAGE_OVERRIDE_EPREFIX}"/usr/lib/postinst-qa-check.d
+   )
+
+   # Now repo-specific checks.
+   # (yes, PORTAGE_ECLASS_LOCATIONS contains repo paths...)
+   for d in "${PORTAGE_ECLASS_LOCATIONS[@]}"; do
+   paths+=(
+   "${d}"/metadata/postinst-qa-check.d
+   )
+   done
+
+   paths+=(
+   # Portage built-in checks
+   
"${PORTAGE_OVERRIDE_EPREFIX}"/usr/lib/portage/postinst-qa-check.d
+   "${PORTAGE_BIN_PATH}"/postinst-qa-check.d
+   )
+
+   # Collect file names of QA checks. We need them early to support
+   # overrides properly.
+   for d in "${paths[@]}"; do
+   for f in "${d}"/*; do
+   [[ -f ${f} ]] && qa_checks+=( "${f##*/}" )
+   done
+   done
+
+   # Now we need to sort the filenames lexically, and process
+   # them in order.
+   while read -r -d '' f; do
+   # Find highest priority file matching the basename.
+   for d in "${paths[@]}"; do
+   [[ -f ${d}/${f} ]] && break
+   done
+
+   # Run in a subshell to treat it like external script,
+   # but use 'source' to pass all variables through.
+   (
+   # Allow inheriting eclasses.
+   # XXX: we want this only in repository-wide checks.
+   _IN_INSTALL_QA_CHECK=1
+   source "${d}/${f}" || eerror "Post-postinst QA check 
${f} failed to run"
+   )
+   done < <(printf "%s\0" "${qa_checks[@]}" | LC_ALL=C sort -u -z)
+}
+
 install_mask() {
local root="$1"
shift
diff --git a/pym/portage/package/ebuild/doebuild.py 
b/pym/portage/package/ebuild/doebuild.py
index 14d96f57c..ac697a763 100644
--- a/pym/portage/package/ebuild/doebuild.py
+++ b/pym/portage/package/ebuild/doebuild.py
@@ -1738,7 +1738,10 @@ _post_phase_cmds = {
"preinst_sfperms",
"preinst_selinux_labels",
"preinst_suid_scan",
-   ]
+   ],
+
+   "postinst" : [
+   "postinst_qa_check"],
 }
 
 def _post_phase_userpriv_perms(mysettings):
-- 
2.14.1

Re: [gentoo-dev] [FRC] News item: Changing USE flags for >=app-backup/bacula

[Kristian Fiskerstrand]

On 08/15/2017 11:33 AM, tom...@gentoo.org wrote:
> Quoting Kristian Fiskerstrand (2017-08-15 10:37:39)
>> On 08/15/2017 12:29 AM, Rich Freeman wrote:
>>> On Mon, Aug 14, 2017 at 5:55 PM, Michał Górny  wrote:
 On pon, 2017-08-14 at 21:58 +0200, Thomas Beierlein wrote:
> * 'bacula-clientonly' becomes 'clientonly'
 This is still negative logic in disguise. clientonly = noserver.
>>
>> Can the "minimum"-use flag be utilized here?
>>
> Sounds reasonable and is worth thinking about. At least we could define the
> meaning of "minimum" here in metadata.xml.
> 
> But, looking through portage there seems to be no "minimum" use flag anymore.
> Seems it got dropped for some reasons.
> 

typo; "minimal"...
-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [FRC] News item: Changing USE flags for >=app-backup/bacula

[tomjbe]

Quoting Kristian Fiskerstrand (2017-08-15 10:37:39)
> On 08/15/2017 12:29 AM, Rich Freeman wrote:
> > On Mon, Aug 14, 2017 at 5:55 PM, Michał Górny  wrote:
> >> On pon, 2017-08-14 at 21:58 +0200, Thomas Beierlein wrote:
> >>> * 'bacula-clientonly' becomes 'clientonly'
> >> This is still negative logic in disguise. clientonly = noserver.
> 
> Can the "minimum"-use flag be utilized here?
>
Sounds reasonable and is worth thinking about. At least we could define the
meaning of "minimum" here in metadata.xml.

But, looking through portage there seems to be no "minimum" use flag anymore.
Seems it got dropped for some reasons.

Regards,

Thomas

Re: [gentoo-dev] [FRC] News item: Changing USE flags for >=app-backup/bacula

[tomjbe]

Quoting Michał Górny (2017-08-15 08:43:07)
> On wto, 2017-08-15 at 06:55 +0200, tom...@gentoo.org wrote:
> > Quoting Rich Freeman (2017-08-15 00:29:19)
> > > On Mon, Aug 14, 2017 at 5:55 PM, Michał Górny  wrote:
> > > > On pon, 2017-08-14 at 21:58 +0200, Thomas Beierlein wrote:
> > > > > 
> > > > > * 'bacula-clientonly' becomes 'clientonly'
> > > > 
> > > > This is still negative logic in disguise. clientonly = noserver.
> > 
> > True. See below for discussion.
> > > > 
> > > > > * 'bacula-nodir' will be replaced by 'director' but with inverted 
> > > > > logic
> > > > > * 'bacula-nosd' will be replaced by 'storage-daemon' (also inverted).
> > > > > 
> > > > > 'director' and 'storage-daemon' will be active by default resulting 
> > > > > in an
> > > > > installation with backup director and storage daemon enabled.
> > > > > 
> > > 
> > > ++
> > > 
> > > I guess to make it a bit more explicit, would it make sense to have 3 
> > > flags:
> > > 
> > > client - install the client   (or consider calling it file-daemon instead)
> > > director - install the director
> > > storage-daemon - install the storage daemon
> > > 
> > 
> > That would be best, but it is not supported by their (autoconf based) build
> > system (and would require a complete rewrite of it). The actual USE flags
> > mostly mirrors the switches from the configure script. You can not set them 
> > as
> > you like, they are not orthogonal E.g. the file deamon (client) will be
> > installed unconditionally.
> > 
> > The configure script itself is very brittle atm and needs an urgent 
> > overhaul.
> > Discussion with upstream goes a long way, but they do not want to change it
> > because of the need to retest it on very different systems. No good 
> > situation.
> > 
> > A possible idea may be to drop the 'no/client' flag completely. If neither
> > 'director' nor 'storage-daemon' is active all that is left would be the 
> > file daemon.
> > What do you think?
> 
> WFM. If the flag doesn't do anything except for disabling the two other
> flags, then there's no place for such a flag.
> 
And here comes the problem. USE="bacula-nodir bacula-nosd" does not produce
the same set of files as USE="bacula-clientonly". But I will recheck if the
difference is of relevance for normal gentoo user.

> > 
> > The downside of that idea is that we diverge from baculas documentation 
> > which
> > explicitly state that there is a 'clientonly' install. 
> > 
> 
> Upstream install documentation is not relevant to Gentoo. The flag
> descriptions in metadata.xml are.
> 
Right. But if we drop a "clientonly" than there is no hint in metadata.xml how
to get only the file daemon alone. Some einfo output or similar come to mind.

Regards,

Thomas

Re: [gentoo-dev] [FRC] News item: Changing USE flags for >=app-backup/bacula

[Kristian Fiskerstrand]

On 08/15/2017 12:29 AM, Rich Freeman wrote:
> On Mon, Aug 14, 2017 at 5:55 PM, Michał Górny  wrote:
>> On pon, 2017-08-14 at 21:58 +0200, Thomas Beierlein wrote:
>>> * 'bacula-clientonly' becomes 'clientonly'
>> This is still negative logic in disguise. clientonly = noserver.

Can the "minimum"-use flag be utilized here?

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Changing PMS to Portage Manager Specification

[Michał Górny]

On pon, 2017-08-14 at 18:39 -0400, William L. Thomson Jr. wrote:
> On Mon, 14 Aug 2017 15:20:26 -0700
> Rich Freeman  wrote:
> 
> > On Mon, Aug 14, 2017 at 5:26 PM, William L. Thomson Jr.
> >  wrote:
> > > 
> > > Portage supports sets, but the PMS has no mention. Then there is
> > > debate on what they are. Creating so much noise it drowns the bug
> > > request and makes it invalid. Despite the need still existing, and
> > > PMS lacking anything on  sets.
> > > https://bugs.gentoo.org/show_bug.cgi?id=624300
> > > 
> > > Just the needs I have with portage are stalled, marked as invalid.
> > > No discussion for inclusion in PMS. Like documenting sets.  
> > 
> > Ah, well, that's the main mystery of this thread solved.  Thanks.
> 
> That is the tip of the iceberg, not the main problem itself. I have
> never been a fan of EAPI, or the resulting PMS, etc. Having been around
> before such existed, I do not believe it has helped Gentoo and in fact
> maybe the opposite. Why EAPI 0 stuff is in tree, or very old EAPIs.
> 
> Now becoming more real issues rather than just a dislike of EAPI.
> 

Yes, it would be much better if we didn't have EAPI and instead of old
EAPI=0 ebuilds we would just have old ebuilds that install half-broken
packages because of ebuild incompatibility.

-- 
Best regards,
Michał Górny


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] [FRC] News item: Changing USE flags for >=app-backup/bacula

[Michał Górny]

On wto, 2017-08-15 at 06:55 +0200, tom...@gentoo.org wrote:
> Quoting Rich Freeman (2017-08-15 00:29:19)
> > On Mon, Aug 14, 2017 at 5:55 PM, Michał Górny  wrote:
> > > On pon, 2017-08-14 at 21:58 +0200, Thomas Beierlein wrote:
> > > > 
> > > > * 'bacula-clientonly' becomes 'clientonly'
> > > 
> > > This is still negative logic in disguise. clientonly = noserver.
> 
> True. See below for discussion.
> > > 
> > > > * 'bacula-nodir' will be replaced by 'director' but with inverted logic
> > > > * 'bacula-nosd' will be replaced by 'storage-daemon' (also inverted).
> > > > 
> > > > 'director' and 'storage-daemon' will be active by default resulting in 
> > > > an
> > > > installation with backup director and storage daemon enabled.
> > > > 
> > 
> > ++
> > 
> > I guess to make it a bit more explicit, would it make sense to have 3 flags:
> > 
> > client - install the client   (or consider calling it file-daemon instead)
> > director - install the director
> > storage-daemon - install the storage daemon
> > 
> 
> That would be best, but it is not supported by their (autoconf based) build
> system (and would require a complete rewrite of it). The actual USE flags
> mostly mirrors the switches from the configure script. You can not set them as
> you like, they are not orthogonal E.g. the file deamon (client) will be
> installed unconditionally.
> 
> The configure script itself is very brittle atm and needs an urgent overhaul.
> Discussion with upstream goes a long way, but they do not want to change it
> because of the need to retest it on very different systems. No good situation.
> 
> A possible idea may be to drop the 'no/client' flag completely. If neither
> 'director' nor 'storage-daemon' is active all that is left would be the 
> file daemon.
> What do you think?

WFM. If the flag doesn't do anything except for disabling the two other
flags, then there's no place for such a flag.

> 
> The downside of that idea is that we diverge from baculas documentation which
> explicitly state that there is a 'clientonly' install. 
> 

Upstream install documentation is not relevant to Gentoo. The flag
descriptions in metadata.xml are.

-- 
Best regards,
Michał Górny


signature.asc
Description: This is a digitally signed message part