Tom Martin wrote:
Hi list,
Brent lives in Rochester, Minnesota, in the US. There he fills his days
working for the IBM Corporation as a Team LEad and Linux Consultant,
where his primary responsibility is to help people port hteir
applications to Linux running on the IBM POWER4, POWER5, and JS20
On Fri, 2005-07-01 at 01:54 -0400, Joseph Jezak wrote:
Now that I have minions (note the plural), it's time to take over
the
world! MUAHAHA.
lol
Congrats nixnut, and thanks hparker! :)
No problem.. just don't work them /too/ hard ;)
--
Homer Parker
Gentoo/AMD64 Arch
On Friday 01 July 2005 00:38, Aron Griffis wrote:
Dan Armak wrote: [Thu Jun 30 2005, 05:11:10PM EDT]
Instead of 'exit 1', qt_min_version should use die. I use that in
deprange and it does work inside $DEPEND.
Well, it's more visible, but it doesn't stop the emerge. I just put
On Thursday 30 June 2005 23:11, Dan Armak wrote:
Instead of 'exit 1', qt_min_version should use die. I use that in
deprange and it does work inside $DEPEND.
Wouldn't this be a good time to implement actual dependency ranges in
portage. Btw. I normally use the following hack that portage might
On Friday 01 July 2005 12:15, Paul de Vrieze wrote:
On Thursday 30 June 2005 23:11, Dan Armak wrote:
Instead of 'exit 1', qt_min_version should use die. I use that in
deprange and it does work inside $DEPEND.
Wouldn't this be a good time to implement actual dependency ranges in
portage.
On Friday 01 July 2005 11:55, Chris Bainbridge wrote:
On 30/06/05, Olivier Crete [EMAIL PROTECTED] wrote:
On Thu, 2005-30-06 at 15:09 -0500, Caleb Tennis wrote:
I'm sorry, yes, that's what I do in this case.
Also, the eclass is in portage if anyone is so inclined to see how
harmless
On Friday 01 July 2005 14:28, Dan Armak wrote:
On Friday 01 July 2005 12:15, Paul de Vrieze wrote:
On Thursday 30 June 2005 23:11, Dan Armak wrote:
Instead of 'exit 1', qt_min_version should use die. I use that in
deprange and it does work inside $DEPEND.
Wouldn't this be a good time
Francesco R wrote:
[snip]
s/
# example:
###MY_VER_RANGE 4.0 4.0.16
###MY_VER_RANGE 4.1 4.1.4
###MY_VER_RANGE 5.0
# if a patch contains these three lines then:
# all version = 4.0 but 4.0.16,
# all version = 4.1 but 4.0.16,
# all version = 5.0 will be affected by this patch
/
example:
On Friday 01 July 2005 16:56, Aron Griffis wrote:
Dan Armak wrote: [Fri Jul 01 2005, 03:42:22AM EDT]
...OK, so deprange() needs to signal errors out-of-band. Like setting a
KM_ERROR variable which causes the eclass to abort later on.
Heh, doesn't work for the same reason you can't
On Friday 01 July 2005 08:56 am, Aron Griffis wrote:
How about this?
ebuild:
DEPEND=some stuff
qt_min_dep 3.3
How do you handle the ebuilds which use the qt use flag to determine whether
or not that qt is a dependency?
Caleb
--
gentoo-dev@gentoo.org mailing list
On Fri, 1 Jul 2005 17:45:57 +0300
Dan Armak [EMAIL PROTECTED] wrote:
I'd rather signal failure to code outside the subshell by
touching a file in $T.
The ${T} directory does not exists when portage source an ebuild
to get its metadatas, so I'm not sure that's a good idea.
Btw, what's
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thomas de Grenier de Latour wrote:
Btw, what's wrong with the `DEPEND=$(your_function) || die`
i've proposed? Using a return code seems to be the simplest way
to signal a failure, no?
calling a function in a global scope is a bad idea. it
On Friday 01 July 2005 18:14, Jonathan Smith wrote:
- gpg control packet
Thomas de Grenier de Latour wrote:
Btw, what's wrong with the `DEPEND=$(your_function) || die`
i've proposed? Using a return code seems to be the simplest way
to signal a failure, no?
calling a function in a
On Friday 01 July 2005 18:03, Thomas de Grenier de Latour wrote:
On Fri, 1 Jul 2005 17:45:57 +0300
Dan Armak [EMAIL PROTECTED] wrote:
I'd rather signal failure to code outside the subshell by
touching a file in $T.
The ${T} directory does not exists when portage source an ebuild
to get
Caleb Tennis wrote:
snip
2. You'll force a user to upgrade to qt 3.3 if they attempt to install any
package that depends on Qt. Speaking from personal experience, I still have
some servers using Qt 3.1 because I have programs running 24/7 that rely on
Qt and simply cannot be upgraded right
On Friday 01 July 2005 10:35 am, Alec Joseph Warner wrote:
You don't force anyone to do anything. If they don't want to upgrade
because they can't then they can p.mask the programs they can't upgrade.
But this isn't about upgrading Qt, it's about the packages that depend on it.
If you
Hola.
Quick statement of terminology-
x-compile == cross compiling, building arm crap on an x86, building up
a x-compile target in a subdirectory of / (fex)
Currently, we pretty much leave out the big dogs of build depends from
ebuilds- basically we rely on the profile to require a suitable
Dan Armak wrote:
Hi all,
We finally have a stable-keyworded KDE 3.4.x. Enjoy :-)
ppc64 is stable, too! :-)
Markus
pgpzZv2lEkkce.pgp
Description: PGP signature
On Friday 01 July 2005 12:25 pm, Brian D. Harring wrote:
Currently, we pretty much leave out the big dogs of build depends from
ebuilds- basically we rely on the profile to require a suitable
toolchain. Couple of issues with this though-
1) Deps aren't complete for an ebuild.
2) Merging a
On Friday 01 July 2005 18:25, Brian D. Harring wrote:
So... why don't we add a new DEPEND, BDEPEND (build depends), that
holds atoms of what is required to actually build the package,
literally, what executes on the box to build that package.
Ok trying to get this a bit more clean to tech
On Friday 01 July 2005 19:49, Mike Frysinger wrote:
so what you're proposing is that we add binutils/gcc/glibc to every package
that compiles something, make to every package that uses make,
sed/grep/bash/coreutils to every package which runs configure, and
tar/gzip/bzip2 to every package
On Fri, Jul 01, 2005 at 01:49:19PM -0400, Mike Frysinger wrote:
On Friday 01 July 2005 12:25 pm, Brian D. Harring wrote:
Currently, we pretty much leave out the big dogs of build depends from
ebuilds- basically we rely on the profile to require a suitable
toolchain. Couple of issues with
If the point is to make dependencies complete, isn't there a way to
build in some support for detecting it into some tool or other?
If we have a program that can create an environment and detect which
programs are run within the environment (maybe sandbox can do this,
maybe something with
On Friday 01 July 2005 20:11, Brian D. Harring wrote:
Regarding the require whatever is used to uncompress the source,
hadn't thought about it, but that _should_ be specified imo. That's
also being a bit anal, but frankly, if the resolver can handle it, why
shouldn't we specify the full deps?
On Fri, Jul 01, 2005 at 02:30:12PM -0400, Mike Frysinger wrote:
On Friday 01 July 2005 02:11 pm, Brian D. Harring wrote:
Meanwhile, back to the you want us to add what?, our dependency
graph *is* incomplete.
so what ? i dont see it being a bug
I do. :)
We do a lot of work to have deps
On Fri, Jul 01, 2005 at 08:35:36PM +0200, Maurice van der Pot wrote:
If the point is to make dependencies complete, isn't there a way to
build in some support for detecting it into some tool or other?
If we have a program that can create an environment and detect which
programs are run
Full dependency information hasn't be viable due to resolver issues,
which will be fixed.
so why dont you come back once you have something that is supposed to work
?
you're proposing we start generating a ton of circular dependencies which
we
arent even close to handling
On Friday 01 July 2005 20:42, Brian D. Harring wrote:
Err... missing the point, and proving my point. Current portage
_will_ fail because it's an unstated dependency. Why shouldn't
portage be provided the deps it needs so it can figure out what is
needed to get to what the user requested?
On Fri, Jul 01, 2005 at 01:45:20PM -0500, Brian D. Harring wrote:
Not tenuable
What you're effectivelly suggesting is that portage stomp ahead and,
hit a failure, try and figure out what atom would fix the failure,
retry, wash rinse repeat.
No, I'm not talking about that. I'm talking
On Fri, Jul 01, 2005 at 08:53:18PM +0200, Diego 'Flameeyes' Pettenò wrote:
On Friday 01 July 2005 20:42, Brian D. Harring wrote:
Err... missing the point, and proving my point. Current portage
_will_ fail because it's an unstated dependency. Why shouldn't
portage be provided the deps it
On Fri, Jul 01, 2005 at 08:56:45PM +0200, Maurice van der Pot wrote:
On Fri, Jul 01, 2005 at 01:45:20PM -0500, Brian D. Harring wrote:
Not tenuable
What you're effectivelly suggesting is that portage stomp ahead and,
hit a failure, try and figure out what atom would fix the failure,
On Fri, Jul 01, 2005 at 02:12:07PM -0500, Brian D. Harring wrote:
Best solution in my opinion for such a tool is abuse of binpkgs +
chroot for testing, but that's beyond portage's focus, should be an
external tool.
This is why I was only talking about build dependencies.
A tool to do
On Friday 01 July 2005 17:14, Jonathan Smith wrote:
Thomas de Grenier de Latour wrote:
Btw, what's wrong with the `DEPEND=$(your_function) || die`
i've proposed? Using a return code seems to be the simplest way
to signal a failure, no?
calling a function in a global scope is a bad
On Friday 01 July 2005 20:53, Diego 'Flameeyes' Pettenò wrote:
On Friday 01 July 2005 20:42, Brian D. Harring wrote:
Err... missing the point, and proving my point. Current portage
_will_ fail because it's an unstated dependency. Why shouldn't
portage be provided the deps it needs so it
On Friday 01 July 2005 23:19, Paul de Vrieze wrote:
On Friday 01 July 2005 17:14, Jonathan Smith wrote:
Thomas de Grenier de Latour wrote:
Btw, what's wrong with the `DEPEND=$(your_function) || die`
i've proposed? Using a return code seems to be the simplest way
to signal a
On Thursday 30 June 2005 14:31, José Alberto Suárez López wrote:
i think that all the ebook-* ebuilds must be removed. Is more easy to
dowload the ebooks from the official web.
Sorry to reply to this just now but..
why don't try to use a script like the one Chris Write wrote for KDE themes?
Hi all,
I've just removed a few deprecated profiles for amd64, and saw that
there are still quite a lot of non-cascading profiles around.
The following profiles say they have been removed by 2005.04.01:
default-sparc-1.4
default-sparc-2004.0
default-sparc64-1.4
On Fri, 2005-07-01 at 23:48 +0200, Simon Stelling wrote:
I've just removed a few deprecated profiles for amd64, and saw that
there are still quite a lot of non-cascading profiles around.
The following profiles say they have been removed by 2005.04.01:
default-sparc-1.4
Mike Frysinger [EMAIL PROTECTED] wrote:
On Friday 01 July 2005 12:25 pm, Brian D. Harring wrote:
Currently, we pretty much leave out the big dogs of build depends from
ebuilds- basically we rely on the profile to require a suitable
toolchain. Couple of issues with this though-
so what
On Jul 1, 2005, at 5:59 PM, Drake Wyrm wrote:
Mike Frysinger [EMAIL PROTECTED] wrote:
On Friday 01 July 2005 12:25 pm, Brian D. Harring wrote:
Currently, we pretty much leave out the big dogs of build depends
from
ebuilds- basically we rely on the profile to require a suitable
toolchain.
Dan Armak wrote:[Fri Jul 01 2005, 10:45:57AM EDT]
Would work, but be against the general move to make the general ebuild
section
purely declarative :-(
Ok, but DEPEND=$(some-function) is no more declarative. The
function is evaluated at the time that the ebuild is read, not later
when
Caleb Tennis wrote:[Fri Jul 01 2005, 10:48:38AM EDT]
On Friday 01 July 2005 08:56 am, Aron Griffis wrote:
How about this?
ebuild:
DEPEND=some stuff
qt_min_dep 3.3
How do you handle the ebuilds which use the qt use flag to determine whether
or not that qt is a dependency?
Chris Gianelloni posted [EMAIL PROTECTED],
excerpted below, on Fri, 01 Jul 2005 18:01:43 -0400:
Last time that I checked, each arch needs at least one non-cascaded
profile, due to older versions of portage not working with cascaded
profiles. Either this, or users will not be able to upgrade
Maurice van der Pot posted [EMAIL PROTECTED],
excerpted below, on Fri, 01 Jul 2005 20:35:36 +0200:
If the point is to make dependencies complete, isn't there a way to
build in some support for detecting it into some tool or other?
If we have a program that can create an environment and
Hola.
Quick statement of terminology-
x-compile == cross compiling, building arm crap on an x86, building up
a x-compile target in a subdirectory of / (fex)
Currently, we pretty much leave out the big dogs of build depends from
ebuilds- basically we rely on the profile to require a suitable
45 matches
Mail list logo
