[gentoo-dev] zlib breakage

[gentoo-dev] zlib breakage

[Nikos Chantziaras]

I believe something needs to be done with the zlib-1.2.5.1-r1 and -r2 
packages currently in the tree.  The maintainer of zlib pushed those 
revisions with a patch that alters macro identifiers, making Gentoo's 
zlib incompatible with upstream.  As a result, a lot of packages stopped 
building.  Bug reports for broken packages come in and then are being 
modified to fit Gentoo's zlib.

Breaking compatibility with upstream zlib also means that non-portage 
software, the ones I install with "./configure --prefix=$HOME/usr && 
make install", also won't build.

It's a mess right now and it just doesn't look right.  The bug that 
deals with it was locked from public view:

   https://bugs.gentoo.org/show_bug.cgi?id=383179

Is there a plan for this, or will we have to live with what is 
essentially an incompatible Gentoo fork of zlib?

Re: [gentoo-dev] zlib breakage

[Markos Chandras]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 09/23/2011 10:44 PM, Nikos Chantziaras wrote:
> I believe something needs to be done with the zlib-1.2.5.1-r1 and
> -r2 packages currently in the tree.  The maintainer of zlib pushed
> those revisions with a patch that alters macro identifiers, making
> Gentoo's zlib incompatible with upstream.  As a result, a lot of
> packages stopped building.  Bug reports for broken packages come in
> and then are being modified to fit Gentoo's zlib.
> 
> Breaking compatibility with upstream zlib also means that
> non-portage software, the ones I install with "./configure
> --prefix=$HOME/usr && make install", also won't build.
> 
> It's a mess right now and it just doesn't look right.  The bug that 
> deals with it was locked from public view:
> 
> https://bugs.gentoo.org/show_bug.cgi?id=383179
> 
> Is there a plan for this, or will we have to live with what is 
> essentially an incompatible Gentoo fork of zlib?
> 
> 

Why are you discussing this in the -dev ML since there is already an
open bug about this? This is clearly a problem(if any) with the zlib
packages + maintainer. We ( as individual devs ) can't do much. If you
want to push this further, I'd suggest you to CC qa@ on the bug or
contact them directly.

- -- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iQIcBAEBCgAGBQJOfQABAAoJEPqDWhW0r/LCI20P/3uLDPIWQ1UdVFZxBfS+C9xe
Wc9RvmAt9TlNuBltigs/XnQqfZCg9xIF79AobDuKg1PD8YlUvG/bnHdeXazPiMvN
o4IqBi0Rdc+jJ1eCXlxsPiUndpGXbIOzCsANRDHW8xwF6Au8/odhcEADtcZ8BFX2
C/SW4/UOg+w8VAmcRu85JOZlnuGvSbCCKFpCOM4/BMR7k/fWnWXqFsKQfrUvi8vO
Hu4u4wzTRjPnLVVvmUG8CTH+mXGI+BatAMQ3hD359AV/ya6wr5c+xTon6XO9oYhg
smpdx8IbLkJR3YCfBcr6BvNX4T3mTG8FyjL2YSuxdYWjB3Z5kcg3mdvnc74kXemc
tfqmrI1MG1ZtnQXeOQ2+kX+EKvdxEOLEiALZliZ3lZYeXV4uZqJOh9zdE84K5w71
Ptukbkx59cDtXRyAR/UCUs6ZH3edbXFBxQZUk/qRz6SFL3qha2LYgdLNyu91lrzB
UFztH35k6khf+5nY4eFIKQVIqbBREt5dGKMSN1l0tBSCvzehqbF9VthF0EQPrjVr
DaTEtOTLSvCCX46F6uHgN5fxSsTACOqZVBEGlOAS4wE56o16CAE2ZPGlUgvhx+Hw
4L6oPhfCk3kIedOyNCBEczlCRyO6wBTM7SLOwDJc9mQcKZ99A+UbLcT5LLAgH8Vu
58a3jNtXeOFQlFdQflW1
=M4je
-----END PGP SIGNATURE-----

Re: [gentoo-dev] zlib breakage

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 598 bytes --]

On Freitag 23 September 2011 23:54:09 Markos Chandras wrote:
>
> Why are you discussing this in the -dev ML since there is already an
> open bug about this? This is clearly a problem(if any) with the zlib
> packages + maintainer. We ( as individual devs ) can't do much. If you
> want to push this further, I'd suggest you to CC qa@ on the bug or
> contact them directly.

Because he cannot do this; the bug is dev-only now and Mike un-cc'ed him after 
setting the group restriction.

-- 

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


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] zlib breakage

[Nirbheek Chauhan]

On Sat, Sep 24, 2011 at 3:48 AM, Andreas K. Huettel
<dilfridge@gentoo.org> wrote:
> Because he cannot do this; the bug is dev-only now and Mike un-cc'ed him after
> setting the group restriction.
>

That's not a very nice thing to do.

However, Nikos didn't behave nicely either, so I don't quite blame
vapier for his actions.

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

Re: [gentoo-dev] zlib breakage

[Alec Warner]

On Fri, Sep 23, 2011 at 3:28 PM, Nirbheek Chauhan <nirbheek@gentoo.org> wrote:
> On Sat, Sep 24, 2011 at 3:48 AM, Andreas K. Huettel
> <dilfridge@gentoo.org> wrote:
>> Because he cannot do this; the bug is dev-only now and Mike un-cc'ed him after
>> setting the group restriction.
>>
>
> That's not a very nice thing to do.

I un-hide the bug. If you find that people are misbehaving on bugzilla
you should let userrel know and we will take necessary action.

-A

>
> However, Nikos didn't behave nicely either, so I don't quite blame
> vapier for his actions.
>
> --
> ~Nirbheek Chauhan
>
> Gentoo GNOME+Mozilla Team
>
>

Re: [gentoo-dev] zlib breakage

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 686 bytes --]

On Friday, September 23, 2011 19:30:15 Alec Warner wrote:
> On Fri, Sep 23, 2011 at 3:28 PM, Nirbheek Chauhan wrote:
> > On Sat, Sep 24, 2011 at 3:48 AM, Andreas K. Huettel
> > 
> > <dilfridge@gentoo.org> wrote:
> >> Because he cannot do this; the bug is dev-only now and Mike un-cc'ed him
> >> after setting the group restriction.
> > 
> > That's not a very nice thing to do.
> 
> I un-hide the bug. If you find that people are misbehaving on bugzilla
> you should let userrel know and we will take necessary action.

it was meant as a temporary solution and once people went elsewhere, i'd just 
unlock it.  didn't feel like hassling userrel over a minor issue.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] zlib breakage

[Markos Chandras]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 09/23/2011 11:18 PM, Andreas K. Huettel wrote:
> On Freitag 23 September 2011 23:54:09 Markos Chandras wrote:
>> 
>> Why are you discussing this in the -dev ML since there is already
>> an open bug about this? This is clearly a problem(if any) with the
>> zlib packages + maintainer. We ( as individual devs ) can't do
>> much. If you want to push this further, I'd suggest you to CC qa@
>> on the bug or contact them directly.
> 
> Because he cannot do this; the bug is dev-only now and Mike un-cc'ed
> him after setting the group restriction.
> 
Sorry I did not notice that. That is a very strange behaviour indeed

- -- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iQIcBAEBCgAGBQJOfQiRAAoJEPqDWhW0r/LCrYsQAKfKwcNvc4rw0cA/iQQgjRVj
uKcacVzEZIMyVbrByqfavtKS46GB8LM/5IdsaQbMTrCrmaqfSbMulYqPqC01erf0
THynRiauMxl1OaipycWxdPDpBXIj1boSkrkFbGsJCmyChSX8Sabytxbh459QMmZE
vHz1CMImR0lruHcInWcNnlzQxmZkROCcKoCq85fMx1XEJEQ+XXn91ZD+FUthhLQi
EezRAKpFNN6ufwlhoWhpoRc/b6nLUkXVDbP1HKtl6FR4pOBOUZ2SMxPqlr5pS0hl
mTC00MDM5ncSwSYyhxYl4JeRAR2/RpsqXHrpNw+Tb2PVEdWTs5svhBo9sUQaAiyJ
R/PCqfHL+HeWjcN9rU+AHeQxhIX0wRFcLiXS3MrqpUOOzZj56tWGO1nNCpLu2g4G
Rn47djH3ooIDMrMidpB/H+T21sDc+JFZ+GeGEI12GzOI3n52X5/14W8rB9VipMR2
CeP84zmb/ibVZKodL1pWbRHByGDl6OhbnYH2dLCkHGJ1pDqLpIviwK9oGCHfgjx6
gjA4r1WQ/ommhZrMIiOF1d03DcMqLkkorSSOvFwmpVYeJM8gHKsN/DFIbsPmvLr3
dzmuHv6irgnUWPbcdQf5/OdQy7xG4X9aSiBIrwzKyB/dMPbcoUhBZ0+ZNwgPbtjQ
ADW9iwzdGYCXiQ7ADdac
=gNbC
-----END PGP SIGNATURE-----

Re: [gentoo-dev] zlib breakage

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 830 bytes --]

> It's a mess right now and it just doesn't look right.  The bug that
> deals with it was locked from public view:
> 
>    https://bugs.gentoo.org/show_bug.cgi?id=383179

Is there any good reason why this bug is dev-only? Going over the contents I 
dont see any.

(And we've been bickering in far worse ways on public bugs.)

<snip>
We will not hide problems
We will keep our bug report database open for public view at all times; 
reports that users file online will immediately become visible to others.
Exceptions are made when we receive security-related or developer relations 
information with the request not to publicize before a certain deadline. 
</snip>
http://www.gentoo.org/main/en/contract.xml

-- 

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


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: zlib breakage

[Duncan]

Andreas K. Huettel posted on Sat, 24 Sep 2011 00:02:50 +0200 as excerpted:

>> It's a mess right now and it just doesn't look right.  The bug that
>> deals with it was locked from public view:
>> 
>>    https://bugs.gentoo.org/show_bug.cgi?id=383179
> 
> Is there any good reason why this bug is dev-only? Going over the
> contents I dont see any.
> 
> (And we've been bickering in far worse ways on public bugs.)
> 
> <snip>
> We will not hide problems We will keep our bug report database open for
> public view at all times; reports that users file online will
> immediately become visible to others. Exceptions are made when we
> receive security-related or developer relations information with the
> request not to publicize before a certain deadline. </snip>
> http://www.gentoo.org/main/en/contract.xml

FWIW, thanks, to you for the quote and to Alec W. for unhiding the bug.

The bug hiding distressed me and I thought about bringing it here as 
well, as the logical escalation.  I didn't, but I'm glad someone did, and 
that "the right thing"[1] was done in response. =:^)

As for the technical issue, IMO our patching was indeed a bit of the cart 
before the horse, but if upstream zlib ends up taking it, in practice 
it's a tempest in a teapot.  And agree or disagree, if we don't trust the 
dev who did it, as a practical matter as Gentoo users, we've got bigger 
problems. =:^|

That said, between this (being the bug lockout way more than the 
relatively trivial technical issue) and the changelog thing, I'm honestly 
getting a bit worried.  I'll leave it at that as that's the bit that 
SHOULD be non-public, by the contract as well. =:^|

---
[1]  Those who disagree that it was "the right thing" should really 
consider whether that Gentoo social contract needs changed, then.  
Because based on it, hiding that bug was and remains "the wrong thing".  
Of course, the statement that contract makes was one of the things that 
originally brought me, and I imagine others here, to Gentoo in the first 
place, and IMO it'd be a sad day for Gentoo were that to change or even 
to need changed.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] zlib breakage

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 638 bytes --]

On Friday, September 23, 2011 18:02:50 Andreas K. Huettel wrote:
> > It's a mess right now and it just doesn't look right.  The bug that
> > 
> > deals with it was locked from public view:
> >    https://bugs.gentoo.org/show_bug.cgi?id=383179
> 
> Is there any good reason why this bug is dev-only? Going over the contents
> I dont see any.

it was purely to keep people from continuing to whine with circular logic.  if 
bugzilla had a way to temporarily lock comments, i would have used that.

> (And we've been bickering in far worse ways on public bugs.)

that's not justification to enable further misbehavior.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[gentoo-dev] Re: zlib breakage

[Duncan]

Mike Frysinger posted on Sat, 24 Sep 2011 01:10:43 -0400 as excerpted:

> it was purely to keep people from continuing to whine with circular
> logic.
>  if bugzilla had a way to temporarily lock comments, i would have used
> that.

In theory, that'd be a useful feature.  In fact, probably not so much, as 
it simply encourages people to complain much more visibly, very possibly 
in a PR-adverse way.

You could see it was circular logic, but what if he had blogged about it 
and that blog had hit the FLOSS media circuit?  How many FLOSS reporters 
would have seen that it was circular logic based on his blog and a locked 
(comment or visibility) bug?  What about all their readers?

Additionally, that bug was referenced in a number of changelog entries.  
How useful is a link to a locked bug, for those looking for more info, as 
I, for instance did (as I often do with -rX bumps, since information 
that's significant enough to cause a gentoo revision bump in the absence 
of an upstream version bump is often significant enough for me as an 
admin to want to be aware of)?

Unfortunately, locking a bug to kill the whining is likely to have rather 
more negative effects than one might have anticipated.  One would think 
comment locking would be a logical enough extension to have been 
implemented by now; perhaps this is why it hasn't been.  (Full visibility 
locking is of course different, security bugs and all.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: zlib breakage

[Mike Frysinger]

On Sat, Sep 24, 2011 at 02:49, Duncan wrote:
> Mike Frysinger posted on Sat, 24 Sep 2011 01:10:43 -0400 as excerpted:
>> it was purely to keep people from continuing to whine with circular
>> logic.  if bugzilla had a way to temporarily lock comments, i would
>> have used that.
>
> In theory, that'd be a useful feature.  In fact, probably not so much, as
> it simply encourages people to complain much more visibly, very possibly
> in a PR-adverse way.

i couldn't care less.  if people are swayed by random rants rather
than reality, then i'm not going to waste time on them.

> You could see it was circular logic, but what if he had blogged about it
> and that blog had hit the FLOSS media circuit?  How many FLOSS reporters
> would have seen that it was circular logic based on his blog and a locked
> (comment or visibility) bug?  What about all their readers?

clearly you don't know my opinion of blogs in general.

> Additionally, that bug was referenced in a number of changelog entries.
> How useful is a link to a locked bug, for those looking for more info, as
> I, for instance did (as I often do with -rX bumps, since information
> that's significant enough to cause a gentoo revision bump in the absence
> of an upstream version bump is often significant enough for me as an
> admin to want to be aware of)?

then you'd simply wait until it got unlocked.  or ask a dev.

> Unfortunately, locking a bug to kill the whining is likely to have rather
> more negative effects than one might have anticipated.  One would think
> comment locking would be a logical enough extension to have been
> implemented by now; perhaps this is why it hasn't been.  (Full visibility
> locking is of course different, security bugs and all.)

i don't see any negative effects so far.
-mike

Re: [gentoo-dev] Re: zlib breakage

[Rich Freeman]

On Sat, Sep 24, 2011 at 3:10 AM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Sat, Sep 24, 2011 at 02:49, Duncan wrote:
>> Unfortunately, locking a bug to kill the whining is likely to have rather
>> more negative effects than one might have anticipated.  One would think
>> comment locking would be a logical enough extension to have been
>> implemented by now; perhaps this is why it hasn't been.  (Full visibility
>> locking is of course different, security bugs and all.)
>
> i don't see any negative effects so far.

Well, you can probably count the 22 emails preceding this one, and the
22 that are sure to follow...

User-rel is definitely the appropriate way to handle things like this.
 There are legitimate technical disagreements over the best way to
handle this situation, and I can't approve of Nikos's tendency to
personalize things in the bug.  On the other hand, simply telling him
to get lost is likely to just lead to more flames/etc.

This seems like a bit of a tempest in a teapot - we're not talking
about a glibc ABI change hitting the tree without planning.  A few
obscure packages with questionable practices have broken, and are
being fixed.  We can move on.

The fact is that Mike's attitude does not truly reflect the attitudes
of all developers, and Nikos's attitude does not reflect the attitudes
of all users.  So, going into generalities that amount to devs vs
users is just going to rile a lot of people up.  Gentoo is a
community, and devs benefit from a user pool from which new devs
emerge (and other random contributions), and users obviously benefit
from devs typically at no cost to themselves.  Being on the trustee
list I get to see the countless donations (often small, sometimes not)
coming from the community (no doubt from both devs and users) that let
us have things like rsync servers and the mailing list we're posting
on.  It is really in all of our interests to work together.  Devs on
the infra team spend no small number of hours making it all work, but
it is nice when they need new hardware to just be able to ask and get
a check cut, often due to no small number of users.

Communities also have to have rules, and when users are dissatisfied
with how a developer is handling something there are better and worse
ways to handle it.  Obviously working it out is the best way.  If you
need help with that there is always devrel.  Simply posting flames on
a bug is not the right way to handle it.

But, again, this is a bit of a tempest in a teapot, and hopefully
something we can all think about.

Rich

Re: [gentoo-dev] Re: zlib breakage

[Mike Frysinger]

On Sat, Sep 24, 2011 at 14:18, Rich Freeman wrote:
> On Sat, Sep 24, 2011 at 3:10 AM, Mike Frysinger wrote:
>> On Sat, Sep 24, 2011 at 02:49, Duncan wrote:
>>> Unfortunately, locking a bug to kill the whining is likely to have rather
>>> more negative effects than one might have anticipated.  One would think
>>> comment locking would be a logical enough extension to have been
>>> implemented by now; perhaps this is why it hasn't been.  (Full visibility
>>> locking is of course different, security bugs and all.)
>>
>> i don't see any negative effects so far.
>
> Well, you can probably count the 22 emails preceding this one, and the
> 22 that are sure to follow...

i believe the posts were going to be made regardless.  if i hadn't
shut down the bug temporarily, then it'd have been on there instead.
perhaps after enough time of me saying "no", it'd have come over to
the list anyways.  it's a crap shoot either way.

> User-rel is definitely the appropriate way to handle things like this.
>  There are legitimate technical disagreements over the best way to
> handle this situation, and I can't approve of Nikos's tendency to
> personalize things in the bug.  On the other hand, simply telling him
> to get lost is likely to just lead to more flames/etc.

i'd rather not waste more people's time, but using userrel probably
would have satisfied that desire better than temporarily locking the
bug.
-mike

Re: [gentoo-dev] zlib breakage

[Matt Turner]

On Fri, Sep 23, 2011 at 5:44 PM, Nikos Chantziaras <realnc@arcor.de> wrote:
> I believe something needs to be done with the zlib-1.2.5.1-r1 and -r2
> packages currently in the tree.  The maintainer of zlib pushed those
> revisions with a patch that alters macro identifiers, making Gentoo's zlib
> incompatible with upstream.  As a result, a lot of packages stopped
> building.  Bug reports for broken packages come in and then are being
> modified to fit Gentoo's zlib.
>
> Breaking compatibility with upstream zlib also means that non-portage
> software, the ones I install with "./configure --prefix=$HOME/usr && make
> install", also won't build.
>
> It's a mess right now and it just doesn't look right.  The bug that deals
> with it was locked from public view:
>
>  https://bugs.gentoo.org/show_bug.cgi?id=383179
>
> Is there a plan for this, or will we have to live with what is essentially
> an incompatible Gentoo fork of zlib?

It seemed to me like this was a silly problem from the outset. vapier
did arguably the right thing, and if that means exposing some broken
software, fine. We handle plenty of breakage worse than this, but I
understand that it can be inconvenient.

However, you completely lost any support when you said

> Yes, bad idea.  But it's in my liberty to write code however I see fit.

That just makes me want to slap you.

I'll echo what vapier said in response: it's absolutely your
prerogative to do whatever you want, but it's not our responsibility
to make sure that it works in Gentoo.

> It's a bad call. You've made plenty of those lately. This is just another one.
> IMO, you don't have the skills and insight to mess with this stuff. So when you
> try, breakage happens. I hope you retire soon.

Are you kidding me? Grow up.

[gentoo-dev] Re: zlib breakage

[Nikos Chantziaras]

On 09/24/2011 02:10 AM, Matt Turner wrote:
> On Fri, Sep 23, 2011 at 5:44 PM, Nikos Chantziaras<realnc@arcor.de>  wrote:
>> I believe something needs to be done with the zlib-1.2.5.1-r1 and -r2
>> packages currently in the tree.  The maintainer of zlib pushed those
>> revisions with a patch that alters macro identifiers, making Gentoo's zlib
>> incompatible with upstream.  As a result, a lot of packages stopped
>> building.  Bug reports for broken packages come in and then are being
>> modified to fit Gentoo's zlib.
>>
>> Breaking compatibility with upstream zlib also means that non-portage
>> software, the ones I install with "./configure --prefix=$HOME/usr&&  make
>> install", also won't build.
>> [...]
>
> It seemed to me like this was a silly problem from the outset. vapier
> did arguably the right thing, and if that means exposing some broken
> software, fine. We handle plenty of breakage worse than this, but I
> understand that it can be inconvenient.
>
> However, you completely lost any support when you said
>
>> Yes, bad idea.  But it's in my liberty to write code however I see fit.
>
> That just makes me want to slap you.
>
> I'll echo what vapier said in response: it's absolutely your
> prerogative to do whatever you want, but it's not our responsibility
> to make sure that it works in Gentoo.

The code is perfectly valid.  You cannot force people to follow your 
coding standards.  If it's valid C code, it doesn't matter that it 
contradicts your personal preferences.  It's not your code and you don't 
have a saying in it.  What's next, banning software that indents code 
with tabs instead of spaces?


>> It's a bad call. You've made plenty of those lately. This is just another one.
>> IMO, you don't have the skills and insight to mess with this stuff. So when you
>> try, breakage happens. I hope you retire soon.
>
> Are you kidding me? Grow up.

This was just another episode of Vapier's hostile and arrogant behavior 
towards users.  Every time someone comes up with a valid argument of why 
he's wrong, the final answer is "don't care, I do what I please because 
I'm the dev and you're not."  So my reply was the politest I could come 
up with without using the f-word.

Re: [gentoo-dev] Re: zlib breakage

[Nirbheek Chauhan]

On Sat, Sep 24, 2011 at 4:56 AM, Nikos Chantziaras <realnc@arcor.de> wrote:
> This was just another episode of Vapier's hostile and arrogant behavior
> towards users.  Every time someone comes up with a valid argument of why
> he's wrong, the final answer is "don't care, I do what I please because I'm
> the dev and you're not."  So my reply was the politest I could come up with
> without using the f-word.
>

If you felt like using swear words on bugzilla, you shouldn't be
commenting there at all.

Either be polite and know how to escalate, or don't speak at all.
Publicly insulting people will not make them listen to you.

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

Re: [gentoo-dev] Re: zlib breakage

[Alec Warner]

On Fri, Sep 23, 2011 at 4:26 PM, Nikos Chantziaras <realnc@arcor.de> wrote:
> On 09/24/2011 02:10 AM, Matt Turner wrote:
>>
>> On Fri, Sep 23, 2011 at 5:44 PM, Nikos Chantziaras<realnc@arcor.de>
>>  wrote:
>>>
>>> I believe something needs to be done with the zlib-1.2.5.1-r1 and -r2
>>> packages currently in the tree.  The maintainer of zlib pushed those
>>> revisions with a patch that alters macro identifiers, making Gentoo's
>>> zlib
>>> incompatible with upstream.  As a result, a lot of packages stopped
>>> building.  Bug reports for broken packages come in and then are being
>>> modified to fit Gentoo's zlib.
>>>
>>> Breaking compatibility with upstream zlib also means that non-portage
>>> software, the ones I install with "./configure --prefix=$HOME/usr&&  make
>>> install", also won't build.
>>> [...]
>>
>> It seemed to me like this was a silly problem from the outset. vapier
>> did arguably the right thing, and if that means exposing some broken
>> software, fine. We handle plenty of breakage worse than this, but I
>> understand that it can be inconvenient.
>>
>> However, you completely lost any support when you said
>>
>>> Yes, bad idea.  But it's in my liberty to write code however I see fit.
>>
>> That just makes me want to slap you.
>>
>> I'll echo what vapier said in response: it's absolutely your
>> prerogative to do whatever you want, but it's not our responsibility
>> to make sure that it works in Gentoo.
>
> The code is perfectly valid.  You cannot force people to follow your coding
> standards.  If it's valid C code, it doesn't matter that it contradicts your
> personal preferences.  It's not your code and you don't have a saying in it.
>  What's next, banning software that indents code with tabs instead of
> spaces?

You are allowed to disagree with his changes; but that doesn't mean we
must listen to you.
I actually disagree with Vapier as well (I don't see why we would act
without waiting for upstream) but I also trust his technical ability
in matters like this.

>
>
>>> It's a bad call. You've made plenty of those lately. This is just another
>>> one.
>>> IMO, you don't have the skills and insight to mess with this stuff. So
>>> when you
>>> try, breakage happens. I hope you retire soon.
>>
>> Are you kidding me? Grow up.
>
> This was just another episode of Vapier's hostile and arrogant behavior
> towards users.  Every time someone comes up with a valid argument of why
> he's wrong, the final answer is "don't care, I do what I please because I'm
> the dev and you're not."  So my reply was the politest I could come up with
> without using the f-word.

I'm curious what you think the final answer should be?

-A

>
>
>

[gentoo-dev] Re: zlib breakage

[Nikos Chantziaras]

On 09/24/2011 02:40 AM, Alec Warner wrote:
>> This was just another episode of Vapier's hostile and arrogant behavior
>> towards users.  Every time someone comes up with a valid argument of why
>> he's wrong, the final answer is "don't care, I do what I please because I'm
>> the dev and you're not."  So my reply was the politest I could come up with
>> without using the f-word.
>
> I'm curious what you think the final answer should be?

Taking other people's input and concerns into account would be OK. 
Knowing when you're wrong is a useful thing.  Right now, zlib does the 
exact opposite of what should be done; Vapier changed zlib, and tries to 
fix the packages that break because of that change.  The correct way to 
handle it is to let zlib be, and fix the packages that stopped working 
with zlib 1.2.5.1.

Why is that the correct way?  Because we don't know yet what upstream is 
planning.  We don't know if they'll rename those macros.  If they won't, 
then Gentoo is creating problems for itself.  Packages that won't build 
out of the box on Gentoo's zlib will need to be patched.  And you can't 
go to upstream of those packages with that patch, because it's none of 
their business.  They know their code works against vanilla zlib, they 
have no reason to change it.  If Gentoo decides to break a base library 
by making it incompatible with the upstream version, it's their own fault.

If, on the other hand, you send a patch upstream that fixes compilation 
against vanilla zlib 1.2.5.1, they will most probably accept it, because 
it's a fix for a problem that is not distro-specific.  If their software 
won't build against zlib 1.2.5.1, it's *their* problem, not ours.

This is why I think the current "solution" is headed 180 degrees from 
the correct direction.

Re: [gentoo-dev] Re: zlib breakage

[Brian Harring]

On Sat, Sep 24, 2011 at 02:58:02AM +0300, Nikos Chantziaras wrote:
> On 09/24/2011 02:40 AM, Alec Warner wrote:
> >> This was just another episode of Vapier's hostile and arrogant behavior
> >> towards users.  Every time someone comes up with a valid argument of why
> >> he's wrong, the final answer is "don't care, I do what I please because I'm
> >> the dev and you're not."  So my reply was the politest I could come up with
> >> without using the f-word.

The problem with your justification here is the statement "he's 
wrong"; that's opinion (and in this realm the dev frankly 9 times out 
of 10 is more experienced in the pkg in question thus their opinion 
carries greater weight).  Treating your opinion as justification to be 
an ass doesn't really fly, especially considering the stats I mention 
below.

> > I'm curious what you think the final answer should be?
> 
> Taking other people's input and concerns into account would be OK. 
> Knowing when you're wrong is a useful thing.  Right now, zlib does the 
> exact opposite of what should be done; Vapier changed zlib, and tries to 
> fix the packages that break because of that change.  The correct way to 
> handle it is to let zlib be, and fix the packages that stopped working 
> with zlib 1.2.5.1.
> 
> Why is that the correct way?  Because we don't know yet what upstream is 
> planning.  We don't know if they'll rename those macros.  If they won't, 
> then Gentoo is creating problems for itself.  Packages that won't build 
> out of the box on Gentoo's zlib will need to be patched.  And you can't 
> go to upstream of those packages with that patch, because it's none of 
> their business.  They know their code works against vanilla zlib, they 
> have no reason to change it.  If Gentoo decides to break a base library 
> by making it incompatible with the upstream version, it's their own fault.

"Incompatible with upstream version" ?

Quick bug count, 12 packages (most of which are doing bad things in 
their header usage) went boom.

13 out of *608* packages.  I reiterate, 6-!@#*ing-hundred-and-8.  If 
that 13 became 50 I'd be viewing this differently, but half the time 
core pkg upgrades break that /alone/ (meaning upstream induced 
breakage).

The packages are broken; while vapier is mildly ahead of the curve, 
updating upstream is going in parallel.

I strongly suspect you've got the unstated 13th, or hit some fallout 
thus why you're pushing on this as hard as you are.  While that sucks 
for you, you'd have hit the same breakage once upstream releases the 
API change.

All vapier is doing is frankly fixing the offending packages (which 
those patches then go upstream) so the upstream zlib change can be 
made w/out any fallout.

By and large, this is good open source behaviour, and fits with the 
gentoo "don't fuck with upstream's releases" philosophy (which is 
aimed at avoiding the sort of hellacious backporting/monkey-patching 
debian/fedora are known for).

Nothing to see here, pretty much.
~brian

[gentoo-dev] Re: zlib breakage

[Nikos Chantziaras]

On 09/24/2011 03:23 AM, Brian Harring wrote:
>> [...] Right now, zlib does the
>> exact opposite of what should be done; Vapier changed zlib, and tries to
>> fix the packages that break because of that change.  The correct way to
>> handle it is to let zlib be, and fix the packages that stopped working
>> with zlib 1.2.5.1.
>>
>> Why is that the correct way?  Because we don't know yet what upstream is
>> planning.  We don't know if they'll rename those macros.  If they won't,
>> then Gentoo is creating problems for itself.  Packages that won't build
>> out of the box on Gentoo's zlib will need to be patched.  And you can't
>> go to upstream of those packages with that patch, because it's none of
>> their business.  They know their code works against vanilla zlib, they
>> have no reason to change it.  If Gentoo decides to break a base library
>> by making it incompatible with the upstream version, it's their own fault.
>
> "Incompatible with upstream version" ?

Why in quotes?


> Quick bug count, 12 packages (most of which are doing bad things in
> their header usage) went boom.
>
> 13 out of *608* packages.  I reiterate, 6-!@#*ing-hundred-and-8.  If
> that 13 became 50 I'd be viewing this differently, but half the time
> core pkg upgrades break that /alone/ (meaning upstream induced
> breakage).

The packages that break with vanilla zlib 1.2.5.1 (like Lynx, which I 
fixed myself and sent upstream) are less than those that break with r1 
and r2.  So that argument doesn't hold.  Also, you didn't rebuild the 
whole tree, so there's no way of knowing whether there's 13 packages 
that break or 130.


> The packages are broken; while vapier is mildly ahead of the curve,
> updating upstream is going in parallel.

If vapier is such an expert, why did he use _Z_ as the prefix for those 
macros?  It's a well known fact that identifiers beginning with an 
underscore and followed by a capital letter (or another underscore) are 
reserved in C and shouldn't be used.


> I strongly suspect you've got the unstated 13th, or hit some fallout
> thus why you're pushing on this as hard as you are.  While that sucks
> for you, you'd have hit the same breakage once upstream releases the
> API change.

Introducing something to the tree that is known to break packages means 
it's better to mask it.  On top of that, zlib 1.2.5.1 is a beta version, 
which supports masking more strongly when you combine it with the breakage.


> All vapier is doing is frankly fixing the offending packages (which
> those patches then go upstream) so the upstream zlib change can be
> made w/out any fallout.

If upstream accepts the changes, then that's good work.  But not when 
doing that with an unmasked package.  ~arch is for testing.  We tested. 
  Now we know it's borked, so mask it.  When it looks ready, unmask it 
for another round of wide testing.


> By and large, this is good open source behaviour, and fits with the
> gentoo "don't fuck with upstream's releases" philosophy (which is
> aimed at avoiding the sort of hellacious backporting/monkey-patching
> debian/fedora are known for).

But we *did* fuck with upstream's release.

Re: [gentoo-dev] zlib breakage

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1769 bytes --]

On Friday, September 23, 2011 17:44:50 Nikos Chantziaras wrote:
> I believe something needs to be done with the zlib-1.2.5.1-r1 and -r2
> packages currently in the tree.  The maintainer of zlib pushed those
> revisions with a patch that alters macro identifiers, making Gentoo's
> zlib incompatible with upstream.

the defines in question are internal to zlib.  packages relying on them are 
broken, plain and simple.

> As a result, a lot of packages stopped building.

the *only* code that broke was code that was copied out of the zlib tree and 
directly imported into other projects -- minizip.  because the code was 
designed to be compiled & linked as part of the zlib project, it uses internal 
zlib defines.  projects copying the code into their own tree and not cleaning 
things up made a mistake.

for many, this is a direct violation of Gentoo policy and they should be fixed 
to use the minizip code that zlib exports.  for the rest that modify the code 
heavily, they should stop using the internal defines since their own code base 
doesn't support pre-ansi C compilers.

> Bug reports for broken packages come in and then are being
> modified to fit Gentoo's zlib.

and those fixes can be sent to the respective upstreams

> Breaking compatibility with upstream zlib also means that non-portage
> software, the ones I install with "./configure --prefix=$HOME/usr &&
> make install", also won't build.

send the fix to the upstream maintainer

> It's a mess right now and it just doesn't look right.  The bug that
> deals with it was locked from public view:

because you keep presenting the same flawed ideas and ignore the responses.  
in fact, all of the answers i posted above i already posted to the bug.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[gentoo-dev] Re: zlib breakage

[Nikos Chantziaras]

On 09/24/2011 08:24 AM, Mike Frysinger wrote:
> On Friday, September 23, 2011 17:44:50 Nikos Chantziaras wrote:
>> I believe something needs to be done with the zlib-1.2.5.1-r1 and -r2
>> packages currently in the tree.  The maintainer of zlib pushed those
>> revisions with a patch that alters macro identifiers, making Gentoo's
>> zlib incompatible with upstream.
>
> the defines in question are internal to zlib.  packages relying on them are
> broken, plain and simple.

Then fix *them*, not zlib.


>> As a result, a lot of packages stopped building.
>
> the *only* code that broke was code that was copied out of the zlib tree and
> directly imported into other projects -- minizip.  because the code was
> designed to be compiled&  linked as part of the zlib project, it uses internal
> zlib defines.  projects copying the code into their own tree and not cleaning
> things up made a mistake.
>
> for many, this is a direct violation of Gentoo policy and they should be fixed
> to use the minizip code that zlib exports.  for the rest that modify the code
> heavily, they should stop using the internal defines since their own code base
> doesn't support pre-ansi C compilers.

Then why did you "fix" zlib instead of those bad packages?


>> Bug reports for broken packages come in and then are being
>> modified to fit Gentoo's zlib.
>
> and those fixes can be sent to the respective upstreams

See above.


>> Breaking compatibility with upstream zlib also means that non-portage
>> software, the ones I install with "./configure --prefix=$HOME/usr&&
>> make install", also won't build.
>
> send the fix to the upstream maintainer

Maybe 5% of users know how to code.  The rest doesn't.


>> It's a mess right now and it just doesn't look right.  The bug that
>> deals with it was locked from public view:
>
> because you keep presenting the same flawed ideas and ignore the responses.
> in fact, all of the answers i posted above i already posted to the bug.

You ignore the suggestions, which is the reason the same arguments pop 
up over and over again.  The core issue is that ~arch is turning into a 
testing ground for upstreams rather than for Gentoo packaging.  It's not 
nice to keep something in portage unmasked that is *known* to break 
packages, and *especially* if it's a beta release of an important base 
library (which zlib 1.2.5.1 certainly is).  But you ignore that 
repeatedly.  And this makes it very frustrating to communicate.

~arch is not for cleaning up upstream crap.  ~arch is for testing 
packages that will later be marked stable.

Re: [gentoo-dev] Re: zlib breakage

[Mike Frysinger]

On Sat, Sep 24, 2011 at 02:43, Nikos Chantziaras wrote:
> On 09/24/2011 08:24 AM, Mike Frysinger wrote:
>> the defines in question are internal to zlib.  packages relying on them
>> are broken, plain and simple.
>
> Then fix *them*, not zlib.

they are being fixed already

> Then why did you "fix" zlib instead of those bad packages?

i have no idea what you're talking about.  they're both getting fixed.

>>> Breaking compatibility with upstream zlib also means that non-portage
>>> software, the ones I install with "./configure --prefix=$HOME/usr&&
>>> make install", also won't build.
>>
>> send the fix to the upstream maintainer
>
> Maybe 5% of users know how to code.  The rest doesn't.

then file a bug report.  it isn't rocket science.

>>> It's a mess right now and it just doesn't look right.  The bug that
>>> deals with it was locked from public view:
>>
>> because you keep presenting the same flawed ideas and ignore the
>> responses.
>> in fact, all of the answers i posted above i already posted to the bug.
>
> You ignore the suggestions, which is the reason the same arguments pop up
> over and over again.

i read your position, evaluated it, and found it to be inferior.  you
cannot accept that, thus you continue to waste time.

> The core issue is that ~arch is turning into a testing
> ground for upstreams rather than for Gentoo packaging.

if you want to restart the long thread about what ~arch is actually
for, then go for it.  it has come up from time to time and developers
are generally fine with the current model.

> keep something in portage unmasked that is *known* to break packages

~arch is known to have bugs.  if you don't want bugs, don't use ~arch.
 we do not operate on a "if you broke anything at all, it must get
reverted" development style.  you simply need to accept the reality.

further, in order to get p.masked, it has to be a fairly wide
breakage.  in this case, we've got a whopping ~15 bugs.  half of which
are already fixed.

> *especially* if it's a beta release of an important base library (which zlib
> 1.2.5.1 certainly is).

there hasn't been a single bug filed about 1.2.5 vs 1.2.5.1.  stop
making up issues that don't exist.

> But you ignore that repeatedly.

back up your position with actual data and perhaps someone will listen.

until you have something new to say, there isn't anything left for me to cover.
-mike

[gentoo-dev] Re: zlib breakage

[Nikos Chantziaras]

On 09/24/2011 10:07 AM, Mike Frysinger wrote:
> On Sat, Sep 24, 2011 at 02:43, Nikos Chantziaras wrote:
>> On 09/24/2011 08:24 AM, Mike Frysinger wrote:
>>> the defines in question are internal to zlib.  packages relying on them
>>> are broken, plain and simple.
>>
>> Then fix *them*, not zlib.
>
> they are being fixed already
>
>> Then why did you "fix" zlib instead of those bad packages?
>
> i have no idea what you're talking about.  they're both getting fixed.

You are right.  I will stop posting about this.  I'm sorry for the noise 
I caused.