Re: [gentoo-dev] [RFC] Dropping slotted boost
Am Dienstag, den 30.10.2012, 22:48 -0700 schrieb Diego Elio Pettenò: On 30/10/2012 22:44, Tiziano Müller wrote: I agree. It really doesn't make sense to keep unbuildable stuff in the tree. The point of slotting it in the first place was also to force a rebuild of reverse dependencies to have them use newer boost (since at that time when boost slotting was introduced we had some API breakages occurring between versions). Now with the sub-slots we can simply use this feature to tell the PM to rebuild the stuff. Well, as long as the soname is correct (which it is), with preserved-rebuild (which is now available on ~arch Portage as well), this is basically already possible to some extent without even using subslots. Each new minor version bump (1.49 - 1.50) will orphan the 1.49 libraries, @preserved-rebuild will rebuild the linked packages. Of course for those that don't link to the objects, but only use the headers, the sub-slots make it possible as well. Didn't have @preserved-rebuild back then and I don't really consider this a feature (but that's just a side note). One reason for the slotting was also to give people developing code on Gentoo the chance to easily have multiple versions of boost in parallel (for testing, etc.). This was also the main reason to introduce eselect-boost (besides making the transition to slotted boost easier .. a transition which never really happened since everyone kept relying on eselect-boost). But that too stems from a time when boost got a release once a year, so by now slotting is really just a burden. Question is: do we want to keep the versioned soname scheme (which doesn't make much sense without the slotting) or not. I would like to see it removed together with the slotting. Concerning the maintenance: I'd prefer herdcpp/herd and nothing else. The reason for this is that boost is tied to the development of C++ itself pretty closely and we want that people who take care of boost have enough knowledge about C++ itself.. and then: why not share your knowledge by taking care of some other C++ packages as well.
[gentoo-dev] Re: [RFC] Dropping slotted boost
Diego Elio Pettenò posted on Tue, 30 Oct 2012 17:45:27 -0700 as excerpted: On 30/10/2012 17:42, Duncan wrote: icu-49.1.2 seems to build just fine against glibc-2.16.0, here. I just rebuilt to be sure. (With gcc-4.7.2.) I said 1.50+, I'm referring to Boost. Thanks. Makes MUCH more sense when I have the right package (and version) in mind! =;^) (I had mixed them up before, but caught myself until now. This time I didn't. Thanks again.) -- 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: gentoo-x86/eclass: udev.eclass
On 30-10-2012 23:22:01 +0200, Samuli Suominen wrote: So exactly what is (your) problem with the current eclass now? Your eclass pretends to support Prefix, but it is broken in that respect, and because some other eclass does it the same way (your claim), you refuse to fix it. -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
Re: [gentoo-dev] Re: [RFC] Dropping slotted boost
On 31/10/12 03:03, Diego Elio Pettenò wrote: On 30/10/2012 17:49, Ryan Hill wrote: And I had to argue to get 1.48 fixed. I'm not sure why we have to keep so many unbuildable versions in the tree. Because as mgorny explained earlier he's expecting some fairy to make it possible to _always_ install an older boost just because it's slotted. Honestly, from what I can tell, Mike is doing, exactly like for ICU, a direct proxying of commits from a developer that has been explicitly kicked out by Gentoo, mgorny is in some fantasyland where the presence of an ebuild makes it possible to build it just because it's slotted (and his only commit is to add himself to metadata), Tiziano has been last seen dropping eselect boost in favour of ... nothing, and Sebastian Luther I have no word of in a long time. I'm pretty sure that if the package was moved to cpp, or toolchain, or whatever, is going to be better maintained by whatever is going on now even if it's just going to be re-active instead of pro-active. In the list of bugs for boost, most of the recently RESOLVED ones are NOT related to boost itself, but to the reverse dependencies — lots of them also seem to be due to =boost-1.50-r2 which is without eselect boost. Of the open ones, I'm pretty sure that a lot of them are obsolete such as bug #334659 dev-libs/boost is built as non-PIC on amd64, plus we got a number of trackers, ICEs, stabilization bugs still open, and so on so forth. I have unfortunately a few packages using it; so does Tomáš — KDE and MySQL depend on it as well. Is there somebody else interested in the package? We might just want to take this over and restore some sanity. [picked near random mail from this thread, as this seemed most suitable] We have been in this situation before where I've had to clean out old boost versions because the toolchain went forward as it should. 22 Apr 2010; Samuli Suominen ssuomi...@gentoo.org -boost-1.36.0-r1.ebuild: Remove boost-1.36.0 for gcc-porting wrt #287638. So all of this should come as no suprise to anyone. - Samuli
Re: [gentoo-dev] Re: gentoo-x86/eclass: udev.eclass
On 31/10/12 09:50, Fabian Groffen wrote: On 30-10-2012 23:22:01 +0200, Samuli Suominen wrote: So exactly what is (your) problem with the current eclass now? Your eclass pretends to support Prefix, but it is broken in that respect, and because some other eclass does it the same way (your claim), you refuse to fix it. I'm not refusing anything. I don't do prefix and I'm _always_ expecting a patch from prefix@ for prefix issues. Thanks for volunteering. I'll be looking forward in seeing the patch. - Samuli
Re: [gentoo-dev] Re: gentoo-x86/eclass: udev.eclass
On 31-10-2012 09:51:51 +0200, Samuli Suominen wrote: I don't do prefix and I'm _always_ expecting a patch from prefix@ for prefix issues. In that case, please don't invent prefix things yourself. Thanks. -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
[gentoo-dev] Merging the devrel handbook into the devmanual
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/
Re: [gentoo-dev] [warning] the bug queue has 100 bugs
Simply look at the metadata.xml files which can be found in each package directory. 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. Cheers, Dirkjan On Wed, Oct 31, 2012 at 1:34 PM, Marco Poletti poletti.ma...@gmail.com wrote: On mer 31 ott 2012 13:31:53 CET, Dirkjan Ochtman wrote: That's rather unsurprising... If you're going to file bugs in a semi-automated manner, might as well try to assign to the correct maintainer? Can you give me some help on how to do that? How can I find the maintainer of a package? Marco
Re: [gentoo-dev] [warning] the bug queue has 100 bugs
2012/10/31 Dirkjan Ochtman d...@gentoo.org: That's rather unsurprising... If you're going to file bugs in a semi-automated manner, might as well try to assign to the correct maintainer? Yep he should've assign them, but anyway the annoying elog messages are an issue. And quite few packages suffer from it :-) Tom
Re: [gentoo-dev] [warning] the bug queue has 100 bugs
On Wed, Oct 31, 2012 at 8:31 AM, Dirkjan Ochtman d...@gentoo.org wrote: If you're going to file bugs in a semi-automated manner, might as well try to assign to the correct maintainer? How about a policy - no automated bugs may be logged to the bug wranglers without their prior approval/review. I wouldn't think about running a script against somebody's bugzilla/repository/forum/whatever without some kind of prior communication with the administrators. This usually is considered abuse. Rich
Re: [gentoo-dev] [warning] the bug queue has 100 bugs
The php herd is the maintainer, so you should php-b...@gentoo.org (the herd-to-email mapping can probably be found elsewhere). Still, please get more of a feeling for how the Portage tree is put together before doing more automated bug filing, please. Cheers, Dirkjan On Wed, Oct 31, 2012 at 2:08 PM, Marco Poletti poletti.ma...@gmail.com wrote: On 31/10/2012 13:49, Dirkjan Ochtman wrote: Simply look at the metadata.xml files which can be found in each package directory. I don't find any maintainer email there... For example: ~ cat /usr/portage/dev-lang/php/metadata.xml ?xml version=1.0 encoding=UTF-8? !DOCTYPE pkgmetadata SYSTEM http://www.gentoo.org/dtd/metadata.dtd; pkgmetadata herdphp/herd use flag name='cli'Enable CLI SAPI/flag flag name='embed'Enable embed SAPI/flag flag name='enchant'Add supports Enchant spelling library./flag flag name='fileinfo'Add fileinfo extension support/flag flag name='filter'Add filter extension support/flag flag name='fpm'Enable the FastCGI Process Manager SAPI/flag flag name='gd'Adds support for gd (bundled with PHP)/flag flag name='hash'Enable the hash extension/flag flag name='json'Enable JSON support/flag flag name='ldap-sasl'Add SASL support for the PHP LDAP extension/flag flag name='mysqlnd'Use native driver for mysql, mysqli, PDO_Mysql/flag flag name='intl'Enables the intl extension for extended internalization support/flag flag name='pic'Force shared modules to build as PIC on x86 (speed tradeoff with memory usage)/flag flag name='pdo'Enable the bundled PDO extensions/flag flag name='phar'Enables the phar extension to provide phar archive support/flag flag name='suhosin'Add Suhosin support (patch and extension from http://www.suhosin.org/)/flag flag restrict=gt;=dev-lang/php-5.3.6_rc1 name='suhosin'Add the Suhosin patch from http://www.suhosin.org/)/flag flag name='sqlite2'Add sqlite2 support. Will be removed/flag flag name='xmlreader'Enable XMLReader support/flag flag name='xmlwriter'Enable XMLWriter support/flag flag name='zip'Enable ZIP file support/flag /use /pkgmetadata Marco
Re: [gentoo-dev] [warning] the bug queue has 100 bugs
Maybe you should remember that non-devs simply /aren't allowed/ to assign bugs correctly... And if you look closer into these bugs, you might discover that jer instructed this guy to file separate bugs. (see #440178) aranea signature.asc Description: PGP signature
[gentoo-dev] [PATCH distutils-r1 1/2] Explicitly set --build-lib for distutils.
Some of the packages want to access that directory (lxml for example),
and they have to do globbing to guess the suffix. Since we use
per-implementation build dirs anyway, let's just use a simple '/lib'
there.
I'm doing this for out-of-source builds only since we don't set
--build-base for in-source anyway. With in-source builds, we allow
setup.py to control the build locations. You can treat it as a safe
switch to disable our hackery for packages which are broken by it.
---
gx86/eclass/distutils-r1.eclass | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/gx86/eclass/distutils-r1.eclass b/gx86/eclass/distutils-r1.eclass
index 172cc70..3b86afd 100644
--- a/gx86/eclass/distutils-r1.eclass
+++ b/gx86/eclass/distutils-r1.eclass
@@ -151,7 +151,12 @@ esetup.py() {
die 'Out-of-source build requested, yet BUILD_DIR
unset.'
fi
- args+=( build --build-base ${BUILD_DIR} )
+ args+=(
+ build
+ --build-base ${BUILD_DIR}
+ # using a single directory for them helps us export
${PYTHONPATH}
+ --build-lib ${BUILD_DIR}/lib
+ )
fi
set -- ${PYTHON:-python} setup.py \
--
1.7.12.4
[gentoo-dev] [PATCH distutils-r1 2/2] Export PYTHONPATH=${BUILD_DIR}/lib for out-of-source builds.
This may help a few test suites and shouldn't hurt much of the others
(which weren't broken already).
Done only for out-of-source builds as that's where we control the build
directories.
---
gx86/eclass/distutils-r1.eclass | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/gx86/eclass/distutils-r1.eclass b/gx86/eclass/distutils-r1.eclass
index 3b86afd..d748621 100644
--- a/gx86/eclass/distutils-r1.eclass
+++ b/gx86/eclass/distutils-r1.eclass
@@ -331,12 +331,22 @@ distutils-r1_python_install_all() {
# @USAGE: [argv...]
# @INTERNAL
# @DESCRIPTION:
-# Run the given command in BUILD_DIR.
+# Run the given command.
+#
+# If out-of-source builds are used, the phase function is run in source
+# directory, with BUILD_DIR pointing at the build directory
+# and PYTHONPATH having an entry for the module build directory.
+#
+# If in-source builds are used, the command is executed in the BUILD_DIR
+# (the directory holding per-implementation copy of sources).
distutils-r1_run_phase() {
debug-print-function ${FUNCNAME} ${@}
if [[ ${DISTUTILS_IN_SOURCE_BUILD} ]]; then
pushd ${BUILD_DIR} /dev/null || die
+ else
+ local PYTHONPATH=${BUILD_DIR}/lib:${PYTHONPATH}
+ export PYTHONPATH
fi
${@} || die ${1} failed.
--
1.7.12.4
Re: [gentoo-dev] Merging the devrel handbook into the devmanual
31.10.2012 16:39, Michael Palimaka пишет: 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/ As a new developer , I think this is a good idea. When i was a recruit it was not so easy to find some information(well, at least for me). Now i am more familiar with Gentoo website internals and it's not a problem anymore(at least, generally :-)). I think recruiters would be also agreed with this point of view(at least hwoarang does :-D) -- Best regards, Sergey Popov Gentoo Linux Developer Desktop-effects project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] ship app-arch/pbzip2 instead of app-arch/bzip2
29.10.2012 18:39, Rich Freeman wrote: On Mon, Oct 29, 2012 at 10:13 AM, Rick Zero_Chaos Farina but would anyone be interested in blocking using lbzip2 by default? It seems pretty safe and I've done dozens of full system builds etc. Why not just make it an option to start, advertise it by all means, and then see how it turns out with volunteers before we make it the default. Going from nobody-has-heard-of-it to default overnight seems a bit much. +1 for that -- Best regards, Sergey Popov Gentoo Linux Developer Desktop-effects project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [warning] the bug queue has 100 bugs
On Wed, Oct 31, 2012 at 9:18 AM, li...@aixah.de wrote: Maybe you should remember that non-devs simply /aren't allowed/ to assign bugs correctly... And if you look closer into these bugs, you might discover that jer instructed this guy to file separate bugs. (see #440178) Fair points, and clearly this wasn't malicious. I think we still want to find a better solution than logging dozens of bugs for the wranglers. Perhaps where there is a need we can give elevated privs in bugzilla to those running scripts who understand what they're doing. Or non-devs could ask a dev to run the script for them after review. Rich
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: udev.eclass
On Tue, 30 Oct 2012 21:18:02 +0100 Michał Górny mgo...@gentoo.org wrote: [...] Don't even try to touch any of my eclasses without prior asking. A bit aggressive but its rather obvious that this is the norm not the exception, meaning the argument 'I do not want to diverge from $other eclass' is moot.
Re: [gentoo-dev] Re: gentoo-x86/eclass: udev.eclass
On Tue, 30 Oct 2012 23:22:01 +0200 Samuli Suominen ssuomi...@gentoo.org wrote: [...] One of the commits was before anything was said to ML (the EAPI change), the comment was later but the commenter didn't notice it just got fixed minutes before that. I didn't ignore anything, but pointed this thread and the comments to mgorny since the exact same EPREFIX code is in systemd.eclass too. If you think this is incorrect, I would expect prefix@ maintainers to provide a patch to correct it. That's why a review is usually useful... And as I already pointed out, i'll be reusing the internal function later on in the ebuild just like systemd.eclass does, like for example, $(udev_do_rules_d) function. Please show the code. As of now, the internal function is only obfuscating a bit the code. This is obviously another order of magnitude in terms of complexity but I do not want to have pyth... err udev-ng, udev-ng-r1, udev-r1 eclasses :) We discussed also the conversion from echo to printf and saw it unnecessary. Who is we? And why? I believe the -n to echo is not useful, so better drop it entirely instead of wrongly making people believe not having a newline matters.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: udev.eclass
On Wed, 31 Oct 2012 11:57:49 -0300 Alexis Ballier aball...@gentoo.org wrote: On Tue, 30 Oct 2012 21:18:02 +0100 Michał Górny mgo...@gentoo.org wrote: [...] Don't even try to touch any of my eclasses without prior asking. A bit aggressive but its rather obvious that this is the norm not the exception, meaning the argument 'I do not want to diverge from $other eclass' is moot. It's aggressive because Samuli has a history of touching (and sometimes breaking) other people's packages without even asking or pinging that he did that, and believing he's above all the rules here. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [warning] the bug queue has 100 bugs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/31/2012 08:52 AM, Tomáš Chvátal wrote: 2012/10/31 Dirkjan Ochtman d...@gentoo.org: That's rather unsurprising... If you're going to file bugs in a semi-automated manner, might as well try to assign to the correct maintainer? Yep he should've assign them, but anyway the annoying elog messages are an issue. And quite few packages suffer from it :-) Tom I disagree on most of them (and have marked the KDE-related bugs as WONTFIX appropriately). Messages that tell the user about config options, or for x functionality install y (at least until we get SDEPEND or something similar added to portage) should show up every time in my opinion. Only initial config and you just enabled (flag) really merits this. Basically, I would rather the user get too many elog messages than not enough, since I feel that a lot of people skip over them anyway and so the only display once method makes it far too easy for important messages to get lost in the shuffle. Chris Reffett -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCRQQAACgkQ23laikJhg1Q+aQCeLfXsAmbtXNGOcBzM/vJaMat2 ly0AoKFzB3tPLaSO2RK0p2rWd6CoKMXm =J+3S -END PGP SIGNATURE-
Re: [gentoo-dev] Merging the devrel handbook into the devmanual
On Wed, Oct 31, 2012 at 1:39 PM, Michael Palimaka kensing...@gentoo.org wrote: What do you think? +1 love it. The split is pretty annoying, it would be great to have everything in one place. Cheers, Dirkjan
[gentoo-dev] On the usefulness of eclass changelog
On Tue, 30 Oct 2012 18:39:44 -0600 Ryan Hill dirtye...@gentoo.org wrote: [...] The file is pointless if not everyone is using it. I've offered to remove the file before, and I'm reoffering to do so now. It's pointy enough for most uses. Let's keep it that way. I would like to know what are those uses. Here are my thoughts about changelogs: We have cvs logs, cvsweb, etc. So what is the value added from changelogs? Well, those logs are per-file as far as I know, and since a new version of a package means a new .ebuild file, keeping track of changes to packages is painful without a changelog which is global to the whole package. Even if we have all the needed information in the cvs log, changelogs for packages are definitely useful. Now for eclasses the situation is different: I want to know what has recently changed in foo.eclass, what is the fastest way? Search through a changelog file with dozens of absolutely unrelated information, or run cvs log/go to sources.gentoo.org ? I tend to do the latter and find eclass changelogs completely useless.
Re: [gentoo-dev] Merging the devrel handbook into the devmanual
On 31/10/2012 05:39, Michael Palimaka wrote: In bug #304435[1], hwoarang suggested merging the devrel handbook[2] into the devmanual[3]. +1 it was on my TODO list for over two years at this point. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] On the usefulness of eclass changelog
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 31/10/12 11:26 AM, Alexis Ballier wrote:
On Tue, 30 Oct 2012 18:39:44 -0600 Ryan Hill
dirtye...@gentoo.org wrote: [...]
The file is pointless if not everyone is using it. I've
offered to remove the file before, and I'm reoffering to do so
now.
It's pointy enough for most uses. Let's keep it that way.
I would like to know what are those uses. Here are my thoughts
about changelogs:
We have cvs logs, cvsweb, etc. So what is the value added from
changelogs? Well, those logs are per-file as far as I know, and
since a new version of a package means a new .ebuild file, keeping
track of changes to packages is painful without a changelog which
is global to the whole package. Even if we have all the needed
information in the cvs log, changelogs for packages are definitely
useful. Now for eclasses the situation is different: I want to
know what has recently changed in foo.eclass, what is the fastest
way? Search through a changelog file with dozens of absolutely
unrelated information, or run cvs log/go to sources.gentoo.org ? I
tend to do the latter and find eclass changelogs completely
useless.
Cool, you do, that's great. This doesn't mean others don't use a
different process tho, and since it *IS* there and is *SUPPOSED* to be
filled, and it really doesn't hurt to run 'echangelog ${msg} cvs
ci -m ${msg}' , why not do it?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
iF4EAREIAAYFAlCRRU0ACgkQ2ugaI38ACPCobwD+LZvXFPyfsGZ+484wnkv6fk8L
oBazGyjti3n2nNAkM8IA/A5IvVNyOnd6U9lVH1B2dRA2HB1+i8Hac1aAKvs/EPF1
=F5eR
-END PGP SIGNATURE-
Re: [gentoo-dev] On the usefulness of eclass changelog
On Wed, 31 Oct 2012 11:35:41 -0400
Ian Stakenvicius a...@gentoo.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 31/10/12 11:26 AM, Alexis Ballier wrote:
On Tue, 30 Oct 2012 18:39:44 -0600 Ryan Hill
dirtye...@gentoo.org wrote: [...]
The file is pointless if not everyone is using it. I've
offered to remove the file before, and I'm reoffering to do so
now.
It's pointy enough for most uses. Let's keep it that way.
I would like to know what are those uses. Here are my thoughts
about changelogs:
We have cvs logs, cvsweb, etc. So what is the value added from
changelogs? Well, those logs are per-file as far as I know, and
since a new version of a package means a new .ebuild file, keeping
track of changes to packages is painful without a changelog which
is global to the whole package. Even if we have all the needed
information in the cvs log, changelogs for packages are definitely
useful. Now for eclasses the situation is different: I want to
know what has recently changed in foo.eclass, what is the fastest
way? Search through a changelog file with dozens of absolutely
unrelated information, or run cvs log/go to sources.gentoo.org ? I
tend to do the latter and find eclass changelogs completely
useless.
Cool, you do, that's great. This doesn't mean others don't use a
different process tho, and since it *IS* there and is *SUPPOSED* to be
filled, and it really doesn't hurt to run 'echangelog ${msg} cvs
ci -m ${msg}' , why not do it?
so that others are not encouraged to work sub-optimally :)
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: udev.eclass
On 31/10/12 17:09, Michał Górny wrote: On Wed, 31 Oct 2012 11:57:49 -0300 Alexis Ballier aball...@gentoo.org wrote: On Tue, 30 Oct 2012 21:18:02 +0100 Michał Górny mgo...@gentoo.org wrote: [...] Don't even try to touch any of my eclasses without prior asking. A bit aggressive but its rather obvious that this is the norm not the exception, meaning the argument 'I do not want to diverge from $other eclass' is moot. It's aggressive because Samuli has a history of touching (and sometimes breaking) other people's packages without even asking or pinging that he did that, and believing he's above all the rules here. You don't know me clearly, that's definately the opposite of what I'm doing and intending to do, walking the fine line and bothering people only when something real changes... Breaking? Hardly, since I never commit untested code, and the exceptions I've fixed myself usually very quickly as I'm watching incoming bugs, forums, and more I'm being cooperative with you and keeping udev.eclass with systemd.eclass sort of 'in sync' due to the nature of both packages being from the same tarball. What more do you want? Seriously.
Re: [gentoo-dev] [warning] the bug queue has 100 bugs
On Wed, 31 Oct 2012 13:49:37 +0100 Dirkjan Ochtman d...@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? jer
Re: [gentoo-dev] [warning] the bug queue has 100 bugs
On 10/31/2012 10:05 AM, Rich Freeman wrote: On Wed, Oct 31, 2012 at 9:18 AM, li...@aixah.de wrote: Maybe you should remember that non-devs simply /aren't allowed/ to assign bugs correctly... And if you look closer into these bugs, you might discover that jer instructed this guy to file separate bugs. (see #440178) Fair points, and clearly this wasn't malicious. I think we still want to find a better solution than logging dozens of bugs for the wranglers. Perhaps where there is a need we can give elevated privs in bugzilla to those running scripts who understand what they're doing. Or non-devs could ask a dev to run the script for them after review. This would be nice anyway. I'm generally capable of reading metadata.xml and determining whether or not to tag my bugs with e.g. STABLEREQ. One less bug to wrangle.
Re: [gentoo-dev] Re: gentoo-x86/eclass: udev.eclass
On 31/10/12 10:56, Fabian Groffen wrote: On 31-10-2012 09:51:51 +0200, Samuli Suominen wrote: I don't do prefix and I'm _always_ expecting a patch from prefix@ for prefix issues. In that case, please don't invent prefix things yourself. Thanks. Thank you for reviewing the eclass. The prefix code has been dropped from the eclass as requested. - Samuli
Re: [gentoo-dev] On the usefulness of eclass changelog
On 31/10/12 17:39, Alexis Ballier wrote:
On Wed, 31 Oct 2012 11:35:41 -0400
Ian Stakenvicius a...@gentoo.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 31/10/12 11:26 AM, Alexis Ballier wrote:
On Tue, 30 Oct 2012 18:39:44 -0600 Ryan Hill
dirtye...@gentoo.org wrote: [...]
The file is pointless if not everyone is using it. I've
offered to remove the file before, and I'm reoffering to do so
now.
It's pointy enough for most uses. Let's keep it that way.
I would like to know what are those uses. Here are my thoughts
about changelogs:
We have cvs logs, cvsweb, etc. So what is the value added from
changelogs? Well, those logs are per-file as far as I know, and
since a new version of a package means a new .ebuild file, keeping
track of changes to packages is painful without a changelog which
is global to the whole package. Even if we have all the needed
information in the cvs log, changelogs for packages are definitely
useful. Now for eclasses the situation is different: I want to
know what has recently changed in foo.eclass, what is the fastest
way? Search through a changelog file with dozens of absolutely
unrelated information, or run cvs log/go to sources.gentoo.org ? I
tend to do the latter and find eclass changelogs completely
useless.
Cool, you do, that's great. This doesn't mean others don't use a
different process tho, and since it *IS* there and is *SUPPOSED* to be
filled, and it really doesn't hurt to run 'echangelog ${msg} cvs
ci -m ${msg}' , why not do it?
so that others are not encouraged to work sub-optimally :)
eclass/ handling should go to repoman and the automated ChangeLog
process, should be rather straight forward for knowing person.
Re: [gentoo-dev] Re: gentoo-x86/eclass: udev.eclass
Le mercredi 31 octobre 2012 à 18:08 +0200, Samuli Suominen a écrit : On 31/10/12 10:56, Fabian Groffen wrote: On 31-10-2012 09:51:51 +0200, Samuli Suominen wrote: I don't do prefix and I'm _always_ expecting a patch from prefix@ for prefix issues. In that case, please don't invent prefix things yourself. Thanks. Thank you for reviewing the eclass. The prefix code has been dropped from the eclass as requested. - Samuli This thread really looks like kindergarten. I do not have enough popcorn the enjoy it truly though so please stop and act in a constructive way like actually sending the eclass for review (again if you will). -- Gilles Dartiguelongue e...@gentoo.org Gentoo
Re: [gentoo-dev] Re: gentoo-x86/eclass: udev.eclass
On 31/10/12 17:04, Alexis Ballier wrote: On Tue, 30 Oct 2012 23:22:01 +0200 Samuli Suominen ssuomi...@gentoo.org wrote: [...] One of the commits was before anything was said to ML (the EAPI change), the comment was later but the commenter didn't notice it just got fixed minutes before that. I didn't ignore anything, but pointed this thread and the comments to mgorny since the exact same EPREFIX code is in systemd.eclass too. If you think this is incorrect, I would expect prefix@ maintainers to provide a patch to correct it. That's why a review is usually useful... And as I already pointed out, i'll be reusing the internal function later on in the ebuild just like systemd.eclass does, like for example, $(udev_do_rules_d) function. Please show the code. As of now, the internal function is only obfuscating a bit the code. This is obviously another order of magnitude in terms of complexity but I do not want to have pyth... err udev-ng, udev-ng-r1, udev-r1 eclasses :) We discussed also the conversion from echo to printf and saw it unnecessary. Who is we? And why? I believe the -n to echo is not useful, so better drop it entirely instead of wrongly making people believe not having a newline matters. Was talking with the systemd/systemd.eclass maintainer in IRC. The -n was dropped as a conclusion of the discussion from both eclasses.
Re: [gentoo-dev] On the usefulness of eclass changelog
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 31/10/12 12:15 PM, Samuli Suominen wrote:
On 31/10/12 17:39, Alexis Ballier wrote:
On Wed, 31 Oct 2012 11:35:41 -0400 Ian Stakenvicius
a...@gentoo.org wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256
On 31/10/12 11:26 AM, Alexis Ballier wrote:
On Tue, 30 Oct 2012 18:39:44 -0600 Ryan Hill
dirtye...@gentoo.org wrote: [...]
The file is pointless if not everyone is using it. I've
offered to remove the file before, and I'm reoffering to
do so now.
It's pointy enough for most uses. Let's keep it that way.
I would like to know what are those uses. Here are my
thoughts about changelogs:
We have cvs logs, cvsweb, etc. So what is the value added
from changelogs? Well, those logs are per-file as far as I
know, and since a new version of a package means a new
.ebuild file, keeping track of changes to packages is painful
without a changelog which is global to the whole package.
Even if we have all the needed information in the cvs log,
changelogs for packages are definitely useful. Now for
eclasses the situation is different: I want to know what has
recently changed in foo.eclass, what is the fastest way?
Search through a changelog file with dozens of absolutely
unrelated information, or run cvs log/go to
sources.gentoo.org ? I tend to do the latter and find eclass
changelogs completely useless.
Cool, you do, that's great. This doesn't mean others don't use
a different process tho, and since it *IS* there and is
*SUPPOSED* to be filled, and it really doesn't hurt to run
'echangelog ${msg} cvs ci -m ${msg}' , why not do it?
so that others are not encouraged to work sub-optimally :)
eclass/ handling should go to repoman and the automated ChangeLog
process, should be rather straight forward for knowing person.
I agree, that'd make the whole thing easier. But until repoman can
commit in eclass/ it shouldn't be that hard to just run echangelog ,
as inefficient as that may be. :)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
iF4EAREIAAYFAlCRUSYACgkQ2ugaI38ACPAr7AD/ZlbMpcMm2/654o2EroXgpblD
E+g+9ARBZxqxxDLlklQA/ivTUWlSGBXufWe/qQfzpRBvm+ms+cpCys6IMe3N7S4e
=pwjP
-END PGP SIGNATURE-
Re: [gentoo-dev] Merging the devrel handbook into the devmanual
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
Re: [gentoo-dev] On the usefulness of eclass changelog
On Wed, 31 Oct 2012 12:26:14 -0400
Ian Stakenvicius a...@gentoo.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 31/10/12 12:15 PM, Samuli Suominen wrote:
On 31/10/12 17:39, Alexis Ballier wrote:
On Wed, 31 Oct 2012 11:35:41 -0400 Ian Stakenvicius
a...@gentoo.org wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256
On 31/10/12 11:26 AM, Alexis Ballier wrote:
On Tue, 30 Oct 2012 18:39:44 -0600 Ryan Hill
dirtye...@gentoo.org wrote: [...]
The file is pointless if not everyone is using it. I've
offered to remove the file before, and I'm reoffering to
do so now.
It's pointy enough for most uses. Let's keep it that way.
I would like to know what are those uses. Here are my
thoughts about changelogs:
We have cvs logs, cvsweb, etc. So what is the value added
from changelogs? Well, those logs are per-file as far as I
know, and since a new version of a package means a new
.ebuild file, keeping track of changes to packages is painful
without a changelog which is global to the whole package.
Even if we have all the needed information in the cvs log,
changelogs for packages are definitely useful. Now for
eclasses the situation is different: I want to know what has
recently changed in foo.eclass, what is the fastest way?
Search through a changelog file with dozens of absolutely
unrelated information, or run cvs log/go to
sources.gentoo.org ? I tend to do the latter and find eclass
changelogs completely useless.
Cool, you do, that's great. This doesn't mean others don't use
a different process tho, and since it *IS* there and is
*SUPPOSED* to be filled, and it really doesn't hurt to run
'echangelog ${msg} cvs ci -m ${msg}' , why not do it?
so that others are not encouraged to work sub-optimally :)
eclass/ handling should go to repoman and the automated ChangeLog
process, should be rather straight forward for knowing person.
I agree, that'd make the whole thing easier. But until repoman can
commit in eclass/ it shouldn't be that hard to just run echangelog ,
as inefficient as that may be. :)
Don't get me wrong: thats not running echangelog that is inefficient,
trying to get information from the changelog is. A per-eclass changelog
would be much more useful, as, atm, you'd be able to access the
information without internet connection.
I have yet to see a case where a global eclass changelog is more
efficient and/or convenient.
Re: [gentoo-dev] On the usefulness of eclass changelog
On Wed, 31 Oct 2012 12:26:14 -0400 Ian Stakenvicius a...@gentoo.org wrote: I agree, that'd make the whole thing easier. But until repoman can commit in eclass/ it shouldn't be that hard to just run echangelog , as inefficient as that may be. :) https://bugs.gentoo.org/show_bug.cgi?id=390651 jer
Re: [gentoo-dev] On the usefulness of eclass changelog
On Wed, Oct 31, 2012 at 12:15 PM, Samuli Suominen ssuomi...@gentoo.org wrote: eclass/ handling should go to repoman and the automated ChangeLog process, should be rather straight forward for knowing person. Perhaps, but right now the policy is to update it, so do it. The policy is also to post eclass changes for review on -dev, so do that too. That means do it BEFORE you commit it. I don't care if you post it raw, or post a link to a file, or post a link to a proposed commit on your private little git branch, but don't commit it and then send out a link to the commit in production after the fact. This whole double-thread is ridiculous. If somebody at work deliberately violated a dumb policy and pointed out it was dumb, the answer would be, thanks, we'll look into changing the dumb policy, now pack up your desk to make room for the new employee who can benefit from the improved policy. If you don't like the rules feel free to whine, beg, and plead to QA, the council, $DIETY, or your mother, but follow the rules until they're changed. There is always room for mistakes, but big projects don't work when everybody just does whatever they feel like doing. Rich
Re: [gentoo-dev] On the usefulness of eclass changelog
On 31/10/12 20:17, Rich Freeman wrote: On Wed, Oct 31, 2012 at 12:15 PM, Samuli Suominen ssuomi...@gentoo.org wrote: eclass/ handling should go to repoman and the automated ChangeLog process, should be rather straight forward for knowing person. Perhaps, but right now the policy is to update it, so do it. The policy is also to post eclass changes for review on -dev, so do that too. That means do it BEFORE you commit it. I don't care if you post it raw, or post a link to a file, or post a link to a proposed commit on your private little git branch, but don't commit it and then send out a link to the commit in production after the fact. This whole double-thread is ridiculous. If somebody at work deliberately violated a dumb policy and pointed out it was dumb, the answer would be, thanks, we'll look into changing the dumb policy, now pack up your desk to make room for the new employee who can benefit from the improved policy. If you don't like the rules feel free to whine, beg, and plead to QA, the council, $DIETY, or your mother, but follow the rules until they're changed. There is always room for mistakes, but big projects don't work when everybody just does whatever they feel like doing. I'd expect the file to be zeroed out after the repoman has been fixed to cover eclass/ as inconsistent ChangeLog equals useless ChangeLog And indeed this is ridicilous as the claims of not following rules has not been even broken. The eclass was sent to ML months ago already, and the conserns from back then have been counted in already for: http://gentoo.2317880.n4.nabble.com/rfc-udev-rules-eclass-td45792.html How many times are you required to do that before pushing it in? Last minute changes were made, yes, but this is no new news that it was coming in. - Samuli
[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-r2.e
On Wed, 31 Oct 2012 16:32:25 + (UTC) Diego Petteno (flameeyes) flamee...@gentoo.org wrote: flameeyes12/10/31 16:32:25 Modified: boost-1.46.1-r1.ebuild metadata.xml boost-1.49.0-r1.ebuild ChangeLog Added:boost-1.51.0-r1.ebuild Removed: boost-1.47.0.ebuild boost-1.35.0-r2.ebuild boost-1.47.0-r1.ebuild boost-1.39.0.ebuild boost-1.50.0-r2.ebuild boost-1.42.0-r1.ebuild boost-1.51.0.ebuild boost-1.37.0-r1.ebuild boost-1.42.0-r2.ebuild boost-1.50.0.ebuild boost-1.48.0-r2.ebuild boost-1.42.0.ebuild boost-1.35.0-r5.ebuild boost-1.41.0-r3.ebuild boost-1.45.0.ebuild Log: Unslotting. This removes a bunch of older packages that will not build on modern systems, keeps only three versions (stable, mostly-stable and masked). The new 1.51.0-r1 is designed so that it does not have to do any eselect or eselect-like trickery for the symlinks, also drops the tests (which are not working as expected anyway). (Portage version: 2.2.0_alpha141/cvs/Linux x86_64, signed Manifest commit with key 1CD13C8AD4301342) What is this policy of performing widespread destructive changes while: a) you haven't pinged any of the maintainers of the package nor waited for their reply, b) you have ignored output from one of the maintainers of the package, c) you have committed changes *1 day* after submitting RFC to the ml, effectively ignoring output of people who do not read the ml daily, d) you have dropped maintainers from the package without asking, e) you haven't given our users or overlays any ability of testing them, f) you have introduced destructive changes to stable systems, g) and after all, you aren't even maintainer of this package nor member of the cpp herd. 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. -- Best regards, Michał Górny signature.asc Description: PGP signature
[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-r2.e
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 this is destructive, everything that has been done with boost up to this point is apocalyptic. 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). 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. (And yes, I haven't tested it _thoroughly_ unfortunately, because of the stupid testsuite that goes nowhere and so on ... but I made sure that an update on a stable system does not change links to libraries and headers, and now I'm running tinderboxing for both ~arch, masked and stable.) -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
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: +1 and btw move the devmanual in the wiki :D That would rather go against the original idea behind the devmanual, which was that it was supposed to be high quality and authoritative. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [warning] the bug queue has 100 bugs
On Wed, Oct 31, 2012 at 02:18:42pm +0100, li...@aixah.de wrote: maybe you should remember that non-devs simply /aren't allowed/ to assign bugs correctly... That is not correct. I am no dev and i do have edit-bugs privileges. They were given to me on request by a developer from a project i am contributing to. However, that developer *has to* review any change I do, as he/she is responsible for my mistakes. The other way is to join the bug-wranglers project if you are willing to help: http://www.gentoo.org/proj/en/qa/bug-wranglers/index.xml#doc_chap4 -- Cyprien Nicolas (fulax) Gentoo Lisp Project contrib pgpYnoZSLPKmv.pgp Description: PGP signature
Re: [gentoo-dev] Merging the devrel handbook into the devmanual
On Wed, Oct 31, 2012 at 3:02 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Wed, 31 Oct 2012 17:26:38 +0100 Theo Chatzimichos tampak...@gentoo.org wrote: +1 and btw move the devmanual in the wiki :D That would rather go against the original idea behind the devmanual, which was that it was supposed to be high quality and authoritative. Pages can be locked to be editable only by members of blessed groups. -- :wq
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: udev.eclass
On Wed, Oct 31, 2012 at 3:36 PM, Samuli Suominen ssuomi...@gentoo.org wrote: On 31/10/12 17:09, Michał Górny wrote: On Wed, 31 Oct 2012 11:57:49 -0300 Alexis Ballier aball...@gentoo.org wrote: On Tue, 30 Oct 2012 21:18:02 +0100 Michał Górny mgo...@gentoo.org wrote: [...] Don't even try to touch any of my eclasses without prior asking. A bit aggressive but its rather obvious that this is the norm not the exception, meaning the argument 'I do not want to diverge from $other eclass' is moot. It's aggressive because Samuli has a history of touching (and sometimes breaking) other people's packages without even asking or pinging that he did that, and believing he's above all the rules here. You don't know me clearly, that's definately the opposite of what I'm doing and intending to do, walking the fine line and bothering people only when something real changes... Breaking? Hardly, since I never commit untested code, and the exceptions I've fixed myself usually very quickly as I'm watching incoming bugs, forums, and more I'm being cooperative with you and keeping udev.eclass with systemd.eclass sort of 'in sync' due to the nature of both packages being from the same tarball. What more do you want? Seriously. Please stop _NOW_. The thread is about the eclass review. Either comment on that or go flame somewhere else. Did he break your eclass this time or is this a preemptive complain just in case he does in the future? -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
Re: [gentoo-dev] Merging the devrel handbook into the devmanual
On Wed, Oct 31, 2012 at 7:02 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Wed, 31 Oct 2012 17:26:38 +0100 Theo Chatzimichos tampak...@gentoo.org wrote: +1 and btw move the devmanual in the wiki :D That would rather go against the original idea behind the devmanual, which was that it was supposed to be high quality and authoritative. -- Ciaran McCreesh Yes, I see no point moving it to wiki. We want to move it to a more modern format and we want to keep it in VCS so others can send pull requests, submit nice patches or have separate branches if needed. -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
[gentoo-dev] Last rites: x11-apps/grandr
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 # Chí-Thanh Christopher Nguyễn chith...@gentoo.org (31 Oct 2012) # Build and runtime issues, bugs #340883, #369385, #435444. # If you require a graphical monitor configuration tool and your desktop # environment doesn't provide any, try x11-misc/arandr or lxde-base/lxrandr # Masked for removal in 30 days. x11-apps/grandr -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCRpkUACgkQ+gvH2voEPRB7/QCfdP2Kki7H/OSu5OYKUneG7T8r zFMAn2VPWA0gwpm0mrqFEcA3SFyf8k5A =dagW -END PGP SIGNATURE-
Re: [gentoo-dev] [warning] the bug queue has 100 bugs
Quoting Chris Reffett (2012-10-31 16:17:20)
Yep he should've assign them, but anyway the annoying elog messages
are an issue. And quite few packages suffer from it :-)
It would actually be hard to find useful message which place is in elog
showing up every install. Why not move such thing on Wiki for example?
I disagree on most of them (and have marked the KDE-related bugs as
WONTFIX appropriately). Messages that tell the user about config
options,
...are *really* annoying, especially when you read it 100th time and
especially the one from kdelibs: Your homedir is set to
\${HOME}/.kde4.
or for x functionality install y (at least until we get
SDEPEND or something similar added to portage) should show up every
time in my opinion.
elog message for optional dependencies could be unified if must be
shown every time.
Only initial config and you just enabled (flag) really merits this.
Basically, I would rather the user get too many elog messages than not
If you assume that users time have no value and we can flood them with
meaningless messages.
enough, since I feel that a lot of people skip over them anyway and so
the only display once method makes it far too easy for important
messages to get lost in the shuffle.
If user gets hundreds of such useless messages it is almost sure that
he/she will miss few hidden important messages. The example could be
udev long elog message which ONE time has had hidden very important
message which I have unfortunately missed and ended up with unbootable
system. In current form these messages have no use.
I have already highlighted this problem on mailing list:
Subject: [gentoo-dev] Useless messages (elog, ewarn, etc) in ebuilds
Id: 20120821132457.4319.78667@localhost
--
Amadeusz Żołnowski
signature.asc
Description: signature
[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
Re: [gentoo-dev] [warning] the bug queue has 100 bugs
On Wed, Oct 31, 2012 at 5:54 AM, Rich Freeman ri...@gentoo.org wrote: On Wed, Oct 31, 2012 at 8:31 AM, Dirkjan Ochtman d...@gentoo.org wrote: If you're going to file bugs in a semi-automated manner, might as well try to assign to the correct maintainer? How about a policy - no automated bugs may be logged to the bug wranglers without their prior approval/review. I wouldn't think about running a script against somebody's bugzilla/repository/forum/whatever without some kind of prior communication with the administrators. This usually is considered abuse. Rich Bugzilla has a supported scripting API (via XMLRPC), and infra supports people using it, so from our POV this is legitimate. -A
