Re: [gentoo-dev] Re: Proposed change to base.eclass: EAPI-2 support
Hi, And emake is and still should be the default. If there is an issue with it, the ebuild author has to change his ebuild. But this should not be taken to force only one makejob for everyone else. But with rotating storage, don't you (very much) only want one I/O-bound job at a time? Regards, T.
Re: [gentoo-dev] [EMAIL PROTECTED]
Hi, Ciaran McCreesh wrote: On Thu, 19 Jun 2008 23:42:51 +0100 Mike Auty [EMAIL PROTECTED] wrote: And yet still you keep fighting? Why? Because unlike pretty much everyone else around here, I haven't given up on Gentoo. I still think it can have a future. If you really think that everyone else around here but a small minority has given up on Gentoo, how can you believe it still has a future? Regards, Thomas -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Optional Package Dependencies for netscape-flash - libflashsupport
Hi, Jim Ramsay wrote: [snip] Have netscape-flash with IUSE=vanilla (by default it is off), which when enabled will not pull in libflashsupport. I don't quite see why this is necessary? Or why you do have this discussion? This meets the following goals: 1) It makes it easy for regular users to get netscape-flash with any additions required by any global USE flags in exactly one step: - emerge netscape-flash So, in netscape-flash: RDEPEND= ssl? ( foo/libflashsupport ) pulseaudio? ( foo/libflashsupport ) esd? ( foo/libflashsupport ) oss? ( foo/libflashsupport ) and IUSE=ssl pulseaudio esd oss gnutls in libflashsupport (which, as already said, has it's own ebuild)? 2) It makes it easy for power users to not have libflashsupport actually install anything by disabling all the USE flags. This will take 3 steps: - Notice at upgrade or install time that there's this new 'extra' package being installed - Enable the 'vanilla' flag for netscape-flash - Continue with upgrade or install It's still easy enough to disable it via -* in package.use? Regards, Thomas -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [news-item] Paludis 0.24
Hi, Piotr Jaroszyński wrote: Hello, (...) Display-If-Installed: =sys-apps/paludis-0.24 You mean Display-If-Installed: sys-apps/paludis-0.24, right? Regards, Thomas -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: new herd: theology
Hi, I would hate to drag this discussion on endlessly, so I promise this will be my only post :). Dominique Michel wrote: Le Fri, 27 Apr 2007 20:07:26 -0700, Josh Saddler [EMAIL PROTECTED] a écrit : Steve Dibb wrote: Dominique Michel wrote: I fully agree, theology is the worst possible name if the herd will include both religious and scientific softwares. No worries, app-misc/gramps was dropped from the theology herd, and is herdless once again. So what's the big problem of sticking it into a herd somewhere, a herd that seems to be maintained by just one person (beandog in this case)? The fact at the herd is maintained by one or more peoples have nothing to do with this. It is about the meaning of the words and consistency. If I put gramps into theology, I can put gnome into kde, mplayer into media-sound and grabcartoons into theology. I still fail to see why this is such a big thing if one package which is mainly used in relation to a religion is in a herd called theology. It's not as if the world will come to a shattering halt and chaos will reign. If for some reason the gnome herd adopted fluxbox or the KDE people would take care of HAL, would you object because their herd names don't fit? Even if the alternative was the packet remaining herdless, because no other herd was interested? It's not as if this is a giant library, where a book will be lost forever if it's in the wrong category, or like putting ID on the science curriculum. Herds loosely lump related packages together, don't they? I thought they were just infrastructure, not real categories. Regards, Thomas -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
Hi, Ciaran McCreesh schrieb: On Thu, 29 Mar 2007 22:47:46 +0200 Thomas Rösner [EMAIL PROTECTED] wrote: Other things I want from Gentoo right now depend on factors other than the package manager, too; prebuilt packages A package manager that supports a better binary package format (split out local metadata would be a good start) combined with a third party binary provider could deliver that with no tree changes. But then you'd need a tree of binary packages, which you'd only get with many users of your package manager, which would depend on official Gentoo adoption, which would depend on compelling other features, which would depend on having a way to get them into the ebuild tree without breaking portage. That's what I mean. I think you know that and that's why you did work on PMS, but then you point out features paludis has and portage hasn't repeatedly in a way that apparently builds up resistance in people here. Hm, perhaps you should let somebody else do the PR for paludis? :-) Heck, it's even doable with Portage's binaries, although according to a Gentoo-based distribution that tried it, your 30 minutes would be optimistic for -uDpv world... Yes. Also it's quite easy to screw up using the current format, nothing I'd recommend for heterogeneous environments. binary-breakage protection Funnily enough... That one can be done without tree changes too via something we're calling reparenting. There're some vague suggestions of roughly how to do it at [1]. [1]: http://paludis.pioto.org/trac/ticket/129 Now that'd be an interesting feature... *thinks about joining #paludis* Regards, Thomas -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
Hi, Ciaran McCreesh wrote: Have a look at [1] and all the open Portage should... bugs. Would any of those improve the user experience for you? Can you think of other features of a similar nature that would make your life easier? Funny thing is: the only thing that I'd really care about are the USE deps. But to actually get those, it's not enough to use paludis, you'd have to have an ebuild tree that actually provides them. Then you'd get things like sane split up of monolith upstream packages, a way to implement multilib without binary packages, and other things I can't think of right now. Other things I want from Gentoo right now depend on factors other than the package manager, too; prebuilt packages, slow-moving tree, binary-breakage protection (and pre-upgrade notices of major changes). If you could cast a spell that got those features in, I'd happily wait 30 minutes for emerge -Duvat world... So to have an incentive to switch to paludis, it would have to be a supported Gentoo package manager, which drives what devs put into the tree. And to get there, it would have to get the masses to switch to paludis... So I think to get anywhere with all of this is to figure out ways to add the features to the tree without breaking portage (for the use flag dep example: let portage die on not matched use flag deps just like it does now in pkg_setup for the manual use flag checks; real support would of course mean reemerging the package in question with the right flags). And then, if portage really can't keep up with the pace of changes, alternatives would *have* to be considered. Am I making sense? That Portage works does not mean that it is anywhere near ideal... Nothing ever will be. :) Regards, Thomas -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] FYI: linux.com article about the CoC
Hi, for those interested, linux.com has a rather long article about the CoC, carefully worded so the email snippets sound like interview opinions :-). It seems the open source press will watch this list for some time to come, I see more articles than usual about Gentoo and the recent flamewar, and I suspect that any fight here will now be made a story and linked to the recent events. http://www.linux.com/article.pl?sid=07/03/26/139256 Regards, Thomas -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Something positive! (was Re: Client-serve flags (again ;))
Hi, Ciaran McCreesh schrieb: You really have no idea what's considered perfectly acceptable on the forums, do you? http://forums.gentoo.org/viewtopic-p-1053530.html#1053530 -- acceptable Now *that's* satire. See, on forums you can retract what you said (if you don't get quoted, that is), with a ML that's just not possible*. I agree with you, then, that this ML should have a higher standard of conduct than the forums. Regards, Thomas * Well, you can say you're sorry, but so far no one ever did AFAICT -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Client-serve flags (again ;) (was Re: New eclass: gkrellm-plugin)
Hi, Robin H. Johnson schrieb: On Sat, Mar 10, 2007 at 12:56:51AM +0100, Thomas R?sner wrote: I can understand that rationale for the client part, but which packages would depend on the server part of e.g. MySQL if they could? And building the server part to get the small client lib is a larger PITA than building the client lib to get the server, no? In other words: this is a sound argument against the client use flag, but I don't think it's quite as convincing regarding the server flag, which is more important IMHO. Btw, I agree that the best thing to do would be to prompt upstream to split those packages (where it makes sense), which is the preferred way to handle this here (at least I read this somewhere, does it still apply?), but does anybody do that actually? To stay with the MySQL example, did anyone try to suggest to MySQL AB that seperate releases for the client part* would be nice? It depends hugely on the structure of the code-base. In MySQL for example, if you wanted to build only the server, you'd still need a big hunk of the shared code (it's one set of code, that is compiled in two different ways, once for the client, and once for the server), and building the server actually requires building the client anyway (plus the proper shared libs) thus splitting out the source for lib, client, server does not make sense. Yes and no. The same applies to Postgres, and still they provide the libs in an extra package. It just makes sense, how much of that 20M mysql tarball is used by the client? It's like you'd have to dl apache (four times) to get wget. *investigates* Hm, perhaps the client does more than I thought it does, on one sys here it's a 1.5M lib. One of the other arguments I have against the split, and it applies to both CVS and MySQL - is that if you don't build the server, you cannot use src_test. I'd guess those with -server would be cool about that. Regards, Thomas -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Client-serve flags (again ;) (was Re: New eclass: gkrellm-plugin)
Hi, Robin H. Johnson wrote: Of the mysql tarball (23Mb to start), a full 40% belongs to the testcases and the documentation that they ship. Another 8% for the modified copy of BerkDB that they ship, and only then do we start getting really useful things. 12% for the things unique to the server, and thereafter everything else is common or client-only. Thanks for those numbers! So a server flag won't do much for dl in this case, only for build time (and it'd install less unwanted stuff, particularly in /etc). I guess MySQL isn't the poster child for the need of a server flag, then :-). Regards, Thomas -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Client-serve flags (again ;) (was Re: New eclass: gkrellm-plugin)
Chris Gianelloni schrieb: On Fri, 2007-03-09 at 11:10 +, Steve Long wrote: I don't know how it would work technically, how difficult it would be, or indeed if anyone is prepared to do the work, besides maybe some of the users. No. Once we have USE-based dependencies across the board, then yes. Until that time, we should really be building both client and server for *all* packages. I can understand that rationale for the client part, but which packages would depend on the server part of e.g. MySQL if they could? And building the server part to get the small client lib is a larger PITA than building the client lib to get the server, no? In other words: this is a sound argument against the client use flag, but I don't think it's quite as convincing regarding the server flag, which is more important IMHO. Btw, I agree that the best thing to do would be to prompt upstream to split those packages (where it makes sense), which is the preferred way to handle this here (at least I read this somewhere, does it still apply?), but does anybody do that actually? To stay with the MySQL example, did anyone try to suggest to MySQL AB that seperate releases for the client part* would be nice? Regards, Thomas * They already do this for their binaries, see http://mysql.org/downloads/mysql/5.0.html#Linux_x86_generic_RPM_(dynamically_linked). -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Sad
Hi, Disclaimer**: this mail is not meant to point the finger at someone, as I (thankfully) don't know enough about who did what first to whom to do that; in fact, I think no one does at this point. Ciaran McCreesh schrieb: On Sun, 4 Mar 2007 23:31:56 + (UTC) Hubert Mercier [EMAIL PROTECTED] wrote: In the last months, a some talented devs gone, and a few others were thinking to do so. How much more before deciding to simplify our organisation ? Simplifying it won't help. If Gentoo wants more developers, it has to do three things: * Start delivering again. Not just shiny things, although some new shiny things would help, but also things that users and developers really need. * Substantially reduce user-visible breakages and breakages caused by carelessness or deliberate negligence that take huge amounts of time to fix. * Reduce the amount of arcane undocumented voodoo. And, above all, * stop to treat -dev (and the projects) as the ideal battleground for personalities, the home of flames, the temple of mailwar. You know what people state* as the major benefit from using Gentoo? It's not portage, not the tree, certainly not stability or ease of use, it's two things, the community and flexibility. In this order. You all are a very visible part of that community. The only relevance of organisational issues is whether they help or hinder in achieving those objectives. I'll use those words for my point, instead. The above list could be the agenda of Microsoft, too (or Sun, IBM, ...); I don't want to say they're unimportant, that would of course be wrong, but is *this* the core of Gentoo? If you deliver, how you behave doesn't count? Scream all you like, if you attach a patch? Hey, let's make each others life hell, as long as we get releases out the door. Will that work? I doubt it. PMS, in a round-about way, helps with all three. Regards, Thomas (who is just a user, until last week was pondering to help out, until today advocated Gentoo, and who cares too much for it to stay quiet, even if he doubts anyone will read this mail the way it was meant to be) * Yes, people I ask and people i know. No, I don't have a statistic at hand. I can make one up if you want :-). ** Gentoo-Dev, where mails need a disclaimer, or someone *will* take it personal. -- gentoo-dev@gentoo.org mailing list
Re: Copyright, non-US devs and Gentoo Foundation vs Gentoo (Was: [gentoo-dev] Some council topics for March meeting)
Hi, Danny van Dyk schrieb: 2) There are countries who acutally adhere to the Berne Convention (1886). This means even the deed of commiting sources with a Copyright (C) Gentoo Foundation is useless in most countries of the EU. E.g, *none* of the stuff that I ever commited to Gentoo's repositories is copyrighted (solely) by the Gentoo Foundation, due to me being German citizen and writing that stuff in Germany. FYI, there isn't even something like Copyright in Germany. We have an Author's right which agree with the Berne Convention and deviates from copyright in several points. Except that you giving away copyright or donating to public domain is understood by (german) courts to give away usage rights, which is exactly what is intended, no? Regards, Thomas -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: EAPI spec (was Re: Re: let's clear things up (was Slacker archs))
Brian Harring schrieb: On Thu, Feb 22, 2007 at 04:13:11AM +, Ciaran McCreesh wrote: On Thu, 22 Feb 2007 04:04:37 + Steve Long [EMAIL PROTECTED] wrote: | I'm saying that until there is an independent implementation, the | specification is worthless and will contain huge numbers of errors. | | Seriously? Without an implementation, your spec of what should happen | will have loads of errors? Yes. It will describe what people think is allowed, rather than what really is. If you're writing the spec to match what people think, why limit the # of folks involved? Uhm, I think you completely inverted what Ciaran meant. Regards, Thomas (watching from the peanut gallery) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New network config for baselayout-ng
Daniel Robbins schrieb: Structured this way, fastlayout is certainly a project that sounds like a great idea, and would I enjoy working on in some capacity - I have some ideas about this. I also think it would be a good idea to check out what other distributions are doing in this area. Definitely. Other distributions/projects are quite active in this area, and the advantage Gentoo had in init scripts, namely named runlevels, real dependencies and parallel startup, are melting away. Ubuntu will soon have an init script system that actively can restart failed services, or react to system events like ACPI: system now on battery*. This isn't Roys itch (it may even be the complete opposite, though Ubuntu's system is reported to be way faster than what they had before), but I'd really encourage ppl to give the competition a long good look**. http://www.netsplit.com/blog/articles/2006/08/26/upstart-in-universe I like my Gentoo top-notch :) Regards, Thomas * I know, you can force ACPID into providing this right now, but they use it for more than that. Plus, with Gentoo you have to create a new runlevel to switch to, upstart can figure out what to do. ** I don't say, Adopt upstart now!. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New network config for baselayout-ng
Ciaran McCreesh schrieb: On Thu, 08 Feb 2007 09:20:17 -0500 Doug Goldstein [EMAIL PROTECTED] wrote: | Do *YOU* have anything useful to contribute to the discussion because | all I've seen is your useless FUD which countless times people have | said is not true. I can count to one. If you bothered to pay attention, you'll note that Roy *didn't* guarantee compatibility until late on in the discussion, and that he only started providing that guarantee because of what you're calling useless FUD. And I'm personally thankful that backwards compatibility is now guaranteed and it's actually bad that people have to raise a stink to get that promise. soprano gn=tonyIf you break my net config files (again), I'll scratch your itch for good./soprano Regards, Thomas, today's representitive of Evil Admins Group -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] eclass proposal - savedconfig.eclass
Daniel Black schrieb: Fellow devs, [...] Ebuilds that already have their implementation of savedconfig: sys-apps/busybox sys-libs/uclibc x11-wm/dwm x11-misc/dmenu Other potential candidates: net-misc/dropbear [2] app-emulation/mol app-shells/tcsh dev-libs/klibc dev-lang/ccc mail-mta/sendmail net-dialup/isdn4k-utils net-im/kadu net-irc/cyclone net-wireless/wpa_supplicant sys-boot/netboot sys-libs/uclibc++ www-apache/mod_* net-misc/asterisk net-misc/zaptel dev-lang/php sys-kernel/*? Or perhaps genkernel? Being able to build kernel images just like any other package in Gentoo would be nice. Regards, Thomas -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] Some sync control
Dan Meltzer wrote: see http://dev.gentoo.org/~antarus/projects/soc/glep-0052.txt and http://article.gmane.org/gmane.linux.gentoo.devel/42044/match= ...in which mercurial is only mentioned in passing. Apart from Gentoo choosing a new VCS I'd really be interested in how the tests went with Hg (if there were any). Regards, T. -- gentoo-dev@gentoo.org mailing list
