Re: [gentoo-dev] Request for changes to GLEP 41
Kurt Lieber wrote: * Drop the idea of giving the arch testers an email alias altogether I don't see what benefit this provides, to be honest. It's not much of a spiff and if someone is signing up to help with testing just for the email address, they're not here for the right reasons anyway. I agree that if somebody signs up for an email address, he's in the wrong place. This issue is not new, it's the same with beeing a dev. Becoming an AT isn't easier than becoming dev: You've got a probation period of 30 days, you've got to do the staff and ebuild quizzes. On a side note, I don't think anybody considers the worth of a @g.o address so high that he would sign up only to gain the email address. On the other side, giving the ATs a @g.o address does make sense. It might be easier for other arches, but at least the amd64 team has quite a lot of them, and it's really difficult to keep all the cryptic email addresses in mind. I have to check our AT-List about 3 times a week to see whether a bug was filed by an AT which I can trust and which I know of what his system looks like, or if it is just average Joe. So to me, an email alias would make things easier, with or without subdomain * Change @subdomain.gentoo.org to @gentoo.org. If we want to give them a spiff in recognition of their contribution to the project, give them the real thing. We do this today for any number of other non-developer groups, including GWN translators, documentation translators, etc. The original GLEP didn't foresee a subdomain, we actually wanted to give them a @g.o address, but it seemed that a lot of devs thought ATs were just a random bunch of incompetent users and as a consequence this, don't deserve a 'real' @g.o address. It made me quite sad, and I'm happy to see that I'm not the only one who thinks it would be better to not cut gentoo into different groups. However, the council asked for it, and so it was changed. And the council didn't ask for this on his own, they were just reflecting the majority of devs, so we'll have to accept that. * Create an entirely new domain I don't really like this, and it seems at least equally complicated as subdomains. If that's really the way we (as in Gentoo) want to go, I'll happily continue to look up the AT page 3 times a week. It's really not a THAT big issue. I just thought it would be nice to give the ATs a @g.o address, but it's really not essentially for me to work. Regards, -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] implementation details for GLEP 41
Kurt Lieber wrote: Because, in practice, this doesn't happen. Accounts (or, in this case, email addresses) stay around until someone gets enough of a bee under their bonnet to do somethig about it. Since there's no pain or cost for the AT/HT project lead, there's no reason for them to be vigilant about tracking activity. Plus, assuming we have a large number of these testers, how are people going to know whether or not one specific arch tester is active? That's not an acceptable solution. Uhm, does that implicitly mean there is such a tracking method for devs (where dev = dev/staff/whatever)? There are devs who don't have commit permissions to any cvs repo, how is their activity tracked? In the AT case it wouldn't be so hard to check their activity. !seen on IRC and a bugzilla query printing out bugs where they made a comment should be enough, IMHO. -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Request for changes to GLEP 41
Kurt Lieber wrote: However, the council asked for it, and so it was changed. And the council didn't ask for this on his own, they were just reflecting the majority of devs, so we'll have to accept that. If there's one thing I've learned in my tenure with this project is that there is no such thing as a majority of devs. We never have the majority agree on *anything*. So, I don't think that statement is accurate. Heh, that's a valid point. Not trying to be pedantic, but the notion that the majority of Gentoo support(s|ed) GLEP 41 is one that I believe to be incorrect. I've never said (that I think that) the majority supports GLEP 41. In fact, i think the vast majority bluntly doesn't care about it at all, as they aren't affected by it anyway. However, of those who gave feedback on the first draft, a majority said "we need a subdomain". Those who thought that a subdomain would be a bad idea didn't step up at that moment (including me), at least if I recall right. -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] implementation details for GLEP 41
Lance Albertson wrote: I see this as something that devrel would take care of since they already do this for developers. They already have the tools/access to the places for such things. Would rather not have another set of folks with that access. So do I. Hint: Homer Parker is a devrel member ;) -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Decision to remove stage1/2 from installation documentation
Harald van Dijk wrote: (Note that I'm not going to argue either way whether this is a good thing; I'm merely pointing out that the docs do say we're about choice.) You still can choose between stage3 and stage3+GRP without having to do anything but following the handbook :) -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] my apologies for the mess with this release of MySQL 5.0.16
Albert Hopkins wrote: Now all-of-the-sudden MySQL 5 is marked -amd64 so now I must downgrade. Is this intentional? read the changelog, it says: 24 Nov 2005; Jory A. Pratt <[EMAIL PROTECTED]> mysql-5.0.15.ebuild, mysql-5.0.16-r3.ebuild: version 5 does not work on clean install -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Misquoted in the GWN
Is there a good reason for sending this to -dev? You basically complain about the way the GWN authors handled the issue, so why do you tell it all the devs? It seems a bit like a lame attempt to blame them in public for their faults. Other than that, I agree with you. -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] UPGRADE ANNOUNCEMENT bugs.gentoo.org
Jakub Moc wrote: :0: * ^From:[EMAIL PROTECTED] /dev/null What a poor flame. Read through the flaming guide [1] twice, and try again. [1] It once was http://dev.gentoo.org/~chriswhite/flame.html, where has it gone? -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: pkg_{pre,post}inst misusage
Duncan wrote: It just sounds like it /could/ be dangerous to me. For some reason, I don't like the idea of something that could hose a system that badly! =8^\ It won't hose your system badly, since you've got /usr/lib64 listed in /etc/ld.so.conf. I agree it wouldn't be very nice though. -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] making dodoc and dohtml die when they fail and stricter is on
Diego 'Flameeyes' Pettenò wrote: I'm not sure if we're on the same page as far as the target audience of this change. The target audience is developers/those with strict in their features. Actually "stricter", and there are way too many people to put that in without knowing what that do... or is it a default nowadays, I'm not even sure. You're mixing up 'strict' with 'stricter'. -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Stupid USE defaults that need cleaning
Doug Goldstein wrote: the USE defaults are a bit INSANE... We need to get rid of some of this crap... ./default-linux/x86/2005.0/make.defaults:USE="alsa apm arts avi berkdb bitmap-fo nts crypt cups eds emboss encode fortran foomaticdb gdbm gif gnome gpm gstreamer gtk gtk2 imlib ipv6 jpeg kde libg++ libwww mad mikmod motif mp3 mpeg ncurses nls ogg oggvorbis opengl oss pam pdflib perl png python qt quicktime readline sdl spell ssl tcpd truetype truetype-fonts type1-fonts vorbis X xml2 xmms xv zlib" What about discussing this with the x86 arch team instead of -dev? IMO it's pretty much their decision what their defaults look like. -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for January
Hi, Lares Moreau wrote: need to have some form of Governance board. A board that doesn't worry about implementation details; a board that gives a long term vision to our project. This sounds very scary to me. Perhaps that's because I'm not sure how detailed such a plan would be. If our goal is... * "Make Gentoo the best distro 0n 73h p14n37" I can only say "what a lame marketing." * "Make Gentoo the most customizable distro" I'm pretty sure some users with silly ideas will ask us to implement the feature/whatever. If we reject their idea, they come up with something like "But Gentoo is all about customisation!!!111". (Actually, I was already confronted with such a situation in a real-world meeting, it was pretty annoying.) Also, this might not be where everybody wants to go. * "Let's implement $foo with $bar." Oh well, then we already have implementational details, which don't belong into a 'general goal'. I am a big believer is having a common goal to unite all people who work with an organization. I'm sorry If I am repeating myself, but I feel this is an issue that is vital to the continued success of Gentoo. If you replace 'organization' with 'project', I agree. There should be something like a common goal. However, I don't think Gentoo has to have one single goal. I'm pretty sure everybody of us has his own ideas where Gentoo should go and his own motivations which make him contribute. So why make generalisations? Just as an example: Taken from the project listing page: The developer relations Project is an effort to recruit, train, and manage developers for Gentoo's development structure. Now let's have a look at the three possible goals I stated above. * "Make the best distro 0n 73h p14n37" Obviously devrel's goal somehow supports this, as you can assume that people spend more time on Gentoo-related work if there is a good climate, but do you really need a global goal for such a trivial thing? I don't think so. * "Make Gentoo the most customizable distro" I can't see how devrel contributes anything to this goal. Oh, wait a sec, it doesn't contribute anything to Gentoo's goal? Let's drop it! * "Let's implement $foo with $bar." See above. My point is, either you have to generalize each project's goal to a real triviality or you have to define a goal which doesn't match some project's goals. Conclusion: Let it be. Regards, -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for January
Donnie Berkholz wrote: Not necessarily. I just wrote on my blog [1] about this, and got a constructive comment [2], which I'll talk a little about. Here's one example of a global goal: Reduce the learning curve of Gentoo and increase its usability. Sounds like a good idea, but as Ciaran already said, 'low learning curve' and 'great usability' are just opposite things. Also, it is *very* vague. This goal would involve a number of projects: - - Releng would work to ensure that installing Gentoo is as easy as possible. This is very vague too. Easy for who? Easy for a user who is too lazy to read docs and doesn't have any experience or easy for a sysadmin with plenty of experience trying to setting up Gentoo on a cluster with >100 boxes? I think this makes it pretty clear that there is not simply one implementation referring to one idea, but I'm afraid that these 'goals' could be misused to force a common direction instead of having multiple efforts addressing the same idea in different ways. - - The portage team could conduct usability studies of portage (perhaps with the help of openusability.org?). 'to conduct usability studies' sounds great, but it's IMHO not much more. I don't need studies to point out annoying things from a user perspective, I'm a user myself. Sure, feedback is good, but we already get feedback, in the form of bug reports. - - Others How do e.g. arches fit into this scheme? Yeah, sure, they make Gentoo easier to use because they keyword stuff. Great. I'm really glad somebody tells me why I am doing the stuff I've been doing for more than a year. So, the 'easy to learn/use' goal might be a goal that quite some projects already are trying to attain, but it really isn't *THE* goal for Gentoo, is it? -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Parallizing ebuilds - 'trivial' ebuilds
Duncan wrote: app-arch/pbzip2 It covers only bzip2, but proves that it can be done. I tend to like it for catalyst, since it helps a lot on SMP machines. Very cool! I didn't know that existed. It could be quite useful here on my dual Opteron. Thanks! For those who wondered what might be the purpose of that mail, re-read the last sentence with stress on the last three words. SCNR -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] learn to use RESTRICT=test people
Henrik Brix Andersen wrote: Can we have a RESTRICT=compile too, please? ;) Right after RESTRICT=lamejokes is implemented :P -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New developer: Patrick Mclean
Yo, welcome! (Not going to make a lame joke here, as I was the one who asked for a new RESTRICT feature ;)) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New developer: deltacow (Scott Stoddard)
[EMAIL PROTECTED] wrote: > I've got another new victim to present :) Scott is joining the amd64 > team that he's already been a part of for the last few months helping > out as an AT (arch tester). Welcome to the team, again ;) -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Request for Comment
(I think it would be better if you could post the text on the list, so people can easier cite the paragraphs they are referring to.) > I cite one situation which has actually led to system destruction: > > I was in need of a certain version of a library. A the moment I installed it > initially, this version was keyword masked for my architecture, since it was > not thoroughly tested. It worked perfectly anyway. Since it was without > issues, it became officially unmasked some time later and another version was > introduced, which was keyword masked because it didn't work at all on my > architecture. This one could be compiled, but really didn't work at all. Since > I didn't observe the new version introductions all the time, a slightly > careless world update gave me that version and left all programs depending on > the library in a non-working state. > > After all it was my fault, but on a resonably maintained system you will > always have a number of manually unmasked ebuilds, and you can't monitor them > all the time. This is why you should use exact versions in p.mask and p.unmask. If you do that you only get the minimum of masked packages, leading to minimal borkage. Now, over to the GLEP draft.. You make some very dangerous (partly wrong) assumptions in your GLEP. First of all, there's the assumption that we have the capacity to maintain such a fine graded masking scheme. We are currently mainly distinguishing between testing ~arch and stable arch. I can only speak for AMD64, but we have a currently ~100 packages that wait to go into the ~amd64 tree, 54 of them for longer than 30 days. Beside that, we have about 120 packages waiting to go into the stable tree. Now, if you'd increase the number of masking "stages" from two to 10, I can guarantee that this masking scheme would get completely useless. But the far more critical assumption you make is this one: You assume that once a package has been marked stable, it keeps beeing stable. You simply can't treat every package individually. A package marked stable back in 2004 with a status level -5 should be considered ultimatively stable if I understand your proposal right. But then GCC 3.4 is marked stable too, and, oh, look, it doesn't even compile!? Things depend on each other, in a very complex fashion. Whenever some behaviour in one package is changed, it is likely to break another one. Instead of giving us 10 different status levels, show us a way to avoid such problems in general. Part of the assumption above is also the fact that these keywords do not consider the profile the user is using. A package might work great for one profile but terribly break for another (deprecated) one. You can apply the same idea to eclasses. Basically it all bails down to this: Give me 10 environments and I give you 10 different ways to break the package. Regards, -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Duplicated entries in use.desc and use.local.desc
R Hill wrote: > a global USE flag duplicated in use.local.desc could be used to give specific > information about exactly what effect the flag has on a certain package, or if > for some reason it does differ slightly from the global meaning. > > global use flags (searching: doc) > > [-] doc - Adds extra documentation (API, Javadoc, etc) > > local use flags (searching: doc) > > [-] doc (app-examples/fakeapp): > Build user manuals in PDF format (requires ps2pdf) That'd be bad practice. When a new global use flag is made, the requirement is that all local use flags which would get united have *the same meaning*. If the meaning is the same, it doesn't make sense to mention it twice. If the meaning differs (slightly or not), it should get a local use flag. -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Bugzilla etiquette suggestions
Duncan wrote: > Consider this: INVALID is strong enough, under the wrong circumstances, > that it /could/ set an emotionally unstable user off, causing them to > commit suicide or something. I /know/ it was deeply depressing here, > that first time, altho the effect on me would have been to simply push me > back to Mandrake and cause me to become another anti-Gentoo activist, as I > wasn't already suicidal. Some people /might/ be! One never knows the > emotional state of someone filing a bug, so consider carefully the effect > INVALIDating the bug might possibly have on their entire life. Would > /you/ want that on your conscience, that it had been /your/ action, the > marking of that one last bug they filed as INVALID, that finally tipped > them over? I know I wouldn't! Are you being serious about this? I dont' find it particularly funny in case it's a joke. In case it's not, i find it ridiculous. If a person is that emotionally unstable that he'd commit suicide because of an INVALID resolution, he'd probably commit suicide everytime only the slightest negative event occurs too. I really feel sorry for those people who are depressive, but I wouldn't feel guilty because I closed a bug as INVALID instead of WORKSFORME. > Obviously, I like the idea of NOTABUG better, or consider using WORKSFORME > or WONTFIX. Those get the same general message across, without having the > implication of INVALIDating the user's bug, possibly/likely conveying the > message that they are not welcome as a Gentoo user, or worse yet to > someone already unstable, that their whole life is INVALID. NOTABUG sounds good, but as Ciaran said, we need another replacement for those bugs who really deserve it. If a user sticks -fvisibility=hidden into his CFLAGS (instead of CXXFLAGS), PLEASEGOAWAYKTHXBYE would be much more appropriate. -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Last rites: app-editors/gnotepad+
Jakub Moc wrote: > OMG, stop this crap and don't waste our time. Taken from http://dev.gentoo.org/~chriswhite/docs/flame.html: | "One thing is to frequently refer to "us" or "our". Pretend like people are | with you on this, so the uncertain ones will flock to your side! | | Code listing 1.6: Usage of plurality | | email: Stop wasting our time!" Apparently somebody did his homework ;) Kind regards, -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
Ciaran McCreesh wrote:
> On Tue, 28 Feb 2006 18:30:24 +0100 Jakub Moc <[EMAIL PROTECTED]> wrote:
> | OK, so kernel-2.eclass is abusing the slot as well, go scream on
> | kernel devs.
>
> No. kernel-2 installs sources, not an actual package.
Not exactly. The webapp stuff gets installed to /usr/share/webapps/${PN}/${PVR},
which is about the equivalent of /usr/src/linux because you will never point
your webserver to that directory. If you do, you're just dumb and deserve a
security flaw. webapp-config installs the packages to /var/www (equivalent of
/boot), where the webserver should make it available. So the SLOT="${PVR}" is
not an issue in this case.
--
Simon Stelling
Gentoo/AMD64 Operational Co-Lead
[EMAIL PROTECTED]
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA Roles v2
Ciaran McCreesh wrote: > On Thu, 02 Mar 2006 11:35:34 -0600 Lance Albertson > <[EMAIL PROTECTED]> wrote: > | QA shouldn't have to depend on the tools you use. > > Sure. However, the tree is far too large to check manually for many > things. If we were to do the Sekrit Tool's IUSE check manually, for > example, we'd still be in app-something, and would have missed many of > the screwups. Then fix the tool. I find it somehow ironic that a member of the QA team is trying to force a 'work-around' just to avoid fixing the source of the problem. -- Kind Regards, Simon Stelling Gentoo/AMD64 Member -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA Roles v2
Stuart Herbert wrote: It prevents emerge from crashing out in the middle of what could be a quite extensive build. Personally, I would rather rebuild one package to get desired functionality _after_ the emerge completes than have to fix the flags for that one package to be able to build everything else. This is why Ciaran and I opened a bug for the Portage team to get this handled up-front. Alas, I can't find the bug any more to reference it here :( bug 75936 -- Kind Regards, Simon Stelling Gentoo/AMD64 Member -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Re: Gratuitous useflaggery (doc and examples)
Thomas de Grenier de Latour wrote:
> post_src_install() { rm -rf ${D}usr/share/doc ; }
> This way, files will be deleted for real, before getting merged or
> added to your binary package.
No, that function never gets executed with binary packages. You probably meant
post_pkg_preinst.
--
Kind Regards,
Simon Stelling
Gentoo/AMD64 Member
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Change layout of distfiles
Alec Warner wrote:
Taking the earlier comment ( changing files only on the mirrors ) there
are no portage changes that are technically required. However, you'd
need to change about 1 ( random number I pulled out of my ass, but
there are many affected ) SRC_URI's to point to the new format, or
produce some sort of hack that translates between the two, and I
wouldn't be to fond of the latter effort, mostly because it would
probably rot in the tree for way too long ;)
I don't see how making portage translate mirror://gentoo/${P}.patch.bz2
to http://distfiles.gentoo.org/distfiles/${firstchar}/${P}.patch.bz2 is
worse than changing 1 SRC_URIs.
> And you need to modify policy for placing files on the mirrors, but
> thats not a portage problem either; from the portage POV the change is
> relatively seamless.
That should be a one-time effort for one person anyway. I guess it's not
too hard to make a script that puts the stuff in
toucan:/space/distfiles-local into the right dir.
--
Kind Regards,
Simon Stelling
Gentoo/AMD64 Member
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Change layout of distfiles
Daniel Ostrow wrote:
Hrm, /me thinks you are missing something there, almost the entire tree
doesn't explicitly state the mirror://gentoo SRC_URI, portage handles that
automatically. That being the case portage would have change so that the
automatic lookup was mirror://gentoo/${firstchar}/. So that is at least one
portage change I can think of being required
Huh? What does it state then? AFAIK ebuilds should ALWAYS use the
mirror:// URI when possible, and since this change is only affecting our
own mirrors, it is always possible.
Sure I can still see your point about needing to manually change the packages
that do explicitly state mirror://gentoo in their SRC_URI, but given that you
would have to do the above anyway
Huh?? My point was that we shouldn't have to change all those ebuilds
but instead just changing the mirror://gentoo-mapping.
--
Kind Regards,
Simon Stelling
Gentoo/AMD64 Member
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] IMPORTANT: OSL outage
Josh Saddler wrote: The mail server is not hosted by OSL. That server is somewhere in Italy, iirc. I'm still receiving -dev mail just fine. George Prowse wrote: I cant pick up my -dev emails because of this outage Congratulations. You made us all laugh. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Making the developer community more open
Bret Towe wrote: perhaps having some proxys of a sort that accept patchs and such from trusted users that would commit fixes to portage would help. similiar to the kernel format that way users can 'commit'/help out quickly without having to go thru the long process of becoming a dev Users can (and do) attach patches to any bug in bugzilla. When applying such patches, the committing dev hopefully checks the patch and makes sure it's clean, so he already is the kind of proxy you are asking for. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [last rites] media-gfx/sodipodi
Carsten Lohrke wrote: Who said a package gets masked before it gets removed? There is no such requirement in the ebuild policy. Come on. Is this a 'policy doesn't say I have to be sane' war? It's absolutely reasonable to p.mask a package that is pending for removal. That way you give the users a timeframe which they can search for alternative tools in. I don't know whether policy does state this or not, I don't care. It's not like you would get any bugs for a masked package. It's not like you would gain a lot of space because you freed up 3 ebuilds and a few digests. It's not like you would gain anything from removing it immediately. But those who use the package do gain a lot from you giving them a hint to search for alternatives. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [last rites] media-gfx/sodipodi
Carsten Lohrke wrote: This is not the case. At least unless the user actively looks at package.mask. Since Portage doesn't provide the information, this point is void. And even if - four weeks are a too long, imho. It does. Almost all users do emerge -u world when updating their system. Their portage will then tell them that the package is masked and why. So they DO get informed. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [last rites] media-gfx/sodipodi
# emerge -uD world Calculating world dependencies \ !!! All ebuilds that could satisfy "media-libs/mesa" have been masked. !!! One of the following masked packages is required to complete your request: - media-libs/mesa-6.4.2-r2 (masked by: package.mask) # Donnie Berkholz <[EMAIL PROTECTED]> (07 Aug 2005) # Modularized X, upstream release candidates For more information, see MASKED PACKAGES section in the emerge man page or refer to the Gentoo Handbook. (dependency required by "media-libs/jasper-1.701.0" [ebuild]) !!! Problem resolving dependencies for x11-misc/xscreensaver !!! Depgraph creation failed. Note that this has been a feature since a veeery long time. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] When will KDE 3.5 be marked as stable?
Stephen P. Becker wrote: I fail to see how pointing out a post was offtopic is mean. Rather, it will save that individual (and hopefully others) from making the same mistake in the future. Also, RTFM is absolutely the right answer more often than not. Otherwise, what is the point of having TFM in the first place? The amusement of those who spent a lot of time and effort writing it? That's not the problem. RTFM is never the right answer because 'please, RTM' is. Your mail pointing out that it was off-topic wasn't mean because it pointed out that fact, it was mean because it was written in a form that could have been much more friendlier. A message is usually more than just the information in it. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo theming during bootup
Carsten Lohrke wrote: On Friday 07 April 2006 04:26, Donnie Berkholz wrote: I also share the opinion that we shouldn't go against upstream wishes IRT branding, but if upstream encourages some fairly subtle branding along with keeping their name visible, I'm for it. There's a thread in gentoo-core from 2004 with regards to branding and the outcome was to refrain from it. I don't have a problem, when we do this for live iso's, but generally I strongly dislike it. Users don't choose their distro because of it, so it's just unnecessary bloat. And given that we tout Gentoo a meta distribution, encouraging others to build on it, there's no point forcing them to have to clean out the Gentoo brand, before they actually can use it. He said he wanted to make it easy, not forcing it. Or am I mistaken? -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Let portage symlink latest version of installed docs
Graham Murray wrote: Fabian Neumann <[EMAIL PROTECTED]> writes: What I'd like portage do to is to create a symlink to the latest version of a package's documentation. Just omitting the version number would of course not work as slotted packages may have multiple versions of docs installed. The first format coming to my mind would be: What would be even nicer would be if it could create and maintain an html index, for example at /usr/share/doc/index.html, to all package html documentation in a similar way to that which gnu info maintains the top level index to all info documentation on the system. This would be a very cool feature. Not for portage though. Portage is a package manager, and a package manager has nothing to do with generating indexes of HTML files. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] xorg-server 1.0.99/1.1 ABI break
Donnie Berkholz wrote: We are working to ensure the dependencies work as smoothly as possible, but I expect there will be some issues since it's difficult to require updates to all these optional drivers following an update to the server. wouldn't !< atoms solve that problem? -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo: State of the Union
rt of voting structure for all the developers (this doesn't mean requiring everyone to vote) and not just the council or devrel makes a lot of sense for most things. If I don't like how someone is acting within the project there should be a vote and then see if that person is kicked out. No trial, no anything besides a vote. And if I lose I have to deal with it. Either stay with the project, or find something else. This solution just works. Do you really think just because 60% of the voting devs agreed on something the other 40% will like it suddenly? Conflicts cannot be avoided, other than shooting down all people which don't share your point of view. Gentoo should be a fun environment. The previous paragraph should be taken as a last resort. Gentoo is fun to me. __Problem: GLEPs__ I dislike GLEPs. Usually they sit on the website for a long long time not doing anything. My vote (+1) is get rid of gleps and do everything by email and a vote by the developers. AFAIK, the board votes on the GLEPs. Bad Idea. It stifles things from getting done, and there is no ownership of who is going to implement the idea. I dislike them too. However, you're not addressing the issue IMHO. The problem is not that the council votes on them. The problem is much more that they are proposed to the whole dev community. Yes, you read right. It's mostly a good thing, but it is also a show stopper. I once wrote up a GLEP, sent it to the dev ml. Some people liked it, others wanted this or that changed. I re-submitted it, and they criticised this and that (which is a good thing!). So I fixed all the stuff they pointed out. In the end, I had a GLEP. But what I documented was not the idea I wanted to implement. So I lost interest. The GLEP got approved, but it's still not implemented. I don't know if anybody is working on it, I wont, because it's no longer what I once wanted to push forward. I would like it much more, if the people who are not affected by the GLEP wouldn't read it at all anyway. Whenever something is discussed I'm not involved in or affected by at all, I try to keep my mouth shut. I just trust the guys who submitted it to do their job the right way. And IMHO, this is exactly the point. Trust the others to do their job seriously and well. We don't need a whole dev community voting on an idea. Having everybody vote instead of a 7-headed council won't reduce politicalness. And that was what all your mail was about, in the end. __Problem: Voting__ Heh, really don't need to comment on that one anymore. ;) -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Last rites for dev-embedded/sdcc-cvs
Denis Dupeyron wrote: dev-embedded/sdcc-cvs will be masked right now, and then removed in a month or so if nobody complains. A pkg move might be wise to do, no? -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Heritage
Duncan wrote: I wondered about the "stupid" poster, myself. I don't quite have the sentimental value some seem to for him, but use in an error page and the like seems at least logical -- connected to something. However, I tried the above link and to my great disappointment, saw no Larry. Just a more or less normal 404 page. I surf with images off by default, so I thought that was it and turned them on, to no avail. Ahh... Turned off my filters that enforce light on dark, and tried again. There he is! Maybe he showed up the first time, but as I had enforced a dark background (and light text), I couldn't see him. Well, I doubt we can do anything about that. Turn off your filters :P Suggestion: Both he and the UFO guy have some value in Gentoo history, agreed. It's not always obvious to a new user what that might be, however. Whenever they are used, it might be a good idea to have them link to a history page explaining a bit about them, what they mean to Gentoo, how they became a part of Gentoo, etc. That would be a very good place IMO to put the traditional Larry with text and the like. As it is, the error page with just the Larry icon again leaves one with the question of just what it has to do with anything. Also, maybe a caption on the page. Larry is confused! Or something similar. If there's such a caption now, I missed it too. Is there really a story behind it that can be explained? If so, I'd be curious too, but I doubt there's a "real" story. Larry and the UFO guy just came up at some time, people got used to them and even liked them. Trying to explain why we have a cow's face on a 404 page or trying to explain why we like Larry is like trying to explain a love story: You just can't without everybody looking strange at you afterwards. Especially the UFO guy somehow lives from the mythos around it, explaining it would destroy it, at least that's my feeling. I'd certainly like the 'Larry is confused!' though, makes error pages a lot more personal. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
Ciaran McCreesh wrote: A large part of why Paludis exists is because I and several others were sick of waiting for three years for Portage to provide certain basic features. Which is really what this whole thread is all about... Sorry for being an ass, but could we *maybe* stop the constant portage bashing and turn this into an on-topic discussion? Thanks. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
Paul de Vrieze wrote: On Wednesday 17 May 2006 02:42, Stephen Bennett wrote: paludis/packages: -*>=sys-apps/portage-2.0.51.22 *sys-apps/paludis Is there any reason that portage and paludis can not live together. As this basically blocks any kind of migration or backwards compatibility I see this as a very serious roadblock to the acceptance of paludis as a supported (secondary) package manager. This is not a block. -*>=sys-apps/portage-2.0.51.22 means that the depedency on portage is no longer in the system class (base defines it as such). -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] new herd: vdr
Ned Ludd wrote: Whats wrong with the existing herd? Maybe the question should rather be: 'Will it allow you to manage the vdr-related packages and it's bugs easier and more efficient than before?' media-tv seems like the right place. I'd say that heavily depends on the answer of the question above. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] new herd: vdr
Simon Stelling wrote: 'Will it allow you to manage the vdr-related packages and it's bugs s/it's/its/ *sigh* -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] cmake.eclass
I have no clue what cmake is or what you are trying to, so I just
comment on a few other things I catched:
INHERITED="$INHERITED $ECLASS"
you don't need that
cmake_use_option() {
local USEFLAG="$1"; shift
local OPTION="$1"; shift
'local USEFLAG="$1" OPTION="$2" ; shift 2' reads better and is more
efficient
if [ -z "${OPTION}" ]; then
OPTION="WITH_${USEFLAG}"
fi
OPTION=${OPTION:-"WITH_${USEFLAG}"}
case $1 in
on|On|oN|ON)
'[oO][nN]') does the same, but i doubt anything beside on|ON will ever
be used.
off|ofF|oFf|oFF|Off|OfF|OFf|OFF)
same here:
[oO][fF][fF]) or simply off|OFF)
wE'rE nOt ThAt FrEaKy YoU kNoW ;)
cmake_configure() {
[...]
vecho cmake ${S} -DCMAKE_INSTALL_PREFIX=/usr $(cmake_use_option debug
CMAKE_BUILD_TYPE debugfull) $*
You can't use vecho yet. It's been introduced not long ago, stable
portage versions will just tell you that there is no `vecho'.
cmake_compile() {
cmake_install() {
aren't these meant to be cmake-src_compile/cmake-src_install?
--
Kind Regards,
Simon Stelling
Gentoo/AMD64 Developer
--
gentoo-dev@gentoo.org mailing list
[gentoo-dev] Funding Request
Hey all, To continue my development in an efficient way, I need a larger screen, particularly one with a resolution of 1024x3972. However, I can not afford the costs for such an investment, so I thought maybe the community could help me out. The reason it has to be a screen with exactly the mentioned resolution should become obvious after having a glance at: http://dev.gentoo.org/~blubb/funding.png Thanks in advance for your help, it is greatly appreciated! -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New eclass db-use
Paul de Vrieze wrote: It has not been. As far as I know such a requirement does not exist. In It does. The reason for it is pretty good, as kloeri mentioned: The API of an eclass may never change. See GLEP 33 for some horror scenarios [1] ;) [1] http://www.gentoo.org/proj/en/glep/glep-0033.html -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New eclass db-use
Paul de Vrieze wrote: Unfortunately this GLEP has not been implemented yet. This eclass would indeed be an ideal elib. Also, for this eclass the API requirements are not as strict as it is only intended to be used in unpack and compile stages. That's not my point. I mentioned it because it briefly shows why the current eclass system has its problems and why contacting -dev *before* adding a new eclass to the tree is essential. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Need a use-expanded TV_GRAB variable for xmltv
You forgot to mention which package uses the variable. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA subproject, TreeCleaners
Peter Volkov (pva) wrote: > But how can I search for removed ebuild in cvs? Is there any quick way > for such things? Use "site:sources.gentoo.org " as query, e.g. http://www.google.ch/search?q=site%3Asources.gentoo.org+sonar&btnG=Suche&meta= -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] A heretical thought? Blessing project sunrise as an almost-fork.
Jakub Moc wrote: > Getting tired of this thread, really. Talk about too much ado for > nothing. So, how about we stop wasting time, let people who are > interested to do something do it, and the rest of us can focus on more > important stuff than endless debates on mailing list and bothering > Gentoo Council - such as fixing current bugs and cleaning the dead cruft > in the tree, or fixing things not yet ported for modular X, or unported > for gcc-4.x, or whatever else? Damn liberal! [1] SCNR [1] http://dev.gentoo.org/~chriswhite/docs/flame.html#doc_chap1_pre1 -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] Useflags: qt, qt3, qt4?
I don't know all the details, but assuming no app supports qt3 and qt4 at the same time (i.e. you have two interfaces, one against each, which is pretty senseless), wouldn't something like qt? ( || (=x11-libs/qt-3* =x11-libs/qt-4*)) be the best solution? It would allow the maintainer to set a reasonable default, but in case the user only has the other version, it would take that one. If both are installed, the one that the maintainer deemed the best is chosen. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Bugzilla usage by gentoo-java's doing migration work
James Potts wrote: > There is a problem here for the java folks...Technically, their > migration-overlay is an overlay, and technically, that overlay is > currently unofficial. Therefore, technically, if it is against the > rules for projects and/or devs to use bugzilla for unofficial > overlays, then it is against the rules for the java team to use > bugzilla for their migration-overlay. > > As for the fact that the migration overlay is in the process of being > moved to o.g.o, "in the process of" doesn't mean it's already been > done, and until it's finished, the above statement stands. > > Props *and* apologies to the java team for this, but it looks like you > need to move the overlay *before* you finish the migration process > now. Question is, do we care about blindly following a policy that obviously was targetting at something completely different, or do we care about getting stuff done? There's nothing as unproductive as political correctness. Just my 0.02 SFr, -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Bugzilla usage by gentoo-java's doing migration work
James Potts wrote: I hate to put it to you this way, but if you give people an inch, they'll take a mile. Yes, political correctnes is unproductive. This is why decisions like the one made here need to be thought out better before being made. But once the decision is made, it should be applied equally, or not at all. "If you give people an inch, they'll take a mile." What's there to take? Freedom to work on stuff that they like to work on? As for the decision that led to this mess, I'd like to see it on the agenda for the next Council meeting. I really don't agree with it (or rather the way it was worded), and I can see others don't either. Unfortunately, I don't know if I have the authority to request this, since I'm not a dev. Right. So you agree with the intention, but not with the wording. This is exactly what I'm after. At least here in Europe, judges have to 'interprete' the law. They judge whether somebody is guilty or not based on the _intentions_ that are behind the law. If the law has flaws in its wording, nobody cares about it, because the _intentions_ are important, not the wording. This wording vs. intentions makes this whole thing really ridiculous. It makes you look like being nitpicking, even if you aren't. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Scientific Gentoo reorg: the proposal
George Shapovalov wrote: > sci-biology: 58 > rather large, may be worth splitting more, no particular suggestions yet > though, devs: > ribosome, blubb, corsair, j4rg0n, mcummings, sediener, pbienst, apokorny, > hansmi?, phosphan, lostlogic? i'm not maintaining anything, just keywording it for amd64. wouldn't it be easier to only list people that are in the sci herd? > sci-misc: 19 > Size is Ok, but, if we follow the idea, should probably stay under sci (herd) > devs: > cryos, hansmi?, phosphan, ribosome, kugelfang?, pbienst, blubb? same here -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] gentoo-dev-announce list
Stuart Herbert wrote: > But I also think you're over-exaggerating the situation by a long way, > sorry. I don't think so. As I understand it, it's not the amount of threads that makes the noise, it's mainly all the sub-sub-sub-sub-threads. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] gentoo-dev-announce list
Lance Albertson wrote: > I'd rather not create a -core-announce. The amount of times those types > of things come up on the list are rare. It would be easier to have an > standard subject heading (maybe ANNOUNCEMENT:) that people can use in > their filters. If devs start abusing it, then we'll vote them off the > island :) Bad idea, IMHO. That people are unable to change the subject line even when we're no longer discussing an upcoming project but choice of pet doesn't have to be proved again. Please, create a seperate announcement list, it would make things helluvalot nicer. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] arch-cruft in use.mask makes me angry
Mike Frysinger wrote: can someone remind me why our arch USE flags are in an "opt-out" system rather than "opt-in" ? instead of adding things like: to every non-x86 profile, why dont we mask these things in base/use.mask and then un-mask them in default-linux/x86 ? doesnt that make more sense ? I asked myself the same question about two weeks ago and made up a huge patch, I just didn't get around to verify it's really correct and complete. I can mail it to you if you want :) -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
Ciaran McCreesh wrote: Well, you're assuming that a) everyone's using a C compiler, b) that gcc has the slightest clue what it's doing, c) that the user has no problem using nasty hacks to regain control, d) that this information is only needed at compile time, e) that various gcc internal definitions won't change... You're adding a lot of complexity, and thus room for very weird breakages, to something that doesn't need it. as for... b) You kind of have to assume that when running a system that was compiled from ground up with gcc c) This is not about "regaining" control. Currently, users who want to cross-compile are screwed and need nasty use.mask-hacks to not end up with broken binaries. The inability to provide per-package CFLAGS is a missing feature in portage, it's got nothing to do with this issue. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
Ciaran McCreesh wrote: You can do it through bashrc. But then, if this is about working around Portage's annoying lack of sane cross compile handling, why not put a little effort into fixing it properly rather than a lot of effort into making the tree more complicated? Err, I think you're mixing up different things. How should portage be able to do sane cross compiling if you control the instruction sets through use flags which are blocked in profiles the build system is using? In fact, moving away from use flags over to the real(TM) solution is a step towards fixing the issue. Also, it doesn't make the tree more complicated. It is far more intuitive that supported instruction sets are used if the user doesn't explicitly wish not to than having some strange use flags that don't mean what they're named like. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
Curtis Napier wrote: > I could find a million threads in the forums supporting what Ciaran is > saying here. We have been told over and over and over until my head > feels bashed in that MMX/SSE, etc... are NOT TO BE PUT IN CFLAGS!! THAT > IS WHAT USE FLAGS ARE FOR > > Every developer who has ever commented on one of these threads has > always agreed with that. Put it in USE not CLFAGS. 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. > To change this behavior now after all this time would be crazy IMHO. It might have become some sort of policy, but if the policy doesn't have a god-like status. Sometimes it becomes obsolete and new (better) rules are put in place. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
Luca Barbato wrote: > Alternatives: > > - as PPC we provide a default cflags & use tuned per certain cpu > families using profiles, amd64 could provide a nocona profile that bans > 3dnow* useflags. Not really. There are athlon64s and opterons with and without sse3 support. The users who have an sse3-enabled CPU mostly stick -msse3 into their CFLAGS, as they expect the flag to do what it says. The problem is even worse for x86: You'd have to provide own profiles for: * i386 * pentium-mmx,k6 * athlon xp,pentium3 * pentium4,athlon64/opteron (starting from 'Paris' core),celeron (starting from 'willamette' core) * celeron D/M, core solo/duo,core 2 duo, core 2 extreme,athlon64 (starting from venice stepping E3 or san diego stepping E4), athlon64 X2, athlon64 FX (starting from san diego stepping E4), sempron (starting from palermo stepping E3), pentium4 (starting from 'prescott') etc... and now you want to let your pentium4(paris)-server, which is running 24/7, compile a binpkg for your pentium4(prescott), using SSE3 have fun 8-) > - as before but provide an eclass that uses flameeyes infrastructure to > warn about possible mismatch between what the cflags could do and what > you expect to obtain eg: -mcpu=nocona use 3dnow would issue a warning > and disable it I'm not sure whether I understand this correctly. If we use flameeyes logic anyway, why keeping the use flags? -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
Martin Schlemmer wrote: > 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. There is a -march=nocona, and it doesn't define __3dNOW__. > 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 ? I don't understand this. Why is '-march=i686 -m3dnow' bad if it results in the same thing as '-march=athlon-xp'? I guess I'm just lacking facts here, so please give me a hint :) -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
Marius Mauch 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. > > Huh? What do you assume users think that CFLAGS=-msse does? > I know some people get confused by the mmx/sse/whatever use flags, but > I've never seen anybody assuming that CFLAGS determine if a patch > should be applied/configure switch enabled. > (I'm not arguing about the proposal itself here, just this argument is > bullshit) Well, that was the best argument I could think of. I wasn't aware of the breakage in old compilers like
Re: [gentoo-dev] Dying on some CFLAGS instead of filtering them.
Richard Fish wrote: > 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. Sounds like your after bug 95741: http://bugs.gentoo.org/show_bug.cgi?id=95741 -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] xpdf status
[EMAIL PROTECTED] wrote: > I really would like to see back the upstream version, what do you think? I don't think anybody would mind you putting them into the tree again. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] 'mad' vs 'mp3' USE flags
Diego 'Flameeyes' Pettenò wrote: > On Friday 14 July 2006 06:03, Daniel Watkins wrote: >> Is there a rationale behind this decision? > On some systems libmad does not work and has to be masked, if I called it > mp3, > it couldn't be use.masked or all the mp3 supports, even when not provided by > libmad, would have been removed. > > Per-package use.mask is not here for another year and in the mean time I > needed a working solution, this is it. In the specific case of xine-lib, the mad USE flag can simply be replaced with mp3 because mips, which is the only arch that has the mad USE flag in use.mask, doesn't have any version keyworded. Of course that doesn't fix the general problem, but at least it would save time for a lot of users... -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] making the firefox USE flag a global one
Hi all, I just noticed that the USE flag 'firefox' is a local one. I think it should be global, though: $ grep :firefox use.local.desc app-office/openoffice:firefox - Add Firefox support dev-haskell/gtk2hs:firefox - Build the Mozilla Embeded Component against firefox rather than mozilla dev-java/swt:firefox - Build the Mozilla Embeded Component against firefox rather than mozilla dev-python/gnome-python-extras:firefox - allow building against firefox libs dev-ruby/ruby-gtkmozembed:firefox - compile against Firefox instead of Mozilla dev-util/devhelp:firefox - Build against firefox rather than mozilla dev-util/eclipse-sdk:firefox - Build against firefox rather than mozilla gnome-extra/evolution-data-server:firefox - Use Firefox's NSS/NSPR libraries if SSL is enabled gnome-extra/yelp:firefox - Build against firefox instead of mozilla mail-client/evolution:firefox - Use Firefox's NSS/NSPR libraries if SSL is enabled media-video/totem:firefox - Build against Firefox instead of Seamonkey net-news/liferea:firefox - Build against Firefox instead of Mozilla net-www/mozplugger:firefox - Depend on firefox rather than seamonkey www-client/epiphany-extensions:firefox - build against firefox instead of mozilla www-client/epiphany:firefox - build against firefox instead of mozilla www-client/galeon:firefox - build against firefox instead of mozilla www-client/kazehakase-cvs:firefox - Use firefox's Gecko engine. www-client/kazehakase:firefox - Use firefox's Gecko engine. If nobody objects, I'd like to push that change through in two weeks. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] making the firefox USE flag a global one
Alec Warner wrote: > Except these aren't doing the same thing. > > "add firefox support" I have yet to find out what this does. > "use firefox's NSS/NSPR" This is a stale entry, no eds ebuild has a firefox flag anymore as it was removed some time ago. > "use firefox's Gecko Engine" This is actually "build against firefox instead of mozilla/seamonkey". > sooo..which one is the global flag for? :) All of them, except if the openoffice one turn out to have a different meaning than '"build against firefox instead of mozilla/seamonkey"'. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [Fwd: [gentoo-portage-dev] Breakout etc-update, dispatch-conf]
Alec Warner wrote: > In an attempt to receive more comments and to request comments on the > virtual/config-manager, I have forwarded this mail here. Please comment > + point out weird things wrong. I'd prefer to make either dispatch-conf > or cfg-update the default for the virtual, but I am definately open to > discussion on that. > > A bunch of bugs have been fixed with both of these lately, anyone > against splitting them out, please speak up now, otherwise I will split > them out later this week and portage will depend on some nasty virtual > whose name I have not come up with yet ( new style virtual ). If you don't scream loud, I will go and split them out, using virtual/configfile-manager. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] making the firefox USE flag a global one
Hanno Böck wrote: > Am Dienstag, 18. Juli 2006 14:06 schrieb Simon Stelling: >> If nobody objects, I'd like to push that change through in two weeks. > > As most of then are "use ff instead of mozilla" and that'll be deprecated in > favour of using ff by default and seamonkey by seamonkey useflag, I don't > think this makes sense. I can't follow, sorry. Sure, the new flag will be 'build against ff instead of seamonkey', but then it's still valid use, no? -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New category: net-voip
Jakub Moc wrote: >>> Erm... Portage updates these automatically. >> as .cfg_** files. The end user still has to run an etc-update and >> pray that it was not a file he/she had in masking. > > Err, no? You don't need to run etc-update/dispatch-conf to get those > updated on package moves. Err, yes. At least here you do. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: proxy-dev (an alternative to sunrise?)
Enrico Weigelt wrote: > The gentoo devs currently do much of the upstream's work. > Fixing bugs or even adding new stuff which does not directly have to > do w/ gentoo should be done exlusively by the upstream. This is not really a problem. Fixing bugs is what I enjoy after all, this is the interesting stuff. Spending hours on one broken build system is far more interesting than writing 100 ebuilds. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Resignation
Ciaran McCreesh wrote: > Good intentions and trying to be helpful don't keep users or > developers. Screwups lose users and developers. It's really funny to hear such a statement from a person who made several great developers leave the project. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Keep Sunrise... But not Here
Michael Crute wrote: > Thoughts anyone? That's all been done. That's why the last thread's title has the word 'resumed' in it, after all :P -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for August
Jakub Moc wrote: Broken bugzilla affects every ebuild dev, affects GDP, affects bug wranglers, affects anyone else who's using it to track outstanding project issues. How is this continuous borkage not a global issue that council should discuss? What is there to discuss? Do you expect them to say 'bugzilla shall be fix0rd!'? What would that change in reality? I, (and I guess so does solar) fail to see what the council could effectively do in regard to this matter. You should probably elaborate on that. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Proposal for advanced useflag-syntax
Enrico Weigelt wrote: For example: mplayer It has it's gui-less player and an gtk-based frontend in one package. We should split this into two packages: mplayer and gmplayer. The chances to get this done in the upstream *before* some major distro like gentoo does the split by its own are quite low. Not quite true. In reality, they're just the same. mplayer simply checks whether it was called as mplayer or gmplayer. So you not only have two programs in one package, but even in one binary. Changing this behaviour has nothing to do with packaging and is really upstream's responsibility, IMHO. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for August
Lance Albertson wrote: kashani wrote: Chris Bainbridge wrote: I'm curious what the problem is with bugzilla and it's db interactions? You're suggesting a specific issue rather than general db performance issues like fs, io scheduling, raid1, hyperthreads, etc.? It's most likely related to Bugzilla using MyISAM tables by default which is fine in a small environment. However as concurrency grows along with table size those full table locks begin to cause issues. Additionally most www-apps are not known for their well thought out db schema. Performance of the underlying hardware plays a part, but can be overshadowed pretty quickly by query and table inefficiencies. The usual fix without touching the internals of the software is doing master/slave replication and allowing the selects to happen on the slave and writes on the master. However you would need to change most of the queries to point to the slave server which is usually not trivial. It sounds like this is the path the Infra team is pursuing. Thanks a lot for this explanation. 1++ You got it right :-) I'm not out to blame anybody, but if infra had communicated what the problem exactly is once they found it out, you wouldn't have ended up with all those "I'm sick and tired of your "we're working on it"". Asking people for patience is easy, but it's hard to swallow when you don't understand what the problem is at all. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] gtk1 vs. gtk2
You've already been told it's a non-issue, but here's why: http://devmanual.gentoo.org/general-concepts/slotting/index.html -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] gtk1 vs. gtk2
Enrico Weigelt wrote: Oh hell, this can't be serious ! It is. It mixes up diffent things to one and just introduces new problems instead of solving anything. I could live with that, if it's for supporting different ABIs, but it obviously isn't. What sort of problems? An example backing up your claims would be very nice. gtk1 and gtk2 are completely different packages, they're not compatible. So why should they be one package ? Just because they share some ideas and the name ?! Yes. Why not, after all? For example, there are lots of packages requiring gtk1, other gtk2. As long as dependencies don't cope the slot cleanly, slotting is utterly useless. =x11-libs/gtk+-1.2* >x11-libs/gtk+-2 do a decent job. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] PDA herd call for assistance
Enrico Weigelt wrote: I'm going to take a deeper look at the synce stuff in a few days, so I'll probably have to fix a lot of things there anyways. You may add me to your maillist(s) and CC me to bugs at will. http://bugs.gentoo.org/userprefs.cgi?tab=email has a 'Users to watch:' input field. Just add the PDA herd's email address there and you will receive all their bug mails, which has the advantage of not causing a lot of bugzi spam. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Masking practics
Enrico Weigelt wrote: My problem still seems unsolved (or did I miss something) ? Lets say, if I've, installed foo-1.1, and it gets masked due some bug(s), but 1.0 isn't, I want to get informed with an big fat warning, *before* anything actually done, ie. [...] # WARNING: installed package foo-1.1 has been masked and would # be downgraded: # [...] An fully-automatic downgrade should *never* downgrade anything. This is too dangerous, because essential features can get lost. Again, my bugzilla example: assuming 2.22 will be unmasked some day and I installed it w/ postgres support. Now there are some bugs found, but not fixed fast enough, so it gets masked. I run an update w/o knowing that it downgrades, and my whole bugzilla hosting is suddenly broken. Do you consider this as stability, seriously ?! If your bugzilla hosting breaks with lower versions, then the ebuild contains a RDEPEND="postgres? ( >=dev-db/postgresql-2.22 )". Now if >=postgresql-2.22 gets masked, portage will bail out with an error because it can't find a valid dependency tree. This will cause the comment above the masking line in p.mask to be shown. You can then decide whether the breakage affects you or not and depending on that unmask it locally or remove your bugzilla installation. If there is a bugzilla-ebuild which works with downgraded too, leaving you with a working bugzilla. I can't quite see the massive problem. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] SearchSecurity.com: "Linux patch problems: Your distro may vary"
Wolfram Schlich wrote: Any comments or thoughts about this? Does the security team currently face serious problems that need to be solved, be it inside or outside the security team? As far as I know large chunks of time get lost when waiting for maintainers and arch teams to do their work. I don't see how the security team could do much about this; except maybe giving them a yearly budget to travel around the world and slap people who seem to ignore security bugs. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] gtk1 vs. gtk2
Enrico Weigelt wrote: What sort of problems? An example backing up your claims would be very nice. + Additional complexity (slotting) is necessary, so additional changes of bugs. Oh please, this is so lame. That feature has been in existance for long enough to be proven useful and not faulty. The "higher probability of problems" is really not the best argument when discussing features that have been around for an incredible long time. + Package maintainers have to both take care of slots *and* version number *ranges* "taking care" takes you one line. I already gave you both dependency strings. Now guess what: If they were two packages, it would take you one line too! OMG! + Different packages are treated as equal, produces confusion Aside from that guy who opened bug 143063 [1] I have yet to see anybody who got confused by this behaviour. So, why don't you consider libxml and libxml2 equal packages ? Because that's the way upstream names them. As said: you have to take care of version *ranges*. Adds additional complexity. BTW: how do you enforce an minimum gtk1 version ? You know that this wouldn't even make sense, as - you've pointed it out so many times - the API is incompatible. So, I'm asking you one last time: Do you have any actual good reasons to not package things the way upstream does it? [1] http://bugs.gentoo.org/show_bug.cgi?id=143063 -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] gtk1 vs. gtk2
Enrico Weigelt wrote: Yes, I'll file a bug on the whole gtk issue and all packages using this ugly hacks. You can save your time. Really. And vastly more important, save our bug-wrangler's time. You've already filed a bug. It was closed as INVALID, and except for you nobody in this thread agreed with you. It won't get anywhere, because you're the only one pushing for that change. I can assure you that every single bug for every package you file will get marked as DUPLICATION of the first bug, which was closed as INVALID. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] gtk1 vs. gtk2
Enrico Weigelt wrote: If we changed the name of a package every time there was an API break, we would literally have thousands of packages in the tree that essentially do the same thing, just with different API's. Yes, but it would be much more cleaner. Everyone would see what actually happens. Now its hidden from the user, but not changing the fact that they're different. __ ___ _ _ __ _ ___ ___ /_ /_ | | (_) | / / | | | | _/_ | |__ \ __ _| || |__| |_| |__ ___ / /_ _| |_| | ___| |_ __| |) | \ \/ / || |__| | | '_ \/ __| / / _` | __| |/ /_ _|__| | / / > <| || | | | | |_) \__ \/ / (_| | |_| < |_|| |_ / /_ /_/\_\_||_| |_|_|_.__/|___/_/ \__, |\__|_|\_\|_(_)| __/ | |___/ Tell me, where is it actually hidden? I tend to avoid such unstable packages. Nice for you. We don't care. Thanks for the warning of neon, so I'll never even think of using it. Nice for you. We don't care. Of course. They're different packages. They have the same name. Different versions. That's how it is upstream and how it should be. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] use.force as a complement to use.mask in profiles
Peter Gordon wrote: Zac Medico wrote: The difference with use.force is that it prevents flags, that are deemed extremely important, from being accidentally disabled by the user. If they were so "extremely important" then they would not be optional, and hence not even be USE flags at all, no? Or am I missing something? Yes. Some flags are extremely important to certain users (read: profiles) but not to others. In some cases the USE flag are so extremely important because they are more or less what makes the whole profile. Think of 'selinux' or 'multilib'. http://article.gmane.org/gmane.linux.gentoo.portage.devel/2316 -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Proposal for advanced useflag-syntax
Enrico Weigelt wrote: foo/bar gui=gtk blah/blubb gui=qt2 bleh/enrico gui=qt4 SCNR -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] client+server packages - build which one?
Enrico Weigelt wrote: But it's very unclear. Ask around in the user list, who knows what "minimal" in this special case means (without extra reading the documentation). Such useflags should be obvious, but "minimal" isnt. "without extra reading the documentation"? Documentation is there to be read! That being said, server/client flags are nice, but not really applicable until we have per-package default USE flags, which is soon I hope. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Re: Masking practics
Joshua Nichols wrote: While it is columnar, the D is in a dark blue font. If you happen to be using a dark background, there is extremely little contrast. Perhaps it could be a different color that would stick out in both light and dark backgrounds? There is color-mapping support in portage 2.1, i guess it could be done with that. Also something that has always bugged me... isn't the U supposed to be for upgrade and the D for downgrade? In this case, it would make sense to only show the D when downgrades will occur, and not both, wouldn't it? I always interpreted it as 'update' instead of 'upgrade'. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: AT emerge info cruft > attachments to [STABLE] bugs
Being an amd64 dev, I want to basically add a 'me too!' here. I think it's not necessary to add the --info output when all worked well, though, if instead the output of -pv $PN was given. Except when there was a failure reported before, because then we need it to compare the two. Regarding the inline vs. attachment issue, I'd vote for inline too. Just my 0.05 CHF, -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: AT emerge info cruft > attachments on bugs.g.o
Jeroen Roovers wrote: > On a minor note, I'd also like to see bug reporters use canonical > package names in bug descriptions, including the category (and > preferably the specific version, not some >=foo-3*!!!one, not to > mention specifying no version at all). Including the category means > arch devs won't need to guess/discover which of a few hundred categories > a package is meant to reside in. First off, I second that. Second, here's how you still get where you want without looking up the category: $ cd gentoo-x86/*/foo This of course doesn't work if there are multiple packages with the same name in different categories, but if a package maintainer doesn't specify the category in such a case, he should be hit anyway ;P -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] User support system [WAS: Sunrise contemplations]
Enrico Weigelt wrote: I already suggested an bug-reporting tool, which automatically collects all the necessary data, several weeks ago. This tool is simply called by commandline and asks the users several questions. Then it files an bug with some certain syntax and uploads necessary information (emerge --info, pkg-db extracts, ...). That somehow looks like the guided file-a-new-bug form we had some time ago. Personally, I'd rather have it in bugzilla, because a shell tool takes the user away from bugzilla, and after all you have to search for existing bugs anyway, so you already are on bugzilla. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo-Status
Lance Albertson wrote: > Frankly, the attitude of a lot devs lately towards infra > have made many of us not want to communicate what we're doing. If we're I can understand that, partly. But that won't help anyone. Assuming you're not thinking *nobody* outside infra does respect you, try to write the status report for those who you feel respected by. It will even make those happy who didn't respect you and maybe even make them respect you again because they see that a genuine effort is made to solve a problem that buggers them. > not getting respected by you, then why should we respect you back? At > least for me personally, I don't hold any personal grudges against > anyone unless you stop respecting the group and/or me. Personally, I > think the larger problem in Gentoo itself is the attitudes of many > developers. Communication aside, it means nothing if we can't deal with > each other in a semi-professional manner. It seems like mini-flame > explosions on irc/email have happened more frequently in the last few > months. This is just going to make the group implode if nothing is done > about it. Respect is something that should be applied unconditionally, in my opinion. The "you don't so I won't" attitude gets us nowhere. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo-Status
Lance Albertson wrote: > I generally try to do that, but after the 10th time the person doesn't > respect you and demands things from you, its kind of hard to keep that > mentality. Well, one out of >300. Simply do it for someone else then ;) -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Portage Sets
Chris White wrote: > y'all are killing me So are you: > -- > Chris White > Gentoo Developer aka: > ChrisWhite > cpw > ChrisWhite|Work > WhiteChocolate > VanillaWhite > Whitey > WhiteLight > WhiteCheese > WhiteSugar > WhiteButter > WhiteWall > WhiteLemon > WhiteApple > WhiteBlanket > WhiteEnergy > WhiteWhite > go shorten your sig ChrisWhite head -n4 $(<~/.sig) > ~/.sig -- Kind Regards, Simon Stelling Gentoo/AMD64 developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 39 compliance
Wernfried Haas wrote: > As far i am concerned, i find seperate sections quite good as it's a > clear solution as it's easy to see who is an official Gentoo monkey > who did all the quiz stuff etc. May be subject to personal taste though. Well, yeah, it just makes we wonder what the fuck an ebuild quiz has to do with a bash framework, as in this example? Really, the ebuild quiz is cool for ebuild maintainers, so you at least know about some common mistakes, but it does nothing beyond that. Simply spoken: You can use them as indicator for _nothing_, i.e. it's completely unimportant whether you did the quizzes or not. IMO, at least. -- Kind Regards, Simon Stelling Gentoo/AMD64 developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Suggestion: Globalness of some USE flags
Steve Dibb wrote: > And the descriptions seem to be pretty much the same in all of them from > use.local.desc I think we agreed at least 3 times on that the logrotate use flag shouldn't exist at all because those files add <4kb to the package. About the udev, there's one package that doesn't share the effect: sys-apps/pcmciautils:udev - Install as an udev helper instead of a hotplug helper Which is different from the other 5 "Enable udev rules file installation". -- Kind Regards, Simon Stelling Gentoo/AMD64 developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: The Age of the Universe
Edgar Hucek wrote: > Just a side hint. Try to enable all flags at the first cimpile time would > reduce trys drasticaly ;) If you had a look at the php ebuild (just because we took it as example here), you'd see that it is a bit more complicated than just enabling everything to have everything tested. > So you say a developer cant't test all useflags? That is a strange > message from you. How can a developer garantee that his package is correct. He can't. That's what we're saying. Nobody said we can, nor do, nor want to. > Realy funny, i only hear exuses but no real solution for the problem. You have heard the real solution for the specific problems you pointed out: File a bug. You have also heard why it is impossible to guarantee that it simply works. > The fact is, that long outstanding bugs are simple ignored. If a useflag > would only apply to one package it could be ok, but not when the same > useflag is in other packages and makes this one useflag for the "normal user" > unusable. man portage: package.use Per-package USE flags. Useful for tracking local USE flags or for enabling USE flags for certain packages only. Perhaps you develop GTK and thus you want documen- tation for it, but you don't want documentation for QT. Easy as pie my friend! Format: - comments begin with # - one DEPEND atom per line with space-delimited USE flags Example: # turn on docs for GTK 2.x =x11-libs/gtk+-2* doc # disable mysql support for QT x11-libs/qt -mysql Know your tools, man. -- Kind Regards, Simon Stelling Gentoo/AMD64 developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: The Age of the Universe
Edgar Hucek wrote: > I know my tools but not necessarly the normal user who wanna use gentoo > and is ending frustrated. If the users are too lazy to read the documentation, why should we care about them? -- Kind Regards, Simon Stelling Gentoo/AMD64 developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: The Age of the Universe
Wiktor Wandachowicz wrote: >> If the users are too lazy to read the documentation, why should we care >> about them? > > Because we risk that Gentoo may receive the "user-UN-friendly" label and > become irrelevant in the long run? I know it ain't gonna happen, but still. Well, that might be the case, but then, do we really care? I'm more than glad if people who are too lazy to read the docs don't bugger me with their issues which they could easily avoid if they'd have read the docs. > You OTOH bring to the table a fact that developers shouldn't be that much > concerned with the stabilization/testing of packages before new release of > installation media. But new releases *ARE* targeted specifically at new users > and it's them who suffer the most. Next to it is the reputation of Gentoo and > its developers. Edgar's call was targeted mostly at releng and QA teams, who > should poke developers to decrease number of similar problems. I never said that, and I don't mean it either. We are concerned about testing, but we can only do as much as human can do. Gentoo gives you much flexibility. We can workaround the issue by masking the accessibility flag for example, but that wouldn't be all that great, because it only hides the problem, and it doesn't help those disabled people either. > I maintain a bunch of Debian/sparc, Debian/i386, Gentoo/amd64, Gentoo/x86, > Solaris/sparc, Ubuntu/i686 boxes and mind you, out-of-box experience at > install time means A LOT. I know that. The first Gentoo CD I threw away just after booting it because I couldn't figure out how to launch the setup app. "Wow, what a crappy shit." I thought. Seriously, I don't want such people to use the distro. It's not the right one for them. (On a sidenote, should be quite obvious that in a second try I did figure out how to install Gentoo and kind of changed my mind ;)) > More respect to the users => more respect to Gentoo. I'm not sure how to parse that, but in case you mean that Gentoo gets more popular when we make the out-of-the-box-experience better, then I agree. I do not agree that this is something I want, though, because to achieve that you either need a) much more resources or b) drop some of the flexibility we offer. a) is hard to get and b) sucks. I'd rather have other people think Gentoo is a bad distro but be happy with it myself. Yes, I am a selfish pig. -- Kind Regards, Simon Stelling Gentoo/AMD64 developer -- gentoo-dev@gentoo.org mailing list
