[gentoo-dev] Re: zlib breakage
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
[gentoo-dev] Re: zlib breakage
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] zlib breakage
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 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] zlib breakage
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 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] zlib breakage
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 > > > > 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 signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: zlib breakage
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.) > > > 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. > 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
[gentoo-dev] GCC 4.6 unmasking
Now that I finally have some time for Gentoo.I'd like to get GCC 4.6 unmasked sometime in the next month. Thanks to everyone but me, we only have a few bugs remaining on the tracker. None of them I consider critical except maybe mplayer (I'd like someone from media-video to look at applying that patch). If you have any bugs open blocking the tracker, please take a look at them soon. If you have a 4.6-related bug that isn't blocking the tracker then please add it, even if it's already fixed (the tracker is used to generate a fixed-in-version list for the eventual stabilization). If you have any issues with 4.6 itself or patches you need applied, now is the time to speak up. Tracker: https://bugs.gentoo.org/show_bug.cgi?id=gcc-4.6 -- fonts, gcc-porting, it makes no sense how it makes no sense toolchain, wxwidgets but i'll take it free anytime @ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
[gentoo-dev] Re: zlib breakage
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] Re: zlib breakage
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
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
On Fri, Sep 23, 2011 at 4:26 PM, Nikos Chantziaras wrote: > On 09/24/2011 02:10 AM, Matt Turner wrote: >> >> On Fri, Sep 23, 2011 at 5: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 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 > > >
Re: [gentoo-dev] Re: zlib breakage
On Sat, Sep 24, 2011 at 4:56 AM, Nikos Chantziaras 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] zlib breakage
On Fri, Sep 23, 2011 at 3:28 PM, Nirbheek Chauhan wrote: > On Sat, Sep 24, 2011 at 3:48 AM, Andreas K. Huettel > 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 > >
[gentoo-dev] Re: zlib breakage
On 09/24/2011 02:10 AM, Matt Turner wrote: On Fri, Sep 23, 2011 at 5: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 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] zlib breakage
On Fri, Sep 23, 2011 at 5: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? 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.
Re: [gentoo-dev] zlib breakage
-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
On Sat, Sep 24, 2011 at 3:48 AM, Andreas K. Huettel 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
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 dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] zlib breakage
> 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.) 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. http://www.gentoo.org/main/en/contract.xml -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] zlib breakage
-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-
[gentoo-dev] zlib breakage
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] euscan proof of concept (like debian's uscan)
On Mon, Sep 19, 2011 at 10:53 AM, Michał Górny wrote:
> On Mon, 19 Sep 2011 10:39:11 +0200
> Corentin Chary wrote:
>
>> ## Also update eix database, because we use eix internaly
>> ## Bottleneck: disk and cpu
>> ##Time: 30mn ~ 1h
>> eix-update
>
> Using egencache to keep caches for overlays will make eix updates much
> faster.
>
> Here's my code for it (it uses overlays in /usr/portage/local):
>
> cd /usr/portage/local && \
> for O in */; do
> echo "${O}"
> egencache --jobs=8 --update --update-use-local-desc --rsync \
> --repo=$(cat ${O}profiles/repo_name)
> done
>
Just done that, and indeed, it's much faster.
Also I switched to PostgreSQL, and since that avoids a lot of deadlock
situations when making queries in parallel, I'm now able to do that:
eix --only-names -x | gparallel --eta --load 8 --jobs 400%
--max-args=64 python manage.py scan-metadata
And now it takes less than 30mn instead of more than 1h, and more
importantly, it scales.
--
Corentin Chary
http://xf.iksaif.net
Re: [gentoo-dev] Packages up for grabs: virtual/{cron,dev-manager,inetd,libc,linux-sources,man,os-headers,package-manager,skkserv,ssh,w3m}
> On Thu, 22 Sep 2011, Tim Harder wrote: >> As these are virtuals, I won't expect that there will be much >> maintenance required. Also, all of them will fall back to (at >> least) one herd. > Personally I don't see why all of these need specific maintainers > beyond the herds they fall under already, especially if they are > very low maintenance. Right, but still I think that a heads-up should be sent in such a case, instead of silently removing oneself from metadata. Ulrich
