m h wrote:
Like I said, if you are interested in manipulating wars from ant or
maven perhaps cargo is for you. I'm assumming this is more of the
programmer/qa type person who wants this sort of functionality. My
end user is a sys-admin. They are usually more comfortable from the
command
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Lance Albertson wrote:
Peter Gordon wrote:
Matthew Marlowe wrote:
If we could get a license donated, my vote would be to switch to Atlassian
Jira, http://www.atlassian.com/software/jira. It seems to be gaining
mindshare rather quickly, and
Luis Francisco Araujo wrote:
I think it is perfectly valid we use this kind of tools for development;
as far as i know, our SC refers to those components (in form of software
and metadata) to be free software upon which a user depend to build a
Gentoo system, and this isn't one of those
On Fri, 04 Aug 2006 20:18:40 -0400
Alec Warner [EMAIL PROTECTED] wrote:
Give me some numbers on how many things still fail with that enabled
because I would be concerned if the number is too high.
I don't have numbers, but if you have FEATURES=test set yourself you
should know how many fail.
On Sat, 5 Aug 2006 02:39:16 +0200
Danny van Dyk [EMAIL PROTECTED] wrote:
Am Samstag, 5. August 2006 02:11 schrieb Kevin F. Quinn:
At the very least, ebuild maintainers and ATs should be running with
tests switched on. If the tests are known to fail then the ebuild
can either
On Fri, 04 Aug 2006 17:25:17 -0700
Joshua Jackson [EMAIL PROTECTED] wrote:
While I agree that it would be nice to see more
people using test and collision-protect I don't think its something we
should enable at this point in time till we have many packages working
correctly with the feature.
Am Samstag, 5. August 2006 11:19 schrieb Kevin F. Quinn:
On Sat, 5 Aug 2006 02:39:16 +0200
Danny van Dyk [EMAIL PROTECTED] wrote:
Am Samstag, 5. August 2006 02:11 schrieb Kevin F. Quinn:
At the very least, ebuild maintainers and ATs should be running
with tests switched on. If the
On Sat, Aug 05, 2006 at 01:32:50AM -0700, Peter Gordon wrote:
However, I don't believe that Bugzilla is such a separate entity from
the distribution as a whole. I, for one, would simply stop reporting
bugs there if it was switched to a proprietary bug-tracking tool. Now,
one could say that
On Sat, 5 Aug 2006 11:49:53 +0200
Danny van Dyk [EMAIL PROTECTED] wrote:
Please re-read the list of packages that fail tests:
* glibc
* autoconf
* gettext
* tar
That makes _4_ system packages. Before I would consider making
FEATURES=test a default, I would add least want the system
Kevin F. Quinn [EMAIL PROTECTED] wrote:
I don't know if anyone is interested in my opinion, but I'll dump it on
you anyway. :-)
IMO devs should be working with collision-protect sandbox strict
stricter test userpriv but let's not get too excited ;)
ACK. I also agree with the general idea to
On Sat, 5 Aug 2006 13:14:17 +0200
Sascha Geschwandtner [EMAIL PROTECTED] wrote:
So right now, I'd like to see collision-protect sandbox strict
included in the default FEATUREs.
sandbox and strict are already default for a long time.
Marius
--
Public Key at
Alec,
Will you proxy-maintain it ? PLEASE
I am willing to test it and create up to date ebuilds for it.
Ahmed.
(amd64 arch. tester)
On 18/07/06, Alec Warner [EMAIL PROTECTED] wrote:
This package was given to treecleaners[1], but I think it is too useful
to clean from the tree.
I'd like
Marius Mauch [EMAIL PROTECTED] wrote:
sandbox and strict are already default for a long time.
Not in the selinux profiles (sandbox is missing there). Regarding strict,
I just found out it's in the base profile, so you are of course correct.
But maybe I'm overlooking something else.
Well, I
Sascha Geschwandtner [EMAIL PROTECTED] wrote:
Not in the selinux profiles (sandbox is missing there).
No, I'm wrong here either. Sorry for the noise.
--
gentoo-dev@gentoo.org mailing list
On Sat, 2006-08-05 at 12:57 +0200, Kevin F. Quinn wrote:
On Sat, 5 Aug 2006 11:49:53 +0200
Danny van Dyk [EMAIL PROTECTED] wrote:
Please re-read the list of packages that fail tests:
* glibc
* autoconf
* gettext
* tar
That makes _4_ system packages. Before I would consider
Marius Mauch wrote:
On Sat, 5 Aug 2006 13:14:17 +0200
Sascha Geschwandtner [EMAIL PROTECTED] wrote:
So right now, I'd like to see collision-protect sandbox strict
included in the default FEATUREs.
sandbox and strict are already default for a long time.
Not 100% true. Sandbox has been
Kevin F. Quinn [EMAIL PROTECTED] posted
[EMAIL PROTECTED], excerpted below, on Sat,
05 Aug 2006 11:33:39 +0200:
IMO devs should be working with collision-protect sandbox strict
stricter test userpriv but let's not get too excited ;)
Don't forget (for the appropriate arch(s)) multilib-strict!
Kevin F. Quinn [EMAIL PROTECTED] posted
[EMAIL PROTECTED], excerpted below, on Sat,
05 Aug 2006 11:33:39 +0200:
IMO devs should be working with collision-protect sandbox strict
stricter test userpriv but let's not get too excited ;)
Don't forget (for the appropriate arch(s)) multilib-strict!
I'm currently preparing one of my embedded system for a test-run and noticed
that a *binary* package of media-libs/libpng pulls in the autofoo-stuff.
I went looking for the reason, looked into the eutils, multilib and finally
autotools eclasses and saw that the autotools.eclass is setting the
I'd like to suggest we make FEATURES=test (and therefore USE=test) the
default behaviour, rather than the opt-in we currently have. Far too
many packages fail their test phase.
I have a related question, but first a comment:
I like the idea, that packages run their self-tests before they get
On Sat, 05 Aug 2006 09:29:48 -0400
Stephen P. Becker [EMAIL PROTECTED] wrote:
Marius Mauch wrote:
On Sat, 5 Aug 2006 13:14:17 +0200
Sascha Geschwandtner [EMAIL PROTECTED] wrote:
So right now, I'd like to see collision-protect sandbox strict
included in the default FEATUREs.
On Saturday 05 August 2006 15:14, Sven Köhler wrote:
So my question is:
where's the difference between USE=test and FEATURES=test ?
So FEATURES=test means, that portage runs src_test(), right?
So what does USE=test mean?
sometimes packages require special package dependencies when the tests
On Sat, 05 Aug 2006 17:14:23 +0200
Sven Köhler [EMAIL PROTECTED] wrote:
So my question is:
where's the difference between USE=test and FEATURES=test ?
So FEATURES=test means, that portage runs src_test(), right?
Yes.
So what does USE=test mean?
USE=test is a workaround; portage cannot
On Sat, 5 Aug 2006 17:35:32 +0200 Kevin F. Quinn
[EMAIL PROTECTED] wrote:
| USE=test is a workaround; portage cannot use FEATUREs in dep
| strings.
Actually, it could, if anyone ever got around to adding FEATURES to
USE_EXPAND...
--
Ciaran McCreesh
Mail: ciaran dot mccreesh at
Ciaran McCreesh wrote:
On Sat, 5 Aug 2006 17:35:32 +0200 Kevin F. Quinn
[EMAIL PROTECTED] wrote:
| USE=test is a workaround; portage cannot use FEATUREs in dep
| strings.
Actually, it could, if anyone ever got around to adding FEATURES to
USE_EXPAND...
We would do lots of things; that
On Sat, Aug 05, 2006 at 02:26:16AM +0200, Jakub Moc wrote:
Kevin F. Quinn wrote:
I'd like to suggest we make FEATURES=test (and therefore USE=test) the
default behaviour, rather than the opt-in we currently have. Far too
many packages fail their test phase.
Sure everyone likes to watch
Alec Warner wrote:
All you crazy folks that wanted to help clean the tree please e-mail me
off list.
To briefly go over requirements you need to be able to:
Speak English;
Read English;
Write English;
Use Bugzilla;
Use Portage;
Some of you need to be able to use CVS and SVN;
Some of
On Sat, Aug 05, 2006 at 12:04:01PM -0400, Alec Warner wrote:
Ciaran McCreesh wrote:
On Sat, 5 Aug 2006 17:35:32 +0200 Kevin F. Quinn
[EMAIL PROTECTED] wrote:
| USE=test is a workaround; portage cannot use FEATUREs in
dep
| strings.
Actually, it could, if anyone ever got around to adding
On Saturday 05 August 2006 09:29, Stephen P. Becker wrote:
P.S. Note that we have offered various portage devs hardware and/or an
account on Iluxa's ginormous Origin 2000 machine in the past with the
intention of getting this fixed, and nobody has taken us up on that...
so ? none of the
On Saturday 05 August 2006 06:57, Kevin F. Quinn wrote:
On Sat, 5 Aug 2006 11:49:53 +0200
Danny van Dyk [EMAIL PROTECTED] wrote:
Please re-read the list of packages that fail tests:
* glibc
* autoconf
* gettext
* tar
That makes _4_ system packages. Before I would consider making
On Saturday 05 August 2006 10:12, Christian Heim wrote:
I went looking for the reason, looked into the eutils, multilib and finally
autotools eclasses and saw that the autotools.eclass is setting the DEPEND
but not the RDEPEND. IIRC portage-2.1 is now setting RDEPEND to DEPEND if
nothing other
On Sat, Aug 05, 2006 at 02:35:49PM -0400, Mike Frysinger wrote:
On Saturday 05 August 2006 06:57, Kevin F. Quinn wrote:
On Sat, 5 Aug 2006 11:49:53 +0200
Danny van Dyk [EMAIL PROTECTED] wrote:
Please re-read the list of packages that fail tests:
* glibc
* autoconf
* gettext
Mike Frysinger wrote:
On Saturday 05 August 2006 09:29, Stephen P. Becker wrote:
P.S. Note that we have offered various portage devs hardware and/or an
account on Iluxa's ginormous Origin 2000 machine in the past with the
intention of getting this fixed, and nobody has taken us up on that...
On Sat, 5 Aug 2006 14:35:49 -0400
Mike Frysinger [EMAIL PROTECTED] wrote:
On Saturday 05 August 2006 06:57, Kevin F. Quinn wrote:
On Sat, 5 Aug 2006 11:49:53 +0200
Danny van Dyk [EMAIL PROTECTED] wrote:
Please re-read the list of packages that fail tests:
* glibc
* autoconf
*
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christian Heim wrote:
I'm currently preparing one of my embedded system for a test-run and noticed
that a *binary* package of media-libs/libpng pulls in the autofoo-stuff.
I went looking for the reason, looked into the eutils, multilib and
On Saturday 05 August 2006 14:56, Stephen P. Becker wrote:
The metadata for sandbox suggests that it is under the control of the
portage team, even if they lack a herd:
... because it is tightly integrated with portage ... there is the aspects of
portage which require some sandbox env
On Saturday 05 August 2006 14:48, Harald van Dijk wrote:
Then RESTRICT=test, or use a src_test which warns on test failures
rather than aborting, could be used. Or am I missing something?
some architectures pass fine
my [hidden] point was that globally enabling/disabling FEATURES=test isnt a
Mike Frysinger wrote:
On Saturday 05 August 2006 14:56, Stephen P. Becker wrote:
The metadata for sandbox suggests that it is under the control of the
portage team, even if they lack a herd:
... because it is tightly integrated with portage ... there is the aspects of
portage which require
On Saturday 05 August 2006 15:32, Zac Medico wrote:
The actual fault is in libpng-1.2.12-r1.ebuild where RDEPEND= should be
explicitly set.
the actual fault is portage
instead of half-assing all this DEPEND/RDEPEND garbage, why not fix portage to
do it consistently
either it implicitly sets
On Saturday 05 August 2006 16:07, Stephen P. Becker wrote:
Of course I know this, and it sucks. If sandbox is so tightly
integrated with portage, then why *isn't* there a portage team member
who works on sandbox?
because portage requires deep knowledge in python/bash
sandbox requires deep
On Sat, 2006-08-05 at 16:07 -0400, Stephen P. Becker wrote:
Mike Frysinger wrote:
On Saturday 05 August 2006 14:56, Stephen P. Becker wrote:
The metadata for sandbox suggests that it is under the control of the
portage team, even if they lack a herd:
... because it is tightly
not sure the impact of this, but i just finished fixing three packages with
this issue, and the problem arises due to system packages being updated ...
a recent upgrade with gettext causes some packages to fail with errors like:
/bin/sh: @MKINSTALLDIRS@: No such file or directory
if you hit
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mike Frysinger wrote:
On Saturday 05 August 2006 15:32, Zac Medico wrote:
The actual fault is in libpng-1.2.12-r1.ebuild where RDEPEND= should be
explicitly set.
the actual fault is portage
instead of half-assing all this DEPEND/RDEPEND
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mike Frysinger wrote:
On Saturday 05 August 2006 17:29, Zac Medico wrote:
I'm not satisfied with the current implicit RDEPEND behavior either. I
propose that we make repoman force explicit definition of RDEPEND.
and i'm on the opposite side
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi everyone,
The PDA herd is pretty slim right now and the only active members are
really liquidx and myself. That said I'm looking around for people
that can help with confirmations/patches/etc. for app-pda packages.
Plans are to hopefully pull
Hi
Ive cooked up a rudimentary hook system into portage-2.1.1_pre4-r2
If there is an API defined for functions that can be plugged
into emerge, this system can dynamically load any scripts in /etc/portage/portage.modules/
Theres a patch included in the bug on bugzilla, Im
looking
46 matches
Mail list logo
