[gentoo-dev] m68k, s390, sh: ACCEPT_KEYWORDS="${ARCH} ~${ARCH}"

[Andreas K. Huettel]

The m68k, s390, sh profiles have been modified to set 
ACCEPT_KEYWORDS="${ARCH} ~${ARCH}"

Feel free to replace stable keywords by testing/unstable keywords on these 
arches.

Cheers, 
Andreas

-- 
Andreas K. Huettel
Gentoo Linux developer (council, kde)
dilfri...@gentoo.org
http://www.akhuettel.de/


signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] Last rites: python-distutils-ng.eclass

[Michał Górny]

# Michał Górny  (29 Sep 2013)
# This eclass has been superseded by distutils-r1 and python-r1 eclasses
# and will be removed on 2013-10-29. Please modify your ebuilds to use
# the new eclasses instead. Bug #450770.

python-distutils-ng.eclass

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

[gentoo-dev] [PATCH] gst-plugins10.eclass: fix support for 1.2 series

[Gilles Dartiguelongue]

Hi all,

here is a little patch to gst-plugins10.eclass fixing SLOT definition
for the new 1.2 release. Per upstream release mail, 1.* will remain
API/ABI compatible.

-- 
Gilles Dartiguelongue 
Gentoo
Index: gst-plugins10.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/gst-plugins10.eclass,v
retrieving revision 1.10
diff -u -B -r1.10 gst-plugins10.eclass
--- gst-plugins10.eclass	31 Jan 2013 19:59:54 -	1.10
+++ gst-plugins10.eclass	29 Sep 2013 14:50:58 -
@@ -102,7 +102,11 @@
 SRC_URI="http://gstreamer.freedesktop.org/src/${GST_ORG_MODULE}/${GST_ORG_MODULE}-${PV}.tar.${GST_TARBALL_SUFFIX}";
 
 LICENSE="GPL-2"
-SLOT="${GST_ORG_PVP}"
+case ${GST_ORG_PVP} in
+	0.10) SLOT="0.10" ;;
+	1.*) SLOT="1.0" ;;
+	*) die "Unkown gstreamer release."
+esac
 
 S="${WORKDIR}/${GST_ORG_MODULE}-${PV}"
 

Re: [gentoo-dev] Gentoo Upgrade Guide and EAPI

[Luca Barbato]

On 29/09/13 04:12, hero...@gentoo.org wrote:
> It's just a starting point, though. I still don't have a clear plan yet.
> 
> After reading carefully the thread Ulrich pointed out, it seems that
> refactoring ebuild/eclass is invevitable, which calls for an overlay to
> carry it on.

That would be much welcome, having new people in toolchain and trying to
get new useful stuff done while we aren't breaking our users (hint, some
people are already sad for the /usr thing) seems a good idea.

lu - still too busy with stuff...

Re: [gentoo-dev] Re: [RFC] Policy for migrating library consumers to subslots

[Kent Fredric]

On 29 September 2013 11:13, Martin Vaeth
wrote:

>
> > The best solution I presently have for this problem, would be to have
> > a PROVIDES-${PV}.json file in every package under files/
>
> Not under files but in the eclass, and the rest of the
> work is done by the perl-dep function.


The reason I suggested that approach, is because a list of modules and
versions that are contained within a specific version of a specific
package, is ostensibly a property of that version of that package.

And thus, with it in ${FILESDIR}, updating $P to a new $V makes it easy to
check for the existence of a respective ${FILESDIR}/PROVIDES-{$PV}.json

And thus, the technique can be used, not only for all of dev-lang/perl, but
for all of perl-core/* , and possibly even dev-perl/* , and maybe even
things outside these categories that happen to be providers of perl modules.

Then, the relative content in the eclass/  tree could be generated from
that data, and generated in the inverse form, allowing $(perl-dep "some
string here")  to have a unique mapping for all values of those strings, in
a form that was easy to decode and understand.

Thus, the conditionality of the dependency would not have to be determined
by messy bash code during the parsing of each and every ebuild, and would
instead be a relatively simple lookup table.

This moves all the overhead complexity from being something that only
happens in the developer side of things, reducing the number of ways the
eclass can fail.

And then we can also debate the qualities of specific ways of declaring the
dependency itself post-eclass, as it becomes a separate problem from how
the resolution is performed.

-- 
Kent

[gentoo-dev] stabilizing libraries without testing reverse deps

[hasufell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

It seems this happens more frequently these days, so I'd like to
remind people to check stable reverse deps before stabilizing a
library, especially when this is a non-maintainer stablereq.

Arch teams do not test them, so this is the business of the maintainer
or the dev who requested stabilization.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSSJ5vAAoJEFpvPKfnPDWz9IAH/iFs7a87ylffzSBALk7FqmPw
voO1ubXaneNsjAGErZpj2XZlmZHuWHGrbPbvJllHKoKTWcXV1hUwYMYgUWwEF8Th
Ypco+MM/kAlcaB8vPVOjV+k3h3ogqcz7xUhkl9qShMgyKJrLS4gwlXavEpFQi0Mq
u/uqIwW2XN8tfrPCbB/FG4A6GqggIDb6ce9UCCjyYuqF3IUOKlj2LMz1SMBI7/ZQ
fVLrk9DqYzgns5Q0cQmCN+Fk+/2ypBdhybLNCpUD0HfhP8U05S5Cp1VEN9XOczDs
EAM/3pXRG6rZZspQmFIPjiTiQMFvxlF1kexpp1QQ/mqiWfRbjU4j7hHkc4//npE=
=w1hs
-END PGP SIGNATURE-

Re: [gentoo-dev] stabilizing libraries without testing reverse deps

[Paweł Hajdan, Jr.]

On 9/29/13 2:41 PM, hasufell wrote:
> It seems this happens more frequently these days, so I'd like to
> remind people to check stable reverse deps before stabilizing a
> library, especially when this is a non-maintainer stablereq.

+1 to the reminder. It would be great to hear about specific examples of
problems happening more frequently recently. FWIW I didn't notice such
tendency, but that doesn't mean it's not happening.

> Arch teams do not test them, so this is the business of the maintainer
> or the dev who requested stabilization.

This is new to me.

Do you have anything official to point to so that you could back your claim?

See e.g.
:
"If the package is a library, emerge a couple of packages that use the
library to ensure they still work with the new version (best option: all
that depend on it and have a stable version)."

I also created a tool
()
to assist arch teams in testing reverse dependencies.

As far as I know the person opening the bug does not guarantee anything.
Furthermore, the bugs I've filed using an automated tool explicitly ask
for maintainer's opinion before adding arches. They are only filed for
packages with no open bugs by the way. The person stabilizing the
package is ultimately responsible for breakages - otherwise why would we
have dedicated arch teams instead of letting anyone stabilize anything?

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] stabilizing libraries without testing reverse deps

[Thomas Kahle]

On 09/29/2013 11:41 PM, hasufell wrote:
> It seems this happens more frequently these days, so I'd like to
> remind people to check stable reverse deps before stabilizing a
> library, especially when this is a non-maintainer stablereq.
> 
> Arch teams do not test them, so this is the business of the maintainer
> or the dev who requested stabilization.

Huh.  This must be new.  When I was still arch-testing, reverse deps
were checked.  app-portage/tatt (which is sort of maintainer-needed now)
has support for these tests too.

Cheers,
Thomas

-- 
Thomas Kahle



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] stabilizing libraries without testing reverse deps

[Andreas K. Huettel]

Am Sonntag, 29. September 2013, 23:41:03 schrieb hasufell:
> It seems this happens more frequently these days, so I'd like to
> remind people to check stable reverse deps before stabilizing a
> library, especially when this is a non-maintainer stablereq.
> 
> Arch teams do not test them, so this is the business of the maintainer
> or the dev who requested stabilization.

Arch testing includes testing of reverse deps. 
If that's not the case, arch teams are not doing their job.

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfri...@gentoo.org
http://www.akhuettel.de/

Re: [gentoo-dev] stabilizing libraries without testing reverse deps

[hasufell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/30/2013 12:54 AM, Andreas K. Huettel wrote:
> Am Sonntag, 29. September 2013, 23:41:03 schrieb hasufell:
>> It seems this happens more frequently these days, so I'd like to 
>> remind people to check stable reverse deps before stabilizing a 
>> library, especially when this is a non-maintainer stablereq.
>> 
>> Arch teams do not test them, so this is the business of the
>> maintainer or the dev who requested stabilization.
> 
> Arch testing includes testing of reverse deps. If that's not the
> case, arch teams are not doing their job.
> 

I'd have to search the irc logs, but afair I was told so by ago.

CCing him if I am wrong.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSSMJoAAoJEFpvPKfnPDWzKM0IAJE9RHUsSJKS9owZbuAdfvPh
3SSQDmXOP3WqG71Q0tLh0kYLH5IkSBktqypEgIBTyXbEiak8BH9tyR9xCSi6sEtb
toId4i9xCPZuHc5nLl6Yllc4uHQpkHziRGChESxWrGUv/+BVfrs9DhYA17yy3JYc
R1QGANf82v4hH85zsN9ITbJK07YkEzOsdBTbKZpxMeku6+X70KWMe51TImXDhOup
fVNTL5uss5BhHpbhVB4PInlTpSTBGUVbiNQRmdmxs+oj/IKfOQZZaWa4ax1d7gmI
hDunq5ZjsetaU3o7bDLzantSyLEX5fMYbOrZA/HTAKSX6jLDykmLRkrov39/E8M=
=RK65
-END PGP SIGNATURE-

[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2013-09-29 23h59 UTC

[Robin H. Johnson]

The attached list notes all of the packages that were added or removed
from the tree, for the week ending 2013-09-29 23h59 UTC.

Removals:

Additions:
dev-lang/fsharp 2013-09-24 12:22:10 cynede
net-wireless/mfoc   2013-09-24 15:24:26 mrueg
dev-java/kryo   2013-09-24 17:26:41 ercpe
app-emulation/docker2013-09-25 03:22:15 gregkh
dev-java/guice  2013-09-25 17:20:14 ercpe
dev-java/jsoup  2013-09-25 17:36:28 ercpe
dev-java/classmate  2013-09-25 17:40:20 ercpe
dev-python/oslo-sphinx  2013-09-26 00:37:33 
prometheanfire
app-vim/tcomment2013-09-26 07:56:34 
radhermit
app-vim/recover 2013-09-26 08:20:29 
radhermit
app-vim/checkattach 2013-09-26 08:34:28 
radhermit
dev-java/jboss-modules  2013-09-26 17:29:17 ercpe
dev-java/jboss-logmanager   2013-09-26 17:34:48 ercpe
dev-java/jboss-logging  2013-09-26 17:39:00 ercpe
kde-misc/kio-mtp2013-09-26 18:23:07 johu
www-apps/novnc  2013-09-27 01:39:57 
prometheanfire
dev-python/flask-dashed 2013-09-27 04:13:06 patrick
dev-util/include-what-you-use   2013-09-27 09:54:25 slyfox
app-vim/easy-align  2013-09-28 01:46:12 
radhermit
app-admin/hardening-check   2013-09-29 14:49:59 ago
media-plugins/gst-plugins-dash  2013-09-29 17:55:11 eva
media-plugins/gst-plugins-hls   2013-09-29 17:55:53 eva
media-plugins/gst-plugins-smoothstreaming   2013-09-29 17:56:34 eva
dev-python/imapclient   2013-09-29 19:29:18 
radhermit

--
Robin Hugh Johnson
Gentoo Linux Developer
E-Mail : robb...@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85
Removed Packages:
Added Packages:
dev-lang/fsharp,added,cynede,2013-09-24 12:22:10
net-wireless/mfoc,added,mrueg,2013-09-24 15:24:26
dev-java/kryo,added,ercpe,2013-09-24 17:26:41
app-emulation/docker,added,gregkh,2013-09-25 03:22:15
dev-java/guice,added,ercpe,2013-09-25 17:20:14
dev-java/jsoup,added,ercpe,2013-09-25 17:36:28
dev-java/classmate,added,ercpe,2013-09-25 17:40:20
dev-python/oslo-sphinx,added,prometheanfire,2013-09-26 00:37:33
app-vim/tcomment,added,radhermit,2013-09-26 07:56:34
app-vim/recover,added,radhermit,2013-09-26 08:20:29
app-vim/checkattach,added,radhermit,2013-09-26 08:34:28
dev-java/jboss-modules,added,ercpe,2013-09-26 17:29:17
dev-java/jboss-logmanager,added,ercpe,2013-09-26 17:34:48
dev-java/jboss-logging,added,ercpe,2013-09-26 17:39:00
kde-misc/kio-mtp,added,johu,2013-09-26 18:23:07
www-apps/novnc,added,prometheanfire,2013-09-27 01:39:57
dev-python/flask-dashed,added,patrick,2013-09-27 04:13:06
dev-util/include-what-you-use,added,slyfox,2013-09-27 09:54:25
app-vim/easy-align,added,radhermit,2013-09-28 01:46:12
app-admin/hardening-check,added,ago,2013-09-29 14:49:59
media-plugins/gst-plugins-dash,added,eva,2013-09-29 17:55:11
media-plugins/gst-plugins-hls,added,eva,2013-09-29 17:55:53
media-plugins/gst-plugins-smoothstreaming,added,eva,2013-09-29 17:56:34
dev-python/imapclient,added,radhermit,2013-09-29 19:29:18

Done.

Re: [gentoo-dev] stabilizing libraries without testing reverse deps

[Rich Freeman]

On Sun, Sep 29, 2013 at 8:14 PM, hasufell  wrote:
> On 09/30/2013 12:54 AM, Andreas K. Huettel wrote:
>> Am Sonntag, 29. September 2013, 23:41:03 schrieb hasufell:
>>> It seems this happens more frequently these days, so I'd like to
>>> remind people to check stable reverse deps before stabilizing a
>>> library, especially when this is a non-maintainer stablereq.
>>>
>>> Arch teams do not test them, so this is the business of the
>>> maintainer or the dev who requested stabilization.
>>
>> Arch testing includes testing of reverse deps. If that's not the
>> case, arch teams are not doing their job.
>>
>
> I'd have to search the irc logs, but afair I was told so by ago.
>
> CCing him if I am wrong.

If you aren't wrong, that might be why Ago is about the only one
stabilizing libraries...  :)

It probably makes sense for arch teams to test a few reverse
dependencies as the FAQ suggests.  If we want them all tested, then it
would make a lot more sense to have a tinderbox or other automated
testing tools of some sort.  Even then, we won't get much more than
compile testing, or whatever test suites the packages happen to come
with.

I haven't really seen any sign of widespread breakage though.  I'm
sure some issues slip through, but short of having automated testing I
doubt we'll ever do better than that.

Rich

Re: [gentoo-dev] stabilizing libraries without testing reverse deps

[Paweł Hajdan, Jr.]

On 9/29/13 7:41 PM, Rich Freeman wrote:
> Even then, we won't get much more than compile testing, or whatever
> test suites the packages happen to come with.

That's right.

I think we can rely on the time packages spend in ~arch to catch the
issues that wouldn't come up with compile and test phases.

Also, when stable is not far behind testing, the testing that ~arch
packages get is more applicable to stable (because there are less
differences). This is one of the main reason for my push to stabilize
more packages (always with proper testing), and I've also seen bugs
being fixed in ~arch but the fixes are not always pushed to stable
(which can be addressed by stabilizing more packages in general).

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] stabilizing libraries without testing reverse deps

[Peter Volkov]

В Пн, 30/09/2013 в 00:54 +0200, Andreas K. Huettel пишет:
> Am Sonntag, 29. September 2013, 23:41:03 schrieb hasufell:
> > It seems this happens more frequently these days, so I'd like to
> > remind people to check stable reverse deps before stabilizing a
> > library, especially when this is a non-maintainer stablereq.
> > 
> > Arch teams do not test them, so this is the business of the maintainer
> > or the dev who requested stabilization.
> 
> Arch testing includes testing of reverse deps. 
> If that's not the case, arch teams are not doing their job.

I think it's good idea if maintainers and arch team developers will work
in tandem and help each other by both checking reverse deps. That said
the question here is who is in charge for stable tree stability? Stable
tree is the arch team's primary responsibility. That is why only they
are allowed to touch stable keywords after all. So arch team developer
should never commit anything if at least few reverse deps were checked.
Last but not least, I guess that average developer has lot's of things
in package.keywords, so it's not sane to expect developer to do stable
tree checks.

--
Peter.

[gentoo-dev] Re: stabilizing libraries without testing reverse deps

[Agostino Sarubbo]

This is a delicate point.

If you look at the policy, it says to test few rdeps.

The arch tester is in charge to test the packages on his architecture. These 
type of failures are _not_ architecture dependant.

So, instead of have 10 ATs that are testing the same rdeps, seems logic that 
the maintainer could do it one time.

What do you think?

Re: [gentoo-dev] stabilizing libraries without testing reverse deps

[Sergey Popov]

30.09.2013 01:41, hasufell пишет:
> Arch teams do not test them, so this is the business of the maintainer
> or the dev who requested stabilization.
> 

I hope you are kidding, cause when i was joining to arch teams, i was
taught to test reverse dependencies of libraries.

Of course, maintainer should test this also when bringing new version to
tree to prevent breakages. But stabilizing is different story and those
who putting apropriate version to stable should be 100% sure that it
would not break revdeps.

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Qt project lead
Gentoo Proxy maintainers project lead



signature.asc
Description: OpenPGP digital signature