Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

2013-11-14 Thread Ulrich Mueller
> On Fri, 15 Nov 2013, Ben de Groot wrote:

> As I see it now, with respect to multilib, we have three competing
> solutions, but not a clear direction which way we want to go as a
> distro:

> 1: emul-* packages
> 2: multilib-portage
> 3: multilib.eclass

> I would like to vote for option 1, as it is the least intrusive and
> does what we need. If it is really felt we need a more complete
> solution, then my vote would be for 2, since 3 is too intrusive and
> more likely to break or complicate stuff for normal users.

Option 1 is not a solution, but a workaround. It has served us,
but IMHO its replacement is overdue. Just to give an example,
stable emul-linux-x86-xlibs suffers from several security issues
(bug 471098, A1/critical severity) since half a year.

Besides, distributing pre-compiled binary packages seems very
un-Gentoo-ish.

Not sure why you think that option 3 is more intrusive than option 2.
What can be more intrusive than requiring a modified package manager?

Ulrich



Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

2013-11-14 Thread Ben de Groot
On 15 November 2013 01:32, Rich Freeman  wrote:
> On Thu, Nov 14, 2013 at 11:38 AM, Ben de Groot  wrote:
>> I was particularly hit by this as maintainer of freetype, see bugs
>> 455070 and 459352 for some of the mess that could have been avoided.
>
> Looks like 455070 was the source of problems there (the other is just
> a tracker with the aftermath).  The package had no maintainer at the
> time, only a herd (per cvs).  There was a request in the bug for
> whether it was suitable to deploy to production.  Somebody associated
> with the herd gave a thumbs-up, apparently (I can only say that based
> on your comment - I have no idea how that was communicated).  Then
> something went wrong.  Since it caused problems, it was masked.  Those
> who run ~arch should be thanked for saving the stable users from
> potential breakage!
>
> I'm not sure what should have been done differently.  If the package
> maintainer (in this case a herd) says that something is good to go,
> why would anybody assume that it wasn't?  You suggested testing in an
> overlay 20 days earlier, but you weren't in any particularly
> privileged position at the time (you were presumably just another
> maintainer of the herd).

I don't really want to bring up this episode again, but it is a
telling example, which you asked for.

As can be seen from the ChangeLog, I was the primary maintainer. As a
member of the herd I didn't feel it necessary to assert any kind of
"privilege" any other way. I had already said "no, or at least wait"
but that was circumvented by asking another herd member who hadn't
touched the package in years. It would have been nice were I asked for
my okay before making any changes.

And as can be seen, the mess I feared for indeed took place. This
could have been prevented, in my opinion, had this seen more extensive
testing in an overlay.

And this is exactly why I am now more weary for the next package about
to be mangled: cairo (bug 488672).

I am even tempted to undo the multilib changes to freetype, since it
is still causing trouble (just search for freetype bugs and see how
often multilib pops up).

> I'm not pointing fingers here.  This was apparently a
> miscommunication, and part of the cause was a failure to document that
> there was a primary maintainer of the package (something which was
> subsequently corrected).  Michał did offer to just maintain the status
> quo on that package instead of migrating it, and apparently he thought
> he had the all-clear to migrate it anyway.
>
> Michał did add the multilib project as a co-maintainer, taking
> responsibility for dealing with the multilib-related issues long-term.
>  In my mind this is the sort of things projects should do.

Indeed, but more communication with the current actual maintainers of
the package in question should also be part of that.

> I'm sure there were other issues, but issues will happen when projects
> make changes.  That's just the way things roll around here.  If Michał
> just committed a change to a package without conferring with the
> maintainer at all or giving significant notice, I'd feel differently.
> I think we just need to learn and move forward, and from the looks of
> things we have.  Gentoo always has been a fairly "disruptive" distro,
> though it has settled down of late.  I don't think we're erring on the
> side of breaking systems too often right now, though I'm always for
> preventing that as long as it doesn't require ossification.
>
> (Just a note - this is all based on what I could piece together from
> cvs and bugzilla.  I'm sure those who were personally involved could
> contribute more detail. I'm not sure it is necessary that do so, but
> I'll gladly defer to those with firsthand knowledge.)
>
>>> In the end, stuff only
>>> gets done if people write code.  Your power in any FOSS project really
>>> comes down to your ability to write code or convince others to write
>>> code on your behalf.
>
>> No, it's more about your ability to commit and get away with it.
>
> So, I'm 100% for what Donnie said and in general I tend to lean
> towards saying "thanks, but no thanks" when a heavy contributor is
> driving everybody nuts.  However, the reality is that those who commit
> more also tend to be allowed to get away with committing more.  That's
> just human nature - we all like our free toys and we're reluctant to
> take too much objection when we're slapped around a little by the guy
> who is giving us the free toys.  There needs to be a balance, and from
> the sound of things Markos is looking to step in and adjust the
> balance if it gets out of line.  Honestly, I just wish everybody would
> do what they can to make his job easier, and I say that without
> pointing my fingers in any direction.  I think we have a really great
> thing going here...
>
> Rich
>

Markos has shown initiative and good ideas, so I'm looking forward to
positive changes.

I am also cautiously optimistic about a renewed QA team, which could
be involved more

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

2013-11-14 Thread Kent Fredric
On 15 November 2013 17:56, Matt Turner  wrote:
> After using it for a month, he's now convinced that
> Gentoo is clearly the most difficult to use.
>
> I'm inclined to agree,


I'd have to disagree there slightly, arch is more easy to use if you
stick to the core set, the binary packages ... as is debian.

But if you verge outside that set, arch quickly becomes a headache,
AUR may have lots of contribution, but its nowhere near the quality we
have of even some of our worse quality overlays, and the arch
toolchain lacks lots of features ebuild authors have come to rely on.

This means if you use arch's equivalent of our overlays, you'll spend
much time fixing up  broken syntax in AUR packages.

I mean, sure, its "simpler", but at the same time, it does so by
simply cauterizing out the extra complexity, making it impossible for
end users to even opt for the complex or different behaviours, by
choosing one for them, and not informing them at all of that choice.

So that argument mostly boils down to "useflags add complexity for
people who aren't used to them, or aren't interested in them".

-- 
Kent



Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

2013-11-14 Thread Matt Turner
On Wed, Nov 13, 2013 at 2:28 AM, Martin Vaeth
 wrote:
> The new "features" use.stable.mask and package.use.stable.mask
> have turned maintaining systems with mixed ARCH and ~ARCH keywords
> into a nightmare:

I agree. I have helped two friends convert to Gentoo recently (one
used it a few years ago). They both came from Arch, and one told me
that before he resumed using Gentoo recently he considered these two
distros in the same category in terms of difficulty of use and
maintenance. After using it for a month, he's now convinced that
Gentoo is clearly the most difficult to use.

I'm inclined to agree, and I think in large part recently it's because
of use.stable.mask and package.use.stable.mask. These really are a
nightmare for users. Heck, they're really a nightmare for me and I've
been using Gentoo for nine years and feel like I have a pretty good
ability to decipher portage's error messages.

I think most of the confusion is caused by the necessity to put a
*stable* package atom into package.keywords to unmask a *USE* flag.
(Am I doing something wrong that would prevent 'x11-proto/kbproto
-abi_x86_32' in /etc/portage/package.use.stable.mask from
un-stable-masking the abi_x86_32 USE flag for kbproto?)

And then in addition, we did really weird things like stabilizing
package versions whose only difference from the previous is that it
supports multilib (e.g., kbproto-1.0.6 vs kbproto-1.0.6-r1). Except
that it's package.use.stable.mask'd. So you have to keyword a stable
package to get its only defining feature. (Why did we stabilize it in
the first place?)

Portage correctly shows that unstable USE flags are masked by printing
parenthesis around them, like use.mask'd flags, but the error messages
are really unhelpful. Take for instance dropping the stable
=x11-proto/kbproto-1.0.6-r1 from package.keywords, in order implicitly
mask the abi_x86_32. Attempting to merge =x11-proto/kbproto-1.0.6-r1
results in:

x11-proto/kbproto:0

  (x11-proto/kbproto-1.0.6-r1::gentoo, ebuild scheduled for merge) pulled in by
(no parents that aren't satisfied by other packages in this slot)

  (x11-proto/kbproto-1.0.6-r1::gentoo, installed) pulled in by

x11-proto/kbproto[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?]
required by (x11-libs/libX11-1.6.2::gentoo, installed)

x11-proto/kbproto[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?]
required by (x11-libs/libXt-1.1.4::gentoo, installed)

There's a single problem. It can't enable abi_x86_32. Why didn't it
just say that?

You could even go beyond this and explain why it can't do it, but at
this point I'd settle for a concise explanation of *what* it can't do.



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

2013-11-14 Thread Rich Freeman
On Thu, Nov 14, 2013 at 4:22 PM, Pacho Ramos  wrote:
>
> We are pleased to announce the stabilization of GNOME-3.8. Users are
> strongly encouraged to read the GNOME 3.8 Upgrade Guide to avoid any
> possible issues relating to the upgrade. The guide will also show you
> how to migrate to systemd as it is the only supported setup now,
> suggesting you how to avoid blockers and problems trying to let you
> have a smoother update.

I like it - highlights the key elements that users should be aware of,
and directs them to more details.

Rich



Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

2013-11-14 Thread Patrick Lauer
On 11/15/2013 03:35 AM, Ciaran McCreesh wrote:
> On Thu, 14 Nov 2013 20:07:39 +0100
> Thomas Sachau  wrote:
>> - multilib-portage was planned to add features with a future EAPI
>> version, so in the end needs agreement from maintainers of package
>> managers, the pms team and the council. If anyone from those groups
>> only claims "you wrote so much, but i dont understand it, write
>> more", then it can be a very long time to get it into the main tree
>> (also this usually means it is well reviewed and tested)
> 
> That's only a problem if you've got a horribly complicated feature
> where you can't remember yourself what you changed to make it work or
> how or why you implemented it.
> 
... or if people shift the goalpost so much that you don't even remember
what game is being played



Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

2013-11-14 Thread Patrick Lauer
On 11/15/2013 01:51 AM, Michał Górny wrote:

>>> So tell me, what you exactly want or need? Or is it just bare
>>> complaining for the sake of complaining?
>>
>> Well, you accidentally cut out all references to TommyD's work again.
>> Almost as if you don't even want to discuss a working proper solution
>> that just doesn't have the ego hammering it in ...
> 
> 'Proper' is the keyword. The solution you mention has many issues that
> I listed more than once, and is far from unobtrusive, clear
> or explicit. It's supposedly working, yes, but it is nowhere near
> production-ready.

But at least the maintainer followed the protocol and did ask for
feedback, did not just hammer it into the main tree etc.

(Said maintainer was told to properly document AND DICSUSS it, or else
... one wonders why there's so much divergence between these two attempts)





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

2013-11-14 Thread Pacho Ramos
New try:

Title: Upgrade to GNOME 3.8
Author: Pacho Ramos 
Content-Type: text/plain
Posted: 2013-11-14
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: http://wiki.gentoo.org/wiki/GNOME/3.8-upgrade-guide








Re: [gentoo-dev] keep a gen 2013 snapshot on mirrors

2013-11-14 Thread Ian Stakenvicius
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 14/11/13 08:19 AM, Lars Wendler wrote:

>  Once you go the route to use mirror://gentoo in ebuilds as
> SRC_URI people are screwed as soon as the ebuild vanishes from
> portage. I'd love to see this (mis-)behavior being more vigorously
> discouraged in Gentoo-land...

Me too; at least until such time as infra starts running out of space,
and i'm sure they can let us know when that's about to happen




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

iF4EAREIAAYFAlKFKVkACgkQ2ugaI38ACPD7GgD+O0Of0R0BeOmGmKNKHwaLt/Oh
63xVewB5tQKdTeqn7dIBAKZgrPu2ScMfPSyOgSQNXpveUGWntsin3HqOifGLCTvQ
=o4tM
-END PGP SIGNATURE-



Re: [gentoo-dev] Re: Package removal without proper last-riting

2013-11-14 Thread Diego Elio Pettenò
On Thu, Nov 14, 2013 at 3:08 AM, Ryan Hill  wrote:

> I wasn't aware last-riting had become general policy.  It was originally
> started by the treecleaner team to give people time to object to
> maintainer-needed removals, and others thought it was a good idea, but it
> was
> always up to the discretion of the maintainer back then.
>

Last riting predates treecleaners by quite a bit.


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


Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

2013-11-14 Thread Ciaran McCreesh
On Thu, 14 Nov 2013 20:07:39 +0100
Thomas Sachau  wrote:
> - multilib-portage was planned to add features with a future EAPI
> version, so in the end needs agreement from maintainers of package
> managers, the pms team and the council. If anyone from those groups
> only claims "you wrote so much, but i dont understand it, write
> more", then it can be a very long time to get it into the main tree
> (also this usually means it is well reviewed and tested)

That's only a problem if you've got a horribly complicated feature
where you can't remember yourself what you changed to make it work or
how or why you implemented it.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

2013-11-14 Thread Thomas Sachau
Rich Freeman schrieb:
> On Thu, Nov 14, 2013 at 7:03 AM, Patrick Lauer  wrote:
>>
>> So just "fix it as problems appear and/or we have some spare time" ...
> 
> Have any problems appeared that impact anybody who hasn't tried to
> take advantage of the new multilib features (ie modified their config
> files/etc)?
> 
>>
>> Well, you accidentally cut out all references to TommyD's work again.
>> Almost as if you don't even want to discuss a working proper solution
>> that just doesn't have the ego hammering it in ...
> 
> We get it - there are two competing approaches to multilib...  That's
> perfectly fine - we can sort out which one works better once they both
> work.  It would be more of a concern if maintainers were being asked
> to maintain things twice, but as far as I'm aware the developers of
> each of the competing approaches have been doing most of the work
> themselves.
> 
> Of course, there could be issues I simply haven't heard of.

There is a pretty big issue/difference here:

- multilib-portage was planned to add features with a future EAPI
version, so in the end needs agreement from maintainers of package
managers, the pms team and the council. If anyone from those groups only
claims "you wrote so much, but i dont understand it, write more", then
it can be a very long time to get it into the main tree (also this
usually means it is well reviewed and tested)

- the new multilib eclasses dont need any ok from anyone, so they have
been added instantly after first creation of a draft. So after addition
(also they only support a subset of the things supported by
multilib-portage) ebuilds are now converted to use them for multilib
support. Noone will opt to revert/convert those changes once
multilib-portage would be ready, so the eclasses win simply by the lower
entrance barrier


In the end multilib-portage will likely end as a portage-only feature
allowing multilib-support on packages without the need to change ebuilds
(it also has support for wrapping binaries per ABI, but this will
hopefully at some point also go into the eclasses).

-- 

Thomas Sachau
Gentoo Linux Developer



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

2013-11-14 Thread Michał Górny
Dnia 2013-11-14, o godz. 20:03:36
Patrick Lauer  napisał(a):

> On 11/14/2013 01:13 PM, Michał Górny wrote:
> > https://wiki.gentoo.org/wiki/Multilib_porting_status
> > 
> > That's the closest thing to a roadmap.
> 
> So just "fix it as problems appear and/or we have some spare time" ...

You could tell that. Or you could notice that this was specifically
designed as an unobtrusive solution with possibility of gradual
migration and backwards compatibility.

> > So tell me, what you exactly want or need? Or is it just bare
> > complaining for the sake of complaining?
> 
> Well, you accidentally cut out all references to TommyD's work again.
> Almost as if you don't even want to discuss a working proper solution
> that just doesn't have the ego hammering it in ...

'Proper' is the keyword. The solution you mention has many issues that
I listed more than once, and is far from unobtrusive, clear
or explicit. It's supposedly working, yes, but it is nowhere near
production-ready.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature


Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

2013-11-14 Thread Rich Freeman
On Thu, Nov 14, 2013 at 11:38 AM, Ben de Groot  wrote:
> I was particularly hit by this as maintainer of freetype, see bugs
> 455070 and 459352 for some of the mess that could have been avoided.

Looks like 455070 was the source of problems there (the other is just
a tracker with the aftermath).  The package had no maintainer at the
time, only a herd (per cvs).  There was a request in the bug for
whether it was suitable to deploy to production.  Somebody associated
with the herd gave a thumbs-up, apparently (I can only say that based
on your comment - I have no idea how that was communicated).  Then
something went wrong.  Since it caused problems, it was masked.  Those
who run ~arch should be thanked for saving the stable users from
potential breakage!

I'm not sure what should have been done differently.  If the package
maintainer (in this case a herd) says that something is good to go,
why would anybody assume that it wasn't?  You suggested testing in an
overlay 20 days earlier, but you weren't in any particularly
privileged position at the time (you were presumably just another
maintainer of the herd).

I'm not pointing fingers here.  This was apparently a
miscommunication, and part of the cause was a failure to document that
there was a primary maintainer of the package (something which was
subsequently corrected).  Michał did offer to just maintain the status
quo on that package instead of migrating it, and apparently he thought
he had the all-clear to migrate it anyway.

Michał did add the multilib project as a co-maintainer, taking
responsibility for dealing with the multilib-related issues long-term.
 In my mind this is the sort of things projects should do.

I'm sure there were other issues, but issues will happen when projects
make changes.  That's just the way things roll around here.  If Michał
just committed a change to a package without conferring with the
maintainer at all or giving significant notice, I'd feel differently.
I think we just need to learn and move forward, and from the looks of
things we have.  Gentoo always has been a fairly "disruptive" distro,
though it has settled down of late.  I don't think we're erring on the
side of breaking systems too often right now, though I'm always for
preventing that as long as it doesn't require ossification.

(Just a note - this is all based on what I could piece together from
cvs and bugzilla.  I'm sure those who were personally involved could
contribute more detail. I'm not sure it is necessary that do so, but
I'll gladly defer to those with firsthand knowledge.)

>> In the end, stuff only
>> gets done if people write code.  Your power in any FOSS project really
>> comes down to your ability to write code or convince others to write
>> code on your behalf.

> No, it's more about your ability to commit and get away with it.

So, I'm 100% for what Donnie said and in general I tend to lean
towards saying "thanks, but no thanks" when a heavy contributor is
driving everybody nuts.  However, the reality is that those who commit
more also tend to be allowed to get away with committing more.  That's
just human nature - we all like our free toys and we're reluctant to
take too much objection when we're slapped around a little by the guy
who is giving us the free toys.  There needs to be a balance, and from
the sound of things Markos is looking to step in and adjust the
balance if it gets out of line.  Honestly, I just wish everybody would
do what they can to make his job easier, and I say that without
pointing my fingers in any direction.  I think we have a really great
thing going here...

Rich



Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

2013-11-14 Thread Ben de Groot
On 14 November 2013 23:12, Rich Freeman  wrote:
> On Thu, Nov 14, 2013 at 7:57 AM, Ben de Groot  wrote:
>>>  I said
>> As it is always happy to point out, Council doesn't see itself as
>> leadership, just as a supreme court of appeal, when everything else
>> seems to have failed. It likes to get involved as little as possible.
>
> The last time I talked to Council she said that she doesn't like it
> when you anthropomorphize her.
>
> Certainly I stated in my manifesto that I believe that Council members
> SHOULD be leaders, and should not limit their leadership of the distro
> to casting votes.  That's why we're chatting on a list, and I'm not
> sitting back waiting for you to put this issue on a Council agenda.

That is nice of you, but many of your fellow councilmen (historically,
as well as currently) do not hold similar views, as was made painfully
clear to me a few years ago.

>>> We
>>> also have Comrel, which is a better starting point for cases
>>> concerning individuals vs policies.
>>
>> This also displays little real leadership. It concerns itself with
>> conflict resolution, with various degrees of success. (I still have a
>> bad taste in my mouth from my past dealings with that institution.)
>
> Well, that is the role of Comrel.  I don't expect it to decide whether
> developers can touch each other's ebuilds to add systemd units to
> them, etc.  However, if the Council establishes a policy then Comrel
> should certainly take issue with devs that ignore that policy.  Comrel
> certainly can show leadership when it comes to how it operates,
> facilitating better relations in the community in general, etc.
>
>>
>> The costs are higher than the benefits, in my opinion. Where are the
>> use cases for this high-cost solution that is being pushed upon us?
>
> Where are the costs for this high-cost solution that you purport the
> existence of?  Just what about this solution is difficult to maintain?
>  I keep hearing that it is painful, but I haven't seen specific
> examples of HOW it is painful.

See how much effort is expended on this, and how many maintainers are
being involved:
https://bugs.gentoo.org/buglist.cgi?quicksearch=ALL+multilib

I was particularly hit by this as maintainer of freetype, see bugs
455070 and 459352 for some of the mess that could have been avoided.

>>> The problem with having top-down leadership in a volunteer-based
>>> organization is that it tends to drive away anybody who doesn't agree
>>> with the leader.  If a supreme leader said "mgorny has the right
>>> solution to multilib - everybody is going to work to implement it"
>>> that would probably cause more harm than good.  Everybody wants a
>>> supreme leader until the leader backs something they oppose.
>>
>> But what's the alternative? Having a few dozen self-appointed leaders
>> doing whatever they want, and often taking things in opposing
>> directions. It's not top-down leadership, but rule of the strongest.
>
> When you have officially-appointed leaders they usually tend to be the
> same people who would otherwise be the self-appointed leaders.  They
> just have more power to kick everybody out who disagrees with them.
> It is still the rule of the strongest.  How did Linus become the
> leader of Linux?  He wrote it...

At least there is one person in charge who sets a clear direction, and
is accountable.

> I used to get philosophical about things like this, but I think the
> model Gentoo has is actually not a bad one.

I guess we'll have to agree to disagree on this one then.

> In the end, stuff only
> gets done if people write code.  Your power in any FOSS project really
> comes down to your ability to write code or convince others to write
> code on your behalf.

No, it's more about your ability to commit and get away with it.

> We can argue about what piece of software is
> conceptually the best, but implemented software will almost always win
> over the unimplemented competitor, unless the merits of the competitor
> are such that people will flock behind it and actually implement it.
>
> Rich
>

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

2013-11-14 Thread Rich Freeman
On Thu, Nov 14, 2013 at 7:57 AM, Ben de Groot  wrote:
>>  I said
> As it is always happy to point out, Council doesn't see itself as
> leadership, just as a supreme court of appeal, when everything else
> seems to have failed. It likes to get involved as little as possible.

The last time I talked to Council she said that she doesn't like it
when you anthropomorphize her.

Certainly I stated in my manifesto that I believe that Council members
SHOULD be leaders, and should not limit their leadership of the distro
to casting votes.  That's why we're chatting on a list, and I'm not
sitting back waiting for you to put this issue on a Council agenda.

>
>> We
>> also have Comrel, which is a better starting point for cases
>> concerning individuals vs policies.
>
> This also displays little real leadership. It concerns itself with
> conflict resolution, with various degrees of success. (I still have a
> bad taste in my mouth from my past dealings with that institution.)

Well, that is the role of Comrel.  I don't expect it to decide whether
developers can touch each other's ebuilds to add systemd units to
them, etc.  However, if the Council establishes a policy then Comrel
should certainly take issue with devs that ignore that policy.  Comrel
certainly can show leadership when it comes to how it operates,
facilitating better relations in the community in general, etc.

>
> The costs are higher than the benefits, in my opinion. Where are the
> use cases for this high-cost solution that is being pushed upon us?

Where are the costs for this high-cost solution that you purport the
existence of?  Just what about this solution is difficult to maintain?
 I keep hearing that it is painful, but I haven't seen specific
examples of HOW it is painful.

>> The problem with having top-down leadership in a volunteer-based
>> organization is that it tends to drive away anybody who doesn't agree
>> with the leader.  If a supreme leader said "mgorny has the right
>> solution to multilib - everybody is going to work to implement it"
>> that would probably cause more harm than good.  Everybody wants a
>> supreme leader until the leader backs something they oppose.
>
> But what's the alternative? Having a few dozen self-appointed leaders
> doing whatever they want, and often taking things in opposing
> directions. It's not top-down leadership, but rule of the strongest.

When you have officially-appointed leaders they usually tend to be the
same people who would otherwise be the self-appointed leaders.  They
just have more power to kick everybody out who disagrees with them.
It is still the rule of the strongest.  How did Linus become the
leader of Linux?  He wrote it...

I used to get philosophical about things like this, but I think the
model Gentoo has is actually not a bad one.  In the end, stuff only
gets done if people write code.  Your power in any FOSS project really
comes down to your ability to write code or convince others to write
code on your behalf.  We can argue about what piece of software is
conceptually the best, but implemented software will almost always win
over the unimplemented competitor, unless the merits of the competitor
are such that people will flock behind it and actually implement it.

Rich



Re: [gentoo-dev] keep a gen 2013 snapshot on mirrors

2013-11-14 Thread Rich Freeman
On Thu, Nov 14, 2013 at 8:17 AM, Francesco R.  wrote:
> Rich, that made me smile, none of my remote machine has cvs since a
> _very_ long time say 2006.
> We are speaking of box that have troubles to emerging anything new, plus
> me and most of the internet barely remember cvs up  :)

You don't need to run cvs on the box that you're trying to update.
Just run it on a different box and create a tarball of the resulting
tree.

I couldn't tell you what the syntax for doing that is offhand, but I
imagine that it wouldn't take you much longer than it would take me to
read the manpage and figure it out.  If you're really stuck I'm sure
somebody would help you.

>
> I do highly appreciate the suggestion to keep a @system distfiles
> snapshot (once a year + portage snapshot would be a bone), but that it's
> not strictly needed, just a 40MB bzipped files on a public directory and
> maybe some change to the cron that wipe old files.

Personally I'd prefer to see a more standardized way of handling
non-upstream distfiles as well (probably not a tarball).  However,
Gentoo really isn't one of those distros that is ever going to be easy
to upgrade in-place if you only do it once a year or less often.
There are ways to do it, but they're going to be painful.

Rich



Re: [gentoo-dev] keep a gen 2013 snapshot on mirrors

2013-11-14 Thread Lars Wendler
Am Wed, 13 Nov 2013 14:12:24 -0500
schrieb Rich Freeman :

> On Wed, Nov 13, 2013 at 1:58 PM, Francesco R. 
> wrote:
> >
> > long story short
> > having a  portage-20130126.tar.bz2 snapshot (before the EAPI 5
> > switch) greatly simplified the upgrade of an old server on a client.
> >
> > Why not keep a copy on the servers? I mean
> > http://distfiles.gentoo.org/snapshots/
> >
> 
> Going back in time with portage is the easy part - it is in CVS.
> 
> The real problem is all the distfiles themselves, especially things
> like out-of-tree patch tarballs hosted by devs.

IMHO not even the worst problems as long as devs stop removing files
they consider as "deprecated" or "old". I keep everything in my
dev-space I ever put in an ebuild that landed in our official portage
tree. Of course this only works as long as you reference that place in
the affected ebuilds. Once you go the route to use mirror://gentoo in
ebuilds as SRC_URI people are screwed as soon as the ebuild vanishes
from portage.
I'd love to see this (mis-)behavior being more vigorously discouraged
in Gentoo-land...

Cheers
-- 
Lars Wendler
Gentoo package maintainer


signature.asc
Description: PGP signature


Re: [gentoo-dev] keep a gen 2013 snapshot on mirrors

2013-11-14 Thread Francesco R.
Il 13/11/2013 20:12, Rich Freeman ha scritto:
> On Wed, Nov 13, 2013 at 1:58 PM, Francesco R.  wrote:
>> long story short
>> having a  portage-20130126.tar.bz2 snapshot (before the EAPI 5 switch)
>> greatly simplified the upgrade of an old server on a client.
>>
>> Why not keep a copy on the servers? I mean
>> http://distfiles.gentoo.org/snapshots/
>>
> Going back in time with portage is the easy part - it is in CVS.
>
> The real problem is all the distfiles themselves, especially things
> like out-of-tree patch tarballs hosted by devs.
>
> Rich
Rich, that made me smile, none of my remote machine has cvs since a
_very_ long time say 2006.
We are speaking of box that have troubles to emerging anything new, plus
me and most of the internet barely remember cvs up  :)

I do highly appreciate the suggestion to keep a @system distfiles
snapshot (once a year + portage snapshot would be a bone), but that it's
not strictly needed, just a 40MB bzipped files on a public directory and
maybe some change to the cron that wipe old files.

cheers,
Francesco R.




Re: [gentoo-dev] keep a gen 2013 snapshot on mirrors

2013-11-14 Thread Francesco R.
Il 14/11/2013 05:38, Johann Schmitz ha scritto:
> >> long story short having a  portage-20130126.tar.bz2 snapshot
> >> (before the EAPI 5 switch) greatly simplified the upgrade of an
> >> old server on a client.
>
>
>  Updating from old portage versions or
> profiles isn't fun but it basically boils down to
Sorry for the snip, but all you said is valid only if:
you remember to update portage _before_ an emerge --sync
_and_ you are able to do it.

basically what I did was to remove the old snapshot find an old snapshot
but recent enough to have EAPI5 portage.
yes some wget of some distfiles was needed but it made the whole thing
possible.

Alternatively build a completely new system and then switch is a
possibility,
nothing deadly but as said a simple copy of a january snapshot would
have made some paths simpler

cheers,
Francesco Riosa




Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

2013-11-14 Thread Ben de Groot
On 14 November 2013 20:32, Rich Freeman  wrote:
> On Thu, Nov 14, 2013 at 7:21 AM, Ben de Groot  wrote:
>> On 14 November 2013 13:13, Michał Górny  wrote:
>>>
>>> And how is it possible to discuss anything properly in Gentoo?
>>
>> That's because we have no proper leadership. We're an anarchistic
>> collection of people working at cross-purposes at the best of times.
>> There is no direction, and very little accountability.
>
> This seems to be an arrangement that everybody likes except when
> somebody else does something differently than they would prefer...

Seems, maybe. I for one do not like it at all, and I do bring that up
from time to time. Others agree with me to various degrees. The
problem is that it's so damn hard to change anything structurally in
Gentoo.

> We have a Council, and any issue can always be escalated there.

As it is always happy to point out, Council doesn't see itself as
leadership, just as a supreme court of appeal, when everything else
seems to have failed. It likes to get involved as little as possible.

> We
> also have Comrel, which is a better starting point for cases
> concerning individuals vs policies.

This also displays little real leadership. It concerns itself with
conflict resolution, with various degrees of success. (I still have a
bad taste in my mouth from my past dealings with that institution.)

> However, so far I haven't really seen any real indications of what the
> concern is here.  32-bit software on amd64 has always been a kludge,
> and if anything the latest multilib eclass seems to be less of a
> kludge.

I vehemently disagree. The emul-* packages may be a hack, but they
work and cover the use cases we need. The new multilib eclass approach
is much more intrusive in many packages, introduces new levels of
complexity in ebuilds, with resulting new bugs and new behaviour that
confuses users, and adding maintenance costs. It does this for very
little gain. The great majority of our users doesn't need this
functionality.

The costs are higher than the benefits, in my opinion. Where are the
use cases for this high-cost solution that is being pushed upon us?

>  Apparently some argue that there is a better solution being
> worked on, and that's great to hear.  What exactly is the problem?  If
> the eclass were breaking things that weren't already broken and having
> a real impact on ordinary systems I'd consider that a concern.

If you'd care to look at the history of bugs due to multilib eclass
introduction in various packages, that's what you'd find.

> The problem with having top-down leadership in a volunteer-based
> organization is that it tends to drive away anybody who doesn't agree
> with the leader.  If a supreme leader said "mgorny has the right
> solution to multilib - everybody is going to work to implement it"
> that would probably cause more harm than good.  Everybody wants a
> supreme leader until the leader backs something they oppose.

But what's the alternative? Having a few dozen self-appointed leaders
doing whatever they want, and often taking things in opposing
directions. It's not top-down leadership, but rule of the strongest.

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

2013-11-14 Thread Rich Freeman
On Thu, Nov 14, 2013 at 7:30 AM, Patrick Lauer  wrote:
>
> Apart from me masking a few things because portage couldn't figure out a
> way to a consistent state, and all that ...

That is vague.  It may be true, but it does nothing to help anybody
understand what is going on.  I haven't had to mask anything, which
suggests that we're doing things differently.  That isn't to say that
you're doing things wrong, but it is hard to take complaints seriously
when they're vague.

>
> I mean, not that we had lots of users in #gentoo WTFing all over the
> place, or something. Oh wait, we did.

Honestly, I wish that a news item went out before it was implemented.
I'll agree that there was some end-user impact - I suddenly saw
portage outputting requests to set ABI on a few packages due to
dependency issues.  However, when I followed portage's instructions as
with any USE dependency issue everything "just worked."

>
> I have no idea how you think we can sort out anything with a pre-set
> conclusion.

What pre-set conclusion?  Nobody said that you can't work on multilib
in portage.  Nobody said you couldn't put it in the tree either, but I
would avoid namespace collision/etc unless done in a way that is
compatible with the eclass-based solution.  When we get to the point
where we have two options I'd be all for making it possible for users
to pick which one they want to use.

> Apart from the maintainers that now have to figure out the funny bugs of
> the in-tree work ... unlike a certain overlay. But I keep repeating
> myself, which is redundantly redundant.

I'll be the first to admit that I haven't seen these bugs, so I won't
say they aren't severe.  However, at least a few examples of the sorts
of things that could go wrong wouldn't hurt.  Again, this is vague.

> So instead of figuring out bugs the proper way ... we let users hit
> them? I feel tempted to use the letters "A" and "Q" together.
>
> Also, I could again redundantly point at a certain overlay.
>
> Oh well. I guess I should complain less and package.mask more to express
> my feelings...

Complaining isn't the problem.  The issue is that complaints aren't
helpful if they lack any detail or suggestions that are likely to be
acted upon.  Nobody is going to move the new eclass into an overlay,
and it is unlikely that anybody is going to spend a year tweaking
packages in an overlay just to find that they're all obsolete when it
comes time to merge them into the main tree.  Besides, it isn't like
an overlay would get much testing on this scale anyway.

Overlays are great places to work out issues on a small scale with a
few packages if you have multiple developers involved.  They don't
really accomplish much when you scale up, because your overlay is
always going to be out-of-date compared to the main tree.

Honestly, I'm not trying to pick sides here.  I just see complaints
about very new features, and my sense is that if those features aren't
working they should simply not be used.  I don't think I have that
variable set to anything but 64 on my stable amd64 system and I
haven't seen any problems with it recently.  If there are problems I'm
certainly interested in hearing about them.

Rich



Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

2013-11-14 Thread Rich Freeman
On Thu, Nov 14, 2013 at 7:21 AM, Ben de Groot  wrote:
> On 14 November 2013 13:13, Michał Górny  wrote:
>>
>> And how is it possible to discuss anything properly in Gentoo?
>
> That's because we have no proper leadership. We're an anarchistic
> collection of people working at cross-purposes at the best of times.
> There is no direction, and very little accountability.

This seems to be an arrangement that everybody likes except when
somebody else does something differently than they would prefer...

We have a Council, and any issue can always be escalated there.  We
also have Comrel, which is a better starting point for cases
concerning individuals vs policies.

However, so far I haven't really seen any real indications of what the
concern is here.  32-bit software on amd64 has always been a kludge,
and if anything the latest multilib eclass seems to be less of a
kludge.  Apparently some argue that there is a better solution being
worked on, and that's great to hear.  What exactly is the problem?  If
the eclass were breaking things that weren't already broken and having
a real impact on ordinary systems I'd consider that a concern.  If it
is just breaking things that never worked before then I'd just call it
an experimental feature.

The problem with having top-down leadership in a volunteer-based
organization is that it tends to drive away anybody who doesn't agree
with the leader.  If a supreme leader said "mgorny has the right
solution to multilib - everybody is going to work to implement it"
that would probably cause more harm than good.  Everybody wants a
supreme leader until the leader backs something they oppose.

Rich



Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

2013-11-14 Thread Patrick Lauer
On 11/14/2013 08:13 PM, Rich Freeman wrote:
> On Thu, Nov 14, 2013 at 7:03 AM, Patrick Lauer  wrote:
>>
>> So just "fix it as problems appear and/or we have some spare time" ...
> 
> Have any problems appeared that impact anybody who hasn't tried to
> take advantage of the new multilib features (ie modified their config
> files/etc)?

Apart from me masking a few things because portage couldn't figure out a
way to a consistent state, and all that ...

I mean, not that we had lots of users in #gentoo WTFing all over the
place, or something. Oh wait, we did.

>>
>> Well, you accidentally cut out all references to TommyD's work again.
>> Almost as if you don't even want to discuss a working proper solution
>> that just doesn't have the ego hammering it in ...
> 
> We get it - there are two competing approaches to multilib...  That's
> perfectly fine - we can sort out which one works better once they both
> work.  

Given that one has been properly developed in an overlay, and one is now
forcefully hammered into the main tree, it's a fait accompli.

I have no idea how you think we can sort out anything with a pre-set
conclusion.

> It would be more of a concern if maintainers were being asked
> to maintain things twice, but as far as I'm aware the developers of
> each of the competing approaches have been doing most of the work
> themselves.
Apart from the maintainers that now have to figure out the funny bugs of
the in-tree work ... unlike a certain overlay. But I keep repeating
myself, which is redundantly redundant.

> 
> Of course, there could be issues I simply haven't heard of.
> 
>> There's this thing called overlay ;)
>> Once you have everything prepared commit it all masked.
>> A few days later if there's no obvious bug reports unmask it and duck.
> 
> I'm not sure an overlay is a good solution for a tree-wide change that
> will take months to roll out.  It is great for testing the core
> features with a small testing group, but the implementation is always
> going to have to hit the whole tree and all its consumers with little
> formal testing at that scale.

So instead of figuring out bugs the proper way ... we let users hit
them? I feel tempted to use the letters "A" and "Q" together.

Also, I could again redundantly point at a certain overlay.

Oh well. I guess I should complain less and package.mask more to express
my feelings...


Have a nice day,

Patrick



Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

2013-11-14 Thread Ben de Groot
On 14 November 2013 13:13, Michał Górny  wrote:
> Dnia 2013-11-14, o godz. 07:49:55
> Patrick Lauer  napisał(a):
>
>> On 11/13/2013 11:02 PM, Ian Stakenvicius wrote:
>>
>> > It's also worth pointing out that the whole reason why abi_x86_32 is
>> > {package.,}use.stable.masked is because trying to manage the partial
>> > transisition between emul-* and multilib-build dependencies
>>
>> ^^
>>
>> Why is there a partial random transition with no roadmap, no coordination?
>
> https://wiki.gentoo.org/wiki/Multilib_porting_status
>
> That's the closest thing to a roadmap.

Closest thing, yeah. But it doesn't really solve the problem. It's
basically a one-man show, but affecting a large part of the tree,
going ahead like a steam roller that can't be stopped, never mind the
road kill.

>> Well, discussing it properly would also maybe have been a good idea, but
>> since this is now getting unilaterally hammered in it's mostly about
>> damage limitation now ...
>
> And how is it possible to discuss anything properly in Gentoo?

That's because we have no proper leadership. We're an anarchistic
collection of people working at cross-purposes at the best of times.
There is no direction, and very little accountability.

-- 
Cheers,

Ben | yngwin
Gentoo developer



Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

2013-11-14 Thread Rich Freeman
On Thu, Nov 14, 2013 at 7:03 AM, Patrick Lauer  wrote:
>
> So just "fix it as problems appear and/or we have some spare time" ...

Have any problems appeared that impact anybody who hasn't tried to
take advantage of the new multilib features (ie modified their config
files/etc)?

>
> Well, you accidentally cut out all references to TommyD's work again.
> Almost as if you don't even want to discuss a working proper solution
> that just doesn't have the ego hammering it in ...

We get it - there are two competing approaches to multilib...  That's
perfectly fine - we can sort out which one works better once they both
work.  It would be more of a concern if maintainers were being asked
to maintain things twice, but as far as I'm aware the developers of
each of the competing approaches have been doing most of the work
themselves.

Of course, there could be issues I simply haven't heard of.

> There's this thing called overlay ;)
> Once you have everything prepared commit it all masked.
> A few days later if there's no obvious bug reports unmask it and duck.

I'm not sure an overlay is a good solution for a tree-wide change that
will take months to roll out.  It is great for testing the core
features with a small testing group, but the implementation is always
going to have to hit the whole tree and all its consumers with little
formal testing at that scale.

I guess my main question is what exactly is broken?  I haven't heard
of any large-scale problems with the new multilib rollout.  I'm sure
if I went looking for bugs I'd find them, but that's pretty much
par-for-the-course for Gentoo.  If I go install the latest gcc the day
after it gets added to the tree and enable some new flag that was just
introduced I'm going to find lots of packages that break.  That
doesn't mean that the new GCC wasn't ready for the tree - just that I
went looking for trouble, found it, and now I have the opportunity to
help out by filing bugs if what I actually did was reasonable.

Rich



Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

2013-11-14 Thread Patrick Lauer
On 11/14/2013 01:13 PM, Michał Górny wrote:
> Dnia 2013-11-14, o godz. 07:49:55
> Patrick Lauer  napisał(a):
> 
>> On 11/13/2013 11:02 PM, Ian Stakenvicius wrote:
>>
>>> It's also worth pointing out that the whole reason why abi_x86_32 is
>>> {package.,}use.stable.masked is because trying to manage the partial
>>> transisition between emul-* and multilib-build dependencies
>>
>> ^^
>>
>> Why is there a partial random transition with no roadmap, no coordination?
> 
> https://wiki.gentoo.org/wiki/Multilib_porting_status
> 
> That's the closest thing to a roadmap.

So just "fix it as problems appear and/or we have some spare time" ...

> So tell me, what you exactly want or need? Or is it just bare
> complaining for the sake of complaining?

Well, you accidentally cut out all references to TommyD's work again.
Almost as if you don't even want to discuss a working proper solution
that just doesn't have the ego hammering it in ...


>> A more clean way would have been to target each of the emul-x86
>> libraries, replace one completely with multilib-enabled libraries, fix
>> all consumers, *then* unmask that whole shebang at once.
> 
> We tried that. But in the end, it ended up masking new versions
> of a whole lot of libraries waiting for remaining maintainers'
> approval. And the maintainers that opposed the idea now complained that
> it caused the packages to be masked long...
There's this thing called overlay ;)
Once you have everything prepared commit it all masked.
A few days later if there's no obvious bug reports unmask it and duck.

> Feel free to convert all libraries, fix all consumers etc. We couldn't
> achieve that with our manpower.
So you just do it half-donkey'ed. Sigh.

Maybe ... you shouldn't do it if you can't properly finish it?

I mean, not like you cause a trail of destruction like the python-exec
fun, and such things ... maybe ... maybe ... you need to slow down and
plan more, and do your experiments in overlays.

Have fun,

Patrick