Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.

[konsolebox]

On Wed, Sep 16, 2015 at 3:29 PM, konsolebox  wrote:
> On Tue, Sep 15, 2015 at 5:31 PM, Ulrich Mueller  wrote:
>>> On Tue, 15 Sep 2015, Ulrich Mueller wrote:
>>
> We consider 5.01 and 5.010 as equal versions.
>>
 And do we still plan to keep them equal when we fix =*?
>>
>>> Yes.
>
> Makes me wonder.  Are there even packages that still follow this
> format?  I.e. one that shifts from 2 digit to 3 digit format where it
> intends to have the third digit as a subversion?

And I find it so wrong that it makes me think that it shouldn't have
been acknowledged by any packaging system.  That versioning madness
should have been just fixed in the ebuilds level.

Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.

[konsolebox]

On Tue, Sep 15, 2015 at 5:31 PM, Ulrich Mueller  wrote:
>> On Tue, 15 Sep 2015, Ulrich Mueller wrote:
>
 We consider 5.01 and 5.010 as equal versions.
>
>>> And do we still plan to keep them equal when we fix =*?
>
>> Yes.

Makes me wonder.  Are there even packages that still follow this
format?  I.e. one that shifts from 2 digit to 3 digit format where it
intends to have the third digit as a subversion?

Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.

[Kent Fredric]

On 15 September 2015 at 06:54, Ulrich Mueller  wrote:
>
>> I think it'd be okay to e.g. change the meaning and behavior of * in
>> a new EAPI.
>
> Bug 560466 now.


Assuming the syntax can be changed in a future EAPI.

What EAPI applies to the use of these specifiers on the command line?

What EAPI applies to the use of these specifiers in /etc/portage/** ?



-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.

[konsolebox]

On Tue, Sep 15, 2015 at 8:18 PM, Ciaran McCreesh
 wrote:
> Semantic versioning is a new fad.

I believe it's already been there for a while.  It just didn't become
a standard soon.

> Certain upstreams still think that
> 5.10 is a lower version that 5.2. Perl used to be notorious for doing
> this, but they've partially changed in some places but not others.
>
> The rules are a mess because they need to a reasonable job of dealing
> with all the crazy.

But these rules may no longer be applicable with the current packages.
Besides I think we can just enforce using 3 digits on versioning
ebuilds when we see a package that uses both 2 digits and 3 digits.

Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.

[Kent Fredric]

On 16 September 2015 at 19:40, konsolebox  wrote:
> And I find it so wrong that it makes me think that it shouldn't have
> been acknowledged by any packaging system.  That versioning madness
> should have been just fixed in the ebuilds level.


Yeah. My experience with versions is its better to have a single
versioning scheme that is regular and well defined, without any
magical "Do everything different if this thing exists here" stuff.
Perl versions suffer seriously from such logic, and gentoo also does,
in different ways.

The reason I believe we permitted versions to have such a variety of
interpretations is to make it easier to track upstream versions 1:1.

But in some places, that just makes our life more miserable for the
attempt, and its more "Sane" to normalise upstream versions into a
scheme that is consistent and makes sense.

After all, that's what our downstream job is: To sanitize upstream for
our users.

And upstream *can* and *will* do utterly rediculous shit with versions
that no single versioning syntax can ever attempt to adjust for. ( For
instance, publishing versions with substrings of MD5s , where the
textual data itself conveys absolutely no relativistic numeric value,
because upstream don't care for progressive scales of versioning, only
a "Have the latest version published or GTFO" mandate, which is
something you can't map sanely )

Hence why perl herd bit that bullet a long time ago and applied a
normalisation scheme, to map the horrible multiple-version-schemes
system into a logical and consistent thing that gentoo handles simply.

It comes with a price of course, that every ebuild has to have a "The
upstream version is really ... " declaration, and people have to
remember to change that when they bump the version, but it leads to
much less dependency version confusions.

-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

[gentoo-dev] Re: code.google.com readonly starting on 25/Aug/15

[Jörg Schaible]

Hi Tobias,

Tobias Klausmann wrote:

> Hi!
> 
> Tomorrow, code.google.com will turn off write access to all
> remaining projects[0]. As such, Gentoo ebuilds which still have
> HOMEPAGE= pointing there should be updated.

Hmm. Codehaus has also been shut down this year in May, but packages still 
refer it as their homepage:

= %< 
$ eix -# -H codehaus
dev-java/annogen
dev-java/bytelist
dev-java/groovy
dev-java/jaxen
dev-java/jcodings
dev-java/jettison
dev-java/joni
dev-java/jruby
dev-java/plexus-classworlds
dev-java/qdox
dev-java/spice-jndikit
dev-java/stax
dev-java/wstx
dev-java/xstream
= %< 

Some new homes I know of:

- dev-java/bytelist: https://github.com/jruby/bytelist
- dev-java/groovy: http://groovy.apache.org
- dev-java/jaxen: https://github.com/jaxen-xpath/jaxen
- dev-java/jcodings: https://github.com/jruby/jcodings
- dev-java/jettison: https://github.com/jettison-json/jettison
- dev-java/jodi: https://github.com/jruby/jodi
- dev-java/jruby: http://jruby.org/
- dev-java/plexus-classworlds: http://sonatype.github.io/plexus-classworlds/
- dev-java/qdox: https://github.com/paul-hammant/qdox
- dev-java/spice-jndikit: https://github.com/realityforge/jndikit
- dev-java/xstx: http://fasterxml.github.io/woodstox/
- dev-java/xstream: http://x-stream.github.io/

The sources of some inactive projects have been simply moved to GitHub:

- dev-java/annogen: https://github.com/codehaus/annogen
- dev-java/stax: https://github.com/codehaus/stax

However, most packages in the tree are outdated.

BTW: Rubyforge was shut down a year earlier than Codehaus, some of those 
packages can be found now also in the jruby organization at GitHub (like 
bytelist, jodi and jcodings).

Cheers,
Jörg

Re: [gentoo-dev] www-apps/otrs: needs new maintainer

[Stefan G. Weichinger]

Am 2015-09-16 um 02:37 schrieb Rich Freeman:
> On Tue, Sep 15, 2015 at 3:56 PM, Robin H. Johnson  wrote:
>> On Tue, Sep 15, 2015 at 02:13:34PM +0200, hasufell wrote:
>>> On 09/15/2015 02:00 PM, Peter Stuge wrote:
 If you have interest in this package then you can do one or more of:
 * become a Gentoo developer (ha-ha)
>>> hmm
>> For background, SGW did work on becoming a developer once before, but he
>> mainly found he was short on time to handle more than the packages that
>> he had a business interest in.
>>
>> I used to proxy-commit changes from him to the Amanda package, but found
>> myself short on time to test them as well in the long run.
>>
> 
> To be constructive, a github pull-request is probably the most
> effective way to get a proxy maintainer to notice your work right now
> and commit it for you.  Bugs assigned to proxy-maintainers@ might also
> work.  Believe it or not people will actually use ebuilds you attach
> whether or not they get into the tree.  Another option is to publish
> your own overlay, and that makes a good foundation for a pull-request
> anyway and it is easy to use for those who do want to use the overlay
> directly.

Well, my ebuilds for www-apps/otrs are in here already:

https://github.com/stefangweichinger/gentoo-overlay/tree/master/www-apps/otrs

(the other packages in that overlay aren't that up to date ... simply
some work collected over the years)

I only added beta4 yesterday.

> And do consider signing up as a proxied maintainer for a package
> you're interested in.  If you do establish a long-term relationship
> with a package it probably will make devs more willing to commit your
> changes without a lot of testing on their part.

I may do that if something gets moving around this package, yes.
Where would I have to sign up?

I am a proxied maintainer for app-backup/amanda already, as Robin mentioned.

Re: [gentoo-dev] Re: code.google.com readonly starting on 25/Aug/15

[Justin (jlec)]

On 16/09/15 10:56, Jörg Schaible wrote:
> Hi Tobias,
> 
> Tobias Klausmann wrote:
> 
>> Hi!
>>
>> Tomorrow, code.google.com will turn off write access to all
>> remaining projects[0]. As such, Gentoo ebuilds which still have
>> HOMEPAGE= pointing there should be updated.
> 
> Hmm. Codehaus has also been shut down this year in May, but packages still 
> refer it as their homepage:
> 
> = %< 
> $ eix -# -H codehaus
> dev-java/annogen
> dev-java/bytelist
> dev-java/groovy
> dev-java/jaxen
> dev-java/jcodings
> dev-java/jettison
> dev-java/joni
> dev-java/jruby
> dev-java/plexus-classworlds
> dev-java/qdox
> dev-java/spice-jndikit
> dev-java/stax
> dev-java/wstx
> dev-java/xstream
> = %< 
> 
> Some new homes I know of:
> 
> - dev-java/bytelist: https://github.com/jruby/bytelist
> - dev-java/groovy: http://groovy.apache.org
> - dev-java/jaxen: https://github.com/jaxen-xpath/jaxen
> - dev-java/jcodings: https://github.com/jruby/jcodings
> - dev-java/jettison: https://github.com/jettison-json/jettison
> - dev-java/jodi: https://github.com/jruby/jodi
> - dev-java/jruby: http://jruby.org/
> - dev-java/plexus-classworlds: http://sonatype.github.io/plexus-classworlds/
> - dev-java/qdox: https://github.com/paul-hammant/qdox
> - dev-java/spice-jndikit: https://github.com/realityforge/jndikit
> - dev-java/xstx: http://fasterxml.github.io/woodstox/
> - dev-java/xstream: http://x-stream.github.io/
> 
> The sources of some inactive projects have been simply moved to GitHub:
> 
> - dev-java/annogen: https://github.com/codehaus/annogen
> - dev-java/stax: https://github.com/codehaus/stax
> 
> However, most packages in the tree are outdated.
> 
> BTW: Rubyforge was shut down a year earlier than Codehaus, some of those 
> packages can be found now also in the jruby organization at GitHub (like 
> bytelist, jodi and jcodings).
> 
> Cheers,
> Jörg
> 
> 
> 

Hi Jörg,

would you like to send us a PR at GH?

Thanks,
Justin



signature.asc
Description: OpenPGP digital signature

[gentoo-portage-dev] Portage questions

[Joakim Tjernlund]

1)
  Is there a way to generate a snapshot of an installed portage VDB and then 
later
  compare that snapshot against the current VDB and generate a list of
  added/updated packages?

2)
  Currently we generate a tar file with binary pkgs containing all updated pkgs,
  unpack the tar file and emerge the binary pkgs with emerge --usepkgonly ...
  into a new ROOT. This works but that misses any updates to the profile(both 
gentoo and our own).

  To fix that we include a copy of both profiles in the tar file and copy our
  updated profiles into the new ROOT profiles before merging. This feels a bit
  clumsy and I wonder if there is a better way? 

 Jocke

[gentoo-dev] Dynamic dependencies

[Andreas K. Huettel]

Hi all, 

here's a quote from the Council 20140826 summary:

> Dynamic dependencies in Portage
> ===
> During discussion, is was remarked that some changes, e.g. to
> dependencies in eclasses, could require mass rebuilds of packages.
> 
> Vote:
> - "The council asks the Portage team to first outline their long-term
>   plan regarding removal or replacement of dynamic dependencies,
>   before they remove this feature. In particular, tree policies and
>   the handling of eclasses and virtuals need to be clarified."
>   Accepted unanimously.

Since there seems to be interest in the Portage team to go ahead with that 
plan, I'd like to ask about the tree policies and the handling of eclasses and 
virtuals.

I guess we'd appreciate this as a prerequisite for being able to give the plan 
future council support.

Cheers, 
Andreas

-- 
Andreas K. Huettel
Gentoo Linux developer
perl, office, comrel, council

Re: [gentoo-dev] Dynamic dependencies

[Rich Freeman]

On Wed, Sep 16, 2015 at 11:49 AM, Andreas K. Huettel
 wrote:
> Hi all,
>
> here's a quote from the Council 20140826 summary:
>
>> Dynamic dependencies in Portage
>> ===
>> During discussion, is was remarked that some changes, e.g. to
>> dependencies in eclasses, could require mass rebuilds of packages.
>>
>> Vote:
>> - "The council asks the Portage team to first outline their long-term
>>   plan regarding removal or replacement of dynamic dependencies,
>>   before they remove this feature. In particular, tree policies and
>>   the handling of eclasses and virtuals need to be clarified."
>>   Accepted unanimously.
>
> Since there seems to be interest in the Portage team to go ahead with that
> plan, I'd like to ask about the tree policies and the handling of eclasses and
> virtuals.

I'll go ahead and start a tangent on this thread right here.  As a
first step can we separately consider the proposal to require a
revbump anytime a package's RDEPENDS changes?  I'm referring here to
directly-specified RDEPENDS, not those inherited from an eclass or
virtual.

I agree completely that we need to solve the eclass and virtual issue
and that is by far the stickier part of the mess.  However, can we at
least get ebuild authors to stop making changes to their RDEPENDS
without revbumps?  If nothing else that will hopefully provide some
immediate relief to users with dependency breakage, and it doesn't
entail the amount of mass-rebuilding you can potentially get with the
eclass and virtual side of the problem.

And I acknowledge that this is not my original idea...

-- 
Rich

Re: [gentoo-dev] Dynamic dependencies

[hasufell]

On 09/16/2015 05:49 PM, Andreas K. Huettel wrote:
> Hi all, 
> 
> here's a quote from the Council 20140826 summary:
> 
>> Dynamic dependencies in Portage
>> ===
>> During discussion, is was remarked that some changes, e.g. to
>> dependencies in eclasses, could require mass rebuilds of packages.
>>
>> Vote:
>> - "The council asks the Portage team to first outline their long-term
>>   plan regarding removal or replacement of dynamic dependencies,
>>   before they remove this feature. In particular, tree policies and
>>   the handling of eclasses and virtuals need to be clarified."
>>   Accepted unanimously.
> 
> Since there seems to be interest in the Portage team to go ahead with that 
> plan, I'd like to ask about the tree policies and the handling of eclasses 
> and 
> virtuals.
> 
> I guess we'd appreciate this as a prerequisite for being able to give the 
> plan 
> future council support.
> 

I'm against it, because I would...
* not be able to depend on portage specific behavior anymore
* not be able to break the dep-graph for portage users who disable
dynamic dependencies (and even those who don't)
* not be able to break the dep-graph for paludis users
* be forced to actually write ebuilds that comply to PMS
* have to care about correctness of dependencies
* have to do some work, actually
* have to listen to people like PMS and PM authors, but I am smarter

Instead we should...
* start another thread of ~100 mails where PM authors have to repeatedly
explain the problem to every single developer
* let the council dictate over 3-liner devmanual patches that are merely
expressions of the current PMS standard
* piss off everyone who was even remotely thinking of working on this
(there's no one anymore, so maybe this point can be omitted)

Re: [gentoo-dev] Dynamic dependencies

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 16/09/15 03:49 PM, Rich Freeman wrote:
> On Wed, Sep 16, 2015 at 3:31 PM, Michał Górny
>  wrote:
>> 2. Dependency changes that don't need to apply immediately 
>> don't need revbump. For example, if foo.eclass raises minimal 
>> required version of a dependency but all packages built so far 
>> will work with the old one.
>> 
> 
> Are we talking about a build dependency or a run-time
> dependency? I don't get why we'd increase the minimal required
> version of a run-time dependency if everything built so far still
> works with the old version.

I'm also concerned with this one.  Bumping version in an eclass so
that the minver that everything -in the tree- needs is correct seems
to me could suddenly make incorrect everything that's currently
emerged up to that change.

That said this might not matter since deps are almost always pushed
up to latest stable/~arch anyways, so perhaps i'm just generally
being more sensitive on this than is necessary.  Definitely, if the
minver was bumped to fix a bug, then imo the eclass needs bumping to
enforce the vdb update.



-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlX5yR4ACgkQAJxUfCtlWe3BZQD8CPVQ/oEjszqAFtgQzLFKKOSz
3fXRt3ARQE8HHI/jyTwA/jMOnDTTENLs7R/8r2VYYrHIUAv6mrQljuSU2zalJEXY
=S25f
-END PGP SIGNATURE-

Re: [gentoo-dev] Dynamic dependencies

[Daniel Campbell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 09/16/2015 09:21 AM, hasufell wrote:
> On 09/16/2015 05:49 PM, Andreas K. Huettel wrote:
>> Hi all,
>> 
>> here's a quote from the Council 20140826 summary:
>> 
>>> Dynamic dependencies in Portage 
>>> === During discussion, is was
>>> remarked that some changes, e.g. to dependencies in eclasses,
>>> could require mass rebuilds of packages.
>>> 
>>> Vote: - "The council asks the Portage team to first outline
>>> their long-term plan regarding removal or replacement of
>>> dynamic dependencies, before they remove this feature. In
>>> particular, tree policies and the handling of eclasses and
>>> virtuals need to be clarified." Accepted unanimously.
>> 
>> Since there seems to be interest in the Portage team to go ahead
>> with that plan, I'd like to ask about the tree policies and the
>> handling of eclasses and virtuals.
>> 
>> I guess we'd appreciate this as a prerequisite for being able to
>> give the plan future council support.
>> 
> 
> I'm against it, because I would... * not be able to depend on
> portage specific behavior anymore * not be able to break the
> dep-graph for portage users who disable dynamic dependencies (and
> even those who don't) * not be able to break the dep-graph for
> paludis users * be forced to actually write ebuilds that comply to
> PMS * have to care about correctness of dependencies * have to do
> some work, actually * have to listen to people like PMS and PM
> authors, but I am smarter
> 
> Instead we should... * start another thread of ~100 mails where PM
> authors have to repeatedly explain the problem to every single
> developer * let the council dictate over 3-liner devmanual patches
> that are merely expressions of the current PMS standard * piss off
> everyone who was even remotely thinking of working on this (there's
> no one anymore, so maybe this point can be omitted)
> 

As a developer interested in adhering to the PMS, do we have a tool to
check conformance beyond repoman? How would virtuals be handled with
static dependencies?

- -- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJV+bErAAoJEAEkDpRQOeFwaM0QANan7U4hgyJk7GLhHriWerFP
fisJ2yeBeXyzSu9N9XnGAcGKZcanYjvbZs/gLUwbwdGcFXgkxYYcHceh8k+6ZvlH
LPpKy7j+0Af7l0Ooe1wToJ52pyeZZR0N1rKNYPWuY21i9mTHjXYmlX/m7gpAEkPP
WBv/9JiJm9wLJ6rY66fjsBRU/FEyDumI+qv4/FLiIkKmquHDtYCgnryx/ERAXcoW
XpA58zBa0FBQESNaQ1NbDutTJNPZpgtkCTwtMzZ8puO1EGggOrq9yKV6EROztA36
JfzJY4uAQjsaN/AKnULeAeoXBIstFmMvD3b+aeJCTFWLCPz1GVNcVunPjaRwMLCH
MmwzbNMKf+JiBfTxgjWV0NSG3SMosv/e5B72BlvEW+wSTim6O6suSXcLtbkRrAqW
kO/sBo1OqCvolBuvfnngS1/fqSloJjwyimp5utLdDrW212OS3kxaQSDCxeXfJce1
+5mXBSgCEzkBgb0oaZj6BQEcMjFXT9cq+Aa8yUTpPDXpB1el5ogTcWHBt8sQNZjV
V1k0nfIBJqJMydFxsrE7GzaRxqwkptu6mn6A/6rt6mKUJtwWDMKdPKm9cmDa0Vrl
al5moOiDJ1lS07AxPD6q2yjSjn/v3FZC7gh91HM0p+6xK90ttH9oHB3yivfE2DLL
gKkJbCq9/tYV7li8hE7Q
=83M7
-END PGP SIGNATURE-

Re: [gentoo-dev] Dynamic dependencies

[Rich Freeman]

On Wed, Sep 16, 2015 at 3:31 PM, Michał Górny  wrote:
>
> As for virtuals and eclasses, I don't really understand why anyone
> thinks they are special in any regard. In both cases, we're talking
> about regular dependency change in metadata, and we need to understand
> the consequences. And they're going to be the same whether we change
> dep A to B, A to virtual, and whether we change it directly or via
> eclass.

Sure, but a developer KNOWS when their RDEPENDS change when they're
modifying it directly in an ebuild.  If they inherit an eclass and it
sets an RDEPEND and the eclass changes, then it effectively changes
the dependency for every ebuild that inherits it even though there
weren't any commits to any of those ebuilds.

So, we need to think about what kinds of changes we allow to eclasses.
This also applies to virtuals, but those don't have the same kind of
indirect impact to packages that RDEPEND on them any more than changes
in any other RDEPEND of an RDEPEND.

> 2. Dependency changes that don't need to apply immediately don't need
> revbump. For example, if foo.eclass raises minimal required version of
> a dependency but all packages built so far will work with the old one.
>

Are we talking about a build dependency or a run-time dependency?  I
don't get why we'd increase the minimal required version of a run-time
dependency if everything built so far still works with the old
version.

Also, assuming that there is a case where this actually happens, does
this have any impact on running --depclean or any other obscure
blocker issues because the version in VDB is no longer in the tree?

When the policy is just a simple "always revbump when you change
RDEPEND, whether you're an ebuild, an eclass, or a virtual" then I can
see how it is painful, but I can also see how it is fairly
bulletproof.

-- 
Rich

Re: [gentoo-dev] Dynamic dependencies

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 16/09/15 02:13 PM, Daniel Campbell wrote:
> How would virtuals be handled with static dependencies?

AFAIK virtuals would need to be handled the same as anything else --
when updating an atom in RDEPEND, the virtual's ebuild needs to be
revbumped.  This would mean that on --update --deep, the new virtual
would get emerged and so the VDB would be updated again with the
proper list of atom(s) that satisfy it.

Same would have to go for eclasses that include dependencies -- any
time an atom changes, the eclass needs to be revbumped and anything
inheriting it also needs to be revbumped (and its inherit line
adjusted).  Of course we may need some well-defined guidelines (if
we don't have them already) on when and how we can remove the old
eclasses.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlX5vjcACgkQAJxUfCtlWe2UiQD/V+w5t64RkYsqFMqYZevlmVH4
01NkXPI0b9NmM4+chSEBANl2HL+KryM5avwa4EDTYbSA11W4IeTVc+lww9MJXn+V
=RZgQ
-END PGP SIGNATURE-

Re: [gentoo-dev] Dynamic dependencies

[Michał Górny]

Dnia 2015-09-16, o godz. 17:49:24
"Andreas K. Huettel"  napisał(a):

> Hi all, 
> 
> here's a quote from the Council 20140826 summary:
> 
> > Dynamic dependencies in Portage
> > ===
> > During discussion, is was remarked that some changes, e.g. to
> > dependencies in eclasses, could require mass rebuilds of packages.
> > 
> > Vote:
> > - "The council asks the Portage team to first outline their long-term
> >   plan regarding removal or replacement of dynamic dependencies,
> >   before they remove this feature. In particular, tree policies and
> >   the handling of eclasses and virtuals need to be clarified."
> >   Accepted unanimously.
> 
> Since there seems to be interest in the Portage team to go ahead with that 
> plan, I'd like to ask about the tree policies and the handling of eclasses 
> and 
> virtuals.
> 
> I guess we'd appreciate this as a prerequisite for being able to give the 
> plan 
> future council support.

How about the usual 'common sense' policy? Assuming the developer
understands the consequences of bumping and not bumping, and can see
for himself if the latter breaks stuff (which would happen once portage
finally changes the default behavior and makes failures non-random).

As for virtuals and eclasses, I don't really understand why anyone
thinks they are special in any regard. In both cases, we're talking
about regular dependency change in metadata, and we need to understand
the consequences. And they're going to be the same whether we change
dep A to B, A to virtual, and whether we change it directly or via
eclass.

Long story short:

1. Build-time dependency changes don't need revbump unless they
resulted in broken built package. Pretty much like any other build-time
fix.

2. Dependency changes that don't need to apply immediately don't need
revbump. For example, if foo.eclass raises minimal required version of
a dependency but all packages built so far will work with the old one.

3. For non-important fixes, a revbump is recommended. Like when
the package rarely breaks due to missing dep, or the dependency is
implicitly pulled in but should be listed explicitly for completeness.

4. For any change that could result in conflicts or major problems for
people who are stuck with old metadata, revbump is required. This for
example applies to the Perl team virtuals which frequently make
updating impossible.

There are probably more common cases to be considered but that's
the ones that immediately come to my mind.

-- 
Best regards,
Michał Górny



pgpS3cRu6UlKm.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Dynamic dependencies

[Ciaran McCreesh]

On Wed, 16 Sep 2015 21:31:04 +0200
Michał Górny  wrote:
> Assuming the developer understands the consequences of bumping and
> not bumping

Well that narrows it down to about three people, and only if they're
thinking very very carefully.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] Dynamic dependencies

[Rich Freeman]

On Wed, Sep 16, 2015 at 4:17 PM, Michał Górny  wrote:
>
> If you modify an eclass, you're responsible for the outcome. Even if
> means revbumping hundreds of ebuilds for the sake of it. Note that this
> is the kind of revbump that wouldn't require resetting stable keywords
> as long as deps are satisfied.

Ok, so it sounds like there are two eclass proposals out there:
1.  Modify the eclass in place and then revbump all ebuilds that use
it for which the new RDEPEND matters (the second part of this email).
2.  Don't modify the eclass in place, and then update the eclass
reference and revbump any ebuilds for which the new RDEPEND matters,
and for the ones that don't matter there really is no change since
they use the old eclass.

#1 results in less eclass propagation, but requires mass-commits.  #2
seems safer and allows the eclass and ebuilds to be modified
separately, but still requires lots of ebuild changing.

>
> Runtime. The minver can be raised for developer's convenience -- like
> when a large number of packages is expected to require a new version
> soon, and the developers would otherwise have to override the eclass-
> specified versions. Instead, the eclass is updated and new requirements
> apply.

Does not revbumping in this situation actually save us much other than
the need to do the revbumps themselves?

If the dependency uses a slot operator then everything is going to get
rebuilt anyway as soon as the first package comes along and triggers
an update.  Then again, it does save us a bunch of revbumps.

-- 
Rich

Re: [gentoo-dev] Inconsistent and messy layout of team maintainership in Gentoo

[Matthew Thode]

On 09/16/2015 04:25 PM, Michał Górny wrote:
> Hello,
> 
> Right now we kinda have three layers of team package maintainership
> in Gentoo:
> 
> 1. e-mail aliases + bugzilla accounts,
> 
> 2. herds,
> 
> 3. projects.
> 
> Now if we get into the details, it's all very messy.
> 
> 
> E-mail aliases are pretty much handled by obscure, proprietary
> scripts. Formally Gentoo developers can read and modify them, but
> willikins also provides read access to most of the aliases. E-mail
> aliases specify the de-facto list of people receiving bug mail
> and other package inquiries. E-mail aliases are either listed directly
> as  objects, or indirectly provided through herds.
> 
> It should be noted that Bugzilla allows users to 'watch' particular
> e-mail addresses, effectively subscribing users to the bug mail. This
> can extend the list of people receiving bug mail for a package.
> 
> Herds are stored in data/api.git repository, as an .xml file.
> Additionally, read access is provided through api.gentoo.org site.
> Herds specify explicitly the de-facto maintainers of packages maintained
> by herds. In the past they could alternatively refer to project pages
> but that support was dropped along with project wiki migration. Herds
> are also mapped to e-mail aliases (which may list different people).
> Herds are listed as  objects.
> 
> Projects are stored in the proprietary databases of our Wiki instance.
> Projects may specify maintainers of packages where herd is supposed to
> map directly to a project (though herds.xml doesn't provide a correct
> mapping anymore), and also when the particular project's e-mail address
> is listed as maintainer. Projects are usually (though not obligatorily)
> mapped to e-mail aliases. There is no explicit listing for projects in
> metadata.xml.
> 
> 
> To summarize, I see the following issues:
> 
> 1. All three layers are totally disjoint, stored in completely
> different format in completely different places.
> 
> 2. Only herds and aliases can be cleanly mapped via metadata.xml.
> 
> 3. If an alias is given as maintainer, and the alias maps both to
> a herd and a project, it is unclear which of the two it is.
> 
> 4. Herds can no longer refer to projects, so all project members are
> duplicated in herds (= increased maintenance burden).
> 
> 5. Projects can't list members who do not have Wiki accounts or are
> not Gentoo developers.
> 
> So, what are your thoughts for unmessing this?
> 

Herds are groups of developers that can then be mapped to a package.

Aliases are groups of developers and/or others that can be mapped to a
package (and more, but at least that).

Is there a reason not to do a merge into it all being one or the other
(preferably aliases I think, as it's somewhat more explicit with mail).
-- 
Matthew Thode (prometheanfire)



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Inconsistent and messy layout of team maintainership in Gentoo

[Andreas K. Huettel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Mittwoch, 16. September 2015, 23:25:33 schrieb Michał Górny:
> 
> To summarize, I see the following issues:
> 
> 1. All three layers are totally disjoint, stored in completely
> different format in completely different places.
> 
> 2. Only herds and aliases can be cleanly mapped via metadata.xml.
> 
> 3. If an alias is given as maintainer, and the alias maps both to
> a herd and a project, it is unclear which of the two it is.
> 
> 4. Herds can no longer refer to projects, so all project members are
> duplicated in herds (= increased maintenance burden).
> 
> 5. Projects can't list members who do not have Wiki accounts or are
> not Gentoo developers.
> 
> So, what are your thoughts for unmessing this?

a) Disallow the term "herd". Noone uses it correctly anyway.

b) package is "in herd" -> package is "maintained by project"

b') in metadata.xml x  ->  y

b'') simple and stupid mapping project y -> alias y-proj...@gentoo.org
   ( legacy y...@gentoo.org should be forwarded if possible )

c) project membership implies project e-mail alias membership
   If you have a problem with this, read man procmail.

d) per GLEP 39, only developers can be project members. introduce a category
   "contributors" who are also listed on the project page and are also added
   to the project alias.

e) storage of member/contributor lists- if there is a way to extract them from
   the wiki, do it, otherwise let the wiki get them from somewhere else

f) (mopping up) remove herds.xml for good

questions?

- -- 

Andreas K. Huettel
Gentoo Linux developer 
dilfri...@gentoo.org
http://www.akhuettel.de/

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0

iQJ8BAEBCgBmBQJV+eJtXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0RkJDMzI0NjNBOTIwMDY5MTQ2NkMzNDBF
MTM4NkZEN0VGNEI1Nzc5AAoJEOE4b9fvS1d55agQAK2jbpwh91/y3d1O6znAErdC
bFTr1qZ8+14cu1PLpIQh5Aq3u7w6vp2hYnnr9eGTpnlHWm71dWrjPEBYiT8tJwUl
noex1OIvhf9h8LNl9KKx7H8PGEhJBdCGf2JJMgvw/isrNNZWDuPPddWTvVPxy0hm
IqDIdq+fWizFpqW2knb+YTknTsM2eae+uQG4V2r6J5yMFzKzLAObdYes7DPv7FOA
o3pMPKPpGsrqC2wYL/65/RI1ucK+KLXoNNr9wJItTNbyPrRIFuWdG17gwTpTgQ6r
+GagMdUGKZ6zIGASO/H44ZRIS5vUg7WcKq6bIOODWY/G6jArtanHW9f0XVlzZ+Rn
g/WXkw9kxJUAW0DFJ9qs2kRaebdv8nr647RO0VYi6nx9ZDa2mnRmfikOkv195F/7
RA++yZvc85qR0LDk9CQzE1u/JWgjWPOmrzNZznJmVzuqx2HUW4huvyv1Z59YCyBA
0Tqill1LbccfRbxEat8Je5I34PPnZYl2ljIlq6CpsUECvg0XGhylGJatPeDMwUAm
vbTvQW4djh3X8GXXSrj+G+PEUCf7wNEQpKJaYXXm2nJwhEw81K9HTJ8TY+qkzNqJ
2u8CboK4MycOAIAGlXp16/vb/oRSJh4ai6V3aM1ihuTdJsgv2uie1ReCz397u8tv
ImpcfiM2ubvQXNbhVrBE
=pJos
-END PGP SIGNATURE-

Re: [gentoo-dev] Dynamic dependencies

[Rich Freeman]

On Wed, Sep 16, 2015 at 4:44 PM, Ian Stakenvicius  wrote:
>
> - - emerge -uD @world would update the dep anyhow
>
> - - emerge -u @world wouldn't rebuild the package if that package
> didn't change, and if the package did change then the new dep would
> get built.

Just to be clear, my point was that if the reason the eclass was
updated was because some new package version in the tree needed it,
and you update that other package in the tree, then that will update
the dependency, and that would in turn rebuild anything with a slot
operator dep on it.

Which is of course exactly what should happen if the soname/ABI needs to change.

>
> So I think I can safely drop my concern.  Care still needs to be
> given, certainly, as if the in-tree package isn't revbumped and gets
> a patch that only supports the new dep, then suddenly systems will
> fail when said package re-emerges.  But that seems bad practice anyhow
> .

Right, a patch change would always require a revbump and that is
nothing new.  The only case that doesn't require a revbump is a
build-time change.  And if somebody makes a build-time change with the
assumption that the new minimum depencency version is in effect it is
fine, since anybody with it already installed won't be rebuilding it,
and if anybody does rebuild it then portage will check and force the
dependency update so everything is fine at build time.

So, assuming we want to entertain the "only revbump if necessary"
eclass wording, do we think we can actually come up with something
that not only makes technical sense, but where we can actually expect
developers to get it right 99% of the time?  Are we encouraging
dangerous behavior just because a few of us might or might not be able
to get it right?

I suppose if somebody does mess up we can go in and revbump a bunch of
ebuilds.  The thing is that such problems are very hard to detect -
they usually manifest as users posting bizarre portage output on lists
and forums and being showered with a lot of bad advice before somebody
who knows what they're talking about notices the thread, and it can
happen a while after the commit that introduced the problem.

So, part of me really wonders if it is worth it just to save a bunch
of revbumps that probably could be done by a script and with git it
can even happen atomically and with the possibility of review or
testing.

-- 
Rich

[gentoo-dev] Inconsistent and messy layout of team maintainership in Gentoo

[Michał Górny]

Hello,

Right now we kinda have three layers of team package maintainership
in Gentoo:

1. e-mail aliases + bugzilla accounts,

2. herds,

3. projects.

Now if we get into the details, it's all very messy.


E-mail aliases are pretty much handled by obscure, proprietary
scripts. Formally Gentoo developers can read and modify them, but
willikins also provides read access to most of the aliases. E-mail
aliases specify the de-facto list of people receiving bug mail
and other package inquiries. E-mail aliases are either listed directly
as  objects, or indirectly provided through herds.

It should be noted that Bugzilla allows users to 'watch' particular
e-mail addresses, effectively subscribing users to the bug mail. This
can extend the list of people receiving bug mail for a package.

Herds are stored in data/api.git repository, as an .xml file.
Additionally, read access is provided through api.gentoo.org site.
Herds specify explicitly the de-facto maintainers of packages maintained
by herds. In the past they could alternatively refer to project pages
but that support was dropped along with project wiki migration. Herds
are also mapped to e-mail aliases (which may list different people).
Herds are listed as  objects.

Projects are stored in the proprietary databases of our Wiki instance.
Projects may specify maintainers of packages where herd is supposed to
map directly to a project (though herds.xml doesn't provide a correct
mapping anymore), and also when the particular project's e-mail address
is listed as maintainer. Projects are usually (though not obligatorily)
mapped to e-mail aliases. There is no explicit listing for projects in
metadata.xml.


To summarize, I see the following issues:

1. All three layers are totally disjoint, stored in completely
different format in completely different places.

2. Only herds and aliases can be cleanly mapped via metadata.xml.

3. If an alias is given as maintainer, and the alias maps both to
a herd and a project, it is unclear which of the two it is.

4. Herds can no longer refer to projects, so all project members are
duplicated in herds (= increased maintenance burden).

5. Projects can't list members who do not have Wiki accounts or are
not Gentoo developers.

So, what are your thoughts for unmessing this?

-- 
Best regards,
Michał Górny



pgpT1WSHJgbGl.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Inconsistent and messy layout of team maintainership in Gentoo

[Andreas K. Huettel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Mittwoch, 16. September 2015, 23:43:43 schrieb Matthew Thode:

> 
> Herds are groups of developers that can then be mapped to a package.
> 

Heh. See? :)

- -- 

Andreas K. Huettel
Gentoo Linux developer 
dilfri...@gentoo.org
http://www.akhuettel.de/

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0

iQJ8BAEBCgBmBQJV+eRYXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0RkJDMzI0NjNBOTIwMDY5MTQ2NkMzNDBF
MTM4NkZEN0VGNEI1Nzc5AAoJEOE4b9fvS1d5mzoP/A0ruS8oBgcCdXoUc47QsQdf
tDWiy8ayiJmD7/b+ymxE//QCBSc/X5p2jPY+ar57wMg7xse8kl+bIgnhU2AK6Fb2
FLZVMa/Wra3nEfe6h0xbOsKdPMZP+9hJ1d9gyMzWSQ0BIGfwOeWw4hY+gIw1vGcg
9C3blHXrg2l+2D8FXxvZcy0Br7aOHOHA+xuhDph65NucgB3dgULkDhX+5DDKt8u3
+whEQlaF3idxk2nXcrPgkniE4+SHKqIVRTFJWVviy+DCb3UZmSjcqkZr1AFreC9Q
VIeBVGaZFfIpeeGr/LhNSJi7c8KbKov/REill/XqZvaw+a8gZfLbr6scxWKazy1r
d+grZS/OruY2sL7qD8B7HQ4SEHafG5foH3l2lYiauqq4yHbff5V5a8W5Nt4boOXy
kBrrUp0Ls85RSfiOYQMyT4tFaYMOypoJg4YSX2fLroZ46O4pj7sFsD1IRce0TlPP
QQH6XhMHmvL0hoPQSKFDvoGjo8vgWdf68NlaTva2mpD0TqOOdH86V+854DhIs+1K
VSCSpo0+mQ3pDLrSSINZV7iMO+MITHFlr9hAtnVwcpKmTd8GXiMINFXYc+jlyNwp
9cAVowOHiL/aNGbSyK55RYUpdp262wOR2gOZVRDl1Rv4Bv2lKyJRF8wEUhWVFP0i
5YF83Lnfj9ShDlDfegMw
=x1Xd
-END PGP SIGNATURE-

Re: [gentoo-dev] RFI: A better workflow for github pull requests

[Maciej Mrozowski]

On Saturday 12 of September 2015 21:12:25 Michał Górny wrote:

| What are your thoughts? Any other proposals?

Well, there's always an option to set up infra hosted Gerrit or Gitlab and 
forget about Github workflow altogether...

regards
MM

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

Re: [gentoo-dev] [RFC] New Project: MATE

[Joakim Tjernlund]

On Thu, 2015-07-02 at 21:50 +0200, Pacho Ramos wrote:
> El jue, 02-07-2015 a las 15:40 -0400, NP-Hardass escribió:
> > Greetings all,
> > 
> > Looking for some feedback on creating a new project and herd for the
> > MATE Desktop environment.  The goal, like many other DE based 
> > projects,
> > is to provide up to date packaging and as complete an offering of the
> > DE's packages as possible.
> > 
> > Currently, the packages of the MATE Desktop DE are listed as 
> > maintained
> > by TomWij (who is on long term devaway).  Prior to acceptance into 
> > the
> > Gentoo repo, it was worked on by lxnay and steev.  All 3 have either
> > not responded to inquiries, or have expressed limited interest in
> > maintaining the DE.  As a result, I felt the best way to support 
> > users
> > was to move support of MATE away from any individual, and create a
> > project and associated herd to manage the packages, thus allowing any
> > developer that is interested in helping out an easy means of doing 
> > so.
> > 
> > I've created a prospective Wiki project page:
> > https://wiki.gentoo.org/wiki/Project:MATE and intend to have a mail
> > alias, m...@gentoo.org, and an email channel for Gentoo support and
> > development, #gentoo-mate.
> > 
> > Any feedback regarding the aforementioned would be greatly 
> > appreciated.
> > 
> > --
> > NP-Hardass
> 
> 
> I fully agree and I hope that helps with current MATE maintenance that
> is a bit stalled due to Tomwij devaway

Had a look at gentoo-mate repo and it seems it has stalled?

   Jocke

Re: [gentoo-dev] Dynamic dependencies

[Michał Górny]

Dnia 2015-09-16, o godz. 15:49:24
Rich Freeman  napisał(a):

> On Wed, Sep 16, 2015 at 3:31 PM, Michał Górny  wrote:
> >
> > As for virtuals and eclasses, I don't really understand why anyone
> > thinks they are special in any regard. In both cases, we're talking
> > about regular dependency change in metadata, and we need to understand
> > the consequences. And they're going to be the same whether we change
> > dep A to B, A to virtual, and whether we change it directly or via
> > eclass.
> 
> Sure, but a developer KNOWS when their RDEPENDS change when they're
> modifying it directly in an ebuild.  If they inherit an eclass and it
> sets an RDEPEND and the eclass changes, then it effectively changes
> the dependency for every ebuild that inherits it even though there
> weren't any commits to any of those ebuilds.

If you modify an eclass, you're responsible for the outcome. Even if
means revbumping hundreds of ebuilds for the sake of it. Note that this
is the kind of revbump that wouldn't require resetting stable keywords
as long as deps are satisfied.

> > 2. Dependency changes that don't need to apply immediately don't need
> > revbump. For example, if foo.eclass raises minimal required version of
> > a dependency but all packages built so far will work with the old one.
> >
> 
> Are we talking about a build dependency or a run-time dependency?  I
> don't get why we'd increase the minimal required version of a run-time
> dependency if everything built so far still works with the old
> version.

Runtime. The minver can be raised for developer's convenience -- like
when a large number of packages is expected to require a new version
soon, and the developers would otherwise have to override the eclass-
specified versions. Instead, the eclass is updated and new requirements
apply.

> Also, assuming that there is a case where this actually happens, does
> this have any impact on running --depclean or any other obscure
> blocker issues because the version in VDB is no longer in the tree?

It shouldn't have. And if it would, the issues with the whole 'do
stupid stuff and not bump' policy would be much worse.

-- 
Best regards,
Michał Górny



pgpA3qwSJ91iD.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Dynamic dependencies

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 16/09/15 04:30 PM, Rich Freeman wrote:
> On Wed, Sep 16, 2015 at 4:17 PM, Michał Górny 
> wrote:
>> 
>> If you modify an eclass, you're responsible for the outcome.
>> Even if means revbumping hundreds of ebuilds for the sake of
>> it. Note that this is the kind of revbump that wouldn't require
>> resetting stable keywords as long as deps are satisfied.
> 
> Ok, so it sounds like there are two eclass proposals out there: 
> 1.  Modify the eclass in place and then revbump all ebuilds that
> use it for which the new RDEPEND matters (the second part of this
> email). 2.  Don't modify the eclass in place, and then update the
> eclass reference and revbump any ebuilds for which the new
> RDEPEND matters, and for the ones that don't matter there really
> is no change since they use the old eclass.
> 
> #1 results in less eclass propagation, but requires mass-commits.
> #2 seems safer and allows the eclass and ebuilds to be modified 
> separately, but still requires lots of ebuild changing.
> 
>> 
>> Runtime. The minver can be raised for developer's convenience
>> -- like when a large number of packages is expected to require
>> a new version soon, and the developers would otherwise have to
>> override the eclass- specified versions. Instead, the eclass is
>> updated and new requirements apply.
> 
> Does not revbumping in this situation actually save us much other
> than the need to do the revbumps themselves?
> 
> If the dependency uses a slot operator then everything is going
> to get rebuilt anyway as soon as the first package comes along
> and triggers an update.  Then again, it does save us a bunch of
> revbumps.
> 

..if the minver is bumped on the atom in the eclass, and the package
is re-emerged without dyndeps, then the existing installed
dependency is considered fine and kept, whereas with dyndeps it
would be upgraded. Is that the only thing we need to be concerned
about?

- - emerge -uD @world would update the dep anyhow

- - emerge -u @world wouldn't rebuild the package if that package
didn't change, and if the package did change then the new dep would
get built.

- - emerge [package] is as above.

So I think I can safely drop my concern.  Care still needs to be
given, certainly, as if the in-tree package isn't revbumped and gets
a patch that only supports the new dep, then suddenly systems will
fail when said package re-emerges.  But that seems bad practice anyhow
.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlX51L8ACgkQAJxUfCtlWe0HYgEAoH7UscWxE4Lgxw+ghFk4EbYY
xYb5XU02Cg9cqh4kH3UBALJGM5sc9K5mFKEDXkiPJva+U4Txeii0MdD4TJpgEBUM
=buWM
-END PGP SIGNATURE-

Re: [gentoo-dev] Inconsistent and messy layout of team maintainership in Gentoo

[Rich Freeman]

On Wed, Sep 16, 2015 at 5:25 PM, Michał Górny  wrote:
>
> So, what are your thoughts for unmessing this?
>

This sounds familiar.  :)

Honestly, I wouldn't mind combining them all.  Just today I was pinged
by an !expn in IRC and thought to myself, "how many times have I typed
the wrong command to translate a group name into a list of members?"

Is there any way to just have one list of groups, and by all means we
can have a group-type as an attribute if that serves any purpose at
all, and we can either name the group by an email alias, or assign an
alias to a group?  Ideally the same list would be used to populate the
mail aliases.  That seems like it would make life much easier on
anybody writing software that accesses such lists, and perhaps we'd
stop worrying about what exactly a herd or a project or an alias is,
and which ones need to elect leads, and which ones don't, and maybe
just let each do whatever makes the most sense for the job at hand.

-- 
Rich