[gentoo-dev] Last rites: app-office/openproj-bin

[Chris Reffett]

# Chris Reffett <creff...@gentoo.org> (08 Jan 2017)
# Superseded by projectlibre-bin, please migrate to that.
# Masked for removal in 30 days.
app-office/openproj-bin



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] New Working Group established to evaluate the stable tree

[Chris Reffett]

On August 14, 2016 5:49:48 PM EDT, Kent Fredric  wrote:
>On Sun, 14 Aug 2016 22:45:07 +0100
>Ciaran McCreesh  wrote:
>
>> What's a Working Group, and how is it related to a Project? Shouldn't
>> there be a GLEP to define what a Working Group is first?
>
>So if a group of people wanted to write such a GLEP ... would they have
>to be part of a defined Project first, or would they form a Working
>Group, and then be stuck in a recursive loop needing themselves
>defined before they can define themselves?

Friendly reminder that anyone may submit a GLEP, it doesn't need to be on 
behalf of an official group. If memory serves, there isn't even a requirement 
that the submitter/"champion" even be a Gentoo dev. So although there is a 
theoretical recursion issue, in practice it's a silly question.

creffett
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[gentoo-dev] New project: Theology

[Chris Reffett]

A bit late, but official announcement of the herd->project conversion of
theology to follow GLEP 67.

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

creffett



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: ban EAPI 1

[Chris Reffett]

On 6/10/2015 4:43 PM, Ulrich Mueller wrote:
 Hi,
 The number of EAPI 1 ebuilds in the Portage tree has decreased to
 a total of 60, corresponding to 0.16 %.
 
 We briefly discussed in the QA team if we should demote EAPI 1 in
 layout.conf from eapis-deprecated to eapis-banned. This would
 have the consequence that repoman would refuse to commit packages
 containing such ebuilds. AFAICS there would be no impact on users.
 
 What do you think?
 
 Ulrich
 
Make it so.

Re: [gentoo-dev] rfc: calling all eclass phase functions by default

[Chris Reffett]

On 8/18/2014 8:56 AM, hasufell wrote:
 hasufell:

 Even more interesting... you can work around this by inheriting
 base.eclass explicitly before e.g. unpacker.eclass, something like

 inherit base unpacker games

 = unpacker_src_unpack() is carried out by default (and the ebuild
 breaks if someone thinks the base.eclass is useless and removes it)

 inherit unpacker games

 = unpacker_src_unpack is not carried out by default although
 games.eclass does not directly overwrite it

 If you think any of this is sensible...

 
 Almost forgot, of course this does not work if you expect
 unpacker_src_unpacker() to run:
 inherit unpacker games base
 
 as well as
 inherit unpacker base games
 
 however
 inherit games unpacker base
 
 will work.
 
 And now... guess why the games herd made it a policy to always inherit
 games.eclass last. Because of the unpredictability of eclasses and that
 they may randomly add exported phase functions. It's a bit paranoid, but
 understandable, since we don't have any real rules here.
 
 So in the end 3 eclasses all tell you inherit me last! really!. Good
 luck with figuring out how to make a gnome game with python and multilib
 support work together. I can predict the days such a review would take
 in #gentoo-sunrise. Not less than 3.
 
Would it be feasible to add a repoman check for situations like this,
where the behavior of a phase is dependent on inherit order? If so, it
seems reasonable to me to require explicit calls to eclass functions in
these cases to make it clear what's being called when.

Chris Reffett

Re: [gentoo-dev] rfc: calling all eclass phase functions by default

[Chris Reffett]

On August 18, 2014 11:11:56 AM EDT, Michał Górny mgo...@gentoo.org wrote:
Dnia 2014-08-18, o godz. 09:22:46
Chris Reffett creff...@gentoo.org napisał(a):

 On 8/18/2014 8:56 AM, hasufell wrote:
  Almost forgot, of course this does not work if you expect
  unpacker_src_unpacker() to run:
  inherit unpacker games base
  
  as well as
  inherit unpacker base games
  
  however
  inherit games unpacker base
  
  will work.
  
  And now... guess why the games herd made it a policy to always
inherit
  games.eclass last. Because of the unpredictability of eclasses and
that
  they may randomly add exported phase functions. It's a bit
paranoid, but
  understandable, since we don't have any real rules here.
  
  So in the end 3 eclasses all tell you inherit me last! really!.
Good
  luck with figuring out how to make a gnome game with python and
multilib
  support work together. I can predict the days such a review would
take
  in #gentoo-sunrise. Not less than 3.
  
 Would it be feasible to add a repoman check for situations like this,
 where the behavior of a phase is dependent on inherit order? If so,
it
 seems reasonable to me to require explicit calls to eclass functions
in
 these cases to make it clear what's being called when.

Right now, we have no kind of repoman for eclasses. If you have time to
work on such a thing, please do. Otherwise, all we can do is put more
checks in ebuilds but that triggers the warning for the wrong people...

I was thinking more ebuild-side. Example: my ebuild inherits both cmake-utils 
and games eclasses, and I don't explicitly define src_compile, repoman full 
could pop up a warning like src_compile is ambiguous between 
cmake-utils_src_compile and games_src_compile, please explicitly define this 
phase and call the appropriate eclass function. I imagine that this would pop 
up a lot of warnings, but I feel like it would improve readability and make it 
explicit what should be going on where. I concede that it could make a lot more 
boilerplate code in ebuilds, so that's a potential issue, mostly just throwing 
out an idea here.

Chris Reffett

Re: [gentoo-dev] gentoo-x86 tree cleanup for 'DESCRIPTION ends with a '.' character' warnings

[Chris Reffett]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 8/12/2014 9:26 AM, Rich Freeman wrote:
[snip]
 I don't have a problem with QA recommending new tree policies, but 
 if they're going to do this the QA team ought to first ensure that 
 the team agrees (however they want to govern that), and then 
 communicate the policy before implementing it.  I'd also implement 
 it in documentation before doing so in repoman, otherwise we're 
 going to have a repoman full of 800 rules whose origin is a 
 mystery.  I'm fine with QA policies going into effect by default, 
 but communicating them allows objections to be raised and an
 appeal made to Council if necessary before we get too far along.
 This isn't just about due process - it is hard for developers to
 even comply with a policy they are unaware of.
 
 Rich
 
This isn't a QA policy, was not run by us as far as I can tell, and I
don't know where it came from or why it was added. +1 for revert, if
people want to run this by Council or QA later and actually get an
official decision we can talk about putting it back, but for now it's
generating a lot of noise for no real benefit. It's useless checks
like this that make people ignore repoman warnings.

Chris Reffett
QA Team Lead
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iEYEARECAAYFAlPqXvAACgkQ23laikJhg1QvTQCffjAZYIzBGBRlp1l/y6iydzTQ
3d0An12lbTbzr7nWe37qtoay7ktWUAs6
=6c3E
-END PGP SIGNATURE-

Re: [gentoo-dev] minimalistic emerge

[Chris Reffett]

On August 9, 2014 10:56:49 AM EDT, Igor lanthrus...@gmail.com wrote:
 [snip]
Just the main blockers are:

- Somebody has to implement this technology
- That requires time and effort
- People have to be convinced of its value
- Integration must happen at some level somehow somewhere in the
portage toolchain(s)
- People must opt in to this technology in order for the reports to
happen
- And only then can this start to deliver meaningful results.



IMHO seriously, it could be done if ONLY portage dev team would
implement 
an interface CAPABLE for HTTP reporting. Once the interface is there
but turned off 
by default - server side statistics are feasible. Personally I don't
see any future of 
this system unless it's coded in portage. Today - portage support
without server side 
- tomorrow - server side. 

Then write it. Portage's source is available to anyone. I remember that you 
were on this list earlier this year pushing for Portage QOS or something. 
Keep in mind what a significant number of people told you then: first, if you 
want to make some change, just do it and show us what you have, rather than 
asking  for votes and permission and changes. Second, repeatedly saying we 
should have (some feature) doesn't work if the people who would do the work 
(the portage team) don't see value in it. From the general response on the 
list, I would say this is the case. This means that if you want the feature, 
write it and come back with an implementation, since complaining about it is 
getting you nowhere.

Chris Reffett
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [gentoo-dev] minimalistic emerge

[Chris Reffett]

On August 9, 2014 10:56:49 AM EDT, Igor lanthrus...@gmail.com wrote:
[snip]
Just the main blockers are:

- Somebody has to implement this technology
- That requires time and effort
- People have to be convinced of its value
- Integration must happen at some level somehow somewhere in the
portage toolchain(s)
- People must opt in to this technology in order for the reports to
happen
- And only then can this start to deliver meaningful results.



IMHO seriously, it could be done if ONLY portage dev team would
implement 
an interface CAPABLE for HTTP reporting. Once the interface is there
but turned off 
by default - server side statistics are feasible. Personally I don't
see any future of 
this system unless it's coded in portage. Today - portage support
without server side 
- tomorrow - server side. 

Then write it. Portage's source is available to anyone. I remember that you 
were on this list earlier this year pushing for Portage QOS or something. 
Keep in mind what a significant number of people told you then: first, if you 
want to make some change, just do it and show us what you have, rather than 
asking for votes and permission and changes. Second, repeatedly saying we 
should have (some feature) doesn't work if the people who would do the work 
(the portage team) don't see value in it. From the general response on the 
list, I would say this is the case. This means that if you want the feature, 
write it and come back with an implementation, since complaining about it is 
getting you nowhere.

Chris Reffett

Re: [gentoo-dev] minimalistic emerge

[Chris Reffett]

On August 9, 2014 10:56:49 AM EDT, Igor lanthrus...@gmail.com wrote:
 [snip]
Just the main blockers are:

- Somebody has to implement this technology
- That requires time and effort
- People have to be convinced of its value
- Integration must happen at some level somehow somewhere in the
portage toolchain(s)
- People must opt in to this technology in order for the reports to
happen
- And only then can this start to deliver meaningful results.



IMHO seriously, it could be done if ONLY portage dev team would
implement 
an interface CAPABLE for HTTP reporting. Once the interface is there
but turned off 
by default - server side statistics are feasible. Personally I don't
see any future of 
this system unless it's coded in portage. Today - portage support
without server side 
- tomorrow - server side. 

Then write it. Portage's source is available to anyone. I remember that you 
were on this list earlier this year pushing for Portage QOS or something. 
Keep in mind what a significant number of people told you then: first, if you 
want to make some change, just do it and show us what you have, rather than 
asking  for votes and permission and changes. Second, repeatedly saying we 
should have (some feature) doesn't work if the people who would do the work 
(the portage team) don't see value in it. From the general response on the 
list, I would say this is the case. This means that if you want the feature, 
write it and come back with an implementation, since complaining about it is 
getting you nowhere.

Chris Reffett

Re: [gentoo-dev] minimalistic emerge

[Chris Reffett]

On August 9, 2014 11:46:54 AM EDT, Chris Reffett creff...@gentoo.org wrote:
On August 9, 2014 10:56:49 AM EDT, Igor lanthrus...@gmail.com wrote:
[snip]
Just the main blockers are:

- Somebody has to implement this technology
- That requires time and effort
- People have to be convinced of its value
- Integration must happen at some level somehow somewhere in the
portage toolchain(s)
- People must opt in to this technology in order for the reports to
happen
- And only then can this start to deliver meaningful results.



IMHO seriously, it could be done if ONLY portage dev team would
implement 
an interface CAPABLE for HTTP reporting. Once the interface is there
but turned off 
by default - server side statistics are feasible. Personally I don't
see any future of 
this system unless it's coded in portage. Today - portage support
without server side 
- tomorrow - server side. 

Then write it. Portage's source is available to anyone. I remember that
you were on this list earlier this year pushing for Portage QOS or
something. Keep in mind what a significant number of people told you
then: first, if you want to make some change, just do it and show us
what you have, rather than asking for votes and permission and changes.
Second, repeatedly saying we should have (some feature) doesn't work
if the people who would do the work (the portage team) don't see value
in it. From the general response on the list, I would say this is the
case. This means that if you want the feature, write it and come back
with an implementation, since complaining about it is getting you
nowhere.

Chris Reffett
Apologies for multiple emails getting sent, on a mobile connection here and it 
reported a failure to send. My bad.

Chris Reffett
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[gentoo-dev] Help with EAPI bumps

[Chris Reffett]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi everyone,
It's been a QA team objective for some time to help get rid of older
EAPI ebuilds in-tree. I personally will be spending some time in the
next couple weeks working on this, but I we on the QA team would
appreciate it if the developer community in general could contribute,
especially with packages that are either maintainer-needed or in herds
which have low activity. To play things safe, please revbump and file
stable requests when doing the EAPI change (rather than directly
bumping EAPI). Thanks in advance for the help!

Chris Reffett
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlPhekUACgkQ23laikJhg1Q12ACfZgY5sei2KvpBbimA5QTaT85K
etIAnA1AbRs2AsrqFKiaVWgvtxAERaxe
=chii
-END PGP SIGNATURE-

Re: [gentoo-dev] Making a common sub-profile for no-multilib

[Chris Reffett]

On June 25, 2014 2:44:57 PM EDT, Michał Górny mgo...@gentoo.org wrote:
Dnia 2014-06-25, o godz. 13:01:48
Ian Stakenvicius a...@gentoo.org napisał(a):

 At the moment there are two profiles in particular that do this,
 amd64/no-multilib and hardened/linux/uclibc/amd64 ..  It's possible
or
 likely there are others, too, on other arches perhaps.
 
 In general, it's good that repoman notices this because those
profiles
 don't support having the 32bit deps installed.  However, if one of
 those profiles ever moves from a dev profile to a stable one (and
 blueness mentioned he would like to make uclibc/amd64 stable), then
 those dependency.badindev warnings will suddenly turn into
 dependency.bad errors.
 
 The solution to this would seem to be to package.mask all of these
 32-bit packages in the pure 64bit profiles.  However, having to do
 this in multiple locations is annoying.
 
 I would like to propose adding 'no-multilib/[arch]/package.mask'
 sub-profile(s), to allow all of these masks to go in one place.
 
 Populating package.mask should be fairly easy for amd64 at least,
 since anything depending on an app-emulation/emul-* will need to be
 masked.  However the merits of where the package.mask will go needs
 discussion.  Perhaps, for instance, it's time to adjust the profile
 tree hierarchy more aggressively instead of piling on with yet
 another subdir.

Forgive me for using such a words, but the profile tree is a well
stacked pile of crap. We have a dozen random profiles for each arch
then a dozen other profiles forked off them 'because the generic
arch profiles have crap' and a lot of profiles that inherit others
in a complex and semi-random manner.

For example, abi_x86_64 and abi_x86_32 each need to be forced in 4
profiles. This proves that we have 4 distinct profiles for amd64 which
need to be kept in sync. If I change something, I need to perform
the change in 4 different profiles and make sure I didn't screw
something up.

Then there's the x32 profile that inherits amd64 profile and therefore
requires reverting some of the stuff done on amd64. To do a complete
common change to x86-family multilib (like adding IUSE_IMPLICIT) I have
to modify 9 profiles.

Now let's add to this circa 8 mips profiles, around 3 ppc profiles, 4
arm profiles and some more. Every arch organized in somewhat different
and totally non-documented manner.

Long story short, doing anything to Gentoo profiles is utter pain
and comes with random breakage guarantee. Therefore, I'm asking -- nuke
those damn profiles, and start over! The current situation is
completely unmaintainable.

+1, I'm all for replacing it with something more usable. I personally would 
favor the mix-in approach, but just about anything would be better than the 
weird setup we have right now.

Chris

Re: [gentoo-dev] Re: Automated Package Removal and Addition Tracker, for the week ending 2014-04-27 23h59 UTC

[Chris Reffett]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 4/28/2014 9:41 AM, Sergey Popov wrote:
 28.04.2014 17:30, Ciaran McCreesh пишет:
 On Mon, 28 Apr 2014 17:08:28 +1000 Michael Palimaka
 kensing...@gentoo.org wrote:
 On 04/28/2014 04:56 PM, hasufell wrote:
 What is going on here? Doesn't look right. The commit
 messages don't give an understandable reason.
 
 
 It was added to the tree by someone outside the Qt team
 without permission. Since it's not ready for the tree yet, it
 was immediately removed again.
 
 So the Qt team is overriding the QA team now? Is it
 alphabetical?
 
 
 As a Qt team lead i want to say that there is no permission for me
 or pesa(as the main maintainer of Qt Framework packages) for
 importing Qt 5 in tree. So, i kindly asks zlogene to remove that
 stuff from main tree.
 
 As QA team member - there was no serious QA issue here - ebuilds,
 even semi-broken, was bringed with apropriate masks, so - no damage
 on users's systems.
 
Saying that a Qt team member did something wrong because he reverted
an action taken by someone who happens to be a member of the QA team
is like saying that I can't revert something done by a council member
to one of my packages just because they happen to be on the council.
As Pinkbyte said, there was no QA issue here, just a developer being
quick on the trigger, so the membership of any parties in QA is
irrelevant to the discussion.

Chris Reffett
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlNeW8IACgkQ23laikJhg1RQ6wCbBVdKKUe0J9n74CPBOmOdWmvz
JqEAmgM5PuT29aF5Djyp6X1thdo2z/WX
=E9g0
-END PGP SIGNATURE-

Re: [gentoo-dev] can we get a clang herd/project?

[Chris Reffett]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/03/2014 03:19 PM, Michał Górny wrote:
 Dnia 2014-03-03, o godz. 20:01:25 hasufell hasuf...@gentoo.org
 napisał(a):
 
 I'm tired of looking all the maintainers up manually and adding
 each one to CC list of bug reports.
 
 Why is there no herd or project?
 
 Not sure what gentoo-dev ml has to do with it...
 
 ...but I've filed bug 503354 [1] to create the alias.
 
 [1]:https://bugs.gentoo.org/show_bug.cgi?id=503354
 

Any dev may create a new project just by creating a new project page
on the wiki.gentoo.org (see
Gentoo_Wiki:Developer_Central/Project_pages) and sending a Request For
Comments (RFC) e-mail to gentoo-dev. Note that this GLEP does not
provide for a way for the community at large to block a new project,
even if the comments are wholly negative. (GLEP39)

If he wants there to be a herd/project, this is entirely the right
place to say so :)

Chris Reffett
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iKYEARECAGYFAlMU5thfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2NzU5RjUyMDczREJDQkVDQTBDRkE1NERC
Nzk1QThBNDI2MTgzNTQACgkQ23laikJhg1S9DACeNLZGwG6XqsHwl3caNwOIEsKq
7g0AoJ7IQq2dcIM0qqVGur0sDLBh9sTT
=sKf+
-END PGP SIGNATURE-

[gentoo-dev] February 2014 QA policy updates

[Chris Reffett]

Hello all,
The following are the policy changes from this month's QA team meeting:

-USE=multislot (and other USE-dependent SLOT values) need to be removed
from the tree. Toolchain can keep it in an overlay if they want. We
would consider it acceptable to remove USE=multislot from the tree but
keep the eclasses as-is, so that toolchain doesn't need to maintain multiple
eclasses. This does not affect sys-boot/grub's USE=multislot, as that
does not mangle the SLOT value like the others (as I understand it).

-Regarding the gtk/gtk2/gtk3 USE flag situation: we mandate that gtk
move to versioned USE flags. For simplicity of migration, we will allow
USE=gtk to mean depend on gtk2, since there are only a few USE=gtk2
remaining in tree. USE=gtk3 will mean depend on gtk3, and in the
future, USE=gtk4 will mean depend on gtk4, and so on. USE=gtk may
not be used to mean depend on some version of gtk.

-More generally: we recommend that in future situations like this (a package
can optionally depend on different versions of a library), we recommend the
use of versioned USE flags. It should be discussed with the QA team either
way.

Also, on a non-policy note, we recommend that the Council deprecate
EAPIs 0 and 3 (0 pending discussion with toolchain) and ban EAPI 1. As
always, if you have questions, feel free to ping us in #gentoo-qa. The meeting
summary and these policies will be available on the Quality Assurance page
on the Gentoo Wiki tonight or tomorrow.

Chris Reffett
Gentoo QA Lead

Re: [gentoo-portage-dev] [PATCH v2] Add --output-style option to repoman

[Chris Reffett]

On 02/13/2014 10:42 AM, Brian Dolbec wrote:
 On Thu, 13 Feb 2014 03:19:35 -0500
 Mike Frysinger vap...@gentoo.org wrote:
 
 On Monday, February 10, 2014 20:22:36 Chris Reffett wrote:
 This patch adds a --output-style option to repoman, which gives the
 user a choice of output formats for the repoman checks. Choices are
 default (current style) and column (a greppable format), but it
 should be easy to add more. Fixes bug 481584.

 i'd expect a proper structured output would make sense to include in
 the default set.  like JSON.  just create a dict and send it to
 json.dump().
 
 He is working on more changes to repoman and the output. So, if you
 can, Chris, then do it, add a json option.
 
Will do that after my next set of changes to repoman (to be emailed shortly)
 

 v2: Fix docstring to be complete and in the standard format, make
 use of default choices in --output-style wrt comments by antarus
 and dol-sen

 erm, i thought the previous docstring was correct.  it followed
 PEP257 while this new one is like javadoc or something.

 
 It is the existing format that has been around in portage for years.
 There is even a page for it:
 
 http://www.gentoo.org/proj/en/portage/doc/policies/docstring-spec.xml
 
 It is also the style that epydoc recognizes. 
 
 -utilities.format_qa_output(f, stats, fails, dofull, dofail,
 options, qawarnings)
 +if options.output_style == 'column':
 +   utilities.format_qa_output_column(f, stats, fails, dofull,
 dofail, options, qawarnings)
 +else:
 +   utilities.format_qa_output(f, stats, fails, dofull,
 dofail, options, qawarnings)

 use a func pointer instead.
 format_outputs = {
  'column': utilities.format_qa_output_column,
  'default': utilities.format_qa_output,
 }
 format_output = format_outputs.get(options.output_style,
  format_outputs['default'])
 format_output(f, stats, fails, dofull, dofail, options, qawarnings)

 
 yeah, make it so.  Good spot, Mike
 
Committed, thanks for the spot.
 
 Since Mike was too slow in replying, make another commit to change
 it.
 
 +   formatter.add_literal_data(NumberOf  + category
 +  )

 prefer to use % rather than + like so:
  'NumberOf %s ' % category

 +   formatter.add_literal_data(%s % number)

 
 well actually, for simple additions like that, string1 + string2, it is
 actually faster.
 But for multiple additions,  %s is much better, faster.  Also if the
 string is translated, then use %s regardless.  That way the %s can be
 moved around for the translation.
 
 str(number)
 -mike
 
 
 

[gentoo-portage-dev] [PATCH 0/2] Refactor repoman QA handling

[Chris Reffett]

This series of patches alters repoman's QA output to be much more usable. The
first patch changes all checks to output a list of either length 1 or 2,
splitting the file with the error from the error itself. This will be helpful
for making machine-parseable output in the future. The second both makes the
variables used to build the output much more consistent and makes the output
itself more consistent by removing a few instances where the full path was
printed rather than the relative path. This will change the existing repoman
output format and potentially break scripts which rely on the old and
inconsistent behavior.

Chris Reffett (2):
  Split output for repoman checks into file and message
  Repoman check code cleanup

 bin/repoman  | 232 +++
 pym/repoman/utilities.py |  18 +++-
 2 files changed, 128 insertions(+), 122 deletions(-)

-- 
1.8.5.3

Re: [gentoo-dev] RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)

[Chris Reffett]

On 2/12/2014 3:09 AM, Michał Górny wrote:
 Dnia 2014-02-11, o godz. 19:33:06 Chris Reffett 
 creff...@gentoo.org napisał(a):
 
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
 
 On 02/11/2014 06:13 PM, Gilles Dartiguelongue wrote:
 Unfortunately, the concurrent nature of gtk2/gtk3 has 
 resulted in packages that may support either or both the 
 toolkits. To handle this, a few developers have introduced 
 the gtk3 useflag, that prefers gtk3 over gtk2 when both 
 toolkit versions are supported. At this point, the Gnome
 team highly recommends prefering gtk3 if possible, skipping
 the useflag altogether. [1]
 
 Wrong, as is written in policy whether to prefer gtk2 or 3 is 
 up to the maintainer of the package. We point people to the 
 fact that upstream says gtk2 is a dead end and support will 
 stop (if not in fact already stopped) in the near future.
 
 We also recommend to have maintainers support slots for their 
 libs where possible considering man-power and to only choose 
 one toolkit for applications considering where upstream 
 development is going and maturity of the port, and again, this 
 is up to package maintainers.
 This doesn't make sense to me at all. I can't see why slotted 
 libraries can't just use USE flags to specify what toolkit 
 they're built against, just like any other package in the tree 
 (so, for example, a package that needs webkit-gtk built against 
 gtk3 would depend on webkit-gtk[gtk3] instead of webkit-gtk:3). 
 I'm well aware that there could be limitations I'm unaware of 
 (maybe the package only can build one at a time?), but this is 
 how it looks to me. By switching to versioned gtk flags, this 
 kills two birds with one stone: it makes it obvious to the end 
 user which version they're trying to build their package
 against, and it gets rid of the need for (ab)using revision
 numbers to implement slots like that.
 
 Except when you end up rebuilding the huge thing twice. Or trying 
 to live with binpackages -- the thing that most Gentoo developers 
 don't care about at all. They just love their precious USE flags
 so much they'd shove them everywhere for the sake of it.
 

You'll have to build it twice anyway, this just splits it into two
separate packages, and I suspect that the times where you will have to
rebuild are when a package needs webkit-gtk to support another toolkit
(which should happen only once), and when you upgrade (in which case
you would be updating them separately anyway). I also fail to see what
this has to do with binpkgs: if something needs webkit-gtk[gtk2], you
add a dep on webkit-gtk[gtk2]. The user adds USE=gtk2 to webkit-gtk if
needed, webkit-gtk binpkg gets rebuilt. I see no breakage there.

Chris Reffett

Re: [gentoo-dev] RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)

[Chris Reffett]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/11/2014 06:13 PM, Gilles Dartiguelongue wrote:
 Thanks for attaching link to team's policy which tries to lift any
 kind of ambiguities people may have for what concerns gnome team's
 packages, I hope it proved useful in your discussions.
 
 
 Le mercredi 12 février 2014 à 00:39 +0200, Alex Alexander a écrit
 :
 Hello fellow developers,
 
 In the first meeting of the new QA team, we discussed the state
 of the gtk{,2,3} USE flags in the main tree. [0]
 
 In its current state, USE=gtk means gtk2. The Gnome team is
 trying to change this into the most recent gtk version (it is a
 work in progress).
 
 Wrong, gtk USE flag means enable gtk support, whether this is gtk
 1, 2 or 3 depends on what the package (presumably library) supports
 and whether is can be slotted or not and whether current gentoo
 maintainer decides what can be reasonably supported.
 
 Unfortunately, the concurrent nature of gtk2/gtk3 has resulted in
 packages that may support either or both the toolkits. To handle
 this, a few developers have introduced the gtk3 useflag, that
 prefers gtk3 over gtk2 when both toolkit versions are supported.
 At this point, the Gnome team highly recommends prefering gtk3 if
 possible, skipping the useflag altogether. [1]
 
 Wrong, as is written in policy whether to prefer gtk2 or 3 is up to
 the maintainer of the package. We point people to the fact that
 upstream says gtk2 is a dead end and support will stop (if not in
 fact already stopped) in the near future.
 
 We also recommend to have maintainers support slots for their libs
 where possible considering man-power and to only choose one toolkit
 for applications considering where upstream development is going
 and maturity of the port, and again, this is up to package
 maintainers.
This doesn't make sense to me at all. I can't see why slotted
libraries can't just use USE flags to specify what toolkit they're
built against, just like any other package in the tree (so, for
example, a package that needs webkit-gtk built against gtk3 would
depend on webkit-gtk[gtk3] instead of webkit-gtk:3). I'm well aware
that there could be limitations I'm unaware of (maybe the package only
can build one at a time?), but this is how it looks to me. By
switching to versioned gtk flags, this kills two birds with one stone:
it makes it obvious to the end user which version they're trying to
build their package against, and it gets rid of the need for (ab)using
revision numbers to implement slots like that.

 
 Some developers choose to follow the Gnome team's highlights,
 while others choose to go their own way. The QA team would like
 to establish a guideline that solves this problem in the best way
 possible.
 
 During our discussion, it was pointed out that keeping a generic
 USE=gtk is sub-optimal. The non-straightforward nature of new
 toolkit versions makes transitioning from one to the other a
 slow, tedius process and we think that a non-versioned USE flag
 makes things even worse.
 
 A few of our members recommended a move away from the unversioned
 USE=gtk to versioned-only USE flags. Qt managed to do this
 quite successfully when they transitioned from the unversioned
 USE=qt (that actually meant qt3) to USE=qt4. The benefits can
 be seen now that qt5 is around the corner. USE=qt5 is
 straightforward, does not mess with qt4 packages and was 
 introduced to the tree without messing with current packages too
 much - other than adding a new use flag where appropriate. There
 is also no need for USE=qt anymore.
 
 To achieve this, version 3 of gtk should always be enabled by
 USE=gtk3. At some point in the future, when gtk2 consumers
 reach zero, we will retire gtk for good. Then, if some day gtk4
 comes around, we will be able to introduce support for it in the
 tree by simply adding USE=gtk4, without having to re-structure
 half the tree.
 
 We are reaching out to the developer community to hear your
 thoughts and ideas on the matter. We would like to reach a
 decision that could possibly affect and direct the state of whole
 tree. This decision could then be turned into a policy, improving
 Gentoo's consistency across the tree.
 
 Imho the whole discussion stems for packages maintainers which, as
 you have written, did not follow our recommendation and tried to
 provided application with both gtk2 and gtk3 support.
 
 I agree that Gentoo is about choice... however as a maintainer of
 a lot of packages, it is unreasonable to try to support two
 configuration where one is dying slowly due to upstream (gtk)
 maintainer focus being elsewhere, hence why we wanted maintainers
 to choose. Instead, it occurs that some decided not to choose or to
 stop users from annoying them with 100 of duplicate bugs about not
 providing the alternative.
 
 Looking at the situation from a gnome team member perspective when
 Gnome 3 was introduced to the tree, only three packages (providing
 libs) needed exception to the rule to avoid 

[gentoo-portage-dev] [PATCH v2] Add --output-style option to repoman

[Chris Reffett]

This patch adds a --output-style option to repoman, which gives the user
a choice of output formats for the repoman checks. Choices are default
(current style) and column (a greppable format), but it should be easy
to add more. Fixes bug 481584.

v2: Fix docstring to be complete and in the standard format, make use of
default choices in --output-style wrt comments by antarus and dol-sen
---
 bin/repoman  | 15 ++-
 pym/repoman/utilities.py | 44 
 2 files changed, 58 insertions(+), 1 deletion(-)

diff --git a/bin/repoman b/bin/repoman
index 3504b6b..c7a1c4c 100755
--- a/bin/repoman
+++ b/bin/repoman
@@ -144,9 +144,16 @@ def ParseArgs(argv, qahelp):
'scan' : 'Scan directory tree for QA issues'
}
 
+   output_choices = {
+   'default' : 'The normal output format',
+   'column' : 'Columnar output suitable for use with grep'
+   }
+
mode_keys = list(modes)
mode_keys.sort()
 
+   output_keys = sorted(output_choices)
+
parser = ArgumentParser(usage=repoman [options] [mode],
description=Modes: %s %  | .join(mode_keys),
epilog=For more help consult the man page.)
@@ -228,6 +235,9 @@ def ParseArgs(argv, qahelp):
parser.add_argument('--without-mask', dest='without_mask', 
action='store_true',
default=False, help='behave as if no package.mask entries exist 
(not allowed with commit mode)')
 
+   parser.add_argument('--output-style', dest='output_style', 
choices=output_keys,
+   help='select output type', default='default')
+
parser.add_argument('--mode', dest='mode', choices=mode_keys,
help='specify which mode repoman will run in (default=full)')
 
@@ -2422,7 +2432,10 @@ console_writer.style_listener = style_file.new_styles
 
 f = formatter.AbstractFormatter(console_writer)
 
-utilities.format_qa_output(f, stats, fails, dofull, dofail, options, 
qawarnings)
+if options.output_style == 'column':
+   utilities.format_qa_output_column(f, stats, fails, dofull, dofail, 
options, qawarnings)
+else:
+   utilities.format_qa_output(f, stats, fails, dofull, dofail, options, 
qawarnings)
 
 style_file.flush()
 del console_writer, f, style_file
diff --git a/pym/repoman/utilities.py b/pym/repoman/utilities.py
index 3ec3a4a..aec61fe 100644
--- a/pym/repoman/utilities.py
+++ b/pym/repoman/utilities.py
@@ -330,6 +330,50 @@ def format_qa_output(formatter, stats, fails, dofull, 
dofail, options, qawarning
formatter.add_line_break()
 
 
+def format_qa_output_column(formatter, stats, fails, dofull, dofail, options, 
qawarnings):
+   Helper function that formats output in a machine-parseable column 
format
+
+   @param formatter: an instance of Formatter
+   @type formatter: Formatter
+   @param path: dict of qa status items
+   @type path: dict
+   @param fails: dict of qa status failures
+   @type fails: dict
+   @param dofull: Whether to print full results or a summary
+   @type dofull: boolean
+   @param dofail: Whether failure was hard or soft
+   @type dofail: boolean
+   @param options: The command-line options provided to repoman
+   @type options: Namespace
+   @param qawarnings: the set of warning types
+   @type qawarnings: set
+   @return: None (modifies formatter)
+   
+   full = options.mode == 'full'
+   for category, number in stats.items():
+   # we only want key value pairs where value  0
+   if number  1:
+   continue
+
+   formatter.add_literal_data(NumberOf  + category +  )
+   if category in qawarnings:
+   formatter.push_style(WARN)
+   else:
+   formatter.push_style(BAD)
+   formatter.add_literal_data(%s % number)
+   formatter.pop_style()
+   formatter.add_line_break()
+   if not dofull:
+   if not full and dofail and category in qawarnings:
+   # warnings are considered noise when there are 
failures
+   continue
+   fails_list = fails[category]
+   if not full and len(fails_list)  12:
+   fails_list = fails_list[:12]
+   for failure in fails_list:
+   formatter.add_literal_data(category +   + 
failure)
+   formatter.add_line_break()
+
 def editor_is_executable(editor):

Given an EDITOR string, validate that it refers to
-- 
1.8.5.3

[gentoo-dev] February 2014 KDE team meeting

[Chris Reffett]

Hello all,
The next KDE team meeting will take place on Feb 20 at 1900 UTC in
#gentoo-meetings. Our agenda (yet to be filled in) can be found at
https://wiki.gentoo.org/wiki/Project:KDE/Meeting/2014-02. All are
welcome to attend.

Chris Reffett



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: Re: dropping redundant stable keywords

[Chris Reffett]

 trying to do so. We will have
a meeting, argue it there, and vote. Right now, all this arguing just
makes everyone more confused about what our opinion is.
- -I realize that our policy was unclear and may conflict with existing
policy on ebuild removal. I apologize for that, and will keep this
episode in mind in the future.

Chris Reffett
Gentoo QA Lead
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iKYEARECAGYFAlLzAFBfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2NzU5RjUyMDczREJDQkVDQTBDRkE1NERC
Nzk1QThBNDI2MTgzNTQACgkQ23laikJhg1T76QCeOCFk8ClakUmKMqD0ldJEFQE2
kxkAn1Zw/6sSOghbc43KC4QEVzolYIvn
=+Pmi
-END PGP SIGNATURE-

Re: [gentoo-dev] January 2014 QA Policy Updates

[Chris Reffett]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/31/2014 09:07 AM, Peter Stuge wrote:
 Alec Warner wrote:
 hmm?
 
 To be fair, I had a long discussion with this regarding when QA
 has the authority to temporarily ban a developer.
 
 Cool.
 
 
 In the case where policy is missing, QA does not have a clear
 case of authority there. It becomes a more murky area. I've tried
 to very much encourage QA to both publish the policies they want
 to enforce, and automate enforcement with better tooling (repoman
 or otherwise). Being transparent and consistent in enforcement
 of policy goes a long way for getting developers on your side.
 
 Absolutely.
 
 
 So in short, while one could read that passage as you did, I
 don't think that is their intention.
 
 To be clear, I don't think so either.
 
 
 Rich Freeman wrote:
 I was really happy to see a public notice of meeting and a
 published summary.
 
 Yes, me too!
 
 
 I still think it seems like QA could essentially introduce
 arbitrary new policies and 2 weeks later be expected to effect
 them.
 
 Fine when everyone agrees. Not so much at other times. The 
 responsibility is with QA to build support among the developers,
 and I agree that the transparency goes a long way!
 
 
 //Peter
 

Regarding the question in your first email: We will not create a
policy then immeiately use the policy as justification to to go edit
packages. The intention of the we may ask the developer to stop line
is for cases where we suspect that what the developer is doing is
causing a problem and would like to discuss it further. I feel that
that is well within the bounds of GLEP 48. As for the when/how we
make and communicate fixes, I think that just about any policy we
make will fall into the middle ground you omitted of file a bug, wait
2 weeks, fix. So no, we will not be making arbitrary fixes just
because we can.

Regarding your concern about us introducing arbitrary policies: again,
most will fall into the file a bug middle ground. We also are
perfectly aware that you can't expect people to change overnight, and
we will not be shouting at devs just because they didn't implement
$(new-policy) right away. We will file bugs asking for changes, and we
will try to offer suggestions or patches wherever possible to make it
easier for maintainers.

Chris Reffett
Gentoo QA Lead
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iKYEARECAGYFAlLrv0hfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2NzU5RjUyMDczREJDQkVDQTBDRkE1NERC
Nzk1QThBNDI2MTgzNTQACgkQ23laikJhg1QZ+wCeJre5n44E9BdZcUBgZdC5DjPe
WR8AoJ1W9QuqVIFXxsVAWBO23yx+etak
=5CIT
-END PGP SIGNATURE-

Re: [gentoo-dev] January 2014 QA Policy Updates

[Chris Reffett]

On 01/30/2014 03:10 PM, William Hubbs wrote:
 On Thu, Jan 30, 2014 at 12:47:01AM -0500, Chris Reffett wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hello all,
 The new QA team has completed its first meeting, and so I would like
 to announce policy changes agreed upon during the meeting which are
 relevant to the developer community. In the future, when a meeting
 results in changed or amended policy, we will notify the community via
 - -dev and -dev-announce, so there will probably be a summary email like
 this coming out about once a month. Changes to policy from this meeting:

 - -USE-controlled optional RDEPENDs policy clarified to say that those
 dependencies are not allowed, but QA will grant exceptions for certain
 circumstances (such as a package not working unless one of a set of
 optional deps is installed)

 - -The QA team policymaking workflow will look like the following:
 * User/dev/team member brings us an issue
 * Team investigates
 * Team discusses at the next meeting
 ** If the person is violating policy, we inform them of that and
 request that they stop violating policy
 ** If the existing policy is unclear, we update it
 ** If there is no existing policy, make one
 If we think a developer's actions are causing problems, we may ask
 them to stop/undo pending discussion by the QA team at the next meeting.

 - -Rules for the QA team editing peoples' packages:
 *For trivial fixes, such as repoman errors, we fix the issue and send
 the developer a friendly reminder
 *For large but non-critical fixes, we open a bug, wait 2 weeks, and if
 it is not fixed within that time frame we make the change.
 *For critical fixes, such as a problem that breaks the tree or a
 package, we fix the issue and send the developer a notice about our change

 - -The QA team will communicate changes to policy via emails to
 gentoo-dev and gentoo-dev-announce and by updating the QA policy page
 on the Gentoo Wiki.

 For anyone interested, the summary of the meeting can be found at
 https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Meeting_Summaries
 and the current set of QA policies can be found at
 https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies. If
 you have any questions or concerns about these policies, feel free to
 discuss them with us in #gentoo-qa or by emailing q...@gentoo.org.
 
 I have one.
 
 The way I read that email, we are saying that our only policies are on
 the wiki.
 
 Is that right, or is the DevManual stil relevant?
 
 If it is, I would suggest that on the wiki we make it clear that our
 technical policies are all in the devmanual. Along that line, I would
 suggest moving the stabilization policy to the devmanual. I'll look for
 a place for a patch.
 
 William
 

That's my mistake, the devmanual is still relevant. My idea is to use
the wiki page for smaller or more specific items which probably don't go
in the devmanual (for example, policy which is about specific packages
or USE flags, or policies which just affect the QA team). Stabilization
should go to the devmanual, then.

Chris Reffett



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] January 2014 QA Policy Updates

[Chris Reffett]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello all,
The new QA team has completed its first meeting, and so I would like
to announce policy changes agreed upon during the meeting which are
relevant to the developer community. In the future, when a meeting
results in changed or amended policy, we will notify the community via
- -dev and -dev-announce, so there will probably be a summary email like
this coming out about once a month. Changes to policy from this meeting:

- -USE-controlled optional RDEPENDs policy clarified to say that those
dependencies are not allowed, but QA will grant exceptions for certain
circumstances (such as a package not working unless one of a set of
optional deps is installed)

- -The QA team policymaking workflow will look like the following:
* User/dev/team member brings us an issue
* Team investigates
* Team discusses at the next meeting
** If the person is violating policy, we inform them of that and
request that they stop violating policy
** If the existing policy is unclear, we update it
** If there is no existing policy, make one
If we think a developer's actions are causing problems, we may ask
them to stop/undo pending discussion by the QA team at the next meeting.

- -Rules for the QA team editing peoples' packages:
*For trivial fixes, such as repoman errors, we fix the issue and send
the developer a friendly reminder
*For large but non-critical fixes, we open a bug, wait 2 weeks, and if
it is not fixed within that time frame we make the change.
*For critical fixes, such as a problem that breaks the tree or a
package, we fix the issue and send the developer a notice about our change

- -The QA team will communicate changes to policy via emails to
gentoo-dev and gentoo-dev-announce and by updating the QA policy page
on the Gentoo Wiki.

For anyone interested, the summary of the meeting can be found at
https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Meeting_Summaries
and the current set of QA policies can be found at
https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies. If
you have any questions or concerns about these policies, feel free to
discuss them with us in #gentoo-qa or by emailing q...@gentoo.org.

Chris Reffett
Gentoo QA Lead
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iKYEARECAGYFAlLp51VfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2NzU5RjUyMDczREJDQkVDQTBDRkE1NERC
Nzk1QThBNDI2MTgzNTQACgkQ23laikJhg1R6zwCfXY0q7Ig3d40Xq2hScLcT4Hm6
zE8AoJfIWsuV9yAKdsuxwB6JSDr8KbZY
=sheY
-END PGP SIGNATURE-

Re: [gentoo-dev] [PATCH] eutils.eclass: add optfeature() function

[Chris Reffett]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/25/2014 05:12 AM, Markos Chandras wrote:
 On 01/23/2014 04:48 PM, Michał Górny wrote:
 Dnia 2014-01-23, o godz. 11:36:06 Chris Reffett
 creff...@gentoo.org napisał(a):
 
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
 
 On 01/23/2014 11:28 AM, Michał Górny wrote:
 Dnia 2014-01-23, o godz. 11:24:41 Chris Reffett 
 creff...@gentoo.org napisał(a):
 
 After some discussion on good ways to communicate optional
  dependencies to users, I was shown the optfeature()
 function in net-misc/netctl. Gentoo contributor Andrew
 Hamilton and I came up with a cleaned up and expanded
 version of it, and I would like to add it to eutils.eclass
 to provide a standard way of notifying users of optional
 dependencies. The patch to eutils.eclass is attached.
 
 This was discussed already:
 
 http://thread.gmane.org/gmane.linux.gentoo.devel/72162
 
 First of all, this is a short patch for a function, not a full
 eclass.
 
 Ah, sorry, this changes *a lot*. Let's start the bikeshed again
 then, whatever.
 
 I haven't looked at the implementation, but I wonder if we need a 
 function for such trivial stuff. Most maintainers deal with this
 problem using pkg_postinst() einfo/elog messages. Why do we need a
 dedicated function for that? Just for consistency reasons...?
 
Consistency, and because it removes the need for a bunch of if
has_version lines, instead only displaying if you don't satisfy the
deps (and supports both and and or groupings for packages
satisfying the dep). This also stems from a complaint I've seen a lot
about how optional dep messages should only display if the requisite
package isn't installed, this makes that job a little simpler. But
mostly consistency, this gives us one nice function that we can
standardize on.

Chris Reffett
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iKYEARECAGYFAlLjt6NfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2NzU5RjUyMDczREJDQkVDQTBDRkE1NERC
Nzk1QThBNDI2MTgzNTQACgkQ23laikJhg1SAZACgqLjfMMmvPNa/6Nwxzlpm5sde
kwQAniZMjvFkQ7H/1+wpYnDjyezplMud
=6E+E
-END PGP SIGNATURE-

Re: [gentoo-dev] Drop net-analyzer/nagios-* to maintainer-needed

[Chris Reffett]

On 01/25/2014 12:22 PM, Andrew Hamilton wrote:
 On 1/25/2014 9:24 AM, Markos Chandras wrote:
 On 11/10/2013 06:12 AM, Johann Schmitz wrote:
 - gpg control packet
 I already have too many packages to take care of but my company
 is using nagion on Gentoo so I take care of it. Although I
 wouldn't mind if somebody else helps with the packages as well.

 We use Nagios on many servers at work, so i can help out with these
 packages too.

 ... git overlay for easier nondev contributions? :)

 A git repo would be useful if there are many changes to the code (e.g.
 plugins). From what i see in the buglist, most of the bugs are ebuild
 related (bumps, compile and installation issues).


 (picking a random email from the thread)

 ping again. 3 months later, the list of bugs remain the same. Shall we
 consider dropping it to maintainer-needed?

 I would be happy to proxy-maintain these packages.
 
 Andrew Hamilton
 
I will proxy for him, will update metadata shortly.

Chris Reffett

[gentoo-dev] [PATCH] eutils.eclass: add optfeature() function

[Chris Reffett]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello all,
After some discussion on good ways to communicate optional
dependencies to users, I was shown the optfeature() function in
net-misc/netctl. Gentoo contributor Andrew Hamilton and I came up with
a cleaned up and expanded version of it, and I would like to add it to
eutils.eclass to provide a standard way of notifying users of optional
dependencies. The patch to eutils.eclass is attached.

Chris Reffett
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iKYEARECAGYFAlLhQklfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2NzU5RjUyMDczREJDQkVDQTBDRkE1NERC
Nzk1QThBNDI2MTgzNTQACgkQ23laikJhg1TDkwCeJ7MQliIiI6ViSkZzD+eIYM/J
0F4AoIVMP32HenJcjOkTIJkd6vGniiSi
=+oIe
-END PGP SIGNATURE-
--- eutils.eclass	2014-01-22 23:36:35.81900 -0500
+++ eutils.eclass.patched	2014-01-23 00:37:07.90700 -0500
@@ -1729,4 +1729,49 @@
 
 check_license() { die you no longer need this as portage supports ACCEPT_LICENSE itself; }
 
+# @FUNCTION: optfeature
+# @USAGE: short description package atom to match [other atoms]
+# @DESCRIPTION:
+# Print out a message suggesting an optional package (or packages) which
+# provide the described functionality
+#
+# The following snippet would suggest app-misc/foo for optional foo support,
+# app-misc/bar or app-misc/baz[bar] for optional bar support
+# and either both app-misc/a and app-misc/b or app-misc/c for alphabet support.
+# @CODE:
+# 		optfeature foo support app-misc/foo
+# 		optfeature bar support app-misc/bar app-misc/baz[bar]
+#		optfeature alphabet support app-misc/a app-misc/b app-misc/c
+#
+optfeature() {
+	debug-print-function ${FUNCNAME} $@
+	local i j msg
+	local desc=$1
+	local flag=0
+	shift
+	for i; do
+		for j in $i; do
+			if has_version $j; then
+flag=1
+			else
+flag=0
+break
+			fi
+		done
+		if [[ $flag -eq 1 ]]; then
+			break
+		fi
+	done
+	if [[ $flag -eq 0 ]]; then
+		for i; do
+			msg= 
+			for j in $i; do
+msg=${msg} ${j} and
+			done
+			msg=${msg:0: -4} for ${desc}
+			elog ${msg}
+		done
+	fi
+}
+
 fi

Re: [gentoo-dev] [PATCH] eutils.eclass: add optfeature() function

[Chris Reffett]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/23/2014 11:28 AM, Michał Górny wrote:
 Dnia 2014-01-23, o godz. 11:24:41 Chris Reffett
 creff...@gentoo.org napisał(a):
 
 After some discussion on good ways to communicate optional 
 dependencies to users, I was shown the optfeature() function in 
 net-misc/netctl. Gentoo contributor Andrew Hamilton and I came up
 with a cleaned up and expanded version of it, and I would like to
 add it to eutils.eclass to provide a standard way of notifying
 users of optional dependencies. The patch to eutils.eclass is
 attached.
 
 This was discussed already:
 
 http://thread.gmane.org/gmane.linux.gentoo.devel/72162
 
First of all, this is a short patch for a function, not a full eclass.
Further, people are doing this sort of thing already (printing
messages to say if you want support for x, install y, this is just
making it easier to do so. Of course full support for an SDEPEND
variable would be much better, but unless you have a patch for that
ready to go for the next EAPI I don't see that happening anytime soon,
so a short function in eutils seems like a reasonable choice to me.

Chris Reffett
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iKYEARECAGYFAlLhRPZfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2NzU5RjUyMDczREJDQkVDQTBDRkE1NERC
Nzk1QThBNDI2MTgzNTQACgkQ23laikJhg1QaawCeM3GnYAc83Czei2r1l2XHFFB4
sAgAn21yARrui9E+ZsNnk75UCk0j0oEp
=VTT0
-END PGP SIGNATURE-

[gentoo-portage-dev] [PATCH v6] Test for read-only filesystems, bail out during preinst if there are any which will be written to and display a useful error message. Fixes bug 378869.

[Chris Reffett]

v2: Reformat, add a function to return an appropriate read-only checker
for the operating system, so that this can be extended to other OSes.

v3: minor formatting tweaks from bernalex, including use os.path.join()
instead of string concatenation

v4: Update copyright header, change the code in rochecker to open with
io.open in order to not break on non-ascii characters as reported by
Arfrever. Change get_ro_checker to use a dict as suggested by vapier.

v5: Fix comment format as requested by vapier.

v6: Change linux_ro_checker to use set.intersection instead of the
longer check-and-append system as suggested by vapier.
---
 pym/portage/dbapi/vartree.py  | 34 +-
 pym/portage/util/rochecker.py | 80 +++
 2 files changed, 113 insertions(+), 1 deletion(-)
 create mode 100644 pym/portage/util/rochecker.py

diff --git a/pym/portage/dbapi/vartree.py b/pym/portage/dbapi/vartree.py
index ed62323..cf6781b 100644
--- a/pym/portage/dbapi/vartree.py
+++ b/pym/portage/dbapi/vartree.py
@@ -1,4 +1,4 @@
-# Copyright 1998-2013 Gentoo Foundation
+# Copyright 1998-2014 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
 
 from __future__ import unicode_literals
@@ -32,6 +32,7 @@ portage.proxy.lazyimport.lazyimport(globals(),
'portage.util.env_update:env_update',
'portage.util.listdir:dircache,listdir',
'portage.util.movefile:movefile',
+   'portage.util.rochecker:get_ro_checker',
'portage.util._dyn_libs.PreservedLibsRegistry:PreservedLibsRegistry',
'portage.util._dyn_libs.LinkageMapELF:LinkageMapELF@LinkageMap',
'portage.util._async.SchedulerInterface:SchedulerInterface',
@@ -3508,6 +3509,8 @@ class dblink(object):

This function does the following:

+   calls get_ro_checker to retrieve a function for checking 
whether Portage
+   will write to a read-only filesystem, then runs it against the 
directory list
calls self._preserve_libs if FEATURES=preserve-libs
calls self._collision_protect if FEATURES=collision-protect
calls doebuild(mydo=pkg_preinst)
@@ -3685,6 +3688,7 @@ class dblink(object):
eagain_error = False
 
myfilelist = []
+   mydirlist = []
mylinklist = []
paths_with_newlines = []
def onerror(e):
@@ -3717,6 +3721,9 @@ class dblink(object):

unicode_errors.append(new_parent[ed_len:])
break
 
+   relative_path = parent[srcroot_len:]
+   mydirlist.append(os.path.join(/, 
relative_path))
+
for fname in files:
try:
fname = _unicode_decode(fname,
@@ -3829,6 +3836,31 @@ class dblink(object):
for other in others_in_slot])
prepare_build_dirs(settings=self.settings, cleanup=cleanup)
 
+   # Check for read-only filesystems.
+   ro_checker = get_ro_checker()
+   rofilesystems = ro_checker(mydirlist)
+
+   if rofilesystems:
+   msg = _(One or more files installed to this package 
are 
+   set to be installed to read-only filesystems. 
+   Please mount the following filesystems as 
read-write 
+   and retry.)
+   msg = textwrap.wrap(msg, 70)
+   msg.append()
+   for f in rofilesystems:
+   msg.append(\t%s % os.path.join(destroot,
+   f.lstrip(os.path.sep)))
+   msg.append()
+   self._elog(eerror, preinst, msg)
+
+   msg = _(Package '%s' NOT merged due to read-only file 
systems.) % \
+   self.settings.mycpv
+   msg += _( If necessary, refer to your elog 
+   messages for the whole content of the above 
message.)
+   msg = textwrap.wrap(msg, 70)
+   eerror(msg)
+   return 1
+
# check for package collisions
blockers = self._blockers
if blockers is None:
diff --git a/pym/portage/util/rochecker.py b/pym/portage/util/rochecker.py
new file mode 100644
index 000..c13bdfc
--- /dev/null
+++ b/pym/portage/util/rochecker.py
@@ -0,0 +1,80 @@
+#-*- coding:utf-8 -*-
+# Copyright 2014 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+
+Methods to check whether Portage is going to write to read-only 

[gentoo-portage-dev] [PATCH v4] Test for read-only filesystems, bail out during preinst if there are any which will be written to and display a useful error message. Fixes bug 378869.

[Chris Reffett]

v2: Reformat, add a function to return an appropriate read-only checker
for the operating system, so that this can be extended to other OSes.

v3: minor formatting tweaks from bernalex, including use os.path.join()
instead of string concatenation

v4: Update copyright header, change the code in rochecker to open with
io.open in order to not break on non-ascii characters as reported by
Arfrever. Change get_ro_checker to use a dict as suggested by vapier.
---
 pym/portage/dbapi/vartree.py  | 34 -
 pym/portage/util/rochecker.py | 87 +++
 2 files changed, 120 insertions(+), 1 deletion(-)
 create mode 100644 pym/portage/util/rochecker.py

diff --git a/pym/portage/dbapi/vartree.py b/pym/portage/dbapi/vartree.py
index ed62323..22cf222 100644
--- a/pym/portage/dbapi/vartree.py
+++ b/pym/portage/dbapi/vartree.py
@@ -1,4 +1,4 @@
-# Copyright 1998-2013 Gentoo Foundation
+# Copyright 1998-2014 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
 
 from __future__ import unicode_literals
@@ -32,6 +32,7 @@ portage.proxy.lazyimport.lazyimport(globals(),
'portage.util.env_update:env_update',
'portage.util.listdir:dircache,listdir',
'portage.util.movefile:movefile',
+   'portage.util.rochecker:get_ro_checker',
'portage.util._dyn_libs.PreservedLibsRegistry:PreservedLibsRegistry',
'portage.util._dyn_libs.LinkageMapELF:LinkageMapELF@LinkageMap',
'portage.util._async.SchedulerInterface:SchedulerInterface',
@@ -3508,6 +3509,8 @@ class dblink(object):

This function does the following:

+   calls get_ro_checker to retrieve a function for checking 
whether Portage
+   will write to a read-only filesystem, then runs it against the 
directory list
calls self._preserve_libs if FEATURES=preserve-libs
calls self._collision_protect if FEATURES=collision-protect
calls doebuild(mydo=pkg_preinst)
@@ -3685,6 +3688,7 @@ class dblink(object):
eagain_error = False
 
myfilelist = []
+   mydirlist = []
mylinklist = []
paths_with_newlines = []
def onerror(e):
@@ -3717,6 +3721,9 @@ class dblink(object):

unicode_errors.append(new_parent[ed_len:])
break
 
+   relative_path = parent[srcroot_len:]
+   mydirlist.append(os.path.join(/, 
relative_path))
+
for fname in files:
try:
fname = _unicode_decode(fname,
@@ -3829,6 +3836,31 @@ class dblink(object):
for other in others_in_slot])
prepare_build_dirs(settings=self.settings, cleanup=cleanup)
 
+   # Check for read-only filesystems
+   ro_checker = get_ro_checker()
+   rofilesystems = ro_checker(mydirlist)
+
+   if rofilesystems:
+   msg = _(One or more files installed to this package 
are 
+   set to be installed to read-only filesystems. 
+   Please mount the following filesystems as 
read-write 
+   and retry.)
+   msg = textwrap.wrap(msg, 70)
+   msg.append()
+   for f in rofilesystems:
+   msg.append(\t%s % os.path.join(destroot,
+   f.lstrip(os.path.sep)))
+   msg.append()
+   self._elog(eerror, preinst, msg)
+
+   msg = _(Package '%s' NOT merged due to read-only file 
systems.) % \
+   self.settings.mycpv
+   msg += _( If necessary, refer to your elog 
+   messages for the whole content of the above 
message.)
+   msg = textwrap.wrap(msg, 70)
+   eerror(msg)
+   return 1
+
# check for package collisions
blockers = self._blockers
if blockers is None:
diff --git a/pym/portage/util/rochecker.py b/pym/portage/util/rochecker.py
new file mode 100644
index 000..2bbfe9d
--- /dev/null
+++ b/pym/portage/util/rochecker.py
@@ -0,0 +1,87 @@
+#-*- coding:utf-8 -*-
+# Copyright 2014 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+
+Methods to check whether Portage is going to write to read-only filesystems.
+Since the methods are not portable across different OSes, each OS needs its
+own method. To expand RO checking for different OSes, add a method which
+accepts a list 

[gentoo-portage-dev] [PATCH v5] Test for read-only filesystems, bail out during preinst if there are any which will be written to and display a useful error message. Fixes bug 378869.

[Chris Reffett]

v2: Reformat, add a function to return an appropriate read-only checker
for the operating system, so that this can be extended to other OSes.

v3: minor formatting tweaks from bernalex, including use os.path.join()
instead of string concatenation

v4: Update copyright header, change the code in rochecker to open with
io.open in order to not break on non-ascii characters as reported by
Arfrever. Change get_ro_checker to use a dict as suggested by vapier.

v5: Fix comment format as requested by vapier.
---
 pym/portage/dbapi/vartree.py  | 34 -
 pym/portage/util/rochecker.py | 88 +++
 2 files changed, 121 insertions(+), 1 deletion(-)
 create mode 100644 pym/portage/util/rochecker.py

diff --git a/pym/portage/dbapi/vartree.py b/pym/portage/dbapi/vartree.py
index ed62323..cf6781b 100644
--- a/pym/portage/dbapi/vartree.py
+++ b/pym/portage/dbapi/vartree.py
@@ -1,4 +1,4 @@
-# Copyright 1998-2013 Gentoo Foundation
+# Copyright 1998-2014 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
 
 from __future__ import unicode_literals
@@ -32,6 +32,7 @@ portage.proxy.lazyimport.lazyimport(globals(),
'portage.util.env_update:env_update',
'portage.util.listdir:dircache,listdir',
'portage.util.movefile:movefile',
+   'portage.util.rochecker:get_ro_checker',
'portage.util._dyn_libs.PreservedLibsRegistry:PreservedLibsRegistry',
'portage.util._dyn_libs.LinkageMapELF:LinkageMapELF@LinkageMap',
'portage.util._async.SchedulerInterface:SchedulerInterface',
@@ -3508,6 +3509,8 @@ class dblink(object):

This function does the following:

+   calls get_ro_checker to retrieve a function for checking 
whether Portage
+   will write to a read-only filesystem, then runs it against the 
directory list
calls self._preserve_libs if FEATURES=preserve-libs
calls self._collision_protect if FEATURES=collision-protect
calls doebuild(mydo=pkg_preinst)
@@ -3685,6 +3688,7 @@ class dblink(object):
eagain_error = False
 
myfilelist = []
+   mydirlist = []
mylinklist = []
paths_with_newlines = []
def onerror(e):
@@ -3717,6 +3721,9 @@ class dblink(object):

unicode_errors.append(new_parent[ed_len:])
break
 
+   relative_path = parent[srcroot_len:]
+   mydirlist.append(os.path.join(/, 
relative_path))
+
for fname in files:
try:
fname = _unicode_decode(fname,
@@ -3829,6 +3836,31 @@ class dblink(object):
for other in others_in_slot])
prepare_build_dirs(settings=self.settings, cleanup=cleanup)
 
+   # Check for read-only filesystems.
+   ro_checker = get_ro_checker()
+   rofilesystems = ro_checker(mydirlist)
+
+   if rofilesystems:
+   msg = _(One or more files installed to this package 
are 
+   set to be installed to read-only filesystems. 
+   Please mount the following filesystems as 
read-write 
+   and retry.)
+   msg = textwrap.wrap(msg, 70)
+   msg.append()
+   for f in rofilesystems:
+   msg.append(\t%s % os.path.join(destroot,
+   f.lstrip(os.path.sep)))
+   msg.append()
+   self._elog(eerror, preinst, msg)
+
+   msg = _(Package '%s' NOT merged due to read-only file 
systems.) % \
+   self.settings.mycpv
+   msg += _( If necessary, refer to your elog 
+   messages for the whole content of the above 
message.)
+   msg = textwrap.wrap(msg, 70)
+   eerror(msg)
+   return 1
+
# check for package collisions
blockers = self._blockers
if blockers is None:
diff --git a/pym/portage/util/rochecker.py b/pym/portage/util/rochecker.py
new file mode 100644
index 000..2d3c89f
--- /dev/null
+++ b/pym/portage/util/rochecker.py
@@ -0,0 +1,88 @@
+#-*- coding:utf-8 -*-
+# Copyright 2014 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+
+Methods to check whether Portage is going to write to read-only filesystems.
+Since the methods are not portable across different OSes, each OS needs its
+own method. To expand RO checking for 

Re: [gentoo-dev] Regarding long delays on GLSA generation

[Chris Reffett]

On Jan 18, 2014 1:35 PM, Pacho Ramos pa...@gentoo.org wrote:

 El sáb, 18-01-2014 a las 19:19 +0100, Alex Legler escribió: 
 [...] 
  So you observed correctly there's still plenty of delays. There are 
  three parts to an advisory that take time: 
  - Drafting: Collecting information, linking references, getting package 
  versions done right (slots are a huge pain still). 
  
  - Reviewing: Our current process asks for two independent positive 
  reviews from other team members before an advisory can be sent. 
  
  - Sending: The original author gets a .txt to email and have to check in 
  the .xml to CVS. 
  
  Going through these three steps requires at least three people, and the 
  (group of) people whose action is required shifts twice. That overall 
  process is spot #1 we are planning to improve. The current plan contains 
  requiring only one review and the reviewer sends the advisory directly. 
  So we go from author - reviewer 1 - reviewer 2 - author to just 
  author - reviewer. 

 This looks a nice improvement indeed :) 

  
  Concerning the single steps here are other measures: 
  - Drafting: Implement a new GLSA format to 
    * reduce the amount of editorial text written by us 
    * support slots (makes specifying vulnerable ranges in slotted package 
  much easier) 
    * (cleanup old stuff no longer needed) 

 That looks interesting as doing all the draft manually is really a huge 
 work (with leads to not so enhancement). I am unsure how will the 
 cleanup be done, as soon as the portage tree doesn't break (due some 
 other package requiring the old buggy version), why are not all devs 
 allowed to drop (or, at least, hardmask if needed for some base-system 
 package :/) the vulnerable versions? Looks like currently security team 
 waits for maintainers to do that, I try to do it fast but maybe will 
 take much more time in other situations. I think this could be improved 
 if other people like security team members or the last one stabilizing 
 the fixed version could do the cleanup too. 
We prefer that the maintainers do the drop in case there's some dependency 
situation we're not aware of, but we will drop if maintainers are unresponsive.

 Also, currently looks like, when we (maintainers) get asked to bump the 
 package fixing it, we tend to wait for security team members to CC 
 arches, maybe the maintainers could do that directly to gain a bit of 
 time. 
By all means, maintainer should be the one to call for the stable. It's your 
package, I cannot think of any situation where security would not want the 
maintainer to do that.

  
  - Reviewing: Reduced editorial text means less to review. 
  
  - Sending: We want to improve our tooling to automatically send 
  advisories and push them to a git repository. 
  
  The new GLSA format was up for review on -security last week. Next up 
  will be getting it specified formally, implemented in our tooling, 
  glsa-check and a new security.g.o frontend. [1] 
  Then, we can adopt the new workflow. 
  
   
   Then, instead of blaming on how should I have asked for clarification on 
   this (well, looks like the main topic here is that I have asked about 
   this in ML instead of the real problem :O), I think you should focus on 
   explaining how are you fixing this problem. 
  
  Your original email didn't reflect actual interest in the details. Now 
  that we've established you do care, I hope my explanations helped you 
  out there. 
  

 They helped for sure :) and I appreciate them, I simply thought nothing 
 was being worked out as I explained in previous mail (I was still saying 
 long delays) 

   I have been long time wondering about this because: 
   1. I usually get lots of bugs from alias I am a member whose we go fast 
   bumping, calling for stabilization and dropping vulnerable versions and, 
   the, the bugs get stalled. 
   2. Once of the machines I maintain would benefit from being able to use 
   glsacheck to only update vulnerable packages as not always have enough 
   time for updating the full world 
   
   
   
  
  [1] Lots of code to be written here. .py+.rb, help wanted! 
  

[gentoo-portage-dev] [PATCH v3] Test for read-only filesystems, bail out during preinst if there are any which will be written to and display a useful error message. Fixes bug 378869.

[Chris Reffett]

v2: Reformat, add a function to return an appropriate read-only checker
for the operating system, so that this can be extended to other OSes.

v3: minor formatting tweaks from bernalex, including use os.path.join()
instead of string concatenation
---
 pym/portage/dbapi/vartree.py  | 32 +
 pym/portage/util/rochecker.py | 81 +++
 2 files changed, 113 insertions(+)
 create mode 100644 pym/portage/util/rochecker.py

diff --git a/pym/portage/dbapi/vartree.py b/pym/portage/dbapi/vartree.py
index ed62323..917634f 100644
--- a/pym/portage/dbapi/vartree.py
+++ b/pym/portage/dbapi/vartree.py
@@ -32,6 +32,7 @@ portage.proxy.lazyimport.lazyimport(globals(),
'portage.util.env_update:env_update',
'portage.util.listdir:dircache,listdir',
'portage.util.movefile:movefile',
+   'portage.util.rochecker:get_ro_checker',
'portage.util._dyn_libs.PreservedLibsRegistry:PreservedLibsRegistry',
'portage.util._dyn_libs.LinkageMapELF:LinkageMapELF@LinkageMap',
'portage.util._async.SchedulerInterface:SchedulerInterface',
@@ -3508,6 +3509,8 @@ class dblink(object):

This function does the following:

+   calls get_ro_checker to retrieve a function for checking 
whether Portage
+   will write to a read-only filesystem, then runs it against the 
directory list
calls self._preserve_libs if FEATURES=preserve-libs
calls self._collision_protect if FEATURES=collision-protect
calls doebuild(mydo=pkg_preinst)
@@ -3685,6 +3688,7 @@ class dblink(object):
eagain_error = False
 
myfilelist = []
+   mydirlist = []
mylinklist = []
paths_with_newlines = []
def onerror(e):
@@ -3717,6 +3721,9 @@ class dblink(object):

unicode_errors.append(new_parent[ed_len:])
break
 
+   relative_path = parent[srcroot_len:]
+   mydirlist.append(os.path.join(/, 
relative_path))
+
for fname in files:
try:
fname = _unicode_decode(fname,
@@ -3829,6 +3836,31 @@ class dblink(object):
for other in others_in_slot])
prepare_build_dirs(settings=self.settings, cleanup=cleanup)
 
+   # Check for read-only filesystems
+   ro_checker = get_ro_checker()
+   rofilesystems = ro_checker(mydirlist)
+
+   if rofilesystems:
+   msg = _(One or more files installed to this package 
are 
+   set to be installed to read-only filesystems. 
+   Please mount the following filesystems as 
read-write 
+   and retry.)
+   msg = textwrap.wrap(msg, 70)
+   msg.append()
+   for f in rofilesystems:
+   msg.append(\t%s % os.path.join(destroot,
+   f.lstrip(os.path.sep)))
+   msg.append()
+   self._elog(eerror, preinst, msg)
+
+   msg = _(Package '%s' NOT merged due to read-only file 
systems.) % \
+   self.settings.mycpv
+   msg += _( If necessary, refer to your elog 
+   messages for the whole content of the above 
message.)
+   msg = textwrap.wrap(msg, 70)
+   eerror(msg)
+   return 1
+
# check for package collisions
blockers = self._blockers
if blockers is None:
diff --git a/pym/portage/util/rochecker.py b/pym/portage/util/rochecker.py
new file mode 100644
index 000..67e8131
--- /dev/null
+++ b/pym/portage/util/rochecker.py
@@ -0,0 +1,81 @@
+#-*- coding:utf-8 -*-
+# Copyright 2014 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+
+Methods to check whether Portage is going to write to read-only filesystems.
+Since the methods are not portable across different OSes, each OS needs its
+own method. To expand RO checking for different OSes, add a method which
+accepts a list of directories and returns a list of mounts which need to be
+remounted RW, then add elif ostype == (the ostype value for your OS) to
+get_ro_checker()
+
+from __future__ import unicode_literals
+
+import logging
+import re
+
+from portage.util import writemsg_level
+from portage.localization import _
+from portage.data import ostype
+
+
+def get_ro_checker():
+   
+   Uses the system type to find an appropriate method for 

[gentoo-portage-dev] [PATCH v2] Add repoman check to warn if src_prepare/src_configure are used in EAPI 0/1 and if pkg_pretend is used in EAPI 4. Fixes bug 379491.

[Chris Reffett]

---
 pym/repoman/checks.py | 29 +
 1 file changed, 29 insertions(+)

diff --git a/pym/repoman/checks.py b/pym/repoman/checks.py
index 85aa065..5c55b0d 100644
--- a/pym/repoman/checks.py
+++ b/pym/repoman/checks.py
@@ -731,6 +731,21 @@ class DeprecatedHasq(LineCheck):
re = re.compile(r'(^|.*\b)hasq\b')
error = errors.HASQ_ERROR
 
+# EAPI 2 checks
+class Eapi01UndefinedPhases(LineCheck):
+   repoman_check_name = 'EAPI.incompatible'
+   src_configprepare_re = re.compile(r'\s*src_(configure|prepare)\s*\(\)')
+
+   def check_eapi(self, eapi):
+   return eapi in ('0', '1')
+
+   def check(self, num, line):
+   m = self.src_configprepare__re.match(line)
+   if m is not None:
+   return (%s % m.group(1)) + \
+phase is not defined in EAPI=0/1 on line: %d
+
+
 # EAPI-3 checks
 class Eapi3DeprecatedFuncs(LineCheck):
repoman_check_name = 'EAPI.deprecated'
@@ -745,6 +760,20 @@ class Eapi3DeprecatedFuncs(LineCheck):
return ('%s' % m.group(1)) + \
 has been deprecated in EAPI=3 on line: %d
 
+# EAPI 4 checks
+class Eapi0123UndefinedPhases(LineCheck):
+   repoman_check_name = 'EAPI.incompatible'
+   pkg_pretend_re = re.compile(r'\s*pkg_pretend\s*\(\)')
+
+   def check_eapi(self, eapi):
+   return eapi in ('0', '1', '2', '3')
+
+   def check(self, num, line):
+   m = self.pkg_pretend_re.match(line)
+   if m is not None:
+   return (%s % m.group(1)) + \
+phase is not defined in EAPI  4 on line: %d
+
 # EAPI-4 checks
 class Eapi4IncompatibleFuncs(LineCheck):
repoman_check_name = 'EAPI.incompatible'
-- 
1.8.5.1

[gentoo-portage-dev] [PATCH v3] Add repoman check to warn if src_prepare/src_configure are used in EAPI 0/1 and if pkg_pretend is used in EAPI 4. Fixes bug 379491.

[Chris Reffett]

---
 pym/repoman/checks.py | 29 +
 1 file changed, 29 insertions(+)

Ignore v2, I apparently didn't commit all of my changes and so that patch
won't work. Undid the compression of the src_prepare/src_configure regex,
because the way that the regex is set up means that it would output prepare
phase is not defined in EAPI... instead of src_prepare and I feel that
it's more intuitive to match the full name of the function instead of tacking
src_ in front of the output.


diff --git a/pym/repoman/checks.py b/pym/repoman/checks.py
index 85aa065..c6860d8 100644
--- a/pym/repoman/checks.py
+++ b/pym/repoman/checks.py
@@ -731,6 +731,21 @@ class DeprecatedHasq(LineCheck):
re = re.compile(r'(^|.*\b)hasq\b')
error = errors.HASQ_ERROR
 
+# EAPI 2 checks
+class Eapi01UndefinedPhases(LineCheck):
+   repoman_check_name = 'EAPI.incompatible'
+   src_configprepare_re = 
re.compile(r'\s*(src_configure|src_prepare)\s*\(\)')
+
+   def check_eapi(self, eapi):
+   return eapi in ('0', '1')
+
+   def check(self, num, line):
+   m = self.src_configprepare_re.match(line)
+   if m is not None:
+   return ('%s' % m.group(1)) + \
+phase is not defined in EAPI  2 on line: %d
+
+
 # EAPI-3 checks
 class Eapi3DeprecatedFuncs(LineCheck):
repoman_check_name = 'EAPI.deprecated'
@@ -745,6 +760,20 @@ class Eapi3DeprecatedFuncs(LineCheck):
return ('%s' % m.group(1)) + \
 has been deprecated in EAPI=3 on line: %d
 
+# EAPI 4 checks
+class Eapi0123UndefinedPhases(LineCheck):
+   repoman_check_name = 'EAPI.incompatible'
+   pkg_pretend_re = re.compile(r'\s*(pkg_pretend)\s*\(\)')
+
+   def check_eapi(self, eapi):
+   return eapi in ('0', '1', '2', '3')
+
+   def check(self, num, line):
+   m = self.pkg_pretend_re.match(line)
+   if m is not None:
+   return ('%s' % m.group(1)) + \
+phase is not defined in EAPI  4 on line: %d
+
 # EAPI-4 checks
 class Eapi4IncompatibleFuncs(LineCheck):
repoman_check_name = 'EAPI.incompatible'
-- 
1.8.5.1

[gentoo-portage-dev] [PATCH v4] Add repoman check to warn if src_prepare/src_configure are used in EAPI 0/1 and if pkg_pretend is used in EAPI 4. Fixes bug 379491.

[Chris Reffett]

---
 pym/repoman/checks.py | 31 ++-
 1 file changed, 30 insertions(+), 1 deletion(-)

diff --git a/pym/repoman/checks.py b/pym/repoman/checks.py
index 85aa065..c814fa7 100644
--- a/pym/repoman/checks.py
+++ b/pym/repoman/checks.py
@@ -15,7 +15,7 @@ import repoman.errors as errors
 import portage
 from portage.eapi import eapi_supports_prefix, eapi_has_implicit_rdepend, \
eapi_has_src_prepare_and_src_configure, eapi_has_dosed_dohard, \
-   eapi_exports_AA
+   eapi_exports_AA, eapi_has_pkg_pretend
 
 class LineCheck(object):
Run a check on a line of an ebuild.
@@ -731,6 +731,21 @@ class DeprecatedHasq(LineCheck):
re = re.compile(r'(^|.*\b)hasq\b')
error = errors.HASQ_ERROR
 
+# EAPI 2 checks
+class UndefinedSrcPrepareSrcConfigurePhases(LineCheck):
+   repoman_check_name = 'EAPI.incompatible'
+   src_configprepare_re = 
re.compile(r'\s*(src_configure|src_prepare)\s*\(\)')
+
+   def check_eapi(self, eapi):
+   return not eapi_has_src_prepare_and_src_configure(eapi)
+
+   def check(self, num, line):
+   m = self.src_configprepare_re.match(line)
+   if m is not None:
+   return ('%s' % m.group(1)) + \
+phase is not defined in EAPI  2 on line: %d
+
+
 # EAPI-3 checks
 class Eapi3DeprecatedFuncs(LineCheck):
repoman_check_name = 'EAPI.deprecated'
@@ -745,6 +760,20 @@ class Eapi3DeprecatedFuncs(LineCheck):
return ('%s' % m.group(1)) + \
 has been deprecated in EAPI=3 on line: %d
 
+# EAPI 4 checks
+class UndefinedPkgPretendPhase(LineCheck):
+   repoman_check_name = 'EAPI.incompatible'
+   pkg_pretend_re = re.compile(r'\s*(pkg_pretend)\s*\(\)')
+
+   def check_eapi(self, eapi):
+   return not eapi_has_pkg_pretend(eapi)
+
+   def check(self, num, line):
+   m = self.pkg_pretend_re.match(line)
+   if m is not None:
+   return ('%s' % m.group(1)) + \
+phase is not defined in EAPI  4 on line: %d
+
 # EAPI-4 checks
 class Eapi4IncompatibleFuncs(LineCheck):
repoman_check_name = 'EAPI.incompatible'
-- 
1.8.5.1

Re: [gentoo-portage-dev] [PATCH] Check for and report read-only filesystems

[Chris Reffett]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/11/2014 12:09 AM, Brian Dolbec wrote:
 On Fri, 2014-01-10 at 22:07 -0500, Chris Reffett wrote:
 Hi all, Attached is a patch to test if Portage is going to write
 to a read-only filesystem and print out the list of filesystems
 that need to be remounted RW. This leaves ${D} intact rather than
 having some files moved before hitting the RO filesystem. Fixes
 bug 378869. Since git.overlays.gentoo.org is down, I haven't had
 the chance to rebase this against latest, but I can resubmit if
 it doesn't cleanly apply. This is my first patch to the list, so
 I apologize if I didn't submit correctly.
 
 Chris Reffett
 
 
 yeah, patch looks good.
 
 Only thing I didn't like is the return 1  IS that suppose to be
 True or sys.exit() value?
 
 If that is what the module was using, then it's ok.  Personally I'm
 not a fan of using 0, 1 for False, True.
 
 But that will come later...
 
That was just following the style of the rest of the module, for
example a collision will return 1. This can be added to the stuff to
be fixed up in future patches list.

Chris Reffett
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iKUEARECAGYFAlLRU7VfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2NzU5RjUyMDczREJDQkVDQTBDRkE1NERC
Nzk1QThBNDI2MTgzNTQACgkQ23laikJhg1QLjQCfSJSpacHoI/IQPS/o+NFJvP6q
d8YAmP+RmhoWwa3J1eRNk0BAxX1TtDg=
=a7If
-END PGP SIGNATURE-

[gentoo-portage-dev] [PATCH] Check for and report read-only filesystems

[Chris Reffett]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi all,
Attached is a patch to test if Portage is going to write to a
read-only filesystem and print out the list of filesystems that need
to be remounted RW. This leaves ${D} intact rather than having some
files moved before hitting the RO filesystem. Fixes bug 378869. Since
git.overlays.gentoo.org is down, I haven't had the chance to rebase
this against latest, but I can resubmit if it doesn't cleanly apply.
This is my first patch to the list, so I apologize if I didn't submit
correctly.

Chris Reffett
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iKYEARECAGYFAlLQtYhfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2NzU5RjUyMDczREJDQkVDQTBDRkE1NERC
Nzk1QThBNDI2MTgzNTQACgkQ23laikJhg1SCCgCfZIo57KiijmACnDTa2vC9UMAb
9YwAoIhnc/nHDcIXBbzF9Tie3eTJyWpH
=j/1A
-END PGP SIGNATURE-
From c464ac5e0007a087def9a96efea9653e508e57c1 Mon Sep 17 00:00:00 2001
From: Chris Reffett creff...@gentoo.org
Date: Fri, 10 Jan 2014 09:03:26 -0500
Subject: [PATCH] Test for read-only filesystems, bail out during preinst if
 there are any which will be written to and display a useful error message.
 Fixes bug 378869.

---
 pym/portage/dbapi/vartree.py   | 31 
 pym/portage/util/checkwriteable.py | 49 ++
 2 files changed, 80 insertions(+)
 create mode 100644 pym/portage/util/checkwriteable.py

diff --git a/pym/portage/dbapi/vartree.py b/pym/portage/dbapi/vartree.py
index ed62323..8ae7014 100644
--- a/pym/portage/dbapi/vartree.py
+++ b/pym/portage/dbapi/vartree.py
@@ -28,6 +28,7 @@ portage.proxy.lazyimport.lazyimport(globals(),
 	'portage.util:apply_secpass_permissions,ConfigProtect,ensure_dirs,' + \
 		'writemsg,writemsg_level,write_atomic,atomic_ofstream,writedict,' + \
 		'grabdict,normalize_path,new_protect_filename',
+	'portage.util.checkwriteable:check_dirs_writeable',
 	'portage.util.digraph:digraph',
 	'portage.util.env_update:env_update',
 	'portage.util.listdir:dircache,listdir',
@@ -3508,6 +3509,8 @@ class dblink(object):
 		
 		This function does the following:
 		
+		calls check_dirs_writeable to verify that no files will be
+		written to read-only filesystems
 		calls self._preserve_libs if FEATURES=preserve-libs
 		calls self._collision_protect if FEATURES=collision-protect
 		calls doebuild(mydo=pkg_preinst)
@@ -3685,6 +3688,7 @@ class dblink(object):
 			eagain_error = False
 
 			myfilelist = []
+			mydirlist = []
 			mylinklist = []
 			paths_with_newlines = []
 			def onerror(e):
@@ -3717,6 +3721,9 @@ class dblink(object):
 	unicode_errors.append(new_parent[ed_len:])
 	break
 
+relative_path = parent[srcroot_len:]
+mydirlist.append(/ + relative_path)
+
 for fname in files:
 	try:
 		fname = _unicode_decode(fname,
@@ -3829,6 +3836,30 @@ class dblink(object):
 			for other in others_in_slot])
 		prepare_build_dirs(settings=self.settings, cleanup=cleanup)
 
+		# Check for read-only filesystems
+		rofilesystems = check_dirs_writeable(mydirlist)
+
+		if rofilesystems:
+			msg = _(One or more files installed to this package are 
+set to be installed to read-only filesystems. 
+Please mount the filesystems below read-write 
+and retry.)
+			msg = textwrap.wrap(msg, 70)
+			msg.append()
+			for f in rofilesystems:
+msg.append(\t%s % os.path.join(destroot,
+	f.lstrip(os.path.sep)))
+			msg.append()
+			self._elog(eerror, preinst, msg)
+
+			msg = _(Package '%s' NOT merged due to read-only file systems.) % \
+self.settings.mycpv
+			msg += _( If necessary, refer to your elog 
+messages for the whole content of the above message.)
+			msg = textwrap.wrap(msg, 70)
+			eerror(msg)
+			return 1
+
 		# check for package collisions
 		blockers = self._blockers
 		if blockers is None:
diff --git a/pym/portage/util/checkwriteable.py b/pym/portage/util/checkwriteable.py
new file mode 100644
index 000..9bd9056
--- /dev/null
+++ b/pym/portage/util/checkwriteable.py
@@ -0,0 +1,49 @@
+#-*- coding:utf-8 -*-
+# Copyright 2014 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+
+from __future__ import unicode_literals
+
+import re
+
+from portage.util import writemsg
+from portage.localization import _
+
+
+def check_dirs_writeable(dir_list):
+	
+	Use /proc/mounts to check that no directories installed by the ebuild are set to
+	be installed to	a read-only filesystem
+
+	@param dir_list: Directories installed by the ebuild
+	@type dir_list: List
+	@return:
+	1. A list of filesystems which are both set to be written to and are mounted
+	read-only, may be empty.
+	
+	ro_filesystems = set()
+	ro_filesystems_written = set()
+
+	try:
+		with open(/proc/mounts) as procmounts:
+			roregex = re.compile(r'(\A|,)ro(\Z|,)')
+			for line in procmounts:
+if roregex.search(line.split( )[3].strip()) is not None:
+	romount

Re: [gentoo-dev] Re: Portage QOS

[Chris Reffett]

On 01/09/2014 03:42 PM, Igor wrote:
 Hello Duncan,
 
 Thursday, January 9, 2014, 9:59:50 PM, you wrote:
 
 Thank you for the reply. I started to comment first... but it was more
 philosophy a mature and grown up, experienced man and I don't think
 I have right to comment it.
 
 Statistically if you have more users the probability of the system
 survival of any architecture, philosophy or type is higher. People
 learn, they're not fixed and if they at the beginning do not share
 the philosophy of the system but they can use it - they may like it,
 understand it and follow it and support later. Many people I asked
 are not minding to help Gentoo getting better by turning on
 feedback. If you remember - feedback worked well for Perl once and
 many used it and Perl is very traditional.
 
 It's like a chess game. You have the system in it's prime. There is
 already one fork from Gentoo. There will be more. It's inevitable. You
 have to understand that not all the developers share the same
 philosophy - and it OK.
 And they may fork Gentoo with time and pull half of the team to their
 side.
 
 When there is a competition between systems with equal philosophy the
 only thing that stands between who is going to live and who is going
 to die is the number of users.
 The fight will focus not around philosophy or system but around gaining
 user support. The competitor can build a better, more friendly system
 sharing basically the same design and he will win it over.
 
 To keep in power it's in your deepest interest to close the open gates that
 invite competition while the power is in your hands. This is a failure
 many grown up companies made they belive they're forever and gods. I could
 share with you privately with several examples that prove that concept
 wrong.
 
 Your competitors will build basically the same system targeting the
 same philosophy but more user oriented, friendly. User oriented - means
 each user opinion matters.
 
 There might be millions of users but each is treated like he is the only one.
 
 
 PortageQOS is small step, it's not everything or main part of the
 system, it's a just small contribution. But it will close the door and
 you'll have another peaceful 8 years to rule.
 
Right here is the big problem: you're not looking at this from the
perspective of the average Gentoo developer. We don't care about market
share. We don't care whether we're on top for another few years. There
are several forks of Gentoo. I doubt most devs care about them. I
personally know that we're not going to compete with Debian, which has a
huge contributor, or Ubuntu or Red Hat, which have whole companies
behind them. You're selling this as if you're selling to a company which
wants to be on the top of the market and beating out competitors, and
that's not what we are. We are a source-based distro that requires some
effort from users, and people want that or they don't want it.
 What we need is a vote YES or NO. If you against it - vote NO. It's
 perfectly normal, if there would be no NO there would be no need voting.
 
 
 Actually, in that regard it's very possible that gentoo's long planned
 and worked toward cvs-to-git conversion will help finally bust that 
 barrier for gentoo as well.  Time will tell I guess, but that's one more
 reason to try to help make it happen.
 
 
 
 
Chris Reffett

Re: [gentoo-dev] rfc: renaming rc binary in OpenRC

[Chris Reffett]

On 12/11/2013 3:41 PM, William Hubbs wrote:
 All,

 We got a request from Debian to rename the rc binary of OpenRC due to
 a naming conflict they have. They have a port of the att plan 9 shell,
 which has a binary named rc as well[1].

 My thought is to rename our rc to openrc, since that would be
 unique.

 I know at least one thing that will break is everyone's inittab, so
 should I sed their inittab in our live ebuild or expect them to fix it
 and give a warning? I know that once OpenRC with this change is
 released, it will need to probably be p.masked until there is a new
 release of sysvinit that updates the inittab.

 I'm not sure what else will break.

 Does anyone have any ideas wrt other things to look for, or should I
 make the changes upstream and have people let us know what
 else breaks?

 William

 [1] https://bugs.gentoo.org/show_bug.cgi?id=493958
The idea of running a sed on inittab in an ebuild, no matter what the
context, terrifies me. Perhaps we can ease this in slowly by renaming rc
- openrc and symlinking rc - openrc and making a release with that
change concurrent with a news item? Or even just do that in the ebuild
rather than in the actual sources. I don't think Debian will keel over
and die if it takes a little extra time for the change to go through,
and it beats a ton of broken systems.

Chris Reffett

Re: [gentoo-dev] Drop net-analyzer/nagios-* to maintainer-needed

[Chris Reffett]

On 11/8/2013 7:14 PM, Markos Chandras wrote:
 Hi,

 I see nobody seems to take care of nagios packages anymore.
 There are numerous bugs (and many of them are pending version bumps).

 Is the sysadmin@ herd still interested in this package? If not, could
 you please consider moving it to maintainer-needed@? Maybe users are
 interested in working with proxy-maintainers to bring this package up
 to date.

 https://bugs.gentoo.org/buglist.cgi?quicksearch=net-analyzer%2Fnagios

If sysadmin@ doesn't want it, I know a user/potential dev who would be
interested in maintaining it with me as a proxy. Just let me know.

Chris reffett

[gentoo-dev] mobile-phone herd needs help

[Chris Reffett]

Hi folks,
I'm currently the only dev in mobile-phone, and I don't actually use
any of the packages in the herd (I added myself just to keep the
packages from going into m-n, but I don't have the time to attend to the
bugs lately). There aren't too many bugs assigned to the herd at this
point. If nobody joins, I will be removing myself and we'll do the usual
herd-removal procedure within the next couple weeks.

Chris Reffett

[gentoo-dev] Last rites: dev-games/neotools, dev-games/neoengine

[Chris Reffett]

# Chris Reffett creff...@gentoo.org (03 Sep 2013)
# Dead upstream, outstanding security bug #260956.
# Masked for removal in 30 days.
dev-games/neoengine
dev-games/neotools



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] desktop experience on smartphone: thoughts and plans against Ubuntu edge

[Chris Reffett]

Indeed I have. If you want to start such a project, I would certainly be
interested in joining. Plasma Active is basically untested because I
don't have a mobile device with Gentoo and installing it on a normal
computer leads to display sizing issues, but I welcome any suggestions
or bug reports you have for that. What I would really like to see come
out of this is some pre-made Gentoo stage4s for different kinds of
devices, which I think would be a big draw for users.

Chris Reffett
On 8/13/2013 1:09 PM, Andreas K. Huettel wrote:
 Benda, 

 while I won't have the time to contribute much, I would like to tell
you that
 this is definitely a very cool and worthwhile project! I think you
should make
 a project page and sign yourself up as team lead immediately... :)

 Chris Reffett from KDE team has done already a lot of work on
packaging Plasma
 Active, see http://plasma-active.org/ - it's in the KDE overlay but
mostly
 untested so far. You might be interested!

 Best,
 Andreas

 Dear Fellows,

 Canonical is raising money by pushing their concept of Ubuntu for
 Android[1][2]. The idea is to put GNU environment (esp. Ubuntu userland)
 in parallel to Android to drive the external HDMI output with X11
 protocal, so that desktop applications can run on the smartphone.

 The idea is cool, but not new. The idea is general to all android
 devices, while Canonical is binding the concept with its own new device.

 The project is developed underground by Canonical, so far nothing, not
 to say repository, is available except advertisements and the call for
 people to donate.

 As a natual consequence of the on-going Google Summer of Code project,
 Gentoo on Android[3], we can run native Gentoo on *all* the Android
 devices. Compiling out an Xorg and output to HDMI has no theoretical
 difficulty. Furthermore, sharing of graphic output with Android (instead
 of a separate HDMI output) can be explored with wayland x11[4].

 I feel sorry to the behavior of Canonical. We, people from the Gentoo
 community, can show the general public what is the cooperative way to
 develop desktop/smartphone hybrid to benefit all.

 I would like to kick out a sub-project of Gentoo targeting smartphone
 and tablets. It would be nice to find out a solution based on Gentoo for
 desktop/smartphone hybrid *before* Canonical's release.

 Comments welcome.

 Cheers,
 Benda

 1. http://www.ubuntu.com/phone/ubuntu-for-android
 2. http://www.indiegogo.com/projects/ubuntu-edge
 3. http://www.awa.tohoku.ac.jp/~benda/projects/android.html
 4. http://en.wikipedia.org/wiki/Wayland_%28display_server_protocol%29

Re: [gentoo-dev] Re: KDE/semantic-desktop

[Chris Reffett]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/08/2013 01:52 PM, Rich Freeman wrote:
 On Thu, Aug 8, 2013 at 1:44 PM, Martin Vaeth 
 va...@mathematik.uni-wuerzburg.de wrote:
 Sorry for reposting: Somehow the first line got lost making the
 whole posting not understandable...
 
 Andreas K. Huettel dilfri...@gentoo.org wrote:
 
 answer is about 10 additional megs of ram at idle and about 2
 extra seconds to boot.
 
 ..and two huge database servers which lots of disk and ram space
 and a huge waste of compile time (not so much for KDE but more
 for the databases), opening to all sort of possible attacks by
 bugs in these databases whose servers need to be running etc.
 
 
 Do those servers still run if you disable the features in the
 control panel?  I already run MySQL so the only annoyance for me
 was getting it to use the existing instance rather than spawning a
 new one.
 
 If somebody is willing to join the KDE team to support keeping
 that option (even as a proxy maintainer) I think the team should
 work with them.  I think that we should generally offer any choice
 as long as somebody steps up to support it properly (and I do mean
 properly). While I'm sure the KDE team has their faults they do
 announce their meetings/etc and I suspect it would be an easy team
 for an outsider to get involved with as a result.
 
 Rich
 
Lies! Blatant lies! The KDE team has no faults! :)
...but seriously, if someone were willing to work with us and put in
the effort, I'm sure we could work something out. I'll skip the usual
part about explaining our motivations behind the original removal
since that's been discussed ad nauseam in bugs and on the -desktop list.

Chris Reffett
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iKYEARECAGYFAlID4FpfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2NzU5RjUyMDczREJDQkVDQTBDRkE1NERC
Nzk1QThBNDI2MTgzNTQACgkQ23laikJhg1TlrQCfXM1Pmi1lwwBCsSEfwyC3E5MJ
zQUAn2OZ8pvujwUnu+bLtCZ0e4lacuui
=tus9
-END PGP SIGNATURE-

Re: [gentoo-dev] cmake-utils.eclass and bug 475502

[Chris Reffett]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/17/2013 04:57 PM, hasufell wrote:
 I know there was an announcement about the upcoming change to 
 cmake-utils.eclass, however... it is not enough to give a deadline 
 without caring if people actually fixed it by then.
 
 By doing that you risk breaking stable packages which is not
 trivial.
 
 You _must_ do a tinderbox run, test that stuff in an overlay or 
 whatever. You are responsible for ALL reverse deps.
 
 The way it was done... was not appropriate. Please be more careful 
 next time. There are still incoming bugs about broken base_src_* 
 calls. (see the tracker)
 

I discussed this with hasufell on IRC, but I'll lay out the response
on the list too. Yes, this was my fault. We (KDE team) tested in our
overlay, but none of the packages there use the base_src_* calls,
which is why it didn't come up in testing, and I did not realize that
there were packages that did rely on the implicit base inherit to call
base_src_* directly.

Chris Reffett
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iKYEARECAGYFAlHnCfVfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2NzU5RjUyMDczREJDQkVDQTBDRkE1NERC
Nzk1QThBNDI2MTgzNTQACgkQ23laikJhg1T6ZACcC5cDNBCODxrnzlPCTm+L4EgS
wCkAniqjyBFXhIXeXyb0Wbvufkbw68yS
=QM3o
-END PGP SIGNATURE-

[gentoo-dev] Request for testing: plasma-active

[Chris Reffett]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

All,
The KDE team has added Plasma Active to the KDE overlay, under the
(provisional) category name kde-active. Plasma Active is based on KDE
and is designed for mobile devices. We are not able to test it at
present as none of the KDE team has a mobile device running Gentoo, so
we would be very appreciative if community members would help us by
testing and reporting bugs to us. To install it, add the overlay
(layman -a kde) and emerge all of the packages in the kde-active category.

Thanks,
Chris Reffett
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iKYEARECAGYFAlHE4LdfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2NzU5RjUyMDczREJDQkVDQTBDRkE1NERC
Nzk1QThBNDI2MTgzNTQACgkQ23laikJhg1RYvwCgpqhdNy0VJJFPnpmQr46mCS77
mt4AnAi8c78k109hpsTPYqdcNFYpTC7j
=EURc
-END PGP SIGNATURE-

[gentoo-dev] cmake-utils.eclass dropping EAPI 0/1 support

[Chris Reffett]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

All,
At the beginning of July, the KDE team will be removing EAPI 0/1
support from cmake-utils.eclass and inlining the functions from
base.eclass in order to remove that inherit [1]. The modified eclass
is currently available in the KDE overlay. There is one package [2]
remaining in-tree which has EAPI2 which will be handled soon, but
please update any overlay packages using the eclass. I have also added
a deprecation warning to the in-tree cmake-utils.eclass for packages
using EAPI 0/1.


Chris Reffett


[1] https://bugs.gentoo.org/show_bug.cgi?id=459678
[2] https://bugs.gentoo.org/show_bug.cgi?id=460572
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iKYEARECAGYFAlG6PmRfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2NzU5RjUyMDczREJDQkVDQTBDRkE1NERC
Nzk1QThBNDI2MTgzNTQACgkQ23laikJhg1QIkgCfV+VLuCg3bC880EhaTiol4ggB
jhQAoJaBwxZHwH9l4g48olShsnWDZBos
=qeh9
-END PGP SIGNATURE-

Re: [gentoo-dev] cmake-utils.eclass dropping EAPI 0/1 support

[Chris Reffett]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/13/2013 06:37 PM, Alexis Ballier wrote:
 At the beginning of July, the KDE team will be removing EAPI 0/1
  support from cmake-utils.eclass and inlining the functions from
  base.eclass in order to remove that inherit [1].
 
 So, instead of fixing what you consider wrong in base.eclass, you 
 inline it so that if someone improves base.eclass he has to do it 
 for cmake-utils too?
 
We did not actually inline most of the complicated logic from
base.eclass, as to the best of my knowledge epatch itself will handle
all of the corner cases that base_src_prepare covers. The new patching
code essentially consists of [[ ${PATCHES[@]} ]]  epatch
${PATCHES[@]}; epatch_user. As for the reason for the change, the
request and rationale can be seen in the first bug that I linked in
the email.

Chris Reffett
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iKYEARECAGYFAlG6TDVfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2NzU5RjUyMDczREJDQkVDQTBDRkE1NERC
Nzk1QThBNDI2MTgzNTQACgkQ23laikJhg1S3SACgitmH0FVRUNwmJE9e/4JmrwqV
ucwAnj+/+V9ECy9OoCK6eDqSsuiiTgDU
=5QKk
-END PGP SIGNATURE-

Re: [gentoo-dev] theology herd is empty

[Chris Reffett]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/20/2013 04:34 AM, Pacho Ramos wrote:
 If we agree on keeping this herd instead of trying to find one 
 maintainer per package, somebody should join. Otherwise I will
 move their packages to maintainer-needed in a week
 
 Thanks
 
I will join this herd, but anyone who wants to add themselves as a
maintainer to a package is welcome to do so.

Chris Reffett
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlD8LQYACgkQ23laikJhg1SqkgCfbVyh/gK1lCwGJMkuP0I+HDPM
VSwAn2rlVv6TCuvTP8EldDfXruWkHk8v
=dWxs
-END PGP SIGNATURE-

Re: [gentoo-dev] RFC: new qt category

[Chris Reffett]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/17/2013 08:57 AM, Ben de Groot wrote:
 Hi guys,
 
 Presently we already have a good number of split qt-* library
 packages in x11-libs. With the arrival of Qt5 upstream has gone a
 lot further in modularization, so we expect the number of packages
 to grow much more. We, the Gentoo Qt team, are of the opinion that
 the time has come to split all these out into their own category.
 This category is to be used for the various modules and
 applications that belong to the upstream Qt Framework only (these
 include e.g. assistant and linguist). Third-party applications
 should remain in the current categories.
 
 After some initial bikeshedding we came to the conclusion that
 naming the category simply qt is the most elegant solution. We
 will then also be dropping the qt- prefix in package names. This
 means x11-libs/qt-core will be moved to qt/core, and so on.
 
 Please let us know your thought on this.
 
+1ish. I'm all for a new category (specific naming scheme to be
bikeshedded, no preference there), but I think dropping the qt- prefix
will lead to overly generic/already existing package names: gui
declarative dbus core opengl etc. I don't see any value from
dropping the prefix that would justify this.
Chris Reffett
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlD4RbIACgkQ23laikJhg1SUngCfatp7/zOP4iGym3sitfH6xpA6
mPAAn2+4HWyOF5+qj2DNIn9IjflOXYc4
=TuOb
-END PGP SIGNATURE-

Re: [gentoo-dev] [warning] the bug queue has 100 bugs

[Chris Reffett]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/31/2012 08:52 AM, Tomáš Chvátal wrote:
 2012/10/31 Dirkjan Ochtman d...@gentoo.org:
 That's rather unsurprising...
 
 If you're going to file bugs in a semi-automated manner, might
 as well try to assign to the correct maintainer?
 
 Yep he should've assign them, but anyway the annoying elog
 messages are an issue. And quite few packages suffer from it :-)
 
 Tom
 
I disagree on most of them (and have marked the KDE-related bugs as
WONTFIX appropriately). Messages that tell the user about config
options, or for x functionality install y (at least until we get
SDEPEND or something similar added to portage) should show up every
time in my opinion. Only initial config and you just enabled (flag)
really merits this. Basically, I would rather the user get too many
elog messages than not enough, since I feel that a lot of people skip
over them anyway and so the only display once method makes it far
too easy for important messages to get lost in the shuffle.
Chris Reffett
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlCRQQAACgkQ23laikJhg1Q+aQCeLfXsAmbtXNGOcBzM/vJaMat2
ly0AoKFzB3tPLaSO2RK0p2rWd6CoKMXm
=J+3S
-END PGP SIGNATURE-

Re: [gentoo-dev] dev-embedded/tigcc needs an urgent bump

[Chris Reffett]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/29/12 07:48, Pacho Ramos wrote:
 El lun, 23-04-2012 a las 20:35 +0200, Pacho Ramos escribió:
 Our stable versions are broken for a long time, they even don't compile,
 but we cannot stable latest testing version because of a buffer overflow
 problem. A bump could help, but looks like embedded team doesn't have
 enough time for it. Is anybody interested in taking care of it?

 Its bugs:
 https://bugs.gentoo.org/buglist.cgi?quicksearch=tigcclist_id=978701

 Thanks

 Or maybe we should simply treeclean it if nobody is willing to
 fix/maintain it and since nothing in the tree needs it...

I've submitted what I hope is fix for the buffer overflow problem to bug
337059. Will that be sufficient to remove the block on stabilization?
- --Chris Reffett
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+dm5gACgkQ23laikJhg1Q2aQCeOOHS3tB0gVfCxQ79ldSBMV3N
gEYAn3Ek1hpIhU/CSjsLxMEa13bx8R0t
=0uOv
-END PGP SIGNATURE-