[gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Michael Palimaka]

On 2012-05-23 22:42, Michael Weber wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

i've looked at the blockers of "[TRACKER] portage migration to git"
[1] and want to discuss "testing git-cvsserver" [2].

There are two proposed scenarios how to migrate the developers write
access to the portage tree.

"Clean cut" turns of cvs access on a given and announced timestamp,
rsync-generation/updates is suspended (no input ->  no changes), some
magic scripts prepare the git repo (according to [3], some hours
duration) and we all checkout the tree (might be some funny massive load).

"testing git-cvsserver" proses "Clean cut" with the additional ability
to continue using cvs update/commit, - in best case - on the old
checkout w/o alteration on the developers side.

"Clean cut" forces us to clean up out dirty checkouts (I have some
added directories, added ebuilds i hesitated to `repoman commit`).
Plus we have to alter all our hot-wired portage mangling scripts from
cvs'ish to git'ish (I use my read/write checkout as portage tree (cvs
checkout + egencache for checkout) and have an automated google-chrome
bump script). But this can be accomplished on a per developer basis,
and slackers don't stall the process.

"testing git-cvsserver" forces us all to test these cvs'ish scripts
and behaviours against a git-cvsserver and report.
We all know that this test-runs will never happen, stalling this bug
till infinity.
Plus infra/"subset of devs marshalling the migration" get stuck
between fixing git issues and git-cvsserver.

*if you still read this* *wow*

Please discuss my arguments and come to the conclusions to
RESO/WONT-FIX "testing git-cvsserver", make a "clean cut" and remove
this bug from the blockers of "[TRACKER] portage migration to git".

My lengthy 2 cents.

[1] https://bugs.gentoo.org/333531
[2] https://bugs.gentoo.org/333699
[3] https://bugs.gentoo.org/333705#c2
- --
Gentoo Dev
http://xmw.de/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk+82z0ACgkQknrdDGLu8JBUWAD/dmuqyES/mYDrMam+/txnHmgd
VaQaqwHMlwzzqQwbpY4A/0h+5Vp8sLbOE78k4SCaGE2dCQtmeOz0jd1YxkDzP+YW
=jXLQ
-END PGP SIGNATURE-



Another vote for clean cut.

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-sound/kid3: metadata.xml kid3-2.1.ebuild ChangeLog

[Michael Palimaka]

On 2012-06-07 23:06, Samuli Suominen wrote:

On 06/07/2012 04:06 PM, Michael Palimaka (kensington) wrote:

kensington 12/06/07 13:06:48

Modified: metadata.xml ChangeLog
Added: kid3-2.1.ebuild
Log:
Version bump. Add upstream metadata.

(Portage version: 2.1.10.65/cvs/Linux x86_64)

Revision Changes Path
1.5 media-sound/kid3/metadata.xml

file :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-sound/kid3/metadata.xml?rev=1.5&view=markup

plain:
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-sound/kid3/metadata.xml?rev=1.5&content-type=text/plain

diff :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-sound/kid3/metadata.xml?r1=1.4&r2=1.5


Index: metadata.xml
===
RCS file: /var/cvsroot/gentoo-x86/media-sound/kid3/metadata.xml,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- metadata.xml 21 Aug 2009 14:36:01 - 1.4
+++ metadata.xml 7 Jun 2012 13:06:48 - 1.5
@@ -3,4 +3,12 @@

kde
sound
+ 
+ Enable support for acoustic fingerprinting
plugin using
+ (media-libs/chromaprint)
+ 
+ 
+ http://sourceforge.net/tracker/?group_id=70849
+ kid3
+ 




1.61 media-sound/kid3/ChangeLog

file :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-sound/kid3/ChangeLog?rev=1.61&view=markup

plain:
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-sound/kid3/ChangeLog?rev=1.61&content-type=text/plain

diff :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-sound/kid3/ChangeLog?r1=1.60&r2=1.61


Index: ChangeLog
===
RCS file: /var/cvsroot/gentoo-x86/media-sound/kid3/ChangeLog,v
retrieving revision 1.60
retrieving revision 1.61
diff -u -r1.60 -r1.61
--- ChangeLog 19 May 2012 09:07:30 - 1.60
+++ ChangeLog 7 Jun 2012 13:06:48 - 1.61
@@ -1,6 +1,12 @@
# ChangeLog for media-sound/kid3
# Copyright 1999-2012 Gentoo Foundation; Distributed under the GPL v2
-# $Header: /var/cvsroot/gentoo-x86/media-sound/kid3/ChangeLog,v 1.60
2012/05/19 09:07:30 ssuominen Exp $
+# $Header: /var/cvsroot/gentoo-x86/media-sound/kid3/ChangeLog,v 1.61
2012/06/07 13:06:48 kensington Exp $
+
+*kid3-2.1 (07 Jun 2012)
+
+ 07 Jun 2012; Michael Palimaka  +kid3-2.1.ebuild,
+ metadata.xml:
+ Version bump. Add upstream metadata.

19 May 2012; Samuli Suominen  kid3-1.4.ebuild,
kid3-2.0.1.ebuild:



1.1 media-sound/kid3/kid3-2.1.ebuild

file :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-sound/kid3/kid3-2.1.ebuild?rev=1.1&view=markup

plain:
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-sound/kid3/kid3-2.1.ebuild?rev=1.1&content-type=text/plain


Index: kid3-2.1.ebuild
===
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/media-sound/kid3/kid3-2.1.ebuild,v
1.1 2012/06/07 13:06:48 kensington Exp $

EAPI=4
KDE_LINGUAS="cs de es et fi fr it nl pl ru sr sr@ijekavian
sr@ijekavianlatin sr@Latn tr zh_TW"
KDE_REQUIRED="always"
KDE_HANDBOOK="optional"
inherit kde4-base

DESCRIPTION="A simple tag editor for KDE"
HOMEPAGE="http://kid3.sourceforge.net/";
SRC_URI="mirror://sourceforge/${PN}/${P}.tar.gz"

LICENSE="GPL-2"
SLOT="4"
KEYWORDS="~amd64 ~x86"
IUSE="chroma flac mp3 mp4 +taglib vorbis"

RDEPEND="
chroma? (
media-libs/chromaprint
virtual/ffmpeg
)
flac? (
media-libs/flac[cxx]
media-libs/libvorbis
)
mp3? ( media-libs/id3lib )
mp4? ( media-libs/libmp4v2:0 )
taglib? ( media-libs/taglib )
vorbis? (
media-libs/libogg
media-libs/libvorbis
)"
DEPEND="${RDEPEND}"

REQUIRED_USE="flac? ( vorbis )"

src_configure() {
local mycmakeargs=(
$(cmake-utils_use_with chroma CHROMAPRINT)
$(cmake-utils_use_with flac)
$(cmake-utils_use_with mp3 ID3LIB)
$(cmake-utils_use_with mp4 MP4V2)
$(cmake-utils_use_with vorbis)
$(cmake-utils_use_with taglib)
"-DWITH_TUNEPIMP=OFF"
"-DWITH_KDE=ON"


No such flag as WITH_TUNEPIMP in 2.1 release anymore.

Good catch, thanks for noticing.



And the build system should now work so that USE="kde" can be added with
KDE_REQUIRED=optional.

I did test that, however was unable to make it work correctly. YMMV.



(I was writing ebuild for this too, and it looks very much like what you
have except these 2 issues.)

Great minds think alike. ;-)



- Samuli


Michael

[gentoo-dev] Patch: Linguas USE support for cmake-utils.eclass

[Michael Palimaka]

Hi,

A number of package using cmake and qmake currently do something like this:

LANGS="en de fr"
for x in ${LANGS}; do
IUSE="${IUSE} linguas_${x}"
done

This is ugly, so for some time the loop has been included in qt4-r2, and 
I'd also like to add it to cmake-utils.


As far as I can see, this change will have no visible effect on ebuilds 
that already manually include the loop, and will cause only one package 
to get linguas_* flags that it doesn't already have (which I'll fix).


Thoughts?

--- cmake-utils.eclass
+++ cmake-utils.eclass
@@ -20,0 +21,29 @@
+# @ECLASS-VARIABLE: LANGS
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# In case your application provides various translations, use this 
variable to specify
+# them in order to populate "linguas_*" IUSE automatically. Make sure 
that you set this

+# variable before inheriting cmake-utils eclass.
+# Example:
+# @CODE
+#   LANGS="en el de"
+# @CODE
+for x in ${LANGS}; do
+   IUSE+=" linguas_${x}"
+done
+
+# @ECLASS-VARIABLE: LANGSLONG
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# Same as above, but this variable is for LINGUAS that must be in long 
format.

+# Remember to set this variable before inheriting cmake-utils eclass.
+# Look at ${PORTDIR}/profiles/desc/linguas.desc for details.
+# Example:
+# @CODE
+#   LANGS="de_DE hu_HU"
+# @CODE
+for x in ${LANGSLONG}; do
+   IUSE+=" linguas_${x%_*}"
+done
+unset x
+

Best regards,
Michael

[gentoo-dev] Re: Patch: Linguas USE support for cmake-utils.eclass

[Michael Palimaka]

On 2012-06-24 18:34, Ben de Groot wrote:

We at qt@ have been discussing this on and off. We would like to
see a linguas.eclass happen, because already now we start having
code duplication. So instead of this duplication of code between
qt4-r2 and cmake-utils eclasses, why not put this into a separate
linguas.eclass that both can inherit?

>
> Obviously the problem with handling more than just setting IUSE
> is the variety of ways in which linguas are handled by different
> packages and different build systems.

I agree that linguas.eclass is a good idea, but how possible is it to 
incorporate the various build systems, and the various approaches used 
by each package?


If you have some ideas, I'm more than happy to help.

[gentoo-dev] Re: Patch: Linguas USE support for cmake-utils.eclass

[Michael Palimaka]

On 2012-06-24 18:48, Michał Górny wrote:

Of course, another question is whether LINGUAS does actually benefit
users. If compiling another .po files takes a lot of time, probably
yes. If it doesn't, I would think about getting rid of that and just
installing everything. Additional removal can be handled through
INSTALL_MASK.



I personally dislike installing numerous files that are useless to me 
and enjoy the visibility the use flag gives.

I know this is not for everyone - I offer it as an option only.

[gentoo-dev] Re: euscan GSoC project - requesting feedback

[Michael Palimaka]

On 2012-06-27 17:51, Federico "fox" Scrinzi wrote:

Hi everybody!

I'm working on a GSoC project for enhancing Euscan
(http://euscan.iksaif.net/). Euscan allows to check if a given
package/ebuild has new upstream versions or not. It uses different
heuristic to scan upstream and grab new versions and related urls.
Euscan has a web interface for surfing data but for now is only possible
to see the scan results per package/category/herd/maintainers/overlay.
We're working now on the possibility to register and provide a cool
dashboard for maintainers, so that they can easily keep an eye on the
upstream versions of the packages they maintain.

The main question is: what would you like to have on this dashboard?
Currently (in the development version) there's the possibility to login
and watch/unwatch packages/categories/herds/... and see the watched
stuff in the account dashboard. We're planning on implementing a
weekly(?) custom newsletter based on the packages you're watching, which
features would you like?

The project repo for the GSoC is here: https://github.com/volpino/euscan

Thanks!



Looking forward to seeing the improvements. :)

I'd like to see the information regarding current tree state updated 
more regularly than the full upstream scan. Especially when looking at 
the herd view, it can be hard to keep track of which bumps have already 
been completed.

[gentoo-dev] Last rites: net-misc/ssh-installkeys

[Michael Palimaka]

# Michael Palimaka  (15 Jul 2012)
# Bundles dev-python/pexpect (bug #315843)
# Replaced by ssh-copy-id from net-misc/openssh.
# Removal in 30 days.
net-misc/ssh-installkeys

[gentoo-dev] Re: Portage FEATURE suggestion - limited-visibility builds

[Michael Palimaka]

Autodep[1][2] is a current implementation of this idea, with library 
hook and FUSE options.


Would definitely love to see more development in this area. :)

[1]: https://dev.gentoo.org/~neurogeek/guidexml/
[2]: http://git.overlays.gentoo.org/gitweb/?p=proj/autodep.git;a=summary

[gentoo-dev] Last rites: dev-util/cccc

[Michael Palimaka]

# Michael Palimaka  (7 Aug 2012)
# Fails to build with GCC 4.7 (bug #430250)
# Bundles utilities from dev-util/pccts
# Dead upstream. Removal in 30 days.
dev-util/

[gentoo-dev] Re: About changing security policy to unCC maintainers when their are not needed

[Michael Palimaka]

On 2012-09-13 03:59, Pacho Ramos wrote:

Hello

Currently, package maintainers are CCed to security bugs when their are
needed. The problem is that, once maintainers add a fixed version and
tell security team they are ok to get it stabilized, maintainers are
kept CCed until bug is closed by security team. This usually means
getting a lot of mail after some time when security team discuss if a
GLSA should be filled or not, if security bot adds some comment... some
of that comments are applied to really old bugs that need no action from
maintainers.

Maybe would be interesting to change the policy to unCC maintainers
again when their action is no longer required.

What do you think?

Thanks for your thoughts



Hello,

Is the policy you describe officially documented, or just current behaviour?

In KDE and Qt herds for example, we usually just unCC ourselves when 
we've taken the required action.


Best regards,
Michael

[gentoo-dev] Last rites: net-libs/libwww

[Michael Palimaka]

# Michael Palimaka  (18 Oct 2012)
# md5 module breaks on 64-bit through improper types (bug #320253),
# libwww-config fails to mention libssl (bug #327377),
# poor programming practices (bug #259287).
# Dead upstream, masked for removal in 30 days.
net-libs/libwww

[gentoo-dev] Merging the devrel handbook into the devmanual

[Michael Palimaka]

Hi all,

In bug #304435[1], hwoarang suggested merging the devrel handbook[2] 
into the devmanual[3].


As the project has grown, so has the amount - and dispersion - of 
development information. I believe consolidation of this information 
into a single point will make everyone's (especially new developers) 
lives easier.


What do you think?

Best regards,
Michael

[1]: https://bugs.gentoo.org/show_bug.cgi?id=304435
[2]: http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml
[3]: http://devmanual.gentoo.org/

[gentoo-dev] Documenting touching of arch profiles' files

[Michael Palimaka]

Hi all,

With regards to bug #304435[1], we would like to formalise the policy 
for touching arch profiles' files.


The key suggested points:

* Archs profiles should generally only be touched by members of that 
arch team, unless prior permission is given


* Exception: anyone may add a mask to an arch profile only if
	- it delays visibility of something new for that arch (eg. dependencies 
introduced in a version bump), and
	- it is not reasonable to follow the standard keyword dropping 
procedure (many other packages would be affected), and

- the responsible arch team is not responsive

* The person touching arch profiles is responsible for the subsequent 
maintenance of said entries, and any subsequent breakage.


Thoughts?

Best regards,
Michael

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

[gentoo-dev] Re: gentoo-x86 commit in profiles: ChangeLog package.mask

[Michael Palimaka]

Hi,

On 2012-11-11 18:44, Mike Frysinger (vapier) wrote:

--- package.mask11 Nov 2012 02:03:39 -  1.14217
+++ package.mask11 Nov 2012 07:44:58 -  1.14218
-# Michael Weber  (9 Jun 2012)
-# The mentioned versions fail to assemble raid 0/1/5 devices.
-# As reported in bug 416081 users end up with multiple raids
-# all consiting of single drives. disk/by-uuid is preseved
-# for single disks, so users end up with auto-mounted raids
-# effectivly running on single disks.
-# @base-system feel free to re-evaluate the severeness of this
-# regression and drop the mask. Masked for now.
-=sys-fs/mdadm-3.2.5-r1


Why was this mask removed?

This is a serious bug that remains unfixed - in my case I had to use a 
livecd and downgrade before I could even boot again.


Best regards,
Michael

[gentoo-dev] Last rites: dev-libs/safestr and dev-libs/xxl

[Michael Palimaka]

# Michael Palimaka  (02 Feb 2017)
# Upstream missing. Ancient. Unmaintained. No revdeps.
# Masked for removal in 30 days.
dev-libs/safestr
dev-libs/xxl

[gentoo-dev] Last rites: games-arcade/mari0 and games-action/openlierox

[Michael Palimaka]

# Michael Palimaka  (12 Feb 2017)
# Potential licensing issues. Masked for removal in 30 days.
# Bug 608954 and 609052
games-arcade/mari0
games-action/openlierox

[gentoo-dev] Last rites: sys-power/cpudyn

[Michael Palimaka]

# Michael Palimaka  (12 Feb 2017)
# Dead upstream. Unmaintained. Problems with multicode CPUs.
# Masked for removal in 30 days.
sys-power/cpudyn

[gentoo-dev] Last rites: media-libs/iulib

[Michael Palimaka]

# Michael Palimaka  (12 Feb 2017)
# Build failures. Dead upstream. No revdeps. Unmaintained.
# Masked for removal in 30 days. Bug #594826 and 597872.
media-libs/iulib

[gentoo-dev] Last rites: media-libs/FusionSound

[Michael Palimaka]

# Michael Palimaka  (18 Feb 2017)
# Fails to build. Use dev-libs/DirectFB[fusionsound] instead.
# Bug #602674, 543728, 542000, 456770. Masked for removal in 30 days.
media-libs/FusionSound

[gentoo-dev] Last rites: net-ftp/bareftp

[Michael Palimaka]

# Michael Palimaka  (18 Feb 2017)
# Fails to build. Bug #608940. Masked for removal in 30 days.
net-ftp/bareftp

[gentoo-dev] Last rites: net-news/blam and dev-dotnet/webkit-sharp

[Michael Palimaka]

# Michael Palimaka  (18 Feb 2017)
# Requires a dead and vulnerable webkit-gtk version. Bug #608602.
# Masked for removal in 30 days.
dev-dotnet/webkit-sharp
net-news/blam

[gentoo-dev] Last rites: dev-util/weblint

[Michael Palimaka]

# Michael Palimaka  (18 Feb 2017)
# Fails at runtime. Dead upstream. Unmaintained. Bug #602008.
# Masked for removal in 30 days.
dev-util/weblint

[gentoo-dev] Last rites: sys-fs/udisks-glue

[Michael Palimaka]

# Michael Palimaka  (18 Feb 2017)
# Dead upstream. Relies on dead udisks:0. Bug #601356.
# Masked for removal in 30 days.
sys-fs/udisks-glue

[gentoo-dev] Last rites: x11-terms/valaterm

[Michael Palimaka]

# Michael Palimaka  (18 Feb 2017)
# Dead upstream. Relies on vala slot. Unmaintained. Bug #601346.
# Masked for removal in 30 days.
x11-terms/valaterm

[gentoo-dev] Last rites: x11-misc/bbappconf

[Michael Palimaka]

# Michael Palimaka  (19 Feb 2017)
# Doesn't work. Dead upstream. Unmaintained.
# Masked for removal on 30 days. Bug #609754.
x11-misc/bbappconf

[gentoo-dev] Last rites: x11-misc/xrmap

[Michael Palimaka]

# Michael Palimaka  (22 Feb 2017)
# Fails to build. Dead upstream.
# Masked for removal in 30 days. Bug #520890.
x11-misc/xrmap

[gentoo-dev] Last rites: x11-misc/oroborus-desklaunch

[Michael Palimaka]

# Michael Palimaka  (03 Mar 2017)
# Segfaults at runtime. Dead upstream. Unmaintained.
# Masked for removal in 30 days. Bug #611406.
x11-misc/oroborus-desklaunch

[gentoo-dev] Packages up for grabs

[Michael Palimaka]

Due to a retiring proxied maintainer, these packages are now up for grabs:

dev-python/python-gammu
net-irc/inspircd

[gentoo-dev] Last rites: dev-scheme/schoca

[Michael Palimaka]

# Michael Palimaka  (11 Mar 2017)
# Fails to build. Dead upstream.
# Masked for removal in 30 days. Bug #592184.
dev-scheme/schoca

[gentoo-dev] Last rites: net-p2p/phxd

[Michael Palimaka]

# Michael Palimaka  (18 Mar 2017)
# Fails to run. Ancient. Unmaintained. Dead upstream.
# Masked for removal in 30 days. Bug #605120.
net-p2p/phxd

[gentoo-dev] Last rites: gnome-extra/zeitgeist-datasources

[Michael Palimaka]

# Michael Palimaka  (18 Mar 2017)
# Broken. Dead upstream. Unmaintained.
# Masked for removal in 30 days. Bug #604836.
gnome-extra/zeitgeist-datasources

[gentoo-dev] Last rites: net-misc/apt-proxy

[Michael Palimaka]

# Michael Palimaka  (18 Mar 2017)
# Broken. Dead upstream. Unmaintained.
# Masked for removal in 30 days.
net-misc/apt-proxy

[gentoo-dev] Last rites: app-editors/vim-qt

[Michael Palimaka]

# Michael Palimaka  (23 Apr 2017)
# Doesn't work with any in-tree versions of vim. Inactive upstream.
# Bug 607136. Masked for removal in 30 days.
app-editors/vim-qt

[gentoo-dev] Last rites: sci-mathematics/freemat

[Michael Palimaka]

# Michael Palimaka  (04 Jun 2017)
# Relies on obsolete and vulerable qtwebkit version. Dead upstream.
# Masked for removal in 30 days. Bug #620752.
sci-mathematics/freemat

[gentoo-dev] Last rites: www-client/qtweb

[Michael Palimaka]

# Michael Palimaka  (04 Jun 2017)
# Relies on obsolete and vulerable qtwebkit version. Dead upstream.
# Masked for removal in 30 days. Bug #620758.
www-client/qtweb

[gentoo-dev] Re: Gentoo Council 2017 / 2018 election

[Michael Palimaka]

On 06/17/2017 03:56 AM, Alice Ferrazzi wrote:
> I nominate:
> 
> blueness
> gokturk
> maffblaster
> kensington
> mrueg
> Soap
> mgorny
> 
> -- 
> アリス フェッラッツィ
> Alice Ferrazzi
> 
> Gentoo Kernel Project Leader
> Mail: Alice Ferrazzi mailto:ali...@gentoo.org>>
> PGP: 2E4E 0856 461C 0585 1336 F496 5621 A6B2 8638 781A

Thanks, but I decline.

[gentoo-dev] Last rites: media-sound/ams

[Michael Palimaka]

# Michael Palimamka  (18 Jun 2017)
# Fails to build with uncoming stable Qt 5.7. Dead upstream.
# Masked for removal in 30 days. Bug #603564.
media-sound/ams

[gentoo-dev] Last rites: app-cdr/acetoneiso

[Michael Palimaka]

# Michael Palimaka  (01 Jul 2017)
# Depends on vulnerable qtwebkit:4. Dead upstream.
# Masked for removal in 30 days. Bug #620688.
app-cdr/acetoneiso

[gentoo-dev] Last rites: kde-misc/semantik

[Michael Palimaka]

# Michael Palimaka  (01 Jul 2017)
# Depends on vulnerable qtwebkit:4. Dead upstream.
# Masked for removal in 30 days. Bug #620700.
kde-misc/semantik

[gentoo-dev] Last rites: media-gfx/smile

[Michael Palimaka]

# Michael Palimaka  (01 Jul 2017)
# Depends on vulnerable qtwebkit:4. Dead upstream.
# Masked for removal in 30 days. Bug #620704.
media-gfx/smile

[gentoo-dev] Last rites: media-gfx/picturewall

[Michael Palimaka]

# Michael Palimaka  (01 Jul 2017)
# Depends on vulnerable qtwebkit:4. Dead upstream.
# Masked for removal in 30 days. Bug #620836.
media-gfx/picturewall

[gentoo-dev] Last rites: app-office/calligra-l10n

[Michael Palimaka]

# Michael Palimaka  (06 Jul 2017)
# Obsolete. l10n is now included in app-office/calligra:5.
# Masked for removal in 30 days. Exported to kde-sunset overlay.
app-office/calligra-l10n

[gentoo-dev] Re: Sets vs Meta ebuilds

[Michael Palimaka]

On 07/08/2017 02:48 AM, NP-Hardass wrote:
> On 07/07/2017 12:32 PM, William L. Thomson Jr. wrote:
>> I have been playing with some package sets and I like the concept of
>> sets quite a lot. However there is one big drawback. You cannot use a
>> package set in a profile. Or at least I do not think you can. I have
>> looked into it a bit and does not seem like it is possible.
>>
>> I know I can create a meta ebuild and use it like a package set. I
>> think it would be useful to have package sets be able to be used in a
>> profile like meta ebuilds. It would likely reduce the need or use of
>> meta packages. Not sure if there is any benefit to that approach over a
>> set.
>>
>> I think sets have benefits over meta packages. This was the most
>> comprehensive document on sets, benefits, uses, etc. Other than the
>> general docs on the wiki.
>> https://makuro.wordpress.com/2010/12/12/intro-to-portage-sets/
>>
>> I  would really like to be able to use package sets in profiles. I
>> think of use and benefit to others as well.
>>
> 
> There is actually a huge functional difference between the two that you
> are missing here.  A meta package defines its dependencies in full
> dependency syntax.  This means you can specify versions, USE flag
> dependencies, make packages dependent on USE flags, etc.  A package set
> is just a list of packages (potentially constrained by version.  TTBOMK,
> there is no inclusion of any USE flag functionality in sets.
> Additionally, let's say you have a more complicated dependency like || (
> A B ),  I don't think there is a way to describe that in a package set
> at all.

Bug #272488[0] proposed a PROPERTIES="set" feature to combine the power
of sets with the flexibility of ebuilds.

1: https://bugs.gentoo.org/show_bug.cgi?id=272488

[gentoo-dev] Re: About adding a *warning* to remind maintainers to check for new PYTHON_COMPAT values

[Michael Palimaka]

On 07/10/2017 11:35 PM, Kent Fredric wrote:
> On Mon, 10 Jul 2017 13:43:43 +0200
> Pacho Ramos  wrote:
> 
>> Yes, but it's similar as the cases when we need to fix our packages
>> to work with a newer library they depend on. In this case it would be
>> even easier as we can have multiple python versions and switch to the
>> newer one for testing while going back to the stable one (if
>> preferred) later.
>>
> 
> I'm starting to think we need a collection of QA scripts in a repo
> somewhere, optimized for symlinking into /etc/portage/hooks/install/
> 
> And make it standard practice for:
> 
> - Gentoo Devs to have those scripts
> - Tinderboxers' to have those scripts
> 
> That's going to be the only way we can get these warnings in ways
> *developers* will see them, but: 
> 
> 1. Won't needlessly clutter stable users systems
> 2. Won't produce loads of ebuild bumps that do waves of metadata
> updates for things that don't affect end users.
> 
> Presently the only things *like* this require hard-coded QA logic into
> portage itself, which, while useful, pulls us back to the whole problem
> where it might affect users, and becomes tightly coupled to portage's
> release cycle.
> 
> We could however make things simpler, and have a package that installs
> these QA hacks into the hooks dir for us, and then it would be a matter
> of simply installing them via opt-in
In addition to the checks that are bundled, Portage already natively
supports custom post-install QA checks in:

* /usr/local/lib/install-qa-check.d
* /usr/lib/install-qa-check.d
* $REPO/metadata/install-qa-check.d

It's just a matter of someone writing and shipping them. I've been very
slowly preparing a collection based on the common type of tinderboxing
bugs that are filed and porting parts of lintian, but I haven't finished
yet.

[gentoo-dev] Re: stabilization candidates, July 2017

[Michael Palimaka]

On 07/10/2017 06:41 PM, Paweł Hajdan, Jr. wrote:
> Hey folks,
> 
> If you'd like to help Gentoo stable be more up to date, please read on.
> 
> See
> 
> for potential stabilization candidates (over 1000 of them).
> 
> These are automatically checked to pass repoman, and bugzilla is also
> checked for bugs. Only ebuilds not modified in last 30 days are considered.
> 
> Feel free to check out 
> for the script(s) which generate this. It's a project I've been working
> on throughout 2011-2014, and might now work more on it.
> 
> Feedback about next steps would be welcome.
> 
> Paweł
> 

This worked really well in the past - I hope you decide to continue this
great work.

I have two suggestions:

1. Put out a call for updated blacklist requests. This will help avoid
(a) whinging from the vocal minority who are terribly offended by this
sort of thing, and (b) unnecessary requests for sets of packages that
are managed in bulk eg. certain kde and qt categories

2. Please update the bug filing script to use the new bugzilla
components and package list fields - these are now essential to getting
prompt service from arch teams

[gentoo-dev] Re: taking a break from arches stabilization

[Michael Palimaka]

On 07/11/2017 09:29 AM, Andrew Savchenko wrote:
> On Mon, 10 Jul 2017 22:17:34 +0200 Kristian Fiskerstrand wrote:
>> On 07/10/2017 10:02 PM, Rich Freeman wrote:
>>> On Mon, Jul 10, 2017 at 3:57 PM, Andrew Savchenko  
>>> wrote:

 On Mon, 10 Jul 2017 13:49:40 -0400 Rich Freeman wrote:

> In the case of amd64 we already
> encourage individual package maintainers to stabilize their own
> packages

 Huh? Have our rules changed? As per devmanual[1] and GLEP 40[2]
 stabilization must be carried out by arch teams, unless a special
 arrangement is done between a developer and a team.

>>>
>>> The docs are probably out of date - I'm not sure if the policy is
>>> documented anywhere.  However it has been a fairly longstanding policy
>>> at this point that amd64 allows individual maintainers to stabilize
>>> their own packages.
>>>
>>
>> We looked after it for wg-stable (which died out as a result of rather
>> low participation, maybe it should be rebooted if people feel like
>> discussing this again), there isn't any authoritative policy allowing
>> it, GLEP:40 explicitly removes the possibility to do it for x86. That
>> said, for a number of packages maintainer stabilization can likely make
>> sense, the opposite view is four-eyes principle, it is always good to
>> have someone else build-test etc, but this is greatly helped by
>> tinderboxing efforts (thanks toralf) etc. So one likely output if
>> wg-stable is to come up with something would be a replacement GLEP for
>> 40 that matches the current state, and also kernel auto-stabiliation (as
>> discussed in [section 3.2 (Kernel)]
> 
> So, am I understanding this correctly that right now a package
> stabilization by maintainer without explicit permit from an arch
> team will be the violation of active and approved policies?

As Rich pointed out, amd64 team has long allowed maintainers to perform
their own stabilisations. I've asked x86 team about this in the past,
and they too were OK with maintainer stabilisations.

It would be nice to improve documentation of this, but it is certainly
not a policy violation just because some ancient document was never updated.

> Despite the maintainer-driven stabilization seems to be "a fairly
> longstanding policy" I'm reluctant to do such stabilization myself,
> because anyone may point out later that such action is a violation
> of the written policies and I will have nothing to defend me.
> 
> Even if such stabilization is allowed, there are unanswered
> questions here:
> - is following seciton 4.1 from wg recommendations is sufficient?
> - should developer test each stabilization candidate on an
> up-to-date stable setup?

The guidelines from that document are ripped straight out of the
devmanual and are a good starting point but rather generic. You can find
some more detailed suggestions on things to consider while testing on
the wiki: https://wiki.gentoo.org/wiki/Package_testing

[gentoo-dev] Re: taking a break from arches stabilization

[Michael Palimaka]

On 07/11/2017 11:06 PM, Rich Freeman wrote:
> On Tue, Jul 11, 2017 at 8:59 AM, Michael Palimaka  
> wrote:
>> On 07/11/2017 09:29 AM, Andrew Savchenko wrote:
>>>
>>> Even if such stabilization is allowed, there are unanswered
>>> questions here:
>>> - is following seciton 4.1 from wg recommendations is sufficient?
>>> - should developer test each stabilization candidate on an
>>> up-to-date stable setup?
>>
>> The guidelines from that document are ripped straight out of the
>> devmanual and are a good starting point but rather generic. You can find
>> some more detailed suggestions on things to consider while testing on
>> the wiki: https://wiki.gentoo.org/wiki/Package_testing
>>
> 
> I think that in practice arch teams don't do have the stuff on that
> wiki page.  Maybe some people do, but back when I was an amd64 AT I
> don't think anybody went testing multiple USE combinations for a
> typical package.

Everything on that page is deliberately a suggestion only, and not
necessarily specific to stabilisation testing.

In the end, we've never been able to reach any consensus on what exactly
an arch tester should do. Personally, I think we should just switch to
fully-automated, build-only testing for stabilistions unless the
maintainer opts otherwise (something that largely happens in practice
already). The main risk of breakage of a package moving from testing to
stable is always at build time anyway.

[gentoo-dev] Re: taking a break from arches stabilization

[Michael Palimaka]

On 07/12/2017 12:13 AM, Kristian Fiskerstrand wrote:
> On 07/11/2017 03:47 PM, Michael Palimaka wrote:
>> The main risk of breakage of a package moving from testing to
>> stable is always at build time anyway.
> 
> citation needed
> 

Based on my experience doing package testing in stabilisation work. Feel
free to provide citations (or complete sentences) to the contrary.

[gentoo-dev] Re: taking a break from arches stabilization

[Michael Palimaka]

On 07/12/2017 12:15 AM, Kristian Fiskerstrand wrote:
> On 07/11/2017 04:13 PM, Kristian Fiskerstrand wrote:
>> On 07/11/2017 03:47 PM, Michael Palimaka wrote:
>>> The main risk of breakage of a package moving from testing to
>>> stable is always at build time anyway.
>>
>> citation needed
>>
> 
> Anecdotal evidence against, currently gnupg 2.1.21 scdaemon bug will
> happily sign a third party public keyblock's UID using signature subkey
> on smartcard, which results in useless signature that doesn't have any
> effect, but the application builds fine.
> 
> This means gnupg 2.1.21 is not a candidate for stabilization, but it
> certainly builds fine.
> 

Stop trolling - you know perfectly well that this sort of issue would
never ever be caught during arch testing. Nor should it be - it's called
*arch* testing for a reason.

Ensuring that a package's functionality is of merchantable quality is
the maintainer's responsibility (that's you!).

[gentoo-dev] Re: taking a break from arches stabilization

[Michael Palimaka]

On 07/12/2017 12:25 AM, James Le Cuirot wrote:
> On Tue, 11 Jul 2017 16:15:51 +0200
> Kristian Fiskerstrand  wrote:
> 
>> On 07/11/2017 04:13 PM, Kristian Fiskerstrand wrote:
>>> On 07/11/2017 03:47 PM, Michael Palimaka wrote:  
>>>> The main risk of breakage of a package moving from testing to
>>>> stable is always at build time anyway.  
>>>
>>> citation needed
>>>   
>>
>> Anecdotal evidence against, currently gnupg 2.1.21 scdaemon bug will
>> happily sign a third party public keyblock's UID using signature
>> subkey on smartcard, which results in useless signature that doesn't
>> have any effect, but the application builds fine.
>>
>> This means gnupg 2.1.21 is not a candidate for stabilization, but it
>> certainly builds fine.
> 
> This is a good opportunity to remind ourselves what stable means. Are
> we referring exclusively to our packaging or are upstream issues taken
> into account too? 30 days seems like a reasonable time for any upstream
> issues to be reported. Unfortunately security issues mean that new
> releases sometimes get stabilised immediately. Ideally these releases
> would carry just the security fixes but that isn't always the case.
> 

I think we should consider both our packaging as well as upstream
issues, and I agree that for most packages 30 days in ~arch is enough
time to smoke out upstream issues.

[gentoo-dev] Re: taking a break from arches stabilization

[Michael Palimaka]

On 07/12/2017 07:26 AM, Kristian Fiskerstrand wrote:> That presumes that
the maintainer is the one calling for the
> stabilization, and it is not an automated procedure simply due to 30
> days in ~arch. In this particular case, look for the number of bug
> reports filed in Gentoo for the issue.

All of the past automated stabilisation request initiatives did look for
open bugs against a package before filing any request.

> 
> But the main risk is certainly not built testing, it is breaking
> operational live stable systems.

I'm not sure exactly what you mean by this. Build testing is a process
and not a risk. When ebuilds are moved to stable, there's risk of
breakage at both build time and runtime.

Most runtime issues will either be known by the maintainer (who can then
block the stabilisation) or smoked out during the usual ~arch waiting
period.

Build time issues are more tricky. One of the reasons we have arch
testers is to ensure that something that built fine in ~arch will still
build fine on an otherwise stable system.

I've encountered a number of ebuilds marked stable that failed to build
on an all-stable system but built fine on an all-testing system. I've
never encountered a single ebuild that failed to run correctly on an
all-stable system but ran fine on an all-testing system.

I don't think it's practical to demand detailed runtime testing by an
arch tester for every stabilisation request (which we know doesn't
happen in practice anyway). There's also many packages where it may be
prudent to do more than just build testing.

I think the answer lies somewhere in the middle. We need to recognise
that we have very limited arch testing resources and focus them where it
will have the most impact. We have a "runtime testing required" field on
stable bugs now - let's use it, and let's be smart about it. Looking at
the current open bugs, I see some good examples where runtime testing
was requested (eg. sys-devel/gcc-config) and some examples where I
really question what value we get from an arch tester's time (eg.
app-text/htmldoc).

> Nowhere was it claimed that the arc
> testers are responsible for it, but it certainly doesn't coincide, at
> any point, with "The main risk of breakage of a package moving from
> testing to stable is always at build time anyway."
In a previous post you stated:
> currently gnupg 2.1.21 scdaemon bug will
> happily sign a third party public keyblock's UID using signature subkey
> on smartcard, which results in useless signature that doesn't have any
> effect, but the application builds fine.
>
> This means gnupg 2.1.21 is not a candidate for stabilization, but it
certainly builds fine.

If it's not a stable candidate then why do you use this as an example
against build testing-based stabilisations? If there are known issues it
should never reach the arch teams in the first place.

[gentoo-dev] Re: [RFC pre-GLEP] Gentoo Git Workflow

[Michael Palimaka]

On 07/25/2017 06:05 PM, Michał Górny wrote:
> Hi, everyone.
> 
> There have been multiple attempts at grasping this but none so far
> resulted in something official and indisputable. At the same time, we
> end having to point our users at semi-official guides which change
> in unpredictable ways.
> 
> Here's the current draft:
> https://wiki.gentoo.org/wiki/User:MGorny/GLEP:Git

This looks really nice, thanks for working on it.

> * When doing a minor change to a large number of packages, it is
> reasonable to do so in a single commit. However, when doing a major
> change (e.g. a version bump), it is better to split commits on package
> boundaries.

In some cases we do prefer to make major changes on a set of related
package all in one commit. For example, we always bump the 240+ KDE
Applications collection together because that's how it's released.

> ===Commit messages===
> A standard git commit message consists of three parts, in order: a
> summary line, an optional body and an optional set of tags. The parts
> are separated by a single empty line.
> 
> The summary line is included in the short logs (git log --
> oneline, gitweb, GitHub, mail subject) and therefore should
> provide a short yet accurate description of the change. The summary line
> starts with a logical unit name, followed by a colon, a space and a
> short description of the most important changes. If a bug is associated
> with a change, then it should be included in the summary line as
> #nn or likewise. The summary line must not exceed 69
> characters, and must not be wrapped.

Does a bug # really need to always be in the summary line? It can eat
valuable characters and tags which are pretty popular are equally valid IMO.

> ** Bug: https://bugs.gentoo.org/NN; — to
> reference a bug,
> ** Closes: https://github.com/gentoo/gentoo/pull/ ki>; — to automatically close a GitHub pull request,
> ** Fixes: https://bugs.gentoo.org/NN; —
> to indicate a fixed bug,

grepping the git log shows that 'Gentoo-bug' is much more common than
plain 'Bug'. 'Fixes' is hardly used at all, and I think it's a bit
confusing to use this for bugs as well as commits.

> a few branches on the repository, and did not maintain them. The Infra
> had to query the developers about the state of the branches and clean
> them up.

Should 'The Infra' be 'The Infra team' or just 'Infra'?

> Gentoo developers are still frequently using Gentoo-Bug tag,
> sometimes followed by Gentoo-Bug-URL. Using both
> simultaneously is meaningless (they are redundant), and using the former
> has no advantages over using the classic #nn form in the
> summary or the body.

I agree that using both is redundant, but I don't agree with
discouraging or banning the use of 'Gentoo-bug'. If someone prefers to
use it so it sits nicely with the other tags why stop them?

[gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Michael Palimaka]

On 07/25/2017 07:22 AM, Sergei Trofimovich wrote:
> 2. Q: How to make arch testing faster and easier?
> 
>A: - KEYWORDREQ/STABLEREQ bugs not marked as "runtime testing
> required" will be automatically tested and keyworded.
> 
> [handwave] automated tinderbox setup would help a lot
> to now upfront what fails to built, fails tests.

I've had similar thoughts about this and have already been working on
some tooling for this.

We would need to establish exactly what criteria must be met for an
automated test to be considered as successful.

Here's a sample report that my tool produces:
https://dev.gentoo.org/~kensington/tinderbox/sys-apps/dbus/dbus-1.6.18-r1/df017e14-bd68-47e2-9738-554e7ba1cf10.html

In this case, would it be enough that it builds and tests pass? What
about the QA issues? Do we need someone to review them to determine if
they should block stabilisation, or if they're even a regression or not?

[gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Michael Palimaka]

On 07/25/2017 05:22 PM, Dirkjan Ochtman wrote:
> First, the assumption in our processes seems to be that many or
> important bugs will be due to architecture-specific differences, and I
> wonder if that assumption really holds up. Do arch testers for a smaller
> arch often find problems that were not noticed on one of the larger
> arches? With the languages and tools that we have today, it seems like
> for many of our packages, bugs due to architectural differences
> represent a minority of the problems we found. In this case, the whole
> idea of per-arch stabilization does not really make sense, and doing
> away with that idea could drastically shortcut our process.

This would be really interesting to know.

> Second, I believe a lot of the value in our stable tree comes *just*
> from the requirement that stabilization is only requested after 30 days
> without major bugs/changes in the unstable tree. Assuming there are
> enough users of a package on unstable, that means important bugs can be
> shaken out before a version hits stable. This could mean that
> potentially, even if we inverted our entire model to say we
> "automatically" stabilize after a 30-day period without major bugs, we
> hit most of the value of the stable tree with again drastically reduced
> pain/work.

The 30 day waiting period is useful for smoking out major upstream bugs,
but can't replace stabilisation integration testing. For example,
package foobar may build fine in ~arch but fails in stable because it
needs a newer libbaz.

[gentoo-dev] Re: sys-boot/plymouth needs major fixes/maintainer

[Michael Palimaka]

On 08/05/2017 12:37 AM, Mart Raudsepp wrote:
> On R, 2017-08-04 at 14:23 +, Lucas Ramage wrote:
>> I am looking into this for openrc. I copied it over to my personal
>> overlay.
> 
> Ok, how about I mark myself as maintainer then and add you as co
> -maintainer for OpenRC aspects, and you can e-mail me fixes for openrc
> or otherwise?
> sys-boot/plymouth-openrc-plugin is involved in that OpenRC support too
> still, right?
> 
> I'm not sure about
> kde-plasma/breeze-plymouth
> kde-plasma/plymouth-kcm
> do you use KDE/Plasma to care for those too?

These two are still maintained by KDE team, they just got masked
(without asking by the way...) because they depend on plymouth.

[gentoo-dev] Re: Gentoo QA Help

[Michael Palimaka]

On 08/11/2017 12:30 AM, Michael Mair-Keimberger wrote:
> Hi Gentoo Team,
> 
> As some of you may noticed i started to clean up some old patches in the
> gentoo portage tree. I did so already a while ago, and like before I'm
> using a small script in order to identify unused patches.

I just wanted to say thank-you for all your work on this. I certainly
appreciate how much cleaner the tree is from your 1000+ commits, and I'm
sure others do to.

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

[Michael Palimaka]

On 08/12/2017 09:50 AM, Michael Orlitzky wrote:
> Q. But what about the rebuilds?
> 
>   For most packages, the rebuilds simply don't matter. Unless you're
>   the maintainer of libreoffice, firefox, chromium, etc. -- just do the
>   revision and forget about the (quick) rebuilds.

I really wish people would stop trotting out this false argument. Not
everyone has the latest and greatest hardware. Rebuilds have a real cost
to end users and as such we should use them wisely.

>   We tell everyone to use --changed-use and --newuse if they want
>   things to work, so they were probably going to rebuild anyway.

Who tells everyone to use these flags and where? I never use these flags
day-to-day, only if I need that specific functionality for that reason

> Q. But what if I maintain firefox, and I need to change  IUSE?
> 
>   If the IUSE change isn't important, just make the new revision in a
>   branch and wait to commit it later when there are more changes
>   piled up. If it is important (like if its default value changes
>   RDEPEND), then it would have required a revision anyway.

Please stop trying to force workflows on people. Using that same logic,
I can make the IUSE change in-place and it would be propagated in the
next version bump.

> Q. But I work on a team, and we can't all work in different branches.
> 
>   If you work on a massive package and if you're collaborating with
>   others regularly, you can commit the new ebuild masked. This is
>   annoying, but is an extremely rare combination of circumstances.

Again, let's not try and tell teams which workflow works best for them.

> == tl;dr ==
> 
> We would be better off with respect to IUSE changes and revisions if we
> deleted the --changed-use and --newuse flags right now, and just
> required developers to revbump when changing IUSE.
> 
> Package managers get simpler, documentation gets simpler, the user
> interface gets simpler, and behavior becomes more uniform and predictable.
> 
> Please let me know what you think.

I disagree with this change because your proposed benefits don't hold up:

>   * We can delete all of the PM code for --changed-use and --newuse and
> friends.

As pointed out by Brian, we still need at least --changed-use even if
IUSE changes in-place are banned.

>   * The documentation becomes much simpler: revbump if IUSE changes.

We should base our policies around the cost / benefit of said policy,
not how many or few words we need to write in the devmanual about it.

>   * Users can omit --newuse and --changed-use from their lives.

They already can.

>   * All package managers now handle IUSE changes properly.

If you want to see consistent behaviour in how package manages handle
IUSE, I suggest sending patches for PMS. I don't see any problem in
portage/paludis/pkgcore handling things differently. That is the point
of having different package managers, after all.

>   * emerge runs a bit faster.

Why will it run faster?

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

[Michael Palimaka]

On 08/12/2017 08:16 PM, Michael Orlitzky wrote:
> On 08/12/2017 12:22 AM, Michael Palimaka wrote:
>>
>>> Q. But what if I maintain firefox, and I need to change  IUSE?
>>>
>>>   If the IUSE change isn't important, just make the new revision in a
>>>   branch and wait to commit it later when there are more changes
>>>   piled up. If it is important (like if its default value changes
>>>   RDEPEND), then it would have required a revision anyway.
>>
>> Please stop trying to force workflows on people. Using that same logic,
>> I can make the IUSE change in-place and it would be propagated in the
>> next version bump.
>>
> 
> I'm not trying to force anything on anyone, I'm just asking for
> feedback. If it turns out to be a stupid idea, then so be it.
> 
> If it's understood that you can make IUSE changes but that they'll only
> be propagated on the next version bump, then there would be no problem.
> But we're about to document a policy that says it's OK to do things that
> wouldn't normally be OK, because --changed-use is there to save us:
> 
>   The examples of changes that can be done without a revision bump are:
> 
> ...
> 
> * adding a new USE flag or removing an existing one (since change
>   in USE flags is going to trigger --changed-use rebuild),
> 
> If developers operate under that assumption and if you don't use
> --changed-use, you're going to run into problems eventually.

--changed-use is an optional flag and portage works just as well without
it. Please provide examples of such problems.

> 
> 
>>>   * emerge runs a bit faster.
>>
>> Why will it run faster?
> 
> The developer now indicates that IUSE has changed, so portage doesn't
> have to figure it out on its own.

Please provide some numbers to back up this claim. Even if we assume
portage will run faster because we can remove --changed-use (which we
can't, because as pointed out in other posts we still need this flag),
surely any time savings gained there will be lost by pointless rebuilds?

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

[Michael Palimaka]

On 08/12/2017 08:29 PM, Rich Freeman wrote:
> On Sat, Aug 12, 2017 at 5:57 AM, Michael Orlitzky  wrote:
>> On 08/12/2017 03:03 AM, Michał Górny wrote:
>>>
>>> Please provide some examples of recent in-place USE changes that benefit
>>> from revbumps.
>>>
>>
>> There is no single example. Things only get simpler if *all* USE changes
>> come with a new revision.
>>
> This policy change would make my life easier, because for big packages
> it would encourage maintainers to not make IUSE changes until they do
> revbumps, which would save me a build.  I'm running on relatively old
> hardware at this point so these rebuilds actually do cost me quite a
> bit of time.  I'm not sure that not using --changed-use is a great
> option though as it will make it that much harder to keep things
> consistent when I do modify my package.use/make.conf.
> 

At least now you have the option to run without --changed-use if you
want. If inline IUSE changes are completely banned, you will definitely
see more pointless rebuilds on your old hardware. In my experience most
developers make a change when there's a change to be made, and don't
"save up" changes until some arbitrary delta is reached. We've already
an increase in revbumps like this in other areas where inline changes
are being discouraged.

[gentoo-dev] Last rites: media-gfx/kflickr

[Michael Palimaka]

# Michael Palimaka  (27 Aug 2017)
# Doesn't work anymore. Dead upstream.
# Masked for removal in 30 days.
media-gfx/kflickr

[gentoo-dev] Last rites: kde-misc/colibri

[Michael Palimaka]

# Michael Palimaka  (27 Aug 2017)
# Doesn't work with Plasma 5. Dead upstream.
# Masked for removal in 30 days.
kde-misc/colibri

[gentoo-dev] Last rites: media-gfx/kgrab

[Michael Palimaka]

# Michael Palimaka  (27 Aug 2017)
# Requires deprecated Qt/KDE4. Dead upstream. Use kde-apps/spectacle
instead.
# Masked for removal in 30 days.
media-gfx/kgrab

[gentoo-dev] Last rites: dev-qt/qtphonon

[Michael Palimaka]

# Michael Palimaka  (03 Sep 2017)
# Dead upstream. Use media-libs/phonon instead.
# Masked for removal in 30 days. Bug #629144.
dev-qt/qtphonon

[gentoo-dev] Last rites: x11-apps/python-whiteboard

[Michael Palimaka]

# Michael Palimaka  (09 Sep 2017)
# Requires dead Qt 4. Dead upstream. Unmaintained.
# Masked for removal in 30 days.
x11-apps/python-whiteboard

[gentoo-dev] Last rites: sys-process/procexp

[Michael Palimaka]

# Michael Palimaka  (09 Sep 2017)
# Requires dead Qt 4. Dead upstream. Unmaintained.
# Masked for removal in 30 days.
sys-process/procexp

[gentoo-dev] Last rites: app-text/kding

[Michael Palimaka]

# Michael Palimaka  (09 Sep 2017)
# Requires dead Qt 4. Dead upstream.
# Masked for removal in 30 days.
app-text/kding

[gentoo-dev] Last rites: app-editors/qwriter, dev-util/kscope, dev-util/monkeystudio, dev-util/universalindentgui

[Michael Palimaka]

# Michael Palimaka  (11 Sep 2017)
# Requires dead Qt 4. Dead upstream. Fails to build with new
x11-libs/qscintilla.
# Masked for removal in 30 days. Bug #628224.
app-editors/qwriter

# Michael Palimaka  (11 Sep 2017)
# Requires dead Qt 4. Dead upstream. Fails to build with new
x11-libs/qscintilla.
# Masked for removal in 30 days. Bug #628228.
dev-util/kscope

# Michael Palimaka  (11 Sep 2017)
# Requires dead Qt 4. Dead upstream. Fails to build with new
x11-libs/qscintilla.
# Masked for removal in 30 days. Bug #628230.
dev-util/monkeystudio

# Michael Palimaka  (11 Sep 2017)
# Requires dead Qt 4. Dead upstream. Fails to build with new
x11-libs/qscintilla.
# Masked for removal in 30 days. Bug #628234.
dev-util/universalindentgui

[gentoo-dev] Last rites: media-libs/herqq

[Michael Palimaka]

# Michael Palimaka  (21 Sep 2017)
# Requires dead Qt 4. Dead upstream.
# Masked for removal in 30 days.
media-libs/herqq

[gentoo-dev] Last rites: kde-misc/kookie

[Michael Palimaka]

# Michael Palimaka  (26 Sep 2017)
# Requires dead Qt 4. Dead upstream.
# Masked for removal in 30 days.
kde-misc/kookie

[gentoo-dev] Last rites: kde-misc/konstruktor

[Michael Palimaka]

# Michael Palimaka  (26 Sep 2017)
# Requires dead Qt 4. Dead upstream.
# Masked for removal in 30 days.
kde-misc/konstruktor

[gentoo-dev] Last rites: app-office/qcharselect

[Michael Palimaka]

# Michael Palimaka  (30 Sep 2017)
# Depends on dead qt4. Dead upstream.
# Masked for removal in 30 days.
app-office/qcharselect

[gentoo-dev] Last rites: net-misc/dnetstats

[Michael Palimaka]

# Michael Palimaka  (30 Sep 2017)
# Depends on dead qt4. Dead upstream.
# Masked for removal in 30 days.
net-misc/dnetstats

[gentoo-dev] Last rites: media-sound/lastfm-desktop

[Michael Palimaka]

# Michael Palimaka  (01 Oct 2017)
# Fails to build (bug #622632). Requires dead and vulnerable qtwebkit4
# (bug #620710). Masked for removal in 30 days.
media-sound/lastfm-desktop

[gentoo-dev] Re: cmake + ninja vs autotools

[Michael Palimaka]

On 11/16/2017 02:27 PM, William L. Thomson Jr. wrote:
> It maybe worth considering switching the default generator in the
> cmake-utils.eclass from the default of emake to ninja.
> 
> - : ${CMAKE_MAKEFILE_GENERATOR:=emake}
> + : ${CMAKE_MAKEFILE_GENERATOR:=ninja}
> 
> For those with cmake ebuilds you can test this out now via 
> 
> CMAKE_MAKEFILE_GENERATOR="ninja"
> inherit cmake-utils

If testing this, please use : ${CMAKE_MAKEFILE_GENERATOR:=ninja} in
ebuilds unless the emake generator is explicitly known not to work. This
will preserve user choice if they want to avoid ninja for some reason.

[gentoo-dev] Last rites: dev-vcs/qsvn

[Michael Palimaka]

# Michael Palimaka  (02 Dec 2017)
# Depends on dead Qt 4. Dead upstream.
# Masked for removal in 30 days. Bug #639252.
dev-vcs/qsvn

[gentoo-dev] Last rites: dev-vcs/qct

[Michael Palimaka]

# Michael Palimaka  (07 Dec 2017)
# Dead upstream. Requires dead Qt4.
# Masked for removal in 30 days. Bug #640138.
dev-vcs/qct

[gentoo-dev] Last rites: net-ftp/oneclickftp

[Michael Palimaka]

# Michael Palimaka  (07 Dec 2017)
# Dead upstream. Requires dead Qt4.
# Masked for removal in 30 days. Bug #640138.
net-ftp/oneclickftp

[gentoo-dev] Last rites: app-editors/znotes

[Michael Palimaka]

# Michael Palimaka  (22 Dec 2017)
# Dead upstream. Requires dead Qt 4.
# Masked for removal in 30 days.
app-editors/znotes

[gentoo-dev] Last rites: x11-misc/qsynergy

[Michael Palimaka]

# Michael Palimaka  (22 Dec 2017)
# Dead upstream. Requires dead Qt 4.
# Masked for removal in 30 days.
x11-misc/qsynergy

[gentoo-dev] Last rites: sci-calculators/qalculator, x11-misc/basqet, x11-misc/okindd

[Michael Palimaka]

# Michael Palimaka  (22 Dec 2017)
# Dead upstream. Requires dead Qt 4.
# Masked for removal in 30 days.
sci-calculators/qalculator

# Michael Palimaka  (22 Dec 2017)
# Dead upstream. Requires dead Qt 4.
# Masked for removal in 30 days.
x11-misc/basqet

# Michael Palimaka  (22 Dec 2017)
# Dead upstream. Requires dead Qt 4.
# Masked for removal in 30 days.
x11-misc/okindd

[gentoo-dev] Re: Deleting old news items

[Michael Palimaka]

On 01/03/2018 11:13 AM, Alec Warner wrote:
> Problem:
> 
> New stages have numerous news items listed that are likely not relevant,
> but are shown due to limitations in the filtering in NEWS items. E.g. on
> a recent stage3:
> 
> nspawntest / # eselect news list
> News items:
>   [1]   N  2013-09-27  Separate /usr on Linux requires initramfs
>   [2]   N  2014-06-15  GCC 4.8.3 defaults to -fstack-protector
>   [3]   N  2014-10-26  GCC 4.7 Introduced the New C++11 ABI 
>   [4]   N  2015-02-02  New portage plug-in sync system
>   [5]   N  2015-07-25  Python 3.4 enabled by default
>   [6]   N  2015-08-13  OpenSSH 7.0 disables ssh-dss keys by default
>   [7]   N  2015-10-22  GCC 5 Defaults to the New C++11 ABI
>   [8]   N  2016-06-19  L10N USE_EXPAND variable replacing LINGUAS
>   [9]   N  2017-11-30  New 17.0 profiles in the Gentoo repository
> 
> Many of these are always displayed. For example:
> 
> https://gitweb.gentoo.org/data/gentoo-news.git/tree/2015-02-04-portage-sync-changes/2015-02-04-portage-sync-changes.en.txt
> 
> has "Display-If-Installed: sys-apps/portage" and will be displayed on
> nearly every Gentoo machine. While relevant in 2015; I'm skeptical that
> its relevant today. I am also considering explicit changes in the
> filtering directives to resolve this in the future.
> 
> Glep42 states:
> 
> ---
> News Item Removal
> 
> News items can be removed (by removing the news file from the main tree)
> when they are no longer relevant, if they are made obsolete by a future
> news item or after a long period of time. This is the same as the method
> used for updates entries.
> ---
> 
> I suggest we delete all entries prior to 2016. Git keeps history
> forever, so folks can gander at the old entries on gitweb.gentoo.org
> :
> 
> https://gitweb.gentoo.org/data/gentoo-news.git/tree/
> 
> -A

I strongly support this idea. I've tried to push this several times in
the past however was met with some resistance from several teams.

[gentoo-dev] Re: News Item: Portage Dynamic Deps

[Michael Palimaka]

On 01/22/2018 09:28 PM, Andreas K. Huettel wrote:
> Am Montag, 22. Januar 2018, 08:01:08 CET schrieb Zac Medico:
>>
>> According to Gentoo policy, future ebuild dependency changes need to be
>> accompanied by a revision bump in order to trigger rebuilds for users.
>> Therefore, you should only need to use --changed-deps=y for a single
>> deep @world update. After that, if you encounter installed packages with
>> outdated dependencies in a future deep @world update, then you should
>> report it as a bug.
> 
> Did you come up with a solution how to handle eclass-generated dependency 
> changes then?

No.

Bug #641346 was filed for clarification about this, but it just got
closed without answering the question or consulting anyone.

Now, every time we want to make a minor change we need to revbump half
the tree due to a change that has been forced mostly by people not
actually involved in any actual ebuild maintenance.

[gentoo-dev] Re: News Item: Portage Dynamic Deps

[Michael Palimaka]

On 01/24/2018 12:15 AM, Michael Orlitzky wrote:
> On 01/23/2018 07:40 AM, Michael Palimaka wrote:
>>>
>>> Did you come up with a solution how to handle eclass-generated dependency 
>>> changes then?
>>
>> No.
>>
>> Bug #641346 was filed for clarification about this, but it just got
>> closed without answering the question or consulting anyone.
>>
>> Now, every time we want to make a minor change we need to revbump half
>> the tree due to a change that has been forced mostly by people not
>> actually involved in any actual ebuild maintenance.
> 
> You could always set "--dynamic-deps y" on your machine, and ignore the
> breakage caused to end users (i.e. the situation last week).

You mean the breakage caused by changing default options without any
consultation or notification?

[gentoo-dev] Last rites: media-video/qx11grab

[Michael Palimaka]

# Michael Palimaka  (25 Jan 2018)
# Requires dead Qt 4. Dead upstream.
# Masked for removal in 30 days. Bug #644532.
media-video/qx11grab

[gentoo-dev] Last rites: media-sound/lastfmplayer

[Michael Palimaka]

# Michael Palimamka  (11 Feb 2018
# Fails to build (bug #538400). Requires dead Qt 4 (bug #637014).
# Dead upstream. Masked for removal in 30 days.
media-sound/lastfmplayer

[gentoo-dev] Re: Lastrite: app-crypt/monkeysign

[Michael Palimaka]

On 02/12/2018 08:59 AM, Kristian Fiskerstrand wrote:
> # Kristian Fiskerstrand  (11 Feb 2018)
> # Lastrite: app-crypt/monkeysign . Please use caff from
> # app-crypt/signing-party instead. Removal in 30 days.
> # Bug: #647352
> app-crypt/monkeysign
> 

What's the reason for the removal?

[gentoo-dev] Last rites: media-sound/moodbar

[Michael Palimaka]

# Michael Palimaka  (22 Feb 2018)
# Plugin for removed package media-sound/amarok. Dead upstream.
# Depends on vulnerable gstreamer:0.10.
# Masked for removal in 30 days. Bug #629184.
media-sound/moodbar

[gentoo-dev] Re: [PATCH] cmake-utils.eclass: Extend ASM rules to ASM-ATT

[Michael Palimaka]

On 02/25/2018 08:06 PM, Michał Górny wrote:
> Some CMake projects use ASM-ATT rather than ASM, so extend our rule
> overrides to that.
> 
> Bug: https://bugs.gentoo.org/625844
> ---
>  eclass/cmake-utils.eclass | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
> index b9f69a824b14..ef3f3c2607f8 100644
> --- a/eclass/cmake-utils.eclass
> +++ b/eclass/cmake-utils.eclass
> @@ -516,6 +516,7 @@ cmake-utils_src_configure() {
>   fi
>   cat > "${build_rules}" <<- _EOF_ || die
>   SET (CMAKE_ASM_COMPILE_OBJECT "  
> ${includes} ${CPPFLAGS}  -o  -c " CACHE STRING "ASM 
> compile command" FORCE)
> + SET (CMAKE_ASM-ATT_COMPILE_OBJECT " 
>  ${includes} ${CPPFLAGS}  -o  -c " CACHE 
> STRING "ASM compile command" FORCE)
>   SET (CMAKE_C_COMPILE_OBJECT "  
> ${includes} ${CPPFLAGS}  -o  -c " CACHE STRING "C 
> compile command" FORCE)
>   SET (CMAKE_CXX_COMPILE_OBJECT "  
> ${includes} ${CPPFLAGS}  -o  -c " CACHE STRING "C++ 
> compile command" FORCE)
>   SET (CMAKE_Fortran_COMPILE_OBJECT " 
>  ${includes} ${FCFLAGS}  -o  -c " CACHE 
> STRING "Fortran compile command" FORCE)
> @@ -531,6 +532,7 @@ cmake-utils_src_configure() {
>   local toolchain_file=${BUILD_DIR}/gentoo_toolchain.cmake
>   cat > ${toolchain_file} <<- _EOF_ || die
>   SET (CMAKE_ASM_COMPILER "${myCC/ /;}")
> + SET (CMAKE_ASM-ATT_COMPILER "${myCC/ /;}")
>   SET (CMAKE_C_COMPILER "${myCC/ /;}")
>   SET (CMAKE_CXX_COMPILER "${myCXX/ /;}")
>   SET (CMAKE_Fortran_COMPILER "${myFC/ /;}")
> @@ -609,6 +611,7 @@ cmake-utils_src_configure() {
>   if [[ ${CMAKE_BUILD_TYPE} != Gentoo && ${EAPI} != 5 ]]; then
>   cat >> ${common_config} <<- _EOF_ || die
>   SET (CMAKE_ASM_FLAGS_${CMAKE_BUILD_TYPE^^} "" CACHE 
> STRING "")
> + SET (CMAKE_ASM-ATT_FLAGS_${CMAKE_BUILD_TYPE^^} "" CACHE 
> STRING "")
>   SET (CMAKE_C_FLAGS_${CMAKE_BUILD_TYPE^^} "" CACHE 
> STRING "")
>   SET (CMAKE_CXX_FLAGS_${CMAKE_BUILD_TYPE^^} "" CACHE 
> STRING "")
>   SET (CMAKE_Fortran_FLAGS_${CMAKE_BUILD_TYPE^^} "" CACHE 
> STRING "")
> 

LGTM

[gentoo-dev] Re: [PATCH] cmake-utils.eclass: Override CMAKE_INSTALL_{INFO,MAN}DIR

[Michael Palimaka]

On 03/02/2018 02:40 AM, Michał Górny wrote:
> Provide an explicit override for CMAKE_INSTALL_INFODIR
> and CMAKE_INSTALL_MANDIR to force Gentoo standards for those locations.
> This is needed for Gentoo/FreeBSD where CMake defaults to /usr/info
> and /usr/man; while PMS specifies /usr/share/info and /usr/share/man
> via econf & do* helpers.
> ---
>  eclass/cmake-utils.eclass | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
> index b9f69a824b14..636927d66491 100644
> --- a/eclass/cmake-utils.eclass
> +++ b/eclass/cmake-utils.eclass
> @@ -602,6 +602,8 @@ cmake-utils_src_configure() {
>   SET (CMAKE_GENTOO_BUILD ON CACHE BOOL "Indicate Gentoo package 
> build")
>   SET (LIB_SUFFIX ${libdir/lib} CACHE STRING "library path 
> suffix" FORCE)
>   SET (CMAKE_INSTALL_LIBDIR ${libdir} CACHE PATH "Output 
> directory for libraries")
> + set (CMAKE_INSTALL_INFODIR "${EPREFIX}/usr/share/info" CACHE 
> PATH "")
> + set (CMAKE_INSTALL_MANDIR "${EPREFIX}/usr/share/man" CACHE PATH 
> "")
>   _EOF_
>   [[ "${NOCOLOR}" = true || "${NOCOLOR}" = yes ]] && echo 'SET 
> (CMAKE_COLOR_MAKEFILE OFF CACHE BOOL "pretty colors during make" FORCE)' >> 
> "${common_config}"
>  
> 

There was some discussion in the past about adding these (and some
others), but at that time it was postponed until EAPI 7 due to concerns
about breaking existing packages. What do you think about the risk?

[gentoo-dev] Last rites: media-gfx/qosmic

[Michael Palimaka]

# Michael Palimaka  (07 Mar 2018)
# Depends on deprecated Qt 4. Dead upstream.
# Masked for removal in 30 days. Bug #644424.
media-gfx/qosmic

[gentoo-dev] Last rites: media-video/qt-recordmydesktop

[Michael Palimaka]

# Michael Palimaka  (07 Mar 2018)
# Depends on deprecated Qt 4. Dead upstream.
# Masked for removal in 30 days. Bug #649116.
media-video/qt-recordmydesktop

[gentoo-dev] Re: Packages up for grabs

[Michael Palimaka]

On 03/11/2018 12:12 AM, Pacho Ramos wrote:
> This packages are now up for grabs:
...
> net-irc/unrealircd

I can take this one.

[gentoo-dev] Mailing list moderation and community openness

[Michael Palimaka]

I see that in bug #650964[1] Council is pushing forward again with
implementing user whitelisting on this mailing list (ie. anyone that is
not "approved" will have their mail rejected).

Could someone please explain how this doesn't directly contradict the
core tenets of an open and inclusive community?

1: https://bugs.gentoo.org/650964

[gentoo-dev] [PATCH] skel.ChangeLog: remove file

[Michael Palimaka]

ChangeLog files are no longer used since the git migration.
---
 skel.ChangeLog | 67 --
 1 file changed, 67 deletions(-)
 delete mode 100644 skel.ChangeLog

diff --git a/skel.ChangeLog b/skel.ChangeLog
deleted file mode 100644
index 10ffc31..000
--- a/skel.ChangeLog
+++ /dev/null
@@ -1,67 +0,0 @@
-# ChangeLog for /
-# Copyright 1999-2016 Gentoo Foundation; Distributed under the GPL v2
-# $Id$
-
-*-- (DD MMM )
-
-  DD MMM ; YOUR_NAME  changed_file1, changed_file2 :
-  Initial import.  Ebuild submitted by submitter_name .
-  Note that the "changed_file" listing is optional if you are simply bumping
-  the rev of the ebuild and are only making changes to the .ebuild file
-  itself.  Also note that we now have a single unified paragraph rather than
-  having the first line separated from the rest by a newline.  Everything
-  should be in one block like this. (note by drobbins, 16 Jul 2002)
-
-  DD MMM ; YOUR_NAME  changed_file1, changed_file2: this is
-  an earlier ChangeLog entry.
-
--- Explanation of ChangeLog format:
-
-  ***
-  THIS IS IMPORTANT: The ChangeLog format is a *chronological* account of all
-  changes made to a set of ebuilds. That means that the most recent ChangeLog
-  entry *always* goes at the top of the file. More explanation below.
-  ***
-
-  ***
-  ANOTHER IMPORTANT NOTE: There are some ChangeLogs that don't follow this
-  format and organize all changes under the "correct" "*" entry. This is not
-  correct. However, rather than making a concerted effort to fix these
-  ChangeLogs, we should spend our energy defining a comprehensive and strict
-  XML-based ChangeLog format which we then migrate to. But for any entries to
-  any ChangeLog that *you* make, please make sure to always add entries to the
-  top of the file like a good boy/girl. Even do this if it's clear that you're
-  adding an entry to a b0rked ChangeLog.
-  ***
-
-  This changelog is targeted to users. This means that the comments should be
-  well explained and written in clean English.
-
-  Every new version or revision of the package should be marked by a '*'
-  separator line as above to indicate where in the chronology it was first
-  added to our Git tree. Any changes since the last revision, really _any
-  changes at all_ have to be added to the top of the file, underneath the
-  initial copyright and file header comments, in exactly the same format as 
this
-  comment. If you are modifying older ebuilds, simply note them as changed
-  files and add your entry to the top of the ChangeLog. Resist the temptation
-  to "organize" your ChangeLog entries by placing them under the "correct" "*"
-  entries -- this isn't the purpose of the "*" entries.
-
-  This means that you start with header line that has the following format,
-  indented two spaces:
-
-  DD MMM ; your_name  changed_file1, changed_file2: Your
-  explanation should follow. It should be indented and wrapped at a line width
-  of 80 characters.  The changed_files can be omitted if they are obvious; for
-  example, if you are only modifying the .ebuild file and committing a new rev
-  of a package.  Any details about what exactly changed in the code should be
-  added as a message when the changes are committed to Git, not in this file.
-
--- A word regarding credit:
-
-  Please add credit information ("ebuild submitted by ...", "patch submitted
-  by ...") to the ChangeLog. Do not add this information to the ebuilds
-  themselves.
-
-  And remember: Give credit where credit is due. We're all doing this for
-  free, so the best we can hope (and expect!) to receive is credit.
-- 
2.4.10

[gentoo-dev] [PATCH] skel.metadata.xml: update for GLEP 67

[Michael Palimaka]

I tried to tidy it up a bit too. Any ideas on how to improve further are
appreciated.

Michael Palimaka (1):
  skel.metadata.xml: update for GLEP 67

 skel.metadata.xml | 35 +--
 1 file changed, 17 insertions(+), 18 deletions(-)

-- 
2.4.10

[gentoo-dev] [PATCH] skel.metadata.xml: update for GLEP 67

[Michael Palimaka]

---
 skel.metadata.xml | 35 +--
 1 file changed, 17 insertions(+), 18 deletions(-)

diff --git a/skel.metadata.xml b/skel.metadata.xml
index 7a496fb..1c8bc32 100644
--- a/skel.metadata.xml
+++ b/skel.metadata.xml
@@ -5,30 +5,29 @@
 
 This is the example metadata file.
 The root element of this file is . Within this element a
-number of subelements are allowed: herd, maintainer, and
-longdescription. herd is a required subelement.
+number of subelements are allowed, the most common being maintainer.
 
 For a full description look at:
 https://devmanual.gentoo.org/ebuild-writing/misc-files/metadata/
 
-
 Before committing, please remove the comments from this file. They are
 not relevant for general metadata.xml files.
 -->
 
-
-
-   @gentoo.org
-
-
-
-
+   
+   example...@gentoo.org
+   Primary maintainer
+   
+   
+   exampleproj...@gentoo.org
+   Gentoo Example Project
+   
+   Long description of the package
+   
+   Uses app-text/aspell for spell 
checking.
+   Requires an installed dictionary from 
app-dicts
+   Description of how USE='flag' affects this 
package
+   Description of how USERLAND='GNU' 
affects this
+   package
+   
 
-- 
2.4.10

[gentoo-dev] Last rites: media-libs/gluon

[Michael Palimaka]

# Michael Palimaka  (12 Feb 2016)
# Fails to build. No revdeps. Masked for removal in 30 days.
# Bug 574432
media-libs/gluon

[gentoo-dev] Last rites: media-video/stk11xx

[Michael Palimaka]

# Michael Palimaka  (18 Feb 2016)
# Fails to build with recent kernels. Dead upstream.
# Masked for removal in 30 days. Bug 488128.
media-video/stk11xx

[gentoo-dev] Last rites: media-tv/wis-go7007

[Michael Palimaka]

# Michael Palimaka  (18 Feb 2016)
# Fails to build with recent kernels. Dead upstream.
# Use kernel driver VIDEO_GO7007 instead.
# Masked for removal in 30 days. Bug 482120.

[gentoo-dev] Last rites: gnome-extra/connman-gnome

[Michael Palimaka]

# Michael Palimaka  (18 Feb 2016)
# Fails to build. Dead upstream. Use net-misc/connman-gtk instead.
# Masked for removal in 30 days. Bug 502552.
gnome-extra/connman-gnome