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.d
# 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
Descript
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
===
R
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 m
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
-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 m
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 examp
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 th
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
-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
>> l
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
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
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 phase
В Пн, 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-
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 main
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 sho
16 matches
Mail list logo
