Re: [gentoo-dev] New project: Gentoo Artwork
On 4/29/07, William L. Thomson Jr. [EMAIL PROTECTED] wrote: On Fri, 2007-04-27 at 11:28 +0200, Bjarke Istrup Pedersen wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It would be nice if there where some CD/DVD labels created, that people could print and put on their LiveCDs/InstallCDs :-) Yes that would be quit nice. At LWE in 06 we were handing out cds we were burning with hand written labels. So for any events were we give out livecds and etc. Would make a big difference at least in first impressions for many, IMHO. I've found something here... http://download.iansview.com/gentoo/artwork/ian/livecds/ -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] new herd: theology
Josh Saddler wrote: It would only be called humanities if it was also trying to include gramps (geneology) with the other 7 packages which are explicitly religious in nature. As beandog has already said, gramps has been removed from the herd. I had missed that part in the other threads. My bad. Rémi -- [EMAIL PROTECTED] mailing list
[gentoo-dev] gentoo: static/dynamic linking libraries
I'm now using gentoo with EXTRA_ECONF=--disable-static for a while and it seems quite stable. Sometimes I encounter a package that won't build with this setting, but that's a rare occasion. At the moment this packages are for me: x11-libs/libXxf86vm sys-devel/gdb-6.6 dev-libs/jrtplib-3.5.2 dev-libs/libpcre sys-apps/ed I see that this way to disable static libraries is not perfect. Disabling static linking has - for me - before all the advantage of reducing size for most packages - for some packages up to 50%. So I'm curious why (nearly?) all ebuilds build static _and_ dynamic libraries? I understand that the current way is pretty hassle-free. But from my perspective a (possibly officialy unsupported) way to make things easier for people who wan't the choice would be fine. I'm sorry if there has been such a discussion already. Also I don't want to start a flame about what is the better choice (static or dynamic). regards Roman pgpXU7XoTHJaM.pgp Description: PGP signature
Re: [gentoo-dev] gentoo: static/dynamic linking libraries
On 4/29/07, Roman Zimmermann [EMAIL PROTECTED] wrote: I'm now using gentoo with EXTRA_ECONF=--disable-static for a while and it seems quite stable. Sometimes I encounter a package that won't build with this setting, but that's a rare occasion. At the moment this packages are for me: dev-libs/libpcre Disabling static libs in libpcre makes sys-apps/grep w/ USE=pcre bomb out on compile... Just an example why you should always install both of them. Disabling static linking has - for me - before all the advantage of reducing size for most packages - for some packages up to 50%. So I'm curious why (nearly?) all ebuilds build static _and_ dynamic libraries? I understand that the current way is pretty hassle-free. But from my perspective a (possibly officialy unsupported) way to make things easier for people who wan't the choice would be fine. See http://bugs.gentoo.org/show_bug.cgi?id=165629, http://marc.info/?l=gentoo-devm=116026024223024w=2 etc. -- Jakub Moc Email: [EMAIL PROTECTED] -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: new herd: theology
Le Sat, 28 Apr 2007 22:27:47 + (UTC), Duncan [EMAIL PROTECTED] a écrit : Dominique Michel [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Sat, 28 Apr 2007 18:32:50 +0200: I disagree. When searching for a software to do a given job and when I have no idea of which software can do it, I begin to look for the ebuild descriptions in the portage tree. It goes faster as anything else with mc. And I will never search a genealogy program in theology, so I will just miss it if it is in theology. I think you are missing the distinction between category/package, as seen in the tree and therefore affecting users and externally visible, and herd, which many users likely aren't aware of at all, as it's primarily a Gentoo-internal way for devs to organize packages of a similar theme they may be interested in working on. It is well possible as I am not a dev. (still) I will look at it. But it doesn't change at some devs expressed the same concern in this thread. Another fact remain: theology is about religion when genealogy is about sciences. Ciao, Dominique -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] new herd: theology
Le Sat, 28 Apr 2007 18:25:46 -0700, Josh Saddler [EMAIL PROTECTED] a écrit : Nathan Smith wrote: On 4/28/07, Rémi Cardona [EMAIL PROTECTED] wrote: Josh Sled wrote: If that's the case, might not humanities be a better name? s/theology/humanities/ sounds good. +1 from me. Rémi -- [EMAIL PROTECTED] mailing list Indeed. Even if we wanted a herd specific to religion, theology is not the best choice since I've yet to conceive of how a program can do theology. Certain types of programs can inform one's theology (textual studies programs based on SWORD are a good example of this), but the same programs have various other uses. Humanities is a good enough description. It would only be called humanities if it was also trying to include gramps (geneology) with the other 7 packages which are explicitly religious in nature. As beandog has already said, gramps has been removed from the herd. religion or theology is clearly the most appropriate category of the remaining packages. There's no need to rename the herd to humanities just because some folks are uncomfortable with topics and packages relating to religion. Think about your local library (Dewey decimal system) -- you don't find Bible study guides in the humanities/sociology (300s, 400s, 600s, 800s and possibly 900s (history))...you find it in 100s and 200s. The sections on religion and philosophy. the remaining 7 packages are clearly religious in nature. Don't try to label them anything else, just because you ain't comfortable with it or don't like 'em. I agree with you. And genealogy is somewhere in the sciences or human sciences section. Dominique -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: new herd: theology
On Sunday, April 29, 2007 12:00:08 PM Dominique Michel wrote: Another fact remain: theology is about religion when genealogy is about sciences. Theology *is* a science. Anyway, gramps is no longer part of the theology herd. Can we drop this now? Best regards, Wulf pgpvhWvMjUbRS.pgp Description: PGP signature
Re: [gentoo-dev] gentoo: static/dynamic linking libraries
On Sun, 29 Apr 2007 10:54:12 +0200 Jakub Moc [EMAIL PROTECTED] wrote: On 4/29/07, Roman Zimmermann [EMAIL PROTECTED] wrote: I'm now using gentoo with EXTRA_ECONF=--disable-static for a while and it seems quite stable. Sometimes I encounter a package that won't build with this setting, but that's a rare occasion. At the moment this packages are for me: dev-libs/libpcre Disabling static libs in libpcre makes sys-apps/grep w/ USE=pcre bomb out on compile... Just an example why you should always install both of them. No, that's an example of why you should sometimes install both. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Last rites media-gfx/opcion
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 William L. Thomson Jr. wrote: Last rites for media-gfx/opcion Last upstream release was 1.1.1, released April 24, 2004. The package has been masked, and will be moved to Java junkyard overlay after 30 days pass. Unless someone cares about this package, needs it, uses it, and/or is willing to updated it. Recalled and unmasked at user's request. - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGNHrytbrAj05h3oQRAlazAJ9Q3BW5NyCwH8a1raeS5eNyzLclWgCdEEDl znlqWjgDr/4Sqsiv5jOT4M0= =Oalb -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Virtuals and Java
We want to implement virtuals for Java at some point and for that we
need to know the package that provides the virtual because some virtuals
can be provided by the JDK or normal packages and this affects the JDK
selection at build time. One option is to call into Portage to find this
out, but of course Paludis and Pkgcore people most likely don't like
this approach. One thing that comes to mind is to allow for virtuals to
install files so we can install the provider information in a format
easy for us. We need the information in format ${PN}-${SLOT} because
that's the way we install in /usr/share. So do you think it's ok for
virtuals to install files (we can of course call the category
java-virtual/ too), should we call Portage code, or do you have an
another idea?
Regards,
Petteri
--
Gentoo/Java project lead
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Last rites media-sound/jsynthlib
William L. Thomson Jr. ha scritto: Last rites for media-sound/jsynthlib Last upstream release was 0.20-beta, released March, 2005. The package has been masked, and will be moved to Java junkyard overlay after 30 days pass. Unless someone cares about this package, needs it, uses it, and/or is willing to updated it. I need/use it! shall I provide an updated ebuild or try to maintain it? (note: I'm not a dev; I'll send you ebuilds through g.o bugzilla) -- Federico -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Looking for help with 2.6 kernel maintenance
Hi, I'm looking to find one or more people to help out with gentoo-sources-2.6 maintenance (our primary supported kernel). I'm looking for someone with at least: - Interest in kernel stuff, or a desire to become interested - Time to put towards the tasks - Enthusiasm to ask lots of questions rather than let stuff sit around - Basic experience with bugzilla - Basic kernel experience (i.e. you can compile your own) Having knowledge of kernel internals or experience with kernel hacking are not requirements because if you have time, interest and ask a lot of questions then these will come anyway. A lot of the work doesn't involve technical stuff, plus I was certainly very clueless about all this when I originally got involved a couple of years ago. Being an existing Gentoo developer is not a requirement. Most of the work is done on bugzilla and via email. This may be a good opportunity to get involved with development and later become a Gentoo developer for those that are interested. It's an enjoyable task, you get to interact with a lot of very intelligent people upstream and you end up learning a lot. I still intend to continue working on gentoo-sources in large capacity, but would like to be able to have more time to spend on more aggressive regression fixing and upstream kernel development. Contact me offlist or on IRC if you are interested. Thanks, Daniel -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] gentoo: static/dynamic linking libraries
Am Sonntag 29 April 2007 12:36 schrieb Ciaran McCreesh: On Sun, 29 Apr 2007 10:54:12 +0200 Jakub Moc [EMAIL PROTECTED] wrote: On 4/29/07, Roman Zimmermann [EMAIL PROTECTED] wrote: I'm now using gentoo with EXTRA_ECONF=--disable-static for a while and it seems quite stable. Sometimes I encounter a package that won't build with this setting, but that's a rare occasion. At the moment this packages are for me: dev-libs/libpcre Disabling static libs in libpcre makes sys-apps/grep w/ USE=pcre bomb out on compile... Just an example why you should always install both of them. No, that's an example of why you should sometimes install both. These are 5 packages out of 845 on my system. For those with version number it is only a compile time error, when make errornously tries to build a static target. Those without number are needed static by another package or don't like --disable-static (sys-apps/ed). That leaves 2 out of 845. So I'm with Ciaran here: It works for almost all packages and makes at least some difference. Maybe enough to (really) give the users the choice (without the ugly EXTRA_ECONF-hack)? Those links Jakub posted are interesting, but I don't find an explanation why this decission was made. Maybe you have a link to that discussion too? pgptEfQSM1KOK.pgp Description: PGP signature
Re: [gentoo-dev] gentoo: static/dynamic linking libraries
On Sun, 29 Apr 2007 18:43:29 +0200 Roman Zimmermann [EMAIL PROTECTED] wrote: Those links Jakub posted are interesting, but I don't find an explanation why this decission was made. Maybe you have a link to that discussion too? What decision? That USE=static shouldn't be used for (not) installing static libraries is simply because the flag is used to control how (parts of) a package should be linked and global flags shouldn't be used for completely different purposes. That's been the case since the beginning, so I doubt you'll find any dicussion about it. Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-dev] gentoo: static/dynamic linking libraries
On Sun, 29 Apr 2007 19:50:58 +0200 Marius Mauch [EMAIL PROTECTED] wrote: On Sun, 29 Apr 2007 18:43:29 +0200 Roman Zimmermann [EMAIL PROTECTED] wrote: Those links Jakub posted are interesting, but I don't find an explanation why this decission was made. Maybe you have a link to that discussion too? What decision? That USE=static shouldn't be used for (not) installing static libraries is simply because the flag is used to control how (parts of) a package should be linked and global flags shouldn't be used for completely different purposes. That's been the case since the beginning, so I doubt you'll find any dicussion about it. The more interesting question is why static libraries are built and installed for most packages at all. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] gentoo: static/dynamic linking libraries
Am Sonntag 29 April 2007 19:50 schrieb Marius Mauch: On Sun, 29 Apr 2007 18:43:29 +0200 Roman Zimmermann [EMAIL PROTECTED] wrote: Those links Jakub posted are interesting, but I don't find an explanation why this decission was made. Maybe you have a link to that discussion too? What decision? That USE=static shouldn't be used for (not) installing static libraries is simply because the flag is used to control how (parts of) a package should be linked and global flags shouldn't be used for completely different purposes. That's been the case since the beginning, so I doubt you'll find any dicussion about it. There is also the part about: packages that can install static and shared libraries should always be installing them. [http://marc.info/?l=gentoo-devm=116026024223024w=2] Which means either that this statement was meant for another context (and not in such a general meaning) or it says that there shouldn't/won't be a way to change this behavior. In case 1 this misses the point. (As Ciaran pointed out.) Since I was not specifically talking about the 'static' useflag. For case 2 I'm very interested in the reason. pgpnVRT4W10cb.pgp Description: PGP signature
Re: [gentoo-dev] gentoo: static/dynamic linking libraries
Roman Zimmermann wrote: So I'm with Ciaran here: It works for almost all packages and makes at least some difference. Maybe enough to (really) give the users the choice (without the ugly EXTRA_ECONF-hack)? I wonder why you call this an ugly hack? It seems to me everyone who wishes to avoid installing static libs is able to do so with a simple variable. Having such a feature exposed to the mainstream crowd without proper support by developers (testing and such) will not do any good. cheers Paul -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] gentoo: static/dynamic linking libraries
Am Sonntag 29 April 2007 20:46 schrieb paul kölle: Roman Zimmermann wrote: (without the ugly EXTRA_ECONF-hack)? I wonder why you call this an ugly hack? It seems to me everyone who wishes to avoid installing static libs is able to do so with a simple variable. Having such a feature exposed to the mainstream crowd without proper support by developers (testing and such) will not do any good. This is an ugly code since it's relies on econf which is - as an implementation detail - only used for packages with ./configure. (according to the ebuild howto). So it's not really a feature but a lucky assumption that most packages know what to do with ./configure --disable-static. Additionally handling exceptions with package.env can be a pain. It is much less supported by tools than package.use or .keywords. You are right that it would be wrong to expose this feature. But having it readily available and exposing it are two different sorts of things. pgpoGB49S0MSm.pgp Description: PGP signature
Re: [gentoo-dev] gentoo: static/dynamic linking libraries
On Sun, 29 Apr 2007 21:04:07 +0200 Roman Zimmermann [EMAIL PROTECTED] wrote: Am Sonntag 29 April 2007 20:46 schrieb paul kölle: Roman Zimmermann wrote: (without the ugly EXTRA_ECONF-hack)? I wonder why you call this an ugly hack? It seems to me everyone who wishes to avoid installing static libs is able to do so with a simple variable. Having such a feature exposed to the mainstream crowd without proper support by developers (testing and such) will not do any good. This is an ugly code since it's relies on econf which is - as an implementation detail - only used for packages with ./configure. (according to the ebuild howto). So it's not really a feature but a lucky assumption that most packages know what to do with ./configure --disable-static. Additionally handling exceptions with package.env can be a pain. It is much less supported by tools than package.use or .keywords. An alternative that doesn't rely on autotools would be using INSTALL_MASK. Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-dev] gentoo: static/dynamic linking libraries
On Sun, 29 Apr 2007 21:31:52 +0200 Marius Mauch [EMAIL PROTECTED] wrote: An alternative that doesn't rely on autotools would be using INSTALL_MASK. Doesn't solve the packages take twice as long to compile as they should issue. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] gentoo: static/dynamic linking libraries
On Sun, 2007-29-04 at 20:36 +0100, Ciaran McCreesh wrote: On Sun, 29 Apr 2007 21:31:52 +0200 Marius Mauch [EMAIL PROTECTED] wrote: An alternative that doesn't rely on autotools would be using INSTALL_MASK. Doesn't solve the packages take twice as long to compile as they should issue. A combination of passing --disable-static to econf and INSTALL_MASK should do it. That said, having a feature/use flag to enable static library might not be such a good idea (and disable it on packages where static libraries are needed). -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] gentoo: static/dynamic linking libraries
Ciaran McCreesh wrote: On Sun, 29 Apr 2007 10:54:12 +0200 Jakub Moc [EMAIL PROTECTED] wrote: On 4/29/07, Roman Zimmermann [EMAIL PROTECTED] wrote: I'm now using gentoo with EXTRA_ECONF=--disable-static for a while and it seems quite stable. Sometimes I encounter a package that won't build with this setting, but that's a rare occasion. At the moment this packages are for me: dev-libs/libpcre Disabling static libs in libpcre makes sys-apps/grep w/ USE=pcre bomb out on compile... Just an example why you should always install both of them. No, that's an example of why you should sometimes install both. Open Question part: Since I don't have any thing other than Gentoo : does anyone know how other distros handle static libs in their -dev packages? Does anyone care about static libs except for maybe really really low level stuff? My Opinion part: I'd definitely would like to see them leave my system for good as I have no use for 99% of them whatsoever. Open Question part: Could some FEATURE disable static libs building by default in desktop profiles, with some (like the 5 packages Roman pointed out) using something like a RESTRICT? (These questions are really not meant to be inflammatory and they are honest questions as I'm learning the trade here. Yet, if I'm way off, please let me know :) ) Cheers, Rémi -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] gentoo: static/dynamic linking libraries
Rémi Cardona wrote: Since I don't have any thing other than Gentoo : does anyone know how other distros handle static libs in their -dev packages? Does anyone care about static libs except for maybe really really low level stuff? Anyone who wants to build a static binary wants the static libs. Given the difficulty in universally enabling or disabling their builds because of build-system differences, building them and tossing them in the trash with INSTALL_MASK, as Marius suggested, seems like the best way to go. Thanks, Donnie signature.asc Description: OpenPGP digital signature
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2007-04-29 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2007-04-29 23h59 UTC. Removals: dev-perl/Newt 2007-04-24 22:29:27 mcummings dev-java/eclipse-core 2007-04-25 15:34:37 betelgeuse dev-java/eclipse-jface 2007-04-25 15:34:37 betelgeuse dev-java/eclipse-osgi 2007-04-25 15:34:37 betelgeuse net-misc/nx-x11-bin 2007-04-26 09:09:06 voyageur net-misc/nx-x11 2007-04-26 09:11:15 voyageur net-misc/nxcomp 2007-04-26 09:11:15 voyageur net-misc/nxesd 2007-04-26 09:11:15 voyageur net-misc/nxproxy2007-04-26 09:11:15 voyageur net-misc/nxssh 2007-04-26 09:11:15 voyageur dev-java/datavision 2007-04-27 08:42:27 wltjr dev-util/jcvs 2007-04-28 16:27:06 betelgeuse dev-java/j2ssh 2007-04-28 16:27:49 betelgeuse dev-java/javatar2007-04-28 23:09:18 betelgeuse dev-haskell/buddha 2007-04-29 17:08:42 dcoutts Additions: dev-python/yolk-portage 2007-04-23 05:52:32 pythonhead dev-python/yolk 2007-04-23 05:56:36 pythonhead sci-mathematics/rkward 2007-04-23 14:37:11 bicatali app-text/wklej 2007-04-23 23:57:13 jurek dev-java/jibx 2007-04-24 09:56:39 nelchael www-apps/gnopaste 2007-04-24 10:34:19 jurek app-text/gnopaster 2007-04-24 10:44:52 jurek net-proxy/ufdbguard 2007-04-24 13:49:40 bass sci-visualization/mayavi2007-04-24 15:55:31 bicatali dev-python/twill2007-04-24 19:37:59 pythonhead sci-biology/meme2007-04-24 20:44:01 ribosome dev-util/deskzilla 2007-04-24 22:09:31 caster dev-java/jempbox2007-04-24 23:23:43 caster dev-java/pdfbox 2007-04-25 00:23:45 caster net-misc/nxclient-2xterminalserver 2007-04-25 12:58:04 voyageur app-portage/autounmask 2007-04-25 13:44:50 ian dev-perl/Passwd-Linux 2007-04-25 15:21:14 ian net-misc/nxserver-2xterminalserver 2007-04-25 16:02:33 voyageur games-simulation/fgrun 2007-04-26 06:16:18 tupone app-portage/meatoo 2007-04-26 15:53:53 pythonhead games-strategy/knights-demo 2007-04-27 04:47:24 mr_bones_ net-im/kopete-otr 2007-04-27 10:06:10 drizzt dev-java/glassfish-servlet-api 2007-04-27 20:37:12 wltjr games-strategy/lightyears 2007-04-27 20:57:33 tupone dev-java/laf-plugin 2007-04-28 22:08:06 caster net-im/pyicq-t 2007-04-28 23:34:00 griffon26 app-text/omegat 2007-04-29 05:18:14 matsuu dev-embedded/zmac 2007-04-29 09:37:14 ulm gnome-extra/contacts2007-04-29 18:04:17 dertobi123 -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: dev-perl/Newt,removed,mcummings,2007-04-24 22:29:27 dev-java/eclipse-core,removed,betelgeuse,2007-04-25 15:34:37 dev-java/eclipse-jface,removed,betelgeuse,2007-04-25 15:34:37 dev-java/eclipse-osgi,removed,betelgeuse,2007-04-25 15:34:37 net-misc/nx-x11-bin,removed,voyageur,2007-04-26 09:09:06 net-misc/nx-x11,removed,voyageur,2007-04-26 09:11:15 net-misc/nxcomp,removed,voyageur,2007-04-26 09:11:15 net-misc/nxesd,removed,voyageur,2007-04-26 09:11:15 net-misc/nxproxy,removed,voyageur,2007-04-26 09:11:15 net-misc/nxssh,removed,voyageur,2007-04-26 09:11:15 dev-java/datavision,removed,wltjr,2007-04-27 08:42:27 dev-util/jcvs,removed,betelgeuse,2007-04-28 16:27:06 dev-java/j2ssh,removed,betelgeuse,2007-04-28 16:27:49 dev-java/javatar,removed,betelgeuse,2007-04-28 23:09:18 dev-haskell/buddha,removed,dcoutts,2007-04-29 17:08:42 Added Packages: dev-python/yolk-portage,added,pythonhead,2007-04-23 05:52:32 dev-python/yolk,added,pythonhead,2007-04-23 05:56:36 sci-mathematics/rkward,added,bicatali,2007-04-23 14:37:11 app-text/wklej,added,jurek,2007-04-23 23:57:13 dev-java/jibx,added,nelchael,2007-04-24 09:56:39 www-apps/gnopaste,added,jurek,2007-04-24 10:34:19 app-text/gnopaster,added,jurek,2007-04-24 10:44:52 net-proxy/ufdbguard,added,bass,2007-04-24 13:49:40 sci-visualization/mayavi,added,bicatali,2007-04-24 15:55:31 dev-python/twill,added,pythonhead,2007-04-24 19:37:59 sci-biology/meme,added,ribosome,2007-04-24 20:44:01 dev-util/deskzilla,added,caster,2007-04-24 22:09:31
Re: [gentoo-dev] Looking for help with 2.6 kernel maintenance
Hi Daniel, I talked with you quickly on the irc. I'm interested in helping gentoo with kernel related stuff. I have a base kernel knowledge, but in these last few days I've been reading lots of kernel related stuff, I got very interested on it and want to learn more about it. I generally have more then 4 hours a day to work on this kind of thing, so, maybe I can help the team. No problems with bugzilla, I've working using it for the last few years. I've been using gentoo for more than 2 years, and now that I I'm graduated and have some available time, I want to spend it on this kind of thing. If you could send more info about the work it'd be nice! Thanks, -- Ricardo Salveti -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] gentoo: static/dynamic linking libraries
Am Montag 30 April 2007 00:11 schrieb Ciaran McCreesh: On Sun, 29 Apr 2007 14:56:57 -0700 Donnie Berkholz [EMAIL PROTECTED] wrote: Anyone who wants to build a static binary wants the static libs. Given the difficulty in universally enabling or disabling their builds because of build-system differences, building them and tossing them in the trash with INSTALL_MASK, as Marius suggested, seems like the best way to go. The best way to go or the only viable short term solution? That's the point! Universally disabling static builds can't be a longterm solution. The only sane way to do this is on a per ebuild basis. Since only the ebuild knows whats the right way to disable static libs or whether this package supports it at all. As of now most packages use or ignore --disable-static in a proper way, but since GNU autotools are not that popular anymore the ignore part of the tree is inclined to grow. This method has the advantage that it either fails at compile time or works fine. Something gives me the feeling that INSTALL_MASK will break things after installation and silently, which is a bad thing. So no solution here. And as it was pointed out before. Static builds are not needed most of the time. There is only 2 packages that actually need the static libraries. The rest fails due to upstream bugs in the configure/makefile (recognizing --disable-static but only applying it partially). So --disable-static seems to me like the only half-sane-partial-short-time-solution. cheers pgpIqS2Q3K9uo.pgp Description: PGP signature
Re: [gentoo-dev] gentoo: static/dynamic linking libraries
On Mon, 30 Apr 2007 05:07:00 +0200 Roman Zimmermann [EMAIL PROTECTED] wrote: And as it was pointed out before. Static builds are not needed most of the time. There is only 2 packages that actually need the static libraries. The rest fails due to upstream bugs in the configure/makefile (recognizing --disable-static but only applying it partially). In your test case. With USE=static or when checking the whole tree you'd almost definitely get more packages needing it. Note that I'm not saying that there shouldn't be another way to disable building/installing static libs or that the general message of static builds being irrelevant in many cases is wrong, just that the claim of only 2 packages needing it is bogus. Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
