[gentoo-dev] Last rites: kde-misc/akonadi-google

[Johannes Huber]

+# Johannes Huber j...@gentoo.org (09 May 2013)
+# Masked for removal in 30 days. Package is obsolete.
+# Upstream replaced it with net-libs/libkgapi.
+kde-misc/akonadi-google
-- 
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID F3CFD2BD

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

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

[Johannes Huber]

# Johannes Huber j...@gentoo.org (13 May 2013)
# Masked for removal in 30 days. Package is obsolete.
# Merged into kde-base/plasma-workspace by upstream 
# since KDE SC 4.10.
kde-misc/ktouchpadenabler
-- 
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID F3CFD2BD

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

[gentoo-dev] Last rites: media-libs/phonon-xine

[Johannes Huber]

# Andreas K. Huettel dilfri...@gentoo.org (1 Dec 2011)
# edit: Johannes Huber j...@gentoo.org (16 Jan 2012)
# Masked for removal in 15 days. phonon xine backend is unmaintained.
# Upstream declared it as dead. Use vlc or gstreamer backend instead.
# Bugs #359979, #397585
media-libs/phonon-xine
-- 
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID F3CFD2BD


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

[gentoo-dev] latest boost vs. eselected boost

[Johannes Huber]

Hello,

a user submitted a bug[1] that cmake always select the latest boost. We the 
kde team as cmake maintainer found a solution to respect the (e)selected 
boost. The patched version is not in tree yet, because after my blog post[2] 
about this issue a discussion in the bug starts.

Summary of the comments: 
1) Ebuilds should always pick the latest boost version.
2) Boost should be compared to gcc, python, ruby etc 

So please state your opinion here, before the bug comments explode. In the 
case that eselect feature for boost will be last rited as in comment 16[1] 
announced, then you can forget this mail. 

[1] https://bugs.gentoo.org/show_bug.cgi?id=335108
[2] http://blogs.gentoo.org/johu/2012/01/13/cmake-picks-always-the-latest-
boost/

Greetings
-- 
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID F3CFD2BD


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

Re: [gentoo-dev] color management in gentoo (kde expecially) proposal for help

[Johannes Huber]

Am Donnerstag, 23. Februar 2012, 15:47:09 schrieb Francesco Riosa:
 Hi,
my name is Francesco Riosa, I would be interested in a more
 complete support of the oyranos color managment programs in ::gentoo.
 Oyranos is intended to be multy platform and in some sense multy os,
 but in the current incarnation has good support for kde.
 
 In case there is interest I can apply to return as a developer in
 gentoo, will respond to emails this week end (25/26 Feb)
 
 I'm _not_ offering support for digikam, for which I develop, because I
 would like to mantain a two step verification process
 (developer/packager)

 Regards,
 Francesco

Hi Francesco,

we have already kde-misc/kolor-manager in tree.

Greetings,
-- 
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID F3CFD2BD


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

Re: [gentoo-dev] cmake-utils.eclass: set default of CMAKE_VERBOSE=1

[Johannes Huber]

Am Freitag, 4. Mai 2012, 18:30:10 schrieb hasufell:
 # @ECLASS-VARIABLE: CMAKE_VERBOSE
 # @DESCRIPTION:
 # Set to enable verbose messages during compilation.
 
 By default this is deactivated which is inconvenient imo and results in
 pastes having minimum information.
 I have to tell users every time to recompile with CMAKE_VERBOSE=1 so
 that I have proper information on what is going on.
 
 Are there any arguments against this being default?

In 95-99% of the build failures we get in kde herd the information is 
sufficient. So from my point of view the current behaviour is good.

Greetings

-- 
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID F3CFD2BD

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

Re: [gentoo-dev] cmake-utils.eclass: set default of CMAKE_VERBOSE=1

[Johannes Huber]

Am Freitag, 4. Mai 2012, 14:41:42 schrieb Mike Gilbert:
 On Fri, May 4, 2012 at 2:29 PM, hasufell hasuf...@gentoo.org wrote:
  On 05/04/2012 08:00 PM, Johannes Huber wrote:
  Am Freitag, 4. Mai 2012, 18:30:10 schrieb hasufell:
  # @ECLASS-VARIABLE: CMAKE_VERBOSE # @DESCRIPTION: # Set to enable
  verbose messages during compilation.
  
  By default this is deactivated which is inconvenient imo and
  results in pastes having minimum information. I have to tell
  users every time to recompile with CMAKE_VERBOSE=1 so that I have
  proper information on what is going on.
  
  Are there any arguments against this being default?
  
  In 95-99% of the build failures we get in kde herd the information
  is sufficient. So from my point of view the current behaviour is
  good.
  
  Greetings
  
  I think that as an argument pro CMAKE_VERBOSE=1 because that would
  cover 100% instead of 95-99.
 
 I only maintain a couple of cmake-based ebuilds, but I find having the
 full compiler command line useful. Without it, I have to guess at what
 was actually run.

How about bump docs for that use case? For example 
http://www.gentoo.org/proj/en/qa/backtraces.xml

Cheers
-- 
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID F3CFD2BD

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

[Johannes Huber]

Am Mittwoch 23 Mai 2012, 14:42:37 schrieb Michael Weber:
 -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-

I support RESOLUTION WONTFIX, if nobody cares about the bug since it was 
opened it is obvious out of interest. There is no reason to support jurassic 
software. 

Clean cut++

Cheers
-- 
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID F3CFD2BD


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

[gentoo-dev] Last rite: tetex.eclass + tetex-3.eclass

[Johannes Huber]

Is obsolete and not used anymore[1][2]. Will be removed in 30 days.

+  18 Jul 2012; Johannes Huber j...@gentoo.org tetex-3.eclass, tetex.eclass:
+  Marking as DEAD for removal.
+

[1] http://qa-reports.gentoo.org/output/eapi-per-eclass/tetex-3.eclass/
[2] http://qa-reports.gentoo.org/output/eapi-per-eclass/tetex.eclass/

-- 
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID F3CFD2BD

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

[gentoo-dev] EAPI usage

[Johannes Huber]

Hello gentoo devs,

From last council meeting summary:
[snip]
 Open floor
 ==
 scarabeus suggested the change dev should use latest eapi when bumping
 to dev must use latest eapi when bumping if not forbidden by eclasses.
 He was asked to bring it up on the mailing lists, to get a better
 definition of when what EAPI should be used.
[/snip]

I raised the issue through scarabeus, as in my opinion there is no reason to 
not use latest EAPI. So please discuss.

Greetings,
-- 
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID F3CFD2BD

Re: [gentoo-dev] EAPI usage

[Johannes Huber]

 I can't say I'm a big fan of this.  This requires forcing changes to
 ebuilds that offer no actual benefit to either the maintainer or the
 end-users (changes that actually have some benefit to either are
 likely to be made anyway).  The PM maintainers have chimed in that
 there is no benefit to PM maintenance from this change.

EAPI 0 is more readable than EAPI 4? No benefit for maintainer? No benefit for 
user who wants to read the ebuild? Realy?

 So, I can't really see what the upside of such a policy is.
 
 The downsides are several - you're taking code that works and fiddling
 with it, perhaps creating code that doesn't work.  You're forcing that
 development to take place in the newest EAPI, which is also the
 version which the everybody has the least experience with (likely less
 documentation online as well).

devmanual is fine.

 Developers have only a limited amount of time, and this will eat into
 it.  The result is likely to not be new shiny ebuilds that use the new
 EAPIs, but rather old rusty ones that still use the old EAPI but also
 which contain other bugs, since they don't get touched at all (since
 touching them triggers the new policy).

You dont need to touch the old ebuild, but if you are touching it for example 
a version bump, a bug fix etc you should be able to do the EAPI bump as long as 
you have done the ebuild quizzes ;)

 For a real-world analogy - look at the result of well-intended laws
 that require ADA compliance and such on building modifications.  The
 result is often stuff like kids taking classes in modular trailers and
 such because in order to add an extension to the building you need to
 bring the entire building up to code (and not just the new part).  The
 result isn't more elevators and ramps - but the use of hacked together
 solutions to work around the policy.

Examples?

 If it ain't broke, don't fix it.

Essential part of software development is refactoring to get the code in a 
modern state. 
 
 Now, if a maintainer actually needs a feature of a new EAPI, or an
 ebuild contains a bug that can only be addressed by bumping it, then
 by all means the maintainer should be revising the ebuild.  Then there
 is actually an upside to balance the cost.

True.

 Rich

Greetings,
-- 
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID F3CFD2BD

Re: [gentoo-dev] EAPI usage

[Johannes Huber]

 Could you elaborate what the reasons FOR it are (not that I don't know
 any, but you brought it up) since this will add work for every developer
 to check a) how the behavior of the new EAPI impacts the current ebuild
 and b) how the behvaior of inherited eclasses change depending on EAPI.

My main arguement is a modern code base, my intention is not to touch the 
ebuild if there is no reason. But if you are doing a version bump, bug fix etc 
you working on the package anyway.

a) thats normal developer work
b) if there is  a bug in the eclass for a specified EAPI you should file a bug

-- 
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID F3CFD2BD

Re: [gentoo-dev] EAPI usage

[Johannes Huber]

Am Freitag, 31. August 2012, 11:03:06 schrieb Andreas K. Huettel:
 Am Donnerstag, 30. August 2012, 12:57:25 schrieb Rich Freeman:
  On Thu, Aug 30, 2012 at 6:28 AM, Johannes Huber j...@gentoo.org wrote:
   scarabeus suggested the change dev should use latest eapi when
   bumping
   to dev must use latest eapi when bumping if not forbidden by
   eclasses.
   He was asked to bring it up on the mailing lists, to get a better
   definition of when what EAPI should be used.
   
   I raised the issue through scarabeus, as in my opinion there is no
   reason
   to not use latest EAPI. So please discuss.
  
  I can't say I'm a big fan of this.  This requires forcing changes to
  ebuilds that offer no actual benefit to either the maintainer or the
  end-users (changes that actually have some benefit to either are
  likely to be made anyway).  The PM maintainers have chimed in that
  there is no benefit to PM maintenance from this change.
  
  So, I can't really see what the upside of such a policy is.
 
 rant
 Let's say, we as in Gentoo decide that we're completely sick of keeping all
 that old code out there adjusted to newer and newer gcc versions that are
 more and more critical towards minor details of the c++ standards. So, we
 declare that gcc-4.5 has to be enough for everyone, we'll just keep it in
 tree forever and dont bother anymore with all these superfluous does not
 build with gcc-4.7 bugs.
 
 Well, newer gcc versions might have some very minor marginal advantages, but
 they require that we mess with code that has worked for ages. They require
 that we actually give some thought on the evolution of the language
 semantics or nag upstream, but we can't really be bothered with that
 because of limited time. Also, keeping gcc-4.5 will always (trivially) keep
 us backward compatibility... much more important than forward
 compatibility, should porting to a much never future version ever become
 necessary.
 
 For a real world analogy, serious quakes happen only once a century... why
 should we even bother with improving building codes? I mean, at some point
 in the future things will fall apart anyway. Better dont shake anything in
 between.
 /rant
 
 Sorry but I could not really resist... please take it with a grain of salt.
 However, seriously, ...
 
 Give me one non-trivial ebuild where you can absolutely guarantee that a
 bump from EAPI=0 to EAPI=4 will not enable any improvements (in
 readability, failsafe behaviour and code size for example).
 
 Last point, if someday the tree contains ebuilds with 7-8 different EAPI's,
 we'll have succeeded in generating an unmaintainable mess (tm). It will not
 be any fun to look up things in PMS anew everytime you edit something. (Was
 the prayer to Paludis only required in EAPI=7 in src_prepare or in EAPI=8
 in pkg_preinst?) This problem could however also be solved by selectively
 phasing out in-between EAPIs (i.e. deprecate EAPIs 1 and 3 asap).

Words of wisdom, nothing to add.

Greetings.

 Cheers,
 Andreas

Cheers,
-- 
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID F3CFD2BD

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

[Johannes Huber]

# Johannes Huber j...@gentoo.org (16 Dec 2011)
# Masked for removal in 30 days. Dead upstream. Package
# is not full functional. Last release was on 2010-01-14.
# See bug #394881
kde-misc/kcheckgmail


-- 
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID F3CFD2BD


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

Re: [gentoo-dev] News item about Gnome 3.8

[Johannes Huber]

Am Sonntag, 20. Oktober 2013, 12:46:40 schrieb Pacho Ramos:
 El sáb, 19-10-2013 a las 10:32 +0200, Pacho Ramos escribió:
  Well, even if the stabilization is still waiting for two blocking bugs:
  https://bugs.gentoo.org/show_bug.cgi?id=474128 - for Orca 3.8
  https://bugs.gentoo.org/show_bug.cgi?id=486278 - for getting a lvm2
  version working ok with Systemd finally
  
  I think we could start preparing the news item. I attach one based in
  latest one from the times of 2.32 :D
  
  It only points to Gnome 3.8 upgrade guide as that guide is already
  pointing to Systemd guide for migrating (and explaining the Systemd
  need)
 
 A user replied to me suggesting to reword it to simply:
 
 
 Title: Upgrade to GNOME 3.8
 Author: Pacho Ramos pa...@gentoo.org
 Content-Type: text/plain
 Posted: 2013-10-19
 Revision: 1
 News-Item-Format: 1.0
 Display-If-Installed: gnome-base/gnome-3.8
 Display-If-Installed: gnome-base/gnome-light-3.8
 Display-If-Installed: gnome-base/gnome-session-3.8
 
 We are pleased to announce the stabilization of GNOME-3.8. Users are
 strongly encouraged to read the GNOME 3.8 Upgrade Guide to avoid any
 possible issues relating to the upgrade.
 
 Please read the Gnome 3.8 Upgrade Guide:
 http://wiki.gentoo.org/wiki/GNOME/3.8-upgrade-guide

How about to change the title to GNOME 3.8 Upgrade?


Greetings
-- 
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID F3CFD2BD

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

[gentoo-dev] Last rites: kde-misc/kio-upnp-ms

[Johannes Huber]

# Johannes Huber j...@gentoo.org (03 Nov 2013)
# Masked for removal in 30 days.  Doesn't work without
# debug. UPnP support was disabled by upstream in kdelibs. 
# See bug #442912
kde-misc/kio-upnp-ms

-- 
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID F3CFD2BD

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

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

[Johannes Huber]

# Johannes Huber j...@gentoo.org (03 Nov 2013)
# Masked for removal in 30 days.  Doesn't build. Dead upstream.
# Attempt to patch leads to runtime errors.
# See bug #484100
kde-misc/qtrans

-- 
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID F3CFD2BD

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

[gentoo-dev] Last rites: kde-misc/polkit-kde-kcmodules

[Johannes Huber]

# Johannes Huber j...@gentoo.org (24 Nov 2013)
# Masked for removal in 30 days. Broken functionality.
# See bug #438790
kde-misc/polkit-kde-kcmodules

--
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID F3CFD2BD

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

[gentoo-dev] Last rites: kde-base/kdegraphics-strigi-analyzer, kde-base/kdesdk-misc, kde-base/kdesdk-scripts, kde-base/kdesdk-strigi-analyzer, kde-base/kstartperf, kde-base/kuiviewer, kde-base/solid

[Johannes Huber]

# Johannes Huber j...@gentoo.org (14 Dec 2013)
# Masked for removal in 30 days. Not packaged in current
# stable KDE SC 4.11 and later.
kde-base/kdegraphics-strigi-analyzer
kde-base/kdesdk-misc
kde-base/kdesdk-scripts
kde-base/kdesdk-strigi-analyzer
kde-base/kstartperf
kde-base/kuiviewer
kde-base/solid
-- 
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID F3CFD2BD

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

Re: [gentoo-dev] Commit into profiles fails

[Johannes Huber]

Am Freitag, 20. Dezember 2013, 20:19:08 schrieb Alon Bar-Lev:
 Hi,
 
 Long time since I done this... maybe something had been changed.
 
 $ cvs commit -m thirdpartymirrors: fixup gnupg mirros, bug#494842, thanks
 to Ben Kohler
 cvs commit: cannot exec /var/cvsroot/CVSROOT/cvslogdate: Permission denied
 cvs commit: cannot exec /var/cvsroot/CVSROOT/checkgroup.pl: Permission
 denied
 cvs commit: Pre-commit check failed
 cvs [commit aborted]: correct above errors first!
 
 It looks like something is wrong in remote, but I see people succeed in
 committing today...
 
 What's wrong?
 
 Thanks,
 Alon

Hi Alon,

its not only you. Seems something is broken on infra side or its the pre-
christmas present, the git migration.

Greetings
-- 
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID F3CFD2BD

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

Re: [gentoo-dev] Packages up for grabs

[Johannes Huber]

Am Mittwoch 09 April 2014, 22:34:07 schrieb Pacho Ramos:
 mail-filter/bogofilter

I take it.

-- 
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID F3CFD2BD

[gentoo-dev] Last rites: games-puzzle/krosswordpuzzle

[Johannes Huber]

# Johannes Huber j...@gentoo.org (10 Apr 2014)
# Masked for removal in 30 days. Doesn't build since KDE 4.9,
# bumping to newest release from 2011 same result. Dead upstream.
# bug #429604
games-puzzle/krosswordpuzzle

-- 
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID F3CFD2BD

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

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

[Johannes Huber]

# Johannes Huber j...@gentoo.org (14 Apr 2014)
# Masked for removal in 30 days. Superseeded by kde-misc/plasma-nm.
# Acknowledged and marked as deprecated by upstream.
# Does not build with =net-misc/openconnect-5.99, bug #503898.
kde-misc/networkmanagement

-- 
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID F3CFD2BD

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

Re: [gentoo-dev] About current ppc/ppc64 status

[Johannes Huber]

Am Samstag, 26. Juli 2014, 10:44:26 schrieb Pacho Ramos:
 El sáb, 26-07-2014 a las 10:36 +0200, Pacho Ramos escribió:
  El vie, 25-07-2014 a las 15:07 -0500, William Hubbs escribió:
   On Fri, Jul 25, 2014 at 03:57:20PM -0400, Anthony G. Basile wrote:
On 07/25/14 15:50, Pacho Ramos wrote:
 El vie, 25-07-2014 a las 15:38 -0400, Anthony G. Basile escribió:
 On 07/25/14 15:28, Pacho Ramos wrote:
 That is the reason for me thinking that maybe the way to go would
 be to
 do the opposite - keep only base-system and a few others stable
 and
 drop stable for most of the rest. This big effort could be
 accomplished
 in a week by other developers willing to help (like me) and would
 solve
 the issue for the long term. I guess that is what HPPA team did in
 the
 past and I think it's working pretty well for them (in summary,
 have a
 stable tree they are able to keep stable). That will also help
 people in
 ppc* teams to know that the remaining stabilization bugs, apart of
 being
 much less, are important enough to deserve rapid attention, as
 opposed
 to current situation that will have some important bugs mixed with
 tons
 of stabilization requests of apps that got ppc stable keywords
 years ago
 and are currently no so important.
 
 Yes, please let's just do base system stable.  I've been randomly
 taking
 care of ppc but nothing systematic.  Its pretty spotty.  But at the
 same
 time I don't like the idea of just loosing all the stabilization
 effort
 on the base system, so that might work best. Something to think
 about
 for mips too.
 
 Nice, one think we would need to discuss is what do we consider base
 system :/
 
 I guess packages maintained by base-system, toolchain and...
 xorg-server
 and co... what more
 
 Not sure if we could have a list of current stable tree for ppc*,
 once
 do we have that list, ppc* teams can drop from that list what they
 want
 and we get a new list that will be the final result. What do you
 think
 about that?

At the very least, its what's needed to build the stages with
catalyst.
I would think we should start with base/packages, but I don't want to
limit it to just those because I at least need a more for building and
maintaining.  Where should we start to compile such a list?
   
   If we are going to do this, I think we should drop these arch's
   to exp status in the profiles. That way, it keeps repoman from bothering
   the rest of us about stabilizations, and we don't have to worry about
   filing stable requests on them.
   
   That would let you stabilize things that you need to build the stages.
   
   William
  
  But, moving ppc* to exp wouldn't lead us to likely break their tree?
  (because we wouldn't get any dependency issue even with base
  packages...)
 
 I was thinking in this plan:
 - Get a list with all packages stable on ppc
 - Drop from that list what ppc teams want
 - Run on all that packages ekeyword ~ppc*
 - Run repoman to the full tree to fix the dependencies, use.stable.mask
 some, tune the list of stable packages...

++ from Gentoo kde point of view

[gentoo-dev] CMake 3.0 unmasking

[Johannes Huber]

Hi all,

your favorite build tool =dev-util/cmake-3.0.0 just hit the tree. If no 
regressions show up, we would like to unmask it in ~30 days. Please test it!

Greetings,
-- 
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID F3CFD2BD


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

Re: [gentoo-dev] minimalistic emerge

[Johannes Huber]

Am Freitag 08 August 2014, 17:12:27 schrieb Igor:
 Hi,
 
 About 60% of all the packages are installed and work with nodep flag
 without any problems for years. Most of the maintainers just depend on new
 packages not knowing if it's necessary or not resulting in a really HUGE
 update that in the absolute majority of cases destabilize GENTOO making it
 not operational and WORSE than it was before. You then STABILIZE it again
 spending hours and then the story repeats itself.

 Experience show that out of 20 new dependencies pulled by
 emerge only 1 is critical and really needed to assemble the target.
 
 Is there any option in emerge to pull MINIMUM packages to
 get the result - install the application you need, leaving everything else
 AS IS untouched and stable?
 
 I would rather prefer and many would agree to use this kind of
 install instead of a full system update by default.
 
 Is there any USE flag that can switch system to this kind of update instead
 of conventional? If no such USE flag, what about stabilize gentoo with
 STABILIZED flag implementation in make.conf?
 
 Whoever needs everything new - can continue fighting with nature,
 the rest of us who has a limited life span - well, they might go for
 STABILIZED flag and live happily ever after.
 
 What do you think?

/me is thinking: 
 Your caps lock key is broken and about the content: man portage || use linux 
from scratch

-- 
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID F3CFD2BD

Re: [gentoo-dev] Supporting both Qt4 and Qt5 builds

[Johannes Huber]

Am Sonntag, 10. August 2014, 14:51:45 schrieb Georg Rudoy:
 Hi,
 
 I'm thinking of converting a few ebuilds (x11-libs/qwt,
 dev-libs/kqoauth, net-libs/qxmpp among them) to support building with
 both Qt4 and Qt5.
 
 Should this better be done by adding the corresponding useflags (qt4
 and qt5 respectively) or by slotting? The pros and cons for each, off
 the top of my head:
 
 slotting:
 + Allows having different use flags for qt4 and qt5 builds (can't
 think why that would be needed in the above examples though).
 - Possibility of exponential growth of the number of slots in case
 slotting would be required according to some other criteria (again,
 can't think why that would be needed in the above examples).
 - Requires keeping two different copies of the same ebuild with
 basically the same build rules, with all the consequences.
 
 useflags:
 + Seems to be easier and doing the required trick.
 + app-text/poppler already does this.
 - Enabling support for previously disabled Qt version requires
 rebuilding the whole library twice.
 
 What's your opinion on this?
 
 I've attached the useflag-based variant as a draft.

Multibuild is prefered.

-- 
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID F3CFD2BD

Re: [gentoo-dev] Re: My masterplan for git migration (+ looking for infra to test it)

[Johannes Huber]

Am Sonntag 14 September 2014, 15:17:41 schrieb Ulrich Mueller:
  On Sun, 14 Sep 2014, Michał Górny wrote:
  I think we should also merge gentoo-news  glsa  herds.xml into the
  repository. They all reference Gentoo packages at a particular state
  in time, and it would be much nicer to have them synced properly.
 
 Not a good idea, because we may want to grant commit access to these
 repos for people who are not necessarily ebuild devs.
 
 Ulrich

This could be solved by a pull requests review tool (gerrit, reviewboard, 
gitlab etc).

-- 
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID F3CFD2BD

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

[gentoo-dev] Last rites: kde-misc/kio-ftps

[Johannes Huber]

# Johannes Huber j...@gentoo.org (26 Jan 2015)
# Masked for removal in 30 days, bug #537746.
# Superseded by kde-base/kdebase-kioslaves ages ago.
kde-misc/kio-ftps

-- 
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID F3CFD2BD


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

Re: [gentoo-dev] Naming of repositories: gento-x86 edition, bike shedding wanted

[Johannes Huber]

Am Samstag, 14. März 2015, 22:25:56 schrieb Robin H. Johnson:
 This is a mostly inconsequential issue, but the Git migration provides
 us a chance to make a clean break...
 
 The repository of our ebuilds and the name of the CVS module have been
 called gentoo-x86 since the start of Gentoo, because it originally was
 only for x86. Here's the very first ebuild added to CVS [1], Portage
 v1.1 is also early on [2].
 
 On the rsync side, it was originally called gentoo-x86-portage, and then
 between the 1.2 and 1.4 release (early 2003), the stages switched to
 using the name 'gentoo-portage'; as recently as 2010, various mirrors
 were STILL fetching from the name of gentoo-x86-portage, when we
 reminded them that they should have switched years ago.
 
 All of these names have caused some confusion. Trying to explain to a
 new user that the Portage tree refers to the collection of ebuilds used
 by a PMS-compliant package manager (eg Portage) is problematic.
 
 To that end, I'd like us to brainstorm names for the new
 bikeshed^R^R^R^R^R^R^R^R
 repository, to go live at the time of the Git migration.
 
 It will be the single tree that contains what you find today in the
 gentoo-x86 CVS module; and on rsync as gentoo-x86-portage and
 gentoo-portage.
 
 Ideally, it should be something that works as a relatively unique
 identifier (Portage is bad as it refers to both the package manager and
 the tree), and fits easily into discussions, both in-person and online.
 
 Questions:
 0. What names for the tree/repository.
 1. We have some namespaces in Git: proj, dev, priv, data, sites, exp; should
 the tree be in one of those namespaces, a new namespace, or be without a
 namespace? git://anongit.gentoo.org/NEW-NAME.git.
 
 [1]
 http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-mail/mutt/mutt- 
 1.2.5-1.ebuild?hideattic=0revision=1.1view=markupsortby=date [2]
 http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-apps/portage/fi
 les/ebuild?hideattic=0revision=1.1view=markupsortby=date#l1051

My proposal would be:
gentoo-core

Greetings
-- 
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID F3CFD2BD


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

Re: [gentoo-dev] Re: Should there be a preference with qt4 and qt5 USE flags?

[Johannes Huber]

Am Sonntag, 8. März 2015, 21:50:02 schrieb Nikos Chantziaras:
 On 08/03/15 21:35, Alexandre Rostovtsev wrote:
  On Sun, 2015-03-08 at 21:31 +0200, Nikos Chantziaras wrote:
  Some ebuilds in portage for Qt-based software support both Qt4 as well
  as Qt5. Some have +qt4 qt5 in IUSE, others have qt4 qt5.
  
  Is there a guideline for this somewhere? If a package needs Qt and thus
  
  lists:
  REQUIRED_USE=^^ ( qt4 qt5 )
  
  but otherwise doesn't prefer one version over the other and both are
  equally well supported, should qt4 still be enabled by default?
  
  Follow what upstream developers suggest and/or what works best in
  practice? At least that's what is usually done for gtk2 vs. gtk3.
 
 Both work equally well. (I'm upstream.)

As long qt5 is testing only qt4 makes sense.

-- 
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID F3CFD2BD

[gentoo-dev] Re: RFC: using Ninja in more CMake-based packages

[Johannes Huber]

Am Sonntag 07 Juni 2015, 17:08:57 schrieb Michał Górny:
 Hello, developers.

Hello Michal,

 As you probably know already, CMake sucks a lot. One of its more sucky
 features is that it generates Makefiles that fail a lot. In particular,
 they fail at verbose build logs that are cluttered with useless CMake
 intermediate commands and hard to read. But also they sometimes
 deadloop hard in faulty dependency scanning [1].

 Those two issues can be solved by switching CMake to use Ninja instead
 of make. As you may know, Ninja is the fancy building tool that is
 faster and much harder to use than make. However, it integrates with
 CMake much better and with less hackery. In particular, the verbose
 build log is free of useless CMake percentage printing output and other
 non-sense, and contains only real build commands. It also gets
 dependency scanning right.
 
 Sadly, there are two problems with using Ninja:
 
 1) it will not work with some packages,
 
 2) it introduces an extra dep (on Ninja).
 
 The first issue is a bit complex. Sometimes the problem lies in CMake
 itself (not all CMake magic works in Ninja for some reason), sometimes
 in the project (relying on Makefile stuff), sometimes in the ebuild.
 For example, with Ninja you can't do '-C subdirectory' to run targets
 from a specific subdirectory. So, we can't force Ninja everywhere.
 
 The second issue is a bit easier. GNU make is part of @system, ninja
 would be considered an extra package being installed. Do we consider it
 fine to require it randomly? Or do we need to justify the extra dep by
 benefits of building a particular package with Ninja? Is sane verbose
 build log a good enough benefit?
 
 So, what do you think? Should I start switching random packages to
 Ninja whenever it works?
 
 Oh, and this would be done via something like:
   : ${CMAKE_MAKEFILE_GENERATOR:=Ninja}
 
 before inherit line. To respect user forcing another generator, and to
 get deps right.
 
 [1]:https://bugs.gentoo.org/show_bug.cgi?id=546336

KDE herd maintains ~1000 packages and the majority relies on CMake. I am not 
aware of any reports about GNU make related build files. So i would vote for 
the reliable GNU make generator.

Greetings,

-- 
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID F3CFD2BD

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

[gentoo-dev] Last rites: app-portage/kportagetray

[Johannes Huber]

 # Johannes Huber j...@gentoo.org (26 Jun 2015)
 # Mask for removal in 30 days. Segfaults on startup, bug #544822.
 # Last release in 2010. Non upstream repository, bug #544822.
 app-portage/kportagetray

-- 
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID FDF4F788

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

[gentoo-dev] Herd/project cleanup

[Johannes Huber]

Hello Kentoos,

i think this topic is overdue. Compared to the list of members and real 
activity i would love to cleanup the herd/project.

So please raise your hands to say yes i want to stay part of it or no i am 
not interested anymore. Please answer me within 90 days. If you reading this 
mail after the 90 days and be removed, feel free to re-join. 

Greetings,
-- 
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID FDF4F788

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: ChangeLog kde5-functions.eclass kde5.eclass

[Johannes Huber]

On Sunday 28 June 2015 04:12:01 Michał Górny wrote:

  +   for lang in $(ls) ; do
 
 How about... for lang in *?

What is the advantage?

Greetings
-- 
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID FDF4F788

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

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

[Johannes Huber]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

# Johannes Huber j...@gentoo.org (18 Aug 2015)
# Masked for removal in 30 days. Does not compile with
# dev-python/PyQt4-4.11.4, which blocks stabilization.
# Dead upstream. Last commit 6 years ago. See bug #558020.
net-misc/guidedog
- -- 
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID FDF4F788
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1

iQJ8BAEBCgBmBQJV05vbXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0N0Y0MTczMjZGRTRGODM5M0MzOTU4RDAy
OTU0NDVDRUY5MDcyRDJGAAoJEClURc75By0vchUQAJa8SGKooITl/IFFNEo0M3EI
2Kasj6WnCpKZi8GYSVjGJGF8qnrALveYdSxcU2nPM6XD3Zkn/Us4OUA5pyIXS+UQ
dkaPCN1Lb0MJyTooYHTydtZcV1TU1qiSP4g/2ymhSekc1bWEgeC1ob4mmK6m3aBx
LyRWqPiwkcUffhgvGGWSr9iXAkEvwAsINTBUpfkJ8tcV12Kp94O6xkhwPalHjmbo
HO/QGQ3SvqQH9xQZnrIo4AbE+IfihiytRXWGwjRLVnkdqBNzXm9PgQAeca4M0N2h
3JbjIeQjAc2Xn3Uz8eNK1zukDk8hhRJviIOWw32BnHZt+TOD0dlQUMa/4vIG5nGD
R4SZ1rtfecxZ67hDUJH4ZYscxhiVDCQ/0/JdaDnrIfw1jmiDhaEQdGywGmAe73Ji
eot1Z71LS7a36S5Ze5lDS6HASq8wS1/q/4br2foJnbdXBkDIWxi1bpm7npFD+xoG
CyypwmZy55a8dmeBugZM9QxFmOZEnpEca2bDmOGNXyzNz4U24GfsC8kZJ6sM5bpF
BmurD5/QozK1GwjQMOewkJaqsbzvZIjC0uTz9kaV/+DjpTleRusmWnxul5V93HG3
CwphVBDyawcX2R2+eKZMM2GxDYtIvMep/J4Ix0/2mIysg+RN9ju9YRv+V5F3QW9L
sPyHd0bgLbq9M0gG1cuh
=1GBt
-END PGP SIGNATURE-

[gentoo-dev] Re: RFC: using Ninja in more CMake-based packages

[Johannes Huber]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am 06/07/15 um 17:08 schrieb Michał Górny:
 Hello, developers.
 
[snip]

 Sadly, there are two problems with using Ninja:
 
 1) it will not work with some packages,
 

[snip]

 
 So, what do you think? Should I start switching random packages to 
 Ninja whenever it works?
 
 Oh, and this would be done via something like:
 
 : ${CMAKE_MAKEFILE_GENERATOR:=Ninja}
 
 before inherit line. To respect user forcing another generator, and
 to get deps right.
 
 [1]:https://bugs.gentoo.org/show_bug.cgi?id=546336
 

FYI we have a tracker bug now[1]. Bug alias is ninja-porting Toralf
Förster is already tinderboxing it. If we have all bugs fixed we can
discuss to enable it globally.

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

Kreetings
- -- 
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID FDF4F788
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1

iQJ8BAEBCgBmBQJV1QcfXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0N0Y0MTczMjZGRTRGODM5M0MzOTU4RDAy
OTU0NDVDRUY5MDcyRDJGAAoJEClURc75By0v80oP/22dI/4S0b36oxM+fKwh13a+
6Q9RMflwZtd+OKLPaeqZEU3XS2E/F0r8WR/GDWzZuRRFpJbOXjVjaB+GwEwrvi7V
t5bN8Xu8wTMuACEc8RbJWl1WClnEm8pEyODutdwXaePSt+w4cIOivdNZopzdkgFD
LkNAMk7wbsb4RNnbdpcmIXEFn0SSZvV52B8nof9l1XMhPgwYACa2E7PyY/uVzWae
nP1NfZLM8HRI9S41+jS4hDdrpIls03XBvdcEZfDZ3Wiru5ibXEcyYcSbjzvNlUpp
N+wCSjbtawjVuWF/h/ltW07EXtJEqlz0PrdW2P6rf1H7G8Z0vmzLGPh1LJ4cOVYH
cTMmEagQJjKiQnv1z+ijJrpsEVAAerApVpcEtoDmFFSwjxgEr34dGlNETrTWAB8x
vv14aVp94T+o5satjNQSeB6jyPySO4slTEYlZ2NZpX50oelF1aUgX4glaxadU0Yb
5Nd+xu4W7eeZf1TJ/DNTx8kHOEHnGzff/JZ+4+tUrtR/V61fHGPWrFRmiBC2U2Br
HjdaCefWE+lEbJm81a4LH0k7S0axMPZQHCuuicUt3uy2eNxJpBOMMDe0xGfzadZ1
c26sJgU6SdQhGSwMy6PiQGYw8AY9ffQk7KTfGiX5E4oMiiWXGDTU6jschqw4+ZlI
45qYstN0xi7VeAut8uYJ
=6/bq
-END PGP SIGNATURE-

Re: [gentoo-dev] Where did vanilla-sources-3.14.x go?

[Johannes Huber]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


Am 08/16/15 um 10:43 schrieb Joakim Tjernlund:
 vanilla-sources 3.14.x is gone from the tree.
 
 Jocke
 

Thanks. This is fixed in git now. There was a missing file name suffix
.ebuild.

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=65afe5fc850ac9568cb
c89fa4efe66d78130ab1f

- -- 
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID FDF4F788
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1

iQJ8BAEBCgBmBQJV0GtiXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0N0Y0MTczMjZGRTRGODM5M0MzOTU4RDAy
OTU0NDVDRUY5MDcyRDJGAAoJEClURc75By0vEssP/jaaK0chMvz1dUQuts0gpY55
+bkuoDtktvPbGLlzucE62dSL0PQom3dPITr0ngwUfPJkdJndOXgtYZb2U5knr3tU
fRzIZ9utSFiBo4/XqRwfRBykeQGZP+dnwrZQ+Im0Vq1EVutclsZE+frBsNXbCDEK
8tXESQtT6NM3TgOPBkkdyfTER0wIz11zI2ypDnZGy/0pie34wAejY38tpzHg/Suk
prcQB+l1ruOzdgDFqpwrmNmTOwbZXNDPmL1p2ntaG9XdI7HUVKJH5pqlva0aG+dS
+rtsmLr+XXQCWjNHrAp766gjC8jLt0VxiEC+N+C3ZenUhOwNO45zbuBs5zf5AUbU
mfL4HXWHo9LloAaraRGsNxMkHwdccU+C7ZeCqWKRfDxELTQBWXVNooW2NGEIIMda
CS2BNqFACzK83C7tazI3eGGuoQzJeZ+L+eBvl/jS4vxK/uZ6cME4yL4zzW5QlV3E
aDNawPZrf3YgXvWUZSW2jMz7ov/2ykf9aREUoxbLpxC+EcR2Dmi9ZOFe1dmmXwtL
icyg8LoLud6DVuOJ/XxA28y13gQj4oX+gFF+9V9/ZkuLlhUeiIB4+op78C2gZjV+
c6lB588G+xrq7E9hbUqtrkq18EZPVQKw83fpSOKzwsQAXPm8eBSF/JzTWbbA+D5j
+RUPv1U9M6P7e2wl1DJa
=lu9g
-END PGP SIGNATURE-

Re: [gentoo-dev] RFC: News item about Nepomuk removal

[Johannes Huber]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi all,

given non-negative replies this is published now.

Greeting.

Am 08.08.2015 um 13:28 schrieb Johannes Huber:
 Hello Gentoos,
 
 please read and comment on the attached news item for the upcoming
 Nepomuk removal.
 
 Greetings,
 

- -- 
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID FDF4F788
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1

iQJ8BAEBCgBmBQJVyjmnXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0N0Y0MTczMjZGRTRGODM5M0MzOTU4RDAy
OTU0NDVDRUY5MDcyRDJGAAoJEClURc75By0vPt8QAJAz9KMS2/WZQ10ss2I5qqYI
3VM91lt2GQ0FBypu5sAiTFftqXOYdB7prY1iW4QmBWvFpR7Ul9qfeZED1dTHkS4F
yAZ4BfseaO2pVcQaQ/biKDxKOKBU7j/FJ94fSpLOuLju52Ed2+RJ3eKD6w9LBNjr
THVWiv6kQehMu4hk16EY5nRyAM8pRuU+iaZ2P5xthqhMnIieXhbxS77T9W6DHWnM
3U11y5lukcFBKWPoBVcfKWuQHaaobwW8QpAz0gOmb7kI4jm2Q5L2Y2oW3gfWR9pM
V2PmRZ7XwQ/SRYgTBRlL3vpkQQ7uq9VUcp2C0XfNbXDYRzh3af+0uvAiG6h8GilK
SeTbrcmEmE7DQVedbSNw78SX/GnU/Ql8KanNM01qc3oJfWfsxsFruezfDklNmQ83
ma+cSk3PR1ZOe6BmUKX9Wl+Jy/jS0eASxjHPd946W8KcOZNwzRhZxMJV5lOP09Xn
/cIJalaI3ZbAwtc1FldUDLbMwzQUXH8HsqkRHM5vdfXRcIflMA1ryKMGQbXgCWrQ
vSG999wCPtAG3skaqok8ZCaGr5qgqOkIGvv3I7wKY71OKCNe2wHuM5GmPW9uqtVI
RnchiDFxGnS5NiIehjo/AWal/fDT6V3C9JizlLYQ5wiEL+zIoWRtt+SzohXUcIHe
LR1TqelJ56TZ/p4ou8Lj
=EnjI
-END PGP SIGNATURE-
Title: Nepomuk removal
Author: Johannes Huber j...@gentoo.org
Content-Type: text/plain
Posted: 2015-08-11
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: dev-db/virtuoso-server

With KDE SC 4.13.0 release the default semantic desktop search engine
switched from Nepomuk to Baloo.[1] This change was honoured in Gentoo
by changing the semantic-desktop use flag to cover the new engine and
moving the old to nepomuk use flag.

The underlaying storage backend for Nepomuk aka Virtuoso DB has a lot
of unsolved upstream issues[2], therefore we will remove it. This means
packages with build options on the old stack will drop them. Other
packages which hard requiring it will be removed.

If you are still using Nepomuk you can switch to Baloo by globally
enable semantic-desktop and disabling nepomuk use flag in
/etc/portage/make.conf or using one of the kde desktop profiles.

[1] https://www.kde.org/announcements/4.13/
[2] https://bugs.gentoo.org/buglist.cgi?quicksearch=virtuoso
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1

iQJ8BAABCgBmBQJVyjeuXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0N0Y0MTczMjZGRTRGODM5M0MzOTU4RDAy
OTU0NDVDRUY5MDcyRDJGAAoJEClURc75By0vv+AQAMkio+WhdU+gE3rDNdKuRts4
aXafLqE8pIi+kcURGmsuWquc9hv90qcRgYdN7O12jIRHA9YLhsJCa8tbvDw9cP3r
17qG1FBwAE1qDDhWOAeMN+LovL5qnRnZNN52LSSbpFbCp7gzSwSGp+gRsNg3VYVW
LtwwYUm22DafFIfWAgk0ie/2H3JdTaJv/Ob++ZE6aQjlnLplQe9n0fGYmrp3EV8Y
gumVD3tH7327Ic2vexxvy/sWcPgbY4UeNXQKxlYkIpwcFzm/bjofqFHrq1xH5Dm5
arxMb56M98U5oVtrWve1+7TVDbWsOfOEjaEliAuel7QjS6aAMlQHoWhpn1maFCZX
vpTVW6JS0o+GbTg39+oGxQ/x6WCuNUW/kf3Y4SWxYygL61nrf/lK7EyBKefF0IZd
G+HDFXkMff2WXE/bp8GZRoGz5UCpWaEqx7blhNNQRTI8AXFQpMPdLJGpkIiepRIl
1FRCNeZ5GMlXjszsTxyU6YomYHqK+nalV2olcb1mu8u8DuEMdFWfY9ckQtMYQJ1i
9bxAGtZuQMiEGBp0PJ4JxBgpnRYhsQyry6MCCdBN7vEeb0Gwd/i3baG2xb8FNIEw
TRHYpD1NlaPoF8L7x2qn9eNbJSgM0d/y5y0ZVWnUes/yczBZEEHUfL/S8o5cX3bb
1PVTIWOsEtz0mzFI5Mfy
=6hti
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: RFC: News item about Nepomuk removal

[Johannes Huber]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



Am 09.08.2015 um 05:01 schrieb Duncan:
 Johannes Huber posted on Sat, 08 Aug 2015 13:28:08 +0200 as
 excerpted:
 
 Title: Nepomuk removal
 
 Looks good here, and the title's nice and short too. =:^)
 

Thanks for positive feedback.

Greetings
- -- 
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID FDF4F788
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1

iQJ8BAEBCgBmBQJVyjnsXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0N0Y0MTczMjZGRTRGODM5M0MzOTU4RDAy
OTU0NDVDRUY5MDcyRDJGAAoJEClURc75By0vJ6MQAK7lt/OdbDzTZLmyPdbQ376K
8QcvNF2dUtJa/nSHzlKxk1D+AEI9PfP6VQE2tkrk5uIEtr+KVfP91ZO8QCUeXUZT
wapWr4AldPaSxK6cwzW9/oHm0Ux4MU4VQKk4bgjR6ImjxDhYwJxc8OHosPzbviY1
/ABJbLIfj3Hp1XY1leSoY20rEBYmy1yRCkMPjVz7pCGEH1697sQIkmv5xBCaI4SA
Hb0AwpuQXzYyW4DIevZZH2PMyMj9WBVmjcg7VdQexf6JOySljit3Ws2tdLdHaUHu
Kz4Bm98h1KX3XnqUwnWIVhuAzvUR06C7e6Cm4M92PRX1Oyp5+W2HscAPGHLZEHCs
S7Y33ZSHwOU5EqysFm43fplLZxSfGy9+wysHBztjueb0qAjNYBlidFdMhv3ab0PB
JwPYzR5IdTuMk032RZKxjksS8yJlJazgL9SmfxVucK9/o9S46g5y86JgG9Ll+tln
sDXETQot5wPhN+wxniNTBSzR89paQARtFbEufrn53ITu2hwL3Log0iU1Poie0zZX
EADTyuXC6sLhrDwGZQZOH+OApL1LH6QM53chrpUCfpBuh08qgINo498wdB90/cdG
ctLUyofX71H+7rNxi5qt7kiFyjkF5aI2/gAktlVQJpFEfxnCZWHJLEIFLTYvSnnv
wOTt0X7ct7h4Mer8eOpU
=HwoP
-END PGP SIGNATURE-

[gentoo-dev] RFC: News item about Nepomuk removal

[Johannes Huber]

Hello Gentoos,

please read and comment on the attached news item for the upcoming Nepomuk
removal.

Greetings,
--
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID FDF4F788Title: Nepomuk removal
Author: Johannes Huber j...@gentoo.org
Content-Type: text/plain
Posted: 2015-08-08
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: dev-db/virtuoso-server

With KDE SC 4.13.0 release the default semantic desktop search engine
switched from Nepomuk to Baloo.[1] This change was honoured in Gentoo
by changing the semantic-desktop use flag to cover the new engine and
moving the old to nepomuk use flag.

The underlaying storage backend for Nepomuk aka Virtuoso DB has a lot
of unsolved upstream issues[2], therefore we will remove it. This means
packages with build options on the old stack will drop them. Other
packages which hard requiring it will be removed.

If you are still using Nepomuk you can switch to Baloo by globally
enable semantic-desktop and disabling nepomuk use flag in
/etc/portage/make.conf or using one of the kde desktop profiles.

[1] https://www.kde.org/announcements/4.13/
[2] https://bugs.gentoo.org/buglist.cgi?quicksearch=virtuoso


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

[gentoo-dev] Last rites: Nepomuk Co / virtuoso.eclass

[Johannes Huber]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Eclass:
virtuoso.eclass is only used by dev-db/virtuoso-odbc and
dev-db/virtuoso-server. Will be removed in 30 days as well.

Packages:
# Johannes Huber johu@@gentoo.org (13 Aug 2015)
# Nepomuk removal. Announced via portage news item on 2015/08/11.
# Removal in 30 days. Please switch to the default semantic desktop
# search engine Baloo by globally enabling semantic-destkop use
# flag or by using one of the provided kde/plasma desktop profiles.
dev-db/virtuoso-odbc
dev-db/virtuoso-jdbc
dev-db/virtuoso-server
dev-libs/shared-desktop-ontologies
dev-libs/soprano
dev-util/plasmate
kde-apps/nepomuk
kde-base/nepomuk-core
kde-base/nepomuk-widgets
kde-misc/ksoprano
kde-misc/nepomukshell
kde-misc/pgame
media-video/bangarang

- -- 
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID FDF4F788
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1

iQJ8BAEBCgBmBQJVzRCfXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0N0Y0MTczMjZGRTRGODM5M0MzOTU4RDAy
OTU0NDVDRUY5MDcyRDJGAAoJEClURc75By0vqV8P/04gM1nVzt5R12rSw4OqVJdb
JQM/I87X6qZ2xMk9H7VrUsNMgPjSHMQe2uYFoTFzAvoF1JaE2lgGAgP5yIKiP1qs
d3s8tTJGnUxRNeJlLNgB1Hd/lNC0IdWqYGhq6eN+NJ3goSL3AEgKWO5VnQDcaPfO
MzqQLEhr5lrWErX3LGjqpGKgDpU9tkP2pQXLZUVsLrBjyZGN32oeYP29s2jPK84A
+B3QwcLflnI2RlnaMYuXOnDjVryJilttUqkUG16n5Zm14dVq2IxQ1iJ45HlJNiz5
8JThOc7akiG3+WMQ9Tl3woYjxUcbN/zdFbjLc5QWkCudbWHvnriRV/Nz8WdSbMaA
REkaVAQVeEVr5bGOVHJ5YS5VDzikRq1P0CTWERWn+lHcut2AVpavrtQVZBM/u/t/
DoCrSh5KSLSZckzxkJeP1WSJubTesI/KiRlRzlCUg8O3TUvKEqIumL4ZkpFx7U4m
NCPkXG4KnZpWY6UZBhjbPSsHwYSUACLgRlMna9fIzDwdsqBLMnGyiyzP5fXhicsN
BcOha7+QBCaWjX0nZZWb/BQDpnQNkVLniV8cHN/M4OK/QK4O3mpZ767HSOUho/2S
FxpeT8BycZRm5IQP/2nBtsI5n/L+AHtTiuhU3jk1ySc/zAK/W6td0xmgVB40Adby
dkZ5XQ99LfXBtrRdZAzS
=Zuh2
-END PGP SIGNATURE-

[gentoo-dev] Last rites: kde-base/{akonadi,kdepim-strigi-analyzer}

[Johannes Huber]

Konsole output
Konsole output
# Johannes Huber j...@gentoo.org (10 Aug 2015)
# Masked for removal in 30 days. Not needed anymore for
# KDE Old PIM 4.4.2015.06.
kde-base/akonadi
kde-base/kdepim-strigi-analyzer

[gentoo-dev] RFC: EAPI 4 deprecated ban

[Johannes Huber]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello Gentoos Penguins,

if we want to attract more contributors we should consider to have one
supported EAPI (latest). EAPI 4 is the last not marked as deprecated
( EAPI 5). The move in ebuilds from EAPI 4 to EAPI 5 is very simple
replacing the declaration. As we have now git in place we could easily
do this with one commit (awesome).

So please discuss this to get it ready for decision on next council
meeting.

Have fun,
- -- 
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID FDF4F788
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1

iQJ8BAEBCgBmBQJVzmZCXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0N0Y0MTczMjZGRTRGODM5M0MzOTU4RDAy
OTU0NDVDRUY5MDcyRDJGAAoJEClURc75By0vH6EP/iFqCNmAyKKz7TYsgLVlN72V
As/RpxAp3ag+pPN/vKzmIEA8ZyDKatgaAWWtdKdq3vHFXNghopvxbFjp3a0sxoth
ds0mLUhFpNCYoT8zNS+H91OwAjkL+3VUqRLYg8yTdvBHq++3QnB0ghEfEXM0sff5
CovLLZQov4qrCnGsve2vUQSEdINEEuETmZ3hO/JuiqqT8lOtO6w3N/eXQ/L2VOlD
M/ZcxRXlHoG7SkEs2vnPocaKOAYgAQITv6Cup0zPRFNjAmiWq3DX+xtLieJFhdkL
wOPqfSBzcHCHsJ2XVen7FW0SnYmQJniEfKSwwjneJs+HJb+m8iOQahQ8l4yz8zwP
hNwuu8dxYxK4/x9eQJkSlR1+mcoGv2IVOadme7XlTX9BEmGhTK7ABZyoFlvh4Cfd
Lkgog8DVb5o53kv67nKC87T2zVyPsL06uLVM6O5FbYaEa509aHsElgfnF+3Dmpyp
0I+3gj5oeYl2ScHNUaHZovUTMr7zVRHvwtLlFJcIveCY867x8xrccScQKgw+j9X/
1sNFCYQh2HJRh0xDBr/g8E5KW6HKJN4haQdqOHsyRW+9+j1GgT1IkgYXGyr2n8TB
L9wvyaSlwEFuKj6DvhzK02h5W8pCn86Sxog9z4vXEvdUs9pz2BlC992vww9bjVC6
4+gWbTtRBW4ERJZBpLhh
=jFSb
-END PGP SIGNATURE-

Re: [gentoo-dev] RFC: EAPI 4 deprecated ban

[Johannes Huber]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



Am 08/15/15 um 00:19 schrieb Andrew Savchenko:
 Hi,
 
 While I have no objections about EAPI 4 deprecation (except 
 concerns mentioned above), I see no strong need for this also. Just
 declare EAPI 5 as recommended. Having legacy support for EAPI 4
 will not hurt possible contributions.

Just imagine that the Gentoo developer quiz doesn't contain question
about ancient stuff. Would reduce the question count at least by some
questions. Which could lower the barrier to step forward for some
people. Or do we have enough developers?

 Best regards, Andrew Savchenko
 

- -- 
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID FDF4F788
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1

iQJ8BAEBCgBmBQJVzm8SXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0N0Y0MTczMjZGRTRGODM5M0MzOTU4RDAy
OTU0NDVDRUY5MDcyRDJGAAoJEClURc75By0vDeQQAI4BzX23qVATMaodkVFaxmHr
7qeXL+41nL6F36/q12v7ciIqhnooabC93z7xDQ8NBUac91k+L/UiVbEaJ2Y4EWPo
i3cV86uNR8McjB4WBpmUxWoSRhYP2eEL6vdEosadKeaSK24CjUU6x+4Q3QEdbSK+
qqkJElsrKgxaoIee6I2rL+/TQSBL2afUGpb2aShFzXEN+EkLgLrLux/eDK6er5Tw
p6OFYYes+IU9G9jW+M9kjjkRbr0SdSfzP4lCBRcncbPuRAxVeUwP5GQbELfDj8ar
ofAm38yJh8JWlJ5uJJobRs1ndw/DTHWrBgMi92LZk0SHH1aws/oIodx4QsXpeFlQ
gDMF2DV4PPMKxwSKRNPEppgVzcLHyJuC4TDReBo33utySw1wkWPiclephFl05H+d
1Jq8NlR9XX/ietsydWGxgIm/Of5ahT6Hc1T7NM7TfbM8LmmrnllLTXKSW1ClOua/
j5/DKagD6gOr4vjqJFSbD4l+m1hLh1hJai8dJIYM6seK9Z31KEZqIhuf8T5UDHP2
jIQdVKkfcw0om/HpTAS+yYAd3LlioZeQCYy6unZpJ+PTuWbROAmNBcghgvu+OmHy
kfhJ7AihHbR9Kqu4rG7gtekBPenqAXuO82ypAAZzIgsZ7rbItsAPslzDkNIspRXv
NqHhSZAcAxH2WQoxfW5r
=Q5X5
-END PGP SIGNATURE-

Re: [gentoo-dev] RFC: EAPI 4 deprecated ban

[Johannes Huber]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



Am 08/15/15 um 07:35 schrieb Michał Górny:
 
 This is a cheap hack, not a conversion. Proper conversion to a new
 EAPI is about using the new EAPI features. Not marking it 'done', 
 and pretending there's nothing more to do.
 

Yeah you are right. I rephrase, let's deprecate it.

- -- 
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID FDF4F788
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1

iQJ8BAEBCgBmBQJVzwTpXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0N0Y0MTczMjZGRTRGODM5M0MzOTU4RDAy
OTU0NDVDRUY5MDcyRDJGAAoJEClURc75By0vNhAQAIB1BX3mTI2r2PMR2MG+8kKq
mrWgp2321qdJgcsMl7cJUb5QC4nukVLrkQW1IJ7JpGA37B2/xzcS1Kmonu2XaYX+
YGQuSqA4/jn2t5EZogtxs+ld8X9jpcnFPD8xNqW6WhbOGeinBQURli+cR2UMUJbs
HZohDF7KhithrJE6sWyFiSxYhwNnXKmkCJY3zJSy0B+n+3P6URDlRhGM/uGktxj/
TBIeavRmzOoS/QhsU9ytRhh1SDk8JnEEs3EvORPSIyzRpwugXLMzKw6rzqzRZ0RN
PgfwYA/Sp4Rc6tFg7D/0w7cD1DsTwVoD20OdDB3rV/N+PVwCXLUCF8xyZMuqcRpv
zgWCn8ezU+dmPYG80rebUqg/MsGR4h3dr4a8QzQG/HdqIDnYtxD/V6yw/VoFaAmN
sCSOX9o3ix8GOmwKelzGTGxcwusqBYuAYaW5QjnKExwJ0NxW1N19B0RsrxjmACBn
MN2wMn61WLDPoqfje98LIpaBPNAKnS+if1Hp9xvs5KNAKipf2IOS2MPvialdMpUs
RcKKdDwdhpZLn2x0Rjhd3GqMmjiaxz/iBGJ7r1XtIt7YgeauxAs4T/XG0EAPYiHP
OyB/w8XmSMQw9WTiSLlP8BxnzKm+SV6D2YnBKsa0ZgMaVJSsmB9v14Bm9POyJW0R
46FcWy19AlYBX74Ai6Rz
=kvNL
-END PGP SIGNATURE-

Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

[Johannes Huber]

Am Mittwoch 08 Juni 2016, 15:16:57 schrieb Alexander Berntsen:
> In the end, Gentoo might make a gigantic leap into the future with a
> truly modular distribution. If anyone wants to look at distros that
> get this more right than Gentoo, have a look at e.g. NixOS and Exherbo.

This statement is not feeded with numbers. Distrowatch tells something else.

> What are your thoughts?

Overcomplex mess. This doesn't work on distro level. User have already decided 
which are the successful distros. Those with a central main repo. 

[gentoo-dev] Last rites: kde-apps/superkaramba

[Johannes Huber]

# Johannes Huber <j...@gentoo.org> (31 May 2016)
# Masked for removal in 30 days. Declared as dead by
# upstream in 2015. Last release with KDE Applications 15.08.3.
# Exported to user maintained overlay kde-sunset.
kde-apps/superkaramba

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

[gentoo-dev] Last rites: kde-apps/kdesdk-strigi-analyzer

[Johannes Huber]

# Johannes Huber <j...@gentoo.org> (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
kde-apps/kdesdk-strigi-analyzer

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

Re: [gentoo-dev] metadata.xml GLEP for review

[Johannes Huber]

Am Mittwoch 16 März 2016, 19:43:21 schrieb Michał Górny:
> Hello, all.
> 
> Long story short: while working on various metadata.xml-related
> aspects, it bite us pretty hard that we lack proper spec for
> metadata.xml file. What we have is pretty much the DTD, some partial
> GLEPs (that sometimes provide incorrect info) and random bugs. ml
> posts...
> 
> Therefore, I've been slowly writing a proper GLEP that would describe
> all of metadata.xml in detail. Here's the current draft for review:
> 
> https://wiki.gentoo.org/wiki/User:MGorny/GLEP:68

Hello Michal,

just a crazy idea came to my mind: How about to add HOMEPAGE and DESCRIPTION 
from ebuild to metadata.xml. So that this duplicated info in ebuilds can be 
dropped in future EAPI?

Greetings,
Johannes

[gentoo-dev] Last rites: KDE Toys

[Johannes Huber]

# Johannes Huber <j...@gentoo.org> (22 May 2016)
# Masked for removal in 30 days. Declared as dead by
# upstream in 2015. Last release with KDE Applications 15.08.3. 
# Exported to user maintained overlay kde-sunset.
kde-apps/amor
kde-apps/kdetoys-meta
kde-apps/ktux

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

[gentoo-dev] Last rites: kde-apps/pairs

[Johannes Huber]

# Johannes Huber <j...@gentoo.org> (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.
kde-apps/pairs

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

[gentoo-dev] Last rites: kde-plasma/kactivities-workspace

[Johannes Huber]

# Johannes Huber <j...@gentoo.org> (25 Jul 2016)
# Upstream temp workaround. No reverse dependencies.
# Removal in 30 days.
kde-plasma/kactivities-workspace


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

[gentoo-dev] Last rites: kde-apps/ksnapshot

[Johannes Huber]

# Johannes Huber <j...@gentoo.org> (14 Jul 2016)
# No longer released upstream. Use kde-apps/spectacle instead.
# Masked for removal in 30 days.
kde-apps/ksnapshot

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

Re: [gentoo-dev] Last rites: kde-apps/ksnapshot

[Johannes Huber]

Please check systemsettings -> shortcuts -> 4th tab.

Greetings,
Johannes

Am Donnerstag 14 Juli 2016, 21:26:04 schrieb Alon Bar-Lev:
> Just tried to switch.
> Print-Screen shortcut is not working, any idea why?
> Saw some similar issues, but could not find out what is wrong as most
> of the fixes are embedded.
> Thanks!
> 
> On 14 July 2016 at 20:33, Johannes Huber <j...@gentoo.org> wrote:
> > # Johannes Huber <j...@gentoo.org> (14 Jul 2016)
> > # No longer released upstream. Use kde-apps/spectacle instead.
> > # Masked for removal in 30 days.
> > kde-apps/ksnapshot

Re: [gentoo-dev] Last rites: kde-apps/ksnapshot

[Johannes Huber]

Am Donnerstag 14 Juli 2016, 21:47:10 schrieb Alon Bar-Lev:
> I have only three: Application, Global, Web
> Shouldn't it be integrated into Global?

Maybe this helps:
https://bbs.archlinux.org/viewtopic.php?id=206600

[gentoo-dev] Package up for grab

[Johannes Huber]

x11-misc/kdocker - Does not use technology stack by kde, pure Qt/x11 app. 
Moved from launchpad to github (https://github.com/user-none/KDocke). Needs 
EAPI + version bump.

Cheers
-- 
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID FDF4F788


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

[gentoo-dev] Last rites: kde-apps/kde-wallpapers

[Johannes Huber]

# Johannes Huber <j...@gentoo.org> (29 Jul 2016)
# Masked for removal in 30 days. Dead by upstream, superseded by
# kde-plasma/plasma-workspace-wallpapers. Last release with
# 15.08.3. Exported to kde-sunset overlay.
kde-apps/kde-wallpapers

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

[gentoo-dev] Last rites: kde-apps/kdeartwork*, kde-apps/kde-base-artwork

[Johannes Huber]

# Johannes Huber <j...@gentoo.org> (1 Aug 2016)
# Masked for removal in 30 days. Dead by upstream. Last release
# with 15.08. Exported to kde-sunset overlay.
kde-apps/kdeartwork-colorschemes
kde-apps/kdeartwork-desktopthemes
kde-apps/kdeartwork-emoticons
kde-apps/kdeartwork-iconthemes
kde-apps/kdeartwork-kscreensaver
kde-apps/kdeartwork-meta
kde-apps/kdeartwork-styles
kde-apps/kdeartwork-wallpapers
kde-apps/kdeartwork-weatherwallpapers
kde-apps/kde-base-artwork


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

[gentoo-dev] Last rites: kde4-meta-pkg.eclass

[Johannes Huber]

Removal in 30 days. No consumers left. Exported to kde sunset overlay.

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

[gentoo-dev] Last rites: kde-apps/kdepim-icons

[Johannes Huber]

# Johannes Huber <j...@gentoo.org> (17 Jul 2016)
# Masked for removal in 30 days. Superseded by
# kde-frameworks/oxygen-icons.
kde-apps/kdepim-icons

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

[gentoo-dev] Last rites: app-misc/strigi

[Johannes Huber]

# Johannes Huber <j...@gentoo.org> (28 Jun 2016)
# Masked for removal in 30 days. Dead upstream. Was only
# useful with Nepomuk, superseded by Baloo long time ago.
# No reverse dependencies, bug #583716.
app-misc/strigi


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

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

[Johannes Huber]

# Johannes Huber <j...@gentoo.org> (4 Aug 2016)
# Masked for removal in 30 days. Dead upstream. Last release
# 7 years ago. No reverse dependencies. Use kde-apps/ffmpegthumbs
# or media-video/ffmpegthumbnailer instead.
media-video/kffmpegthumbnailer

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

Re: [gentoo-dev] Packages up for grabs

[Johannes Huber]

Am Samstag 06 August 2016, 14:44:15 schrieb Pacho Ramos:
> This packages are now up for grabs:
> app-editors/nvi
> dev-cpp/yaml-cpp

I take this one.

Greetings,
Johannes

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

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

[Johannes Huber]

# Johannes Huber <j...@gentoo.org> (30 Jun 2016)
# Andreas K. Huettel <dilfri...@gentoo.org> (22 Mar 2012)
# Masked for removal in 30 days. Dead upstream. Superseded
# by oxygen-gtk long time ago.
#
# (Original mask: Even its author admits that it's an ugly
# hack. Crashes e.g. firefox with kde-4.8. Unmask at your own
# risk.)
kde-misc/kgtk

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

[gentoo-dev] Last-rites: Plasma 4 & related

[Johannes Huber]

# Johannes Huber <j...@gentoo.org> (19 Jan 2017)
# Plasma 4 removal in 30 days.
# Please read news item. All packages export to kde-sunset overlay.
# Gentoo bugs #473678, #528612, #537062, #586814.S
kde-plasma/bluedevil:4
kde-plasma/freespacenotifier
kde-plasma/kcheckpass
kde-plasma/kcminit
kde-plasma/kdebase-cursors
kde-plasma/kdebase-pam
kde-plasma/kdebase-startkde
kde-plasma/kde-gtk-config:4
kde-plasma/kdeplasma-addons:4
kde-plasma/kdm
kde-plasma/kephal
kde-plasma/khotkeys:4
kde-plasma/kinfocenter:4
kde-plasma/klipper
kde-plasma/kmenuedit:4
kde-plasma/krunner
kde-plasma/ksmserver
kde-plasma/kscreen:4
kde-plasma/kscreensaver
kde-plasma/ksplash
kde-plasma/ksshaskpass:4
kde-plasma/kstartupconfig
kde-plasma/kstyles
kde-plasma/ksysguard:4
kde-plasma/ksystraycmd
kde-plasma/kwin:4
kde-plasma/kwrited:4
kde-plasma/libkgreeter
kde-plasma/libkscreen:4
kde-plasma/liboxygenstyle
kde-plasma/libplasmaclock
kde-plasma/libplasmagenericshell
kde-plasma/libtaskmanager
kde-plasma/milou:4
kde-plasma/plasma-nm:4
kde-plasma/plasma-workspace:4
kde-plasma/powerdevil:4
kde-plasma/solid-actions-kcm
kde-plasma/systemsettings:4
kde-misc/about-distro
kde-misc/adjustableclock
kde-misc/baloo-kcmadv
kde-misc/bkodama
kde-misc/chromi
kde-misc/commandwatch
kde-misc/cpuload
kde-misc/customizable-weather
kde-misc/drop2ftp
kde-misc/emerging-plasmoid
kde-misc/eventlist
kde-misc/eyesaver
kde-misc/fancytasks
kde-misc/geekclock
kde-misc/gx-mail-notify
kde-misc/hdaps_monitor
kde-misc/homerun
kde-misc/kbstateapplet
kde-misc/kcm-grub2
kde-misc/kcm-touchpad
kde-misc/kcm-ufw
kde-misc/kcometen4
kde-misc/kdmthemegenerator
kde-misc/kepas
kde-misc/kgrubeditor
kde-misc/kprayertime
kde-misc/kraidmonitor
kde-misc/krunner-googletranslate
kde-misc/krunner-kopete-contacts
kde-misc/ksplasher
kde-misc/ktrafficanalyzer
kde-misc/kvkbd
kde-misc/miniplayer
kde-misc/nightmode
kde-misc/nvdevmon
kde-misc/plasma-applet-daisy
kde-misc/plasma-emergelog
kde-misc/plasma-lionmail
kde-misc/plasma-mpd-nowplaying
kde-misc/plasma-network-status
kde-misc/plasma-photooftheday
kde-misc/plasma-widget-menubar
kde-misc/plasma-widget-message-indicator
kde-misc/plasma-wifi
kde-misc/plasmatvgr
kde-misc/plasma-wifi
kde-misc/plasmoid-workflow
kde-misc/pyrad
kde-misc/quickaccess
kde-misc/redshift-plasmoid
kde-misc/serverstatuswidget
kde-misc/smooth-tasks
kde-misc/stdin-plasmoid
kde-misc/steamcompanion
kde-misc/stock-quote
kde-misc/synaptiks
kde-misc/wicd-client-kde
kde-misc/yawp
net-libs/libbluedevil
net-libs/libmm-qt
net-libs/libnm-qt
x11-themes/dekorator
x11-themes/nitrogen
x11-themes/skulpture
x11-themes/smaragd


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

Re: [gentoo-dev] Unused profiles

[Johannes Huber]

Hi Michal,

> default/linux/arm/13.0/armv4/desktop/plasma
> default/linux/arm/13.0/armv4t/desktop/plasma
> default/linux/arm/13.0/armv5te/desktop/plasma
> default/linux/arm/13.0/armv6j/desktop/plasma
> default/linux/arm/13.0/armv7a/desktop/plasma
> default/linux/arm/13.0/desktop/plasma/systemd

bug 588476 waiting for answer by arm.

> default/linux/powerpc/ppc64/13.0/desktop/kde/systemd

will be removed in 30 days after Plasma 4 removal.

Best regards,
Johannes



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

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

[Johannes Huber]

# Johannes Huber <j...@gentoo.org> (26 Feb 2017)
# Masked for removal in 30 days. No maintainer. Dead upstream.
# Current version is outdated. Open QA issues (#522676,#526284).
# Bug #607998.
dev-vcs/veracity

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

[gentoo-dev] Last rites: kde-misc/{fsrunner,kcaldav,takeoff}

[Johannes Huber]

# Johannes Huber <j...@gentoo.org> (07 Nov 2016)
# Masked for removal in 30 days. Dead upstream.
# Hosted on google code, which shutdowns end of the year.
# Support for deprecated Plasma 4 only.
kde-misc/fsrunner
kde-misc/kcaldav
kde-misc/takeoff


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

[gentoo-dev] Last rites: kde-base/legacy-icons

[Johannes Huber]

# Johannes Huber <j...@gentoo.org> (28 Nov 2016)
# Masked for removal in 14 days. Gentoo temp workaround package.
# Superseded by kde-frameworks/oxygen-icons:5.
kde-base/legacy-icons

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

[gentoo-dev] Last rites: kde-apps/kuser

[Johannes Huber]

# Johannes Huber <j...@gentoo.org> (16 Nov 2016)
# Masked for removal in 30 days. Declared as dead by upstream.
# Last release with 16.08.3. Exported to kde-sunset overlay.
kde-apps/kuser


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

[gentoo-dev] Last rites: x11-themes/crystal

[Johannes Huber]

# Johannes Huber <j...@gentoo.org> (20 Nov 2016)
# Masked for removal in 30 days. Dead upstream. Only supports
# deprecated Plasma 4. Fails to build with newer
# kde-base/kdelibs (bug #558516). Fails to build with ninja
# (bug #575828).
x11-themes/crystal


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

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

[Johannes Huber]

# Johannes Huber <j...@gentoo.org> (04 Nov 2016)
# Masked for reomval in 30 days. Superseded by kde-plasma/plasma-nm.
# Only support for deprecated Plasma 4. Exported to kde-sunset overlay.
kde-misc/networkmanagement

-- 
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID FDF4F788


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

Re: [gentoo-dev] News item: KDE Workspaces 4.11 and KDE profile removal

[Johannes Huber]

Am Samstag, 14. Januar 2017, 14:37:29 CET schrieb Andreas Sturmlechner:
> I've updated the news item based on feedback on my initial mail,
> thanks to jstein.
> 
> mva, anything missing in the list of profiles here? I've grepped
> profiles.desc for kde to get the current list.
> 
> Title: KDE Workspaces 4.11 and KDE profile removal
> Author: Andreas Sturmlechner 
> Content-Type: text/plain
> Posted: 2017-01-08
> Revision: 1
> News-Item-Format: 1.0
> Display-If-Installed: kde-plasma/kdebase-startkde
> Display-If-Installed: kde-plasma/kdm
> Display-If-Profile: default/linux/alpha/13.0/desktop/kde
> Display-If-Profile: default/linux/alpha/13.0/desktop/kde/systemd
> Display-If-Profile: default/linux/amd64/13.0/desktop/kde
> Display-If-Profile: default/linux/amd64/13.0/desktop/kde/systemd
> Display-If-Profile: default/linux/arm/13.0/desktop/kde
> Display-If-Profile: default/linux/arm/13.0/desktop/kde/systemd
> Display-If-Profile: default/linux/arm/13.0/armv4/desktop/kde
> Display-If-Profile: default/linux/arm/13.0/armv4t/desktop/kde
> Display-If-Profile: default/linux/arm/13.0/armv5te/desktop/kde
> Display-If-Profile: default/linux/arm/13.0/armv6j/desktop/kde
> Display-If-Profile: default/linux/arm/13.0/armv7a/desktop/kde
> Display-If-Profile: default/linux/ia64/13.0/desktop/kde
> Display-If-Profile: default/linux/ia64/13.0/desktop/kde/systemd
> Display-If-Profile: default/linux/m68k/13.0/desktop/kde
> Display-If-Profile: default/linux/powerpc/ppc32/13.0/desktop/kde
> Display-If-Profile: default/linux/powerpc/ppc32/13.0/desktop/kde/systemd
> Display-If-Profile:
> default/linux/powerpc/ppc64/13.0/32bit-userland/desktop/kde
> Display-If-Profile:
> default/linux/powerpc/ppc64/13.0/32bit-userland/desktop/kde/systemd
> Display-If-Profile:
> default/linux/powerpc/ppc64/13.0/64bit-userland/desktop/kde
> Display-If-Profile:
> default/linux/powerpc/ppc64/13.0/64bit-userland/desktop/kde/systemd
> Display-If-Profile: default/linux/sh/13.0/desktop/kde
> Display-If-Profile: default/linux/sparc/13.0/desktop/kde
> Display-If-Profile: default/linux/sparc/13.0/desktop/kde/systemd
> Display-If-Profile: default/linux/x86/13.0/desktop/kde
> Display-If-Profile: default/linux/x86/13.0/desktop/kde/systemd
> 
> KDE Workspaces 4.11 has reached end of life in Portage. Upstream dropped
> support in 2015-08-19, no security bugs have been fixed since then. It is
> therefore required for all users to upgrade to KDE Plasma 5.
> 
> KDM is being removed as well. Upstream recommends x11-misc/sddm instead
> which is pulled in by plasma-meta by default.
> OpenRC users edit /etc/conf.d/xdm and update DISPLAYMANAGER.
> Systemd users run: systemctl reenable sddm.service
> 
> Part of the cleanup will also be the KDE desktop profile, which is
> superseded by the Plasma desktop profile. Please follow the detailed
> upgrade guide.[1]
> 
> KDE Workspaces 4.11 packages will be moved to kde-sunset overlay.[2]
> 
> [1] https://wiki.gentoo.org/wiki/KDE/Plasma_5_upgrade
> [2] https://wiki.gentoo.org/wiki/Overlay:Kde-sunset

Hi Andreas,

thanks that you take care of the needed news item. I would suggest to replace 
KDE Workspace 4.11 with KDE Plasma 4  in subject and body because that name is  
used in the main Gentoo KDE wiki article since some time. [1]

Greetings,
Johannes

[1] https://wiki.gentoo.org/wiki/KDE


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

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

[Johannes Huber]

# Johannes Huber <j...@gentoo.org> (05 Dec 2016)
# Masked for removal in 30 days. Dead upstream.
# Relies on deprecated dev-qt/qt3support.
# Superseded by kde-apps/kolourpaint.
media-gfx/kiconedit

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

[gentoo-dev] Last rites: kde-apps/ktp-l10n

[Johannes Huber]

# Johannes Huber <j...@gentoo.org> (19 Dec 2016)
# Masked for removal in 14 days. Superseded by kde-apps/kde-l10n.
# No reverse dependencies.
kde-apps/ktp-l10n


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

[gentoo-dev] Last rites: kde-apps/kdgantt2

[Johannes Huber]

# Johannes Huber <j...@gentoo.org> (19 Dec 2016)
# Masked for removal in 14 days. Superseded by dev-libs/kdiagram.
# No reverse dependencies. Never consumed by unmasked packages.
kde-apps/kdgantt2

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

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

[Johannes Huber]

# Johannes Huber <j...@gentoo.org> (25 Dec 2016)
# Masked for removal in 30 days. Dead upstream. No reverse dependencies.
# No maintainer. Was introduced for media-sound/tomahwak. Uses deprecated
# EAPI.
net-libs/qtweetlib

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

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

[Johannes Huber]

# Johannes Huber <j...@gentoo.org> (22 Mar 2017)
# Masked for removal in 14 days. Echonest service is gone
# since 2016/05/31. No reverse dependencies. Bug #587972.
media-libs/libechonest

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

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

[Johannes Huber]

# Johannes Huber <j...@gentoo.org> (14 Apr 2017)
# Masked for removal in 30 days. Dead upstream since
# KDELibs 4 port several years ago. Repository gone.
# Superseded by gwenview and okular. Fails to build
# with gcc 6 (bug #614304).
media-gfx/kuickshow

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

[gentoo-dev] Last rites: media-fonts/bitstream-cyberbit

[Johannes Huber]

# Johannes Huber <j...@gentoo.org> (11 May 2018)
# Masked for removal in 30 days (bug #655466). Fails to
# fetch distfile (bug #655454). Access not existing
# directories (bug #467128). Uses deprecated EAPI 2
# (bug #648050).
media-fonts/bitstream-cyberbit




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] x11-terms/xterm up for grabs

[Johannes Huber]

On 19.06.2018 06:53, Matt Turner wrote:

xterm isn't part of the core set of X applications and libraries from
FreeDesktop.org and it's not something I personally use. I've dropped
x11@ ownership of it.

Please pick it up if you use it or it interests you. There are only 4
bugs filed against it. None looks particularly difficult and the
upstream maintainer is active on bugzilla.


I will take it.

Cheers,
Johannes

[gentoo-dev] What means bup?

[Johannes Huber]

Hi all,

english is not my mother language, so please clarify what bup means, 
just seen here:


https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ee0e0401478cf30b3ced0405f6b89391e05d2397

Just checked if it was a typo, but can't be:
git log --oneline --grep bup | count -l
Expected 0 lines, got 1248.

Best regards,
Johannes

[gentoo-dev] Re: Packages up for grabs: net-news/rssguard,...

[Johannes Huber]

Am 18.07.2018 um 23:38 schrieb Jonas Stein:
> ...
> app-crypt/zulucrypt
> app-admin/profile-cleaner
> ...

Took those two.

Best regards,
Johannes



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Packages up for grabs: app-backup/fsarchiver, app-cdr/daa2iso...

[Johannes Huber]

Am 19.07.2018 um 10:10 schrieb Michał Górny:
> Hello,
> 
> Due to Markos Chandras' prolonged absence, the following packages are up
> for grabs now.
> app-doc/devmanual
> net-misc/sshpass
> sys-apps/cpuid
> sys-apps/daemonize
> sys-fs/fuse-zip
> x11-misc/fpm2
> x11-misc/obconf

I took those by myself.

> x11-themes/tactile
> x11-themes/tactile3

The themes will be maintained by desktop-misc.

Best regards,
Johannes




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: What means bup?

[Johannes Huber]

Am 18.07.2018 um 09:26 schrieb Matthew Thode:
> On 18-07-18 09:16:07, Johannes Huber wrote:
>> Hi all,
>>
>> english is not my mother language, so please clarify what bup means, just
>> seen here:
>>
>> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ee0e0401478cf30b3ced0405f6b89391e05d2397
>>
>> Just checked if it was a typo, but can't be:
>> git log --oneline --grep bup | count -l
>> Expected 0 lines, got 1248.
>>
> 
> It's similiar to a sound you make when you touch something's nose.
> *boop*
> 
> I just prefer bup instead.  I generally only use it when doing simple
> bumps of packages (copy ebuilds with only keyword edits).
> 

Hi Matthew,

thank you for the explanation. As the ChangeLogs are expanded for rsync
or can be inspected via git I would expect from a user standpoint to
read proper entries.

Thanks in advance,
Johannes



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] rfc: moving default location of portage tree

[Johannes Huber]

Am 09.07.2018 um 20:05 schrieb Rich Freeman:
> On Mon, Jul 9, 2018 at 1:40 PM Ulrich Mueller  wrote:
>>
>>> On Mon, 9 Jul 2018, William Hubbs wrote:
>>
>>> is there a tracker for when the portage tree can be moved out of
>>> /usr/portage by default?
>>
>>> If not, what is the status of us being able to do this?
>>
>> Please remind me, what was the plan for the new location?
>> Somewhere under /var/db or /var/lib, IIRC?
>>
> 
> I'd also consider /var/cache here as well.  FHS specifically suggests
> using it for web caches and the like (let's set aside the issue with
> making that global), though for the most part it is more metadata
> caching.  A key principle is that it can be wiped without loss of
> data, and I think that is generally true for the repository since it
> can be synced.
> 
> Stuff in /var/lib can't be deleted without some kind of loss of
> application state.  /var/db isn't in FHS, and I note that even mysql
> sticks its stuff in /var/lib.
> 

Imho it would make sense to split up portage files with this change.
Move the tree (ebuilds, profiles etc) to /var/lib/... and the metadata
cache to /var/db as it can be regenerated out of the tree.

Best regards,
Johannes



signature.asc
Description: OpenPGP digital signature