Re: [gentoo-dev] fix binary debug support, part elevenity billion
On 1/15/06, Olivier Crête <[EMAIL PROTECTED]> wrote: > Why not use the splitdebug instead of nostrip? And make building with -g > the default, then tell small HD users how to disable it in the docs. And > it needs to disable -fomit-frame-pointer at least on x86. I've been > building my whole system with splitdebug and yes it does take a lot of > space, but its really useful. No argument against splitdebug, but my guess is that it would be useless for 99.97% of users, and would lead to complaints on -user about how much disk space gentoo consumes compared to , so it should not be the default. -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] /sbin /usr/sbin security hole
On 1/17/06, Paweł Madej <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] ~ $ ls -al /sbin/ Please don't bother the devs with this anymore. We will be happy to explain the intricacies of unix permissions on gentoo-user. -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Bugzilla etiquette suggestions
On 2/13/06, Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > But... If INVALID is renamed, could we get a new GOAWAY resolution for > people who really deserve it? I would tend to agree with this. I myself was the 'victim' of an aggressively worded INVALID resolution to a bug report I filed due to my screwing up an upgrade to java 1.5. Even though I didn't particularly /like/ the response, I did learn that: 1. It was my own fault. 2. I needed to be really damn sure about future bug reports, particularly when I unmask things! So even if INVALID is watered down to be gentle to new (or easily offended) users, you do occasionally need to smack abusers or people who should know better (like me). -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] missing ide discs mapping is udev's fault?
On 2/21/06, Christian Bricart <[EMAIL PROTECTED]> wrote: > Hi, > So I have /dev/hda through /dev/hdl which are ok. But the mappings to > /dev/discs/discX with X > 7 are missing. > > I wanted to file a bug report, but I'm not certain if it's actually > udev's fault. Yes, it is udev's fault, but it is not a bug. The /dev/discs nodes were a convention of devfs, and _never_ standard. >From the ChangeLog (there are many other entries BTW): *udev-064-r1 (31 Jul 2005) 31 Jul 2005; Greg Kroah-Hartman <[EMAIL PROTECTED]> +files/udev.rules-064-r1, +udev-064-r1.ebuild: Start moving to a sane /dev naming scheme. This release removes the devfs names for the tty and consolde devices, and the symlinks that were implementing the LSB standard names. We only implement the LSB names now, which saves over 3Mb of RAM on /dev. -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] missing ide discs mapping is udev's fault?
On 2/21/06, Christian Bricart <[EMAIL PROTECTED]> wrote: > And hdparm iterates through /dev/ide/* if found... I assume you are talking about the init script? Because my hdparm binary requires one to specify a device node, there is no iteration... If so, AFAIK that exists only for those still running devfs. If /dev/ide does not exist, it iterates over all devices found by "dev/hd?". -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: KDE, metapackages, and monolithic packages
On 2/26/06, Mike Myers <[EMAIL PROTECTED]> wrote: > Do you know if there's a way or going to be a way to handle the split > ebuilds so that reemerging or unemerging a split ebuild will reemerge or > unemerge the corresponding packages? Can I suggest you move this discussion to -user? This has nothing to do with gentoo development. I'll be happy to explain how what you are asking for is accomplished on -user. -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Wishlist: an automated package upgrade system with fine-tunable sysadmin control
On 4/26/06, Kevin <[EMAIL PROTECTED]> wrote: > I'd like to have the capability of being able to list some packages that > should > never be upgraded automatically (I realize I can do this to some degree > already > with portage), some others that are very unlikely to break from an automated > upgrade and thus should always be upgraded automatically, and some packages So maybe this could be satisified by allowing user-defined categories of packages beyond system and world? Something like world, system, fragile, non-fragile? I think you could probably implement something like this yourself with a bit of trickery with the /var/lib/portage/world list. You could copy world to non-fragile, remove anything that you consider fragile from it, and then do an "automatic" update with: cp /var/lib/portage/world /var/lib/portage/world.bak cp /var/lib/portage/non-fragile /var/lib/portage/world emerge -DNuv world cp /var/lib/portage/world.bak /var/lib/portage/world A similar script for the fragile packages would let you update those as a group, obviously using the -p and/or --ask options as you like. Going back to -user now... -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Wishlist: an automated package upgrade system with fine-tunable sysadmin control
On 4/27/06, Duncan <[EMAIL PROTECTED]> wrote: > In any case, once you get your list and weed out the stuff you /don't/ > want on it, rather than doing that copy trickery, try this: Yeah, much smarter than my cp tricks. Although using emerge to generate the package list will have a problem in that it contains the versions, which is not what you want for this. But we seem to have going completely off-topic for -dev now... -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: When will KDE 3.5 be marked as stable?
On 5/4/06, Bart Braem <[EMAIL PROTECTED]> wrote: What makes us think we can not trust the KDE devs? 1. bugs.gentoo.org 2. bugs.kde.org I personally have been running KDE 3.5 since the RC days...when you actually had to add it to package.unmask. And *yes*, it has had more than it's share of problems. Even 3.5.1 had an annoying bug that caused a kicker segfault every time I logged out. 3.5.2 is the first 3.5 that seems completely stable. Honestly, if you want it so badly, add the necessary entries to package.keywords, merge it, and be happy. What is this obsession with pushing the Gentoo devs to mark things stable before they feel it is right to do so?? Is it just some pointless quest to have a completely "stable" system?? -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: When will KDE 3.5 be marked as stable?
On 5/5/06, Philip Webb <[EMAIL PROTECTED]> wrote: 060504 Chris Gianelloni wrote: > If we followed others blindly, as so many users suggest, > then we would have stabilized KDE 3.5 ages ago, > and every single one of you KDE users would be complaining > about how our QA sucks because KDE doesn't compile > or breaks badly in so many places. This is rubbish: I'm now using 3.5.2 & have had no problems whatsoever; nor did I have problems earlier with 3.5.0 & 3.5.1 . Not rubbish. I had problems. So did many others. Fortunately mine were of the "just annoying" variety, not of the "crap, did I make a backup last night?" kind. If you don't believe me, take a walk through bugs.kde.org. The Gentoo devs have done the right thing by holding back on stabilizing KDE. -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Re: When will KDE 3.5 be marked as stable?
On 5/5/06, Carsten Lohrke <[EMAIL PROTECTED]> wrote: All the whining leaves me with the feeling that I'm less interested to work for you. The question "What can I do?" I do never hear. Stop whining, but decide to help or give another distro a try. These are your choices. Just to try to counter some of the whining, I am sure that most users do appreciate the work that you do for little glory and even less pay. And I think you did the right thing by holding off on stabilization this long. Yeah, I know, not as good as a "how can I help?", but my day job is keeping me busy with 60 hour weeks atm Cheers, -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Re: Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay
On 6/9/06, Peter <[EMAIL PROTECTED]> wrote: Firstly, I think it is very clear that anything in sunrise is experimental or not supported in the main gentoo tree. That's fine! I don't think any user who goes through the trouble to set up an overlay would miss that point. You can't go to o.g.o and not see the disclaimers. And, anyone who goes through the trouble to svn the overlay, edit make.conf, etc., would not be an ignorant newbie (no disrespect to newbies intended). Anyone who fetches the sunrise overlay would know exactly what he/she intends to do and why. Much different than emerge --sync with keyword x86. Recently on -user there was someone who couldn't build any gnome apps, because they had an obsolete gnome2.eclass in their overlay. This user certainly didn't know enough about portage or ebuilds to be using an overlay like that. Besides, users frequently do imprudent things to their systems. They will break their systems by unmasking p.masked stuff (I've done this, so I am in this group), add dangerous CFLAGS based on random forum or wiki pages, and use ~arch packages and then rant about any bugs that show up. As you've already said, having it on a *.gentoo.org domain gives some people a higher level of comfort with it, regardless of any dislaimers. I have no idea what the quality of the sunrise overlay will be, but it seems likely to be worse than the currently p.masked stuff. If getting sunrise is easy enough, and a substantial number of users start using it, supporting those users could become very difficult. -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.
On 6/13/06, Peter <[EMAIL PROTECTED]> wrote: As an example, there is a kernel source build I've been playing with. I know, from the kernel team, it will never, repeat NEVER, get onto the portage tree. they want no part of it. My guess is that alternative kernels are probably the strongest argument there is _in favor_ of having a user-supported overlay area. It represents very little risk of wasting developers time on chasing down false bug reports, since the kernel version shows up in the emerge --info output. Any bug report from a user running an unsupported (whether in-tree or out-of-tree) kernel can simply be closed with a "try again with a supported kernel, reopen if necessary". It does risk some extra iterations of problem solving on -user, since we don't have a policy of requiring everybody posting a question to supply their --info. But I think that would be acceptable. But this is a very specific case, and if it really needs to be on *.gentoo.org, it could be handled with a "ricer-kernels.o.g.o" overlay. I don't see any great reason why such an overlay would need to be hosted on o.g.o however. And this single case doesn't serve as an adequate counter-argument to the concerns about the broad scope of sunrise. This kernel source will not cause Armageddon to arrive, cause smoke to issue from your power supply, nor interfere with other ebuilds. So I take this to mean you are supplying a warranty for this kernel? Because AFAIK even the people who *wrote* the kernel are quite explicit in the "no warranty" provisions of the license. Not even if it spins your hard drive backwards causing your entire mp3 collection to be converted to Britney Spears songs! -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] bugzilla 2.22 masked ~x86
On 7/5/06, Enrico Weigelt <[EMAIL PROTECTED]> wrote: Okay, if this short question cannot be anwered with an short help or an direct pointer to some help, it seems my contribution obviously isn't wanted. So I won't waste anymore of your and my time on this topic and don't file a bug. Just forget about it. He did give you a pointer to some help: "just click on the hyperlinks to see a description". All the help/documentation you need should be on the bug entry form. Click on Component (the link, not the list), and the help indicates it should be set to Applications. Platform is x86 (duh!).Priority, Severity, OS, etc are all explained right there. Assign to will be [EMAIL PROTECTED] (based on metadata.xml and Joshua's mail). If you still aren't sure what a stabilization bug looks like, you could search bugzilla for "stabilize" and get lots of examples. Or ask on -user. -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On 7/6/06, Diego 'Flameeyes' Pettenò <[EMAIL PROTECTED]> wrote: Right now we have mmx, 3dnow, 3dnowex, sse, sse2 and so on useflags present in the tree, almost never used to get new dependencies, but usually used to supply econf switches. Hoping the S/N ratio here hasn't gotten too high... IMO the main purpose of USE flags should be econf switches. Pulling in dependancies should be viewed as more of a side-effect, even if a common one. If the user wants "./configure ... --enable-gtk", then they need gtk on their box. Similarly, the mmx,sse,3dnow,etc useflags should be there for econf switches, not additions to CFLAGS. If the autoconf script has an --enable-mmx option, then the proper way to control that is through a useflag. I don't object to ebuilds adding CFLAGS/CXXFLAGS based on the result of your has_cpuset (for example, --fpmath= could be useful), but I don't believe has_cpuset should be used to set econf switches. And users should absolutely not have to muck with bashrc to disable this. Add a FEATURE, or something, to enable/disable it if necessary. -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Portage: missing pieces
On 7/6/06, Molle Bestefich <[EMAIL PROTECTED]> wrote: Evolution depends on Mozilla and Mono depends on SeaMonkey. I don't think this is right, at least not for what is currently in portage. When I do a USE="mono" emerge -Devp evolution No mozilla comes in. So evolution does not depend on mozilla, at least not directly. In fact, in the current portage tree, mozilla is going away, and being replaced by seamonkey. Very few (and hard masked) packages like gecko-sdk still depend on mozilla. So what you should eventually end up with is no mozilla but seamonkey. So I'm stuck here. Is it impossible to have Mono and Evolution installed at the same time? No, it is certainly possible, as I have both on my system. Are you using an portage overlay? If so, what is in it? When was the last time you did an emerge --sync? Also, the full output of "emerge -Duvpt world" would still be useful for us to see. -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On 7/7/06, Simon Stelling <[EMAIL PROTECTED]> wrote: That's because CFLAGS="-msse" currently doesn't do what the user would think it does. Which is the real problem, which we're solving with the change Diego suggested. Well I certainly do *not* expect it to run configure with "--enable-sse". -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Portage: missing pieces
On 7/7/06, Molle Bestefich <[EMAIL PROTECTED]> wrote: > Are you using an portage overlay? If so, what is in it? No. No idea what that is. Sounds interesting, though. It is a local portage tree with ebuilds that you have either written yourself or downloaded from others. Since the overlay will override what is in portage, you can easily get yourself into trouble this way. So it is not really recommended unless you *really* know what you are doing! [nomerge ] dev-util/mono-tools-1.1.11 [ebuild N] dev-dotnet/gecko-sharp-0.6 [nomerge ] www-client/mozilla-1.7.13 *Sigh*. What a mess. Unfortunately the Gentoo dev's have taken the rather unusual step of _breaking the tree_ due to a security problem. And from what I understand [1], mozilla is going to be package masked today (if it hasn't already), so the block messages should go away, but you'll get even worse "no package to satisify" messages. At this point your choices are fairly limited, and neither one is very good. 1. Unmerge both mono-tools and gecko-sharp. Mono-tools requires gecko-sharp, and that requires mozilla. You can use "equery files mono-tools" to see what you will lose by going this route. 2. Manually unmask mozilla (and probably mono-tools and gecko-sharp) to keep them around. This might work, but I think you're going to be jumping through a lot of hoops to try and avoid seamonkey. -Richard [1] http://bugs.gentoo.org/show_bug.cgi?id=137665 -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Portage: missing pieces
On 7/9/06, Molle Bestefich <[EMAIL PROTECTED]> wrote: Try reading the bug - users are basically being shoved off with an arrogant silence and a stamp on their forehead saying INVALID. *Sigh*. You really should post to -user first. The expectation here is that when a new version of gcc is stabilized, that users will upgrade to that in a reasonable amount of time, and use that (by selecting it with gcc-config) for compiling all new updates. FYI, gcc-3.4.4-r1 was stabilized on 2-Dec-2005, and the current stable is 3.4.6-r1 since May 29th. The devs can *not* be expected to verify that all software in portage builds with all versions of gcc in portage. For example, there is still an ebuild for gcc-2.95.3! But that is _not_ to be used for compiling new updates. The alternative here is that old versions of gcc disappear from portage, but that causes a problem for those who need those versions for some reason, such as compiling non-gentoo software. Nothing personal against Jakub Moc who probably has a lot to do, but the handling of relevant issues raised in the bugzilla is just unacceptable. What, exactly, do you find unacceptable in "Your gcc version is outdated and unsupported"? I suppose portage could be enhanced to have a is_gcc_version_supported() check, but I'm not sure how useful that would be. What's the state of Portage and Gentoo in general? Is there not enough hands to do a proper job? Or is it just that none of the devs see what's wrong because bugs are wrongly being closed marked "INVALID" such as the above when they're in fact not? If you want to test compiling every version of every package in portage with all 21 versions (16 if you assume all -rX versions are compatible, or /only 9/ if you only consider stable x86 versions) of gcc that are currently in portage, and submit patches when things fail, go ahead. BTW, your patches cannot remove the ability to use improvements that are only available in newer stable versions of gcc, such as -fvisibility=hidden. -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] helping out - how?
On 7/9/06, Molle Bestefich <[EMAIL PROTECTED]> wrote: I'd like to take a stab at maintainership (or at least fixing) an unmaintained ebuild. What versioning system do you guys use (CVS?), and what's the URL for checking out ebuilds? bugs.gentoo.org is where this kind of work is done. -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Portage: missing pieces
On 7/9/06, Molle Bestefich <[EMAIL PROTECTED]> wrote: As far as I can tell, the complaints are about Portage being unable to handle GCC upgrades gracefully for end users. The thing is, that portage doesn't technically "handle" gcc upgrades. The user really needs to do that, and they (should) know to do that when they see the new version show up in an "emerge -Duv world". Or on GWN. Ok, so some users are not getting that message. To be honest, I have no idea what to do about that. Having dozens (hundreds? all?) ebuilds check for a minimum version of gcc doesn't seem very effecient. I guess portage could check and warn about an unsupported version of gcc being selected for the system compiler, but then I we have to figure out exactly what the "supported" versions are, and exactly when a version becomes unsupported, as a matter of policy. But that won't even fix the "problem". The version of xine-lib that this bug refers to is a ~x86 version. Should that be expected to compile with the stable gcc? Or only with the ~x86 gcc. What if the maintainer doesn't intend to stabilize the package until the ~x86 version of gcc goes stable? So I don't think the issue is as simple as either having xine-lib put out a warning about a particular gcc version, as that doesn't work in the general case. And putting the checks in portage doesn't seem to work very well either. The system as it is now actually seems to work about right...the vast majority of stable users upgrade to new versions of gcc as they come out, hopefully following the upgrade guide, and never see anything fail to build due to the gcc version. Others get informed via other means, and hopefully remember for the future. That won't be necessary. Things mostly works, and when they don't, users file a bug like the aforementioned one, which should result in that particular ebuild getting fixed, instead of the bug being marked INVALID. The thing is, "this particular ebuild" isn't actually broken. Or I guess if it is, then so are other ebuilds in the tree, since they probably won't build with old gcc versions either. Ok, most would probably build with gcc 3.3. And maybe even gcc 3.1. But 2.95?? Handling this at the ebuild level is just not a good solution for the general case. -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Dying on some CFLAGS instead of filtering them.
On 7/9/06, Denis Dupeyron <[EMAIL PROTECTED]> wrote: 2) If yes, are there any other flags that ebuilds should die on ? My (user) opinion is that ebuilds should not die on CFLAGS, at least not until per-package CFLAGS are implemented. Now if someone is crazy enough to enable -ffast-math globally or specifically for python in that situation, well, die, spin the cpu fan backwards, melt the hard disk down and sell it for scrap, whatever you want! -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Dying on some CFLAGS instead of filtering them.
On 7/10/06, Ned Ludd <[EMAIL PROTECTED]> wrote: per pkg cflags are here already it would fall under the per pkg env variables. Please forgive my stupidity, but the only place I could see to set a env var per package was /etc/portage/bashrc. Is that what you are referring to? -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Portage: missing pieces
On 7/10/06, Molle Bestefich <[EMAIL PROTECTED]> wrote: Richard Fish wrote: > of gcc doesn't seem very effecient. I can't see why it would not be efficient? I think it is an inefficient use of developer time. Do we really want gentoo devs spending their time figuring out what the minimum gcc version is for their packages, and then having very similar code duplicated in every ebuild in the tree? Is the problem really so serious that it requires that much effort? I am not saying that there should never be a check for a minimum gcc version...maybe if a large enough population of users is having a problem with a particular package because of gcc, then that package _should_ have a check with an appropriate "stop using obsolete gcc versions" message. But it should only be done in response to bug filings, and at the discretion of the package maintainer. And let's remember that this is a ~arch package. The expectations of people using ~arch is higher than for the stable tree. Indeed, you would probably see a completely different response if this was a problem using the ~x86 gcc to build the ~x86 xine-lib. > And putting the checks in portage doesn't seem to work very well > either. I fail to see how a test in the ebuild for the active GCC compiler version wouldn't work? But that isn't putting a check "in portage", it is adding it to the ebuilds. > The system as it is now actually seems to work about right... the > vast majority of stable users upgrade to new versions of gcc as they > come out I'd think that most users hadn't even run into this problem (yet), Agreed... because many source code maintainers strive to be able to compile with as old a version of GCC as possible.. or alternatively, because most users upgrade gcc to the current version before running into such problems. -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Portage: missing pieces
On 7/10/06, Molle Bestefich <[EMAIL PROTECTED]> wrote: It shouldn't even be _necessary_ to create bugs and receive advice from a living, breathing human being just to perform a system update. It isn't necessary. -user, the forums, IRC, all are monitored by "living, breathing human beings". -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Dying on some CFLAGS instead of filtering them.
On 7/10/06, Zac Medico <[EMAIL PROTECTED]> wrote: Richard Fish wrote: > On 7/10/06, Ned Ludd <[EMAIL PROTECTED]> wrote: >> per pkg cflags are here already it would fall under the per >> pkg env variables. > > Please forgive my stupidity, but the only place I could see to set a > env var per package was /etc/portage/bashrc. Is that what you are > referring to? You're close. There is now a per-package bashrc implementation included in $PORTDIR/profiles/base/profile.bashrc. It's kind of silly imo, when the user can simply put that same code in /etc/portage/bashrc, but this is how it is. :) Ah, thanks, I see it now. I have to say I dislike allowing this "backdoor" method to set CFLAGS, as they won't show up in emerge --info or emerge -pv . You'd have to see the actual build output to see the nasty flags, which you might not even think to ask for if a package builds fine but crashes randomly later. -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Dying on some CFLAGS instead of filtering them.
On 7/10/06, Simon Stelling <[EMAIL PROTECTED]> wrote: Sounds like your after bug 95741: http://bugs.gentoo.org/show_bug.cgi?id=95741 Yeah, that would be nice! :-) -Richard -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] aging ebuilds with unstable keywords - how can we help?
On 7/2/06, Daniel Ahlberg <[EMAIL PROTECTED]> wrote: Hi, This is an automatically created email message. http://gentoo.tamperd.net/stable has just been updated with 15968 ebuilds. A question [1] has come up on -user about why some ebuilds take so long to become stable for an arch. This isn't the old "when will we have KDE yesterday.3am" type question. In reviewing the above database, and the OP, it looks like a fair number of ebuilds that could/should be stable are not. Of particular concern to me are packages that: a) have no open bugs. b) are marked stable on some archs, but not others. c) may have only a single version available in portage. As an example, consider net-analyzer/etherape, which is "~amd64 ppc sparc x86", and has no open bugs (other than a version bump request), and only a single version available in portage to begin with. So my question is: is there anything that interested users can do to help here? I know we can file stabilization bugs, but I agree with Robert [1] that this should not be necessary in the normal case. Besides, do you _really_ want 16,000 new bug reports that say nothing more than "blah/foo works for me, please stabilize"! Is the problem a lack of time, devs, arch testers, or interested users? Regards, -Richard [1] http://thread.gmane.org/gmane.linux.gentoo.user/166565/focus=166565 -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: aging ebuilds with unstable keywords - how can we help?
On 7/27/06, Chris Gianelloni <[EMAIL PROTECTED]> wrote: Honestly, they shouldn't be stable. In fact, likely, many shouldn't be in the tree. We have way too many packages that are used solely by a small group of people sitting around the tree. These would be better served in official overlays, where they can be maintained by the interested parties (including users), rather than in the tree. This might be a good idea. I think some additional tools support would be useful, so that things like esearch could find things in the official overlays that are not actually present on the user's system. The "majority" of packages are also the ones that need more extensive testing. Sure, we could probably stabilize a bunch of the fringe packages that hardly anyone uses and it wouldn't affect anything. The majority of Aliz's database seems to be made up of these "fringe" packages. Many of which are stable on at least one arch already, or have only a single version in the tree anyway. Stabilizing these on the remaining archs that they support should not have any significant impact on the perceived overall quality of Gentoo. Another problem is that we don't *know* what is being run by our users. This is something that the Summer of Code project for a Gentoo Stats project should at least help with, as it will give us an insight into what is actually being used and what isn't. I hope that all users subscribe to this, it will only be useful with a large enough pool of people submitting their stats. It would also be great if Aliz's database incorporated this information when it becomes available. Seriously, folks. If you think that packages should be available faster, run ~arch. Test the packages. Report successes/failures to the maintainers. File stabilization bugs if your favorite package hasn't had another bug in 30 days and you've been using it. Basically, help out, rather than sitting back and complaining. Complaining helps nobody. Please don't interpret my original message as a complaint. It isn't. It is mostly a question of the process. My understanding of stabilization bugs was that they should be the exception, not the rule... that you might not be able to make a commitment, or even want to do so. However, every single bug report that you file *is* helping out... and every little bit helps. ...and I was wrong. Regards, -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Resignation
On 8/1/06, Carsten Lohrke <[EMAIL PROTECTED]> wrote: And that's why it has been announced as the best since sliced bred - urging all users to give it a try, but with the option to point with the finger on them, laughing "Ha, ha, you should have known dumb nuts.", later. Brett is absolutely right with his previous emails. Nothing that I have read about sunrise, either in GWN, their project pages, or the FAQ, has given me the impression that they are "urging all users to give it a try". There is certainly some advertising about it, as would be appropriate for any new Gentoo project. But nothing that I would say gives the slightest hint of "pushiness". -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Re: Masking practics
On 8/7/06, Enrico Weigelt <[EMAIL PROTECTED]> wrote: To be fair, do *you* actually look through *all* the emerge output if there's any "D" flag, without the risk of overlooking it someday ? Um, sorry, but users *should* be looking at the output of --pretend to get an idea of what portage wants to do to their systems. And not just for the 'D' either. Why can't emerge shout out some more verbose text ? Something really eye-catching ? Please don't. Portage already has enough messages that try to be "eye catching". I've only got two eyes after all... -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] gtk1 vs. gtk2
On 8/7/06, Enrico Weigelt <[EMAIL PROTECTED]> wrote: The assumption is wrong, gtk1 and gtk2 are incompatible versions of one library. They are completely different libraries, where one originally had been forked off the other one. Now they look similar, but are in no ways equal. Have you actually visited http://www.gtk.org??! The 2.0 release announcement, the migration guide, the download page, pretty much everything makes it clear that gtk2 is the newer version of the _same_ library, not a completely different project. Indeed, even their CVS repository only has a "gtk" directory, not "gtk1" and "gtk2". -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] use.force as a complement to use.mask in profiles
On 8/8/06, Jason Wever <[EMAIL PROTECTED]> wrote: This could allow for us to get rid of the nofoo use flag nomenclature that folks have been doing for functionality that is highly suggested to be on by default. Which would be fantastic IMO. -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] gtk1 vs. gtk2
On 8/7/06, Simon Stelling <[EMAIL PROTECTED]> wrote: What sort of problems? An example backing up your claims would be very nice. While I don't agree with Enrico that splitting up slotted packages is the right thing to do, there are some corner cases involving slots that portage (more specifically, depclean) doesn't deal with very well. http://thread.gmane.org/gmane.linux.gentoo.user/166809/focus=166809 http://bugs.gentoo.org/show_bug.cgi?id=67179 -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Proposal for advanced useflag-syntax
On 8/8/06, Enrico Weigelt <[EMAIL PROTECTED]> wrote: I think, modularized Xorg, as we have today, is far much better than the old monolithic thing. I think you are failing to realize that this isn't something that Gentoo did on it's own. Upstream went to separate packages, and Gentoo followed. Again, this is perfectly in line with "build what $upstream expects" philosophy. -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: mulltiib cruft: /emul
On 8/9/06, Mike Frysinger <[EMAIL PROTECTED]> wrote: i asked some others and they didnt get the e-mail either ... looks like our gentoo mail server is really starting to crash here ... http://bugs.gentoo.org/show_bug.cgi?id=141904 -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] use.force as a complement to use.mask in profiles
On 8/9/06, Brian Harring <[EMAIL PROTECTED]> wrote: General problem with use deps; *could* still implement it via seperating out use specific restrictions and generating the second logic statement above, but that's bit magic imo. Is it really "magic"? Admittedly I know exactly nothing about portage internals, but it seems to me that use-specific restrictions and version-specific restrictions are two completely separate concepts, and that you have to deal with them separately, regardless of whether you put the directives all in the same file or not. I see the normal case for gcc being something like: sys-devel/gcc[-cxx] =sys-devel/gcc-5.0 The above is very clear and obvious to me...all versions of gcc should be built with USE=cxx, and you should not try >= version 5.0. If you tried to combine those two concepts into a single directive, you would end up with: =sys-devel/gcc-5.0[-cxx] and I can think of at least 3 useful and logical interpretations of that single statement. This is quite different than the same token in an [R]DEPEND, where only one sane interpretation exists. So in fact I think that in the context of masking/unmasking packages, you must deal with the version and use flag masking separately. You should not even allow the combined syntax form, since it is so ambiguous. And if you do that, then the unmasking of use-specific or version-specific masks becomes quite obvious. Placing "sys-devel/gcc[-cxx]" in package.unmask has no effect on the _versions_ of gcc that are masked, as it isn't a version-specific directive. -Richard -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Why can't I re-open this bug??
http://bugs.gentoo.org/show_bug.cgi?id=67179 is marked RESOLVED/WORKSFORME, which according to the descriptions means that I should be able to re-open the bug. But there is no option to do so. Why? -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Xmms needs to die.
On 8/23/06, Josh Saddler <[EMAIL PROTECTED]> wrote: So, don't dump a product that's not even near alpha status on users. If we want to keep using software that's old, but works just fine, why force a really stupid switch? Saying xmms works "just fine" is a bit of stretch IMO. My most hated xmms bug was this one: http://bugs.xmms.org/show_bug.cgi?id=149 This bug is more than 5 years (!!) old. I've since moved on to amarok. -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Democracy: No silver bullet
On 9/2/06, Wiktor Wandachowicz <[EMAIL PROTECTED]> wrote: I suppose that there is a way that Gentoo can follow, only that its leaders, developers and users need to see it clearly. Is there a publicly visible page that contains current goals for new releases? Where all sub-project leaders could add their own goals, coherent with the general vision? I couldn't find it, but maybe I haven't looked in the right places? The problem I see is that for Gentoo the releases are not really useful milestones for most projects. A release is really significant for a few core packages, but what is the real downside for users if Xorg 7.2 is stabilized one week after a release? Outside of the fact that they have to compile it themselves instead of using the GRP package...not much that I see. For a distro like Ubuntu, a release is very significant, as it is the platform that users will be running for the next 6-18 months. Do you think Ubuntu roadmaps would be useful without being tied to a release? Or could project status reports (as discussed here recently) fit the same bill? Maybe I should raise such concerns to the User Representatives first No, definitely not. The point of user reps (of which I am one) is not to filter communications between devs and users, but to improve the communications between the two camps, among other things. If you want to bring an idea up here directly, nobody should respond with "talk to your userrep". -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Democracy: No silver bullet
On 9/3/06, Luis Francisco Araujo <[EMAIL PROTECTED]> wrote: Richard Fish wrote: > The problem I see is that for Gentoo the releases are not really > useful milestones for most projects. A release is really significant That is not a problem. That is a feature. A small clarification may be necessary here. I wasn't pointing to a problem with the way Gentoo evolves, but with the idea that releases could be useful milestones for project roadmaps. -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Democracy: No silver bullet
On 9/3/06, Chris Gianelloni <[EMAIL PROTECTED]> wrote: I really wish people would take the time to either ask the Release Engineering team, or learn how we work before they go off making accusations against us. There was no accusation there. I picked on X only for its popularity and relative ease of upgrading. But it is fair to say that I have no clue how releng actually works, and how you choose what to put in the snapshot, although I expect that there is much more to it than picking a random date on the calendar. -Richard -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Need guidance for updating CHOST
With the stabilization of the nptl-only glibc-2.4, many users are finding out that they installed their systems with CHOST=i386-pc-linux-gnu, and now need to either mask the new glibc, or figure out how to change their CHOST. I am not able to find any official guide on changing CHOST, and the information on the wiki and forums is, well, "confusing" at best. What I've basically been telling people is to: 1. update chost 2. run /usr/portage/scripts/bootstrap.sh 3. emerge -e system 4. emerge -e world But I don't have any great confidence that these instructions will work, and that someone won't end up needing to boot from their live CD to fix or re-install their systems, as I've never had to change CHOST myself. http://article.gmane.org/gmane.linux.gentoo.user/169894 So I really want to know what the official position is on CHOST changes, and whether the above instructions are reasonable. Obviously I'm looking specifically at i386->i686, and not i*86->x86_64. If we could get something in to GWN on this, that would be great. -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Need guidance for updating CHOST
On 9/12/06, Mike Frysinger <[EMAIL PROTECTED]> wrote: On Tuesday 12 September 2006 22:23, Richard Fish wrote: > What I've basically been telling people is to: please god stop telling people that ive given Wernfried Haas proper instructions, he just needs to write them up Is there a "Readers Digest" version you can give the userreps so we can at least answer the question properly when it comes up? -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RC_STRICT_NET_CHECKING or the net dependency
On 10/21/06, Roy Marples <[EMAIL PROTECTED]> wrote: RC_STRICT_NET_CHECKING is used in the init script depdency process, and quite frankly I'd like to punt it and replace it with ... rc-update! Yes, just put the init scripts that "net" should provide in your runlevel. boot contains net.lo by default and we also coldplug any net devices by default too. So can anyone think of any reasons why I cannot punt it? What becomes the equivalency of the "none" or "no" settings? In particular, if I have both wlan and eth0, but rarely at the same time, and I want net to be satisfied by either of them, RC_STRICT_NET_CHECKING=no accomplishes this. -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] The (lack of) use of herds
On 10/28/06, Marius Mauch <[EMAIL PROTECTED]> wrote: Well, I'd go further and question the whole herd concept. It also gives users the impression that there is an entire "team" of people maintaining a package,when in fact it might be just one or two people. -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] baselayout-1.13 going into ~ARCH soon
On 11/8/06, Roy Marples <[EMAIL PROTECTED]> wrote: On Monday 06 November 2006 16:53, Roy Marples wrote: > However, one issue is a concern. All baselayouts defined svcdir > in /etc/conf.d/rc which defines where we hold the state information of the > running services. This defaulted to /var/lib/init.d - which is bad as /var > could be on a different partition. > > In 1.13, we've removed the variable from /etc/conf.d/rc and it's now forced > to /lib/rcscripts/init.d which is safe as /lib is always on the same > partition as /. The 1.13 ebuild will copy across existing state data, this > is not the problem. However, downgrading back to 1.12 is a problem as > services may have been stop, started etc in the middle. > > One solution is to ensure that we only hold one copy of the state data and > move it to the new location. However, this does require altering the stable > ebuild as well. This is still an issue. What do people think - hack the 1.12 ebuilds and try and get an upgrade/downgrade path or just slap a large warning on the ebuild? How about as part of the upgrade, create a symlink from /var/lib/init.d to /lib/rcscripts/init.d? -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] What's the use of mozilla-launcher?
On 11/13/06, Thomas de Grenier de Latour <[EMAIL PROTECTED]> wrote: On Mon, 13 Nov 2006 10:02:25 +0100, Alexander Skwar Though, an other reason for not accepting this patch is that some websites may expect URL like this one, which relies on both encoded and raw commas: http://foo.bar/param-1,param-2%2Cwith%2Ccommas,param-3 Huh? Both of the following requests are equivalent: http://foo.bar/param-1,param-2%2Cwith%2Ccommas,param-3 http://foo.bar/param-1%2Cparam-2%2Cwith%2Ccommas%2Cparam-3 This is because web servers are required to process the URL and unescape *any* '%' sequences. So in both cases the server 'backend' is going to see a request for: param-1,param-2,with,commas,param-3 -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Versioning the tree
On 11/29/06, Stuart Herbert <[EMAIL PROTECTED]> wrote: Hi, On 11/29/06, Bo Ørsted Andresen <[EMAIL PROTECTED]> wrote: > Maybe you should read the replies you got the first time you made this claim > on this list [1]. Many thanks for these links. I didn't see your original email. Wanna add a comment here: :-) http://bugs.gentoo.org/show_bug.cgi?id=141904 -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: udev coldplugging and /etc/init.d/modules
On 12/1/06, Sven Köhler <[EMAIL PROTECTED]> wrote: Will udev rename the card eth1 to eth0 and the card eth0 to eth1? Yes. For this, I'd recommend running "/lib/udev/write_net_rules all_interfaces" and then edit /etc/udev/rules.d/70-persistent-net.rules to set the names like you want. I'd also recommend moving this thread to gentoo-user, since this really doesn't have much to do with gentoo development AFAICS. -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] Ideas for projects...
On 1/11/07, Chris Gianelloni <[EMAIL PROTECTED]> wrote: The Gentoo Council is looking for some ideas for some small projects that we could initiate that would help Gentoo. My idea would be to extend emaint to check package.keywords and package.use for obsolete flags, unnecessary atoms (like foo-1.2 in keywords when foo-1.3 is stable), atoms that don't match any current ebuild, and so on. -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] Ideas for projects...
On 1/11/07, Bo Ørsted Andresen <[EMAIL PROTECTED]> wrote: On Friday 12 January 2007 05:43, Richard Fish wrote: > My idea would be to extend emaint to check package.keywords and > package.use for obsolete flags, unnecessary atoms (like foo-1.2 in > keywords when foo-1.3 is stable), atoms that don't match any current > ebuild, and so on. app-portage/eix already does a lot of this... Sigh. I can't keep up with these changesnevermind :-( -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] newb question about emerge ...
Andrew Muraco wrote: >first of all (some people will disagree with me on this) > > I will ;-> ># emerge -avuDN world >does a much more through job, because it not only checks the packages >you have installed, > ...but only to correct this statement. It is more accurate to say that it checks all packages and dependancies of packages in world. That is frequently a subset of all installed packages. Most users won't understand the distinction though... Ian, consider this an invitation to come over to gentoo-user and ask us any questions you have about using Gentoo. -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] devfs is dead, let's move on
>>>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 2>&1 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!!! -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] devfs is dead, let's move on
Mike Frysinger wrote: >On Monday 11 July 2005 03:47 am, Martin Schlemmer wrote: > > >>On Sat, 2005-07-09 at 20:34 +0200, Richard Fish wrote: >> >> >>>for d in 0 1 2 3; do >>>/sbin/mdadm --assemble --config=partitions --auto=md >>>--super-minor=$d /dev/md$d >/dev/null 2>&1 >>>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? >> >> > >i dont see the point ... ive already fixed raidtools / mdadm to generate >device nodes before running since udev doesnt do it correctly/at all >-mike > > Oh, yes, I see that now. Sorry for the noise. -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Bug 80905
Frank Schafer wrote: I'm still on the kernel from the life-cd. The self compiled kernel has the highmem option set to off (I have only 1GB). I'm on x86 Intel Celeron M and have CHOST set to i686-pc-linux-gnu and CFLAGS="-O2 -march=pentium2" Um, why pentium2? The Celeron-M is the same core as a Pentium-M with less cache and lower clock speeds, so it seems to me that your -march should really be pentium-m. Anyway, I'll be back on gentoo-user if you want to discuss this thread more there. -Richard -- gentoo-dev@gentoo.org mailing list
