[gentoo-dev] Re: Maintainer needed: dev-libs/icu
Diego Elio Pettenò posted on Mon, 05 Nov 2012 07:39:19 -0800 as excerpted: On 05/11/2012 07:31, Steven J. Long wrote: Are you really missing the fact that by testing someone's overlay, the package would by definition not be in the tree, and you wouldn't have to file any bugs at all, just (automatically) email the output back to the overlay developer? Which means I wouldn't be filing bugs for the problems with the _existing_ packages that are in tree, which is what the users actually _use_ by default. If the users are forced to use overlays to get working packages, then I feel I'm perfectly right with screaming at the developers who are using overlays for development because they leave users in a sorry state. I'm not sure if this is what SL had in mind, but it's what I thought of when I read his suggestion, triggered here by the won't have to file bugs at all bit. What about doing overlays, but ONLY one-at-a-time, and ONLY on special- request-runs, presumably immediately pre-tree-introduction? Among other things that might help for stuff like kde where a whole slew of packages are introduced to the tree (and should be tested) together, something that's easier done from a staging overlay. That way, any overlay runs would be pre-requested by the overlay person/ project, so they'd be specifically expecting results. Thus the could (if desired) skip filing bugs, just direct-mail part SL mentioned, or automated bug filing but in this case it'd be ENTIRELY by request and expected, since they would have pre-arranged for the tinderbox run and would be expecting/prepared-for the results. Additionally, one-overlay-at-a-time would automatically mean what's ever there is tested only against the tree and other packages in that overlay, limiting the where'd it come from problem. In fact, a pre-arranged unmask file (say tinderbox.unmask) in the profile could be used effectively as a whitelist to specify specific packages and versions for the tinderbox run. If it's in the whitelist, it's from the overlay, otherwise it's from the tree. This would let the overlay folks keep their live-builds, etc, out of tinderbox run, since they're presumably not tinderbox-test-ready anyway, as well as nicely solving the where'd it come from question. And tree packages would still be heavily emphasized, since all testing except for other packages in that specific overlay test would be against the tree. Let me try to re-explain this to you: let's say I import overlay $foobar and $foobar has library A and packages B C D E and F. Now there's package G in main tree that also uses library A. It fails in the tinderbox run. Who I have to report it to? This one would then be easy. Package G is in the main tree but you're doing a specifically requested overlay run, and it's failing built against overlay library A. You file the bug with the overlay maintainer, since that's specifically what you're testing, and library A is in tinderbox.unmask so the overlay version is specifically being tested in this run. But here's the kicker. Now you're more or less simply providing the tinderbox testing service. You don't have all the usual results analysis to do yourself (tho you might want to do a quick check from time to time to make sure it's still working as expected/intended), you pretty much simply forward them as-is to the overlay maintainer, giving them the test results they requested. They get to figure out where the problem is and adjust (or if it's a tree-only bug that just happened to popup in this test, duplicate it as such, and file the bug accordingly) as necessary. Now let's say I add more one overlay That won't happen in this one-overlay-at-a-time scenario. Again, the tree remains the primary focus, since all non-tinderbox.unmask-listed packages are by definition in-tree. You're simply providing a very specific overlay-against-tree tinderbox testing service, giving the requesting maintainers a bit more flexibility there, in exchange for offloading some of the responsibility you'd normally have for bug pre- analysis, etc, to them. They get both the additional flexibility of an overlay test, and rawer results that they have to do more work to parse, in the same package deal, but the focus remains the tree. There's no possibility or complexity of multiple overlays at once. And you're also failing to understand how the whole tinderbox works. I suggest you read the two posts I wrote on the topic, which will form a basis for the documentation of the tinderbox: http://goo.gl/SM9Rp http://goo.gl/SF0Dz FWIW I'm subscribed to your feed and gentoo-planet both, so saw those. I read/skimmed them, but some of it was beyond me for just reading, tho it'd definitely be useful if I were actually implementing a tinderbox here. So if I missed something obvious therein, and this idea isn't practical either, forgive the waste of time. -- Duncan - List replies
Re: [gentoo-dev] Re: Maintainer needed: dev-libs/icu
On 05/11/2012 13:45, Duncan wrote: What about doing overlays, but ONLY one-at-a-time, and ONLY on special- request-runs, presumably immediately pre-tree-introduction? Among other things that might help for stuff like kde where a whole slew of packages are introduced to the tree (and should be tested) together, something that's easier done from a staging overlay. It's actually easier done by package.mask as Ian already pointed out. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Re: Maintainer needed: dev-libs/icu
On 11/06/12 05:45, Duncan wrote: Diego Elio Pettenò posted on Mon, 05 Nov 2012 07:39:19 -0800 as excerpted: On 05/11/2012 07:31, Steven J. Long wrote: Are you really missing the fact that by testing someone's overlay, the package would by definition not be in the tree, and you wouldn't have to file any bugs at all, just (automatically) email the output back to the overlay developer? Which means I wouldn't be filing bugs for the problems with the _existing_ packages that are in tree, which is what the users actually _use_ by default. If the users are forced to use overlays to get working packages, then I feel I'm perfectly right with screaming at the developers who are using overlays for development because they leave users in a sorry state. I'm not sure if this is what SL had in mind, but it's what I thought of when I read his suggestion, triggered here by the won't have to file bugs at all bit. What about doing overlays, but ONLY one-at-a-time, and ONLY on special- request-runs, presumably immediately pre-tree-introduction? Among other things that might help for stuff like kde where a whole slew of packages are introduced to the tree (and should be tested) together, something that's easier done from a staging overlay. That way, any overlay runs would be pre-requested by the overlay person/ project, so they'd be specifically expecting results. Thus the could (if desired) skip filing bugs, just direct-mail part SL mentioned, or automated bug filing but in this case it'd be ENTIRELY by request and expected, since they would have pre-arranged for the tinderbox run and would be expecting/prepared-for the results. I've been doing this for some overlays - kde, qt, sunrise It's still a lot of work to set things up (keywords, blockers, useflags mostly), and it takes lots of time - the small qt overlay took me about 4 days walltime to process (I'd estimate somewhere near a CPU-day) But why rely on Diego or me for such things? All you need to do is setup a chroot, configure it well, emerge `cat pkglist` and watch the fallout. Additionally, one-overlay-at-a-time would automatically mean what's ever there is tested only against the tree and other packages in that overlay, limiting the where'd it come from problem. Aye, it gives pretty good results, but comes with extra setup time. ... but as you mentioned, if the overlays provided specific files with e.g. unmask lists it'd be easier, and anyone with reasonably fast hardware can do it themselves anyway. Happy compiling, Patrick
Re: [gentoo-dev] Re: Maintainer needed: dev-libs/icu
Ryan Hill dirtye...@gentoo.org writes: Christ on a $#@%! crutch. You can NOT auto-enable C++11 in your library based on a configure test and then stuff flags that are not supported by previous compiler versions into pkg-config for library consumers. Somebody sane please fix this. Though is it not normally a reasonable assumption that the library consumers will be built with the same or later compiler version as the library? In which case it does no harm.
Re: [gentoo-dev] Re: Maintainer needed: dev-libs/icu
On 31/10/2012 23:13, Graham Murray wrote: Though is it not normally a reasonable assumption that the library consumers will be built with the same or later compiler version as the library? In which case it does no harm. Not really, it's not. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Re: Maintainer needed: dev-libs/icu
Graham Murray wrote: Christ on a $#@%! crutch. You can NOT auto-enable C++11 in your library based on a configure test and then stuff flags that are not supported by previous compiler versions into pkg-config for library consumers. Somebody sane please fix this. Though is it not normally a reasonable assumption that the library consumers will be built with the same or later compiler version as the library? Well what about the consumers that have been built already? :) Now, if all consumers could be rebuilt as part of the build of the library (EAPI discussion about reverse dependencies) then I think it's a very reasonable assumption. That would hopefully not be required for very many libraries in the world, but if upstream is broken enough then I think it would be a good thing to promote awareness of that fact among users. I guess that they just don't know how broken it is. //Peter
Re: [gentoo-dev] Re: Maintainer needed: dev-libs/icu
Ryan Hill wrote: You can NOT I am not saying that it is a good idea, but of course you can. It has pretty sucky effects on how your library can be used, disabling various smart stuff that modern systems do, but I guess the upstream practises may be from a different time. Somebody sane please fix this. I both agree and I don't. I guess it will be difficult for representatives from a given distribution to fix very much upstream, if possible I think that the distribution should instead be fixed to deal with the limits imposed by upstream practises. In this case I think it means the EAPI reverse dependency rebuild discussion. Would that be sufficient to address the problem? //Peter pgpydVZch9ywT.pgp Description: PGP signature
[gentoo-dev] Re: Maintainer needed: dev-libs/icu
On Thu, 1 Nov 2012 07:21:38 +0100 Peter Stuge pe...@stuge.se wrote: Graham Murray wrote: Christ on a $#@%! crutch. You can NOT auto-enable C++11 in your library based on a configure test and then stuff flags that are not supported by previous compiler versions into pkg-config for library consumers. Somebody sane please fix this. Though is it not normally a reasonable assumption that the library consumers will be built with the same or later compiler version as the library? Well what about the consumers that have been built already? :) Now, if all consumers could be rebuilt as part of the build of the library (EAPI discussion about reverse dependencies) then I think it's a very reasonable assumption. This has nothing to do with dependencies not getting rebuilt when the library does. It's about switching to an earlier compiler version and having every single package depending on that library fail to build due to something that is non-obvious and hard to track down. You don't know that you have to rebuild the library because you don't know which package that damned flag came from. -- gcc-porting toolchain, wxwidgets we were never more here, expanse getting broader @ gentoo.org but bigger boats been done by less water signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Maintainer needed: dev-libs/icu
On 10/31/12 11:13 PM, Graham Murray wrote: Ryan Hill dirtye...@gentoo.org writes: Christ on a $#@%! crutch. You can NOT auto-enable C++11 in your library based on a configure test and then stuff flags that are not supported by previous compiler versions into pkg-config for library consumers. Somebody sane please fix this. Though is it not normally a reasonable assumption that the library consumers will be built with the same or later compiler version as the library? In which case it does no harm. To clarify: same compiler can support different versions of C++ standard. Those versions are not guaranteed to be compatible, and e.g. chromium fails to compile when -std=gnu++11 is forced (https://bugs.gentoo.org/show_bug.cgi?id=439698), while is otherwise compatible with gcc-4.7. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Maintainer needed: dev-libs/icu
On Thu, 1 Nov 2012 07:30:06 +0100 Peter Stuge pe...@stuge.se wrote: Ryan Hill wrote: You can NOT I am not saying that it is a good idea, but of course you can. It has pretty sucky effects on how your library can be used, disabling various smart stuff that modern systems do, but I guess the upstream practises may be from a different time. No, you can not do it because I will not let you. Somebody sane please fix this. I both agree and I don't. I guess it will be difficult for representatives from a given distribution to fix very much upstream, if possible I think that the distribution should instead be fixed to deal with the limits imposed by upstream practises. I think you're missing something here. This breakage was added to the Gentoo ebuild by the maintainer. In fact, it immediately follows a bit of code that sanitizes compiler flags from the pkg-config files, which was added *specifically so we don't run into issues like this*. In this case I think it means the EAPI reverse dependency rebuild discussion. Again, this has absolutely nothing to do with what I'm talking about. -- gcc-porting toolchain, wxwidgets we were never more here, expanse getting broader @ gentoo.org but bigger boats been done by less water signature.asc Description: PGP signature
[gentoo-dev] Re: Maintainer needed: dev-libs/icu
On Thu, 1 Nov 2012 07:30:06 +0100 Peter Stuge pe...@stuge.se wrote: I guess it will be difficult for representatives from a given distribution to fix very much upstream, if possible I think that the distribution should instead be fixed to deal with the limits imposed by upstream practises. Also, the amount of naïveté in that statement is truly heartwarming. I thank you sir. -- gcc-porting toolchain, wxwidgets we were never more here, expanse getting broader @ gentoo.org but bigger boats been done by less water signature.asc Description: PGP signature
[gentoo-dev] Re: Maintainer needed: dev-libs/icu
On Wed, Oct 31, 2012 at 11:50:13PM -0700, Diego Elio Pettenò wrote: Dirty experiments, no. Testing stuff that's almost ready, yes. If you run the tinderbox against dirty experiments, the time _I_ pour in to sort through the logs report bugs is wasted because they'll hit stupid hacks that fail to work. _If_ it's ready to be tested it is ready to be in package.mask and vice-versa, as it's expected to work *but has to be tested*. If it's not expected to work, why should I spend time on the tinderbox? I don't understand. The topic was how your tinderbox could be even more useful for Gentoo, but you make personal remarks and bring up devrel and QA? That's confusing. You ask me to step off Arfrever, I'm telling you why I'm not. He's right tho: the topic was Why doesn't your tinderbox work with overlays? Your response was to insult Arfrever and not actually answer the point. I'm sure you're open to the idea that your design can be made even more useful, if only for others, in ways you didn't think of yourself. See what I wrote above. If you don't understand _why_ I'm avoiding overlays with reason, then I'm seriously wasting my time responding to you. Well yeah, you finally explained something, after several emails of bullshit. Bully for you. Sure you're not burning out? For anyone else not sure about reasons, there's some more here: http://blog.flameeyes.eu/2010/08/fixed-in-overlay-read-not-fixed Not that I agree with the argument: a tinderbox that can handle overlays sounds much more useful. The process outlined is that you can do special runs against p.masked packages, given an email from the developer. Adding the overlay is just as easy to script, so same amount of work, or less. Of course if the overlay is badly maintained, you don't have to do anything you don't want. But if you don't want to support that workflow *at all* (or only if all the overlay packages are first introduced to the main tree and p.masked in line with _your_ preferred workflow) that is of course your choice. Just don't be surprised when people who work in overlays for whatever reason choose another tinderbox, or deem your tinderbox irrelevant to _their_ workflow. After all, it is: by design, as you've so politely explained. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
[gentoo-dev] Re: Maintainer needed: dev-libs/icu
On Thu, 1 Nov 2012 01:00:14 -0600 Ryan Hill dirtye...@gentoo.org wrote: This has nothing to do with dependencies not getting rebuilt when the library does. It's about switching to an earlier compiler version and having every single package depending on that library fail to build due to something that is non-obvious and hard to track down. You don't know that you have to rebuild the library because you don't know which package that damned flag came from. I've had someone try to make the argument that we don't really support users mixing packages built by different compiler versions. It is true that doing so can sometimes lead to problems with ABI compatibility, unsupported flags, and so forth, as well as more subtle issues due to compiler bugs, etc. Sometimes there is nothing we can reasonably do about this and we have to live with it. Other times there are solutions, such as making sure that ABI-changing options don't get propagated down to other packages through foo-config/pkg-config scripts, or ensuring packages honor the users compiler flags (see for a topical example bug #202059), and we should and do fix these things when we encounter them. What we don't do is make the situation worse by actively introducing these things into the tree, knowing full well the problems they can cause, and hide behind the excuse that it's unsupported. -- gcc-porting toolchain, wxwidgets we were never more here, expanse getting broader @ gentoo.org but bigger boats been done by less water signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Maintainer needed: dev-libs/icu
On Thu, Nov 1, 2012 at 10:23 PM, Steven J. Long sl...@rathaus.eclipse.co.uk wrote: He's right tho: the topic was Why doesn't your tinderbox work with overlays? Your response was to insult Arfrever and not actually answer the point. Well, nobody is paying Diego to make a tinderbox that works with overlays. He actually mentioned that he was going to be spending some time better documenting how it works, which I think is a big win for everybody. Perhaps others will extend his work. That said, I don't think it is helpful to drive off outside contributors either. Ultimately those with commit access need to use discretion when applying it. Boost/ICU/etc are obviously a bit of a mess for what appears to be a variety of reasons. It would be best for those who actually care to invest in them (whether devs or not) to work together to find the best way of doing so. If what they come up with causes issues for others, then they should point it out and escalate as appropriate. But, the rest of us should keep in mind that caring for things like libraries is a bit of a thankless job. Nobody says, gee, thanks for getting that libjpeg bump into the tree, I can really appreciate the slight refinement in the API the way they might appreciate a new KDE release or whatever. However, libraries are a ton of work when it comes to coordinating with various other Gentoo teams, and some upstream practices don't make it easier. And QA can be a bit of a thankless job as well, since the sign of a really effective QA process is that end users don't even realize it is there. However, even when done perfectly there can be hurt feelings... Rich
Re: [gentoo-dev] Re: Maintainer needed: dev-libs/icu
On 01/11/2012 19:23, Steven J. Long wrote: He's right tho: the topic was Why doesn't your tinderbox work with overlays? Your response was to insult Arfrever and not actually answer the point. _Arfrever himself_ point to my reason in that blog post, FFS. Not that I agree with the argument: a tinderbox that can handle overlays sounds much more useful. The process outlined is that you can do special runs against p.masked packages, given an email from the developer. Adding the overlay is just as easy to script, so same amount of work, or less. Of course if the overlay is badly maintained, you don't have to do anything you don't want. Yeah it _could_ be the same amount of work _if_ the overlay is well-maintained. But since those overlays are pretty rare, I'm not going to go out of my way just because. Just don't be surprised when people who work in overlays for whatever reason choose another tinderbox, or deem your tinderbox irrelevant to _their_ workflow. I'm not surprised. And I honestly don't give a rat's ass about it. Gnome works in an overlay, but there is a tipping point when the overlay content is stable enough that it enters the tree under p.mask. Qt did the same as well. Both of them had asked me runs in the past, and it's fine. Now of course there are experimental overlays. I don't care about those, they'll probably add noise rather than signal, so, there they go, out of the window. What about those overlays who're never targeting into the tree? Well, duh, I don't care about those because if it's not in the main tree, for me it's not Gentoo, full stop. Do you still fail to see why I don't find it a _limitation_? The only moment when I can actually get decent signal out of a tinderbox run is when the package _is_ good enough to get into p.mask; if _all_ packages fail to build because the API is totally broken and nobody fixed it, it'll just add to the number of open bugs I have. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
[gentoo-dev] Re: Maintainer needed: dev-libs/icu
On Mon, 29 Oct 2012 15:39:14 -0400 Alexandre Rostovtsev tetrom...@gentoo.org wrote: On Mon, 2012-10-29 at 11:35 -0700, Diego Elio Pettenò wrote: The problem with ICU is worse than you expect. For once, with version 50, it changes ABI (but not soname as far as I can tell) depending on which compiler you build it with. Yes, this is pretty much fucked up. It's even worse than that: if you switch compilers, the declared API in icu-50 headers will not match the ABI of the icu binary. I've just filed https://bugs.gentoo.org/show_bug.cgi?id=440156 after hitting a linking failure when building libreoffice using gcc-4.7 against icu-50 which had been built with gcc-4.6. Christ on a $#@%! crutch. You can NOT auto-enable C++11 in your library based on a configure test and then stuff flags that are not supported by previous compiler versions into pkg-config for library consumers. Somebody sane please fix this. -- gcc-porting toolchain, wxwidgets we were never more here, expanse getting broader @ gentoo.org but bigger boats been done by less water signature.asc Description: PGP signature
