Re: [gentoo-dev] Project Sunrise resumed
On Thu, 2006-07-27 at 18:21 -0400, Stephen P. Becker wrote: Stefan Schweizer wrote: In last weeks council meeting [1] it was decided that the Sunrise project is no longer suspended. I can give a short overview of the current status of the overlay: - we currently have 154 ebuilds in 58 categories in the overlay not counting the ebuilds that got into portage and were removed again - we have 8 developers, 4 trusted committers who have taken the ebuild quiz and 26 users committing to the overlay The basic project concept of creating a social workspace has been reached. #gentoo-sunrise is an active IRC channel where users usually find help quickly and it also forms a friendly community. [1] http://www.gentoo.org/proj/en/council/meeting-logs/20060720-summary.txt http://www.gentoo.org/proj/en/council/meeting-logs/20060720.txt Eso since when did we have the discussion where you actually addressed all of the numerous concerns brought forth right before this project was initially suspended? Looking at the meeting log, the council even noted that the concerns had not been addressed, yet still voted to un-suspend anyway. WTF? I don't seem to remember this. I do though seem to remember that I noted that there was complaints, but died away after Mike asked to actually give some concrete feedback. -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Resignation (was: Project Sunrise resumed)
On Fri, 2006-07-28 at 12:02 +0200, Henrik Brix Andersen wrote: On Fri, Jul 28, 2006 at 11:35:24AM +0200, Martin Schlemmer wrote: Mike asked you repeatedly to voice your issues or concerns in relation to Project Sunrise, which you failed to reply to. How many times are we supposed to raise our concerns about a project whose founders already agreed to run their project as an unofficial project on non-gentoo infrastructure? Did you miss the logs from the devrel + sunrise meeting where genstef and jokey agreed to this? Apparently they changed their minds, as Mike did state (as well as genstef) in that thread. I simply had no idea the Gentoo Council even remotely considered taking Project Sunrise on as an official project. Err, I miss to comprehend above??? You saw the item on the meeting agenda, made vague complaints, but yet did not know about this? Also, I do not remember you even attending the meeting or asking to speak there, so this really seems a tad unreasonable or impulsive. Same as above - had I known that you guys actually intended to revert your own ruling from the previous meeting along with the consensus reached on the devrel + sunrise meeting I would have been there to raise my concerns. Ditto, same again as above. I cannot see how you can state you did not know about it when you did actually complain about re-evaluating it. No big deal, though. Best of luck to all of you, including the people behind Project Sunrise. Do not get me wrong, the little I worked with you was not unpleasant or anything, and I really have no need or want to see you go, but your reasoning just do not add up. Anyhow, good luck whichever way you choose to go. Regards, -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] seamonkey - nss vs nspr
On Tue, 2006-07-25 at 22:16 +0200, Enrico Weigelt wrote: * Martin Schlemmer [EMAIL PROTECTED] schrieb: snip build or unpack both nspr and nss and then look whats laying around there. the nss sourcetree contains the nsprpub tree. Yes, but we don't install it with the nss ebuild, as our build uses system nspr. I am sure you could check with upstream, but they will probably say its intended as nss needs nspr if I remember correctly. So the nspr subtree in nss is dead code (for gentoo) ? Then we better should remove it - just to be sure ;-) Uhm, so you want us to re-tarball it instead of just using the tarball from upstream? How about firefix, seamonkey, xulrunner (I think), thunderbird, sunbird, etc ? Should we re-tarball those as well? BTW: it seems both nspr and nss are not really standalone packages, but instead snippets from CVS which requires much manual interaction (which is done by the ebuild). IMHO it would be worth investing some time into making both nspr and nss standalone packages with clean pkg-config, etc. Although I dislike autotools for some reasons (ie. crosscompiling is very ugly) we could use it until something better is available Sure, but you are still missing the point that it comes so from upstream. You can take the effort, but it will need to be OK with upstream to really make it worth the effort, else it might become a high maintenance item. Anyhow, that is the whole issue with mozilla stuff in general - huge hunk of code that is not really modular, and have to be rebuild for a few to many projects. While I am all for getting the POS more modular (which we at least did for nspr and nss), you will need to get cooperation from upstream, as they used to give a rats ass about abi compatibility when I was more involved with it, and loads of time if you actually want to try and do it yourself (which is more than I have currently), plus even more courage, as currently it will need to be done for probably at least 6-12 projects (nss, nspr, suite, browser, mail, minimo, composer, calendar, xulrunner, macbrowser, standalone, maybe chat, etc). So if you have time, courage and the drive to do it, be my guess, but know that it will be a project of some months of work, if not years. (in fact I'm working on my build tool ...). Something Xorg-modular ;-) Many distros would benefit from that. Not sure how this relates at to us, but as they say, code speak louder than words. Regards, -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] seamonkey - nss vs nspr
On Mon, 2006-07-24 at 17:39 +0200, Enrico Weigelt wrote: Hi folks, while emerging seamonkey I've seen something strange on nspr and nss: these packages are both imported by seamonkey, but it seems that nss contains nspr. Do we have some duplicates here ? Can you elaborate (maybe with a log or something by what you mean exactly) ? -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] seamonkey - nss vs nspr
On Tue, 2006-07-25 at 12:46 +0200, Enrico Weigelt wrote: * Martin Schlemmer [EMAIL PROTECTED] schrieb: On Mon, 2006-07-24 at 17:39 +0200, Enrico Weigelt wrote: Hi folks, while emerging seamonkey I've seen something strange on nspr and nss: these packages are both imported by seamonkey, but it seems that nss contains nspr. Do we have some duplicates here ? Can you elaborate (maybe with a log or something by what you mean exactly) ? build or unpack both nspr and nss and then look whats laying around there. the nss sourcetree contains the nsprpub tree. Yes, but we don't install it with the nss ebuild, as our build uses system nspr. I am sure you could check with upstream, but they will probably say its intended as nss needs nspr if I remember correctly. -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Sat, 2006-07-08 at 08:20 +0200, Harald van Dijk wrote: On Fri, Jul 07, 2006 at 07:50:27PM -0400, Mike Frysinger wrote: On Friday 07 July 2006 19:04, Harald van Dijk wrote: the ssp/pie/htb patches have their own USE flags so separating them from USE=vanilla makes perfect sense ... I'm not disagreeing with that, but removing an older option is not just providing more choices. now you can do: gentoo patches + ssp gentoo patches + nossp vanilla + ssp vanilla + nossp gentoo patches + ssp gentoo patches + stub vanilla + ssp vanilla + stub whereas before you only had the option of: gentoo patches + ssp vanilla + nossp gentoo patches + ssp gentoo patches + stub vanilla like i said in my previous e-mail, forcing stubs onto people even when USE=vanilla *is by design* because i got tired of people who had no clue about the consequences throwing USE=vanilla into their USE in make.conf and then complaining when the lack of SSP broke things ... But I'm not asking for USE=vanilla to disable SSP completely, I'm only asking for USE=vanilla nossp to disable it. nossp is already explicitly documented as NOT FOR GENERAL USE, too. No offence, but you are being very unreasonable in this thread. The fact that you can get what you are after, even though its not entirely supported, should be enough for you, especially for the fact that you are not clueless. You should remember that somebody at the end of the day have to sacrifice time and effort to fix bugs, and especially with something as complex as gcc, the more variables, the more effort it is going to be. And as Mike is relatively the only person currently who seems to maintain gcc, it should be his prerogative to decided that he get too much spam without the stubs. And you should really know by now that being documented as NOT FOR GENERAL USE will still not stop more than enough users to waste his time in telling them not to disable SSP with vanilla if they don't know what they are doing. Gentoo's gcc with the vanilla flag isn't the official GCC. Most patches don't get appplied, but some do. Plus, gcc[vanilla] isn't a supported compiler in Gentoo. For the fact that we do not support vanilla gcc - I assume this is a gcc built by yourself - this truly is really unfair of you to expect it. The 'contract' we usually have with upstream, is that if we apply patches to their software, we will be the first tier in the support chain. Now you want to run gcc which was not modified by us to fix the known hangups in how we do things - or save us time for that matter, and you still want us to support it - or at least make life easier for us by not leaving gaping holes that cost us maintenance time? Am I the only one feeling that this is really selfish/absurd thinking since you have such an hackle in what we do, to not research, debug, and file thus your own bugs with http://gcc.gnu.org/bugzilla/ ? The alternative to this that you seem to ignore, is that you can start helping maintaining gcc (I am sure Mike will appreciate help with Halcy0n gone as well, and me not having that much time currently). And of course promising so long as the stubs do not get applied with nossp, that you will handle all breakage in that area. Although I do not know if its still really fair to expect Jakub et ell to sacrifice time to process the bugs, and get them to you if its related to something failing due to the missing stubs. -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Sat, 2006-07-08 at 13:51 +0200, Harald van Dijk wrote: On Sat, Jul 08, 2006 at 11:27:57AM +0200, Martin Schlemmer wrote: On Sat, 2006-07-08 at 08:20 +0200, Harald van Dijk wrote: On Fri, Jul 07, 2006 at 07:50:27PM -0400, Mike Frysinger wrote: On Friday 07 July 2006 19:04, Harald van Dijk wrote: like i said in my previous e-mail, forcing stubs onto people even when USE=vanilla *is by design* because i got tired of people who had no clue about the consequences throwing USE=vanilla into their USE in make.conf and then complaining when the lack of SSP broke things ... But I'm not asking for USE=vanilla to disable SSP completely, I'm only asking for USE=vanilla nossp to disable it. nossp is already explicitly documented as NOT FOR GENERAL USE, too. No offence, but you are being very unreasonable in this thread. The fact that you can get what you are after, even though its not entirely supported, should be enough for you, especially for the fact that you are not clueless. You should remember that somebody at the end of the day have to sacrifice time and effort to fix bugs, and especially with something as complex as gcc, the more variables, the more effort it is going to be. And as Mike is relatively the only person currently who seems to maintain gcc, it should be his prerogative to decided that he get too much spam without the stubs. Sorry, but how much mail he gets does not affect one bit which behaviour is better, it only helps understand why the lesser behaviour could be chosen by reasonable people anyway. (Regardless of which behaviour is the lesser one.) And I don't harass anyone about -- it's been a very long time since I even mentioned any problems like this, and if nothing is done after this thread dies, I'll likely be quiet about it for a long time again -- so please don't act like I do. Actually it does if it cuts back his time by a very large percentage so that he cannot do the other things he wants/needs to. I assume this was the case if he added that in the first place, and still refuse to change it. Gentoo's gcc with the vanilla flag isn't the official GCC. Most patches don't get appplied, but some do. Plus, gcc[vanilla] isn't a supported compiler in Gentoo. For the fact that we do not support vanilla gcc - I assume this is a gcc built by yourself - Actually, I meant gcc built with the vanilla flag here, as opposed to pure official GCC, which I already stated is unsupported earlier. Hmm, thought I might have had it a tad wrong. I still though do not understand what the whole fuss is about stubs for some 5 flags. (which is what you are left with with USE=vanilla nossp currently if my memory is correct). Maybe read down a bit before replying here. this truly is really unfair of you to expect it. The 'contract' we usually have with upstream, is that if we apply patches to their software, we will be the first tier in the support chain. Now you want to run gcc which was not modified by us to fix the known hangups in how we do things - or save us time for that matter, and you still want us to support it - or at least make life easier for us by not leaving gaping holes that cost us maintenance time? Differences between official GCC and Gentoo's GCC are 1) fixed bugs, and 2) added features. (Assuming no patches are broken.) I think it's reasonable to not rely on the existence of those added features. I think its reasonable to no force the feature on you, but add the stubs if it became a maintenance headache. I am pretty sure it was not toolchain who brought the whole situation about in the first place. You can however fix the tree to make sure it will fully build without those flags, and then talk to Mike again about removing them. I am sure he might be more willing if it will not steal his time again. You seem to think I think it's reasonable to not rely on bugs being fixed. No problem there, I don't. Not at all. I thought you think its reasonable to just keep loading work on other people - or possible did not see that that would have been the end result. More about this to the end. Besides, I said it's unfortunate that vanilla GCC (either one) is unsupported, not that it must be. My other problem, that vanilla GCC is different from Gentoo's GCC with the vanilla flag (plus maybe nossp/nopie/...), can be handled without requiring support for it from anyone. From the length of this email, and you not wanting to see the reasoning, or not having started to fix the tree so that your wish can be full filled, It rather sounded like you did demand it. Or this was at least the impression I got. Also once again I do not see what the big issue with the stubs is. You keep making a big issue out of it without giving concrete examples or serious issues it is causing. The problem was there before they were added, and not due
Re: [gentoo-dev] init.d problem
On Thu, 2006-07-06 at 18:18 -0400, Mike Frysinger wrote: On Thursday 06 July 2006 15:27, Albert Hopkins wrote: On Tue, 2006-07-04 at 18:58 -0400, Mike Frysinger wrote: On Tuesday 04 July 2006 18:43, Enrico Weigelt wrote: We should think about mechanisms to check if the service is actually running. This could also be used for frequently service checks and notification. there is no fool proof way to do this Has anyone considered daemontools? It does this kind of stuff very well. you're fixing the issue by replacing sysvinit/baselayout with daemontools some people may want to do that but really i dont see how that's generally relevant to this discussion There are wrapper scripts if you want to use daemontools with rc-scripts: sys-process/daemontools-scripts -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Fri, 2006-07-07 at 02:08 +0200, Diego 'Flameeyes' Pettenò wrote: On Friday 07 July 2006 01:54, Ciaran McCreesh wrote: | No, we never spent years telling them not to use your so-called | CFLAGS hacks that are rather a proper usage of what the compiler | gives you. Wrong. We did. Then you were wrong. I could have spent time explaining them when they make sense and why they don't in their usecases. If you did, well, then you really need to know better what you do because you seem to me pretty confused yourself, and I feel pity for you. Yes, we did. Were we wrong? Out of a purest point of view ... maybe. The problem was though that earlier gcc's was very bad at generating sse/sse2, and sometimes mmx code. Users being what they are though (ricers should say it all), they enabled every flag that sounded like it could make their old box two times faster. This included -msse, -msse2, etc. Which quite frankly produced bad code in many cases. So we told the users to not add any -m* flags, and let gcc do its job with the proper -march. So yeah, I can see that general use flags for cpu features might become more tedious with the many new modules of processors out there, but to say handle it by adding -msse, etc to CFLAGS, will surely if not on gcc4, but then on gcc3 systems just ask for trouble. And yes, I know you are saying that that is not exactly what you are proposing, but the users will see it as a clear passport to stick all those nice sounding flags just right back in, and then it will be too late to tell them its not proper thing to do when the bugs start flooding in. Anyway, I tried to give some history and some what ifs, but as I admitted many times in the past, I am no great writer. You had to be 'there' I guess, *shrug*. -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Fri, 2006-07-07 at 04:28 +0200, Diego 'Flameeyes' Pettenò wrote: On Friday 07 July 2006 03:15, Mike Frysinger wrote: x86_64 toolchain accepting 3dnow on a nocona arch? :) that isnt a cross-compile nor a different architecture This is the whole point of my solution. From what you discussed above, it sounds more like a problem due to short-sightedness on the amd64 team's part (no offence to amd64 team, just stating things as I see them) because they just enabled 3dnow for stuff that worked regardless. Stupid question though ... does the gcc test thingy list __3dNOW__ on nocona ? I would think that it does, as there is no -march=nocona (or whatever) yet. So now you want to instead of fixing the amd64 profiles to be more flexible, implement something that will give the green light to users on x86 to use flag combinations, especially on older gcc's that causes great pain for themselfs and developers ? Sure, nocona should have had CFLAGS=-march=k8 -mno-3dnow, but it would never have been an issue if the '3dnow' USE flag worked as expected on amd64 ;) Anyhow, just ranting - I understand the reasoning for doing it that way, but you should also see it from the x86 side where -msse could really mean a broken system, and maybe rethink your solution. -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Fri, 2006-07-07 at 05:31 -0700, Brian Harring wrote: On Fri, Jul 07, 2006 at 02:24:49PM +0200, Martin Schlemmer wrote: On Fri, 2006-07-07 at 02:08 +0200, Diego 'Flameeyes' Pettenò wrote: On Friday 07 July 2006 01:54, Ciaran McCreesh wrote: | No, we never spent years telling them not to use your so-called | CFLAGS hacks that are rather a proper usage of what the compiler | gives you. Wrong. We did. Then you were wrong. I could have spent time explaining them when they make sense and why they don't in their usecases. If you did, well, then you really need to know better what you do because you seem to me pretty confused yourself, and I feel pity for you. Yes, we did. Were we wrong? Out of a purest point of view ... maybe. The problem was though that earlier gcc's was very bad at generating sse/sse2, and sometimes mmx code. Users being what they are though (ricers should say it all), they enabled every flag that sounded like it could make their old box two times faster. This included -msse, -msse2, etc. Which quite frankly produced bad code in many cases. So we told the users to not add any -m* flags, and let gcc do its job with the proper -march. So yeah, I can see that general use flags for cpu features might become more tedious with the many new modules of processors out there, but to say handle it by adding -msse, etc to CFLAGS, will surely if not on gcc4, but then on gcc3 systems just ask for trouble. And yes, I know you are saying that that is not exactly what you are proposing, but the users will see it as a clear passport to stick all those nice sounding flags just right back in, and then it will be too late to tell them its not proper thing to do when the bugs start flooding in. Dumb question, but what really blocks them from doing that now for x86 (for example)? Yes, can't enable certain flags for non x86/x86_64 arches, but the con you're pointing at exists now for the most part. I thought it was obvious, but apparently I overrated my writing skills :/ Anyhow, because now we can say 'don't do that!', or just close the bug as INVALID. If not, you can still try it, but the user might say we told him to enable sse/whatever like that. Also, as Luca stated, USE=mmx/sse/sse2/etc means that you enable tailored mmx/sse/whatever code, that should be working fine, as it was not gcc doing some shot in the dark at optimising, where if its enveloped with the CFLAGS, you cannot disable broken gcc optimisations, but enabled mmx/sse/whatever that should work on those older gcc's. -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Fri, 2006-07-07 at 16:03 +0200, Diego 'Flameeyes' Pettenò wrote: On Friday 07 July 2006 15:53, Martin Schlemmer wrote: Check Chris Gianelloni's mail just now. For some compilers with some -march's on x86 it did not explicitly turn on some features (or maybe not to such a high extend). Uh no, I think he meant that for some borderline processors there's not a -march value, like for Athlon64 Revision D, that has sse3 support. In those cases you have to use -msse3 or whatever else to tell the compiler what to generate. So where say CFLAGS=-march=pentium3 would work, CFLAGS=-march=pentium3 -msse would fail to build, or generate bad code (segfaulting binaries). This might have been true with _older_ GCC, but all the series 3.3, 3.4, 4.0 and 4.1 behaves correctly: -march=pentium3 implies -msse without doubt. What you might incorrectly remember is -mfpmath=sse that is totally another thing, and dies usually on bad code anyway, and it's enabled by default on 64-bit CPUs just because on there the 80-bit limit for doubles is not pertinent anymore. As I pointed out on irc (to clarify), its still an issue even with gcc-3.4.6. Its just well enough filtered, and as Mike pointed out, they 'fixed' it in 3.4.5 via specs, and 3.4.6 by backporting patches from 4.0.1 I think. I might seem an idiot, but I have enough experience to know what I'm talking about. Seems instead that other people confuse SEGFAULT with SIGILL and -msse with -mfpmath=sse (or simply remember just what happened with GCC 3.2). I did not imply this as far I know, and if it seemed that way, I can only say that I assumed that newer guys had the advantage of most ebuilds filtering or -mno-sse/whatever for known broken stuff (I know xorg was one with a few workarounds, also mozilla, etc at at some stage), so would not have noticed if sse/whatever broke something. That, and not being on the toolchain list you might not be familiar with the extend of the issue, with the fact that its different issues with different versions depending besides that on if its a i586, k6, p2, p3 or p4, etc. A little note here: tools improve. GCC 2.95 was a joke, GCC 3.0, 3.1 were almost unusable, 3.2 started to be usable but full of problems, 3.3/3.4 series improved, drastically. Stuff like visibility is badly broken up to 4.0, but works fine on 4.1. You cannot think that a flag or a support will always be broken because a release had it broken, you have to watch what you're doing to do it correctly. I'd say only 4.0.1 and upwards really solved most of those issues, especially the long comming sse one. -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles
On Fri, 2006-07-07 at 17:46 +0200, Kevin F. Quinn wrote: On Fri, 7 Jul 2006 16:20:08 +0200 Danny van Dyk [EMAIL PROTECTED] wrote: Diego's proposal essentially generates CPU_SUBMODEL automatically from CFLAGS - which could be the default behaviour if CPU_SUBMODEL is not set. That way we have the best of both worlds; people who are happy to let the system determine the configure options from the compiler architecture can do so, those who want to control things in more detail can do that as well. I snipped your proposal, which I will reread better later on, but sounds not too bad if the glimpse was true. The big issue with Diego's proposal though that most of us for x86 have issues, is that you tie configure time optimisations that in theory should be good with most compilers, with gcc's potshots that may or may not be good. Sure, you might get away with it these days, because either bad stuff are filtered, or patched away, but it really is essentially not the same thing. I might for example with gcc-4.1.1 rather want gcc to do all optimization, as it does a better job than the coders do, but with 3.4.6 gcc that sucks at sse2 (ok, apparently this should be fixed with patches Mike backported, but still), I want what the developer coded mmx/sse code. The other side of it as well, is for new cpu's you might have to disable custom configure enabled mmx/sse/etc in general, as they break with the code (think when p4 was released). Sure, maybe adding auto detecting for USE=mmx sse sse2 etc if they are not -mmx/-sse/etc can be a cool feature, but that is totally different. Hopefully that was clear - if not, point out what I should try to elaborate on. -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] SpanKY's Nominations for the Gentoo Council 2007
On Tue, 2006-07-04 at 15:04 -0400, Mike Frysinger wrote: On Saturday 01 July 2006 02:46, Mike Frysinger wrote: well it's about that time of the year ... time for nominating people for the next Gentoo Council i guess i'll start off some mass nominations of random people off the top of my head who i think would do a good job ... there's a bunch more people i think would do a good job, but i'm going to cut my list short as it's already ridiculously long ... from current council: koon / agriffis / azarah / seemant / solar some other peeps: Kugelfang / Ramereth / Mr_Bones / spb / plasmaroo / Weeve / `Kumba / jaervosz / KingTaco / Flameeyes / dostrow / dsd / kito / exg i'd also nominate g2boojum, but i kind of like his current unofficial role as honorary council adviser guy ... I would like to refrain from accepting until just before the final nominees are put out, as currently my life is pretty much in flux. If possible that is. -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] SIGTERM vs SIGINT
On Wed, 2006-04-05 at 00:13 +0100, Stuart Herbert wrote: On Tue, 2006-04-04 at 22:35 +0100, Roy Marples wrote: As more and more init scripts stopping can trigger other services to restart, it becomes very desirable for this not to happen. So I propose for the next baselayout release (1.12.0_pre17) to default start-stop-daemon calls to SIGINT for stop commands instead of the current SIGTERM. My testing on my boxes has no adverse effects so far. So .. thoughts? Good or bad idea? Reasons and explanations welcome :) From a standards point of view, SIGINT is strictly meant to be an interupt from the keyboard, and SIGTERM is there to notify the process that it should stop. I'm uneasy about going against accepted, standardised, and decades-old UNIX behaviour at this level. Why are bind et al getting into the state that they do? If you attach a debugger to the running processes, what state are they in? Why does stopping dhcpd using SIGINT et al prevent that? What is dhcpd doing in its signal handler? That seems to be the real issue that needs investigating and fixing. I feel that changing the behaviour of start-stop-daemon is masking the symptom, rather than fixing the bug. I would have to agree - it sounds more like dhcpcd is doing something bad when it receives stop and runs resolvconf. So rather figure out what it does wrong, and if really critical, at least just make its SSD call use SIGINT and not SIGTERM then doing it tree wide - until you figured out what is wrong that is. -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Eclass subdirectory for x-modular.eclass
On Fri, 2005-12-09 at 12:13 -0700, Joshua Baergen wrote:
In an attempt to patch all driver packages automatically, I've modified
x-modular.eclass to do something along the lines of what elibtoolize
does for its patching. However, this would require the storage of a
patch for x-modular.eclass, which I would intend to place in a
subdirectory of eclass (my current choice is x-modular-files).
Am I allowed to create this subdirectory, or does this break
policy/anything else I'm unaware of?
The only reason elibtoolize use this abortion from hell, is because it
needs to be working from day one.
Use ${P}-patches-{PVER}.tar.bz2, and set PVER (or whatever) before
inheriting the eclass.
--
Martin Schlemmer
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Proposed changes to base profile for Gentoo/ALT
On Wed, 2005-11-02 at 16:36 +, Mike Frysinger wrote: On Wed, Nov 02, 2005 at 11:12:43AM -0500, solar wrote: On Wed, 2005-11-02 at 14:38 +, Mike Frysinger wrote: On Wed, Nov 02, 2005 at 01:11:24PM +0100, Diego 'Flameeyes' Petten? wrote: Obviously if this is going to be applied the missing packages should be added to the packages of default-linux and other linux profiles that does inherit from base. linux-based profiles should inherit default-linux rather than base anyways ... Thats a lot easier said than done and I'd rather us not inherit from default-linux for the uclibc i dont think it'd be a problem for use with uclibc ... we'd just need to drop pwdb and hdparm from our packages ... btw, why is pwdb in our system ? `scanelf -lpq -N libpwdb.so.0` on my system shows no hits ... is it a pam thing ? I am fairly sure that its legacy from the days we used pam_pwdb as main auth, so we can remove it. -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Improved ebuild information
On Sat, 2005-10-01 at 21:22 +0100, Ciaran McCreesh wrote: On Sat, 01 Oct 2005 22:19:39 +0200 Daniel Stiefelmaier [EMAIL PROTECTED] wrote: | I'd like to have a functionality that prints out what the useflags of | a ebuild are good for. Some are obvious, others are not. Example: | The useflag xprint sounds like printing support, but doesn't tell | if you need it if you use cups or the kde-printing system or... | whatever. We've discussed adding this to metadata.xml a few times in the past, but every time there was opposition from a vocal minority of one who claimed that USE flags should always do exactly the same thing for every package. I guess I am one of this 'minority'. The question I just want to have answered, is how the hell are you going to get a system up sanely (and without tweaking /etc/portage/package.use) if besides the 350 global USE flags, and the 1200 local USE flags, you now have to worry about global USE flags meaning different things for every package? As for the 'xprint' USE flags ... I guess the description is deceptive .. its support for X11's printing system (or should be). 'cups' is for cups support, etc. -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] deprecation of SANDBOX_DISABLED
On Wed, 2005-09-28 at 03:05 -0500, Brian Harring wrote: Hola. Subject says it all; SANDBOX_DISABLED functions as (essentially) RESTRICT=sandbox, except sandbox is left on for pkg_setup . This is pretty much redundant, considering it's usage. People stick it in the global scope; if you _must_ turn off the sandbox for a specific phase, use SANDBOX_ON=0/1 instead. If you need to disable sandbox across the board, restrict=sandbox is your friend. Since there are still ebuilds in the tree that would be schmooked by it, it's not going to hit in the coming version, but I'd expect it to be dead next version after unless people have a really good reason why it should live on. So... thoughts? Yes it's minor, but it's a matter of cleaning up/simplifying portage code, and removing redundancy. Sounds sane. -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] default logger
On Tue, 2005-09-27 at 13:05 -0500, Brian Harring wrote: On Tue, Sep 27, 2005 at 01:47:49PM -0400, Mike Frysinger wrote: On Tuesday 27 September 2005 01:29 pm, Chris Gianelloni wrote: On Tue, 2005-09-27 at 11:57 -0500, Brian Harring wrote: I'd rather see reasons listed as to why syslog-ng is a superior default for users who (most likely) don't care, then we lack /var/log/messages :) Besides the /var/log/messages thing, which I think is a non-argument, there is syslog-ng's ability to be usable by anyone. It works great for servers, it works great for desktops. It works as a loghost. It works for remote logging. Essentially, it has all of the features that users would want. It also has all of the features that administrators would want. It is flexible and powerful. how exactly is this an argument for syslog ? metalog has all these features (and more) except for remote logging ... Additionally, metalog (afaik) won't be depending on glib, like =syslog-ng 1.9. Keep in mind I'm talking only defaults here (iow, use whatever is best for your needs). Re: it being a temporary change that should be undone, it's been around long enough I won't call it 'temporary' at this point. Merits vs well, we recommend/did this a while back and were going to reverse it mainly. How about we just use sysklogd ? It does not depend on glib or any other package that would not be pulled in by default in system profile. It have a sane config. It logs to /var/log/message, etc. It supports network logging. Blah, blah ;p -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] C++ herd proposal
On Tue, 2005-09-20 at 08:54 +0200, Kevin F. Quinn wrote: On 20/9/2005 7:37:19, Georgi Georgiev ([EMAIL PROTECTED]) wrote: maillog: 20/09/2005-07:21:08(+0200): Christian Parpart types On Monday 19 September 2005 15:22, warnera6 wrote: Mark Loeser wrote: Paul de Vrieze wrote: I think that dev-util is a very specific category containing development utilities of some sort. There might be some misclassifications in them, but from a user perspective I don't really care about the language anything is written in. As C++ is so widespread I don't think that anything but app-misc or the like should be moved into a dev-cpp category. This isn't for what the package is written in, but more for what the package is for. If the package is a utility for use when doing coding with C++, like the ones I listed, then I think it should be in dev-cpp. That's what the metadata for the category describes it to be. Mark Once again I'd like to point out that organizing packages in the tree by category is a stupid idea for this very reason. and what's *your* certain proposal then? That's been discussed a number of times already. The best idea is to leave the categories alone and forget that the category means anything. Or, to throw the ball back in your court, could *you* suggest alternatives that accomplish the following: (quoting [1]:) More precisely, what I'd like to see, in order of preference, is - that package in my overlay that has net-wireless/gnome-phone-manager in its *DEPENDs to work for as long as needed - the net-wireless/gnome-phone-manager that I have in my overlay to work for as long as needed - my net-wireless/gnome-phone-manager binary packages to work without having to be fixpackaged - the location of the ebuilds for net-wireless/gnome-phone-manager to stay in the same physical path on my filesystem end quote I would grade the above features as vital, badly needed, happy to see it done, cosmetic. I.e., even solving only the first one is enough, though if you could get to number two it would be better. Here's another requirement I'd like to add to the list: - when moving stuff around, change history moves too CVS doesn't support this, but subversion does (along with atomic commits, also useful to ensure integrity of the tree during a move). The support for symlinks in subversion may also provide a way to resolve the overlay problem... Technically it does support it if said developer gets Infra to move it server side some nasty side effects, etc, but lots better than our current situation where some bright spark removed most if not all history of stuff that was moved :/ -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] Portability eclass
On Fri, 2005-09-16 at 17:42 +0200, Diego 'Flameeyes' Pettenò wrote:
If nobody finds problem in the attached eclass, I'm going to commit this
tonight or tomorrow.
The first function is a drop-in replacement for cp --parent (that doesn't
work
on BSD userland), the second one is a commodity function to symlink commands
and manpages at once (as done by bsdtar and other packages).
If we'll find other functions needed for portability's sake, they'll probably
going to be there, too.
I do not think its so urgent? Either way, we have elibs approved now,
so how about waiting a while so that we do not have yet another elib
candidate to port?
Also, treecopy() will break if I do:
treecopy ${S}/data ${D}/usr/share/foodata
--
Martin Schlemmer
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] first council meeting
On Fri, 2005-09-16 at 19:42 +0200, Paul de Vrieze wrote: On Friday 16 September 2005 00:20, Mike Frysinger wrote: actually this is came up in the meeting as something we would like to see spelled out explicitly ... either as a GLEP itself or as a policy update to current stabilization practices the GLEP was approved on the grounds that we need an x86 team and that it needs to be treated as any other arch ... arch team interaction with maintainers should be spelled out clearly rather than part of a single sentence '... or make individual arrangements with the x86 arch team.' Ok, I do think that we will need a way for the maintainer to indicate that the package is stable. I'd be happy to leave stabilizing out of my hands, but I wouldn't want my packages to be stabilized before I deem it stable. File a bug if the arches (or main ones at least) haven't picked it up yet? Will make the problem of missing some or other keyword minimal (especially for some obscure package not often used). -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] first council meeting
On Fri, 2005-09-16 at 16:59 -0400, Mike Frysinger wrote: On Friday 16 September 2005 04:44 pm, Ciaran McCreesh wrote: On Fri, 16 Sep 2005 16:33:13 -0400 Mike Frysinger [EMAIL PROTECTED] wrote: | ok, e17 packages dont count here. however, your hardcore view i | still dont buy. how about the baselayout-1.9.x - baselayout-1.11.x | stabilization process ? are you telling me that arch teams should | have had the power to move those into stable without talking to the | maintainer ? baselayout may be a core package, but if you continue | with your hard rule here, then it doesnt matter. I'm saying that arch teams should be allowed to mark it stable if they think it's appropriate. Not that it must be moved to stable after $x days, but that it can be at the arch team's discretion. And any arch team which is silly enough to mark a broken baselayout stable has far bigger problems anyway... baselayout is an example, any package can be used here (although not many are as critical) i'm saying that the maintainer may have a certain idea of when the package is ready for stable (a target feature set, working out certain quirks, etc...). your current hard view does not allow for that. for example, i had an arch maintainer one time mark bash-3 stable before base-system was ready for it (readline, baselayout, etc... were going to be stabilized together). i smacked them hard for it, but if we went with this hard view, it would have been perfectly acceptable behavior. We still have KEYWORDS=-*. Sure, I know many do not like it, and if something was decided in regards to it, I missed it, but it is generally seen as 'less severe' than a package.mask'd mask, and its local to the package, so should not get stale. -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] GNOME 2.12.0 Final - Testing
On Wed, 2005-09-14 at 03:29 +, John N. Laliberte wrote: Hello all, The GNOME herd is now ready for 2.12.0 to be tested. The gnome-2.12.0.ebuild should hit the mirrors shortly. ( just committed) Please see this document for information on how to test: http://dev.gentoo.org/~allanonjl/gnome/2.12.0/testing.instructions.txt Hmm, I still have these as outdated: ? app-text/gnome-doc-utils/gnome-doc-utils-0.4.0.ebuild ? dev-cpp/gconfmm/gconfmm-2.12.0.ebuild ? dev-cpp/gnome-vfsmm/gnome-vfsmm-2.12.0.ebuild ? dev-cpp/libglademm/libglademm-2.6.1.ebuild ? dev-cpp/libgnomecanvasmm/libgnomecanvasmm-2.12.0.ebuild ? dev-cpp/libgnomemm/libgnomemm-2.12.0.ebuild ? dev-cpp/libgnomeuimm/libgnomeuimm-2.12.0.ebuild ? dev-libs/libxml2/libxml2-2.6.22.ebuild ? gnome-base/libgnome/libgnome-2.12.0.ebuild ? gnome-base/orbit/orbit-2.13.1.ebuild ? gnome-extra/gucharmap/gucharmap-1.4.4.ebuild ? sys-apps/dbus/dbus-0.50.ebuild Or am I too quick ? :D -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] FAQs for maintainer-wanted ebuilds
On Sun, 2005-09-11 at 22:41 +0100, Ciaran McCreesh wrote: I've put together a kind of FAQ for the most common maintainer-wanted problems: http://dev.gentoo.org/~ciaranm/docs/mw-faq/ The idea is to replace most of my usual bullet points in the please fix list with URLs with more complete explanations. Any additions or suggestions for changes would be appreciated. Please do not GuideXMLify this unless you first make XML not suck. I like my nice sane memorisable consistent URLs and quickly updateable content. Looks good .. any chance you can stitch it up in a guide, and we can get it added somewhere ? -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Why autoconf in system?
On Mon, 2005-09-12 at 14:26 +0200, Frank Schafer wrote:
Hi,
we meet often the (faulty) notion that autoconf/automake (even a couple
of versions on gentoo) is a dependency for packages.
This is true only for development of these packages itself.
Autoconf/automake provides tools to GENERATE configure scripts. Both are
totally unnecessary to build a package or run the programs it provides.
I've built a full featured LFS system not long ago without even
autoconf/automake installed.
I'd suggest to remove the build of autoconf/automake from ``emerge
system''. I'd leave all of the autoconf/automake versions in portage
tough for the case someone wants to involve in development of some
package.
While this is true, you missed the fact that many packages from time to
time apply patches that touches configure.{ac,in}, or Makefile.am, or
just do not come tarballed with configure, etc generated, so it is
indeed needed.
--
Martin Schlemmer
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Why autoconf in system?
On Mon, 2005-09-12 at 10:38 -0400, Mike Frysinger wrote: On Monday 12 September 2005 08:58 am, Stephen P. Becker wrote: Hi, as I mentioned, I built LFS without this (and I have coreutils on it ;) Not at all - if we need to modify or create configure files during build as Paul and Martin said ... we need autoconf/automake And furthermore, many programs (or upstream authors if you prefer) are braindead and don't know what some non-x86 arches are without updating the config.sub/config.guess, and re-running autoconf/automake. those two files dont require re-running autoconf/automake it isnt uncommon though to have upstream run autotools in the wrong order and package the result as their release ... then when you run `./configure make`, the build system has mismatched timestamps and thus tries to invoke autotools to fix itself :/ Toss in libtool in the mess, and it runs aclocal, autoconf and then automake, and you end up with a mismatched ltmain.sh and whatever macro's of libtool expanded in configure, causing either breakage (random or not), or in our case an error informing about the mismatch :/ -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] GLEP 41: Making Arch Testers official Gentoo Staff
On Mon, 2005-09-12 at 20:50 +0100, Ciaran McCreesh wrote: On Mon, 12 Sep 2005 21:39:48 +0200 Simon Stelling [EMAIL PROTECTED] wrote: | This has been in the todo-list for quite a while, but finally it's | done. I'm curious what you think of it. Could we get some numbers? How many arch testers have gone to become official developers? How many have disappeared without trace? How many stuck around but didn't do much? Valid point ... maybe a probation period before the provisions of this glep kicks in if the numbers are acceptable? -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] GLEP 41: Making Arch Testers official Gentoo Staff
On Mon, 2005-09-12 at 18:47 -0400, Stephen P. Becker wrote: Chris White wrote: Alright, so here's what I think on the whole thing now that I made a nice tidy [Summary] thread. There seems to be some concern about AT testers having more privileges than some other devs. First off, I hope everyone saw the readonly access, and even so, the whole point of this thing is to make development smoother. Let me clarify here. I'm not concerned about ATs having more privileges at all. I just want to know why if we're making them full developers for all intents and purposes, we don't go the extra step and get them commit access after a probationary period? It seems like this is supposed to be the end goal anyway. Basically, I feel like this GLEP goes outside the bounds of what I think of when somebody mentions the arch testers. Maybe it's just me though. Maybe the email address is not such an issue, but it does seem fair to people taking time and commitment as a 'kind' of reward .. after of course the probation period. Sort of off the topic, but wanted to clarify. Why I did though say that read-only access to CVS do make sense for AT testers, is that while they will not be actually fixing bugs (OK, so they can make patches, etc), they will though need to test stuff, and especially if its an important or urgent fix, not needing to wait for the rsync mirrors will be a plus for them. -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] MySQL 4.0 = 4.1 upgrade
On Sat, 2005-09-10 at 20:03 +0200, Francesco R wrote:
Maurice van der Pot wrote:
Is this path going to be published somewhere or is this mail it?
Not from me atm, I feel very bad at writing anglish documentation. An
eventual reader sure feel worst.
On Thu, Sep 08, 2005 at 01:08:06PM +0200, Francesco R wrote:
cmd# ebuild /var/db/pkg/dev-db/mysql-4.1.14/mysql-4.1.14.ebuild config
This asks for a password, but not all passwords can be entered.
Specifically one with a ` in it fails =]
Also, when it outputs:
Check the password
it is asking you to enter the password again. I wasn't sure how to
interpret this, because the password was shown on the screen so it might
have been asking me to verify it and type ok or something.
It's a mixture, I've received a suggestion in bugzilla on howto hide the
password, but need to be tested on all platform before.
Just use bash's built-in read function:
-
local password newpasswd
# Read the password into $password
read -sp Please enter password: password
# Just echo a newline so that next output start on new line
echo
# Confirm password into $newpassword
read -sp Please re-enter password: newpassword
echo
# Verify that the passwords match
if [[ ${password} != ${newpassword} ]] ; then
eerror Passwords did not match!
die Passwords did not match!
fi
-
Or something to that regards.
--
Martin Schlemmer
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] tentative x86 arch team glep
On Tue, 2005-09-06 at 20:47 +0100, Ciaran McCreesh wrote: On Tue, 06 Sep 2005 12:35:31 -0700 Donnie Berkholz [EMAIL PROTECTED] wrote: | Chris Gianelloni wrote: | You'd have a really long list of maintenance architectures for me. | Like I said, I don't use a single machine. The idea of *any* | architecture being my primary one just doesn't really fit. | There's also the simple fact that it doesn't matter *at all* what | the maintainer runs it on, only whether or not (s)he considers it | stable. | | There have been many cases where I've considered a package stable on | one architecture but not on another. How would I indicate this? This would be one of the cases where a maintainer / stable keyword would be inappropriate. I suspect there are a lot more of these than some people think... We already have: arch - in theory stable ~arch - in theory should work, but needs testing -arch - do not work at all What about !arch or something (to connect with the one reply to the summary thread) to really indicate unstable on that arch? Should cover those things that sorda work on the arch, but you rather want developers or experienced users that can patch bugs to look at it ... Sure it will still leave some holes, but will be a bit more flexible than a single maintainer keyword. -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] tentative x86 arch team glep
On Tue, 2005-09-06 at 22:31 +0100, Ciaran McCreesh wrote: On Tue, 06 Sep 2005 23:19:43 +0200 Martin Schlemmer [EMAIL PROTECTED] wrote: | What about !arch or something (to connect with the one reply to the | summary thread) to really indicate unstable on that arch? Should | cover those things that sorda work on the arch, but you rather want | developers or experienced users that can patch bugs to look at it ... Those go in per-profile package.masks. It's more flexible than a keyword. I would have said a keyword is more flexible (and less work) than package.masks, but I do not put that much value in the idea - was more just to have something more to kick around. -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] combining x86 and amd64
On Thu, 2005-09-01 at 14:36 -0400, Olivier Crete wrote: On Thu, 2005-01-09 at 19:02 +0100, Ciaran McCreesh wrote: On Thu, 1 Sep 2005 19:50:11 +0200 Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote: | On Thursday 01 September 2005 19:41, Ciaran McCreesh wrote: | Untrue. | | Can I have reasoning? Take a look at how sparc and mips currently handle packages which will run on some CPU kinds or ABIs but not others. Is it just me, it seems that only sparc/mips devs want that kind of change and non none of the x86/amd64 devs... No, Yes, and Yes. I still dont see what practical advantage that would bring to x86/amd64 users or developers? Well, I guess the theory might be because then you only have one keyword and one base profile to manage - I think. --- From a quick diff, it looks like they are handled via the ABI and PROFILE_ARCH stuff, but what your average sparc/mips dev do not realise, is that most x86 devs, and probably many amd64 devs have no idea what and how the ABI stuff is used. Mostly the ABI stuff was hacked by (and still is mostly if I'm not mistaken) by Jeremy, and they mostly just use ARCH or use to apply x86/amd64 patches. So your basic problem is that: 1) They have no idea how sparc/mips does it 2) They do not see any benefits 3) They get even more confused by the half assed answers they get. So to be frank, I propose that either the alt-arch devs start explaining above instead of half-assed answers and senseless ranting, or shut up. From the amount of _usefull_ comments they have given, it does not look like its really an issue or priority for them besides having some fun. Thanks, -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] combining x86 and amd64
On Thu, 2005-09-01 at 19:42 +0100, Ciaran McCreesh wrote: On Thu, 01 Sep 2005 14:36:44 -0400 Olivier Crete [EMAIL PROTECTED] wrote: | Is it just me, it seems that only sparc/mips devs want that kind of | change and non none of the x86/amd64 devs... The people who have worked with such a system before and understand how it works and what all it can do want change. Those who don't understand the system and think that it has all kinds of problems that are really just a lack of understanding don't want it to change. Maybe, but please give one example of such an 'explanation' that any of the pro-merge devs have given. | I still dont see what practical advantage that would bring to | x86/amd64 users or developers? QA. Possible, but once again, why will a merge give 'better' QA ? -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] combining x86 and amd64
On Thu, 2005-09-01 at 21:14 +0100, Ian Leitch wrote: I think myself and tester are the only members who can be considered active at the moment. I'm happy with creating an arch team, though I don't think we'll end up with an abundance of members (x86 is far from the most popular arch among devs). Yeah, I added myself not too long back, but I still need to get my P4 up and running .. should be in the next week or two. Chris Gianelloni wrote: So would just making an x86 arch team. It would also be much less of a problem than merging x86 and amd64. How about this? I proclaim and x86 arch team now exists. It already has a security liason. $ cat /var/mail/alias/arch/x86 avenj solar tester port001 azarah -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: init.d-scripts don't see stuff from /etc/profile.env
On Tue, 2005-08-30 at 22:21 -0400, Mike Frysinger wrote: On Tuesday 30 August 2005 10:15 pm, Martin Schlemmer wrote: On Tue, 2005-08-30 at 21:57 -0400, Mike Frysinger wrote: On Tuesday 30 August 2005 09:41 pm, Sven Köhler wrote: init.d scripts should have a pure env given to them ... which means, they should be run with `env -i` and have only whitelisted variables given to them (and everything that appears in /etc/conf.d/$service /etc/conf.d/rc and /etc/rc.conf) ... Now that may be too few variables. At least the variable LANG (or whatever the system-admin may chose to set) could be seen as a system-wide language-setting. It could be intentional, that at least some variables are available to the started server-processes. Especially a system-wide language-setting would be a good idea. that is the point of the whitelist idea ... we gather a 'full env' (source /etc/profile i guess) and rip out just the whitelisted variables to pass on to init scripts Although I agree, my personal opinion is that its going to be a major PITA to maintain, and slow things down. with the first run, we cache the 'scrubbed' env, and then just use that in the future ? We both know when somebody finally notice that, they will bitch because the environment is not updated :) Damn, did I just point that out ? 8) Also, not only runscript.sh will have to be 'whitelisted', but also /sbin/rc, which will mean that we now have to wrap two things. I guess a solution could have been to use /sbin/runscript (the C thing) for both (should work fine as /sbin/rc's interpreter as well), as that would buy some speed and kill one bash fork, but the problem comes in when we start with a vanilla environment that do not have /etc/profile sourced. mmm unification is good :) I did not argue .. was just wondering how much gain (tears?) it will bring us :) -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: init.d-scripts don't see stuff from /etc/profile.env
On Tue, 2005-08-30 at 21:57 -0400, Mike Frysinger wrote: On Tuesday 30 August 2005 09:41 pm, Sven Köhler wrote: init.d scripts should have a pure env given to them ... which means, they should be run with `env -i` and have only whitelisted variables given to them (and everything that appears in /etc/conf.d/$service /etc/conf.d/rc and /etc/rc.conf) ... Now that may be too few variables. At least the variable LANG (or whatever the system-admin may chose to set) could be seen as a system-wide language-setting. It could be intentional, that at least some variables are available to the started server-processes. Especially a system-wide language-setting would be a good idea. that is the point of the whitelist idea ... we gather a 'full env' (source /etc/profile i guess) and rip out just the whitelisted variables to pass on to init scripts Although I agree, my personal opinion is that its going to be a major PITA to maintain, and slow things down. Also, not only runscript.sh will have to be 'whitelisted', but also /sbin/rc, which will mean that we now have to wrap two things. I guess a solution could have been to use /sbin/runscript (the C thing) for both (should work fine as /sbin/rc's interpreter as well), as that would buy some speed and kill one bash fork, but the problem comes in when we start with a vanilla environment that do not have /etc/profile sourced. (I guess we could do a function that just unset anything not in the whitelist via a for loop that we call top of /sbin/rc and runscript.sh, but bash for loops is kinda slow anyhow ...) -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] autotools support eclass
On Sun, 2005-08-28 at 01:59 -0400, Mike Frysinger wrote: On Saturday 27 August 2005 03:38 pm, Martin Schlemmer wrote: On Sat, 2005-08-27 at 15:11 -0400, Mike Frysinger wrote: On Saturday 27 August 2005 02:58 pm, Martin Schlemmer wrote: Which reminds me .. anybody going to scream if I update elibtoolize() to be able to check if it was already run, and then bug the portage guys to also add it to econf() ? do what now ? Make econf handle elibtoolize the same way it does gnuconfig ... why ? this would help us embedded peeps with uclibctoolize, but other than that ... maybe i just havent really sat down to figure out what elibtoolize does ... Because it applies the portage/relink/whatever patches to ltmain.sh without the need for real libtoolize and the pains that comes with it and a autoreconf (due to missing macro's, broken build system, etc). Note ... I really don`t think uclibctoolize and the other stuff that was added is really appropriate in libtool.eclass, as they touch config.guess, etc .. maybe it would have been better to update gnuconfig to try and apply the patch if in uclibc profile? -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] autotools support eclass
On Sun, 2005-08-28 at 12:50 -0400, Mike Frysinger wrote: On Sunday 28 August 2005 07:28 am, Martin Schlemmer wrote: On Sun, 2005-08-28 at 01:59 -0400, Mike Frysinger wrote: On Saturday 27 August 2005 03:38 pm, Martin Schlemmer wrote: On Sat, 2005-08-27 at 15:11 -0400, Mike Frysinger wrote: On Saturday 27 August 2005 02:58 pm, Martin Schlemmer wrote: Which reminds me .. anybody going to scream if I update elibtoolize() to be able to check if it was already run, and then bug the portage guys to also add it to econf() ? do what now ? Make econf handle elibtoolize the same way it does gnuconfig ... why ? this would help us embedded peeps with uclibctoolize, but other than that ... maybe i just havent really sat down to figure out what elibtoolize does ... Because it applies the portage/relink/whatever patches to ltmain.sh without the need for real libtoolize and the pains that comes with it and a autoreconf (due to missing macro's, broken build system, etc). i guess if we can clean up the output to not complain when none of the patches are needed ... Yeah, that is the plan. Note ... I really don`t think uclibctoolize and the other stuff that was added is really appropriate in libtool.eclass, as they touch config.guess, etc .. maybe it would have been better to update gnuconfig to try and apply the patch if in uclibc profile? uhh, uclibctoolize doesnt touch config.guess ... it only touches ltconfig/configure because libtool does not know about uClibc and thus will often disable shared library support when trying to build on a uClibc host Urk, my fault .. maybe its the macosx stuff then. Either way, how about integrating them rather with the default way elibtoolize() work? If you guys are game, I can do it so that the old still will work, and we can then drop the call to it and elibtoolize once its integrated into econf(). -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] autotools support eclass
On Sun, 2005-08-28 at 13:54 -0400, Mike Frysinger wrote: On Sunday 28 August 2005 01:43 pm, Martin Schlemmer wrote: On Sun, 2005-08-28 at 12:50 -0400, Mike Frysinger wrote: On Sunday 28 August 2005 07:28 am, Martin Schlemmer wrote: On Sun, 2005-08-28 at 01:59 -0400, Mike Frysinger wrote: On Saturday 27 August 2005 03:38 pm, Martin Schlemmer wrote: On Sat, 2005-08-27 at 15:11 -0400, Mike Frysinger wrote: On Saturday 27 August 2005 02:58 pm, Martin Schlemmer wrote: Which reminds me .. anybody going to scream if I update elibtoolize() to be able to check if it was already run, and then bug the portage guys to also add it to econf() ? do what now ? Make econf handle elibtoolize the same way it does gnuconfig ... why ? this would help us embedded peeps with uclibctoolize, but other than that ... maybe i just havent really sat down to figure out what elibtoolize does ... Note ... I really don`t think uclibctoolize and the other stuff that was added is really appropriate in libtool.eclass, as they touch config.guess, etc .. maybe it would have been better to update gnuconfig to try and apply the patch if in uclibc profile? uhh, uclibctoolize doesnt touch config.guess ... it only touches ltconfig/configure because libtool does not know about uClibc and thus will often disable shared library support when trying to build on a uClibc host Urk, my fault .. maybe its the macosx stuff then. i make no claims as to the sanity of the OS X libtoolize as i had nothing to do with it :) Either way, how about integrating them rather with the default way elibtoolize() work? If you guys are game, I can do it so that the old still will work, and we can then drop the call to it and elibtoolize once its integrated into econf(). if you mean dropping uclibctoolize and integrating all of that stuff into the elibtoolize logic, then sure, feel free ... as long as we keep the patches sep though ... Was thinking about creating uclibc-ltconfig and uclibc-configure patch sets and add that to $elt_patches ... -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] autotools support eclass
On Sat, 2005-08-27 at 14:00 +0200, Diego 'Flameeyes' Pettenò wrote:
I was wondering last night with az about the handling of autotools.
They not always require to be re-run by scratch, but when you have to run
aclocal you usually have to run everything after that.
Every ebuild handles them in a different way, some ebuilds run them in a
list and then || die, others runs them one-by-one.
Some force updating of support files and some don't.
Some adds code to let them print the status to the screen, some hides the
actual output and some don't.
I still think a autoreconf is usually enough, except for cases where
that do not work, and then something like this will not work anyhow.
Anyhow, if you insist, then rather something like attached.
PS: elibtoolize is a problem as it might collide with the one from
libtool.eclass
--
Martin Schlemmer
# Copyright 1999-2005 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/eclass/eutils.eclass,v 1.194 2005/08/09
22:40:39 vapier Exp $
#
# Author: Diego Pettenò [EMAIL PROTECTED]
# Enhancements: Martin Schlemmer [EMAIL PROTECTED]
#
# This eclass is for handling autotooled software packages that
# needs to regenerate their build scripts.
#
# NB: If you add anything, please comment it!
inherit eutils gnuconfig
DEPEND=sys-devel/automake
sys-devel/autoconf
sys-devel/libtool
# Internal function to run an autotools' tool
autotools_run_tool() {
local STDERR_TARGET=${T}/$$.out
local PATCH_TARGET=${T}/$$.patch
local ris
echo * $1 * ${STDERR_TARGET%/*}/$1-${STDERR_TARGET##*/}
echo ${STDERR_TARGET%/*}/$1-${STDERR_TARGET##*/}
ebegin Running $1
$@ ${STDERR_TARGET%/*}/$1-${STDERR_TARGET##*/} 21
ris=$?
eend ${ris}
if [[ ${ris} != 0 ]]; then
echo
eerror Failed Running $1 !
eerror
eerror Include in your bugreport the contents of:
eerror
eerror ${STDERR_TARGET%/*}/$1-${STDERR_TARGET##*/}
echo
die Failed Running $1 !
fi
}
# Internal function to check for support
autotools_check_macro() {
[[ -f configure.ac || -f configure.in ]] \
autoconf --trace=$1 2/dev/null
return 0
}
# Internal function to get additional subdirs to configure
autotools_get_subdirs() {
local subdirs_scan_out
subdirs_scan_out=$(autotools_check_macro AC_CONFIG_SUBDIRS)
[[ -n ${subdirs_scan_out} ]] || return 0
# Add --posix to below awk to make sure it will run on macosx, etc
echo ${subdirs_scan_out} | awk \
'($0 !~ /^[[:space:]]*(#|dnl)/) {
# The following is replaced by below, as we cannot use match()
# with a third argument with non-gawk (posix) versions of awk:
#
#if (match($0, AC_CONFIG_SUBDIRS\\(\\[?([^\])]*), res)) {
# split(substr($0, sindex), DIRS, /[\])]/)
# print DIRS[1]
#}
#
sindex = match($0, /AC_CONFIG_SUBDIRS\(\[?([^\])]*)/)
if (sindex 0) {
sindex += length(AC_CONFIG_SUBDIRS()
while (substr($0, sindex, 1) == [)
sindex++
split(substr($0, sindex), DIRS, /[\])]/)
print DIRS[1]
}
}' | uniq
return 0
}
# These functions runs the autotools using autotools_run_tool with the
# specified parametes. The name of the tool run is the same of the function
# without e prefix.
# They also force installing the support files for safety.
eaclocal() {
local aclocal_opts
[[ -n ${M4DIR} ]] aclocal_opts=-I \${M4DIR}\
[[ -f aclocal.m4 -n $(grep -e 'generated.*by aclocal' aclocal.m4) ]]
\
autotools_run_tool aclocal $@ ${aclocal_opts}
}
_elibtoolize() {
# Check if we should run libtoolize
[[ -n $(autotools_check_macro AC_PROG_LIBTOOL) ]] || return 0
autotools_run_tool libtoolize $@
# Need to rerun aclocal
eaclocal
}
eautoheader() {
# Check if we should run autoheader
[[ -n $(autotools_check_macro AC_CONFIG_HEADERS) ]] || return 0
autotools_run_tool autoheader $@
}
eautoconf() {
if [[ ! -f configure.ac ! -f configure.in ]] ; then
echo
eerror No configure.{ac,in} present in '$(pwd | sed -e
's:.*/::')'!
echo
die No configure.{ac,in} present!
fi
autotools_run_tool autoconf $@
}
eautomake() {
[[ -f Makefile.am ]] || return 0
autotools_run_tool automake --add-missing --force-missing --copy $@
}
# This function mimes the behavior of autoreconf
Re: [gentoo-dev] [RFC] autotools support eclass
On Sat, 2005-08-27 at 16:24 +0200, Martin Schlemmer wrote:
On Sat, 2005-08-27 at 14:00 +0200, Diego 'Flameeyes' Pettenò wrote:
I was wondering last night with az about the handling of autotools.
They not always require to be re-run by scratch, but when you have to run
aclocal you usually have to run everything after that.
Every ebuild handles them in a different way, some ebuilds run them in a
list and then || die, others runs them one-by-one.
Some force updating of support files and some don't.
Some adds code to let them print the status to the screen, some hides the
actual output and some don't.
I still think a autoreconf is usually enough, except for cases where
that do not work, and then something like this will not work anyhow.
Anyhow, if you insist, then rather something like attached.
PS: elibtoolize is a problem as it might collide with the one from
libtool.eclass
Apparently I can now use gawk on all the bsd's. I am touchy about
adding gawk/whatever to the DEPEND, as it sometimes causes issues during
'emerge system' if its in a very base package ...
--
Martin Schlemmer
# Copyright 1999-2005 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/eclass/eutils.eclass,v 1.194 2005/08/09
22:40:39 vapier Exp $
#
# Author: Diego Pettenò [EMAIL PROTECTED]
# Enhancements: Martin Schlemmer [EMAIL PROTECTED]
#
# This eclass is for handling autotooled software packages that
# needs to regenerate their build scripts.
#
# NB: If you add anything, please comment it!
inherit eutils gnuconfig
DEPEND=sys-devel/automake
sys-devel/autoconf
sys-devel/libtool
# Internal function to run an autotools' tool
autotools_run_tool() {
local STDERR_TARGET=${T}/$$.out
local PATCH_TARGET=${T}/$$.patch
local ris
echo * $1 * ${STDERR_TARGET%/*}/$1-${STDERR_TARGET##*/}
echo ${STDERR_TARGET%/*}/$1-${STDERR_TARGET##*/}
ebegin Running $1
$@ ${STDERR_TARGET%/*}/$1-${STDERR_TARGET##*/} 21
ris=$?
eend ${ris}
if [[ ${ris} != 0 ]]; then
echo
eerror Failed Running $1 !
eerror
eerror Include in your bugreport the contents of:
eerror
eerror ${STDERR_TARGET%/*}/$1-${STDERR_TARGET##*/}
echo
die Failed Running $1 !
fi
}
# Internal function to check for support
autotools_check_macro() {
[[ -f configure.ac || -f configure.in ]] \
autoconf --trace=$1 2/dev/null
return 0
}
# Internal function to get additional subdirs to configure
autotools_get_subdirs() {
local subdirs_scan_out
subdirs_scan_out=$(autotools_check_macro AC_CONFIG_SUBDIRS)
[[ -n ${subdirs_scan_out} ]] || return 0
echo ${subdirs_scan_out} | gawk \
'($0 !~ /^[[:space:]]*(#|dnl)/) {
if (match($0, AC_CONFIG_SUBDIRS\\(\\[?([^\\])]*), res)) {
split(res[1], DIRS, /[\])]/)
print DIRS[1]
}
}' | uniq
return 0
}
# These functions runs the autotools using autotools_run_tool with the
# specified parametes. The name of the tool run is the same of the function
# without e prefix.
# They also force installing the support files for safety.
eaclocal() {
local aclocal_opts
[[ -n ${M4DIR} ]] aclocal_opts=-I \${M4DIR}\
[[ -f aclocal.m4 -n $(grep -e 'generated.*by aclocal' aclocal.m4) ]]
\
autotools_run_tool aclocal $@ ${aclocal_opts}
}
_elibtoolize() {
# Check if we should run libtoolize
[[ -n $(autotools_check_macro AC_PROG_LIBTOOL) ]] || return 0
autotools_run_tool libtoolize $@
# Need to rerun aclocal
eaclocal
}
eautoheader() {
# Check if we should run autoheader
[[ -n $(autotools_check_macro AC_CONFIG_HEADERS) ]] || return 0
autotools_run_tool autoheader $@
}
eautoconf() {
if [[ ! -f configure.ac ! -f configure.in ]] ; then
echo
eerror No configure.{ac,in} present in '$(pwd | sed -e
's:.*/::')'!
echo
die No configure.{ac,in} present!
fi
autotools_run_tool autoconf $@
}
eautomake() {
[[ -f Makefile.am ]] || return 0
autotools_run_tool automake --add-missing --force-missing --copy $@
}
# This function mimes the behavior of autoreconf, but uses the different
# eauto* functions to run the tools. It doesn't accept parameters, but
# the directory with include files can be specified with M4DIR variable.
#
# Note: doesn't run autopoint right now, but runs gnuconfig_update.
eautoreconf() {
local pwd=$(pwd) x
# Take care of subdirs
for x in $(autotools_get_subdirs); do
if [[ -d ${x
Re: [gentoo-dev] [RFC] autotools support eclass
On Sat, 2005-08-27 at 17:51 +0200, Maurice van der Pot wrote:
On Sat, Aug 27, 2005 at 04:24:40PM +0200, Martin Schlemmer wrote:
I still think a autoreconf is usually enough, except for cases where
that do not work,
And what is not work in this case?
- fails with an error so it's impossible to miss as a dev, or
- fails to do things properly, causing subtle bugs that users will run into
Some guy doing a half ass job on writing configure.{ac,in}, Makefile.am
and whatever other helper scripts causing either autoreconf to fail, or
errors during building.
Don't ask for an example .. I cannot recall now, but I have run into a
few packages in the past.
--
Martin Schlemmer
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] autotools support eclass
On Sat, 2005-08-27 at 14:37 -0400, Mike Frysinger wrote:
On Saturday 27 August 2005 08:00 am, Diego 'Flameeyes' Pettenò wrote:
eautoreconf() {
local aclocal_opts
[[ -n ${M4DIR} ]] aclocal_opts=-I ${M4DIR}
eaclocal $aclocal_opts
eautoconf
eautoheader
eautomake
gnuconfig_update
autotools_run_tool libtoolize --copy --force
}
the gnuconfig isnt really needed ... econf handles all of that for you
Which reminds me .. anybody going to scream if I update elibtoolize() to
be able to check if it was already run, and then bug the portage guys to
also add it to econf() ?
--
Martin Schlemmer
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] autotools support eclass
On Sat, 2005-08-27 at 15:11 -0400, Mike Frysinger wrote:
On Saturday 27 August 2005 02:58 pm, Martin Schlemmer wrote:
On Sat, 2005-08-27 at 14:37 -0400, Mike Frysinger wrote:
On Saturday 27 August 2005 08:00 am, Diego 'Flameeyes' Pettenò wrote:
eautoreconf() {
local aclocal_opts
[[ -n ${M4DIR} ]] aclocal_opts=-I ${M4DIR}
eaclocal $aclocal_opts
eautoconf
eautoheader
eautomake
gnuconfig_update
autotools_run_tool libtoolize --copy --force
}
the gnuconfig isnt really needed ... econf handles all of that for you
Which reminds me .. anybody going to scream if I update elibtoolize() to
be able to check if it was already run, and then bug the portage guys to
also add it to econf() ?
do what now ?
Make econf handle elibtoolize the same way it does gnuconfig ...
--
Martin Schlemmer
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Package version requiring sse
On Thu, 2005-08-25 at 13:41 +0200, Paul de Vrieze wrote: On Wednesday 24 August 2005 15:23, Martin Schlemmer wrote: Same thing (and probably better option) if you put it in pkg_setup() ... Isn't pkg_setup run too when just building a binary package (-B) (then the check shouldn't be performed), and just before installing a binary package? True, but usually you build whatever on a machine that have capabilities to run it (not talking about cross-compiling). And besides, I think its bad style to build something, and then bail after its done about something that could have been tested at setup time (think glibc testing tls/nptl capabilities only during pkg_preinst ...). -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] The make confusion
On Thu, 2005-08-18 at 11:55 -0400, Mike Frysinger wrote: On Thursday 18 August 2005 11:19 am, Diego 'Flameeyes' Pettenò wrote: I'm thinking about adding bsdmk to main tree and make ash/csh use it to find pmake considering the number of packages that use pmake, why do you want an eclass for it ? i'd say just put the logic in the ebuilds themselves Also, Fedora have patches for ash to use gnu make and bison .. not sure about csh ... -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Package version requiring sse
On Wed, 2005-08-24 at 14:53 +0200, Paul de Vrieze wrote: On Saturday 06 August 2005 20:18, Jeff Walter wrote: Yuri Vasilevski wrote: Hi, On Sat, 06 Aug 2005 20:04:20 +0300 Ivan Yosifov [EMAIL PROTECTED] wrote: I am not sure if it is better, but you can cat /proc/cpuinfo | grep flags | grep sse and die if not found. This will make packages dependant on the build system, which will create inconsistencies in binary gentoo packages. Yuri. This is true, and there's no good way around the issue. I had written a small script to actually search for the flag (grep'ing for sse will go true for sse2 as well), we I noticed this. Will valgrind 3.0.0 ever work on systems without sse? If not, the USE flag might be your best bet. Put a check on /proc/cpuinfo in pkg_preinst. This should get executed on the final machine, so not when building binary packages. Same thing (and probably better option) if you put it in pkg_setup() ... -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] The dreaded debug use flag/eclass
On Tue, 2005-08-02 at 09:22 -0400, Mike Frysinger wrote: On Monday 01 August 2005 10:43 pm, Danny van Dyk wrote: Mike Frysinger schrieb: |your USE=pic example is wrong, it does not change CFLAGS (and if your |package does, it is broken) chillispot at least is not wrong. If USE=pic is set, it compiles _only with_ -fPIC, ommiting to compile files twice and effectivly telling libtool not to produce a normal static library. just to review ... `use_with pic` should never be used because if you dont have 'pic' in your USE flags, the ebuild will run `./configure --without-pic` ... that means libtool will try to produce shared and static libraries with object files which were built without PIC ... on many arches (like amd64), the linker will abort btw, where do you get this information ? my tests show that libtool still compiles all files twice even though --with-pic was used ... Last time I checked, only --without-pic or --disable-static disable compiling twice. -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Proposal: pre-emerge advisories
On Sat, 2005-07-23 at 11:18 -0400, Greg KH wrote:
On Sat, Jul 23, 2005 at 10:53:15AM -0400, Alec Warner wrote:
Georgi Georgiev wrote:
Just to make sure I am not missing something.
Does this cover the
- If you are upgrading from a version of udev prior to 046 ...
- If you are upgrading from a version of udev prior to 050 ...
- If you are upgrading from a version of udev prior to 057 ...
- If you are upgrading from a version of udev prior to 059 ...
cases automatically? I.e. *not* showing irrelevant warnings on every
upgrade/rebuild.
The writer of pkg_warn() could do this, it's still in the ebuild and
could use the normal ebuild functions to determine what the user is
running ( has_version() and whatnot ) and then run a case statement on that.
Great, anyone care to send me a patch for the udev ebuild to do this so
not everyone sees this message? It will only get longer over time...
Something like this maybe? (Yes, I know using $T will be frowned upon,
but not much else you can do. Also, might use has_version(), but that
is more difficult to parse, and I figured you normally only want those
for system udev ...)
--
Martin Schlemmer
Index: udev-063.ebuild
===
RCS file: /var/cvsroot/gentoo-x86/sys-fs/udev/udev-063.ebuild,v
retrieving revision 1.2
diff -u -r1.2 udev-063.ebuild
--- udev-063.ebuild 17 Jul 2005 06:10:06 - 1.2
+++ udev-063.ebuild 25 Jul 2005 07:46:59 -
@@ -135,6 +135,15 @@
}
pkg_preinst() {
+ local udev_version=$(udev -V 2/dev/null)
+
+ if [ -n ${udev_version} ]
+ then
+ # Strip leading '0'
+ udev_version=${udev_version##0}
+ echo ${udev_version} ${T}/udev_version
+ fi
+
if [ -f ${ROOT}/etc/udev/udev.config -a \
! -f ${ROOT}/etc/udev/udev.rules ]
then
@@ -155,6 +164,8 @@
}
pkg_postinst() {
+ local udev_version=0
+
if [ ${ROOT} = / -a -n `pidof udevd` ]
then
killall -15 udevd /dev/null
@@ -162,33 +173,48 @@
killall -9 udevd /dev/null
fi
+ [ -f ${T}/udev_version ] udev_version=$( ${T}/udev_version)
+
# people want reminders, I'll give them reminders. Odds are they will
# just ignore them anyway...
- ewarn Note: If you are upgrading from a version of udev prior to 046
- ewarn and you rely on the output of udevinfo for anything, please
- ewarn either run 'udevstart' now, or reboot, in order to get a
- ewarn up-to-date udev database.
- ewarn
- ewarn Note: If you are upgrading from a version of udev prior to 050
- ewarn and you had written some custom permissions rules, please
- ewarn realize that the permission rules are now part of the main
- ewarn udev rules files and are not stand-alone anymore. This means
- ewarn you need to rewrite them.
- ewarn
- ewarn Note: If you are upgrading from a version of udev prior to 057
- ewarn and you have written custom rules, and rely on the etc/dev.d/
- ewarn functionality, please read the RELEASE-NOTES file for details
- ewarn on what has changed with this feature, and how to change your
- ewarn rules to work properly.
- ewarn
- ewarn Note: If you are upgrading from a version of udev prior to 059
- ewarn and you have written custom rules, and rely on the etc/dev.d/
- ewarn functionality, or the etc/hotplug.d functionality, or just
- ewarn want to write some very cool and power udev rules, please
- ewarn read the RELEASE-NOTES file for details on what has changed
- ewarn with this feature, and how to change your rules to work properly.
+ if [ ${udev_version} -lt 46 ]
+ then
+ ewarn Note: If you are upgrading from a version of udev prior to 046
+ ewarn and you rely on the output of udevinfo for anything, please
+ ewarn either run 'udevstart' now, or reboot, in order to get a
+ ewarn up-to-date udev database.
+ echo
+ fi
+ if [ ${udev_version} -lt 50 ]
+ then
+ ewarn Note: If you are upgrading from a version of udev prior to 050
+ ewarn and you had written some custom permissions rules, please
+ ewarn realize that the permission rules are now part of the main
+ ewarn udev rules files and are not stand-alone anymore. This means
+ ewarn you need to rewrite them.
+ echo
+ fi
+ if [ ${udev_version} -lt 57 ]
+ then
+ ewarn Note: If you are upgrading from a version of udev prior to 057
+ ewarn and you have written custom rules, and rely on the etc/dev.d/
+ ewarn functionality, please read the RELEASE-NOTES file for details
+ ewarn on what has changed with this feature, and how to change your
+ ewarn rules to work properly.
+ echo
+ fi
+ if [ ${udev_version} -lt 59 ]
+ then
+ ewarn Note: If you are upgrading from a version of udev prior to 059
+ ewarn and you have written custom rules, and rely on the etc/dev.d/
+ ewarn functionality, or the etc/hotplug.d functionality, or just
+ ewarn want
Re: [gentoo-dev] Re: Proposal: pre-emerge advisories
On Mon, 2005-07-25 at 20:53 +0900, Jason Stubbs wrote: On Monday 25 July 2005 16:51, Martin Schlemmer wrote: On Sat, 2005-07-23 at 11:18 -0400, Greg KH wrote: On Sat, Jul 23, 2005 at 10:53:15AM -0400, Alec Warner wrote: Georgi Georgiev wrote: Just to make sure I am not missing something. Does this cover the - If you are upgrading from a version of udev prior to 046 ... - If you are upgrading from a version of udev prior to 050 ... - If you are upgrading from a version of udev prior to 057 ... - If you are upgrading from a version of udev prior to 059 ... cases automatically? I.e. *not* showing irrelevant warnings on every upgrade/rebuild. The writer of pkg_warn() could do this, it's still in the ebuild and could use the normal ebuild functions to determine what the user is running ( has_version() and whatnot ) and then run a case statement on that. Great, anyone care to send me a patch for the udev ebuild to do this so not everyone sees this message? It will only get longer over time... Something like this maybe? (Yes, I know using $T will be frowned upon, but not much else you can do. Also, might use has_version(), but that is more difficult to parse, and I figured you normally only want those for system udev ...) Combining the pkg_preinst and pkg_postinst parts (and removing the usage of $T ;), that pretty much shows exactly what the proposed pkg_warn would look like. Only difference being that it would be executed before emerging starts. Currently: - if everything is moved to pkg_preinst(), the message will not show at the end of the merge, so much higher chance of getting missed. - if everything is moved to pkg_postinst(), $udev_version will be the new version, and be of no use. - if you meant that this is for the pkg_warn() ... it still wont really help that much, as it will differ from before/after the update :/ -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: upgrade's and rc-scripts
On Fri, 2005-07-22 at 18:40 -0500, Brian D. Harring wrote: On Sat, Jul 23, 2005 at 01:20:19AM +0200, Sven Köhler wrote: Apropos config-files: what about config-files that are provided by the old-version of an ebuild but have been moved or removed by the new version? etc-update doesn't know about them. So /etc/ will be full of useless config-files after some time. Vapier had suggested yanking (on unmerge, not replacement) any config_protected file that has the same md5/mtime as what it was originally merged with. This would cause issues for nvidia-kernel though I'd think, although their solution isn't exactly optimal (no better solution atm either though). Not sure I'm on speed with why that would be bad for nvidia-kernel? Regards, -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
RE: [gentoo-dev] init script guidelines
On Tue, 2005-07-19 at 14:40 -0400, Chris Gianelloni wrote: On Tue, 2005-07-19 at 14:08 -0400, Eric Brown wrote: My point is that Snort and Apache are not alone in this, so I suppose quite a few upstream developers just disagree with us on what proper initialization means. Why should our users suffer? They shouldn't, but that doesn't mean implementing some half-baked hack to resolve the situation. It might be better to instead patch the daemon in question and send the patches upstream. Upstream developers (usually) are much more willing to make changes when you've done the work for them... ;] I know Roy already did the sleep check in rc-services.sh which is small, and I think fairly acceptable, but like Mike said, you cannot make it longer and then do it for all, as some arches is just too slow, and I'm going to guess we have a less than 10% of services with this issue? Personally I think the issue should be taken on a per-package basis, and if somebody sees an issue, open a bug against snort/apache/whatever to do a timeout, and then check some or other way if its actually started. For the developer awareness issue ... its not always such an open/shut case. I can't remember what had this issue, but some daemon only displayed this issues with slower boxes, and not the faster ones, so it really will totally depend on what type of hardware the developer have or not. So yeah, better awareness by adding a section to the developer manual or something to the test for new developers might help, but not fool proof. -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] devfs is dead, let's move on
On Sat, 2005-07-09 at 20:34 +0200, Richard Fish wrote: I.o.w. is it still necessary to have RC_DEVICE_TARBALL=yes as a default or can we move to a pure udev system and change the default to no. I've been running my boxes successfully with no since the option showed up just fine :) I think people is under a misconception about this option and ... you really only need to enable this for a driver that is not sysfs aware (nvidia comes to mind - any others?), or if you have some custom nodes in /dev that you cannot do via udev ... And I am pretty sure (correct me if I am wrong) that all (or most?) in-kernel drivers are sysfs aware, and only a handful outside are not. Well, I do have a small issue with the software RAID (md) driver, in that when autodetection is not performed by the driver (due to either being a module or booting the system through an initramfs), no sysfs entries or device nodes are created. Normally my RAID system is brought up inside my initramfs with static nodes, so this really only affects my recovery CD, where I need to run: for d in 0 1 2 3; do /sbin/mdadm --assemble --config=partitions --auto=md --super-minor=$d /dev/md$d /dev/null 21 done Maybe something similar will be required in /sbin/rc, like you currently do for LVM and the device mapper? It isn't a critical problem though...I am pretty sure there are only a few Gentoo users who will ever see this...maybe as few as 1!!! Mike, what do you think? This viable? We could maybe add an init addon for md, and move the lvm/whatever stuff to that as well? -- Martin Schlemmer Gentoo Linux Developer, Desktop/System Team Developer Cape Town, South Africa signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] splitting build deps out from depends
On Sat, 2005-07-09 at 18:28 +0900, Jason Stubbs wrote: On Tuesday 05 July 2005 19:48, Martin Schlemmer wrote: This is all well and dandy, but try to add coreutils as a dependency of itself, or gcc of itself, or sed ... or grep ... etc, and then try to do a stage1 install (probably stage2/3 as well, but I never do those, so rather wont comment). The point that Mike and I make, is that portage cannot handle this (and probably wont be able to in future without a _lot_ of black magic), and this is why we need the system profile which have just the right amount of DEPEND magic to make it work, and then everything else depends automagically on the system profile (and everything in it). Making the adding of system packages to non system packages really redundant. Portage can handle this because it doesn't look at BDEPEND. Black magic is not required. Black magic is what we have now that is causing so many problems. Ok, sorry, so maybe I went a bit overboard :) The point I tried to make is that with the current depend resolver this will not work, and we cannot just start to add packages in the system profile to DEPEND all over the place. -- Martin Schlemmer Gentoo Linux Developer, Desktop/System Team Developer Cape Town, South Africa signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] splitting build deps out from depends
On Sat, 2005-07-09 at 11:47 +0200, Diego 'Flameeyes' Pettenò wrote: On Saturday 09 July 2005 11:28, Jason Stubbs wrote: However, if an ebuild chooses to run make directly for some unknown reason or use some specific tool to unpack an unsupported file format, the package should really be explicit about its dependency. And this let me think: we'll be able sooner or later to specify 'gmake' instead of make to avoid having aliases magic on G/FBSD systems? :) I still this this is a bsd issue, so some or other solution which do not include having gmake (and then later lots of other symlinks/whatever) should be installed system wide for only a very small portion of our user segment on all systems. If its portage side only, fine. If I am missing something, my apologies - I am just making my stance clear. Thanks, -- Martin Schlemmer Gentoo Linux Developer, Desktop/System Team Developer Cape Town, South Africa signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] splitting build deps out from depends
On Sat, 2005-07-09 at 15:11 +0200, Diego 'Flameeyes' Pettenò wrote: On Saturday 09 July 2005 15:05, Martin Schlemmer wrote: Ditto - point being, is that if you want the agony of per-ebuild hacks, be my guest, but do not expect the rest to hold your hand. It's not a matter of per-ebuild hack. Let me explain for example: for a bit of time we had make - gmake alias on g/fbsd profiles, but emake still called plain make (bsdmake). That was fine for most of the cases, gawk was the first one failing because it uess $(RM) which on gmake is an internal but it's not in other makes. The good solution was to fix the configure.in (or .ac i don't remember) to make sure that RM variable was set. That was discarded and we needed to let emake call gmake. The problem of make/gmake is minimal, just a few corner cases, but I don't really like have to use alias make='gmake' in profiles. Could do a make wrapper similar to the emake one, that just stips /usr/$(get_libdir)/portage/bin from PATH, and then run $MAKE. Then bsd will only need to add MAKE=gmake to its profile, and change it to MAKE=make or whatever for the bsd only stuff ? (as I assume you already have to do that for emake ...) Anyhow, just a suggestion. -- Martin Schlemmer Gentoo Linux Developer, Desktop/System Team Developer Cape Town, South Africa signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] devfs is dead, let's move on
On Fri, 2005-07-08 at 15:25 -0700, Greg KH wrote: On Fri, Jul 08, 2005 at 07:49:34PM +0200, Michiel de Bruijne wrote: On Thursday 07 July 2005 00:46, Greg KH wrote: Ok, now that devfs is removed from the 2.6 kernel tree[1], I think it's time to start to revisit some of the /dev naming rules that we currently are living with[2]. To start with, the 061 version of udev offers a big memory savings if you use the default kernel name of a device[3]. If you do that, it does not create a file in its database in /dev/.udevdb/ Are there any ebuilds in the tree that are not sysfs/udev-aware? Not that I am aware of. Anyone else know of any? Neither. Or rather, I do not know about anything that should not work with LSB /dev ... I.o.w. is it still necessary to have RC_DEVICE_TARBALL=yes as a default or can we move to a pure udev system and change the default to no. I've been running my boxes successfully with no since the option showed up just fine :) I think people is under a misconception about this option and ... you really only need to enable this for a driver that is not sysfs aware (nvidia comes to mind - any others?), or if you have some custom nodes in /dev that you cannot do via udev ... And I am pretty sure (correct me if I am wrong) that all (or most?) in-kernel drivers are sysfs aware, and only a handful outside are not. -- Martin Schlemmer Gentoo Linux Developer, Desktop/System Team Developer Cape Town, South Africa signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] devfs is dead, let's move on
On Sat, 2005-07-09 at 02:44 +0200, Michiel de Bruijne wrote: On Saturday 09 July 2005 01:35, Martin Schlemmer wrote: I think people is under a misconception about this option and ... you really only need to enable this for a driver that is not sysfs aware (nvidia comes to mind - any others?) nvidia is also sysfs-aware and /dev-entries are created with udev, I have RC_DEVICE_TARBALL=no set on all machines I maintain and a few of them have a nvidia-card. Works perfectly. Hmm, what driver version? The earlier versions used to have a patch I wrote to get the support and then they did their own code. The last two or so releases however did not support this as far as I know (could be wrong, but do not look that way .. or with 2.6.11/12+ and 1.0.7* at least): - lycan ~ # grep nvidia /dev/.udevdb/* lycan ~ # bzcat /lib64/udev-state/devices.tar.bz2 | tar -t nvidiactl nvidia0 lycan ~ # - Regards, -- Martin Schlemmer Gentoo Linux Developer, Desktop/System Team Developer Cape Town, South Africa signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] src_configure
On Thu, 2005-07-07 at 02:04 +0200, Sven Wegener wrote: Hi all! I'm writing this mail to bring you a thought we had over on freenode in the #gentoo-portage channel. We would like to split up src_compile. The new src_configure should just do the econf part and src_compile should do the emake part. This represents the general 3-step[1] installation in a much better way. Will make debugging compile failures much easier imho. -- Martin Schlemmer Gentoo Linux Developer, Desktop/System Team Developer Cape Town, South Africa signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: devfs is dead, let's move on
On Thu, 2005-07-07 at 12:44 -0700, Duncan wrote: Martin Schlemmer posted [EMAIL PROTECTED], excerpted below, on Thu, 07 Jul 2005 15:55:45 +0200: Lastly on an unrelated note ... I have a rule: - # cat /etc/udev/rules.d/40-dm.rules KERNEL=dm-[0-9]*, PROGRAM=/sbin/devmap_name %M %m, NAME=mapper/%c, SYMLINK=%c - And in theory it should be the last rule to set the name ... however the default one in 50-udev.rules overrides it, and I have to add OPTIONS=last_rule Why would a rule applied in 40-x.rules be expected to stick when 50-x.rules runs after it and has a conflicting rule? Change the 40- to 60- and it should work. Of course, you are already using another alternative, the last_rule option. According to the manpage: - NAME The name of the node to be created, or the name, the network interface should be renamed to. Only one rule can set the a name, all later rules with a NAME key will be ignored. - -- Martin Schlemmer Gentoo Linux Developer, Desktop/System Team Developer Cape Town, South Africa signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] devfs is dead, let's move on
On Thu, 2005-07-07 at 13:52 -0700, Greg KH wrote: On Thu, Jul 07, 2005 at 03:55:45PM +0200, Martin Schlemmer wrote: On Wed, 2005-07-06 at 15:46 -0700, Greg KH wrote: Ok, now that devfs is removed from the 2.6 kernel tree[1], I think it's time to start to revisit some of the /dev naming rules that we currently are living with[2]. To start with, the 061 version of udev offers a big memory savings if you use the default kernel name of a device[3]. If you do that, it does not create a file in its database in /dev/.udevdb/ If we can move away from some of our devfs-like names, we stand to reclaim a lot of memory from everyone's machines. As an example, if we drop all of the tty/pts/vc/vcc symlinks, and just go with the default kernel name, we save 2.5Mb of space in tempfs/ramfs. I've done this on my machines and everything seems to work just fine (it looks like everything that was trying to use a tty node was just using the symlink anyway.) So, anyone have any objections to me changing the default udev naming scheme in this manner? Fine with me. I assume we will need to keep the rcscript support for those die-hard 2.4 users still, but hopefully we can eventually drop that as well. What rcscript support? Err, sorry, all the crap in /sbin/rc ... Next up, that loony block device naming scheme (more on that later...) [3] HAL needs a patch to be able to handle this. It's posted on the hal development mailing lists and will be checked in real-soon-now. I just think we need to make sure this is in first ... The HAL patch? It's now in HAL's cvs tree, don't know when they will do a new release. Well, you did provide the patch, so hopefully foser or somebody else will just add it. Foser ping ... Lastly on an unrelated note ... I have a rule: - # cat /etc/udev/rules.d/40-dm.rules KERNEL=dm-[0-9]*, PROGRAM=/sbin/devmap_name %M %m, NAME=mapper/%c, SYMLINK=%c - And in theory it should be the last rule to set the name ... however the default one in 50-udev.rules overrides it, and I have to add OPTIONS=last_rule Yes. Want me to just change the default rule to yours? I do not think that will work, as that is not distributed with either udev or device-mapper, but multipath-tools (sorda silly if you ask me, as I think it would have been more appropriate with device-mapper, but what the hey). Anyhow, I'll see if I can hack a patch or something up so that NAME= will also be seen as as a rule that 'set the name' Thanks, -- Martin Schlemmer Gentoo Linux Developer, Desktop/System Team Developer Cape Town, South Africa signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] splitting build deps out from depends
On Fri, 2005-07-01 at 13:42 -0500, Brian D. Harring wrote: On Fri, Jul 01, 2005 at 02:30:12PM -0400, Mike Frysinger wrote: On Friday 01 July 2005 02:11 pm, Brian D. Harring wrote: Meanwhile, back to the you want us to add what?, our dependency graph *is* incomplete. so what ? i dont see it being a bug I do. :) I don't as well, until you can prove that portage can handle a system install without a system profile, and everything depending on the system profile. Just an example what an 'innocent' fix can do by adding a system profile item somewhere into an DEPEND where it does not belong, see bug #96209. We do a lot of work to have deps accurate, ignoring a fairly critical class of dependencies cause it's extra work seems a bit short sighted. Beyond that, see the user profile bit below, it shades incomplete toolchain dependencies as being a bug... Something like 600 ebuilds in the tree state a dependency on gcc- we have 19000 ebuilds. Not all requires gcc to build, but I'd bet it's a tad bit more then 600. and i continue to work day after day to make sure that 600 reaches 0 :p considering your system requires a virtual/libc in order to boot, tell me again why we must list it in every package which uses glibc ? Full dependency information hasn't be viable due to resolver issues, which will be fixed. so why dont you come back once you have something that is supposed to work ? you're proposing we start generating a ton of circular dependencies which we arent even close to handling now Floating the idea. BDEPEND implementation (if people thought it was a good idea) would go alongside use/slot dep implementation. The short version is BDEPEND is fairly heavily related to domain work for collapsing config/ROOT into a single groupping portage can work with. No BDEPEND means that things are nastier for dealing with x-compile from portage's standpoint, so a general yay/nay on the concept is needed (hence it being raised now). Like every other idea, it might be nice - just as the multi-slot-per-version idea would have been cool for x-compiling ... but still are not implemented. Do not get me wrong .. I assume this will do wonders for x-compiling and prevent world war, etc, but as Linus (or some other guy) would say: Show me the Code. On another note .. how do you guys plan to handle this BDEPEND .. just for x-compile, or global? If global, any ideas how to solve the circular issues ??? Regarding the require whatever is used to uncompress the source, hadn't thought about it, but that _should_ be specified imo. That's also being a bit anal, but frankly, if the resolver can handle it, why shouldn't we specify the full deps? portage could be smart about it ... it can easily parse the contents of SRC_URI and put tar into whatever DEPEND rather than forcing a stupid policy of listing tar in thousands of ebuilds Dep should be represented imo, regardless if portage automatically handles it (as mentioned above) or manually tacked in. Automatic tagging of such a dep makes a helluva lot more sense then manual. True, but its not always viable .. how much longer will it take portage to compute a dep graph that is 200 times more complete? 2 times? 10? Also as already asked, what about the chicken egg issue ... (think tar needing tar, or gzip needing gzip to unpack)? To head off the profile has it, so we don't need it, consider a user profile, literally, a user desktop profile. Kde, gnome, office crap, etc. Right now, for such a profile you would need the toolchain tagged in, which I posit is invalid. considering if you try to `emerge` something while under said profile and you already removed binutils/gcc from the system, the emerge will fail ... the reason why is pretty obvious Err... missing the point, and proving my point. Current portage _will_ fail because it's an unstated dependency. Why shouldn't portage be provided the deps it needs so it can figure out what is needed to get to what the user requested? I do not think so .. his point is: htf do you build binutils without binutils installed ? Same for gcc. Thanks, -- Martin Schlemmer Gentoo Linux Developer, Desktop/System Team Developer Cape Town, South Africa signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Software patents
On Tue, 2005-07-05 at 10:09 +0100, twofourtysix wrote: On 05/07/05, Patrick Lauer [EMAIL PROTECTED] wrote: On Tue, 2005-07-05 at 06:13 +0100, twofourtysix wrote: Mostly, I was hoping that all those people who seem more than happy to advocate something with *words* would be prepared to back them up with *actions*. I think it's a shame that Gentoo is prepared to encourage people to pester their politicians whilst simultaneously refusing to spend a few minutes practising what it preaches. Ok ... let's remove all software that might violate a european patent. Who was talking about removing ebuilds for software just because that software violates a patent? I certainly wasn't... Strange that I'm being accused of trolling when I'm not the one with the straw man arguments. Strange that you still have not given your true identity after it being pointed out. Strange that some people cannot see that some of us just love working on Gentoo, and do not want it to become yet another Political debacle. Strange that the same people cannot fight their own battle, but need to do it under the cover of some group. Strange that the same people only wake up now. Strange that some people cannot realise that others might have a different point of view, and way of doing things. -- -core was humorous, but I really do not see why we need to start it all over again due to some nameless person that is too much of a coward to post as himself. Thanks. -- Martin Schlemmer Gentoo Linux Developer, Desktop/System Team Developer Cape Town, South Africa signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Discussion: alternative compatible utilities
On Tue, 2005-06-21 at 14:45 -0400, Aron Griffis wrote: Azarah wrote:[Sat Jun 18 2005, 07:23:19AM EDT] You might however say install all gnuish tools with the 'g' prefix, and then install wrapper scripts/stubs into say /usr/bin/gnu/ or /bin/gnu/ (with /usr/bin/gnu/find calling gfind, etc), and portage just adds this path as the first path to $PATH ... This should cover the fact that aliases might not work in all cases, and is bsd specific implementation. That would actually cause a lot of problems because the PATH would be inherited by configure and/or make. The result is that programs get GNU tools when they are built, but BSD tools at run-time. I can only imagine that causing a lot of confusion. Ahh, right - didn't think about that. Although you realise that the same issues will be present when eselecting something before and after emerge ? Thanks, -- Martin Schlemmer Gentoo Linux Developer, Desktop/System Team Developer Cape Town, South Africa signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] New virtual: virtual/pcmcia
On Tue, 2005-07-05 at 14:11 +0200, Henrik Brix Andersen wrote: On Tue, 2005-07-05 at 11:25 +0200, Martin Schlemmer wrote: A bit late I know, but just for interest sake .. virtuals is usually used when more than one package usually provides the same compatible api/tool ... which basically means pcmcia-cs and pcmciautils do the same thing and cannot be installed together ? Sorry if my non-pcmcia cluedup-ness shows ... Yes, that is correct. pcmciautils will replace pcmcia-cs starting with linux-2.6.13, and the two can not be installed side-by-side as they have file collisions (not to mention the fact that they provide the same functionality). Thanks for clearing that up! Regards, -- Martin Schlemmer Gentoo Linux Developer, Desktop/System Team Developer Cape Town, South Africa signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] splitting build deps out from depends
On Tue, 2005-07-05 at 18:17 -0500, Brian Jackson wrote: Martin Schlemmer wrote: On Fri, 2005-07-01 at 15:59 -0700, Drake Wyrm wrote: Mike Frysinger [EMAIL PROTECTED] wrote: On Friday 01 July 2005 12:25 pm, Brian D. Harring wrote: Currently, we pretty much leave out the big dogs of build depends from ebuilds- basically we rely on the profile to require a suitable toolchain. Couple of issues with this though- so what you're proposing is that we add binutils/gcc/glibc to every package that compiles something Can you compile without binutils/gcc/glibc? No? Then you need it. make to every package that uses make, Again, if you depend on make, then DEPEND on make. sed/grep/bash/coreutils to every package which runs configure That's quite an interesting case. Yes, those should be in DEPEND, but it might be prudent to create an appropriate shortcut instead of explicitly adding each of those. This is all well and dandy, but try to add coreutils as a dependency of itself, or gcc of itself, or sed ... or grep ... etc, and then try to do a stage1 install (probably stage2/3 as well, but I never do those, so rather wont comment). Big picture here: * BDEPEND does nothing now, so don't worry about it if you don't want to * in the future it will make other things possible * give the man problems you see with the proposal, not just tell him that portage doesn't handle it right now... I think out of anyone, he knows what portage does and doesn't handle I did ask Brian in another reply how he thought to implement it. This one however I read as Drake saying/asking that we should start doing it now, and I tried to explain why we could not up until now, and still cannot. Correct me if I interpreted it wrongly. -- Martin Schlemmer Gentoo Linux Developer, Desktop/System Team Developer Cape Town, South Africa signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Discussion: alternative compatible utilities
is using the wrong way... after a couple of examples this can be quite simple as for the old gnu-find dependent ebuilds which are now fixed. But the problem is going to be that somebody will have to keep on 'policing' the ebuilds, and possibly teaching all devs all possible variations (broken or not) out there? The bit that Aron said about having things installed in a different location that you snipped, might be your answer. I don't think anybody (or too many) is going to moan too much about having some things install with a 'g' prefix on bsd systems, but I for one are going to complain about implementing something global such as eselect for utilities that have on 90%+ of the installations just the one implementation. I know that say installing all bsdish tools in say /usr/ucb, might not fly, as some of the bsd implementations might not be able to relocate those. You might however say install all gnuish tools with the 'g' prefix, and then install wrapper scripts/stubs into say /usr/bin/gnu/ or /bin/gnu/ (with /usr/bin/gnu/find calling gfind, etc), and portage just adds this path as the first path to $PATH ... This should cover the fact that aliases might not work in all cases, and is bsd specific implementation. Thanks, -- Martin Schlemmer Gentoo Linux Developer, Desktop/System Team Developer Cape Town, South Africa signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Acquiring a deeper understanding of Gentoo
On Wed, 2005-06-15 at 22:36 -0500, Michael Tindal wrote: Jonathan Smith wrote: M. Edward (Ed) Borasky wrote: I'm not a developer ... and I'm not in California ... but I am a Gentoo bigot and I'm certainly willing to help out ... as are most Gentoo users/developers. [snip] I know that I can't speak for all the developers, but I for one am slightly offended by being called a Gentoo bigot. I work on Gentoo because I love doing it, and I believe it helps people, but if those people use something else (another distro, *BSD, Solaris, OSX, even Windows) and it works for _them_, then so be it... As for the rest of your email, that information is readily available from the Gentoo Documentation Project, and in a much more readable and detailed format. -smithj It is rather offensive to myself as well, for the reasons detailed above. Please keep such comments to yourself and try to be less condescending in your responses in a public forum. And I am slightly offended by both of you, as he clearly was saying that _he_ is a Gentoo bigot. Please reread something 3 or 4 times before taking offence (and then sleep on it before replying). -- Martin Schlemmer Gentoo Linux Developer, Desktop/System Team Developer Cape Town, South Africa signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: New category proposal
On Mon, 2005-05-09 at 13:07 -0400, Aron Griffis wrote: Georgi Georgiev wrote:[Sun May 08 2005, 08:19:20PM EDT] Would it be inappropriate to start bitching (again) about a flat tree where each package can go in multiple categories? That's something I'd love to see eventually... I mean the flat tree, not the complaining ;-) Problem with flat tree, is the search times might then suck even more, as last I heard, too many dirs/files in one directory have a huge speed penalty. -- Martin Schlemmer Gentoo Linux Developer, Desktop/System Team Developer Cape Town, South Africa signature.asc Description: This is a digitally signed message part
