[gentoo-dev] Another resignation
Hi, I think it's time for me to resign as a Gentoo developer. No bad blood or anything like that, I just realized that after being very active during 2005, in the last months I couldn't find time anymore for Gentoo development. Also, a month ago I moved from Italy to Los Angeles to work at UCLA (a really great experience for me), and after settling down I feel quite confident that my current activity won't leave me much spare time anytime soon... I wish you guys all the best, and I will continue to be a happy gentoo user from now on. In particular, I want to thank Carsten, Caleb, Dan, Diego for all the work they did and do for KDE, I'm sorry to leave you guys! Good luck. Gregorio -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Tuesday 29 November 2005 03:40, Mark Loeser wrote: Mike Frysinger [EMAIL PROTECTED] said: that means when people upgrade to gcc-3.4, gcc-3.3 will remain on their system until they remove it so if user fails to rebuild all their packages before unmerging gcc-3.3 they will be screwed, but OH WELL Yea. Even after they remove it though, libstdc++-v3 should be pulled in after that. Only issue I really see is people that have libraries compiled with 3.3 and 3.4 and don't know why stuff is broken. I don't know how large of a problem that will be though. It will be huge, see https://bugs.gentoo.org/show_bug.cgi?id=64615 https://bugs.gentoo.org/show_bug.cgi?id=61146 Every user _must_ be instructed to run 'revdep-rebuild --soname libstdc++.so.5', if a system contains things linking to libstdc++.so.5 and things linking to libstdc++.so.6 I consider it horribly broken. Thus having libstdc++-v3 installed apparently solves a problem but in fact does not solve anything, the only solution is to recompile everything c++ related on the system. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: New Bugzilla HOWTO
On Thursday 07 July 2005 23:05, Gregorio Guidi wrote: Also, it would be easier for user to avoid selecting Bugzilla as product if the form was a bit friendlier, something like this... http://dev.gentoo.org/~greg_g/enter_bug/enter_bug-report.html Mmm... it should have been http://dev.gentoo.org/~greg_g/enter_bug/enter_bug-main.html sorry. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: New Bugzilla HOWTO
On Thursday 07 July 2005 22:15, Duncan wrote: Simon Stelling posted [EMAIL PROTECTED], excerpted below, on Thu, 07 Jul 2005 20:49:04 +0200: Hi, Chris White wrote: jforman EBUILD BUGS GO IN GENTOO LINUX PRODUCT STOP MARKING EVERY BUG AS A BLOCKER /jforman What about changing the description for the severity field rather than jelling at users? Honestly, if a bug prevents you from using your favourite app, wouldn't you select Blocker: This bug prevents a software application from testing and use.? Or what about Critical: The software crashes, hangs, or causes you to lose data.? Perhaps I should file a blocker bug about this ;) Well, not blocker g, but ... http://bugs.gentoo.org/show_bug.cgi?id=73181 I must add: http://bugs.gentoo.org/show_bug.cgi?id=92492 Also, it would be easier for user to avoid selecting Bugzilla as product if the form was a bit friendlier, something like this... http://dev.gentoo.org/~greg_g/enter_bug/enter_bug-report.html -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] use.desc and use.local.desc cleanup
On Wednesday 06 July 2005 00:36, Sven Wegener wrote: Hi all! Please see below for a list of use.desc and use.local.desc entries that are currently unused. I also include a list of local flags for which a global flag with the same name exists. Local flags that are also global flags: sci-mathematics/scilab: atlas The global atlas flag should be removed instead, so I just deleted it from use.desc. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: qt.eclass
On Saturday 02 July 2005 22:54, Caleb Tennis wrote: 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. We can start porting those ebuilds that just need to be changed using =x11-libs/qt-3*. Then we can change kde-functions.eclass for the ebuilds using need-qt() (which can set something like e.g. || ( =x11-libs/qt-3.3* ... =x11-libs/qt-3.1* ) ); and finally we can deal with the remaining ebuilds (not many probably) using the qt.eclass (or qt3.eclass, or qt3-info.eclass, or whatever), or again something like || ( =x11-libs/qt-3.3* ... =x11-libs/qt-3.1* ) ) where possible. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: qt.eclass
On Thursday 30 June 2005 19:54, Caleb Tennis wrote: (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 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. 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. There is also another consideration to do: many Qt applications, or applications with optional Qt support, are not maintained by the qt/kde herd. We had many problems in the past because it was not easy at all to write ebuilds for these applications, this time we should make this task as intuitive as possible. There was a lot of discussion internally already with particular focus on the kde eclasses, but the problems for Qt and KDE applications are nearly the same so designing a new qt eclass uncovers the same problems. Among the options discussed, I particularly like the following one (I think something like this also showed up in this thread, too): 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()... For the applciations (5% ?) that require an higher version of Qt, the ebuild should look like: NEED_QT=4.1 inherit qt4 HOMEPAGE=... SRC_URI=... ... the qt4 eclass would insert the right line in DEPEND. For applications with optional Qt support, the ebuild could manually set the dependency on x11-libs/qt; it is enough to ship a qt4-info.eclass that provides useful functions, with qt_min_versions() among them. So an ebuild with optional Qt support could be like inherit qt4-info HOMEPAGE=... SRC_URI=... DEPEND=qt? ( =x11-libs/qt-4* ) ... (I think this would be the case for 99% of the ebuilds) or inherit qt4-info HOMEPAGE=... SRC_URI=... DEPEND=qt? ( $(qt_min_version 4.1.2) ) ... if there's absolutely no other way to do it. This proposal is meant for Qt, but it should be read as a proposal for both Qt and KDE: we can have a kde4.eclass and a kde4-info.eclass that work in the same way. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: qt.eclass
On Saturday 02 July 2005 22:09, Dan Armak wrote: On Saturday 02 July 2005 22:41, Gregorio Guidi wrote: [...] An application based on Qt4 should look just like this: inherit qt4 HOMEPAGE=... SRC_URI=... ... [...] This proposal is meant for Qt, but it should be read as a proposal for both Qt and KDE: we can have a kde4.eclass and a kde4-info.eclass that work in the same way. I know you know this, but for other readers, this is exactly the design of the current kde.eclass+kde-functions.eclass :-) At least it was until they gathered up a huge amount of special cases and backward support. Exactly, in fact this should be reassumed also as kde eclass started from scratch, without the evil need-kde() :) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] intention for kde-themes eclass
On Tuesday 14 June 2005 04:19, Brian Jackson wrote: Chris White wrote: Here's the nitty gritty: -- BACKGROUND -- kde-look.org is a site that hosts various kde themes to change the look and feel of the kde desktop. - REASONING - An eclass such as this would be benificial to users that want to create custom ebuilds for various kde themes, as well as getting popular kde themes into the portage tree. I actually half wrote a g-cpan.pl like thing for kde-look.org once. It could handle themes and wallpapers. I never got around to the rest. I think something like this would be better in the long run since the eclass will only serve to make people file more new ebuild bugs for stuff the kde team won't add. I second that, that's exactly what I thought when I saw the proposal. A few other points to consider: - As Michael pointed out, kde-look.org already tries to be a install-with-few-clicks portal, and kde is going more and more in this direction with the integration in kde 4. - Often there's no real consistency in content packaged on kde-look, users just offer for public download things packaged as they feel. - Projects appear and become obsolete on kde-look at an _impressive_ rate. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] encode useflag
On Thursday 12 May 2005 20:55, Simon Stelling wrote: Mike Frysinger wrote: so ? can you show me a package that this difference matters ? if not, then having lame sep from mp3 is pointless ... It's analog to the lesstif use flag: lesstif - Use lesstif over openmotif in cases where a program supports both lame - Use lame over $OTHER_MP3ENCODING_LIBRARY where both are supported Is there a package where this could apply? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] encode useflag
On Thursday 12 May 2005 21:22, Diego 'Flameeyes' Pettenò wrote: On Thursday 12 May 2005 21:20, Gregorio Guidi wrote: Is there a package where this could apply? We have couple of packages which can use both lame or toolame. ...toolame doesn't seem to do mp3s, so it doesn't overlap with lame. (and btw it seems a dead project since two years, who would want it ;) -- gentoo-dev@gentoo.org mailing list
