[gentoo-dev] unmasking USE=system-ffmpeg for stable www-client/chromium ebuilds
Currently USE=system-ffmpeg is masked for stable www-client/chromium ebuilds. However, recently a new enough media-libs/ffmpeg has been stabilized, making it possible to use system ffmpeg in stable. I'd like to make the change close to a new version of chromium being stabilized so that less rebuilds would be triggered. Here is how the dependency looks like: system-ffmpeg? ( || ( =media-video/ffmpeg-1.0:=[opus] =media-video/libav-9.5:=[opus] ) ) I know there are some controversies around ffmpeg/libav, and I wouldn't like to go into that. I prefer to ask first and have a discussion before rather than surprising people badly. Please let me know what you think about this idea (unmasking USE=system-ffmpeg for stable chromium ebuilds). Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] unmasking USE=system-ffmpeg for stable www-client/chromium ebuilds
Does this still allow me to use libav? If not I'd like to veto it. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ On Fri, Jul 26, 2013 at 5:22 PM, Paweł Hajdan, Jr. phajdan...@gentoo.orgwrote: Currently USE=system-ffmpeg is masked for stable www-client/chromium ebuilds. However, recently a new enough media-libs/ffmpeg has been stabilized, making it possible to use system ffmpeg in stable. I'd like to make the change close to a new version of chromium being stabilized so that less rebuilds would be triggered. Here is how the dependency looks like: system-ffmpeg? ( || ( =media-video/ffmpeg-1.0:=[opus] =media-video/libav-9.5:=[opus] ) ) I know there are some controversies around ffmpeg/libav, and I wouldn't like to go into that. I prefer to ask first and have a discussion before rather than surprising people badly. Please let me know what you think about this idea (unmasking USE=system-ffmpeg for stable chromium ebuilds). Paweł
Re: [gentoo-dev] unmasking USE=system-ffmpeg for stable www-client/chromium ebuilds
On 7/26/13 9:50 AM, Diego Elio Pettenò wrote: Does this still allow me to use libav? If not I'd like to veto it. You can still use libav - either unmask it or USE=-system-ffmpeg. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] unmasking USE=system-ffmpeg for stable www-client/chromium ebuilds
2013/7/26 Diego Elio Pettenò flamee...@flameeyes.eu Does this still allow me to use libav? If not I'd like to veto it. You can use testing version. Stable is too old, be happy I fixed all those buildcrashes so we can have it in testing. If you want start some tracker to get it stable tho, i would not mind, as all my machines have it unmasked anyway. Tom
Re: [gentoo-dev] unmasking USE=system-ffmpeg for stable www-client/chromium ebuilds
If you can start it I can try to get the stable tinderbox running over the weekend. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ On Fri, Jul 26, 2013 at 5:56 PM, Tomáš Chvátal tomas.chva...@gmail.comwrote: 2013/7/26 Diego Elio Pettenò flamee...@flameeyes.eu Does this still allow me to use libav? If not I'd like to veto it. You can use testing version. Stable is too old, be happy I fixed all those buildcrashes so we can have it in testing. If you want start some tracker to get it stable tho, i would not mind, as all my machines have it unmasked anyway. Tom
[gentoo-dev] New eclass: twisted-r1
Hi,
I'm sending revised twisted-r1.eclass including the ebuild bumps.
You can view the diff either in the included patch or at github [1]
I have tested on amd64 and x86. All packages emerge and tests are
passing, besides nevow, axiom, and mantissa which are failing anyway
with the old eclass too.
Will commit tomorrow if there are no disputers.
[1]
https://github.com/yaccz/gentoo-overlay/commit/1288b7989a156d3e9c3b6b1a0f079c33c9dffc10
commit 1288b7989a156d3e9c3b6b1a0f079c33c9dffc10
Author: Jan (yac) MatÄjka jmate...@suse.cz
Date: Mon Jul 8 13:57:23 2013 +0200
eapi 5/twisted-r1 bumps
* elcass
* twisted-* ebuilds
* twisted depender ebuilds
diff --git a/dev-python/axiom/axiom-0.6.0-r1.ebuild b/dev-python/axiom/axiom-0.6.0-r1.ebuild
index 7291292..8e88ccb 100644
--- a/dev-python/axiom/axiom-0.6.0-r1.ebuild
+++ b/dev-python/axiom/axiom-0.6.0-r1.ebuild
@@ -2,17 +2,11 @@
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/dev-python/axiom/axiom-0.6.0.ebuild,v 1.14 2013/05/12 18:32:59 floppym Exp $
-EAPI=3
-PYTHON_DEPEND=2
-SUPPORT_PYTHON_ABIS=1
-RESTRICT_PYTHON_ABIS=2.5 3.* *-jython
-PYTHON_USE_WITH=sqlite
+EAPI=5
+PYTHON_COMPAT=( python{2_6,2_7} pypy{1_9,2_0} )
+PYTHON_REQ_USE=sqlite
-# setup.py uses epsilon.setuphelper.autosetup(), which tries to use
-# build-${PYTHON_ABI} directories as packages.
-DISTUTILS_USE_SEPARATE_SOURCE_DIRECTORIES=1
-
-inherit eutils twisted
+inherit eutils twisted-r1
MY_PN=Axiom
MY_P=${MY_PN}-${PV}
@@ -23,35 +17,24 @@ SRC_URI=mirror://pypi/${MY_PN:0:1}/${MY_PN}/${MY_P}.tar.gz
LICENSE=MIT
SLOT=0
-KEYWORDS=amd64 ppc ppc64 sparc x86
+KEYWORDS=~amd64 ~ppc ~ppc64 ~sparc ~x86
IUSE=
-DEPEND==dev-python/epsilon-0.6
- =dev-python/twisted-2.4
- =dev-python/twisted-conch-0.7.0-r1
+DEPEND==dev-python/epsilon-0.6.0-r2[${PYTHON_USEDEP}]
+ dev-python/twisted[${PYTHON_USEDEP}]
+ dev-python/twisted-conch[${PYTHON_USEDEP}]
RDEPEND=${DEPEND}
S=${WORKDIR}/${MY_P}
-DOCS=NAME.txt
-PYTHON_MODNAME=axiom twisted/plugins/axiom_plugins.py
-TWISTED_PLUGINS=axiom.plugins twisted.plugins
-
-src_prepare() {
- epatch ${FILESDIR}/${PN}-0.5.30-sqlite3.patch
- epatch ${FILESDIR}/${PN}-0.5.30-sqlite3_3.6.4.patch
- python_copy_sources
-}
-
-src_compile() {
- # Skip distutils_src_compile to avoid installation of $(python_get_sitedir)/build directory.
- :
-}
+DOCS=( NAME.txt )
+PATCHES=(
+ ${FILESDIR}/${PN}-0.5.30-sqlite3.patch
+ ${FILESDIR}/${PN}-0.5.30-sqlite3_3.6.4.patch
+)
-src_test() {
- python_execute_trial -P . axiom
-}
+TWISTED_PLUGINS=axiom.plugins twisted.plugins
-src_install() {
- PORTAGE_PLUGINCACHE_NOOP=1 distutils_src_install
+python_test() {
+ trial -P . axiom || die tests failed with $EPYTHON
}
diff --git a/dev-python/epsilon/epsilon-0.6.0-r2.ebuild b/dev-python/epsilon/epsilon-0.6.0-r2.ebuild
index cc893ad..9462af6 100644
--- a/dev-python/epsilon/epsilon-0.6.0-r2.ebuild
+++ b/dev-python/epsilon/epsilon-0.6.0-r2.ebuild
@@ -2,18 +2,10 @@
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/dev-python/epsilon/epsilon-0.6.0-r1.ebuild,v 1.2 2012/10/12 08:15:00 patrick Exp $
-EAPI=3
-PYTHON_DEPEND=2
-SUPPORT_PYTHON_ABIS=1
-RESTRICT_PYTHON_ABIS=2.5 3.* *-jython
-DISTUTILS_SRC_TEST=trial
-DISTUTILS_DISABLE_TEST_DEPENDENCY=1
+EAPI=5
+PYTHON_COMPAT=( python{2_6,2_7} pypy{1_9,2_0} )
-# setup.py uses epsilon.setuphelper.autosetup(), which tries to use
-# build-${PYTHON_ABI} directories as packages.
-DISTUTILS_USE_SEPARATE_SOURCE_DIRECTORIES=1
-
-inherit eutils twisted
+inherit eutils twisted-r1
MY_PN=Epsilon
MY_P=${MY_PN}-${PV}
@@ -27,14 +19,15 @@ SLOT=0
KEYWORDS=~amd64 ~ppc ~ppc64 ~sparc ~x86
IUSE=
-DEPEND==dev-python/twisted-2.4
+DEPEND=dev-python/twisted[${PYTHON_USEDEP}]
RDEPEND=${DEPEND}
S=${WORKDIR}/${MY_P}
-DOCS=NAME.txt NEWS.txt
+DOCS=( NAME.txt NEWS.txt )
+PATCHES=( ${FILESDIR}/epsilon_plugincache_portagesandbox.patch )
-src_prepare() {
+python_prepare_all() {
# Rename to avoid file-collisions
mv bin/benchmark bin/epsilon-benchmark
sed -i \
@@ -42,27 +35,16 @@ src_prepare() {
setup.py || die sed failed
# otherwise we get sandbox violations as it wants to update
# the plugin cache
- epatch ${FILESDIR}/epsilon_plugincache_portagesandbox.patch
#These test are removed upstream
rm -f epsilon/test/test_sslverify.py epsilon/sslverify.py || die
#See bug 357157 comment 5 for Ian Delaney's explanation of this fix
sed -e 's:month) 2004 9:month) 2004 14:' \
-i epsilon/test/test_extime.py || die
- #These are broken too
- rm -f epsilon/test/test_release.py epsilon/release.py || die
-
- python_copy_sources
-}
-
-src_compile() {
- # Skip distutils_src_compile to avoid installation of $(python_get_sitedir)/build directory.
- :
-}
-
-src_test() {
# Release tests need DivmodCombinator.
- rm -f epsilon/test/test_release.py* epsilon/release.py
+ rm -f epsilon/test/test_release.py* epsilon/release.py || die
+}
-
Re: [gentoo-dev] unmasking USE=system-ffmpeg for stable www-client/chromium ebuilds
On Fri, 26 Jul 2013 18:00:10 +0100 Diego Elio Pettenò flamee...@flameeyes.eu wrote: If you can start it I can try to get the stable tinderbox running over the weekend. libav-9 should be more or less ok for stable tinderbox-wise. what is probably not ok is the planar audio formats and the tinderbox wont catch that. A.
Re: [gentoo-dev] unmasking USE=system-ffmpeg for stable www-client/chromium ebuilds
On Fri, 26 Jul 2013 17:50:58 +0100 Diego Elio Pettenò flamee...@flameeyes.eu wrote: Does this still allow me to use libav? If not I'd like to veto it. As already pointed out, you only need to not enable it. What you can veto is to have it enabled by default. Otherwise, vetoing doesnt make any sense if nobody is going to fix it. Alexis.
[gentoo-dev] Autobuilds go to /experimental and to /releases only when someone actually tests them
(I sent this to gentoo-releng@. Resending to gentoo-dev@ for a wider audience) Can we make autobuilds go to /experimental and then only move them to /releases when someone actually tests them? Looking at bugzilla and listening in #gentoo-releng, it's kind of embarrassing how often someone downloads a Live CD only to find out that networking is totally broken by a udev upgrade, or something to that effect. We don't commit version bumps straight to stable; I don't see why we do with release media. Matt
Re: [gentoo-dev] Autobuilds go to /experimental and to /releases only when someone actually tests them
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/27/2013 12:08 AM, Matt Turner wrote: (I sent this to gentoo-releng@. Resending to gentoo-dev@ for a wider audience) Can we make autobuilds go to /experimental and then only move them to /releases when someone actually tests them? Looking at bugzilla and listening in #gentoo-releng, it's kind of embarrassing how often someone downloads a Live CD only to find out that networking is totally broken by a udev upgrade, or something to that effect. We don't commit version bumps straight to stable; I don't see why we do with release media. It's been an odd week for me agreeing with people but yeah, I completely agree. I think we *need* to keep the autobuilds going as often as possible to detect obvious breakage, but there is no reason they shouldn't be marked experimental. The real question is, how realistic can we make a process of testing and moving to stable? - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJR80jxAAoJEKXdFCfdEflKhGYP/At7Xtd4bWcY1wrxl1oPYdNr vVfgqhmnveNqwhdERcp8InGLGoCDt+O3hvSzq4kX8qJXqizxPonP9ef1hJsnz0iw NgjMHiGiYp2NgmU6DB7X/VLH3RNF96WJMK/R2Qtk1tuN+Ftu1D6T5hP4MmTOuvta T2CvfYGFVAPZiY9+GLAmbe1LhjwlbJ8DnhbaamA7bK1D0ZhApWtRVtjk6unu+D5w XRG8tIDml5gUkZRVl4d9Bg1wxuMoPtOuY2ANr+RCJPRVMkexB1XCdAVzPF73EFx+ 0Ns5TKi+vWyhzY6PElvA0xClj2wAK/enAkAmPZ8OvagnCLfmoqZUNyr4+Eupxclt 54pFMzpdR2KntmmFqS5ZBF8Q6nxz8GDhSm0H8+d1xTKxNcwKSlaAI7JkzBByWhKt MjFYNTVz7MD/MFpvpRt2tKg3BI6m/ZcgCQwnAJ9QjdtyhLA8/Km5+AA2tnN457V7 qlpf+ipjDzb3G5Po1JXSMUidy8Uu6SvqHu8TwiJUy/mlKxjmPmrPPGfRpR32pWNT d/jE6IQAmiVjXWTDDBi0uZY8oUl5H0uroLFuA+//NtmGD8DWmV1fK0PYKLjUsE4X nWaCKn2qlF7d16mnJh1RweBjQjMmvRYutg62A3Jb9Ek9jXBIC4bYJa2VS2xoPpWy qZv8oon/9z336E5Uvamj =KaUO -END PGP SIGNATURE-
Re: [gentoo-dev] Autobuilds go to /experimental and to /releases only when someone actually tests them
On 7/26/13 9:13 PM, Rick Zero_Chaos Farina wrote: On 07/27/2013 12:08 AM, Matt Turner wrote: Can we make autobuilds go to /experimental and then only move them to /releases when someone actually tests them? Very interesting. :) I had a similar idea. I think it's great. Looking at bugzilla and listening in #gentoo-releng, it's kind of embarrassing how often someone downloads a Live CD only to find out that networking is totally broken by a udev upgrade, or something to that effect. Yes - and it's very important to make that first experience with the distro as good as possible. The bugs are usually not fixed quickly enough anyway. I'd like to add a suggestion - document the processes better and allow more people to contribute. We don't commit version bumps straight to stable; I don't see why we do with release media. It's been an odd week for me agreeing with people but yeah, I completely agree. I think we *need* to keep the autobuilds going as often as possible to detect obvious breakage, but there is no reason they shouldn't be marked experimental. +1 The real question is, how realistic can we make a process of testing and moving to stable? We have arch teams, we have users... when several users say it's OK I think it is OK. As compared to a script pushing it to the website just because it compiled. Paweł signature.asc Description: OpenPGP digital signature
