[gentoo-dev] Re: [gentoo-dev-announce] RFC: Graveyard project

[gentoo-dev] Re: [gentoo-dev-announce] RFC: Graveyard project

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/14/2013 04:31 AM, Ben de Groot wrote:
> Hi guys and girls,
> 
> We hereby announce the formation of the Graveyard project [1]. It aims
> to provide users with an overlay for packages removed from portage.
> Users are expressly invited to partake in this project, to help
> maintain the graveyard overlay [2]. We will also help organize a
> central space to host distfiles that are no longer mirrored by Gentoo
> and have a broken upstream link. We use the #gentoo-dev-help channel
> on Freenode for coordination, as well as our project space on the wiki
> [3].

What exactly is wrong with the current cvs attic space? I've salvaged
old ebuilds and it was a completely painless process.

Things that have been treecleaned were not just haphazardly removed,
there is typically very good (often security or complete build failure
related) reasons for this to happen.  Running an overlay of old,
outdated, unbuildable, security vulnerable software... I know there is
no formal process for rejecting a gentoo project but even this idea
makes me want to get council approval for an extension to the gentoo
project guidelines.

If users want to salvage things from the cvs attic and put them into
SUNRISE after fixing them up I'm fine with it, but the whole idea of
this is bad for gentoo developers, bad for gentoo users, bad for gentoo
image, I just don't see a single advantage to this and so many
disadvantages.

Please, this needs to not happen.

Thanks,
Zero


> Please feel free to join us!
> 
> 1: http://www.gentoo.org/proj/en/graveyard/
> 2: https://github.com/gentoo/graveyard
> 3: https://wiki.gentoo.org/wiki/Project:Graveyard
> 

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

iQIcBAEBAgAGBQJRHV1tAAoJEKXdFCfdEflK36YP/j3nXMjBUChv4a/HRVRZbK0P
gEPxljhHLueKpebZfZWG2i/G5RoYT5QTzDpi146+xcKxYxypjnY4EfA3O5erXN7g
rF2j8Ij8Xn4OprxDr+3+l3ojAbr+AMsyteU7jQiXEccN0n/8bDLJ1WaKa+hgy46u
pWP7zm+Mi2S2ZYHuDgH7HbVadC1fyD7IB9heRXdfwuPT6lPA1pgu/jOibMZog2Uh
DJlBx1emDyXt3k/noyFuDiumfNdRAwg6BegrWBuQHFNk0m8ZYiYxuuYFic/a8aRh
Yz0MHsZC+FQd4dx3aDkrHNLJLszWHjyrn9shgtVp7aVu/T3rM9H2BHOZCC00ZtHC
sLkMP69167YaE3UToxAA7eHQpylDBa/maJTHGFZVnz5mV8SzeOjX4ikDkfwNEUuS
LpblNRZHuTDLnDWY6SJWFDK++JDqtAnPXWLAEDqEfEluMC76MVbTdhqjqvNBN8zQ
lMjPTmQ/lihKR4a6LsCCkspmlEv6o4pKqWjghytqDAJuqsA1rIgKaInUPvOfCkCR
5Azl1KyIWL8oUA2OrhZdDvRd4hUlt3mJSEBcx6HC4Oj2NwtmM16zBwSJc3WKt7JC
irk6D2gunFef8z1tcs/SE51lKnW+pFYIMbhyvWtumszZx/dLhu5t78KQe/8vLHnI
S0R5VGULwVZkKVtSiRQK
=mjOM
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: [gentoo-dev-announce] RFC: Graveyard project

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 14/02/13 04:55 PM, Rick "Zero_Chaos" Farina wrote:
> On 02/14/2013 04:31 AM, Ben de Groot wrote:
>> Hi guys and girls,
> 
>> We hereby announce the formation of the Graveyard project [1]. It
>> aims to provide users with an overlay for packages removed from
>> portage. Users are expressly invited to partake in this project,
>> to help maintain the graveyard overlay [2]. We will also help
>> organize a central space to host distfiles that are no longer
>> mirrored by Gentoo and have a broken upstream link. We use the
>> #gentoo-dev-help channel on Freenode for coordination, as well as
>> our project space on the wiki [3].
> 
> What exactly is wrong with the current cvs attic space? I've
> salvaged old ebuilds and it was a completely painless process.
> 

As has been discussed, the attic is fine for ebuilds and stuff saved
in files/ , but patchsets and distfiles (when the upstream src_uri
becomes invalid) are not available.  The graveyard overlay hopes to
alleviate that.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlEdYoMACgkQ2ugaI38ACPDq1AD+PjKwu8FiUUQRFpgu5RBdE65Z
/ROSMfshRZ/iHTCinq0A/RwwoFZZNL149rbbeCXwk/Bvjk3uMBF2Vn4NlonW/koR
=6yUY
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: [gentoo-dev-announce] RFC: Graveyard project

[Jeff Horelick]

[-- Attachment #1: Type: text/plain, Size: 3766 bytes --]

On 14 February 2013 16:55, Rick "Zero_Chaos" Farina <zerochaos@gentoo.org>wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 02/14/2013 04:31 AM, Ben de Groot wrote:
> > Hi guys and girls,
> >
> > We hereby announce the formation of the Graveyard project [1]. It aims
> > to provide users with an overlay for packages removed from portage.
> > Users are expressly invited to partake in this project, to help
> > maintain the graveyard overlay [2]. We will also help organize a
> > central space to host distfiles that are no longer mirrored by Gentoo
> > and have a broken upstream link. We use the #gentoo-dev-help channel
> > on Freenode for coordination, as well as our project space on the wiki
> > [3].
>
> What exactly is wrong with the current cvs attic space? I've salvaged
> old ebuilds and it was a completely painless process.
>
> Things that have been treecleaned were not just haphazardly removed,
> there is typically very good (often security or complete build failure
> related) reasons for this to happen.  Running an overlay of old,
> outdated, unbuildable, security vulnerable software... I know there is
> no formal process for rejecting a gentoo project but even this idea
> makes me want to get council approval for an extension to the gentoo
> project guidelines.
>
> If users want to salvage things from the cvs attic and put them into
> SUNRISE after fixing them up I'm fine with it, but the whole idea of
> this is bad for gentoo developers, bad for gentoo users, bad for gentoo
> image, I just don't see a single advantage to this and so many
> disadvantages.
>
> Please, this needs to not happen.
>
> Thanks,
> Zero
>
>
> > Please feel free to join us!
> >
> > 1: http://www.gentoo.org/proj/en/graveyard/
> > 2: https://github.com/gentoo/graveyard
> > 3: https://wiki.gentoo.org/wiki/Project:Graveyard
> >
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.19 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJRHV1tAAoJEKXdFCfdEflK36YP/j3nXMjBUChv4a/HRVRZbK0P
> gEPxljhHLueKpebZfZWG2i/G5RoYT5QTzDpi146+xcKxYxypjnY4EfA3O5erXN7g
> rF2j8Ij8Xn4OprxDr+3+l3ojAbr+AMsyteU7jQiXEccN0n/8bDLJ1WaKa+hgy46u
> pWP7zm+Mi2S2ZYHuDgH7HbVadC1fyD7IB9heRXdfwuPT6lPA1pgu/jOibMZog2Uh
> DJlBx1emDyXt3k/noyFuDiumfNdRAwg6BegrWBuQHFNk0m8ZYiYxuuYFic/a8aRh
> Yz0MHsZC+FQd4dx3aDkrHNLJLszWHjyrn9shgtVp7aVu/T3rM9H2BHOZCC00ZtHC
> sLkMP69167YaE3UToxAA7eHQpylDBa/maJTHGFZVnz5mV8SzeOjX4ikDkfwNEUuS
> LpblNRZHuTDLnDWY6SJWFDK++JDqtAnPXWLAEDqEfEluMC76MVbTdhqjqvNBN8zQ
> lMjPTmQ/lihKR4a6LsCCkspmlEv6o4pKqWjghytqDAJuqsA1rIgKaInUPvOfCkCR
> 5Azl1KyIWL8oUA2OrhZdDvRd4hUlt3mJSEBcx6HC4Oj2NwtmM16zBwSJc3WKt7JC
> irk6D2gunFef8z1tcs/SE51lKnW+pFYIMbhyvWtumszZx/dLhu5t78KQe/8vLHnI
> S0R5VGULwVZkKVtSiRQK
> =mjOM
> -----END PGP SIGNATURE-----
>
>

IMO, all these reasons are solved by the statement: "This is why it will be
an OVERLAY and there will be no stable packages even if they were stable in
the tree before masking for removal". Packages that have tons of security
issues or do not build whatsoever will obviously not be added (unless
someone wants to give us a patch or 2 to solve those problems). Sunrise is
the wrong place for stuff that still works. Sunrise is about stuff incoming
to the tree (hopefully eventually) not outgoing from the tree.

The reason for this overlay is for packages like: media-tv/ivtv and
net-wireless/at76c503a which seem to be masked for removal because they're
deprecated and likely still work. Perhaps a user is having problems with
the driver that replaced either of these and is still using th old one
since it works fine for his hardware. There are tons of good reasons to
keep old packages around, yes a few possible bad ones as well, but that's
the case with almost anything.

[-- Attachment #2: Type: text/html, Size: 4626 bytes --]

Re: [gentoo-dev] Re: [gentoo-dev-announce] RFC: Graveyard project

[Florian Philipp]

[-- Attachment #1: Type: text/plain, Size: 3180 bytes --]

Am 14.02.2013 22:55, schrieb Rick "Zero_Chaos" Farina:
> On 02/14/2013 04:31 AM, Ben de Groot wrote:
>> Hi guys and girls,
> 
>> We hereby announce the formation of the Graveyard project [1]. It aims
>> to provide users with an overlay for packages removed from portage.
>> Users are expressly invited to partake in this project, to help
>> maintain the graveyard overlay [2]. We will also help organize a
>> central space to host distfiles that are no longer mirrored by Gentoo
>> and have a broken upstream link. We use the #gentoo-dev-help channel
>> on Freenode for coordination, as well as our project space on the wiki
>> [3].
> 
> What exactly is wrong with the current cvs attic space? I've salvaged
> old ebuilds and it was a completely painless process.
> 

The attic is not a ready-to-use overlay. Part of the idea is to remove
the effort of keeping local overlays. Why revive a package N times when
one time is sufficient?

Besides, distfiles for ebuilds in the attic are probably no longer
mirrored and for dead upstreams, they might not exist anywhere else, either.

> Things that have been treecleaned were not just haphazardly removed,
> there is typically very good (often security or complete build failure
> related) reasons for this to happen.  Running an overlay of old,
> outdated, unbuildable, security vulnerable software... I know there is
> no formal process for rejecting a gentoo project but even this idea
> makes me want to get council approval for an extension to the gentoo
> project guidelines.
> 

There have been at least three discussions on what is to be treecleaned
and what not in the past few months. I don't think we have to re-iterate
them. Suffice to say there are more than enough cases where a) no dev
wants to maintain a package anymore, b) a case can be made that the
package should not be left rotting in tree and c) someone might still
have use for the package.

There is simply an unsolvable disagreement between those who want a
slick and well maintained tree and those who view the sheer size of the
tree as one of Gentoo's assets. In this way. the whole discussion
reminds me of the deletionism debate on Wikipedia [1] with the
difference that here there is an easy compromise. So why not make it?

> If users want to salvage things from the cvs attic and put them into
> SUNRISE after fixing them up I'm fine with it, but the whole idea of
> this is bad for gentoo developers, bad for gentoo users, bad for gentoo
> image, I just don't see a single advantage to this and so many
> disadvantages.
> 

Why is the overlay bad for anyone? No dev is forced to contribute to it
and no user has to activate it. There are dozens of overlays out there
which are not meant to be activated unless you know what you are doing.
I don't see how this can affect Gentoo's image (as observed by whom,
anyway?). I mean, it's no different than the attic, just more
convenient. It's just one more niche in this great Gentoo ecosystem.
kde-sunset isn't hurting anyone, either.

[1] https://en.wikipedia.org/wiki/Deletionism_and_inclusionism_in_Wikipedia

Regards,
Florian Philipp


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

Re: [gentoo-dev] Re: [gentoo-dev-announce] RFC: Graveyard project

[Diego Elio Pettenò]

[-- Attachment #1: Type: text/plain, Size: 790 bytes --]

On 14/02/2013 23:47, Florian Philipp wrote:
> Why is the overlay bad for anyone? No dev is forced to contribute to it
> and no user has to activate it. There are dozens of overlays out there
> which are not meant to be activated unless you know what you are doing.
> I don't see how this can affect Gentoo's image (as observed by whom,
> anyway?). I mean, it's no different than the attic, just more
> convenient. It's just one more niche in this great Gentoo ecosystem.
> kde-sunset isn't hurting anyone, either.

The presence of "dozens of overlays" _is_ hurting triaging and other
issues. Things like proaudio overlay should die in a fire, and stop
bothering us to begin with.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

Re: [gentoo-dev] Re: [gentoo-dev-announce] RFC: Graveyard project

[Rich Freeman]

On Thu, Feb 14, 2013 at 7:06 PM, Diego Elio Pettenò
<flameeyes@flameeyes.eu> wrote:
>
> The presence of "dozens of overlays" _is_ hurting triaging and other
> issues. Things like proaudio overlay should die in a fire, and stop
> bothering us to begin with.

How?  We don't support overlays in the main tree.  I could see a
package maintainer being nice if pinged by an overlay maintainer and
delaying some change for a short time to let an overlay be updated,
but issues that impact overlays should not be considered blockers on
closing bugs on the main tree.

If there is something wrong with the proaudio overlay just don't use
it.  The same would apply to sunset.

Rich

Re: [gentoo-dev] Re: [gentoo-dev-announce] RFC: Graveyard project

[Diego Elio Pettenò]

On 15/02/2013 01:15, Rich Freeman wrote:
> How?  We don't support overlays in the main tree.  I could see a
> package maintainer being nice if pinged by an overlay maintainer and
> delaying some change for a short time to let an overlay be updated,
> but issues that impact overlays should not be considered blockers on
> closing bugs on the main tree.

The problem is when you have to triple-check that the user hasn't
enabled some random fucked up overlay and you have to guess whether that
might be the cause of the problem. Yes it happens, not so rarely.

> If there is something wrong with the proaudio overlay just don't use
> it.  The same would apply to sunset.

I don't use it; people still report bugs with it.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] Re: [gentoo-dev-announce] RFC: Graveyard project

[Rich Freeman]

On Thu, Feb 14, 2013 at 7:19 PM, Diego Elio Pettenò
<flameeyes@flameeyes.eu> wrote:
> The problem is when you have to triple-check that the user hasn't
> enabled some random fucked up overlay and you have to guess whether that
> might be the cause of the problem. Yes it happens, not so rarely.

Ah, I always thought of overlays as places where apps tend to reside,
but of course you could have glibc in there for all we know...  Good
point...

I'd think that this would be less of an issue for something like
sunset, but perhaps this is something the maintainers should keep in
mind.

Rich

Re: [gentoo-dev] Re: [gentoo-dev-announce] RFC: Graveyard project

[Diego Elio Pettenò]

On 15/02/2013 02:18, Rich Freeman wrote:
> Ah, I always thought of overlays as places where apps tend to reside,
> but of course you could have glibc in there for all we know...  Good
> point...

Welcome to the life of your average Gentoo ebuild maintainer.

> I'd think that this would be less of an issue for something like
> sunset, but perhaps this is something the maintainers should keep in
> mind.

What I'm afraid of is automagic dependencies, especially for obsolete
libraries that are basically dead. Yes it's still a valid bug, but it's
also a waste of time to debug for the most part.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] Re: [gentoo-dev-announce] RFC: Graveyard project

[Peter Stuge]

Diego Elio Pettenò wrote:
> > Ah, I always thought of overlays as places where apps tend to reside,
> > but of course you could have glibc in there for all we know...  Good
> > point...
> 
> Welcome to the life of your average Gentoo ebuild maintainer.

Stop complaining (and with foul language! come on, you sound like
an idiot, which seems unneccessary) and let's think about solutions.

Do I understand correctly that you consider the problem to be that
it's not clear whether a system in a bug report has ebuilds from an
overlay in the dependency chain or not?

A very low resolution solution would be a tainted flag like the one
in the kernel, but perhaps we can do something a bit better.

emerge could output this information sometime before src_unpack. It
would be very visible in every emerge log, and it would certainly be
helpful for everyone who understands overlays - it's certainly easy
to imagine that it could completely preempt some invalid bug reports.

If I do an emerge I typically know if I want dependencies out of an
overlay or not.

Another potentially interesting vector is to add overlay policies to
ebuilds, although this means introducing arbitrary limitations, which
generally doesn't make sense.


I'm sure there are more and better interesting solutions to this
problem. Let's hear?


//Peter

Re: [gentoo-dev] Re: [gentoo-dev-announce] RFC: Graveyard project

[Diego Elio Pettenò]

On 15/02/2013 02:56, Peter Stuge wrote:
> Stop complaining (and with foul language! come on, you sound like
> an idiot, which seems unneccessary) and let's think about solutions.

Your laziness makes you sound like an idiot too, thank you very much.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] Re: [gentoo-dev-announce] RFC: Graveyard project

[Peter Stuge]

Diego Elio Pettenò wrote:
> > Stop complaining (and with foul language! come on, you sound like
> > an idiot, which seems unneccessary) and let's think about solutions.
> 
> Your laziness makes you sound like an idiot too, thank you very much.

Send me constructive criticism in an email and I'll of course
consider it. Perhaps you can consider solutions for the overlay
problem?

I think overlays are an awesome feature, and I think that the
problems that they obviously have caused you to make you dislike
them and anyone supporting them should be solved.

Technology is all about approaching both having and eating cake, ie.
being lazy.


//Peter

Re: [gentoo-dev] Re: [gentoo-dev-announce] RFC: Graveyard project

[Florian Philipp]

[-- Attachment #1: Type: text/plain, Size: 1336 bytes --]

Am 15.02.2013 01:19, schrieb Diego Elio Pettenò:
> On 15/02/2013 01:15, Rich Freeman wrote:
>> How?  We don't support overlays in the main tree.  I could see a
>> package maintainer being nice if pinged by an overlay maintainer and
>> delaying some change for a short time to let an overlay be updated,
>> but issues that impact overlays should not be considered blockers on
>> closing bugs on the main tree.
> 
> The problem is when you have to triple-check that the user hasn't
> enabled some random fucked up overlay and you have to guess whether that
> might be the cause of the problem. Yes it happens, not so rarely.
> 
>> If there is something wrong with the proaudio overlay just don't use
>> it.  The same would apply to sunset.
> 
> I don't use it; people still report bugs with it.
> 

I understand your argument but isn't something like graveyard actually
an advantage in this case? If people use local or less clearly named
overlays, it's hard so say whether that is the problem. If they install
packages outside of portage, you have no way of knowing it before they
mention it, either.

Graveyard, on the other hand, shows up clearly in `emerge --info` and
is, in my opinion, one of the most justified reasons to close a bug with
WONTFIX without looking further.

Regards,
Florian Philipp


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

Re: [gentoo-dev] Re: [gentoo-dev-announce] RFC: Graveyard project

[Markos Chandras]

On 15 February 2013 00:19, Diego Elio Pettenò <flameeyes@flameeyes.eu> wrote:
> On 15/02/2013 01:15, Rich Freeman wrote:
>> How?  We don't support overlays in the main tree.  I could see a
>> package maintainer being nice if pinged by an overlay maintainer and
>> delaying some change for a short time to let an overlay be updated,
>> but issues that impact overlays should not be considered blockers on
>> closing bugs on the main tree.
>
> The problem is when you have to triple-check that the user hasn't
> enabled some random fucked up overlay and you have to guess whether that
> might be the cause of the problem. Yes it happens, not so rarely.
>

That's not a good argument. You can't stop people from using whatever
external sources they want. But you can easily
spot what they use from a simple eix -e <broken-package> or emerge
--info and close the bug as INVALID in the blink of an eye

-- 
Regards,
Markos Chandras - Gentoo Linux Developer
http://dev.gentoo.org/~hwoarang

Re: [gentoo-dev] Re: [gentoo-dev-announce] RFC: Graveyard project

[Cyprien Nicolas]

[-- Attachment #1: Type: text/plain, Size: 1098 bytes --]

On Fri, Feb 15, 2013 at 09:39:34AM +0000, Markos Chandras wrote:
> On 15 February 2013 00:19, Diego Elio Pettenò <flameeyes@flameeyes.eu> wrote:
> > The problem is when you have to triple-check that the user hasn't
> > enabled some random fucked up overlay and you have to guess whether that
> > might be the cause of the problem. Yes it happens, not so rarely.
> >
>
> That's not a good argument. You can't stop people from using whatever
> external sources they want. But you can easily
> spot what they use from a simple eix -e <broken-package> or emerge
> --info and close the bug as INVALID in the blink of an eye

Not really, this works when the bug is opened against a given package
from an overlay. Diego's raised issue is about some *DEPEND installed
from an overlay, but the failing package is from the tree.

emerge --info will not report from which overlays the *DEPEND has been
installed. I don't know of a simple command to list installed reverse
dependencies; qdepends -Q does not show repo_name info.

-- 
Cyprien Nicolas (Fulax)
Gentoo Lisp project contrib

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: [gentoo-dev-announce] RFC: Graveyard project

[Cyprien Nicolas]

[-- Attachment #1: Type: text/plain, Size: 712 bytes --]

On Fri, Feb 15, 2013 at 01:48:34PM +0100, Cyprien Nicolas wrote:
> Not really, this works when the bug is opened against a given package
> from an overlay. Diego's raised issue is about some *DEPEND installed
> from an overlay, but the failing package is from the tree.
>
> emerge --info will not report from which overlays the *DEPEND has been
> installed. I don't know of a simple command to list installed reverse
> dependencies; qdepends -Q does not show repo_name info.

Forget about reverse dependencies and the -Q switch, It is out of
topic here (and emerge -pc list them). The rest holds, qdepend won't
list slots or repositories.

-- 
Cyprien Nicolas (Fulax)
Gentoo Lisp project contrib

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: [gentoo-dev-announce] RFC: Graveyard project

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 15/02/13 08:10 AM, Cyprien Nicolas wrote:
> On Fri, Feb 15, 2013 at 01:48:34PM +0100, Cyprien Nicolas wrote:
>> Not really, this works when the bug is opened against a given
>> package from an overlay. Diego's raised issue is about some
>> *DEPEND installed from an overlay, but the failing package is
>> from the tree.
>> 
>> emerge --info will not report from which overlays the *DEPEND has
>> been installed. I don't know of a simple command to list
>> installed reverse dependencies; qdepends -Q does not show
>> repo_name info.
> 
> Forget about reverse dependencies and the -Q switch, It is out of 
> topic here (and emerge -pc list them). The rest holds, qdepend
> won't list slots or repositories.
> 

I expect to see the full result one would have to emerge -epv
[package] , at least that will report the repos for all *DEPENDs
(although it is a bit overkill to have users submit that in the
general case)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlEePMcACgkQ2ugaI38ACPC+lgEAvt9MIA9b9fVj2e527d4VNKbs
UwQXS87lxvLIZ3ELVs0A/2TPDdCprzgP1tmawD7vaGniSqEJkki4SFcy3MdyNSRM
=2JkD
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: [gentoo-dev-announce] RFC: Graveyard project

[Ben Kohler]

[-- Attachment #1: Type: text/plain, Size: 587 bytes --]

On Fri, Feb 15, 2013 at 7:48 AM, Ian Stakenvicius <axs@gentoo.org> wrote:
>
>
> I expect to see the full result one would have to emerge -epv
> [package] , at least that will report the repos for all *DEPENDs
> (although it is a bit overkill to have users submit that in the
> general case)
>
> There are also commands like "eix --installed-from-overlay" to see at a
glance what questionable packages may be in play.  Clearly we have a dev or
2 with some overlay hate, but I don't really think that's relevant to this
project discussion.  It certainly shouldn't be a show stopper.

-Ben

[-- Attachment #2: Type: text/html, Size: 1039 bytes --]

Re: [gentoo-dev] Re: [gentoo-dev-announce] RFC: Graveyard project

[Alec Warner]

On Thu, Feb 14, 2013 at 4:19 PM, Diego Elio Pettenò
<flameeyes@flameeyes.eu> wrote:
> On 15/02/2013 01:15, Rich Freeman wrote:
>> How?  We don't support overlays in the main tree.  I could see a
>> package maintainer being nice if pinged by an overlay maintainer and
>> delaying some change for a short time to let an overlay be updated,
>> but issues that impact overlays should not be considered blockers on
>> closing bugs on the main tree.
>
> The problem is when you have to triple-check that the user hasn't
> enabled some random fucked up overlay and you have to guess whether that
> might be the cause of the problem. Yes it happens, not so rarely.

I empathize, but I'm not really sure it is a blocker for this effort.
Developers already have to evaluate whether the bug the user filed is
legitimate; I don't think this makes that significantly more
difficult. As stated. spotting overlay usage is pretty simple as-is.

>
>> If there is something wrong with the proaudio overlay just don't use
>> it.  The same would apply to sunset.
>
> I don't use it; people still report bugs with it.
>
> --
> Diego Elio Pettenò — Flameeyes
> flameeyes@flameeyes.eu — http://blog.flameeyes.eu/
>

Re: [gentoo-dev] Re: [gentoo-dev-announce] RFC: Graveyard project

[Diego Elio Pettenò]

On 15/02/2013 10:44, Alec Warner wrote:
> I empathize, but I'm not really sure it is a blocker for this effort.
> Developers already have to evaluate whether the bug the user filed is
> legitimate; I don't think this makes that significantly more
> difficult. As stated. spotting overlay usage is pretty simple as-is.

Did I say that I don't like the graveyard project? I didn't think so.

I only wanted to make it clear to Rich, who seemed not to know or
remember, that overlays are not harmless in and by themselves.

(But I would still argue that "spotting overlay usage" is not always as
simple; at least in one case I got somebody who was trying to hide their
use of proaudio.)

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] Re: [gentoo-dev-announce] RFC: Graveyard project

[Ben de Groot]

On 15 February 2013 22:34, Diego Elio Pettenò <flameeyes@flameeyes.eu> wrote:
> (But I would still argue that "spotting overlay usage" is not always as
> simple; at least in one case I got somebody who was trying to hide their
> use of proaudio.)

Users editing the output of emerge --info and hiding they overlay
usage is another problem. Anyway, overlays are not going away, so we
just need to streamline our process of dealing with the resulting
bugs.

To bring this back on topic, users are going to get tree-cleaned
ebuilds anyway, putting them in their local overlays if they want to
use these packages. We're just facilitating them with a more
centralized solution for this, as there is obvious demand for it.
Plus, this may be a stepping stone for users fixing those packages and
taking up proxy-maintainership.

-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

Re: [gentoo-dev] Re: [gentoo-dev-announce] RFC: Graveyard project

[Alexander Berntsen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 15/02/13 01:19, Diego Elio Pettenò wrote:
> The problem is when you have to triple-check that the user hasn't 
> enabled some random fucked up overlay and you have to guess whether
> that might be the cause of the problem.
Yes. It's difficult to govern freedom.

- -- 
Alexander
alexander@plaimi.net
http://plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlEeDvkACgkQRtClrXBQc7UMeQD6AkaKr3Zk0aYCbMDhIihkrRkP
8fFaJvptfpEZ9b12scMA/14vmSZiCMwzWtDoL0wuEvBjkVwNH9GsPgVRoOVpfPmE
=knmq
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: [gentoo-dev-announce] RFC: Graveyard project

[Diego Elio Pettenò]

[-- Attachment #1: Type: text/plain, Size: 330 bytes --]

On 15/02/2013 11:33, Alexander Berntsen wrote:
> Yes. It's difficult to govern freedom.

Freedom is overrated, especially by those who use such sound bites.

Let me guess, you use CFLAGS="-O3 -funroll-loops"? I sure hope not.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

Re: [gentoo-dev] Re: [gentoo-dev-announce] RFC: Graveyard project

[Alexander Berntsen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 15/02/13 13:58, Diego Elio Pettenò wrote:
> Freedom is overrated, especially by those who use such sound
> bites.
Whilst you do get to decide how and if you choose to value my freedom,
you most certainly do *not* get to decide how I should rate it.

> Let me guess, you use CFLAGS="-O3 -funroll-loops"?
I have performed benchmarking that suggested that O3 is detrimental to
runtime half the time, and only marginally positive the other half
(and unroll-loops (which of course is very sensitive to context) never
resulted in big enough an improvement to make it worth using) --
regardless of CPU and architecture -- so no.

I do not fully see the relevance to the conversation, so I suggest you
take inquiries regarding compiler flags to me privately, or make a new
thread.

- -- 
Alexander
alexander@plaimi.net
http://plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlEeM2MACgkQRtClrXBQc7XpdAEAoYJm9Av+zy/b4YVCvGp78Oy8
h6wzr5SX87gPJNNkx7UA/2xiWgvzuy8sEmIhd0HjQdOWER950FUd9lIKwkwzW6NW
=UMkA
-----END PGP SIGNATURE-----