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
+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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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.
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.
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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 mind
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.
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
--
* 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
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
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
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 I've
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
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
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
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
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
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
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 fast...
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 unsupported upstream
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
--
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
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
Follow up: Two devs have already mailed me on it.
Thanks,
Caleb
--
gentoo-dev@gentoo.org mailing list
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,
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
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
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 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 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
(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
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
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 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
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
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 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
--
76 matches
Mail list logo
