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] Maintainer needed: dev-libs/icu
Diego Elio Pettenò wrote: One of major problems with this tinderbox is that it cannot be used to test packages against newer versions of packages present in overlays [1] Which is not a problem since we're _not_ talking about packages in overlays but of a bump in the main tree which is not fixed. Um, so how come an overlay isn't the obvious method for testing, before putting things in the main tree? What other method is *more* convenient for testing? Hell, I am *not* a developer exactly *because* overlays are so convenient. Really, I would like to ask you to step off of the discussion, you've proven yourself incapable to work within the constraint of the tree already a long time ago. Diego, I would like to ask you to step off Arfrever. Try for a second to appreciate the time he has contributed and from the sound of it continues to contribute, even if he does not use the methods that you would have made him use if you were paying his salary. You're sounding like a complete ass in this thread, and I don't see the point of that at all. I expect that you're better than that. Especially snapping back at him with some unrelated bull personal remark when he points out what seems to me to be a very legitimate shortcoming of your darling baby is not especially excellent. Maybe it would have been possible for you to reply something like yes, that would be a cool feature actually, if you send me a perfect patch I'll be happy to deploy it or well, I don't see the point in doing that, but if it would help you then send me a perfect patch and I'll be happy to deploy it instead. I guess you see how such an answer would have communicated something different from the answer that you chose. //Peter
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] Maintainer needed: dev-libs/icu
On 31/10/2012 23:18, Peter Stuge wrote: Um, so how come an overlay isn't the obvious method for testing, before putting things in the main tree? What other method is *more* convenient for testing? package.mask Diego, I would like to ask you to step off Arfrever. And I would like that developers didn't try to workaround Devrel's and QA's shared choices. Try for a second to appreciate the time he has contributed and from the sound of it continues to contribute, even if he does not use the methods that you would have made him use if you were paying his salary. Honestly, from my point of view (and I doubt it's only mine given that he got quite a list of people scorned) he contributed mostly headaches. Especially snapping back at him with some unrelated bull personal remark when he points out what seems to me to be a very legitimate shortcoming of your darling baby is not especially excellent. It's not a shortcoming as much as an intentional design. So thank you very, much stop second guessing me. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
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
Re: [gentoo-dev] Maintainer needed: dev-libs/icu
Diego Elio Pettenò wrote: Um, so how come an overlay isn't the obvious method for testing, before putting things in the main tree? What other method is *more* convenient for testing? package.mask Can you clarify? Do you propose that developers carry out wild experiments by committing things that probably don't work and masking them? I don't know, that seems like it will create a pretty dirty tree history, something I would want to avoid as far as possible. Overlays seem like a perfect gateway to me. Diego, I would like to ask you to step off Arfrever. And I would like that developers didn't try to workaround Devrel's and QA's shared choices. 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. Try for a second to appreciate the time he has contributed and from the sound of it continues to contribute, even if he does not use the methods that you would have made him use if you were paying his salary. Honestly, from my point of view (and I doubt it's only mine given that he got quite a list of people scorned) he contributed mostly headaches. I guess that if you review the testing of the couple of hundred Python packages that he mentioned you would find one or two valuable items. Especially snapping back at him with some unrelated bull personal remark when he points out what seems to me to be a very legitimate shortcoming of your darling baby is not especially excellent. It's not a shortcoming as much as an intentional design. So thank you very, much stop second guessing me. 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. //Peter
Re: [gentoo-dev] Maintainer needed: dev-libs/icu
On 31/10/2012 23:42, Peter Stuge wrote: Can you clarify? Do you propose that developers carry out wild experiments by committing things that probably don't work and masking them? 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. I guess that if you review the testing of the couple of hundred Python packages that he mentioned you would find one or two valuable items. Blah blah blah blah. Seriously you can fix 200 packages _for your own toy reason_ but if you break the tree every three months by committing shit that is not tested, or is tested for a very peculiar corner case only, you're creating more trouble than you're worth. And that's, once again, not just my opinion. If it's not your opinion, I'd say we disagree and that's it. I won't try to convince you, please stop demanding that I bow to your opinion. 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. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
[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] [warning] the bug queue has 100 bugs
On Wed, Oct 31, 2012 at 5:08 PM, Jeroen Roovers j...@gentoo.org wrote: Though if you don't know these kinds of basics, I'm not sure you should be doing *any* (semi- or not) automated bug filing. What if you don't have the privilege to assign bugs, but are willing to do the work of filing the bugs? Yeah, that kind of sucks. Perhaps we should extend the privilege a little more often? Cheers, Dirkjan
Re: [gentoo-dev] About unresolved bugs assigned to mobile for ages
On 30/10/12 19:02, Steev Klimaszewski wrote: On Mon, 2012-10-29 at 09:50 +, Markos Chandras wrote: On Sun, Oct 28, 2012 at 12:26 PM, Pacho Ramos pa...@gentoo.org wrote: Hello I would like to know about mobile team status and also show that this team has important bugs assigned to them for a long time, some of them with patches (and reporters angry because of seeing things untouched for a long time). If anyone has time to join to the team and help, nice, if the team needs to drop from some packages maintainership due lack of manpower, please tell us what packages do you want up for grabs. Thanks I don't believe anyone is active in the mobile herd anymore. Probably the packages need to be moved to maintainer-needed@ so individual developers can take care of them. As far as I know, I'm the only one in the mobile herd (actually I think it's 3 of us total), and I don't have the hardware to even test some things with it anymore (e.g. pcmciautils - which REALLY needs a fix and some lovin from someone) - I'd definitely agree that the mobile herd could go away, or if some people wanted to join and help out, that would be greatly appreciated. Take a look at pcmciautils-018_p8 :-)
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/boost: boost-1.46.1-r1.ebuild metadata.xml boost-1.49.0-r1.ebuild boost-1.51.0-r1.ebuild ChangeLog boost-1.47.0.ebuild boost-1.35.0-
On Wed, 31 Oct 2012 11:58:16 -0700 Diego Elio Pettenò flamee...@flameeyes.eu wrote: On 31/10/2012 11:49, Michał Górny wrote: In other words, you have thrown a big, destructive change to live, stable systems without prior testing (and don't say you were able to test it thoroughly in one day's time) and you have left them for other people to maintain and fix. I am really getting tired of those 'senior developers' who believe that Gentoo is their private playground where they can do whatever comes into their mind and ignore package maintainers. Given the kind of destructive behaviour that boost has been having, given that everybody else _beside you_ don't see any reason to keep that slotted boost, given that you've been acting for the most part as a sockpuppet for a developer who's been kicked out of Gentoo, I think it's obvious why I went the way I went. If you have a personal vendetta against Arfrever, then take it to him. As far as I'm concerned, Arfrever is a very knowledgeable person and I doubt that you can compete with him in the area of Python (and the Python counterpart of boost, effectively). And even if that, you have no right to remove maintainers from a package or unCC them from bugs just because you don't like them or disagree with their opinion. Especially that you are not a maintainer of this package. Here's the deal: I've stated clearly what the situation was going to be; Tiziano has been the primary maintainer (first in the list) and he's okay with the move, he _is_ in the cpp herd that will take care of it, and as I said I'll make sure to help out because I have a number of packages depending on boost (but not on other C++ libraries). Sorry, I didn't notice his reply. That's my mistake. You had a month while Mike delayed glibc-2.16 stable, among other things because of boost-1.50, and you did _squat_ to handle it. So it's time that people who've been there before step up and fix it the way that it has to be fixed. Is this something like 'people didn't fix issues yet, so let's throw the issues at users to motivate them'? -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] Re: Clarify the as-is license?
On Tue, 25 Sep 2012, Ulrich Mueller wrote: I've created licenses/HPND [1] now, and added it to the @OSI-APPROVED group. So packages whose license matches this template can be changed from as-is to HPND. (And please, _only_ OSD-compliant packages. We don't want the same mess again, as we have with as-is.) [1] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/licenses/HPND Coming back to this. We've continued discussion in the licenses team, and the conclusion was that as-is should be deprecated. Therefore, a repoman warning for deprecated licenses has been added (and will become active with one of the next Portage releases), along with a new @DEPRECATED license group. See Bug 440638 for details. So please don't use as-is for new packages, and consider moving existing packages away from it. We're down from 679 packages (in September) to 600 today. Especially, there should be no more as-is in the system set and on our release media. Ulrich
Re: [gentoo-dev] [warning] the bug queue has 100 bugs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/01/2012 03:59 AM, Dirkjan Ochtman wrote: On Wed, Oct 31, 2012 at 5:08 PM, Jeroen Roovers j...@gentoo.org wrote: Though if you don't know these kinds of basics, I'm not sure you should be doing *any* (semi- or not) automated bug filing. What if you don't have the privilege to assign bugs, but are willing to do the work of filing the bugs? Yeah, that kind of sucks. Perhaps we should extend the privilege a little more often? I agree 100%, if anyone is willing to file proper and correct bugs in an automated way then we need to extend to them the ability to properly assign them to prevent our bug-wranglers from being crushed. I believe that allowing someone to assign a bug is very appropriate in this case. - -Zero_Chaos Cheers, Dirkjan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQkmnDAAoJEKXdFCfdEflKcgsP/j5V0RhZcrJ2qGok8hlZtAdy +0D1uqbp82XUud6esUgNkCMueFrKHVKURtZwIQlUiL4Y5MexWsPk5/+V0iH+XMGl H0Sc5KlDTnjB9Fi67/026hm2FvAzy2nyeoXazqdc8jnhG4/adMp5UdRcjPtH+nLm 3KShd2BIava1lSZRR3EEOlo2qPFtYloxy7KsGWN+KwC+03DLEyCyeJbN06yxu5B9 z7eo53nSvig6aZKQTwd+6n9MKjHUDkHK+Hv3y7q2S4IR1+3gC7kvrTqHE+LheCVO sZ+BQzGwNUuAeVvmdlJSXLMuQRmR5SoWv7CqRccQcLFX/AX8hhyvQaQidAP3YzG/ gZqx7dc0GvWJ0E1bHQeN0/6YhfvnR83TEaugfilp+BzLfvqHLY9xCtVNiGzYQBqS CjGTeJqH2lPhpg7+/cyKU6l17tAN0TjRd3y9K9F52QJskwth0Rs3qxBT/Ol/zGqC rYDyOPGxu+/cgYFGJn796OZEedh9/kbk3GnvOdAO9yUpU/1JuiCnZ+1l95DJfrzi eFSegwB3DTy7Pr0GNgp3R1vFVlwLL7AUIfHVbdrY17xqwx/Om1m1WdeqyZIWymp3 Lc+riJQBNbyJ0NKX/7joK8JOyPK7SzHBSzWgOl0PYxw/RzdKVv4BSWOAVVwb4Iof JTozrERY+GUb7Rm1IGKt =4Fqk -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/boost: boost-1.46.1-r1.ebuild metadata.xml boost-1.49.0-r1.ebuild boost-1.51.0-r1.ebuild ChangeLog boost-1.47.0.ebuild boost-1.35.0-
On Thu, Nov 1, 2012 at 9:38 AM, Michał Górny mgo...@gentoo.org wrote: And even if that, you have no right to remove maintainers from a package or unCC them from bugs just because you don't like them or disagree with their opinion. Especially that you are not a maintainer of this package. To be honest, I also don't understand why Diego removed the maintainers from metadata.xml as these people are the real maintainers. cpp@ (as a group) hasn't touched boost for years. -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
[gentoo-dev] Documenting touching of arch profiles' files
Hi all, With regards to bug #304435[1], we would like to formalise the policy for touching arch profiles' files. The key suggested points: * Archs profiles should generally only be touched by members of that arch team, unless prior permission is given * Exception: anyone may add a mask to an arch profile only if - it delays visibility of something new for that arch (eg. dependencies introduced in a version bump), and - it is not reasonable to follow the standard keyword dropping procedure (many other packages would be affected), and - the responsible arch team is not responsive * The person touching arch profiles is responsible for the subsequent maintenance of said entries, and any subsequent breakage. Thoughts? Best regards, Michael [1]: https://bugs.gentoo.org/show_bug.cgi?id=304435
Re: [gentoo-dev] [warning] the bug queue has 100 bugs
On Thu, Nov 1, 2012 at 7:59 AM, Dirkjan Ochtman d...@gentoo.org wrote: On Wed, Oct 31, 2012 at 5:08 PM, Jeroen Roovers j...@gentoo.org wrote: Though if you don't know these kinds of basics, I'm not sure you should be doing *any* (semi- or not) automated bug filing. What if you don't have the privilege to assign bugs, but are willing to do the work of filing the bugs? Yeah, that kind of sucks. Perhaps we should extend the privilege a little more often? Cheers, Dirkjan Extend it? More often? It is not a matter of frequency. If a user requests bugzilla rights, and a developer trusts him, he can grant him access. -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/boost: boost-1.46.1-r1.ebuild metadata.xml boost-1.49.0-r1.ebuild boost-1.51.0-r1.ebuild ChangeLog boost-1.47.0.ebuild boost-1.35.0-
Firstly, why are you guys always so mad, and secondly why don't we just start packaging more of these packages as binaries then or bundling the needed version like the rest of the world does anyways? For many packages and systems (in this day and age of personal computing power) the advantage of source or not bundling is negligible but mostly I am starting to get slightly concerned about everyones health having been reading this list for years now. Things like slotted boost and a new glibc really wind some people up, it's not good - it's very concerning. Your health is more important than being forced to increase your compiled binary size by a few KB, despite the tempting memory gain, or because your package won't compile because someone removed one of the 8 available versions of that library you depended on. It is easier to buy more RAM than to reduce ones blood pressure, let me tell you. So how about we transform this distro into one where decisions are made on real world benefits, not purist ideals, and technical giants help each other to make breakthroughs unimaginable to others because they are smarter, work together, and the most kick-ass geeks on this interweb. I want to keep using Gentoo not just because of the pretty colours on the eix output or because when I run emerge --world in a coffee shop all the chicks think I'm that guy from the Hackers movie, or even because my favourite color is purple. I want to keep using Gentoo because the team effing rocks! Who's with me? Jamie
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/boost: boost-1.46.1-r1.ebuild metadata.xml boost-1.49.0-r1.ebuild boost-1.51.0-r1.ebuild ChangeLog boost-1.47.0.ebuild boost-1.35.0-
On 01/11/2012 06:50, Jamie Learmonth wrote: Who's with me? Not me. If you're just looking for another binary distribution, CentOS is there. Or Sabayon. Or Ubuntu. Pick your poison. But I use and _develop_ Gentoo because I _want_, and sometimes just _need_ source based! Sometiems it's because I'm doing embedded work and I have to shave even those 4KiB, most of the time is because I want the flexibility. And unbundling almost never has negligible advantages as it's not the _size_ or performance that we care about in those situation but security and reliability. Would you rather have to track down Internal Compiler Errors in two dozens packages, or on one, even if it takes slightly longer when it breaks compatibility? (And almost never it takes _that_ long anyway.) I would definitely prefer the one. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/boost: boost-1.46.1-r1.ebuild metadata.xml boost-1.49.0-r1.ebuild boost-1.51.0-r1.ebuild ChangeLog boost-1.47.0.ebuild boost-1.35.0-
2012/11/1 Jamie Learmonth jamie-li...@boxlightmedia.com: Firstly, why are you guys always so mad, and secondly why don't we just start packaging more of these packages as binaries then or bundling the needed version like the rest of the world does anyways? So are you suggesting to package all the binaries that depend upon too old boost, or upon too new boost, or whatever, as binaries? I always thought those few -bin packages are -bin just because they take quite a lot time to be compiled. So how about we transform this distro into one where decisions are made on real world benefits, not purist ideals, and technical giants help each other to make breakthroughs unimaginable to others because they are smarter, work together, and the most kick-ass geeks on this interweb. I want to keep using Gentoo not just because of the pretty colours on the eix output or because when I run emerge --world in a coffee shop all the chicks think I'm that guy from the Hackers movie, or even because my favourite color is purple. I want to keep using Gentoo because the team effing rocks! Who's with me? I hope you'd forgive I'd oppose that suggestion, given I'm not a Gentoo dev but just a C++ developer who uses Gentoo as his primary (and, in fact, only) distro and loves it a lot. Gentoo has a wonderful community which I truly love, but first thing about a distro is how it helps you to solve your problems and achieve your goals. I'd surely miss the slotted Boost, since it was one of the things I needed for my C++ thingies and which I loved, but Diego's arguments are sane and reasonable, and I also had quite some PITA with old/new/whatever Boost versions, so OK, I can live without slotted Boost. But please, leave Gentoo as that powerful distro that really helps to work and code. I want it source-based. I want to be able to seamlessly have Qt 4.8., or cabal integrated with Portage (kudos to gentoo-haskell guys, they're doing great work), and things like that. That makes even more sense given the new C++11 standard and it's gradual implementation in gcc. One could just as well say let's just keep the newest gcc 4.7 in portage, since there is software that fails to build with gcc 4.6 and earlier, for example. -- Georg Rudoy LeechCraft — http://leechcraft.org
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/boost: boost-1.46.1-r1.ebuild metadata.xml boost-1.49.0-r1.ebuild boost-1.51.0-r1.ebuild ChangeLog boost-1.47.0.ebuild boost-1.35.0-
On 11/01/2012 02:50 PM, Jamie Learmonth wrote: Firstly, why are you guys always so mad, and secondly why don't we just start packaging more of these packages as binaries then or bundling the needed version like the rest of the world does anyways? You lost faith in our ways, maybe dberkholz can help you. watch http://dberkholz.com/2012/07/10/gentoo-linux-or-why-in-the-world-you-should-compile-everything/ 3 times now compile gcc by hand then chant the portage prayer and lolcat at LFS people (you might need to emerge games-misc/lolcat first) after that install ubuntu in a vbox (close all windows and lock your door beforehand) If you survived, chant the portage prayer. So how about we transform this distro into one where decisions are made on real world benefits, not purist ideals, and technical giants help each other to make breakthroughs unimaginable to others because they are smarter, work together, and the most kick-ass geeks on this interweb. I want to keep using Gentoo not just because of the pretty colours on the eix output or because when I run emerge --world in a coffee shop all the chicks think I'm that guy from the Hackers movie, or even because my favourite color is purple. I want to keep using Gentoo because the team effing rocks! How did it turn out with the chicks? Who's with me? I will forgive you... this time.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/boost: boost-1.46.1-r1.ebuild metadata.xml boost-1.49.0-r1.ebuild boost-1.51.0-r1.ebuild ChangeLog boost-1.47.0.ebuild boost-1.35.0-
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 01/11/12 10:10 AM, Georg Rudoy wrote: 2012/11/1 Jamie Learmonth jamie-li...@boxlightmedia.com: Firstly, why are you guys always so mad, and secondly why don't we just start packaging more of these packages as binaries then or bundling the needed version like the rest of the world does anyways? So are you suggesting to package all the binaries that depend upon too old boost, or upon too new boost, or whatever, as binaries? I always thought those few -bin packages are -bin just because they take quite a lot time to be compiled. They are. This idea wouldn't work tho -- providing the old boost as binaries isn't actually going to help things, unless they are fully static, as it's the breakage against the toolchain that invalidates them (otherwise it wouldn't be an issue to leave 'em in the tree and for that matter leave boost slotted and have all rdeps just depend on the slot they were written for). And fully static binary packages are just plain wrong on any number of levels for something like this imo. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlCSixYACgkQ2ugaI38ACPB72AD9EUYVEovDTDkHBmURJ3XGWt7Z EdPNP7F5k46lZAM6LscA/0rO3wjaVfBZDwKi88kX6NL3nWEUgpDxmNASrN42xs+O =KC5a -END PGP SIGNATURE-
Re: [gentoo-dev] Merging the devrel handbook into the devmanual
On 31.10.2012 14.39, Michael Palimaka wrote: Hi all, In bug #304435[1], hwoarang suggested merging the devrel handbook[2] into the devmanual[3]. As the project has grown, so has the amount - and dispersion - of development information. I believe consolidation of this information into a single point will make everyone's (especially new developers) lives easier. What do you think? I think you will only find people who support the idea. Some years back I tried to list people to migrate information on the basis of for example one page per developer but the actual contributions didn't amount to much. Let's hope there's renewed energy on this front. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Merging the devrel handbook into the devmanual
On Thu, Nov 1, 2012 at 2:48 PM, Petteri Räty betelge...@gentoo.org wrote: On 31.10.2012 14.39, Michael Palimaka wrote: Hi all, In bug #304435[1], hwoarang suggested merging the devrel handbook[2] into the devmanual[3]. As the project has grown, so has the amount - and dispersion - of development information. I believe consolidation of this information into a single point will make everyone's (especially new developers) lives easier. What do you think? I think you will only find people who support the idea. Some years back I tried to list people to migrate information on the basis of for example one page per developer but the actual contributions didn't amount to much. Let's hope there's renewed energy on this front. Regards, Petteri There is :) I will create a separate branch tonight so whoever is interested can start working on it. -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
Re: [gentoo-dev] [warning] the bug queue has 100 bugs
On Thu, 1 Nov 2012 08:59:09 +0100 Dirkjan Ochtman d...@gentoo.org wrote: What if you don't have the privilege to assign bugs, but are willing to do the work of filing the bugs? Yeah, that kind of sucks. Perhaps we should extend the privilege a little more often? In this case no prior history helped me and I foresaw only a few bug reports arising, not several dozens. And anyway, assigning them took only half an hour. jer
Re: [gentoo-dev] Merging the devrel handbook into the devmanual
On Wed, 31 Oct 2012 17:26:38 +0100 Theo Chatzimichos tampak...@gentoo.org wrote: On Wed, Oct 31, 2012 at 1:39 PM, Michael Palimaka kensing...@gentoo.org wrote: Hi all, In bug #304435[1], hwoarang suggested merging the devrel handbook[2] into the devmanual[3]. As the project has grown, so has the amount - and dispersion - of development information. I believe consolidation of this information into a single point will make everyone's (especially new developers) lives easier. What do you think? Best regards, Michael [1]: https://bugs.gentoo.org/show_bug.cgi?id=304435 [2]: http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml [3]: http://devmanual.gentoo.org/ +1 and btw move the devmanual in the wiki :D I'm not sure if wiki fits nicely here. I believe that wiki is very useful at taking notes, writing quick guides and sharing information and tips in general. The main advantage is the free workflow -- you have an idea to share but can't do it all by yourself. You start it, others can easily improve it. Sadly, our wiki is MediaWiki. Not getting deep into it, the syntax is worse than awful. It could be considered acceptable if you write encyclopedia articles, stuff with heavy inside linking and not much code inside. However, for technical articles it is horrible, horrible and once more horrible. Shortly saying, devmanual in wiki would mostly consist of HTML tagsoup intermixed with wiki text. For the very simple reason that MediaWiki lags markup for as basic things as inline code and requires you to use HTML instead. Not something I'd use for anything as fundamental as devmanual. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Merging the devrel handbook into the devmanual
On Thu, Nov 1, 2012 at 5:34 PM, Michał Górny mgo...@gentoo.org wrote: On Wed, 31 Oct 2012 17:26:38 +0100 Theo Chatzimichos tampak...@gentoo.org wrote: On Wed, Oct 31, 2012 at 1:39 PM, Michael Palimaka kensing...@gentoo.org wrote: Hi all, In bug #304435[1], hwoarang suggested merging the devrel handbook[2] into the devmanual[3]. As the project has grown, so has the amount - and dispersion - of development information. I believe consolidation of this information into a single point will make everyone's (especially new developers) lives easier. What do you think? Best regards, Michael [1]: https://bugs.gentoo.org/show_bug.cgi?id=304435 [2]: http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml [3]: http://devmanual.gentoo.org/ +1 and btw move the devmanual in the wiki :D I'm not sure if wiki fits nicely here. I believe that wiki is very useful at taking notes, writing quick guides and sharing information and tips in general. The main advantage is the free workflow -- you have an idea to share but can't do it all by yourself. You start it, others can easily improve it. Sadly, our wiki is MediaWiki. Not getting deep into it, the syntax is worse than awful. It could be considered acceptable if you write encyclopedia articles, stuff with heavy inside linking and not much code inside. However, for technical articles it is horrible, horrible and once more horrible. Shortly saying, devmanual in wiki would mostly consist of HTML tagsoup intermixed with wiki text. For the very simple reason that MediaWiki lags markup for as basic things as inline code and requires you to use HTML instead. Not something I'd use for anything as fundamental as devmanual. Rosetta Code (my site) runs MediaWiki. I can attest to the terrible thing that is MW syntax. That said, we did ultimately come up with workarounds for 98% of the problems. (Most of the remaining 2% are spammers...and that comes down to a question of strongly you lock the thing down.) I've submitted patches to Gentoo docs before. Honestly, I found it a pain; I'm not accustomed to that particular process. Admittedly, this is one of those cases where I simply lack an attainable skill. If nothing else, I'd love to see the docs all reside in Git; I could fork to my Github account and generate pull requests from there. A proper maintainer could review the pull request and decide whether or not to merge it. That would be a much more comfortable workflow, IMO. (Heck, I wouldn't mind migrating RC to a similar workflow; I'd just have to migrate gigabytes worth of wikitext history to a format with new semantics...) -- :wq
Re: [gentoo-dev] Merging the devrel handbook into the devmanual
On Thu, 1 Nov 2012 17:42:52 -0400 Michael Mol mike...@gmail.com wrote: On Thu, Nov 1, 2012 at 5:34 PM, Michał Górny mgo...@gentoo.org wrote: Shortly saying, devmanual in wiki would mostly consist of HTML tagsoup intermixed with wiki text. For the very simple reason that MediaWiki lags markup for as basic things as inline code and requires you to use HTML instead. Not something I'd use for anything as fundamental as devmanual. Rosetta Code (my site) runs MediaWiki. I can attest to the terrible thing that is MW syntax. That said, we did ultimately come up with workarounds for 98% of the problems. (Most of the remaining 2% are spammers...and that comes down to a question of strongly you lock the thing down.) Do you believe that the effort was worth it? As far as I can see, you worked around issues with a particularly bad software for your use. Instead, you could work on a good piece of software which could help others. I've submitted patches to Gentoo docs before. Honestly, I found it a pain; I'm not accustomed to that particular process. Admittedly, this is one of those cases where I simply lack an attainable skill. I'm not saying that our XML forks are good. I'd honestly just use reStructuredText which is basically 'good enough' to write articles efficiently while keeping them readable. If nothing else, I'd love to see the docs all reside in Git; I could fork to my Github account and generate pull requests from there. A proper maintainer could review the pull request and decide whether or not to merge it. That would be a much more comfortable workflow, IMO. (Heck, I wouldn't mind migrating RC to a similar workflow; I'd just have to migrate gigabytes worth of wikitext history to a format with new semantics...) Yes, considering the development of modern git solutions, old wikis could be at least partially replaced by it. I think the github wikis are the best example here, with their best feature being the ability to choose markup yourself (however, to be honest, some of the markups aren't implemented really well there). However, that's the only thing which github did quite good. The quality of forking and pull requests on github are a whole different story, and something not really suited for real-life workflow. In that case, bitbucket is definitely superior to them. -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] The problem with new dev-python/argparse and REQUIRED_USE
Hello, Recently I have committed a new dev-python/argparse revision. I have migrated it to distutils-r1 and enabled building only for those Python versions which don't have argparse built-in. Sadly, I had to package.mask it since it suffers a REQUIRED_USE issue on modern systems. For those who are not in the topic, argparse is included in Python distribution since versions 2.7 and 3.2 (including both pypy versions in Gentoo). Although the 'external' argparse can still be built and installed, it serves no purpose since the built-in takes precedence. The problem is that after disabling argparse build for modern Python versions, the ebuild is left with no Python implementation enabled on modern systems. And this causes the REQUIRED_USE check to fail because of an attempt to build a package for no Python implementation. The main issue here is that REQUIRED_USE errors are not really helpful to users. I don't think there's a way to deliver a custom message there, so user (assuming he is able to understand the dependency syntax) is basically told to enable one of the old Python versions -- which is definitely not the right thing to do. In order to fix that, I have committed a virtual/python-argparse as well and worked on getting both the tree and overlays to depend on it. Still, it will take some time for everything to migrate (yes, I failed to revbump those packages...) and even then, I'm still worried that some users will be left with argparse being pulled in one way or another (e.g. due to @world). Do you have any ideas how to solve that kind of stalemate? One solution I have in mind (which is semi-ugly) is to re-enable all the implementations on argparse and print an explanatory message when it is merged with only 'new enough' implementations enabled. This will basically tell the users to investigate why dev-python/argparse is still pulled in on their systems. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Documenting touching of arch profiles' files
On Fri, Nov 02, 2012 at 12:47:34AM +1100, Michael Palimaka wrote: Hi all, With regards to bug #304435[1], we would like to formalise the policy for touching arch profiles' files. The key suggested points: Ok, this then clears the way for MySQL 5.5 to enter the tree. bug #351931: dev-util/systemtap, needs ~arm ~hppa ~ia64 ~sparc bug #429710: dev-util/google-perftools, needs ~alpha ~arm ~hppa ~ia64 ~ppc ~sparc bug #429708: dev-libs/jemalloc, needs ~alpha ~ia64 ~sparc I'm going to put the following masks in for the above: alpha: =dev-db/mysql-5.5 tcmalloc jemalloc =dev-db/mariadb-5.5 tcmalloc jemalloc arm: =dev-db/mysql-5.5 systemtap tcmalloc =dev-db/mariadb-5.5 systemtap tcmalloc hppa: =dev-db/mysql-5.5 systemtap tcmalloc =dev-db/mariadb-5.5 systemtap tcmalloc ia64: =dev-db/mysql-5.5 systemtap tcmalloc jemalloc =dev-db/mariadb-5.5 systemtap tcmalloc jemalloc ppc/ppc64: =dev-db/mysql-5.5 tcmalloc =dev-db/mariadb-5.5 tcmalloc sparc: =dev-db/mysql-5.5 systemtap tcmalloc jemalloc =dev-db/mariadb-5.5 systemtap tcmalloc jemalloc -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] Documenting touching of arch profiles' files
On 01/11/2012 16:47, Robin H. Johnson wrote: I'm going to put the following masks in for the above: If you're already doing the job would you mind just masking the use flag globally, and not just for mysql/mariadb? -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Documenting touching of arch profiles' files
On Thu, Nov 01, 2012 at 04:51:52PM -0700, Diego Elio Pettenò wrote: On 01/11/2012 16:47, Robin H. Johnson wrote: I'm going to put the following masks in for the above: If you're already doing the job would you mind just masking the use flag globally, and not just for mysql/mariadb? I did package.use.mask already, too late. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
[gentoo-dev] MySQL 5.5 releasing to ~arch
Hi all, I know it's been much awaited, but I didn't have a lot of faith in it previously, so I didn't want to destroy the systems of our ~arch users by releasing MySQL/MariaDB 5.5.x on them. However, as of today, I believe that it is sufficiently ready to be used on ~arch systems, and I will be updating the global package.mask to now only block MySQL 5.6. MySQL 5.6 does not pass it's own testsuite yet, so it'll be a while before it becomes more available. If you want it sooner, be sure to keep an eye on the mysql team overlay! I'd like to thank Jorge Manuel B. S. Vicetto (jmbsvicetto) and Brian Evans grkni...@lavabit.com for their tireless fighting with the ebuilds. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
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/
