I was maintaining this on behalf of some folks previously, but it could use a
new
maintainer if someone is so inclined.
Caleb
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 u
>> 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
> 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 opens
> 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 maili
> +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 t
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.
An
> 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 sqlite
> 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
> 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
> 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 r
> 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
> 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.
> 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
> 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
> 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 ebuil
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
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 PROT
> Did you autogenerate these ebuilds? It looks like the deps were pulled
> out of a conditional in the original qt.
They were pulled out, but they weren't autogenerated. It's all still a work in
progress.
> I've seen this in all of the split qt ebuilds. Should it go in the eclass?
Yep, going to
> 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
> 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
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 do
> 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
> 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 encrypte
> 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
> 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 packa
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
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
>> 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
> 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
> 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
> 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 K
> 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
> 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
> 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 t
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
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 an
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 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
> 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 min
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.
Not
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@g
> * 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 t
> 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
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 o
> 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 tr
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
> 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
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
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:
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 lo
> 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
> 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
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 pa
> I disagree with separate packages, if it's possible to build both at
> once. That's the point of USE flags.
I'd say that's fine in the general case, but with a slotted package it's
going to be extremely messy.
I think we're in agreement that "qt" should represent the most recent
version support
> Currently we are at 4), should we change anything?
My proposal:
I would personally like to stay with just the "qt" use flag. The use flag
will be for support of whichever version of Qt is supported (v3 or v4) for
the particular emerge.
In the cases where more than one version is supported, it
> 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
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
> 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 fas
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
>> 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 "unsuppor
> 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
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
> >
>
> it would seem i lied about this (at least the first two still work)
Still, the behavior of
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 a
Follow up: Two devs have already mailed me on it.
Thanks,
Caleb
--
gentoo-dev@gentoo.org mailing list
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
> 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,
> 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,
> 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
> disli
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
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", "
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,
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 ch
On Friday 01 July 2005 08:56 am, Aron Griffis wrote:
> How about this?
>
> ebuild:
> DEPEND="some stuff"
> qt_min_dep "3.3"
How do you handle the ebuilds which use the qt use flag to determine whether
or not that qt is a dependency?
Caleb
--
gentoo-dev@gentoo.org mailing list
On 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
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\",
> plea
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,
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 :
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 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
(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
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
On Thursday 16 June 2005 11:50 am, Rafael Espíndola 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 overl
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@g
> Is it accepted practice to allow for changes in an ebuild without changing
> the ebuild version number?
It's a bad practice, but it also saves the end user from having to re-emerge
packages which have minor changes in them that may or may not affect them.
> Background
> --
> After emer
On Thursday 14 April 2005 04:54 pm, Stephen Bennett wrote:
> > use blah && ( emake foo || die )
>
> Yep, because that doesn't work.
Wow. I've been doing it for years. What's broken about it, the nested die ro
the "use blah &&" part?
Caleb
--
gentoo-dev@gentoo.org mailing list
So it seems repoman doesn't like nested die calls like this:
use blah && ( emake foo || die )
But, without the parenthesis
use blah && emake foo || die
always dies (the emake functions just fine, but it returns an error once emake
is completed).
What's the trick? Wrap the emake in a if/then
87 matches
Mail list logo
