Re: [gentoo-dev] Re: zlib breakage
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
Re: [gentoo-dev] Re: zlib breakage
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
[gentoo-dev] My first ebuild: app-cdr/furiusisomount-0.11.3.1
Hello developers! I wrote my first ebuild and I would like to ask for some feedback on it. It's attached to bug https://bugs.gentoo.org/show_bug.cgi?id=261362 Because the application neither has a makefile nor is using distribute since it's python, I have to install all files by hand, or have I? Looking forward to improvements and enhancements! Regards, Moritz
Re: [gentoo-dev] Re: zlib breakage
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... 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
[gentoo-dev] Re: zlib breakage
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.
Re: [gentoo-dev] Re: udev and /usr
On Fri, Sep 16, 2011 at 09:59, Rich Freeman wrote: > I'm a bit concerned that the future of linux on the desktop is going to be > one where your choices are things like Android, ChromeOS, Ubuntu, Gnome OS, > or a "KDE OS." Each one would have its own package managers, repositories, > distros, APIs, etc. Clearly there is some benefit from the vertical > integration (Android and ChromeOS have a very high level of polish, and > Ubuntu is approaching this often by just writing their own stuff). Instead > of working to influence other projects (which can be frustrating), big > distros are looking to just eliminate dependencies outside of themselves. > This will be a big challenge for a smaller distro like Gentoo. Obviously we > can't just go write our own Wayland replacement, even if we did essentially > make our own "systemd" of sorts. you're aware the ChromeOS is built on top of / with Gentoo right ? -mike
Re: [gentoo-dev] Re: zlib breakage
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
