Mart Raudsepp | 27 May 16:21 2016

[RFC] gtk/gtk2/gtk3 USE flag situation


Despite it being 2016 and gtk2 pretty much dead, buried and forgotten
upstream, many applications still support only gtk2, have subtle issues
with their gtk3 port, or support both, with some of our userbase
clinging to gtk2 for dubious political or aesthetical reasons.

For the latter cases, despite GNOME teams policy and strong preference
on not providing a choice and just choosing gtk2 or gtk3 (gtk3 if it's
working as good as gtk2), some cases exist where the maintainers want
to provide such choice. In some cases it is understandable for a short
while during transition, e.g firefox. In other cases, it is purely for
the sake of providing the choice of working with a deprecated toolkit,

My highly biased essay aside, we need to finally globally agree on what
we do in this situation. If we allow this choice at all, only for
special cases, or widespread. And if this choice is provided, how do we
name the USE flag.

Historically, for very good reasons in past and present GNOME team
members opinion, USE=gtk has always meant to mean to provide support
for gtk in general, not any particular version. This is opposite to
what the Qt team has been doing.
In our opinion, in a perfect world, only USE=gtk would exist, and no
USE=gtk2 or USE=gtk3 would be necessary. But as we don't live in a
perfect world, we have made use of USE=gtk3 for providing gtk3 support
from library packages to mean to build gtk3 support. Sadly that
overloads USE=gtk in many cases to then mean to build gtk2 support.
This would ideally not be needed, as the package would instead be
(Continue reading)

rindeal | 27 May 00:28 2016

What are eblits?

I've noticed that ebuilds for at least dev-lang/perl and
sys-libs/glibc are using some concept of "eblits", which seems like
parts of ebuilds scattered across $FILESDIR with ebuilds containing
some logic (involving eval) which includes and runs them.

I haven't found any documentation related to them so I'm asking here:

1) what are they?
2) why are they used?

Michał Górny | 26 May 20:43 2016

[PATCH 00/17] USE_EXPAND cleanup

Hi, everyone.

I've just did some testing for USE_EXPAND descriptions that are not used
in a single ebuild. I'm sending the resulting cleanup here, and CC-ing
maintainers in appropriate patches.

I'm going to commit them in a few days if nobody objects.

See also:

Michał Górny (17):
  profiles: Remove unused ALSA_CARDS descriptions
  profiles: Remove unused CALLIGRA_FEATURES=tables
  profiles: Remove obsolete (and unused) CAMERAS
  profiles: Remove unused DRACUT_MODULES=xen
  profiles: Remove unused GPSD_PROTOCOLS
  profiles: Remove unused GRUB_PLATFORMS
  profiles: Remove unused INPUT_DEVICES
  profiles: Remove unused LIBREOFFICE_EXTENSIONS
  profiles: Remove unused LIRC_DEVICES
  profiles: Remove unused NETBEANS_MODULES
  profiles: Remove unused NGINX_MODULES_HTTP
  profiles: Remove unused php5-2 target
  profiles: Remove unused RUBY_TARGETS
  profiles: Remove unused SANE_BACKENDS
  profiles: Remove unused VIDEO_CARDS
  profiles: Remove unused XFCE_PLUGINS=xmonad
  profiles: Remove unused XTABLES_ADDONS

 profiles/desc/alsa_cards.desc             | 118 ------------------------------
(Continue reading)

Johannes Huber | 26 May 16:02 2016

Last rites: kde-apps/kdesdk-strigi-analyzer

# Johannes Huber <johu <at>> (26 May 2016)
# Masked for removal in 30 days. Blocks app-misc/strigi cleanup.
# Last release in 2014 with KDE SC 4.14.3. No development since
# several years. Bug #583716
Michał Górny | 26 May 14:08 2016

[PATCH] git-r3.eclass: Support checking out repo by date, #510704

 eclass/git-r3.eclass | 69 +++++++++++++++++++++++++++++++++++++++++++---------
 1 file changed, 58 insertions(+), 11 deletions(-)

diff --git a/eclass/git-r3.eclass b/eclass/git-r3.eclass
index b7a93338..0ac9d90 100644
--- a/eclass/git-r3.eclass
+++ b/eclass/git-r3.eclass
 <at>  <at>  -159,6 +159,21  <at>  <at>  fi
 # It can be overriden via env using ${PN}_LIVE_COMMIT variable.

+# Attempt to check out the repository state for the specified timestamp.
+# The date should be in format understood by 'git rev-list'.
+# The eclass will select the last commit with commit date preceding
+# the specified date. When merge commits are found, only first parents
+# will be considered in order to avoid switching into external branches
+# (assuming that merges are done correctly). In other words, each merge
+# will be considered alike a single commit with date corresponding
+# to the merge commit date.
+# It can be overriden via env using ${PN}_LIVE_COMMIT_DATE variable.
 # The directory to check the git sources out to.
(Continue reading)

Michael Palimaka | 26 May 13:41 2016

Last rites:

# Michael Palimaka <kensington <at>> (26 May 2016)
# Ancient. Unmaintained. Dead upstream. Masked for removal
# in 30 days. Bug #583510.

Michael Palimaka | 26 May 13:33 2016

Last rites: dev-libs/hammer

# Michael Palimaka <kensington <at>> (26 May 2016)
# No longer developed by upstream. No revdeps.
# Masked for removal in 30 days. Bug 583776.

Michael Palimaka | 26 May 13:18 2016

Last rites: www-client/luakit

# Michael Palimaka <kensington <at>> (26 May 2016)
# Depends on vulnerable slot of net-libs/webkit-gtk.
# Dead upstream. Unmaintained. Masked for removal in 30 days.
# Bug 584186.

Matt Turner | 26 May 02:12 2016

app-portage/tatt: completely broken?

Is tatt usable for anyone? Both the 0.3 and 9999 versions seem to hang
after printing the Bugnumber:

# tatt -b 576112
Bugnumber:  576112

CTRL+C gives this traceback:

        ^CTraceback (most recent call last):
  File "/usr/lib/python-exec/python3.4/tatt", line 135, in <module>
    bugraw = p1.communicate()[0].decode('utf-8')
  File "/usr/lib/python3.4/", line 947, in communicate
    stdout = _eintr_retry_call(
  File "/usr/lib/python3.4/", line 491, in _eintr_retry_call
    return func(*args)

I've asked multiple times in #gentoo-dev, but the lack of responses
indicates to me that no one actually uses it which would be a shame.
If it is indeed broken, perhaps we should remove mentions of it from
pages such as [1].

Does anyone successfully use tatt? Are there alternatives to scripting
this boring keywording procedure?


Mike Gilbert | 25 May 17:52 2016

Last rites: dev-python/buildutils

# Mike Gilbert <floppym <at>> (25 May 2016)
# Causes build failures in unrelated packages due to invasive
# monkey-patching of easy_install (dev-python/setuptools).
# Remove this package in 30 days.
# Bug:

Johannes Huber | 25 May 10:05 2016

Last rites: kde-apps/pairs

# Johannes Huber <johu <at>> (25 May 2016)
# Masked for removal in 30 days. Declared as dead by
# upstream in 2015. Last release with KDE Applications 15.04.3.
# Exported to user maintained overlay kde-sunset.