Re: [gentoo-dev] New package neomutt

[Daniel Campbell]

On 08/10/2017 01:10 AM, Michał Górny wrote:
> On czw, 2017-08-10 at 09:54 +0200, Fabian Groffen wrote:
>> On 10-08-2017 09:40:30 +0200, Michał Górny wrote:
>>> On czw, 2017-08-10 at 06:58 +0200, Nicolas Bock wrote:
 On Mon, Jul 31, 2017 at 09:11:19AM +0200, Nicolas Bock wrote:
> Hi,
>
> I would like to add neomutt to the tree. This new package is meant as 
> an alternative and not a replacement of the existing mutt package.

 Thanks for all of the great suggestions and feedback!

 This is round two. I have update the ebuild with all your 
 suggestions. I have also added support for eselecting between mutt 
 and neomutt. Before the eselect ebuild can land though, we need to 
 rename the mutt binary so that the managed link can be called 
 mutt.
>>>
>>> What for? How many people are exactly in the dire need of having both
>>> installed simultaneously and switching between them? If you really can't
>>> learn to type the new command, add IUSE=symlink blocking original mutt
>>> and be done with it. Don't add more unowned files to /usr by another
>>> poorly written eselect module.
>>
>> Be nice!  No need to be bitchy here (and in the rest of your review).
>> Nicolas is just trying.
>>
>> Me, as maintainer of Mutt, thought it was a good idea, because it allows
>> people to easily have both installed at the same time, which in this
>> interesting time for both projects is not a weird thing to have.
> 
> I don't see how eselect helps that. People can just run neomutt by
> typing... neomutt, right? It works without the symlink, right?
> 
>> If there is a policy/move to get rid of eselect, then sorry, I am not
>> aware of that.  I can live with a symlink USE-flag.  It doesn't seem
>> very elegant to me, but it would work for this scenario.
>>
> 
> The move is against orphaned files in /usr that are randomly changed by
> runtime tools rather than the package manager.
> 

Then how do we explain the reasoning for the other 50 or so eselect
modules? No doubt at least a handful of them modify symlinks in /usr,
and have similarly few options to choose from, such as eselect-vi.
Should we remove those as well?

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Package up for grabs: net-dns/dnscrypt-proxy

[Georgy Yakovlev]

Hi,

I'd like to take this one.

Currently working on the new version and submitted a pull request.

https://github.com/gentoo/gentoo/pull/5346

My proxy is Polynomial-C@


Regards,

Georgy Yakovlev


On 08/16/2017 08:47 PM, Gokturk Yuksek wrote:
> Hi, > > The following package is up for grabs: > > net-dns/dnscrypt-proxy >

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

[Jason Zaman]

On Tue, Aug 15, 2017 at 11:22:54PM -0400, Michael Orlitzky wrote:
> 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)

SELinux policy packages are not strictly RDEPENDs, portage will label
packages as they are installed properly. if the policy package wasnt
installed by the time the package is installed, you can manually label a
package with rlpkg . but obviously having things jsut work is
better. and they arnt DEPEND because you dont need them to build the
package.

Any i know of no selinux users using other package managers. There are
no policies for them so they wouldnt work anyway. so no really throwing
them under the bus. I dont think the other package managers label
packages properly during install anyway even if there was a policy
written.

So there still isnt a reason to revbump a package when 99% of the world
will not want it.

-- Jason

[gentoo-dev] Package up for grabs: net-dns/dnscrypt-proxy

[Gokturk Yuksek]

Hi,

The following package is up for grabs:

  net-dns/dnscrypt-proxy



signature.asc
Description: OpenPGP digital signature

[gentoo-portage-dev] [PATCH 2/2] quickpkg: revert premature return from quickpkg_atom (bug 628060)

[Zac Medico]

Revert premature return from the quickpkg_atom function for atoms
that match multiple slots. This fixes it to create packages for
all matched slots, rather than just the lowest version.

Fixes: cff2c0149142 ("Support different compressors for binary packages")
X-Gentoo-bug: 628060
X-Gentoo-bug-url: https://bugs.gentoo.org/628060
---
 bin/quickpkg | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/bin/quickpkg b/bin/quickpkg
index 3094dd0ae..81d6afa08 100755
--- a/bin/quickpkg
+++ b/bin/quickpkg
@@ -66,6 +66,7 @@ def quickpkg_atom(options, infos, arg, eout):
 
matches = vardb.match(atom)
pkgs_for_arg = 0
+   retval = 0
for cpv in matches:
excluded_config_files = []
dblnk = vardb._dblink(cpv)
@@ -177,20 +178,19 @@ def quickpkg_atom(options, infos, arg, eout):
eout.eerror(str(e))
del e
eout.eerror("Failed to create package: '%s'" % 
binpkg_path)
-   return 1
+   retval |= 1
else:
eout.eend(0)
infos["successes"].append((cpv, s.st_size))
infos["config_files_excluded"] += 
len(excluded_config_files)
for filename in excluded_config_files:
eout.ewarn("Excluded config: '%s'" % filename)
-   return os.EX_OK
if not pkgs_for_arg:
eout.eerror("Could not find anything " + \
"to match '%s'; skipping" % arg)
infos["missing"].append(arg)
-   return 1
-   return os.EX_OK
+   retval |= 1
+   return retval
 
 def quickpkg_set(options, infos, arg, eout):
eroot = portage.settings['EROOT']
-- 
2.13.0

[gentoo-portage-dev] [PATCH 1/2] quickpkg: revert accidental changes to "protect" function (bug 628010)

[Zac Medico]

Revert accidental changes to the "protect" function's return value
that were mixed in with changes to the "quickpkg_atom" function's
return value.

Fixes: cff2c0149142 ("Support different compressors for binary packages")
X-Gentoo-bug: 628010
X-Gentoo-bug-url: https://bugs.gentoo.org/628010
---
 bin/quickpkg | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/bin/quickpkg b/bin/quickpkg
index 392e9da22..3094dd0ae 100755
--- a/bin/quickpkg
+++ b/bin/quickpkg
@@ -111,16 +111,16 @@ def quickpkg_atom(options, infos, arg, eout):
in settings.features))
def protect(filename):
if not confprot.isprotected(filename):
-   return 1
+   return False
if include_unmodified_config:
file_data = contents[filename]
if file_data[0] == "obj":
orig_md5 = 
file_data[2].lower()
cur_md5 = 
perform_md5(filename, calc_prelink=1)
if orig_md5 == cur_md5:
-   return 1
+   return False
excluded_config_files.append(filename)
-   return os.EX_OK
+   return True
existing_metadata = dict(zip(fix_metadata_keys,
vardb.aux_get(cpv, fix_metadata_keys)))
category, pf = portage.catsplit(cpv)
-- 
2.13.0

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

[Daniel Campbell]

On 08/14/2017 03:39 PM, 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.
> 
I'm unaware of any other way to introduce progressive changes to an API
without literally rewriting every ebuild. Versioned APIs are good APIs,
and give developers (both inside and outside Gentoo) something they can
depend on and, most importantly, predict. If there was just one EAPI,
you'd need to consult git log or some other construct to figure out the
API version an ebuild was written against.

The fact we still have older EAPI ebuilds is one of manpower and
(dis)interest. I don't see anyone trying to prevent (or encourage) EAPI
upgrading across the tree. Generally, we wait until a package needs a
revbump/version bump and/or has serious breakage (and thus needing a
rewrite) before bumping EAPI. Some jumps in EAPI, for simple packages,
are painless. Others are a nightmare.

I see no other way to support the 1m+ ebuilds that have been written
since Gentoo's inception in an unambiguous, reference-able way. In fact,
I'd argue if you don't version your APIs, you're not designing them
correctly. APIs *will* change; building a version number into the API
ensures the consumers of said API are aware of changes.

That said, yes, it'd be nice if every ebuild was EAPI 6, but that is a
hge amount of work that nobody seems interested in, for questionable
gain. The work would just be repeated when the next EAPI is approved.
The way it works now is more organic and better representative of the
state of Gentoo development, for better or worse.

It's good to see you taking part in constructive discussions! That's not
intended as sarcasm. I mean it. Thanks for taking part.

~zlg

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature

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

[Daniel Campbell]

On 08/13/2017 03:11 AM, Michael Orlitzky wrote:
> On 08/12/2017 10:52 PM, Duncan wrote:
>>
>> How so?  Are you arguing that deciding to system-wide switch to/from 
>> pulseaudio, systemd, or gstreamer is nonsense?
>>
> 
> The meaning of any one USE flag varies widely across packages. I could
> never say "I want to enable USE=gstreamer" for every package in the
> tree, because I have no idea what it does for most of them. Setting
> USE=whatever globally essentially means "make random changes to my
> system" -- hence my wording.
> 
> The meaning of a USE flag is per-package, so per-package is the only
> meaningful way to set them.
> 
There are USE flag situations that are relevant at the global level.
systemd, pulseaudio, alsa, gstreamer, openssl/libressl, libav/ffmpeg,
vim-syntax, and so on. Then there's USE_EXPAND variables, which might
mean different things in different packages and yet I see nothing in
your argument covering them.

These flags make perfect sense at the global level, because users
generally want support for the choices they make, and they make choices
on that *general* level first, before diving into package-specific USE
flags. It's a monumental waste of developer and user time to manually
set major USE flags in every relevant package. Some people are picky and
will still do that, but global USE ensures that certain assumptions are
made about your system. If you don't want assumptions, don't use global
USE. There's no reason to deprive others of functionality you don't
personally agree with or use.

Granted, some flags don't belong in make.conf. But part of Gentoo's
beauty is that we *do* let users proverbially saw their leg off, if
that's what they really want. There are lots of use cases that would be
made ridiculous in scope if we got rid of global USE. Is your only
answer a megabyte-long p.use file?

That said, I like your idea of clearing up revbump decisions and the
angle of reducing development burden. This particular idea comes at too
high a cost for my taste, as we stand to lose functionality rather than
improve or gain it.

~zlg
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature

[gentoo-portage-dev] [PATCH v2 2/4] 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 v2 4/4] Update caches after reporting missing cache updates

[Michał Górny]

Call the appropriate updater to update caches after reporting a missing
cache update, in order to stop repeating the same issue on subsequent
packages that did not install any relevant files.
---
 bin/postinst-qa-check.d/50gnome2-utils |  9 +
 bin/postinst-qa-check.d/50xdg-utils| 18 ++
 2 files changed, 27 insertions(+)

diff --git a/bin/postinst-qa-check.d/50gnome2-utils 
b/bin/postinst-qa-check.d/50gnome2-utils
index 4e7c6eb85..d0cbb4037 100644
--- a/bin/postinst-qa-check.d/50gnome2-utils
+++ b/bin/postinst-qa-check.d/50gnome2-utils
@@ -16,6 +16,15 @@ gnome2_icon_cache_check() {
while read -r -d $'\0' f; do
files+=( "${f}" )
done < <(find "${d}" -mindepth 2 -type f "${find_args[@]}" 
-print0)
+
+   # if any files were found, update the db to avoid repeating
+   # the warning for subsequent packages
+   # (note: yes, it will eagerly repeat the update for next dirs
+   # but that's a minor issue)
+   if [[ ${files[@]} ]]; then
+   addwrite "${d}"
+   gtk-update-icon-cache -qf "${d}"
+   fi
done
 
if [[ ${files[@]} ]]; then
diff --git a/bin/postinst-qa-check.d/50xdg-utils 
b/bin/postinst-qa-check.d/50xdg-utils
index b0bb029bd..9f5e9a48c 100644
--- a/bin/postinst-qa-check.d/50xdg-utils
+++ b/bin/postinst-qa-check.d/50xdg-utils
@@ -17,6 +17,15 @@ xdg_desktop_database_check() {
files+=( "${f}" )
done < <(find "${d}" -name '*.desktop' "${find_args[@]}" \
-exec grep -lZi '^MimeType=' {} +)
+
+   # if any files were found, update the db to avoid repeating
+   # the warning for subsequent packages
+   # (note: yes, it will eagerly repeat the update for next dirs
+   # but it's a minor issue and we have only one dir anyway)
+   if [[ ${files[@]} ]]; then
+   addwrite "${d}"
+   update-desktop-database "${d}"
+   fi
done
 
if [[ ${files[@]} ]]; then
@@ -42,6 +51,15 @@ xdg_mimeinfo_database_check() {
while read -r -d $'\0' f; do
files+=( "${f}" )
done < <(find "${d}" -name '*.xml' "${find_args[@]}" -print0)
+
+   # if any files were found, update the db to avoid repeating
+   # the warning for subsequent packages
+   # (note: yes, it will eagerly repeat the update for next dirs
+   # but it's a minor issue and we have only one dir anyway)
+   if [[ ${files[@]} ]]; then
+   addwrite "${d}"
+   update-mime-database "${d}"
+   fi
done
 
if [[ ${files[@]} ]]; then
-- 
2.14.1

[gentoo-portage-dev] [PATCH v2 3/4] Use ctime in cache post-postinst checks

[Michał Górny]

Use ctime rather than mtime in cache post-postinst checks since mtime
may be preserved from the original tarball, and therefore be 'long time
ago'. ctime is more reliable in this regard.
---
 bin/postinst-qa-check.d/50gnome2-utils | 2 +-
 bin/postinst-qa-check.d/50xdg-utils| 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/bin/postinst-qa-check.d/50gnome2-utils 
b/bin/postinst-qa-check.d/50gnome2-utils
index 68e21cb74..4e7c6eb85 100644
--- a/bin/postinst-qa-check.d/50gnome2-utils
+++ b/bin/postinst-qa-check.d/50gnome2-utils
@@ -10,7 +10,7 @@ gnome2_icon_cache_check() {
# 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 )
+   find_args+=( -newercm "${d}"/icon-theme.cache )
 
# (use -mindepth 2 to easily skip the cache files)
while read -r -d $'\0' f; do
diff --git a/bin/postinst-qa-check.d/50xdg-utils 
b/bin/postinst-qa-check.d/50xdg-utils
index 4bc7bee9a..b0bb029bd 100644
--- a/bin/postinst-qa-check.d/50xdg-utils
+++ b/bin/postinst-qa-check.d/50xdg-utils
@@ -9,7 +9,7 @@ xdg_desktop_database_check() {
# 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 )
+   find_args+=( -newercm "${d}"/mimeinfo.cache )
 
# look for any .desktop files that are newer than the cache
# and that have any mime types defined
@@ -37,7 +37,7 @@ xdg_mimeinfo_database_check() {
# 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 )
+   find_args+=( -newercm "${d}"/mime.cache )
 
while read -r -d $'\0' f; do
files+=( "${f}" )
-- 
2.14.1

[gentoo-portage-dev] [PATCH v2 1/4] 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-portage-dev] [PATCH 3/2] Update caches after reporting missing cache updates

[Michał Górny]

W dniu śro, 16.08.2017 o godzinie 16∶22 +0200, użytkownik Michał Górny
napisał:
> Call the appropriate updater to update caches after reporting a missing
> cache update, in order to stop repeating the same issue on subsequent
> packages that did not install any relevant files.
> ---
>  bin/postinst-qa-check.d/50gnome2-utils |  8 
>  bin/postinst-qa-check.d/50xdg-utils| 16 
>  2 files changed, 24 insertions(+)
> 
> // (a followup to postinst patches)
> 
> diff --git a/bin/postinst-qa-check.d/50gnome2-utils 
> b/bin/postinst-qa-check.d/50gnome2-utils
> index 68e21cb74..97495f07b 100644
> --- a/bin/postinst-qa-check.d/50gnome2-utils
> +++ b/bin/postinst-qa-check.d/50gnome2-utils
> @@ -16,6 +16,14 @@ gnome2_icon_cache_check() {
>   while read -r -d $'\0' f; do
>   files+=( "${f}" )
>   done < <(find "${d}" -mindepth 2 -type f "${find_args[@]}" 
> -print0)
> +
> + # if any files were found, update the db to avoid repeating
> + # the warning for subsequent packages
> + # (note: yes, it will eagerly repeat the update for next dirs
> + # but that's a minor issue)
> + if [[ ${files[@]} ]]; then
> + gtk-update-icon-cache -qf "${d}"
> + fi
>   done
>  
>   if [[ ${files[@]} ]]; then
> diff --git a/bin/postinst-qa-check.d/50xdg-utils 
> b/bin/postinst-qa-check.d/50xdg-utils
> index 4bc7bee9a..8c33b2dfe 100644
> --- a/bin/postinst-qa-check.d/50xdg-utils
> +++ b/bin/postinst-qa-check.d/50xdg-utils
> @@ -17,6 +17,14 @@ xdg_desktop_database_check() {
>   files+=( "${f}" )
>   done < <(find "${d}" -name '*.desktop' "${find_args[@]}" \
>   -exec grep -lZi '^MimeType=' {} +)
> +
> + # if any files were found, update the db to avoid repeating
> + # the warning for subsequent packages
> + # (note: yes, it will eagerly repeat the update for next dirs
> + # but it's a minor issue and we have only one dir anyway)
> + if [[ ${files[@]} ]]; then
> + update-desktop-database "${d}"
> + fi
>   done
>  
>   if [[ ${files[@]} ]]; then
> @@ -42,6 +50,14 @@ xdg_mimeinfo_database_check() {
>   while read -r -d $'\0' f; do
>   files+=( "${f}" )
>   done < <(find "${d}" -name '*.xml' "${find_args[@]}" -print0)
> +
> + # if any files were found, update the db to avoid repeating
> + # the warning for subsequent packages
> + # (note: yes, it will eagerly repeat the update for next dirs
> + # but it's a minor issue and we have only one dir anyway)
> + if [[ ${files[@]} ]]; then
> + update-mime-database "${d}"
> + fi
>   done
>  
>   if [[ ${files[@]} ]]; then

Please disregard this one for now, it needs more work.

-- 
Best regards,
Michał Górny

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

[Rich Freeman]

On Wed, Aug 16, 2017 at 11:56 AM, Duncan <1i5t5.dun...@cox.net> wrote:
>
> But even if that's the case (I wouldn't know), it's the case due to a
> deliberate decision of those going "under the bus", because portage is
> the default, and by choosing to use some other PM, they've deliberately
> chosen its (non-PMS) features over those of portage.
>

None of this really has anything to do with PMS as far as I can tell.
There is no PMS requirement for --changed-use and such.  There
certainly might be a usability requirement for it, which is why it
usually exists in one way or another.

-- 
Rich

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

[Duncan]

Francisco Blas Izquierdo Riera (klondike) posted on Wed, 16 Aug 2017
12:09:57 +0200 as excerpted:

> s you may know the core of sys-kernel/hardened-sources have been the
> grsecuirty patches.

New typo: s/grsecuirty/grsecurity/

-- 
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: Revisions for USE flag changes

[Duncan]

Michael Orlitzky posted on Tue, 15 Aug 2017 23:22:54 -0400 as excerpted:

> 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.

But even if that's the case (I wouldn't know), it's the case due to a 
deliberate decision of those going "under the bus", because portage is 
the default, and by choosing to use some other PM, they've deliberately 
chosen its (non-PMS) features over those of portage.

Just as I, by choosing --newuse instead, have chosen to do rebuilds in 
such cases, even with portage.

(Tho TBH I've never noticed that particular case, probably because it's 
lost in the noise compared to --changed-deps (enabled when static-deps 
were newer and I wanted to be sure, likely unneeded these days) and smart-
live-rebuild of my (live) kde packages.)

-- 
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-portage-dev] [PATCH 3/2] Update caches after reporting missing cache updates

[Michał Górny]

Call the appropriate updater to update caches after reporting a missing
cache update, in order to stop repeating the same issue on subsequent
packages that did not install any relevant files.
---
 bin/postinst-qa-check.d/50gnome2-utils |  8 
 bin/postinst-qa-check.d/50xdg-utils| 16 
 2 files changed, 24 insertions(+)

// (a followup to postinst patches)

diff --git a/bin/postinst-qa-check.d/50gnome2-utils 
b/bin/postinst-qa-check.d/50gnome2-utils
index 68e21cb74..97495f07b 100644
--- a/bin/postinst-qa-check.d/50gnome2-utils
+++ b/bin/postinst-qa-check.d/50gnome2-utils
@@ -16,6 +16,14 @@ gnome2_icon_cache_check() {
while read -r -d $'\0' f; do
files+=( "${f}" )
done < <(find "${d}" -mindepth 2 -type f "${find_args[@]}" 
-print0)
+
+   # if any files were found, update the db to avoid repeating
+   # the warning for subsequent packages
+   # (note: yes, it will eagerly repeat the update for next dirs
+   # but that's a minor issue)
+   if [[ ${files[@]} ]]; then
+   gtk-update-icon-cache -qf "${d}"
+   fi
done
 
if [[ ${files[@]} ]]; then
diff --git a/bin/postinst-qa-check.d/50xdg-utils 
b/bin/postinst-qa-check.d/50xdg-utils
index 4bc7bee9a..8c33b2dfe 100644
--- a/bin/postinst-qa-check.d/50xdg-utils
+++ b/bin/postinst-qa-check.d/50xdg-utils
@@ -17,6 +17,14 @@ xdg_desktop_database_check() {
files+=( "${f}" )
done < <(find "${d}" -name '*.desktop' "${find_args[@]}" \
-exec grep -lZi '^MimeType=' {} +)
+
+   # if any files were found, update the db to avoid repeating
+   # the warning for subsequent packages
+   # (note: yes, it will eagerly repeat the update for next dirs
+   # but it's a minor issue and we have only one dir anyway)
+   if [[ ${files[@]} ]]; then
+   update-desktop-database "${d}"
+   fi
done
 
if [[ ${files[@]} ]]; then
@@ -42,6 +50,14 @@ xdg_mimeinfo_database_check() {
while read -r -d $'\0' f; do
files+=( "${f}" )
done < <(find "${d}" -name '*.xml' "${find_args[@]}" -print0)
+
+   # if any files were found, update the db to avoid repeating
+   # the warning for subsequent packages
+   # (note: yes, it will eagerly repeat the update for next dirs
+   # but it's a minor issue and we have only one dir anyway)
+   if [[ ${files[@]} ]]; then
+   update-mime-database "${d}"
+   fi
done
 
if [[ ${files[@]} ]]; then
-- 
2.14.1

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

[Tim Harder]

On 2017-08-16 05:56, Ulrich Mueller wrote:
> > Considering it says exactly the same for EAPI 5, this is almost
> > certainly a mistake - but I'd rather confirm this here before
> > changing the page.

> Unfortunately, information about EAPI 4 and 5 support is not entirely
> clear from the NEWS file, so one must look into the git log. Quoting
> bug 326459 comment 4 [1]:

>EAPI 4: pkgcore-0.6.5 (2011-06-22), which is the first version
>(correctly) supporting default src_install. There's another change
>for EAPI 4 in 0.7, namely removal of the AA and KV variables, but I
>think this can be ignored here (also it's not in the NEWS file).

>EAPI 5: pkgcore-0.9.3 (2016-05-28). NEWS says for 0.9 that it has
>"Nearly complete EAPI=5 support just missing subslot rebuilds."
>This was finally added in 0.9.3, "Add support for PN:slot/subslot
>and slotted glob targets."

> So yes, it appears that full support for EAPI 5 was added only in
> pkgcore-0.9.3, which supports EAPI 6 already.

Just to note, I consider pkgcore-0.9 to support EAPI 5 nearly as far as
PMS specifies. The news item you pointed out has more to do with adding
subslot input support for cli tools (pmerge, pquery, etc) which doesn't
have anything to do with PMS.

Tim

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

[tomjbe]

Quoting Thomas Beierlein (2017-08-14 21:58:42)
> Bacula ebuilds uses some weird USE flags with mostly negative
> logic ('do not build ..') coming from their build system.
> 
> With the actual major release (bacula-9.0.3) we should try to switch to
> something more sane. I picked up the new flags from app-backup/bareos as
> both ebuilds have a common anchestry.
> 
> Please comment on the proposed news item. 
> 
> Thanks,
> Thomas
> 
First thanks to all who commented and gave wise advices.

As I see it the discussion boils down to the following new behaviour:

* There will be two USE flags 'director' and 'storage-daemon' which are on by
  default and control the installation of the backup director component 
  and the storage daemon accordingly.
* If both flags are unset neither component gets installed. Only the set of
  files for the file daemon (Client) gets installed - mimicking the
  former 'clientonly' behaviour. The old 'bacula-clientonly' flag gets dropped
  completely.
 
It will require quite some changes to the ebuild and due to its complexity
also some tests. As I have only three days left to holiday I will suspend the
switch to the new USE flag settings for now.

To let users no longer wait for the actual 9.0.3 version (which is out for
already 2 weeks now) I would like to bring it into the tree with the old USE
flag settings. The switch to the new one will then be made after returning 
from my holiday vacation.

Comments?

Best regards,

Thomas.

[gentoo-portage-dev] [PATCH] elog mod_echo: Print log path if PORT_LOGDIR is used

[Michał Górny]

Include the path to the log file if PORT_LOGDIR is being used
(and therefore the log is going to be preserved past the build). This is
useful when elog messages contain QA warnings or other errors that
require reporting a bug. In such case, having a path to the log is
handy.

After this commit, the mod_echo output becomes:

 * Messages for package dev-foo/bar-1:
 * Log file: /var/log/portage/dev-foo:bar-1:20170816-100533.log

 * test
---
 pym/portage/elog/mod_echo.py | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/pym/portage/elog/mod_echo.py b/pym/portage/elog/mod_echo.py
index f9cc53788..bb34a1e44 100644
--- a/pym/portage/elog/mod_echo.py
+++ b/pym/portage/elog/mod_echo.py
@@ -1,5 +1,5 @@
 # elog/mod_echo.py - elog dispatch module
-# Copyright 2007-2014 Gentoo Foundation
+# Copyright 2007-2017 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
 
 from __future__ import print_function
@@ -16,7 +16,12 @@ if sys.hexversion >= 0x300:
 _items = []
 def process(mysettings, key, logentries, fulltext):
global _items
-   _items.append((mysettings["ROOT"], key, logentries))
+   logfile = None
+   # output logfile explicitly only if it isn't in tempdir, otherwise
+   # it will be removed anyway
+   if "PORT_LOGDIR" in mysettings:
+   logfile = mysettings["PORTAGE_LOG_FILE"]
+   _items.append((mysettings["ROOT"], key, logentries, logfile))
 
 def finalize():
# For consistency, send all message types to stdout.
@@ -34,7 +39,7 @@ def finalize():
 def _finalize():
global _items
printer = EOutput()
-   for root, key, logentries in _items:
+   for root, key, logentries, logfile in _items:
print()
if root == "/":
printer.einfo(_("Messages for package %s:") %
@@ -42,6 +47,8 @@ def _finalize():
else:
printer.einfo(_("Messages for package %(pkg)s merged to 
%(root)s:") %
{"pkg": colorize("INFORM", key), "root": root})
+   if logfile is not None:
+   printer.einfo(_("Log file: %s") % colorize("INFORM", 
logfile))
print()
for phase in EBUILD_PHASES:
if phase not in logentries:
-- 
2.14.1

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

[Francisco Blas Izquierdo Riera (klondike)]

El 16/08/17 a las 09:40, Marek Szuba escribió:
> Two tiny bits of formal nitpicking from my side:
>  - it's "grsecurity" (not a typo, they do use a lowercase g except when
> the name appears at the beginning of a sentence), not "grsec";
>  - the patches were not *distributed by* grsecurity, they *are*
> grsecurity. The vendor's name is Open Source Security, Inc.

Nowadays it is, but this hasn't always been the case. You'll notice the
presence of a /dev/grsec and you'll also find grsec referenced accross
some old patches. Anyways I changed it.

The same applies to Open Source Security, Inc. the company was founded
on 2008 but grsecurity has been around for much longer. That's why I
prefer to refer to Brad Spengler and The PaX team here as they are still
the real upstream behind Open Source Security, Inc.


Title: sys-kernel/hardened-sources removal
Author: Francisco Blas Izquierdo Riera 
Posted: 2017-08-19
Revision: 4
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
grsecuirty patches.

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 grsecurity 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] Changing PMS to Portage Manager Specification

[Ulrich Mueller]

> On Wed, 16 Aug 2017, Marek Szuba wrote:

> On 2017-08-14 23:46, William L. Thomson Jr. wrote:
>> pkgcore - does not support EAPI 6, only experimental EAPI 5

> Side note - according to

> https://wiki.gentoo.org/wiki/Project:Package_Manager_Specification

> pkgcore has supported EAPI 6 since version 0.9.3.

Right, the information on the wiki page is taken from pkgcore's NEWS
file.

> Considering it says exactly the same for EAPI 5, this is almost
> certainly a mistake - but I'd rather confirm this here before
> changing the page.

Unfortunately, information about EAPI 4 and 5 support is not entirely
clear from the NEWS file, so one must look into the git log. Quoting
bug 326459 comment 4 [1]:

   EAPI 4: pkgcore-0.6.5 (2011-06-22), which is the first version
   (correctly) supporting default src_install. There's another change
   for EAPI 4 in 0.7, namely removal of the AA and KV variables, but I
   think this can be ignored here (also it's not in the NEWS file).

   EAPI 5: pkgcore-0.9.3 (2016-05-28). NEWS says for 0.9 that it has
   "Nearly complete EAPI=5 support just missing subslot rebuilds."
   This was finally added in 0.9.3, "Add support for PN:slot/subslot
   and slotted glob targets."

So yes, it appears that full support for EAPI 5 was added only in
pkgcore-0.9.3, which supports EAPI 6 already.

Ulrich

[1] https://bugs.gentoo.org/show_bug.cgi?id=326459#c4


pgprOdmQGTXvD.pgp
Description: PGP signature

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

[Marek Szuba]

On 2017-08-14 23:46, William L. Thomson Jr. wrote:

> pkgcore - does not support EAPI 6, only experimental EAPI 5

Side note - according to

https://wiki.gentoo.org/wiki/Project:Package_Manager_Specification

pkgcore has supported EAPI 6 since version 0.9.3. Considering it says
exactly the same for EAPI 5, this is almost certainly a mistake - but
I'd rather confirm this here before changing the page.

-- 
Marecki



signature.asc
Description: OpenPGP digital signature

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

[Marek Szuba]

On 2017-08-15 17:01, Francisco Blas Izquierdo Riera (klondike) wrote:

> 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.

Two tiny bits of formal nitpicking from my side:
 - it's "grsecurity" (not a typo, they do use a lowercase g except when
the name appears at the beginning of a sentence), not "grsec";
 - the patches were not *distributed by* grsecurity, they *are*
grsecurity. The vendor's name is Open Source Security, Inc.


-- 
Marecki



signature.asc
Description: OpenPGP digital signature

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

[tomjbe]

Quoting Duncan (2017-08-16 03:45:35)
> 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.
> 
Thanks for the hint. I was not sure which one is better.

Thomas.