[gentoo-dev] net-im/ejabberd up for grabs

2009-01-30 Thread Caleb Tennis
I was maintaining this on behalf of some folks previously, but it could use a 
new
maintainer if someone is so inclined.

Caleb




[gentoo-dev] Unmasking db 4.6

2008-04-25 Thread Caleb Tennis
Does anyone have any objections to unmasking db 4.6.21?  It's been in portage 
now
for a long time, but was quickly masked when some packages had some issues with 
it. 
The only remaining package that has an issue that I'm aware of is openldap, and 
I've
submitted a patch that makes openldap just use a lower installed db version.

Any other packages that need looked at, or does anyone else have thoughts or
objections?

Thanks,
Caleb

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



Re: [gentoo-dev] Help offered - Portage tree

2008-03-13 Thread Caleb Tennis
 +1 on that and if people who use binary pkgs don't tell us what breaks,
 we won't know.

I'll kick it off, then.

The binpkg format needs some way to store the actual versions of the 
dependencies as
they were on the machine the package was compiled on.  Then, when emerging the
binpkg, someway to force those dependencies on the new install machine would be
nice.

I'll give an example.  Package A was built on machine 1, and has a dep on
=openssl-0.9.7.  Machine 1 has openssl-0.9.8 already installed.  Binary package
built, no problem.

Now, we attempt to install binary package A on machine 2, which has 
openssl-0.9.7. 
It installs fine, deps met.  But, whoops, there's some symbols missing when we 
go to
use package A on machine 2.  After some time, we finally realize it's because we
need new openssl.

I use this example because it's actually hit me before, but it extends to lots 
of
other scenarios.  The obvious fix is to either use --deep, or just make sure you
need machine 2 up to date with machine 1, though that's difficult to do when 
you're
talking about machine 301 and machine 559.

If there was a way to tell the bin package installer to make sure you met all 
of the
same minimum verisons of the deps as they were on the original compiling 
machine,
that would be fantastic.

Now, I'm happy to file a bug and assign it (to the portage team?), but I view 
this
really as a wishlist item, and since admittedly very few devs use the binpkg 
stuff,
I didn't see it as something that would probably get acted upon anyway.  I'm not
complaining about that either, just merely stating a fact.

Caleb

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



Re: [gentoo-dev] Help offered - Portage tree

2008-03-13 Thread Caleb Tennis
 Isn't that stored in the NEEDED file?

It very well might be, I'm not much of an expert here :)

 I think binpkgs store more information than you think.  It's just that
 Portage doesn't fully use it (yet).

This is good information to know.  Thanks!

Caleb

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



Re: [gentoo-dev] Help offered - Portage tree

2008-03-13 Thread Caleb Tennis
 I think remi was more speaking about incorrect deps (say misplaced in
 RDEPEND) than problems concerning the package manager.

 In any case, openssl is the perfect example of what can go wrong because
 of upstream's behavior. The problem is that program A compiled against
 version X of openssl won't work with version YX. Currently we need to
 keep X's libs around and run revdep-rebuild to fix this.

Right, my example was mildly contrived.  But I've run into this same issue with
packages like ruby and glibc, where the build system had newer versions and you 
run
into symbol issues (or errors like invalid binary format) because you need to
upgrade underlying libraries.

 Most librairies don't cause this problem though so I don't really see
 this as a bug on the gentoo side even if it's annoying.

It's not really Gentoo's fault, no, but it's a problem that could be somewhat 
fixed.

 Anyway, to keep machines using binary in sync without much headache, my
 current solution is to use a squashfsed portage tree with --deep. It
 works pretty well.

Agreed, but the problem is (at least in my case) we're talking about production
machines that are actively running, and the customer needs an upgrade of a 
package
but we don't want to take a chance at ruining something else by upgrading 
--deep if
we can help it.

From their perspective, they just want it to work (and don't care about what 
has to
be upgraded), but from a sysadmin perspective it's a difficult problem to solve 
over
time, especially when you have 10+ other sysadmins, who all may not know that 
when
you upgrade package X be sure to remember to also upgrade packages Y and Z at 
the
same time or you'll run into problems.

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



[gentoo-dev] Move SCMs to their own category?

2008-02-01 Thread Caleb Tennis
Hi,

It seems like all source control/revision control programs live in dev-util, but
they might be better served in something like dev-scm or something like that.  
I'm
thinking things like darcs, git, cvs, svn, mercurial, bzr.  Then the slew of
packages that depend on them: gitosis, bzrtools.

Any objections to this potential move, or comments on a better category name?

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



Re: [gentoo-dev] sqlite/sqlite3 useflag inconsistency

2008-01-17 Thread Caleb Tennis

 If a program supports both then go with sqlite3. The things is that
 there are sqlite2 only things left. I don't have much interest in sqlite2.

For anyone interested: I dropped sqlite2 from the new qt-4.4 currently masked in
portage.  I also made it so that the sqlite flag just turns on sqlite3, per the
conversation we've previously had about this.

Caleb

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



Re: [gentoo-dev] Monthly Gentoo Council Reminder for January

2008-01-09 Thread Caleb Tennis
 Why taking it against arch teams? How is that different from certain
 maintainer not taking care of a bug that holds stabilization of certain
 package by some time measured in months ? I'll tell you my answer: 'no
 difference at all'.

You are right, there's not much difference.  However, I brought up the topic 
because
I felt like this particular situation was a bit of a problem that needed to be
addressed.  Yours is also one that can/should potentially be addressed, and I 
advise
you to recommend the council discuss it as well.

My goal wasn't to point fingers or to call anyone lazy.  My goal was to address 
that
if development in this certain area has stagnated, how can those of us who it
affects continue to move forward?  This is simply an area that is gray and 
needs
to be discussed.  There are many other gray areas that need to be discussed too.

I understand we all have real lives and are volunteers.  But if there are areas 
that
we are responsible for and we aren't able to meet the needs/demands of the other
developers in those areas, it's only fair to let them continue moving forward.

I never even mentioned any specific arch in my original request, nor did I call 
any
developer out.  So please, nobody needs to take this personally.

Caleb

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



Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January

2008-01-09 Thread Caleb Tennis
 I'd imagine most of them are staying well clear of it because they've
 already seen this discussion a dozen times before and know that it's
 just the usual malcontents going around making largely bogus claims and
 backing them up with lots of thinly veiled mips bashing rather than
 anything relevant...

Your demand for evidence in this thread doesn't seem balanced with your ability 
to
only offer speculation.

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



Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January

2008-01-09 Thread Caleb Tennis
 The issue was raised, with absolutely no proof or justification, and
 every previous time said issue has been raised it's turned out to be
 somewhere between highly misleading and utter bollocks.

Let's assume that you are right, and that dropping keywords is not a proper 
thing to
do.

What's the proper fix for when keyword requests stagnate in bugzilla?  If the 
arch
team in question was to completely disband and stop all keywording today, then
you're suggesting the proper thing to do is to never remove the ebuild from 
portage
that has keywords for that arch?

And thus, the current system of filing a stabilization request and waiting
indefinitely is sufficient?

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



Re: [gentoo-dev] Monthly Gentoo Council Reminder for January

2008-01-09 Thread Caleb Tennis
 Correct, you did not.  What I find absolutely *damning* is the fact that
 as soon as any arches *were* mentioned, everybody was talking about the
 same one.  It's rather funny that everybody seems to have the exact same
 impression of what architecture might be a slacker and would be affected
 by this.  I wonder why that is?

Righto.  I also have specific mips related issues, and while I'm certain all of 
the
mips conversation will play on lots of people's minds, I think it also is 
helpful
from the council point of view to address this generically as it may be a 
problem
for a different arch in the future.

In other words, if people want to use mips as an example, then so be it, but
whatever resolution eventually comes to play shouldn't be mips specific.



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



Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January

2008-01-05 Thread Caleb Tennis
 If anyone has any examples of where they really are being held back and
 where they really have given the arch teams plenty of time to do
 something, I'd like to see them... Somehow I doubt it happens very
 often, if at all.

Why?  You aren't the person I or anyone else has to make a case to.  In fact, I
never would have mailed the list about this to prevent this very type of
potentially-out-of-control discussion from occurring, except that the e-mail 
from
Mike said that discussion topics needed to be sent to the list.

We currently get rid of packages that are unmaintained or are old enough that 
they
pose technical problems for developers with today's tools.  I see no difference 
in
establishing some similar kinds criteria for arch team keywords (which I'm not 
even
asking for.  I'm simply asking for dialogue to determine what kinds of criteria
would be appropriate, if any).

Similarly, what would the Gentoo policy be if at some time in the future an arch
team had no members?  What if it had two members, but they were unable to keep 
up
with stabilization requests and were running 6-12 months behind?  Sorry, there
isn't anybody who can mark that stable, but we're hoping to get someone on the 
team
this year isn't a valid answer in my book.

I have no idea what the process is to add an officially support arch to the 
tree,
but certainly it's more than just one guy making a few commits.  There's some
process that has to be gone through, right?  Well, there also needs to be an 
exit
strategy for when lack of interest in maintenance no longer means that arch 
should
be supported.  But right now, all I'm asking for it when it's appropriate for an
ebuild maintainer to not have to spend any more time waiting for the arch team 
to
respond to requests.  If you believe that number is 1 billion days, fine.  
Those of
us who have faced the issue and disagree can also make our opinions heard to the
council, and let them decide what should be done, again, if anything.

-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January

2008-01-04 Thread Caleb Tennis

 Most of the time, when people are moaning about 'slacker' archs, they
 don't have any kind of decent technical reason for doing so... In cases
 where such a reason exists, the arch teams are usually quite happy to
 prioritise if asked.

And the point of me asking for the council to talk about this is to set some 
kind of
guidelines for what happens after you've asked X number of times and let Y 
number of
days go by, where X and Y are amounts open for discussion.

Caleb


-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January

2008-01-04 Thread Caleb Tennis
 X and Y are pretty much irrelevant. The important factor is Z, the
 impact of leaving things the way they are.

Well, I'm asking the council to discuss when pretty much irrelevant no longer
applies.

-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Monthly Gentoo Council Reminder for January

2008-01-03 Thread Caleb Tennis
 If you have something you'd wish for us to chat about, maybe even
 vote on, let us know !  Simply reply to this e-mail for the whole
 Gentoo dev list to see.

I would like to request the council discuss, though not necessarily take action 
or
vote on, the idea of slacker arches and what ebuild maintainers are 
allowed/can do
to a package versions that are languishing due to not getting stable keywords on
those arches.

I'm not trying to pick on any specific case, but I am hoping to find out if 
there's
an allowable/acceptable period of time to which if an arch team is unable to
stabilize a package to a newer version, for non-technical reasons, that it's 
okay to
drop older unstable ebuilds.

I realize this is open to lots of debate and dicussion, and I'm just trying to 
have
a dialogue as to what is acceptable and hopefully get concensus as to some kind 
of
guidance that could be added to the devmanual.

Thanks,
Caleb

-- 
[EMAIL PROTECTED] mailing list



[gentoo-dev] EAPI checking in eclasses

2007-12-31 Thread Caleb Tennis
Is it legal for an eclass to check the EAPI version (presumably by using the 
EAPI
variable) and perform some dependent behavior based on what it sees?  I don't 
see
any eclasses using EAPI for anything, so I'm curious.


-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Project Update: qt-4

2007-12-21 Thread Caleb Tennis
This is a followup that I am now committing qt4-build.eclass with a lot of the
redundant functions for building Qt4 put into it.

The only packages that use/depend on it are currently masked, so feel free to
comment here with things you'd like to see changed in the eclass.

Caleb

-- 
[EMAIL PROTECTED] mailing list



[gentoo-dev] Project Update: qt-4

2007-12-20 Thread Caleb Tennis
Just a quick update on the happens in the x11-libs/qt world, as I'm introducing 
some
changes that will probably affect people in the not-to-distant future.

Since Qt is starting to get rather, ahem, big, I've decided that with the
introduction of version 4.4 it's a good time to try and split it down into more
manageable chunks.  I'm introducing a few new packages that are designed to 
break
out some of the major pieces into their own packages.  I present:

x11-libs/qt
x11-libs/qt-dbus ( Breaking out into its own package )
x11-libs/qt-phonon ( New for 4.4, a wrapper around various sound modules )
x11-libs/qt-qt3support ( Breaking out into its own package )
x11-libs/qt-webkit ( New for 4.4, Qt's integrated WebKit support )

There may be some more of these as time goes on and necessity/desire dictate.

The main motivation behind doing this is to make the package a little more
manageable, in that it's not one huge monolithic package with a million use 
flags
dictating which modules get built.  This should make dependant package 
maintenance
nicer, as you can just depend on the necessary packages and not have to resort 
to
the built_with_use trickery that we all love so much.

As well, we gain in the same vein as the split KDE style packages, that updates 
and
security fixes don't require a recompilation of all of the non-affected modules.

There are still lots of goodies that need to be tested.  I'm sure there are
edge-case USE flag scenarios that may need to be accounted for, performance 
tweaks
to be made, and other things I haven't thought of.  If you're into bleeding 
edge,
I'd love to have you try out some of these new packages and see if you've got 
any
failures or ideas for making them better.

As usual, this stuff is all package.masked right now pending lots of tweaks and
changes in the short term.  My guess is that it will hit portage proper by the 
end
of 1Q2008.  Hopefully we can have it all happy by then.

Feel free to file any bug reports you can find or think of.  Patches are 
especially
encouraged.

Thanks,
Caleb

-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Project Update: qt-4

2007-12-20 Thread Caleb Tennis
 Great news. Why don't you split everything, though? In qt-4.3.0-r2, I
 see Core, Gui, Network, OpenGL, Sql, Script, Svg, Xml, Designer,
 UiTools, Assistant, 3Support, Test and DBus and can certainly imagine
 that at least putting the Gui out would make sense for console-based Qt
 applications.

I'm definitely considering this.  At the very least I'd like to make a qt-core
package with all of the non-GUI stuff in it, then have a gui package that has
everything else.  It's a work in progress, but I'm hoping we can get it to this 
kind
of thing soon.

Caleb


-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Project Update: qt-4

2007-12-20 Thread Caleb Tennis
 How about splitting qmake out to help with the WebKitGtk stuff, so we
 don't have to dep on qt?

In theory it can be done very easily, because qmake doesn't rely on any Qt
libraries.  However, it DOES rely on all sorts of .prf and configure time option
files that are installed to the file system.  But I'm hoping to get a very 
minimal
package together that will mitigate the need for a big Qt install for builing
WebKitGtk, yes.

Caleb

-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-libs/qt: ChangeLog qt-4.3.2.ebuild

2007-10-03 Thread Caleb Tennis
 Try being a little smarter with both CHOST and CXX -- only add an
 exception if the spec name isn't equal to the variable value.

 spec=$(echo ${CHOST} | cut -d- -f3)
 spec=${spec%%[0-9]*}
 spec=${spec}-$(tc-getCXX)

The bsd folks are the ones who added these conditionals.  I'd like for them to 
make
the necessary changes, because I don't want to risk screwing up their
builds/installs.

 For icc, you should just be able to use 'icc'; it's installed that for
 quite a while. That way you don't require any special cases here.

This change was made based on a bug a user filed (albiet, some time ago).  
Again,
I'd prefer if someone who can test it with icc can make the appropriate change.

 Quote variables that can have spaces in them: D, S, T, WORKDIR,
 FILESDIR, DESTDIR, ROOT.

Should be fixed thanks.

 If emake doesn't work, please add a comment to that effect.

Will test and fix or comment as needed, thanks.


Caleb

-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] SSL-Certificates and CAcert

2007-09-27 Thread Caleb Tennis
 On Thu, Sep 27, 2007 at 05:23:26PM +0200, Hanno B??ck wrote:
 Well, I hope I don't have to tell that self-signed certs are not really good
 security policy.
 Whether or not self-signed certs are secure or insecure depends entirely
 on your definition of 'secure'.
 - Is the traffic encrypted between your machine and the server?
   Always, regardless of it being a self-signed or self-CA, or external CA.
 - Can you be sure that there is no MITM attack?
   Only if you trust the CA _OR_ you know in advance the SSL fingerprint.

 Knowing the SSL fingerprint is trivial, if you login to machines with
 SSH, you are be doing this every day.

Yes, you and I and most other technical people know and understand this.  But 
how
many end users know or care that their traffic to bugzilla is being safely
encrypted?  And how many are going to have worry and or doubt when they get a 
popup
telling them that some kind of security certificate may not be valid.  It's
definitely a red flag.

 I think most of you know that there's CAcert, a free certificate authority.
 While it's sadly not free in a free software sense (their own software
 isn't released under a free license, though I hope that will change at some
 point in the future), it uses a web-of-trust-based concept for trust and
 issues certificates with no costs.
 Go and read ALL of this bug:
 http://bugs.gentoo.org/show_bug.cgi?id=108944
 Pylon and myself, as folk in favour of CA-Cert tried to get the ball
 rolling to get Organization-level certs from CACert. It seems to have
 long blocked on trustees and paperwork - both on our side, and on the
 side of CACert (Inclusion in Mozilla is blocking on the CACert internal
 audit).

Is there a reason that my Godaddy suggestion in the bug isn't being considered? 
Regardless of what you may think of them as a company, they offer the same free 
type
of certificate to open source projects just like cacert, and with what looks to 
be
considerable less overhead.  I understand that cacert is more open sourcy than
godaddy, but if they're as much of a roadblock as the Trustees are in this case,
maybe going that route would enable us to move forward?

 I think compared to self-signed, having cacert-certificates would be a big
 improvement. Many other free software projects (and more and more other
 pages) use cacert, so it becomes more and more likely that people will
 already have the cacert-root-cert installed.
 I don't agree that it's a big improvement. If you read the bug above,
 you'll note that we did at one stage have a 'Gentoo CA' that Infra ran
 for generating certs.

It is a big improvement.  Not in security, but in perception.

Caleb

-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] meaning of sqlite/sqlite3 use flag

2007-09-14 Thread Caleb Tennis
 Does anything need the sqlite2 support in QT?

Not explicitly.  Qt can also build against an internal version of sqlite2, so it
shouldn't be too big of a problem to remove this particular dep (but that 
doesn't
get rid of the flag issue, I suppose).

Caleb

-- 
[EMAIL PROTECTED] mailing list



[gentoo-dev] app-arch/rpm needs a maintainer

2007-08-20 Thread Caleb Tennis
Title says it all.  There are a lot of open bugs, and I'm trying to clear up 
some
sys-libs/db dependency issues.  Does anyone use this package and want to 
maintain
it?

Caleb

-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] app-arch/rpm needs a maintainer

2007-08-20 Thread Caleb Tennis
 i guess this is the reason why x11-misc/hotkeys has been dropped from
 portage too. We would have appreciated beeing warned through p.mask or
 -dev, or receiving an explanation in the commit message.

Sorry - as I explained in the bug I didn't realize that there was much interest 
in
this package since it hadn't been touched in almost 5 years and had no 
maintainer. 
Last rites seemed a bit silly to me at the time, but now I see there is still
interest so reviving it is quite allright.

That said, the maintenance of RPM is still up for grabs.

Caleb

-- 
[EMAIL PROTECTED] mailing list



[gentoo-dev] distcc and precompiled headers

2007-05-18 Thread Caleb Tennis
Based on some recent findings, it looks like the two above mentioned features 
don't
work together.  pch don't get distributed to distcc nodes, so they're basically
mutually exclusive.  However, distcc is a FEATURE and pch are a USE flag.

Should we just put a check in each ebuild that uses the pch use flag, make an
eclass, or build something into the package manager(s) ?  Thoughts?

Caleb

-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Re: stabilizing expat 2.0.0

2007-05-16 Thread Caleb Tennis
 No.  It would have been ideal if we would have done it with the release.
 Now, it means people *will* need to use revdep-rebuild as soon as they
 install their shiny new system if they use binary packages.  People
 coming from stage3 would be fine, of course.



I would have been happy to do that, but honestly Chris, the thought of 
approaching
you and asking you to bump something like that into 2007.0 scared the crap out 
of
me.  You seemed way overburdened for the release as it was.

I have no problem waiting for 2007.1, if Gnome and KDE don't mind.  I don't know
what hackery has to take place to do that, but I'm sure someone out there does.

Caleb


-- 
[EMAIL PROTECTED] mailing list



[gentoo-dev] stabilizing expat 2.0.0

2007-05-15 Thread Caleb Tennis
I'd like to open a bug soon requesting the stabiliztion of 
dev-libs/expat-2.0.0*. 
It's currently assigned to tcltk, but the bug traffic seems to indicate they 
don't
know why they have it.  If nobody steps up, objects, and is willing to take over
maintenance I will do so.

* - This version has a new soname, so it will require a revdep-rebuild, which is
probably why it hasn't been stabilized as of now.

-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] stabilizing expat 2.0.0

2007-05-15 Thread Caleb Tennis
 Isn't this why we have slots?

Yeah, but I think it's a hack in this case.  All of the current versions in 
portage
are 1.95, which I believe were pre-releases to 2.0.  As far as I can tell, 
nothing
is vastly different in 2.0 other than bug fixes and a final soname change.  As 
well,
we'd have to put the slotted versions header files into directories where all 
of the
packages that depend on expat won't know where to find them.

It's going to cause a mess of why did my program stop working? bugs, but it's
probably one of these things that should have been done a long time ago.

-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] stabilizing expat 2.0.0

2007-05-15 Thread Caleb Tennis
 Yeah, exactly. I was too late to have things sorted out with people
 maintaining (or the lack of it) to have this stabilized together with
 GNOME-2.16, as the biggest desktop environments need to be
 revdep-rebuilt to a large extent if not using --as-needed.

 I hope you guys are going to do it together with a large KDE
 stabilization spree then or something. I can time GNOME-2.16.3
 stabilization to the same time as well, to minimize otherwise useless
 revdep-rebuilding and include this with version updates.
 Some pointer to use -X (--package-names) flag for revdep-rebuild
 somewhere might be a good idea.

I'm certainly happy to time it with these big events.  I think we're planning 
on a
KDE stabiliztion spree in a couple of weeks.  I'll open a bug and CC interested
parties.

Caleb

-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] stabilizing expat 2.0.0

2007-05-15 Thread Caleb Tennis
 If you read the bug with loads of duplicates; it's been avoided as well,
 because it was considered unsafe for the same reason as slotting.

I just read the bug, but I don't see any compelling reason against using the
preserve_old stuff.  It seems like it's a good balance that will mitigate the 
issue
for the majority of users until they can purge their systems of the old expat.

Caleb

-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] stabilizing expat 2.0.0

2007-05-15 Thread Caleb Tennis
 Ok, I can't wait with GNOME-2.16.3 that long. I'm already late a month.
 I wonder how much packages KDE needs rebuilt with the expat bump
 (revdep-rebuild --library expat.so or something like that). Maybe
 including it in the GNOME bumps is a good idea if that has it for more
 packages than KDE.

From my point of view, you're certainly welcome to do this sooner if you would 
like.
 I just wanted to get the ball rolling.

I think the preserve_old_libs thing might just be the hack we need here.

Caleb

-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] stabilizing expat 2.0.0

2007-05-15 Thread Caleb Tennis
 I think the preserve_old_libs thing might just be the hack we need here.

It's been brought to my attention that a bad side effect from using the
preserve_old_libs method is that if an intermediary library, like qt3, gets 
rebuilt
then you end up having both expat libraries linked against the kde libraries at 
the
same time which causes rather undesriable crashes.  Presumably this will affect
GNOME in a similar fashion as well.

In summary: there's no good way to do this, and someone is going to have to 
pick. 
No matter what, the choice will come with critism.  I'm volunteering to take the
heat, unless someone beats me to the punch.

Caleb

-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] stabilizing expat 2.0.0

2007-05-15 Thread Caleb Tennis
 It's been discussed with the original maintainer over and over again,
 and the conclusion was that it's not safe to have two versions of expat
 installed on the same system. So, why don't we just stick to that and be
 done with it?

Yep, I'm on that page as well.  I will push the stabilization when the time is 
right
with either Gnome or KDE, whomever pushes harder and comes first.

-- 
[EMAIL PROTECTED] mailing list



[gentoo-dev] KDE needs your help

2007-03-15 Thread Caleb Tennis
The KDE team is still grossly understaffed.  Most of the long term developers 
on the
team are either gone or inactive, and the ones still working on it really need 
help.
 Bugs are piling up, patches are waiting, and package versions need bumped.  I
simply don't have the time to keep up with it anymore.  I've been doing this for
over 4 years now, and my interests have shifted to other things.

If you are already a developer and can help the team, please feel free to join. 
 If
you are a user who wants to help, becoming active in the forums and with open 
bugs
reports is a good way to get yourself noticed.  It would be nice to get some 
more
people brought on as developers who can help keep the KDE team active and alive 
as
the 4.0 release draws closer.  I would hate to see Gentoo dropping KDE all 
together
because nobody has the time to maintain it.

Thank you.

ps - please don't e-mail me and ask me how you can become a developer.  There 
are
official channels for this, and if you aren't aware of them, you aren't yet 
ready to
go down that road :)

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Cleanup package.mask

2007-03-06 Thread Caleb Tennis
Hi,

If you have a long lingering mask in package.mask, please consider cleaning it 
up.
If you blocked something for testing 2+ years ago and it's still like that, 
maybe
it's time to consider bumping the package, removing it, or more?

If it still needs to be tested more, can you add a new update to the date entry 
so
it shows that there's still some activity being done.  This way it's possible to
identify abandoned packages and missing maintainers.

Thanks,
Caleb

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Packages requiring explicit db versions?

2007-03-01 Thread Caleb Tennis
To follow up to this, I am planning on package.masking sys-libs/db 4.0 and 4.1
sometime in the near future, to be followed up by their removal in ~30 days.

If this poses a problem to you, a package you maintain, one of your family 
members,
or some exotic animal you may or may not own, please let me know.

Caleb

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Packages requiring explicit db versions?

2007-02-28 Thread Caleb Tennis
 There is one use-case that I am aware of against removing old versions of 4.*,
 but I haven't seen it in the tree for a while - other folk might be more aware
 of it: Ability to take DB files from other systems and read them sanely /
 migrate them to new versions.

Yep, subversion comes to mind on this one.  Though, this isn't forcing anyone to
uninstall their db versions, but simply removing them from the portage.  
Granted, it
does make it more difficult to migrate db version backends, but since the 
ebuilds in
question will be available from the CVS attic on cvsweb, I think the benefit
outweighs the harm in removing them.

 Here's a set of stuff of everything that looks for a specific version of 4.*.

Thanks for this list.  It seems that the removal of 4.0* and 4.1* are probably 
okay,
based on this information.

I imagine we'll go through a normal 30 day package.mask/removal procedure when 
the
time comes.

Caleb

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Packages requiring explicit db versions?

2007-02-27 Thread Caleb Tennis
I'm hoping to advocate some more cleanups in sys-libs/db by proposing the 
removal of
4.0.* and 4.1.* from portage.  4.2 has been stable for a long time, with 4.3
unstable and 4.4 and 4.5 available in package.mask.

If anyone has a package that won't work with =sys-libs/db-4.2* please reply.  
Note
that this doesn't affect the 1.85 and 3.2.9 series'.

Thanks,
Caleb

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] KDE herd hurting for help

2007-01-31 Thread Caleb Tennis
Hi,

Unfortunately, most of the active KDE herd/group members are a bit unactive 
right
now (self included), which means that bugs are really starting to pile up.  If 
you
have any interest in this at all, please by all means join the herd and start
helping us out.

Thanks!

Caleb

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] tr1 dependencies

2007-01-30 Thread Caleb Tennis
 * Hard dep upon boost. This sucks for g++-4.1 users.

 * Hard dep upon g++-4.1, which isn't available for all archs. This
 doesn't even work because there's no guarantee that =4.1 is being used
 even if it's installed.

I don't think these are necessarily compatible.  tr1 is implemented in the 
std::tr1,
while I think everything in boost is just in the boost namespace (unless this 
has
changed since I've used boost).  This would mean that the project code itself 
would
have to have the logic to decide which set of headers to use.  I'm guessing most
probably won't have the compatibility code to make that accessment, though some 
may.

Caleb


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] debug.eclass is dead now

2007-01-05 Thread Caleb Tennis

 Don't use debug.eclass.

Pardon what may be a stupid question here, but what's the fix/workaround for 
using
the debug.eclass ?

Caleb

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Ebuild documentation, needs updates?

2006-12-04 Thread Caleb Tennis
I was working through a bug report when I noticed someone recommended using the 
syntax:

DEPEND=category/app-ver:SLOT

In order to lock to a certain slotted version.  I hadn't seen this before, and 
tried
to find out more information about it but I can't find either in the ebuild 5 
man or
the online documentation about this feature.  I'm curious if I'm just really 
behind
in this or if it's an undocumented feature (or it's documented somewhere I 
haven't
seen).  And as such, it makes me wonder how many more of these *features* there 
are
that aren't disclosed anywhere.

Do we need to have someone update the docs to reflect all of the new (new being 
a
quite relative word here) features of portage?

Caleb

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Gentoo World Domination. a 10 step guide

2006-10-04 Thread Caleb Tennis
 Basically, the person doing one or two commits a month *do not* need CVS
 access.  They can still *contribute* at their current pace without
 having CVS access and a nice @gentoo.org email address.

Sorry, but as a dev who has lurked in the shadows for a long time, this
simply isn't globally true.  Sometimes there are packages which the dev
takes over that nobody else who is a developer wants or has time to work
on.  This happened to me when all of a sudden nobody was on the ruby herd
anymore.  All of my requests went unanswered.  So I simply took it over.

I really appreciate the handful of devs who do the most commits, but why
would you want to add even more to their plates by removing a bunch of the
developers who handle smaller stuff.  I simply don't have the time anymore
to be as active as I used to be years ago.  But I still do contribute as
much as I can: I keep Qt, Ruby, Ice, and some KDE packages updated.  If
you want to take away my CVS access because I'm not a power committer
anymore it won't hurt my feelings, but I can't imagine how it helps Gentoo
in any way.

I'll offer a counter proposal: I don't play games on the computer, and
they're definitely not required for a working Linux distribution, so I
think we should just get rid of all games packages.  Let's focus our
efforts more on the necessities.

My point is that as long as it's of sufficient quality, it's silly not to
accept the gratis work that someone's willing to do, be it in putting
games into the distribution or making a small number of commits to keep a
certain subset of packages up to date.

Caleb

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] /opt for binary only packages

2006-09-08 Thread Caleb Tennis
I know that this is a convention we've followed (and is represented on the
ebuild howto guide), but is it set in stone?

The reason I ask is that I have a group of about 5 packages that I'm
working on ebuilds for that by default all want to be in
/opt/Pkgname-version.  I've done some ebuild foo to make it want to
install stuff in /usr/bin, /usr/lib, etc, but it also contains some extra
specification files that get used at runtime that it's expecting to easily
find, and leaving everything to just go into /opt/Blah is so much easier
to support.

So my question is: is it accept to install a package into /opt that isn't
strictly binary, but by default and design convention wants (and pretty
much needs) to be installed there?  I guess moreso I want to propose
changing the 'gentoo convention' for /opt to add in that it's okay to
install something in /opt that was designed to go there by its upstream
authors.

Thanks,
Caleb

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: KDE and Ruby herd call for help

2006-08-23 Thread Caleb Tennis

 Have they already done the ebuild quiz?

 I would love to have some guys fixing kde bugs and asking me or someone
 else
 in the team to check and commit it. So, if they have their quiz I would
 love to help mentoring them and otherwise I would love to see them in IRC

No quizzes yet.  When I've put calls for help before I find that we
usually get a lot of responses and then a lot of people quickly fizzle
out.  I wanted to at least get through that round before we start going
through the ebuild quiz process.  I'll be sure and send people your way
though!

Thanks,
Caleb

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] KDE and Ruby herd call for help

2006-08-22 Thread Caleb Tennis
Hi all,

Right now both the KDE and Ruby herds (which, informally, I am the *lead*
on both) are hurting for people.  I don't have the time to work on general
maintenance and bugs at the moment, so we need some help.  I've sent out a
request for help in the GWN a few weeks ago and got a lot of good leads on
potential new devs, but unfortunately I don't have the time right now to
mentor anyone either.

If you're able to help in either one of these herds, it would certainly be
appreciated.  You don't need my permission or anything - just add yourself
to the herd and throw a mail out to the alias saying you're joining us.

Furthermore, if you can take on the role of mentoring people, I'd be happy
to pass on some e-mail addresses of folks who showed interest in becoming
devs.  Mail me for that information.

Thanks,
Caleb

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] adding graphviz use flag

2006-07-03 Thread Caleb Tennis
I was going to add graphviz as a local use flag to kdevelop, when I found
these:

use.local.desc:media-gfx/imagemagick:graphviz - enable graphviz support
use.local.desc:media-gfx/k3d:graphviz - Add graphviz support
use.local.desc:net-analyzer/scapy:graphviz - Enable graphviz support
use.local.desc:www-apps/bugzilla:graphviz - enable graphviz support
use.local.desc:www-apps/tikiwiki:graphviz - enable graphviz support

I plan on moving all of them to a new global graphviz flag unless someone
screams loudly in my direction.

Thanks,
Caleb



-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Qt use flag recap

2006-06-23 Thread Caleb Tennis
Ok, so there are two fundamental ideas here:

1) Keep the qt use flag, use it if a package offers qt3 or qt4 support. 
If both, then make it for the more recent version and add a local flag for
qt3 support.

A few of us like this one, including me.  The downside to this is you get
a USE that may look like qt -qt3 which is a bit ugly.  Upside is that it
just works.


2) Remove qt use flag, and create qt3 and qt4 global flags.

This is what a few others are behind.  It's more descriptive of what's
actually going on, but will disrupt ~30 packages that currently use the
qt flag.


I suppose I'm not really big on one versus the other.  I was for #1 simply
because it required the least amount of effort to implement, however the
people who are in favor of #2 have volunteered to do the work to implement
it as well as put qt3 into the use.defaults for 2006.1 so KDE will work
out of the box.  I'm not inclined to go against them simply because I
don't see a big downside to going to qt3/qt4 global flags as long as
someone is willing to do the work.

So, as long as nobody comes up with a major objection, consider this my
recommendation to allow portage to move to the #2 scenario.  The it just
works now excuse isn't valid, either.  And, if it turns out the change
really sucks..well...we can always figure out something else. :)

Comments and flames are most welcome.

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] [RFC] Useflags: qt, qt3, qt4?

2006-06-21 Thread Caleb Tennis
On Tuesday 20 June 2006 12:40, Stefan Schweizer wrote:
 Hi,

 with kde4 approaching and the new Qt-4 being in the tree we suddenly see
 the same problems that gtk had with the gtk2 flag again.

I think there's a lot of good thoughts surrounding how to handle this.  There 
are 2 categories of packages we need to concern ourselves with:

1) A package can optionally add support for Qt3 or Qt4 (such as dbus).

Solution: The qt flag represents the latest qt major version for the package.  
The maintainer can either put in another flag for the older version (qt3?) or 
provide a separate package (e.g. dbus-qt3 ).

2) A package requires either Qt3 or Qt4 (both not both?...such as 
x11-libs/qwt-5).  

Solution: Build against qt4.  If you want to provide the same package for the 
qt3 version, add a new package to portage I suppose.



In the end, this is just merely suggestion.  I think each maintainer should 
come up with the best way to handle the situation unless someone is going to 
GLEP this.

I think we should, however, do our best to avoid a situation where we have 
some ugly combination of USE=qt -qt3 or USE=qt4 -qt qt3...

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: [RFC] Useflags: qt, qt3, qt4?

2006-06-21 Thread Caleb Tennis
 Caleb Tennis wrote:
 qt3 - enable optional qt3 support
 qt4 - enable optional qt4 support

Maybe I just need a little time to warm up to this. :)

Caleb

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: Re: [RFC] Useflags: qt, qt3, qt4?

2006-06-21 Thread Caleb Tennis
 qt - GLOBAL use flag that causes the package to build against the good
 version
 for that package.

 qt3, qt4... - LOCAL use flags to build against specific versions of
 qt when it makes sense on a per-package basis and when it's deemed to
 be reasonable by the package maintainer.  Easy to keep track of because
 they'd all be in use.local.desc.

This is exactly what I recommend.  It requires no end user changes to make
it work.


The only downside to this is that using qt isn't explicit in which
version it pulls in.  To that, I say: who cares?  That only seemingly
becomes valid when someone wants to rid their system of a specific
version of Qt, which if they're advanced enough to think they need to do
that they can probably hack around enough to figure out that packages
depend on the version of Qt they want to nuke.

I seriously doubt there will ever be many packages that support both at
the same time.  For those, we'll handle them in the best way we can at the
time, be it a qt3 flag, a separate package instance, or other.

Moreso, people will release new packages of existing products that use Qt4
instead of Qt3.  This is where it gets interesting: if somelibrary-3.0
depends on Qt3 and somelibrary-4.0 depends on Qt4, do we slot them so they
can both be installed at the same time?  Seems reasonable to do so, but
you run into the issue of how to handle version dependencies across slots
of the same package...something portage doesn't do very gracefully at the
moment.

Oh, the joys. :)


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: GWN Comments

2006-06-20 Thread Caleb Tennis
 This is a COOL idea! A global forum with a text-only copy of current GWN
 would enable more users to actually read it. And adding comments would be
 even more beneficial. I think that it would be best to place it near the
 top
 of forums listing, like this:

Agreed.  I think this would be a good place to start until something else
is in place.

Caleb

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] GWN Comments

2006-06-19 Thread Caleb Tennis
I'd like to propose some form of ability to post user comments to GWN
stories.  I suppose a full blown CMS system would work, but for the ease
of time I'm suggesting that perhaps we open up a GWN section on the forums
and post the text of the GWN (or perhaps each section) in a new thread
each week and allow users to write comments.  I think opening up this
venue of feedback would let users more readily tell us what they're
interested in, and it would allow GWN contributors/editors/etc to see some
of the fruits of their labors.

Any comments?

Thanks,
Caleb

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: Re: Re: When will KDE 3.5 be marked as stable?

2006-05-05 Thread Caleb Tennis

 I understand you don't care about how many users you have, Gentoo is not a
 bussiness. But if I try to convince users about the current situation that
 is hard. I can't explain this, I really can't. My only answer is put it
 in /etc/portage/package.keywords. But that one is growing very fast...
 One nice thing for users would be the addition of more metabugs for recent
 packages. I'd like to know why some packages are not stable, and I am not
 the only one. Adding a metabug instead of closing all requests for
 stabilization with wontfix/wontresolve is much more userfriendly.

I read and see that your intentions are good.

The KDE team is currently made of about 3 semi active people.  Our speed
is simply limited by the amount of time and resources we have to put into
maintenance.  I won't argue stability and ~keywords and whatnot, as it's
somewhat of a matter of opinion and interpretation.

But I will say this: if anyone feels as though something has stalled or
wants some explanation as to why the distribution isn't moving in a
certain direction, then your message should be tagged with the following
words:

How can I help?

Get involved.  It's the only way you will truly understand the magnitude
of a project like Gentoo.  KDE is a very small slice of the whole thing,
and yet it still requires a LOT of time.  We're always looking for help. 
If you need a place to start, pick out a bug report and try and fix it. 
You might spend 3-4 hours chasing the answer.  3-4 hours.  Can you imagine
sitting in front of your computer for 3-4 hours to solve a problem for
someone you don't know for no compensation?  And you may never even figure
it out!

So let's rephrase why doesn't Gentoo have ZZZ into how can I help
Gentoo have ZZZ?.  Become empowered.  That's what will keep the
distribution great.


Caleb


My guess is that KDE 3.5.2 is probably ready for stabilization, but nobody
has the time to do it at the moment.  That's purely a guess, though.  Feel
free to open a stabilization tracker bug for it so we do have a place to
discuss it.


-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Using subversion eclass for snapshots

2006-04-10 Thread Caleb Tennis
I've been working on an ebuild that, ideally, would use the subversion
eclass to checkout a snapshot of the ebuild (this is for local program). 
I plan to just put the repository version in the ebuild PV - ie:
myprogram-224.ebuild.

The problem is that portage always want to re-emerge this package during
an update (presumably because it think that svn ebuilds are live ebuilds).
 I want to trick it into not doing this.  I don't see anything obvious
in the subversion eclass that would allow for this.

Any thoughts?

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: When will KDE 3.5 be marked as stable?

2006-04-04 Thread Caleb Tennis

 I think at this point it does more harm than good to be lagging behind
 the
 current upstream kde - last time I checked the kde bugzilla wouldn't
 even
 accept bug reports for the kde currently marked stable as it was too
 old,
 and if bugs can't be filed then it's clearly unsupported upstream and
 time to upgrade.

 Wow!  I run ~arch by choice and generally find its keywording suitable
 (IOW, packages move from masked to ~arch at a generally appropriate
 speed), but I didn't realize Gentoo KDE-stable was /that/ far behind!
 Point well made!

I think historically we were much more bleeding edge with our stable KDE
versions than at the moment, but if you've spent any significant time
playing with 3.5.0 or 3.5.1, I think you would agree that they are
terribly less stable than 3.4.3.  But in a few weeks I think 3.5.2 will be
stable and it will all be behind us.

Caleb

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Find apps not ported to modular X

2006-03-16 Thread Caleb Tennis

 Latest list:
 http://dev.gentoo.org/~spyderous/broken_modular/broken_modular_maintainers.
txt.20060315

What's the search criteria?  I fixed dev-ruby/ruby-gd yesterday, but it's 
still on the list.  Perhaps, though, I didn't fix it correctly for the search 
script to pick up?

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



Re: [gentoo-dev] coreutils: deprecated behavior not so deprecated

2006-01-27 Thread Caleb Tennis
On Friday 27 January 2006 08:44, Mike Frysinger wrote:
 On Monday 23 January 2006 23:04, Mike Frysinger wrote:
  for those who dont know what i'm talking about, consider:
  tail -1
  head -1
  some other stuff i cant remember

 it would seem i lied about this (at least the first two still work)

Still, the behavior of tail -1 and head -1 should be fixed in the packages 
that are implementing it.  I suppose your previous e-mail was good enough 
warning that this behavior is deprecated and will be removed at somepoint 
from coreutils.

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



Re: [gentoo-dev] Find apps not ported to modular X

2006-01-20 Thread Caleb Tennis
On Thursday 19 January 2006 22:27, Donnie Berkholz wrote:
 Dan Meltzer wrote:
  Would you considder putting these daily updates on your devspace
  instead of sending a huge email daily?

 Nope. That puts the effort on these developers who haven't ported apps
 to actually go to my webspace and search around.

You should also post a link to the migration guide in each e-mail so it's easy 
to figure out how to fix what's broken.

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



[gentoo-dev] Request for ebuild (with a cash backer)

2006-01-18 Thread Caleb Tennis
Hi all,

I need an ebuild for GPL Ice C++ (http://www.zeroc.com/download.html) and I 
simply don't have the time to write it at the moment.  If someone is willing 
to take on the task of writing it, and submitting to me (or even better 
helping me to maintain it in the portage tree) I'm willing to paypal you $50 
USD (or send you a business check if you'd prefer).

Sorry for the SPAM for those not interested,
Caleb
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Request for ebuild (with a cash backer)

2006-01-18 Thread Caleb Tennis
Follow up: Two devs have already mailed me on it.

Thanks,
Caleb


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] The deal with epkgmove

2005-12-10 Thread Caleb Tennis

 As for moving packages by hand vs. using a tool, that's not really infra's
 call.  If you were asking about CVS vs. SVN, I have been and remain
 opposed
 to using SVN for gentoo-x86 until someone can offer a whole lot of
 assurances around SVN's ability to manage a repo of our size. (1.3GB,
 216,000+ files and counting)

KDE moved to Subversion earlier this year, with a few million lines of
source code and hundreds of branches and tags.  It did it flawlessly and
maintained over 400,000 commit history items.

I don't think stability is the biggest hurdle here.  I think the
conversion process will be - they had to write a lot of code from scratch
to handle maintaining all of that history (the stock cvs2svn wasn't robust
enough), and they had to run the conversion process a number of times,
find the bugs, rework their conversion code, and rerun.  It was a lengthy
process (a few weeks I believe).

It's going to require someone to actually write the conversion code and
provide a proof of concept conversion.  If anyone's up to the challenge, I
imagine contacting their sysadmins would be a good start.


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] The deal with epkgmove

2005-12-10 Thread Caleb Tennis

 As for moving packages by hand vs. using a tool, that's not really infra's
 call.  If you were asking about CVS vs. SVN, I have been and remain
 opposed
 to using SVN for gentoo-x86 until someone can offer a whole lot of
 assurances around SVN's ability to manage a repo of our size. (1.3GB,
 216,000+ files and counting)

KDE moved to Subversion earlier this year, with a few million lines of
source code and hundreds of branches and tags.  It did it flawlessly and
maintained over 400,000 commit history items.

I don't think stability is the biggest hurdle here.  I think the
conversion process will be - they had to write a lot of code from scratch
to handle maintaining all of that history (the stock cvs2svn wasn't robust
enough), and they had to run the conversion process a number of times,
find the bugs, rework their conversion code, and rerun.  It was a lengthy
process (a few weeks I believe).

It's going to require someone to actually write the conversion code and
provide a proof of concept conversion.  If anyone's up to the challenge, I
imagine contacting their sysadmins would be a good start.


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Modular X plans

2005-08-09 Thread Caleb Tennis
On Monday 08 August 2005 08:14 pm, Donnie Berkholz wrote:
 If you could bring up some specific examples, we could discuss them.

Sure.  Qt has optional support for xkb, tablet, fontconfig, xrender, xrandr, 
xcursor, xinerama (already a use flag), xshape, and xsm.

I'd really hate to add 8 more use flags for those things.  I find it fairly 
hard to believe that a user would want to, for example, configre xrender and 
xcursor but not xrandr.

My *thought* here is why not let the Qt ebuild rely on the base packages of X, 
and if these other packages are also installed ahead of time, then configure 
support for them as well, but don't make them use flag deps.

Something like:

if xcursor is installed
  turn on xcursor support
  DEPEND+=xcursor
fi

I'm sure someone will cast me as a heretic, but I think this is much more 
elegant than 8 more use flags.
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Modular X plans

2005-08-09 Thread Caleb Tennis
 Yep, you're a heretic. :)
 How would you propose that DEPEND information make it's way up the
 portage stack, and ultimately affects the depgraph?

 What you're suggesting is effectively suggested deps, which are a
 bit backwards considering we have optional deps, the 8 flags you
 dislike :)

Let me follow up with that I'm all for adding the use flags IF other packages 
would make use of them as well.  I just really hate adding 8 local use flags 
for this pretty heavily used package that won't add much utility to anything 
else and will add a bit of headache to making sure Qt is installed with all 
of the bells and whistles the end user wants. :)
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Modular X plans

2005-08-08 Thread Caleb Tennis
On Monday 01 August 2005 03:54 pm, Donnie Berkholz wrote:
 I eagerly await your questions and concerns.

Donnie,

What is the plan for packages (I'm thinking other x11-libs/ packages and 
window managers) which can optionally depend on various X11 libraries?  Do we 
need use flags for xcursor, xrender,xsm and the like to pull in the 
deps?

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



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

2005-07-02 Thread Caleb Tennis
On Saturday 02 July 2005 14:41, Gregorio Guidi wrote:
 I'm back from a trip and I'm slowly catching up with all the mails on this
 topic, but a couple of things come to my mind ... please bear with me.

 First, a new eclass for Qt4 ebuilds should really be called qt4.eclass,
 with another one, qt3.eclass, to be used to port the current Qt3-based
 ebuilds. Dealing with more than one major version in a single eclass is a
 pain; this is mostly true for the kde eclasses, but still applies to Qt.
 In fact, we need to introduce a new clean eclass for KDE4-based
 applications, so starting from scratch with a kde4.eclass and a qt4.eclass
 makes a lot of sense.

I completely agree.

 As many already pointed out, using something like
   DEPEND=$(qt_min_version 3.1)
 is very ugly, so we should use it only if it is really unavoidable.

I agree too, but I haven't seen yet how it can be avoided.

 An application based on Qt4 should look just like this:

   inherit qt4

   HOMEPAGE=...
   SRC_URI=...
   ...

 the qt4 eclass would automatically add a DEPEND==x11-libs/qt-4*, and
 would provide default src_compile(), src_install()...

That's fine, except I would think that very few ebuilds would be able to make 
use of a default src_compile() and src_install().  It works for the kde 
eclass because most of the kde packages are built using the standard kde 
auto* scripts, but I doubt many qt only packages have the same build 
structure.

[snip]

While your proposal works okay for the qt4 scenario, I'm more concerned with 
the existing qt3 at the moment.  As is, I stil l don't see a way around what 
has been proposed for those ebuilds.  Until portage has the ability to handle 
 deps, I fear there's no real way around it.  I don't think we'll have time 
to wait much longer; I expect ebuilds that need qt4 will start appearing in 
portage soon and the minute that qt4 is marked ~arch it instantly creates the 
dependency mess addressed previously.
-- 
gentoo-dev@gentoo.org mailing list



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

2005-07-01 Thread Caleb Tennis
On Friday 01 July 2005 03:55 am, Chris Bainbridge wrote:
  Why not just use =qt-3.3 since qt3 probably wont have any new major
  release ?

 This would seem like the easiest option. Is there any reason not to do
 it this way?

Yes, two of them.

1. You don't know that there won't be a 3.4 qt

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 now.
-- 
gentoo-dev@gentoo.org mailing list



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

2005-07-01 Thread Caleb Tennis
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



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

2005-07-01 Thread Caleb Tennis
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 change deps from =qt-3.0 to =qt-3.3 then nobody will be able to work 
with a Qt dependant package until they upgrade Qt.  In the same regard, there 
are people still using Apache1 whom we aren't forcing to upgrade to Apache2 
just so they can use some of the apache modules.

Also, another downside to the =qt-3.3 approach is that it doesn't cleanly 
handle the cases of =qt-3.3.2-r1.
-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] RFC: qt.eclass

2005-06-30 Thread 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] RFC: qt.eclass

2005-06-30 Thread 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

2005-06-30 Thread 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

2005-06-30 Thread 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

2005-06-30 Thread 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] splitting one source package into many binaries

2005-06-16 Thread Caleb Tennis
On Thursday 16 June 2005 11:50 am, Rafael Espndola wrote:
 Is this a bad idea or simply not the Gentoo way?

The idea isn't bad, but the implementation is more work to maintain than it's 
probably worth.

You can, of course, always roll your own ebuild variation and keep it in your 
portage overlay directory.  Or, alternatively, you can just rm 
-f /usr/qt/3/bin/designer.

Caleb

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Qt4 portage update

2005-06-16 Thread Caleb Tennis
With the pending release of Qt4 very soon, I wanted to take a moment to update 
the community on what kind of effect it will have on portage:

First, the installation is now FHS compliant - no more stuff going 
into /usr/qt.

Previous Qt versions built one big library; this version builds 9 or 10 
smaller ones (all installed into /usr/lib/qt4).  Since the names are 
different, as well as the sonames, there should not be any runtime linking 
issues with a mixed installation.

Qt4 does not make use of the QTDIR environment variable like Qt3 did.  This 
means that automated build scripts, such as those with most KDE programs, 
will still pick up the correct Qt3 programs (uic, moc, and qmake).  For 
programs that don't use these types of build scripts, ebuild modifications 
may need to be made to tell the package which directory to pick up its binary 
tools in (/usr/qt/3/bin for Qt3, /usr/bin for Qt4).

I currently don't have any plans for any type of xxx-config package to switch 
between versions.  After installing Qt4, those applications will be higher in 
precedence in the PATH.  If you need to run Qt3 applications, you will either 
need to specify the full path or restructure your PATH to make it work.

Even though Trolltech split out the GUI libraries from the rest of the core 
libraries, X11 is still a dependency for the whole package.  The reason for 
this is that, as of now, Trolltech hasn't provided a convenient way to build 
a subset of the libraries - it's really an all or nothing thing.  Eventually 
once the development stabilizes a bit, I think it will be feasible to have a 
gui and non-gui set of ebuilds.

All that said - the latest version in portage ( qt-4.0.0_rc1-r2 ) works and 
installs great for me.  At this point, it may be good for aches to try 
testing the installation, as well as people who use non-traditional setups, 
like icc, ulibc, or interesting CXXFLAGS.

At the moment, I don't know of any installable applications that make use of 
this new Qt version, but they'll be springing up very soon.  Hopefully we'll 
be ready for them.

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



Re: [gentoo-dev] Re: Re: KDE 3.4 visibility support disabled

2005-05-26 Thread Caleb Tennis
On Thursday 26 May 2005 02:30 am, Duncan wrote:
 So the KDE problem... Is that what's causing all those virtual function
 but destructor isn't virtual type warnings whenever I compile a KDE ebuild
 with gcc4?

No, that's just shoddy C++ coding that also needs to be fixed.

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