Re: [gentoo-dev] New AT

[Homer Parker]

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 Tester Operational Lead
[EMAIL PROTECTED]


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New developer: Brent Baude (ranger)

[Omkhar Arasaratnam]

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
>platforms.
>
>While he does use Gentoo for his primary workstation and all his home
>boxes, Brent's interest in becoming a Gentoo developer is to help
>support the ppc64 and ppc archs for Gentoo. Of late, it's been in trying
>to whip the stage building and new livecds into shape.
>
>Brent is married and a father of two boys. When not working, he is an
>avid outdoors-man; specifically, he is most passionate about hunting
>pheasants, ducks and geese while training his two yellow Labrador
>Retrievers.
>
>Please say 'Hi' to Brent on IRC, and make him feel welcome.
>
>Regards,
>Tom
>
>  
>
Congrats ranger - good to have you on board.

-- 

Omkhar Arasaratnam
Gentoo PPC64 Developer
[EMAIL PROTECTED]



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] New AT

[Joseph Jezak]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Homer Parker wrote:
>   It seems the PPC peeps have done it again, it's with great pleasure
> that I announce their newest AT, nixnut. Please give him a warm welcome
> to the team. I know JoseJX said he had plenty of work for him, so he
> might be hard to find ;)
> 

Now that I have "minions" (note the plural), it's time to take over the
world!  MUAHAHA.

Congrats nixnut, and thanks hparker! :)
- -Joe
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCxNqZwGq7BLLARfoRAqTvAKCQGpfOo+0EexTQxOTs74HqxsF3ygCfUd84
yW0TypiHLyBj1LmR5NfCneQ=
=3b9D
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New AT

[Michael Curtis Napier]

--- Homer Parker <[EMAIL PROTECTED]> wrote:

> 
>   It seems the PPC peeps have done it again, it's with great pleasure
> that I announce their newest AT, nixnut. Please give him a warm
> welcome
> to the team. I know JoseJX said he had plenty of work for him, so he
> might be hard to find ;)
> 

Welcome aboard nixnut! 

M Curtis Napier
curtis119



__ 
Yahoo! Mail Mobile 
Take Yahoo! Mail with you! Check email on your mobile phone. 
http://mobile.yahoo.com/learn/mail 
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] New AT

[Homer Parker]

It seems the PPC peeps have done it again, it's with great pleasure
that I announce their newest AT, nixnut. Please give him a warm welcome
to the team. I know JoseJX said he had plenty of work for him, so he
might be hard to find ;)

-- 
Homer Parker
Gentoo/AMD64 Arch Tester Operational Lead
[EMAIL PROTECTED]


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] KDE 3.4.1 keyworded stable on x86, amd64

[Sven Vermeulen]

On Fri, Jul 01, 2005 at 12:07:19AM +0300, Dan Armak wrote:
> If you're using monolithic ebuilds (this include all 3.3.x ebuilds) consider 
> moving to the split ones: http://www.gentoo.org/doc/en/kde-split-ebuilds.xml

Don't forget to read the KDE Configuration HOWTO which also helps you a bit
on choosing interesting KDE ebuilds:
  http://www.gentoo.org/doc/en/kde-config.xml

Wkr,
  Sven Vermeulen

-- 
  Documentation project leader - Gentoo Foundation Trustee

  The Gentoo Project   <<< http://www.gentoo.org >>>


pgpk6vONkXn81.pgp
Description: PGP signature

Re: [gentoo-dev] Updating the list of non-SPARC herd devs keywording for SPARC

[Kumba]

Chris Gianelloni wrote:


Arches:

MIPS (I just got an Indy and a Challenge S, haven't loaded them up yet)


Drop us a note if/when you get these running.  If you're up for helping us out 
on releng stuff, I can provide oodles of info (and ideas) on how we have to do 
Netboots and my random forays into the liveCD structure (as you've seen me 
yammer on about in -releng)



--Kumba

--
Gentoo/MIPS Team Lead
Gentoo Foundation Board of Trustees

"Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere."  --Elrond

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: RFC: qt.eclass

[Thomas de Grenier de Latour]

On Thu, 30 Jun 2005 17:38:32 -0400
Aron Griffis <[EMAIL PROTECTED]> wrote:

> Well, it's more visible, but it doesn't stop the emerge.  I
> just put DEPEND="$(die)" into an ebuild to test.

Something that "works" better (ie., "makes portage stop during
metadata caching") is to put a non-zero return code in the
function in case of error, and then call die from the ebuild: 

 DEPEND="$(qt_min_version 3.3)" \
|| die "Error in DEPEND"

And sure, the error messages from the function should go to
stderr if you want to see them.

--
TGL.
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Bugday reminder

[Bryan Oestergaard]

Hi all!

Next Bugday is saturday July 2. 2005. As usual it will be held in
#gentoo-bugs on irc.freenode.net.

I hope to see lots of participants and that we can solve lots of bugs as
usual :)

Regards,
Bryan Østergaard

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: RFC: qt.eclass

[Aron Griffis]

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
DEPEND="$(die)" into an ebuild to test.  Here is what happens.  It
also gives you an idea of why putting functions into DEPEND is bad:
they get evaluated A LOT.  (jump down for more message content)

--

$ sudo emerge keychain

Performing Global Updates: /opt/agriffis/portage/profiles/updates/3Q-2004
(Could take a couple of minutes if you have a lot of binary packages.)
  .='update pass'  *='binary update'  @='/var/db move'
  s='/var/db SLOT move' S='binary SLOT move' p='update /etc/portage/package.*'
..
Calculating dependencies  
!!! ERROR: net-misc/keychain-2.5.4.1 failed.
!!! Function , Line 15, Exitcode 0
!!! (no error message)
!!! If you need support, post the topmost build error, NOT this status message.

  ...done!
>>> emerge (1 of 1) net-misc/keychain-2.5.4.1 to /

!!! ERROR: net-misc/keychain-2.5.4.1 failed.
!!! Function , Line 15, Exitcode 0
!!! (no error message)
!!! If you need support, post the topmost build error, NOT this status message.

>>> md5 src_uri ;-) keychain-2.5.4.1.tar.bz2

!!! ERROR: net-misc/keychain-2.5.4.1 failed.
!!! Function , Line 15, Exitcode 0
!!! (no error message)
!!! If you need support, post the topmost build error, NOT this status message.


!!! ERROR: net-misc/keychain-2.5.4.1 failed.
!!! Function , Line 15, Exitcode 0
!!! (no error message)
!!! If you need support, post the topmost build error, NOT this status message.

>>> Unpacking source...
>>> Unpacking keychain-2.5.4.1.tar.bz2 to /var/tmp/portage/keychain-2.5.4.1/work
>>> Source unpacked.

!!! ERROR: net-misc/keychain-2.5.4.1 failed.
!!! Function , Line 15, Exitcode 0
!!! (no error message)
!!! If you need support, post the topmost build error, NOT this status message.


!!! ERROR: net-misc/keychain-2.5.4.1 failed.
!!! Function , Line 15, Exitcode 0
!!! (no error message)
!!! If you need support, post the topmost build error, NOT this status message.

>>> Test phase [not enabled]: net-misc/keychain-2.5.4.1

!!! ERROR: net-misc/keychain-2.5.4.1 failed.
!!! Function , Line 15, Exitcode 0
!!! (no error message)
!!! If you need support, post the topmost build error, NOT this status message.


>>> Install keychain-2.5.4.1 into /var/tmp/portage/keychain-2.5.4.1/image/ 
>>> category net-misc
man:
prepallstrip:
strip: ia64-unknown-linux-gnu-strip --strip-unneeded
strip: ia64-unknown-linux-gnu-strip --strip-unneeded
>>> Completed installing keychain-2.5.4.1 into 
>>> /var/tmp/portage/keychain-2.5.4.1/image/

>>> Merging net-misc/keychain-2.5.4.1 to /

!!! ERROR: net-misc/keychain-2.5.4.1 failed.
!!! Function , Line 15, Exitcode 0
!!! (no error message)
!!! If you need support, post the topmost build error, NOT this status message.

--- /usr/
--- /usr/bin/
>>> /usr/bin/keychain
--- /usr/share/
--- /usr/share/doc/
--- /usr/share/doc/keychain-2.5.4.1/
>>> /usr/share/doc/keychain-2.5.4.1/README.gz
>>> /usr/share/doc/keychain-2.5.4.1/ChangeLog.gz
>>> /usr/share/doc/keychain-2.5.4.1/keychain.pod.gz
--- /usr/share/man/
--- /usr/share/man/man1/
>>> /usr/share/man/man1/keychain.1.gz
>>> Safely unmerging already-installed instance...

!!! ERROR: net-misc/keychain-2.5.4.1 failed.
!!! Function , Line 15, Exitcode 0
!!! (no error message)
!!! If you need support, post the topmost build error, NOT this status message.

--- !mtime obj /usr/share/man/man1/keychain.1.gz
--- !mtime obj /usr/share/doc/keychain-2.5.4.1/keychain.pod.gz
--- !mtime obj /usr/share/doc/keychain-2.5.4.1/README.gz
--- !mtime obj /usr/share/doc/keychain-2.5.4.1/ChangeLog.gz
--- !mtime obj /usr/bin/keychain
--- !empty dir /usr/share/man/man1
--- !empty dir /usr/share/man
--- !empty dir /usr/share/doc/keychain-2.5.4.1
--- !empty dir /usr/share/doc
--- !empty dir /usr/share
--- !empty dir /usr/bin
--- !empty dir /usr

!!! ERROR: net-misc/keychain-2.5.4.1 failed.
!!! Function , Line 15, Exitcode 0
!!! (no error message)
!!! If you need support, post the topmost build error, NOT this status message.

>>> original instance of package unmerged safely.

!!! ERROR: net-misc/keychain-2.5.4.1 failed.
!!! Function , Line 15, Exitcode 0
!!! (no error message)
!!! If you need support, post the topmost build error, NOT this status message.


 * Please see the Keychain Guide at
 * http://www.gentoo.org/doc/en/keychain-guide.xml
 * for help getting keychain running

>>> Regenerating /etc/ld.so.cache...
>>> net-misc/keychain-2.5.4.1 merged.

!!! ERROR: net-misc/keychain-2.5.4.1 failed.
!!! Functio

[gentoo-dev] New developer: Brent Baude (ranger)

[Tom Martin]

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
platforms.

While he does use Gentoo for his primary workstation and all his home
boxes, Brent's interest in becoming a Gentoo developer is to help
support the ppc64 and ppc archs for Gentoo. Of late, it's been in trying
to whip the stage building and new livecds into shape.

Brent is married and a father of two boys. When not working, he is an
avid outdoors-man; specifically, he is most passionate about hunting
pheasants, ducks and geese while training his two yellow Labrador
Retrievers.

Please say 'Hi' to Brent on IRC, and make him feel welcome.

Regards,
Tom

-- 
Tom Martin, http://dev.gentoo.org/~slarti
AMD64, net-mail, shell-tools, vim, recruiters
Gentoo Linux


pgpNxCz9aIMFC.pgp
Description: PGP signature

Re: [gentoo-dev] RFC: qt.eclass

[Olivier Crete]

On Thu, 2005-30-06 at 15:09 -0500, Caleb Tennis wrote:
> On Thursday 30 June 2005 03:01 pm, Thomas de Grenier de Latour wrote:
> > It seems that portage evaluates disjonction left to right and
> > stops on the first match it founds. Thus, if you want want it to
> > choose the best matching version, you should rather sort them in
> > decreasing order. (At least, that's what a small test with CVS
> > HEAD shows here.)
> 
> 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 
> it 
> really i

Why not just use =qt-3.3 since qt3 probably wont have any new major
release ?


-- 
Olivier Crête
[EMAIL PROTECTED]
Gentoo Developer
x86 Security Liaison


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: RFC: qt.eclass

[Dan Armak]

On Thursday 30 June 2005 23:36, Aron Griffis wrote:
> Dan Armak wrote:  [Thu Jun 30 2005, 04:06:03PM EDT]
>
> > Because the function takes a parameter - the minimal version
> > required from which to start the list in the ||.
>
> Makes sense.
>
> > Any everyone who thinks functions inside $DEPEND are iffy should
> > look at deprange() and deprange-dual()... /me hides
>
> They're definitely iffy.  Try this at a bash prompt:
>
> DEPEND="$(exit 1)"
>
> See the problem?  It didn't exit.  That's what will happen if
> a function in DEPEND fails: nothing.  Except that yours will currently
> stick this in DEPEND:
>
> !!! error: qt_min_version called with invalid parameter: \"$1\",
> please report bug
>
Instead of 'exit 1', qt_min_version should use die. I use that in deprange and 
it does work inside $DEPEND.

-- 
Dan Armak
Gentoo Linux developer (KDE)
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD  0069 508D 9143 8D5F 8951


pgpFR8CXBg7se.pgp
Description: PGP signature

[gentoo-dev] KDE 3.4.1 keyworded stable on x86, amd64

[Dan Armak]

Hi all,

We finally have a stable-keyworded KDE 3.4.x. Enjoy :-)

If you're using monolithic ebuilds (this include all 3.3.x ebuilds) consider 
moving to the split ones: http://www.gentoo.org/doc/en/kde-split-ebuilds.xml

There are no explicit instructions for upgrading from the monolithic to the 
split ebuilds there (TODO) and apparently that confused some people, so 
I'll summarize: 

When upgrading from KDE 3.3.x, you can just emerge split ebuilds freely.

When upgrading from KDE 3.4.x monolithic to 3.4.x split, it's easiest to first 
unmerge the monolithic ebuilds and then emerge the split ones. There are a 
few hours in between with nothing installed, so it's good for an overnight 
install. (You can do it for each monolithic package in turn.)

-- 
Dan Armak
Gentoo Linux developer (KDE)
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD  0069 508D 9143 8D5F 8951


pgptyCTW0s4aQ.pgp
Description: PGP signature

Re: [gentoo-dev] Re: RFC: qt.eclass

[Mike Frysinger]

On Thursday 30 June 2005 04:42 pm, Caleb Tennis wrote:
> On Thursday 30 June 2005 03:36 pm, Aron Griffis wrote:
> > See the problem?  It didn't exit.  That's what will happen if
> > a function in DEPEND fails: nothing.  Except that yours will currently
> > stick this in DEPEND:
> >
> > !!! error: qt_min_version called with invalid parameter: \"$1\",
> > please report bug
>
> No doubt, it's definitely a hack.  However, the only alternative that I can
> see is to rename the package (which I'm not opposed to doing).  That is,
> leave qt3 as "qt" and make qt4 "qt4".

i'd prefer to not split QT into sep packages
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: RFC: qt.eclass

[Caleb Tennis]

On Thursday 30 June 2005 03:36 pm, Aron Griffis wrote:
> See the problem?  It didn't exit.  That's what will happen if
> a function in DEPEND fails: nothing.  Except that yours will currently
> stick this in DEPEND:
>
> !!! error: qt_min_version called with invalid parameter: \"$1\",
> please report bug

No doubt, it's definitely a hack.  However, the only alternative that I can 
see is to rename the package (which I'm not opposed to doing).  That is, 
leave qt3 as "qt" and make qt4 "qt4".

emerge qt4

There's pros and cons to each way me thinks.

Caleb
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: RFC: qt.eclass

[Aron Griffis]

Dan Armak wrote:[Thu Jun 30 2005, 04:06:03PM EDT]
> Because the function takes a parameter - the minimal version
> required from which to start the list in the ||.

Makes sense.

> Any everyone who thinks functions inside $DEPEND are iffy should
> look at deprange() and deprange-dual()... /me hides

They're definitely iffy.  Try this at a bash prompt:

DEPEND="$(exit 1)"

See the problem?  It didn't exit.  That's what will happen if
a function in DEPEND fails: nothing.  Except that yours will currently
stick this in DEPEND:

!!! error: qt_min_version called with invalid parameter: \"$1\",
please report bug

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer



pgpExPqVfjVEn.pgp
Description: PGP signature

Re: [gentoo-dev] RFC: qt.eclass

[Caleb Tennis]

On Thursday 30 June 2005 03:01 pm, Thomas de Grenier de Latour wrote:
> It seems that portage evaluates disjonction left to right and
> stops on the first match it founds. Thus, if you want want it to
> choose the best matching version, you should rather sort them in
> decreasing order. (At least, that's what a small test with CVS
> HEAD shows here.)

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 it 
really is.

Caleb
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: RFC: qt.eclass

[Caleb Tennis]

On Thursday 30 June 2005 02:37 pm, Michael Sterrett -Mr. Bones.- wrote:
> Why use a function then?  Why not just supply a variable in the eclass that
> is put in the DEPEND?

Because you need to be able to specify what the minimum version of Qt you want 
is.  I suppose we could have 50 variables :

QT_MINIMUM_VERSION_3_0_0_RC_3="|| (x11-libs/qt-3.3.4-r5 
x11-libs/qt-3.3.4-r4 ... )"
QT_MINIMUM_VERSION_3_0_0_RC_2=...

DEPEND="$QT_MINIMUM_VERSION_3_0_0_RC_2"

A function seems a bit nicer.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: qt.eclass

[Thomas de Grenier de Latour]

On Thu, 30 Jun 2005 22:01:42 +0200
Thomas de Grenier de Latour <[EMAIL PROTECTED]> wrote:

> It seems that portage evaluates disjonction left to right and
> stops on the first match it founds.

Sure, the above holds only for picking a package to install when
the dep is not already satisfied. If a matching version of qt is
already there, then there is no such issue.

--
TGL. 
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: RFC: qt.eclass

[Dan Armak]

On Thursday 30 June 2005 22:37, Michael Sterrett -Mr. Bones.- wrote:
> On Thu, 30 Jun 2005, Caleb Tennis wrote:
> > Understandable, but I don't know any other way to do it.  The function
> > does nothing more than return a list of ebuild versions to make the
> > depend happy. It doesn't rely on anything dynamic.
> >
> > $(qt_min_version 3.3) == "|| ( =x11-libs/qt-3.3.3 =x11-libs/qt-3.3.3-r1
> > =x11-libs/qt-3.3.3-r2 =x11-libs/qt-3.3.3-r3 =x11-libs/qt-3.3.4 )
>
> Why use a function then?  Why not just supply a variable in the eclass that
> is put in the DEPEND?

Because the function takes a parameter - the minimal version required from 
which to start the list in the ||.

Any everyone who thinks functions inside $DEPEND are iffy should look at 
deprange() and deprange-dual()... /me hides

-- 
Dan Armak
Gentoo Linux developer (KDE)
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD  0069 508D 9143 8D5F 8951


pgp057Yns1Gpi.pgp
Description: PGP signature

Re: [gentoo-dev] RFC: qt.eclass

[Thomas de Grenier de Latour]

On Thu, 30 Jun 2005 14:33:04 -0500
Caleb Tennis <[EMAIL PROTECTED]> wrote:

> 
> $(qt_min_version 3.3) == "|| ( =x11-libs/qt-3.3.3
> =x11-libs/qt-3.3.3-r1 =x11-libs/qt-3.3.3-r2
> =x11-libs/qt-3.3.3-r3 =x11-libs/qt-3.3.4 )
> 

It seems that portage evaluates disjonction left to right and
stops on the first match it founds. Thus, if you want want it to
choose the best matching version, you should rather sort them in
decreasing order. (At least, that's what a small test with CVS
HEAD shows here.)

--
TGL. 
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: RFC: qt.eclass

[Michael Sterrett -Mr. Bones.-]

On Thu, 30 Jun 2005, Caleb Tennis wrote:

Understandable, but I don't know any other way to do it.  The function does
nothing more than return a list of ebuild versions to make the depend happy.
It doesn't rely on anything dynamic.

$(qt_min_version 3.3) == "|| ( =x11-libs/qt-3.3.3 =x11-libs/qt-3.3.3-r1
=x11-libs/qt-3.3.3-r2 =x11-libs/qt-3.3.3-r3 =x11-libs/qt-3.3.4 )


Why use a function then?  Why not just supply a variable in the eclass that
is put in the DEPEND?

Michael Sterrett
  -Mr. Bones.-
[EMAIL PROTECTED]
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: qt.eclass

[Caleb Tennis]

On Thursday 30 June 2005 02:15 pm, Mike Frysinger wrote:
> it depends on the information that the function acts upon ...
>
> if the results depend on stuff that is installed (i.e. things in
> /var/db/pkg) or env vars the user manipulates (like $SOME_FOO), then that's
> bad ... if the results depend on a variable that changes across ebuilds but
> retains the same value in a specific ebuild (like $PN or $PV), that is OK
> -mike

This function doesn't rely on anything that isn't directly within the eclass 
itself - ie, a static list of all of the Qt versions over the ages.  No files 
on the system or environment variables at all.

Caleb
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: qt.eclass

[Caleb Tennis]

On Thursday 30 June 2005 01:58 pm, Donnie Berkholz wrote:
> I'm no expert on portage, but running random functions in DEPEND sounds
> like a bad idea.

Understandable, but I don't know any other way to do it.  The function does 
nothing more than return a list of ebuild versions to make the depend happy.  
It doesn't rely on anything dynamic.

$(qt_min_version 3.3) == "|| ( =x11-libs/qt-3.3.3 =x11-libs/qt-3.3.3-r1 
=x11-libs/qt-3.3.3-r2 =x11-libs/qt-3.3.3-r3 =x11-libs/qt-3.3.4 )

In other words, it's just shorthand for explicitly listing all of the 
versions.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: qt.eclass

[Mike Frysinger]

On Thursday 30 June 2005 02:58 pm, Donnie Berkholz wrote:
> Caleb Tennis wrote:
> > DEPEND="$(qt_min_version 3.0)"
> > or
> > DEPEND="qt? ( $(qt_min_version 3.1.2-r2) )"
> >
> > And the eclass will expand out all Qt3 ebuilds which satisfy the
> > statement.
>
> I'm no expert on portage, but running random functions in DEPEND sounds
> like a bad idea.

it depends on the information that the function acts upon ...

if the results depend on stuff that is installed (i.e. things in /var/db/pkg) 
or env vars the user manipulates (like $SOME_FOO), then that's bad ... if the 
results depend on a variable that changes across ebuilds but retains the same 
value in a specific ebuild (like $PN or $PV), that is OK
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: qt.eclass

[Donnie Berkholz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Caleb Tennis wrote:
> DEPEND="$(qt_min_version 3.0)"
> or 
> DEPEND="qt? ( $(qt_min_version 3.1.2-r2) )"
> 
> And the eclass will expand out all Qt3 ebuilds which satisfy the statement.

I'm no expert on portage, but running random functions in DEPEND sounds
like a bad idea.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCxEDRXVaO67S1rtsRAvggAKDQ+Tpj6vywLVTFJ2vHqnLc0GH2jQCg6znN
p3amuxI6r84tb2dNOK5PmBo=
=Qvpf
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] remove app-doc/ebook-*

[Lance Albertson]

>> Wolfgang Illmeyer wrote:[Thu Jun 30 2005, 12:40:21PM EDT]
>>  
>>
>>> Calculating dependencies -
>>> emerge: there are no ebuilds to satisfy "dev-uitl/kdevelop".

I thought we fixed this problem.

-- 
Lance Albertson <[EMAIL PROTECTED]>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net


signature.asc
Description: OpenPGP digital signature

[gentoo-dev] RFC: qt.eclass

[Caleb Tennis]

(I'd like to hear your thoughts and comments on the matter below before I 
start the process of changing ebuilds to comply.)

With Qt4 entering portage, we are going to start running into a dependency 
problem with ebuilds that do:

DEPEND=">=x11-libs/qt-3.2"

Because Qt4 satisfies this depend even though it's not compatible.  Enter my 
proposed qt.eclass (which also replaces kde-functions.eclass for people who 
are using it strictly for Qt).

Now you can:

inherit qt

DEPEND="$(qt_min_version 3.0)"
or 
DEPEND="qt? ( $(qt_min_version 3.1.2-r2) )"

And the eclass will expand out all Qt3 ebuilds which satisfy the statement.

If you don't need anything this fancy (that is, if the ebuild will work with 
any Qt3 version), then the eclass isn't necessary; just change the ebuild to:

DEPEND="x11-libs/qt-3*" 

As an added bonus, you get an exported pkg_setup function which will handle 
some of the same checks that were handled via kde-functions.

Thanks,
Caleb
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] remove app-doc/ebook-*

[Aron Griffis]

Wolfgang Illmeyer wrote:[Thu Jun 30 2005, 01:07:35PM EDT]
> I did spell it right:
> 
> # emerge -pv ebook-binutils

Ah sorry, I misunderstood the problem.

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer



pgpk7wJATpoAz.pgp
Description: PGP signature

Re: [gentoo-dev] remove app-doc/ebook-*

[Joseph Pingenot]

>From Wolfgang Illmeyer on Thursday, 30 June, 2005:
>already synced twice today, but the error didn't go away...

Because of weird caching things that I don't understand (anyone from
  portage group want to explain?), you likely need to lobotomize portage
  as described in bug 8335:

http://bugs.gentoo.org/show_bug.cgi?id=85335

Unless some portage mirror somewhere has reverted to the Old Crufty Bug?

-Joseph

>Mark Loeser wrote:
>>Wolfgang Illmeyer wrote:
>>>BTW:
>>># emerge -pv ebook-binutils
>>>These are the packages that I would merge, in order:
>>>Calculating dependencies -
>>>emerge: there are no ebuilds to satisfy "dev-uitl/kdevelop".
>>>I can't find no dev-uitl/kdevelop... somebody should put that into the
>>>portage tree ;)
>>This was a problem with the eclass that was fixed a while back.  Try
>>syncing again.


-- 
[EMAIL PROTECTED]
  Graduate Student in Physics, Freelance Free Software Developer
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] remove app-doc/ebook-*

[Wolfgang Illmeyer]

I did spell it right:

# emerge -pv ebook-binutils


Aron Griffis wrote:


Wolfgang Illmeyer wrote:[Thu Jun 30 2005, 12:40:21PM EDT]
 


Calculating dependencies -
emerge: there are no ebuilds to satisfy "dev-uitl/kdevelop".
   



Try spelling it right.

--
Aron Griffis
Gentoo Linux Developer

 



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] remove app-doc/ebook-*

[Aron Griffis]

Wolfgang Illmeyer wrote:[Thu Jun 30 2005, 12:40:21PM EDT]
> Calculating dependencies -
> emerge: there are no ebuilds to satisfy "dev-uitl/kdevelop".

Try spelling it right.

--
Aron Griffis
Gentoo Linux Developer



pgpFZNEoYXLLd.pgp
Description: PGP signature

Re: [gentoo-dev] remove app-doc/ebook-*

[Wolfgang Illmeyer]

already synced twice today, but the error didn't go away...

Mark Loeser wrote:

  Wolfgang Illmeyer wrote:
  
  
BTW:

# emerge -pv ebook-binutils

These are the packages that I would merge, in order:

Calculating dependencies -
emerge: there are no ebuilds to satisfy "dev-uitl/kdevelop".

I can't find no dev-uitl/kdevelop... somebody should put that into the
portage tree ;)

  
  
This was a problem with the eclass that was fixed a while back.  Try
syncing again.

Mark
  

Re: [gentoo-dev] remove app-doc/ebook-*

[Mark Loeser]

Wolfgang Illmeyer wrote:
> BTW:
> 
> # emerge -pv ebook-binutils
> 
> These are the packages that I would merge, in order:
> 
> Calculating dependencies -
> emerge: there are no ebuilds to satisfy "dev-uitl/kdevelop".
> 
> I can't find no dev-uitl/kdevelop... somebody should put that into the
> portage tree ;)

This was a problem with the eclass that was fixed a while back.  Try
syncing again.

Mark


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Updating the list of non-SPARC herd devs keywording for SPARC

[Marius Mauch]

On Wed, 29 Jun 2005 21:46:31 -0600
Jason Wever <[EMAIL PROTECTED]> wrote:

> Hi All,
> 
> In the past, a few folks that aren't part of the SPARC herd had
> communicated that they had the ability to actually test packages on
> SPARC hardware and been giving the blessing of the SPARC team to
> keyword select packages.

Just for reference: portage and gentoolkit follow the portage
keywording policy instead of the normal one -> tested on one arch,
keyworded on all (as this was recently reconfirmed by all arch
maintainers).

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.


pgprWhiphmuSM.pgp
Description: PGP signature

Re: [gentoo-dev] remove app-doc/ebook-*

[Wolfgang Illmeyer]

BTW:

# emerge -pv ebook-binutils

These are the packages that I would merge, in order:

Calculating dependencies -
emerge: there are no ebuilds to satisfy "dev-uitl/kdevelop".

I can't find no dev-uitl/kdevelop... somebody should put that into the
portage tree ;)

Wolfgang

Mike Frysinger wrote:

  On Thursday 30 June 2005 08:31 am, 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.

  
  
i dont see how downloading/unpacking/moving files around is easier than 
`emerge ebook-blah`

do you have a reason for wanting them removed ?
-mike

  

Re: [gentoo-dev] remove app-doc/ebook-*

[Mike Frysinger]

On Thursday 30 June 2005 08:31 am, 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.

i dont see how downloading/unpacking/moving files around is easier than 
`emerge ebook-blah`

do you have a reason for wanting them removed ?
-mike

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Updating the list of non-SPARC herd devs keywording for SPARC

[Chris Gianelloni]

On Wed, 2005-06-29 at 21:46 -0600, Jason Wever wrote:
> Please contact me privately if you are missing from this list but have
> notified the SPARC team in the past about an ability to keyword or if
> you need to update what information is on the list.

I am doing this on-list simply to make things easier, since I'll list
everything I've got and am able to test.

For all of these, I will only be touching packages that I either
maintain, or am a member of the maintaining herd.  This boils down to a
few locations:

dev-games
games-*
sys-apps/* (if owned by livecd herd)
app-misc/livecd-tools
dev-util/catalyst
dev-util/livecd-{kconfigs,specs}

Arches:

Alpha
AMD64
HPPA
MIPS (I just got an Indy and a Challenge S, haven't loaded them up yet)
PPC
SPARC
x86

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux


signature.asc
Description: This is a digitally signed message part

[gentoo-dev] remove app-doc/ebook-*

[José Alberto Suárez López]

Hi,

i think that all the ebook-* ebuilds must be removed. Is more easy to
dowload the ebooks from the official web.

somebody want to maintain this ebuilds for a good reason?

regards


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] New virtual: virtual/pcmcia

[Ned Ludd]

On Thu, 2005-06-30 at 11:48 +0200, Henrik Brix Andersen wrote:
> On Wed, 2005-06-29 at 11:18 +0200, Henrik Brix Andersen wrote:
> > For this to work, a new package called pcmciautils [1] will need to be
> > added to portage. Therefore, a new virtual/pcmcia (which will default to
> > sys-apps/pcmcia-cs in base/virtuals for now) will be added as well.
> 
> ... and it is done.
> 
> According to Dominik Brodowski, the author of pcmciautils, Gentoo is the
> first distribution to include pcmciautils.

On that note.. Would you mind compiling it one time with a gcc built 
with +boundschecking and then enabling CFLAGS+= -fbounds-checking as a
basic q/a check. Reason being that if nobody has ever included it
anywhere the chances of it being audited are slim to none and
-fbounds-checking helps ferret out alot of common coding mistakes.
gcc-3.4.4 works good for this.

thanks in advance.

> 
> Sincerely,
> Brix


-- 
Ned Ludd <[EMAIL PROTECTED]>

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New virtual: virtual/pcmcia

[Henrik Brix Andersen]

On Wed, 2005-06-29 at 11:18 +0200, Henrik Brix Andersen wrote:
> For this to work, a new package called pcmciautils [1] will need to be
> added to portage. Therefore, a new virtual/pcmcia (which will default to
> sys-apps/pcmcia-cs in base/virtuals for now) will be added as well.

... and it is done.

According to Dominik Brodowski, the author of pcmciautils, Gentoo is the
first distribution to include pcmciautils.

Sincerely,
Brix
-- 
Henrik Brix Andersen <[EMAIL PROTECTED]>
Gentoo Metadistribution | Mobile computing herd


signature.asc
Description: This is a digitally signed message part