[gentoo-dev] PHP_TARGETS vs PYTHON_TARGETS different grammar, why?
php5-5 vs python2_7 Why, how did that happen?
Re: [gentoo-dev] PHP_TARGETS vs PYTHON_TARGETS different grammar, why?
On Sat, 27 Jul 2013, Leho Kraav wrote: php5-5 vs python2_7 Why, how did that happen? Using the hyphen is cleaner, because the underscore is used as the separator for USE_EXPAND. (OTOH, as long a nobody will introduce a PYTHON_TARGETS_PYTHON2 variable, python2_7 will also work fine.) Ulrich
Re: [gentoo-dev] Autobuilds go to /experimental and to /releases only when someone actually tests them
Le vendredi 26 juillet 2013 à 21:19 -0700, Paweł Hajdan, Jr. a écrit : 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. How about a regular test livecds event? Kind of like a bug day. Seems like it could also be a nice and easy way to reach potential new contributers: just burn an ISO, reboot your computer, report back whether network/disk access works. Rémi
Re: [gentoo-dev] Vanilla sources stabilization policy change
24.07.2013 22:16, Peter Stuge пишет: It seems that for this package Gentoo QA can not realistically add any value to this package, hence my suggestion not to pretend that they can, and just remove the distinction between ~arch and arch for v-s, and make the latest version available to users by default. As were said before, blindly stabling vanilla-sources when gentoo-sources is stabilized is not an option. Remove the distinction between ~arch and arch for any package is not apropriate, as stable keywords were made for a reason, period... -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop-effects project lead Gentoo Qt project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] PHP_TARGETS vs PYTHON_TARGETS different grammar, why?
Dnia 2013-07-27, o godz. 10:37:04 Leho Kraav l...@kraav.com napisał(a): php5-5 vs python2_7 Why, how did that happen? Because some people like to type 'php_targets_php5-5'. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Vanilla sources stabilization policy change
Mike Pagano schrieb: Team members working alongside upstream (and downstream) developer Greg k-h have decided to no longer request stabilization of the vanilla sources kernel. How about dropping vanilla-sources and adding a vanilla USE flag to gentoo-sources? Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Autobuilds go to /experimental and to /releases only when someone actually tests them
Some time ago I was also thinking about writing a test framework for testing live images through kvm. Of course I didn't manage to find time to try to arrange something in the end, but the idea is still popping up in my mind every now and then. -- Fabio Erculiani
Re: [gentoo-dev] [PATCH subversion.eclass] Export working copy information after the update.
Dnia 2013-07-23, o godz. 20:46:15 Michał Górny mgo...@gentoo.org napisał(a): Currently, subversion.eclass exports working working copy information such as ESVN_WC_REVISION two times: once before running 'svn up', and the second time in pkg_preinst(). As a result, between those two calls ESVN_WC_REVISION lists the *previous* working copy revision rather than the current one. This behavior is not exploited by any ebuild. Instead, all ebuilds that use ESVN_WC_REVISION either hack it around, or actually use the wrong revision mistakenly. The patch fixes the eclass to export working copy information *after* the update is done. Redundant call to subversion_wc_info is removed from pkg_preinst() as no ebuild needs the re-export. Fixes: https://bugs.gentoo.org/show_bug.cgi?id=282486 Committed. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Autobuilds go to /experimental and to /releases only when someone actually tests them
On Sat, Jul 27, 2013 at 6:05 AM, Fabio Erculiani lx...@gentoo.org wrote: Some time ago I was also thinking about writing a test framework for testing live images through kvm. Of course I didn't manage to find time to try to arrange something in the end, but the idea is still popping up in my mind every now and then. Feel free to adapt: https://github.com/rich0/rich0-gentoo-bootstrap FYI - I plan to update it slightly today - I'm actually running 4 builds right now, eliminating some config-file cruft that is left over from earlier failures, and adding a little more due to a new one. More often than not I run into a little surprise every time I run it, either due to regressions, or due to the stage3 being so old that half the system needs to be updated. Newer stage3s would certainly help. So, if we add a QA step to stage3 publication we should try to keep up the pace, otherwise we'll create just as many problems for new users having to use old stage3s as we'll solve. Those scripts could benefit from re-factoring (oh, and it wouldn't hurt for me to credit Dowd and Associates again who created them). Some thoughts: 1. I added the plugin framework but never moved some of the default packages into a plugin. That would be an easy improvement to improve utility. 2. All of the EC2 logic itself could be moved into appropriate functions, and then the script could be made configurable for EC2 vs KVM vs whatever. The bootstrap logic itself would work fine in an architecture once /mnt/gentoo is setup. I wouldn't necessarily mind volunteering to keep up with it, but if I'm going to be running these weekly I'll probably ask for reimbursement for EC2 expenses (I use spot instances so it isn't too much, but all that CPU still adds up as well as storage costs while I'm debugging things). If we're willing to pay for the storage (fairly nominal) I could also work on publishing a list of up-to-date EC2 images (they're a byproduct of this stuff anyway so I just need to publish them when they work). Rich
Re: [gentoo-dev] [PATCH systemd.eclass] Introduce systemd_is_booted().
Dnia 2013-07-24, o godz. 09:18:13 Michał Górny mgo...@gentoo.org napisał(a): Pacho requested that to be able to warn users in GNOME packages that do not work anymore without systemd. Committed with a little more verbose description, and a MERGE_TYPE note. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Autobuilds go to /experimental and to /releases only when someone actually tests them
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 27 Jul 2013 00:13:37 -0400 Rick \Zero_Chaos\ Farina zeroch...@gentoo.org wrote: -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? openSUSE is using [openQA] for automated testing of installation media which is pretty need something that starts a machine in KVM and then simulates the user via a keyboard events. Last year there was also a talk about it on osc12 [2] [openQA] http://openqa.opensuse.org/ [2] http://www.youtube.com/watch?v=57a9zmpA844 - -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- -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQEcBAEBAgAGBQJR86ybAAoJEIN+7RD5ejah990H/jHk6bDSJeRmkDwj0FLiIc3I FbzwwaTug3DWpa1xegPTOK4Mxa2Nb7aVYfs4bZsQvQYrw+3WzvHmeYhfRiBNlU/B yiVGJ5TcPQpYltrTKx/nOuEvkH9NTcv/woiuTQ/kRedZKmNAmD/iQPwbITzOgE5U vCKyHtXGv9bwQbQBlHGNDHkinasMEGNio5uK/1XMjSxeRS9xmcAn1UNDc4OucEpA ac9EwrJgIzWgVnqD9x/mGY+GwB+dFZWrVyeGlsfEyHrTkDGu7zMBwJPd7swCxGFT ABLqts0EjbPnZIbihe962Tt/E73srEvgoHACib4D7P4sjB+X4leCQMu3D3RQVNs= =yUYu -END PGP SIGNATURE-
[gentoo-dev] [RFC] default bashrc value suggestion
Hi, list! Many times somebody post buildlogs — they're translated to user's native language due to system's /etc/env.d/02locale. What about adding export LC_ALL=POSIX (or, at least, LC_MESSAGES) to /etc/portage/bashrc by default (out-of-the-box)? That'll 1) fix buildlogs issue, 2) fix some python-related compilation breakages, like in xen-tools-4.3.0, for example. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Vanilla sources stabilization policy change
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 27/07/13 10:56, Chí-Thanh Christopher Nguyễn wrote: How about dropping vanilla-sources and adding a vanilla USE flag to gentoo-sources? Then we might as well just have a Linux package with a bunch of USE flags -- gentoo, hardened, libre, tuxonice, ck, etc. - -- Alexander alexan...@plaimi.net http://plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlHzyugACgkQRtClrXBQc7VyjwD/WXn+JxvCukvY1xkpQzYnwm9N frXlmNbvh8ic0K5dxw4A+gMoly44UzLBNoMlFdp4dGqVjCHv6sMnw7p0zcDc0cO1 =qgEa -END PGP SIGNATURE-
Re: [gentoo-dev] Vanilla sources stabilization policy change
On 07/27/2013 03:28 PM, Alexander Berntsen wrote: On 27/07/13 10:56, Chí-Thanh Christopher Nguyễn wrote: How about dropping vanilla-sources and adding a vanilla USE flag to gentoo-sources? Then we might as well just have a Linux package with a bunch of USE flags -- gentoo, hardened, libre, tuxonice, ck, etc. This is not a good idea, I'd like to have different kernel flavours of the same version installed in parallel. Kind regards, Manuel signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Vanilla sources stabilization policy change
On Sat, Jul 27, 2013 at 4:56 AM, Chí-Thanh Christopher Nguyễn chith...@gentoo.org wrote: Mike Pagano schrieb: Team members working alongside upstream (and downstream) developer Greg k-h have decided to no longer request stabilization of the vanilla sources kernel. How about dropping vanilla-sources and adding a vanilla USE flag to gentoo-sources? Unless it were stable-masked it would create the exact same problem. There was another suggestion to try to manage the patch sets via the kernel config system, but that isn't without its own challenges. Rich
Re: [gentoo-dev] [RFC] default bashrc value suggestion
On 27/07/13 08:09 AM, Vadim A. Misbakh-Soloviov wrote: Hi, list! Many times somebody post buildlogs — they're translated to user's native language due to system's /etc/env.d/02locale. What about adding export LC_ALL=POSIX (or, at least, LC_MESSAGES) to /etc/portage/bashrc by default (out-of-the-box)? That'll 1) fix buildlogs issue This doesn't seem like a major problem. Most errors can be easily deciphered, and if they can't, the user can be asked to run LC_MESSAGES=C emerge. This also introduces a usability problem, in that a user's preference is being overridden. Presumably the user knows that they want their system in a particular language more than we do. 2) fix some python-related compilation breakages, like in xen-tools-4.3.0, for example. This is just papering over the actual issue that needs to be fixed. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] default bashrc value suggestion
On Sat, 27 Jul 2013 16:09:20 +0400 Vadim A. Misbakh-Soloviov m...@mva.name wrote: What about adding export LC_ALL=POSIX (or, at least, LC_MESSAGES) [...] We've been over this plenty of times in the past. Notably in March 2009, July 2010 (about python specific build issues), April 2011, December 2011 and July 2012 on this mailing list alone, at a glance. jer
Re: [gentoo-dev] [RFC] default bashrc value suggestion
Unfortunately, gentoo.org's archive seems to be broken/frozen, while it is a bit hard to grep 3party archives to find already discussed topics :-/ 27.07.2013 18:31, Jeroen Roovers пишет: We've been over this plenty of times in the past. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] default bashrc value suggestion
On Sat, 27 Jul 2013 18:36:26 +0400 Vadim A. Misbakh-Soloviov m...@mva.name wrote: Unfortunately, gentoo.org's archive seems to be broken/frozen, while it is a bit hard to grep 3party archives to find already discussed topics :-/ Please reply below the quoted text. 27.07.2013 18:31, Jeroen Roovers пишет: We've been over this plenty of times in the past. To summarise: 1) locale related ebuild problems should be fixed in the relevant ebuilds/eclasses, because: 2) globally forcing a locale to fix one ebuild will expose build issues in other ebuilds (there is no generic solution) 3) several people have been adamant that locale settings should not be forced upon Gentoo users. 4) use the translation service of your choice to find out what the (usually generic) messages mean. jer
Re: [gentoo-dev] [RFC] default bashrc value suggestion
On 27/07/13 10:36 AM, Vadim A. Misbakh-Soloviov wrote: Unfortunately, gentoo.org's archive seems to be broken/frozen, while it is a bit hard to grep 3party archives to find already discussed topics :-/ 27.07.2013 18:31, Jeroen Roovers пишет: We've been over this plenty of times in the past. http://search.gmane.org/?query=lc_all+lc_messagesgroup=gmane.linux.gentoo.develDEFAULTOP=or signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] PHP_TARGETS vs PYTHON_TARGETS different grammar, why?
On Sat, Jul 27, 2013 at 3:37 AM, Leho Kraav l...@kraav.com wrote: php5-5 vs python2_7 Why, how did that happen? We had some discussion of this a while back. RUBY_TARGETS is yet another permutation with no version separator at all. As for why it happened: the eclasses involved were each written at different times by different people with little to no coordination.
Re: [gentoo-dev] [RFC] default bashrc value suggestion
Am Samstag, 27. Juli 2013, 16:31:52 schrieb Jeroen Roovers: On Sat, 27 Jul 2013 16:09:20 +0400 Vadim A. Misbakh-Soloviov m...@mva.name wrote: What about adding export LC_ALL=POSIX (or, at least, LC_MESSAGES) [...] We've been over this plenty of times in the past. Notably in March 2009, July 2010 (about python specific build issues), April 2011, December 2011 and July 2012 on this mailing list alone, at a glance. Yep. Should probably go on the Council agenda sometime. (rolls eyes) -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] default bashrc value suggestion
The only sane default is likely a POSIX UTF-8 locale, certainly not C; some package will even fail with LC_ALL=C I think.
Re: [gentoo-dev] Vanilla sources stabilization policy change
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alexander Berntsen schrieb: On 27/07/13 10:56, Chí-Thanh Christopher Nguyễn wrote: How about dropping vanilla-sources and adding a vanilla USE flag to gentoo-sources? Then we might as well just have a Linux package with a bunch of USE flags -- gentoo, hardened, libre, tuxonice, ck, etc. I don't think this can be made work, the other kernel packages' releases may not happen simultaneously with kernel releases. Or they may even skip certain releases. Rich Freeman schrieb: Unless it were stable-masked it would create the exact same problem. vanilla flags are not package.use.stable.mask'ed for toolchain packages either, yet they go stable with them. And there, USE=vanilla might cause serious breakage even. There was another suggestion to try to manage the patch sets via the kernel config system, but that isn't without its own challenges. vanilla = don't apply any patches, I don't think that could be improved by any modification to the kernel config system. Best regards, Chí-Thanh Christopher Nguyễn -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with SeaMonkey - http://www.enigmail.net/ iEYEARECAAYFAlH0D3MACgkQ+gvH2voEPRBmFACbBixGjRbW0z4yOhMvLRXaHx1z PjAAnin5cF6lD7X8n0KGpBbyMFT3kAAz =kPOS -END PGP SIGNATURE-
Re: [gentoo-dev] Vanilla sources stabilization policy change
On Saturday, July 27, 2013 09:58:08 AM Rich Freeman wrote: Unless it were stable-masked it would create the exact same problem. ^^ This -- Mike Pagano Gentoo Developer - Kernel Project E-Mail : mpag...@gentoo.org GnuPG FP : EEE2 601D 0763 B60F 848C 9E14 3C33 C650 B576 E4E3 Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3op=index
Re: [gentoo-dev] [RFC] default bashrc value suggestion
Jeroen Roovers schrieb: Unfortunately, gentoo.org's archive seems to be broken/frozen, while it is a bit hard to grep 3party archives to find already discussed topics :-/ http://archives.gentoo.org/gentoo-dev/msg_0ea6864e30d3a4d5319694afc18162df.xml 27.07.2013 18:31, Jeroen Roovers пишет: We've been over this plenty of times in the past. To summarise: 1) locale related ebuild problems should be fixed in the relevant ebuilds/eclasses, because: 2) globally forcing a locale to fix one ebuild will expose build issues in other ebuilds (there is no generic solution) 3) several people have been adamant that locale settings should not be forced upon Gentoo users. 4) use the translation service of your choice to find out what the (usually generic) messages mean. Nobody seemed to be against setting LC_MESSAGES in make.conf. I reported a bug now. https://bugs.gentoo.org/478382 Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] robo-stable bugs
On 5/20/13 9:58 AM, Paweł Hajdan, Jr. wrote: On 5/20/13 5:10 AM, Gilles Dartiguelongue wrote: This generally needs to go first so sorting by summary shows your packages in order and you have a chance to see this part of the summary in bugzilla (with version optionally), the rest of the summary line is imho less important when working through the web interface. This makes sense. I'll post an update when I make this simple change to the script. As promised I'm announcing I made this change: http://git.overlays.gentoo.org/gitweb/?p=proj/arch-tools.git;a=commitdiff;h=a92c88330af1aec3aa9ee58dc497f047129ccd2e The original thread got somewhat long, so if I've missed any other feedback on which there is a consensus, please let me know. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] robo-stable bugs
Am Samstag, 27. Juli 2013, 21:29:15 schrieb Paweł Hajdan, Jr.: The original thread got somewhat long, so if I've missed any other feedback on which there is a consensus, please let me know. Hi Pawel, a general idea that might be helpful: * document your policies on a web page or wiki page * add a link to that page to the stablereq bug text This way we can avoid or at least shorten future discussions about the robostabling. Best, Andreas -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
[gentoo-portage-dev] [PATCH] emerge: accept --pkg-format option
Accept --pkg-format option which will override settings of
PORTAGE_BINPKG_FORMAT. Currently takes choices of 'tar' (original gentoo
binary package), 'rpm' or its combinations.
Signed-off-by: Tomáš Čech sleep_wal...@suse.cz
---
man/emerge.1| 4
man/make.conf.5 | 4
pym/_emerge/EbuildBinpkg.py | 18 +++---
pym/_emerge/EbuildBuild.py | 12 +---
pym/_emerge/actions.py | 17 +
pym/_emerge/main.py | 5 +
pym/portage/const.py| 1 +
7 files changed, 51 insertions(+), 10 deletions(-)
diff --git a/man/emerge.1 b/man/emerge.1
index da6bcba..1571e8a 100644
--- a/man/emerge.1
+++ b/man/emerge.1
@@ -633,6 +633,10 @@ exhaustively apply the entire history of package moves,
regardless of whether or not any of the package moves have
been previously applied.
.TP
+.BR \-\-pkg-format
+Specify which binary package format will be created as target.
+Possible choices now are tar and rpm or their combinations.
+.TP
.BR \-\-prefix=DIR
Set the \fBEPREFIX\fR environment variable.
.TP
diff --git a/man/make.conf.5 b/man/make.conf.5
index adf32bd..8811513 100644
--- a/man/make.conf.5
+++ b/man/make.conf.5
@@ -707,6 +707,10 @@ setting as the base URI.
This variable contains options to be passed to the tar command for creation
of binary packages.
.TP
+.B PORTAGE_BINPKG_FORMAT
+This variable sets default format used for binary packages. Possible values
+are tar and rpm or both.
+.TP
\fBPORTAGE_BUNZIP2_COMMAND\fR = \fI[bunzip2 command string]\fR
This variable should contain a command that is suitable for portage to call
for bunzip2 extraction operations.
diff --git a/pym/_emerge/EbuildBinpkg.py b/pym/_emerge/EbuildBinpkg.py
index 34a6aef..145cd31 100644
--- a/pym/_emerge/EbuildBinpkg.py
+++ b/pym/_emerge/EbuildBinpkg.py
@@ -10,22 +10,26 @@ class EbuildBinpkg(CompositeTask):
This assumes that src_install() has successfully completed.
__slots__ = ('pkg', 'settings') + \
- ('_binpkg_tmpfile',)
+ ('_binpkg_tmpfile', 'pkg_format')
def _start(self):
pkg = self.pkg
root_config = pkg.root_config
bintree = root_config.trees[bintree]
bintree.prevent_collision(pkg.cpv)
- binpkg_tmpfile = os.path.join(bintree.pkgdir,
- pkg.cpv + .tbz2. + str(os.getpid()))
- bintree._ensure_dir(os.path.dirname(binpkg_tmpfile))
+ if self.pkg_format == rpm:
+ requested_phase = rpm
+ else:
+ requested_phase = package
+ binpkg_tmpfile = os.path.join(bintree.pkgdir,
+ pkg.cpv + .tbz2. + str(os.getpid()))
+ bintree._ensure_dir(os.path.dirname(binpkg_tmpfile))
- self._binpkg_tmpfile = binpkg_tmpfile
- self.settings[PORTAGE_BINPKG_TMPFILE] = self._binpkg_tmpfile
+ self._binpkg_tmpfile = binpkg_tmpfile
+ self.settings[PORTAGE_BINPKG_TMPFILE] =
self._binpkg_tmpfile
package_phase = EbuildPhase(background=self.background,
- phase='package', scheduler=self.scheduler,
+ phase=requested_phase, scheduler=self.scheduler,
settings=self.settings)
self._start_task(package_phase, self._package_phase_exit)
diff --git a/pym/_emerge/EbuildBuild.py b/pym/_emerge/EbuildBuild.py
index 75d906f..8755815 100644
--- a/pym/_emerge/EbuildBuild.py
+++ b/pym/_emerge/EbuildBuild.py
@@ -10,6 +10,8 @@ from _emerge.EbuildMerge import EbuildMerge
from _emerge.EbuildFetchonly import EbuildFetchonly
from _emerge.EbuildBuildDir import EbuildBuildDir
from _emerge.MiscFunctionsProcess import MiscFunctionsProcess
+from _emerge.TaskSequence import TaskSequence
+
from portage.util import writemsg
import portage
from portage import os
@@ -306,10 +308,14 @@ class EbuildBuild(CompositeTask):
self.scheduler.output(msg,
log_path=self.settings.get(PORTAGE_LOG_FILE))
- packager = EbuildBinpkg(background=self.background,
pkg=self.pkg,
- scheduler=self.scheduler, settings=self.settings)
+ binpkg_tasks = TaskSequence()
+ requested_binpkg_formats =
self.settings.get(PORTAGE_BINPKG_FORMAT, tar).split()
+ for pkg_fmt in portage.const.SUPPORTED_BINPKG_FORMATS:
+ if pkg_fmt in requested_binpkg_formats:
+
binpkg_tasks.add(EbuildBinpkg(background=self.background, pkg=self.pkg,
+ pkg_format=pkg_fmt,
scheduler=self.scheduler, settings=self.settings))
- self._start_task(packager, self._buildpkg_exit)
+ self._start_task(binpkg_tasks, self._buildpkg_exit)
