[gentoo-dev] Re: Lastrite: media-gfx/pngcrush
Peter Volkov posted on Tue, 11 Oct 2011 09:38:43 +0400 as excerpted: >> You are correct, but AFAIK, that's one function of tree-cleaners >> (whether or not the remover is actually on the tree-cleaner team), when >> packages are broken due to going stale against current, and the bugs >> reporting the problem remain open for months without (visible) movement >> (there's some movement here, yes, but was it visible?). > > No treecleaners are supposed to be working on maintainer-needed packages > only: > http://www.gentoo.org/proj/en/qa/treecleaners/index.xml Thanks for the clarification. I had QA/Treecleaners lumped together somewhat in this regard and appreciate being straightened out. =:^) -- 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: GCC upgrades, FUD and gentoo documentation
Ryan Hill posted on Mon, 10 Oct 2011 22:13:15 -0600 as excerpted: > I try to overcome that obstacle with the gcc-porting overlay. I try to > stick all the patches that haven't been applied to the main tree in > there. (try being the key word - I really dropped the ball this release > cycle as I was graduating and then got stuck working 80hr weeks for a > few months.) Thanks, BTW. I really haven't tried 4.6 yet either, for similar work- related time constraint reasons, and IIRC that overlay hasn't been around for /too/ many cycles, so I've not really had a chance to use it. But thanks for the effort. It is appreciated, and I now have that overlay on my mental checklist for the next time I /do/ decide to unmask gcc. Having gone thru several cycles without it, I'm already sure it's going to be /quite/ a benefit. =:^) -- 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: Lastrite: media-gfx/pngcrush
В Вск, 09/10/2011 в 22:28 +, Duncan пишет: > Chí-Thanh Christopher Nguyễn posted on Sun, 09 Oct 2011 18:37:59 +0200 as > excerpted: > > > Duncan schrieb: > >> Libpng isn't held up that way, while the package still gets its 30 day > >> masking last-rites. No policy broken; no maintainer toes stepped on as > >> a result of the broken policy. No more nasty threads about (this) > >> broken policy and unhappy maintainers as a result! =:^) > > > > Actually removing a package that doesn't violate any (written) rules > > without maintainer consensus could be considered a violation of policy > > too. > > > > http://www.gentoo.org/proj/en/devrel/recruiters/mentor.xml Respect > > existing maintainers: > > Never commit when someone else has clear ownership. Never commit on > > things with unclear ownership until you've tried to clear it up. Samuli pretends here to act as a part of QA team (although he is not). Actually even whiteboard of stabilization bug tells #at _earliest_ 17 Oct" and thus there is really no sign for rush. This is the case where QA should voice and either explain why fast stabilization of libpng is so important or stop policy breakage. That said it became really common to break our own policies (with no attempts to amend policy). > You are correct, but AFAIK, that's one function of tree-cleaners (whether > or not the remover is actually on the tree-cleaner team), when packages > are broken due to going stale against current, and the bugs reporting the > problem remain open for months without (visible) movement (there's some > movement here, yes, but was it visible?). No treecleaners are supposed to be working on maintainer-needed packages only: http://www.gentoo.org/proj/en/qa/treecleaners/index.xml > So, please, at LEAST honor the 30-day-in-mask bit. This must be honored. -- Peter.
Re: [gentoo-dev] Re: Re: [gentoo-commits] gentoo-x86 commit in net-analyzer/wireshark: wireshark-1.6.2.ebuild ChangeLog wireshark-1.4.9.ebuild wireshark-1.4.7.ebuild wireshark-1.6.0_rc1.ebuild wiresha
В Втр, 13/09/2011 в 11:53 +0200, Diego Elio Pettenò пишет:
> Il giorno mar, 13/09/2011 alle 10.28 +0100, Ciaran McCreesh ha scritto:
> > In that case blocking just old versions is wrong, since if your
> > installed version is broken and you try to reinstall, you'll need to
> > uninstall first too.
wireshark relinks against system wsutil library during 'make DESTDIR=
${D} install', so once wireshark-1.6 is installed we have
libwsutil.so.1.0.0. There is nothing bad linking with correct library
version (even though binary came from previous version).
> It doesn't matter as much when it's the same version because then it
> would have the same soversion and thus it wouldn't cause _visible_
> trouble.
>
> It might be interesting to note that it seems like rc4->final also
> causes the same problem.
Well, I can just drop _rc part in blocker. _rc versions were hardmasked
anyway.
> Just for completeness sake, this can usually be fixed/worked around by
> making sure to list just-built .la files _before_ the /usr libraries. I
> had to work that around on opensc before. PAM also suffers from the same
> issue _if_ the .la files are kept around.
Hm interesting. Actually I've tried to strace libtool and it have not
touched system .la files but since we drop .la anyway I'll recheck.
--
Peter.
Re: [gentoo-dev] Lastrite: media-gfx/pngcrush
On Sun, Oct 9, 2011 at 11:22 AM, Markos Chandras wrote: > I am not in QA fwiw just trying to keep a basic QA level in portage tree. Wait, what? If you're not even in QA, then who are you to start masking other people's packages?
Re: [gentoo-dev] Re: Lastrite: media-gfx/pngcrush
On Mon, Oct 10, 2011 at 8:00 PM, Ryan Hill wrote: > On Sat, 08 Oct 2011 18:33:15 +0300 > Samuli Suominen wrote: > >> It's not like fastened lastriting hasn't happened before. I question >> your motives in picking this particular one. It's not like I expected >> cookies for the time I've put into this porting effort, but not this >> "attack" either. > > Then stop trying to remove packages that have an active maintainer. I could > have sworn that was written down somewhere. I think there was error on both sides here. 1) QA should have some documentation regarding when they will take action. I've gotten Samuli and Diego to note that this would be a good idea; so I hope that gets done in the future. 2) There was miscommunication on the bug. In comment #13 Samuli mentions that 'I'm fine with switching to bundled libpng14 for now, but I'm not going to work on it either.' Hanno then bundles libpng only to be told later in the day that that is wrong. Please try to communicate clearly with each other. 3) Maintainers (and upstreams) are not always responsive. The bug was opened in February and wasn't really worked on until recently. When you are making a treewide change like a lib upgrade you do have a to pick a point where 'enough' people have upgraded and you just break (or mask in this case) everything else. If the folks want the package in the tree they can fix it; thats the whole point of masking (providing a notification and a fix-it interval.) Samuli, this interval is why we mask for 30-60 days also...so try not to shrink the interval without a good reason. -A > > > -- > fonts, gcc-porting, it makes no sense how it makes no sense > toolchain, wxwidgets but i'll take it free anytime > @ gentoo.org EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 >
[gentoo-dev] Re: GCC upgrades, FUD and gentoo documentation
On Tue, 11 Oct 2011 03:27:04 + (UTC) Duncan <1i5t5.dun...@cox.net> wrote: > The problem generally occurs when I decided I've waited long enough for a > long released upstream gcc (4.x.1 and often 4.x.2 are released already!) > to get unmasked even to ~arch. Of course, having been thru this cycle a > few times now, I well understand the reasons why it takes so long for > Gentoo to bump gcc even to ~arch, and accept that I'll often have to dig > thru bugs (often with patches attached for months, with no visible > action, if I were to complain about Gentoo it'd be about the maintainers > of those packages letting those bugs sit, or of packages that should be > put up for someone else to maintain if the maintainers can no longer > handle it, not about the efforts of the toolchain folks) and drop patches > in /etc/portage/patches/* and/or overlay a package if the ebuild itself > needs patched, and that a few packages might not yet have patches > available. That's not the problem. I try to overcome that obstacle with the gcc-porting overlay. I try to stick all the patches that haven't been applied to the main tree in there. (try being the key word - I really dropped the ball this release cycle as I was graduating and then got stuck working 80hr weeks for a few months.) > The problem is often cmake related. Since cmake is C++, once I rebuild > it against the new gcc, it tends to refuse to run if I switch to the old > gcc. Which means I'm SOL for the cmake-based package in question if it > can't yet be built against the new gcc, since the package itself won't > build with new gcc, and cmake won't run to let the package build with the > old gcc. Yeah I've run into situations like this many times. I fear it will only get worse as GCC seems to gather more and more external dependencies every release. If some future mandatory dependency links to libstdc++ it would seem to me that building that package with a newer GCC could make it very difficult to switch back. We already have this situation with the graphite libs (ppl/cloog-ppl), but fortunately it only breaks the graphite options, not the entire compiler. Anyways, we're getting off topic here. -- 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: GCC upgrades, FUD and gentoo documentation
Ryan Hill posted on Mon, 10 Oct 2011 20:21:51 -0600 as excerpted: > There are some packages that all need to be built with the same version > of GCC. The whole qt-* family is an example, or at least it was a year > ago (I'm not using KDE any more). Luckily they tend to be bumped as a > unit. > > The biggest problem is building stuff with a newer version of gcc than > the "system" version, either outside of portage, or selectively changing > back with gcc-config. Programs can get linked to symbols in (usually) > libstdc++.so.6 that have a symbol version that doesn't exist in the > previous release. When you switch back to using that release as your > system compiler, > the libstc++ library also gets switched out, and suddenly your > gcc-4.6-compiled firefox won't launch. If you've ever gotten a bug > report like "libstdc++.so.6: version `GLIBCXX_3.4.15' not found" then > you've dealt with this. > > This isn't a problem most users encounter, but some do like to try to > rebuild some of their system a bit at a time, and this is the reason why > I usually recommend they rebuild everything. By making it an all or > nothing affair, they're less likely to try hopping back and forth > between versions. As with you, this problem appears mostly with kde, here. But at least here, it's *NOT* because I'm TRYING to rebuild a bit of my system at a time, but because parts of it won't yet build with the new gcc. The problem generally occurs when I decided I've waited long enough for a long released upstream gcc (4.x.1 and often 4.x.2 are released already!) to get unmasked even to ~arch. Of course, having been thru this cycle a few times now, I well understand the reasons why it takes so long for Gentoo to bump gcc even to ~arch, and accept that I'll often have to dig thru bugs (often with patches attached for months, with no visible action, if I were to complain about Gentoo it'd be about the maintainers of those packages letting those bugs sit, or of packages that should be put up for someone else to maintain if the maintainers can no longer handle it, not about the efforts of the toolchain folks) and drop patches in /etc/portage/patches/* and/or overlay a package if the ebuild itself needs patched, and that a few packages might not yet have patches available. That's not the problem. The problem is often cmake related. Since cmake is C++, once I rebuild it against the new gcc, it tends to refuse to run if I switch to the old gcc. Which means I'm SOL for the cmake-based package in question if it can't yet be built against the new gcc, since the package itself won't build with new gcc, and cmake won't run to let the package build with the old gcc. Of course, there's often transient issues with various apps if I try to run them in the middle of the rebuild process, too, but they do tend to be just that, transient, and to go away once I've completed the full rebuild, even when it means manually finding patches (ok) or switching to older gcc (not as good, but usually works, except as mentioned with cmake based packages) occasionally to do it. Fortunately, kde upstream seems to be /relatively/ good about building with the latest gcc themselves, so there's not as many problems there as there certainly could be given the cmake issue, but it is usually a problem for the couple of corner-cases whose upstream devs apparently don't update gcc as fast as most of the rest of kde does (sometimes not kde-base/* but other kde-based packages), and/or for the occasional non- kde but still qt/cmake based app. Tho fortunately for me personally at least, while I continue using kde as my DE of choice, with the kdepim move to akonadi and my subsequent purge of anything kdepim based, and the time it seems to take to get serious konqueror/rekonq bugs fixed indicating that even most kde folks apparently default to firefox or other alternatives, such that I too now default to firefox, and with the kde4 amarok and kaffeine already long replaced with non-kde alternatives due to their breakage, and with USE=semantic-desktop now turned off since I killed akonadi and thus could actually do so, there's now rather less kde-based-apps to get broken, here, and what remains tends to run VASTLY better and faster without all that semantic-desktop crap dragging it down! =:^) So there's less opportunity for the problem to manifest here, than there once was. =:^) -- 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: Lastrite: media-gfx/pngcrush
On Sat, 08 Oct 2011 18:33:15 +0300 Samuli Suominen wrote: > It's not like fastened lastriting hasn't happened before. I question > your motives in picking this particular one. It's not like I expected > cookies for the time I've put into this porting effort, but not this > "attack" either. Then stop trying to remove packages that have an active maintainer. I could have sworn that was written down somewhere. -- 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: Lastrite: media-gfx/pngcrush
On Sun, 09 Oct 2011 02:41:15 +0100 Markos Chandras wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On 10/08/11 22:45, Matt Turner wrote: > > On Sat, Oct 8, 2011 at 10:20 AM, Markos Chandras > > wrote: > >> On 10/08/2011 02:19 PM, Matt Turner wrote: > >>> On Sat, Oct 8, 2011 at 4:47 AM, Samuli Suominen > >>> wrote: > # Samuli Suominen (08 Oct 2011) # > Fails to compile against system libpng15, bug 356127 # > Removal in 14 days > >>> > >>> 14 days? > >>> > media-gfx/pngcrush > >>> > >> We can't really wait forever for slacking maintainers to fix > >> their packages. amd64 is almost ready to have libpng-1.5 stable > >> in the very near future > > > > Two things: > > > > 1) I'm *really* tired of the usage of the word "slacking" on this > > mailing list. If you or someone else wants to pay me to work on > > Gentoo, *then* you can tell me that I'm slacking. Otherwise, I'm a > > volunteer working on things that interest me in my free time. I > > truly do have more important things to do than to figure out how to > > port pngcrush to libpng1.5. Namely, graduate school and midterm > > exams. > > The bug is open since February (9 months). If you can't handle a bug > in 9 months then maybe you should consider stepping down as a > maintainer. Handling does not necessarily mean fixing. Masking could > be an acceptable solution as well. The fact that nobody pays us does > not mean that we can use that as an excuse for lower the QA barrier of > portage tree. If only I got a $1 everytime I hear this "excuse"... Um, you really want me to mask my package 9 months in advance because it blocks some random tracker that I have no idea when will become relevant? How about no. The onus of masking the package is on the person that institutes the deadline. Stop being surprised that people don't think your personal pet project is as important as you do. -- 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: GCC upgrades, FUD and gentoo documentation
On Sat, 8 Oct 2011 11:33:07 + Sven Vermeulen wrote: > Hi guys > > There is some FUD regarding GCC upgrades and I don't have the proper > knowledge to write a correct document on GCC upgrades. As you are currently > aware, we have a GCC upgrade guide [1], but it has seen its last update in > 2008. Since then, things have undoubtedly changed. > > What I can find on GCC upgrades and their apparent need (or no-need) for > rebuilding stuff: There are some packages that all need to be built with the same version of GCC. The whole qt-* family is an example, or at least it was a year ago (I'm not using KDE any more). Luckily they tend to be bumped as a unit. The biggest problem is building stuff with a newer version of gcc than the "system" version, either outside of portage, or selectively changing back with gcc-config. Programs can get linked to symbols in (usually) libstdc++.so.6 that have a symbol version that doesn't exist in the previous release. When you switch back to using that release as your system compiler, the libstc++ library also gets switched out, and suddenly your gcc-4.6-compiled firefox won't launch. If you've ever gotten a bug report like "libstdc++.so.6: version `GLIBCXX_3.4.15' not found" then you've dealt with this. This isn't a problem most users encounter, but some do like to try to rebuild some of their system a bit at a time, and this is the reason why I usually recommend they rebuild everything. By making it an all or nothing affair, they're less likely to try hopping back and forth between versions. -- 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
Re: [gentoo-dev] [PATCH autotools-utils] Use elibtoolize from libtool.eclass to fix libtool magic.
On Mon, 10 Oct 2011 11:10:49 -0500 Donnie Berkholz wrote: > On 09:55 Mon 10 Oct , Michał Górny wrote: > > On Sun, 9 Oct 2011 21:08:43 -0500 > > Donnie Berkholz wrote: > > > On 10:21 Sun 09 Oct , Michał Górny wrote: > > > > We're calling it with '--patch-only' to avoid heavy changes to > > > > ebuilds. This should handle gracefully eautoreconfed packages > > > > and those not using libtool as well (in worst case, it should > > > > try to apply patches twice). > > > > > > What kind of testing have you done? > > > > Simple testing on a few packages of mine. If you have something > > specific in mind, please be more accurate. > > It's probably better to test on other people's code, since your own > will always use eclass code in the way you imagine it being used. For > changes to popular eclasses like this, I'd go find a cross-section of > 25+ packages written by a variety of people besides yourself (or just > test all 87 in the tree). Yeah, I'm slowly testing random packages against it and haven't seen any problems yet. Would be nice, though, to be able to let tinderbox do the testing with modified eclasses. > Bonus points for those written by the most > and least experienced devs, who I'd expect to use things in more > unexpected/unlikely ways. Sunrise seems a good choice here. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH autotools-utils] Use elibtoolize from libtool.eclass to fix libtool magic.
On 09:55 Mon 10 Oct , Michał Górny wrote: > On Sun, 9 Oct 2011 21:08:43 -0500 > Donnie Berkholz wrote: > > On 10:21 Sun 09 Oct , Michał Górny wrote: > > > We're calling it with '--patch-only' to avoid heavy changes to > > > ebuilds. This should handle gracefully eautoreconfed packages and > > > those not using libtool as well (in worst case, it should try to > > > apply patches twice). > > > > What kind of testing have you done? > > Simple testing on a few packages of mine. If you have something > specific in mind, please be more accurate. It's probably better to test on other people's code, since your own will always use eclass code in the way you imagine it being used. For changes to popular eclasses like this, I'd go find a cross-section of 25+ packages written by a variety of people besides yourself (or just test all 87 in the tree). Bonus points for those written by the most and least experienced devs, who I'd expect to use things in more unexpected/unlikely ways. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgpZSatUY3Hl9.pgp Description: PGP signature
Re: [gentoo-dev] Re: GCC upgrades, FUD and gentoo documentation
On 10/10/11 4:45 AM, Diego Elio Pettenò wrote: > Not really. GCC, like most other libraries, only supports > forward-compatibility. Which means that you can use code built against > 4.5 when using 4.6. I'm not sure about that. It might be a bit speculative, but I think I remember problems with that unless I rebuilt everything with new GCC (this was not with 4.5 and 4.6, but some older versions). > On the other hand without any specifics as to what failed for you it is > difficult to judge whether you found an ABI break or simply a bug in > your library or code... If rebuilding with new GCC fixes the problem I think it means the problem was with ABI. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: GCC upgrades, FUD and gentoo documentation
Il giorno dom, 09/10/2011 alle 12.35 -0400, James Cloos ha scritto: > > > Ie, ln(1) cannot find some of the symbols it needs if the .so was > compiled with 4.5 and the .o files with 4.6. > > Which looks like an ABI issue, yes? Not really. GCC, like most other libraries, only supports forward-compatibility. Which means that you can use code built against 4.5 when using 4.6. Mixing and matching is never high priority and usually doesn't work. On the other hand without any specifics as to what failed for you it is difficult to judge whether you found an ABI break or simply a bug in your library or code... -- Diego Elio Pettenò — Flameeyes http://blog.flameeyes.eu/ signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH autotools-utils] Use elibtoolize from libtool.eclass to fix libtool magic.
On Sun, 9 Oct 2011 21:08:43 -0500 Donnie Berkholz wrote: > On 10:21 Sun 09 Oct , Michał Górny wrote: > > We're calling it with '--patch-only' to avoid heavy changes to > > ebuilds. This should handle gracefully eautoreconfed packages and > > those not using libtool as well (in worst case, it should try to > > apply patches twice). > > What kind of testing have you done? Simple testing on a few packages of mine. If you have something specific in mind, please be more accurate. -- Best regards, Michał Górny signature.asc Description: PGP signature
