[gentoo-dev] net-im/ejabberd up for grabs
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
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
+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
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
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?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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?
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?
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
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
* 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
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?
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
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
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
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
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
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
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?
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?
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?
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
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
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?
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
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?
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
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] Find apps not ported to modular X
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)
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)
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
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
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
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
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
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
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] Re: RFC: qt.eclass
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
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
(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
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
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
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
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
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
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
