Re: [gentoo-dev] [RFC] QA Team's role
Stephen P. Becker wrote: > Grant Goodyear wrote: > >>Ciaran McCreesh wrote: >> >>>My point is that that's a nasty QA bug that's relying upon input from >>>Stuart to be fixed. Whilst that one's still alive, I'm not going to go >>>around filing more similar "breaks non-interactively" bugs because the >>>discussion will just get repeated over and over. >> >>Huh? I just read through the bug, and it actually appears to be >>resolved pending Chris' testing w/ the needed USE flags added to the >>various profiles. I'll admit that the fix is inelegant, but I'm missing >>where it's waiting upon Stuart for additional info. Am I missing something? > > > Yes, you are missing that the bug really isn't fixed. There are still > USE combinations which would be otherwise perfectly valid, but which > cause php to fail to emerge, thus reaking non-interactivity and forcing > people to (ab)use /etc/portage/package.use to get things working properly. > > -Steve The bug is about *default* use flags breaking interactivity. There are donzens of packages that die in pkg_setup if incorrect USE flags are sepcified, because use-dependencies are not implemented. I don't believe anyone is trying to enforce interactivity in that case, because as far as I'm aware there is no workaround present. -Alec Warner signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] QA Team's role
On Monday 27 February 2006 16:12, Stuart Herbert wrote: > On Mon, 2006-02-27 at 20:54 +, Ciaran McCreesh wrote: > > Whilst that one's still alive, I'm not going to go > > around filing more similar "breaks non-interactively" bugs because the > > discussion will just get repeated over and over. > > This point is another example of an attempt to enforce an undocumented > QA policy the non-interactive rule has never been stated, just hinted at for example, the dev handbook mentions offhand: * Testing the package Please keep in mind the general requirements of an ebuild here. The src_test routine must not be interactive. if you like i can rectify this situation in the Ebuild policy guide -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
On Mon, 27 Feb 2006 21:12:22 + Stuart Herbert <[EMAIL PROTECTED]> wrote: > On Mon, 2006-02-27 at 20:54 +, Ciaran McCreesh wrote: > > My point is that that's a nasty QA bug that's relying upon input > > from Stuart to be fixed. > > I'm afraid you've been mis-informed. The PHP herd has provided a set > of default USE flags to go into the profiles, and there's a comment > at the bottom of the bug clearly stating that they're currently being > tested. That's not a fix. That's a workaround. The PHP ebuilds are still broken; all that's changed is that the breakage isn't apparent on a default install. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Re: KDE, metapackages, and monolithic packages
Mike Myers posted <[EMAIL PROTECTED]>, excerpted below, on Sun, 26 Feb 2006 17:05:57 -0600: > 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? It seems like the ebuilds are only > intended to make installing kde easier, which they do, but it doesn't > make handle uninstalling or reinstalling a split ebuild very easy at > all. As others have said it's a technical/portage issue. Unmerging a package always leaves dependencies behind. To clean those up, emerge -NuD world (to ensure use dependencies are uptodate), emerge -p depclean (to get a list of what it thinks is unneeded), fix anything on that list you know to be needed (add it to world), then either unmerge individually (as I do, even then, ensuring I haven't missed adding something to world that I should have, verifying what each package does and thinking about whether I actually do need it as I go) or if you prefer, use the depclean without the -p, then, finally, do a revdep-rebuild (first -p it, of course) to catch any dependencies that still might have slipped thru and need rebuilt. Upgrading is a bit more sensitive. However, with things like KDE upgrades, I'll often use the --prune parameter on emerge, combined with -p first of course. Then again, I unmerge manually as necessary. One other method I've used is to do an equery list of kde packages, then grep it for the version I want to unmerge, to get a list of old packages. So an upgrade from 3.4 to 3.5 I'd grep for 3.4. Finally, when you've unmerged most old KDE packages, take a look at the old /usr/kde/ dir and see what's left there, then do equery belongs with what's left, to figure out the packages they belong to. Anything left over that doesn't belong to a package should be deletable, or if you prefer to be safe, move it to a backup dir for a month or so first, so you can restore it if necessary. Again, after unmerging stuff, a revdep-rebuild is recommended. As others said, please move futher discussion to either user or desktop. I don't look at user, but I'm a regular over in desktop, where KDE questions are happily answered, as it's certainly part of desktop. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
On Mon, 27 Feb 2006 21:49:23 +0100 Jakub Moc <[EMAIL PROTECTED]> wrote: | | May I ask how is that related to webapp-config? | It is related to Stuart, and hence utterly relevant to the conversation. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Mon, 27 Feb 2006 15:04:52 -0600 Grant Goodyear <[EMAIL PROTECTED]> wrote: | Ciaran McCreesh wrote: | > My point is that that's a nasty QA bug that's relying upon input | > from Stuart to be fixed. Whilst that one's still alive, I'm not | > going to go around filing more similar "breaks non-interactively" | > bugs because the discussion will just get repeated over and over. | | Huh? I just read through the bug, and it actually appears to be | resolved pending Chris' testing w/ the needed USE flags added to the | various profiles. I'll admit that the fix is inelegant, but I'm | missing where it's waiting upon Stuart for additional info. Am I | missing something? Yup. It's a huge policy violation being passed off as a feature. See http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1 in the paragraph starting "Occasionally, ebuilds will have conflicting USE flags for functionality.". -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Mon, 27 Feb 2006 21:12:22 + Stuart Herbert <[EMAIL PROTECTED]> wrote: | This point is another example of an attempt to enforce an undocumented | QA policy, which is where I made my input, as the architect of our new | (and well-received) PHP packages. ... and then the discussion | deteriorated into something I'm not particularly proud of, for my part | in it. Huh? I quote the official policy: http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1 > Occasionally, ebuilds will have conflicting USE flags for > functionality. Checking for them and returning an error is not a > viable solution. Instead, you must pick one of the USE flags in > conflict to favour. One example comes from the msmtp ebuilds. The > package can use either SSL with GnuTLS, SSL with OpenSSL, or no SSL > at all. Because GnuTLS is more featureful than OpenSSL, it is > favoured: It's a QA violation, and not a feature as you claim. I find it particularly worrying that you try to pass of blatant policy violations as a feature. The first step in QA is detecting that there is a problem. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re[2]: [gentoo-dev] [RFC] QA Team's role
27.2.2006, 22:18:05, Stephen P. Becker wrote: > Grant Goodyear wrote: >> Ciaran McCreesh wrote: >>> My point is that that's a nasty QA bug that's relying upon input from >>> Stuart to be fixed. Whilst that one's still alive, I'm not going to go >>> around filing more similar "breaks non-interactively" bugs because the >>> discussion will just get repeated over and over. >> >> Huh? I just read through the bug, and it actually appears to be >> resolved pending Chris' testing w/ the needed USE flags added to the >> various profiles. I'll admit that the fix is inelegant, but I'm missing >> where it's waiting upon Stuart for additional info. Am I missing something? > There are still USE combinations which would be otherwise perfectly valid, > but which cause php to fail to emerge, thus reaking non-interactivity and > forcing people to (ab)use /etc/portage/package.use to get things working > properly. Yeah, and there will be, since chosing between stuff like mysql or recode on behalf of the user is plain stupid and produces unexpected outcome, since portage can't handle build_with_use this way, since portage can't handle use flags conflict at emerge --pretend/--ask time, and last but not least since there's no such policy that would mandate such changes. However, I'm still one ear wrt the original topic, which was "all the ways in which webapp-config is broken". -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgpSRt1UKZEbw.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Mon, Feb 27, 2006 at 05:30:27PM +, Stephen Bennett <[EMAIL PROTECTED]> wrote: > (Yes, I'm taking that sentence out of context, but the fact that it > comes up at all says something, to my mind.) Your mind is a dark and twisted place! -- Role:Gentoo Linux Kernel Lead Gentoo Linux:http://www.gentoo.org Public Key: gpg --recv-keys 9C745515 Key fingerprint: A0AF F3C8 D699 A05A EC5C 24F7 95AA 241D 9C74 5515 pgpcif7cymuGN.pgp Description: PGP signature
Re[2]: [gentoo-dev] [RFC] QA Team's role
27.2.2006, 22:33:21, Ciaran McCreesh wrote: > On Mon, 27 Feb 2006 21:49:23 +0100 Jakub Moc <[EMAIL PROTECTED]> wrote: > | > | May I ask how is that related to webapp-config? > | > It is related to Stuart, and hence utterly relevant to the conversation. Ah, sure - so the topic is that you have personal issues with Stuart and are washing your dirty laundry in a public ML? You still haven't posted posted a *single example* of webapp-config brokeness. You, I'd say you should either back up claims about "all the ways in which webapp-config is broken" or apologize to the concerned developers for false claims. Still waiting. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgp56jdp76Pag.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
Stephen P. Becker wrote: > Grant Goodyear wrote: >> Ciaran McCreesh wrote: >>> My point is that that's a nasty QA bug that's relying upon input from >>> Stuart to be fixed. Whilst that one's still alive, I'm not going to go >>> around filing more similar "breaks non-interactively" bugs because the >>> discussion will just get repeated over and over. >> Huh? I just read through the bug, and it actually appears to be >> resolved pending Chris' testing w/ the needed USE flags added to the >> various profiles. I'll admit that the fix is inelegant, but I'm missing >> where it's waiting upon Stuart for additional info. Am I missing something? > > Yes, you are missing that the bug really isn't fixed. There are still > USE combinations which would be otherwise perfectly valid, but which > cause php to fail to emerge, thus reaking non-interactivity and forcing > people to (ab)use /etc/portage/package.use to get things working properly. Well, I did say that it was an inelegant fix In any event, I appreciate your response about php brokenness (I'll come back to this below), but does this php brokenness require additional info from Stuart to fix? Let me try breaking things down a bit to see if I can understand the various specific problems: 0. Stuart and Ciaranm (and Jakub and Ciaranm) don't like each other very much. *Shrug* That's not really a problem, it just means that one needs hip-waders to get through all of the muck. No big deal; that's part of being a dev with a really large project. 1. A fresh Gentoo install w/ default USE flags will fail to compile dev-lang/php. That one is being "solved" by adding some additional USE flags to the default profile. The claim from the php team is that the correct fix is a version of portage with USE-based dependencies. The QA folks would prefer to see the php ebuild implement a set of sane defaults to prevent breakages, instead, if I understand correctly, which in practice would mean that the ebuild would detect whether or not deps were built with the correct USE flags, and work around any "broken" deps in the ebuild. (I must be missing something, since the latter strikes me as notably _bad_, since it would mean that two people with identical USE flags would get different outcomes depending on how their dependencies are built.) 2. There are a variety of otherwise-valid USE-flag combinations that will cause php to fail to build (or be otherwise unusable). That's hardly surprising, since dev-lang/php has ~100 USE flags, which means ~2**100 (~10**30) possible USE-flag combinations. Let's see, there are roughly pi*10**7 seconds per year, so if we could test one build of php per second it would only take considerably longer than the lifetime of the universe to test all of the possible combinations. Clearly QA of the current ebuild has to be rather illusory. Do we have a bug open about this? Are there any reasonable suggestions on how to fix it? I do realize that the problem is complicated by the fact that people really do use fairly esoteric php builds on production machines. That said, the current situation really is a nightmare! 3. There are a number of people (not just ciaranm) who consider the webapp idea to be brilliant in concept, but horribly flawed in its execution. (I'm personally fairly agnostic, although the one time that I had to create a webapp-enabled ebuild I found the process to be incredibly confusing. I just assumed that with great flexibility comes great pain.) However, I've never known precisely why people feel that way, and I can't find any bugs about it, so perhaps we could have a real debate about this issue? I don't think that bug #120088 is it. -g2boojum- signature.asc Description: OpenPGP digital signature
Re[2]: [gentoo-dev] [RFC] QA Team's role
27.2.2006, 22:32:39, Ciaran McCreesh wrote: > I quote the official policy: > http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1 >> Occasionally, ebuilds will have conflicting USE flags for >> functionality. Checking for them and returning an error is not a >> viable solution. Instead, you must pick one of the USE flags in >> conflict to favour. One example comes from the msmtp ebuilds. The >> package can use either SSL with GnuTLS, SSL with OpenSSL, or no SSL >> at all. Because GnuTLS is more featureful than OpenSSL, it is >> favoured: > It's a QA violation, and not a feature as you claim. > I find it particularly worrying that you try to pass of blatant policy > violations as a feature. The first step in QA is detecting that there > is a problem. No, that's not a policy document, ebuild policy is documented here: http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?style=printable&part=3&chap=1 Moreover, the cited howto is wrong, since it will break built_with_use checks, as explained on the relevant bug and as explained here on mailing list before. The howto also doesn't apply to cases like recode vs. mysql, because that's a completely different functionality, you can't exactly choose which one is better on behalf of the user. So, to sum it up - you can't make up for portage's lack of features by inventing a policy that doesn't work. Once again - until portage can handle USE-based dependencies and until portage can handle conflicting use flags, there's nothing that could be done here. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgprwDQAkXsrs.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Monday 27 February 2006 18:15, Ciaran McCreesh wrote: > On Mon, 27 Feb 2006 10:47:58 -0600 Lance Albertson > > <[EMAIL PROTECTED]> wrote: > | > So if the maintainer sticks SANDBOX_DISABLE="1" rm -fr / in global > | > scope and refuses to move it, QA will have to get council approval > | > to fix it? > | > | Use some common sense when showing an example please. We all know > | that something that stupid needs to be delt with quickly. > > If we all recognise that level of stupidity, please explain how the > heck this got into the tree: > > http://www.gentoo.org/cgi-bin/viewcvs.cgi/*checkout*/sys-apps/bootstrap >_cmds/bootstrap_cmds-44.ebuild?rev=1.1&content-type=text/plain Probably because although it isn't a good ebuild it still works and does not violate the sandbox. While it does things in the wrong way/place it does not do the wrong things. I do not think that anyone would argue against QA (or other developers) fixing urgent big tree breakages. (and rm -rf / would certainly qualify). What I see as the argument is that QA should show a degree of flexibility in it's policies, and not just enforce because of the policy. This especially in those cases where there is no way to provide the ebuild without breaking policy, or doing so would mean a greater inconvenience to the users. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpAaY4gCI1d4.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Monday 27 February 2006 21:37, Ciaran McCreesh wrote: > | You know where bugzilla is. You know how to contact any of the > | webapp-config maintainers via email, or via IRC. We're ready to > | listen to your input, and to work with you (or anyone else) on fixing > | any genuine problems that webapp-config has. The more feedback we > | get, the better we can make this package for everyone's enjoyment. > > Then please start with bug 120088. Once that one's fixed we'll go from > there. While that bug explains your issues with the webapp people in general and stuart in particular it is not related to webapp-config at all. Looking at that bug, and the issues discussed in this thread I do get to the point where I feel that instead of buggering people about packages, it would perhaps be better to get those features into portage whose absense causes the problems. The quality of the distribution would be better suited with a portage that supports USE-flag dependencies, dependencies between useflags in a package, sourcefile renaming / DIST_PREFIX, etc. Once that is supported, I'm also sure that those people involved will be more than happy to fix their ebuilds to use those features. I do agree with them though that the distribution should not be held back by missing features in portage. Especially since those features have been missing (recognized as such) for ages. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgp7Sy1ZWbKjB.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Monday 27 February 2006 22:34, Ciaran McCreesh wrote: > Yup. It's a huge policy violation being passed off as a feature. See > http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap= >1 in the paragraph starting "Occasionally, ebuilds will have conflicting > USE flags for functionality.". If that was the only consideration in this case I would agree with you. I do however also see Stuart's point on use_with. While it is by itself a horible kludge, I agree that it's not really proper design to check for all kinds of flags (a changing set) to verify that php was built with a certain feature. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgp1bHziuyhZL.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Monday 27 February 2006 19:19, Ciaran McCreesh wrote: > On Mon, 27 Feb 2006 12:05:58 -0600 Grant Goodyear <[EMAIL PROTECTED]> > > wrote: > | Of course, that leaves the question of who decides on the severity of > | a QA violation? > > All this talk of severity, and no talk of "ease of detection" or "ease > of fixing"... > > Allow me to explain. There are certain not particularly high impact > issues that can very easily be detected, and with 100% reliability, by > The Thing About Which We Do Not Talk. Any individual one of these > doesn't look like such a big deal, but when we're talking a couple of > hundred instances, all of which can easily be fixed in less overall > time than it would take to even detect one instance of a particular > severe problem, it's most definitely worth concentrating on the 'easy' > issue. I understand this point, but by your own admission, they are not particularly high impact. In the case at hand, the particular issue does however conflict with other goals. What I think would be reasonable is to expect that you are not going to be able to solve 100% of the "easilly detectable" issues. So, I think that while you continue to run the tests on these packages, you maintain a list of exceptions, including the reason for them being exceptions. Besides, work on finding solutions to the problems behind it. But do not choose the greater evil (removing or blocking a package) before the lesser evil (keeping a package with well-documented issues). In this respect I would like to propose that each package that has these issues related to missing portage features, ensures that a related bug is created for portage requesting that feature/a solution for the fundamental problem. This bug should be marked as blocker for the package related bugs in this respect. That way we can keep account of which features in portage are needed for which packages. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpunHQXZmc9Y.pgp Description: PGP signature
[gentoo-dev] enable UTF8 per default?
Hi all, at FOSDEM we had a nice discussion about languages, translations etc. Having people from the US (wolf31o2) who never have problems and people from Japan (usata) who always have problems with encodings / charsets / ... was quite interesting. During that discussion we realized that having utf-8 not enabled by default and no utf8 fonts available by default causes lots of recompilation and reconfiguration. Enabling the unicode useflag in the profiles should help our international users and should not cause any problems. Are there any known bugs / problems this would trigger? Any reasons against that? If there are no objections this should be a small but helpful change. On a tangent I wonder if pulling in extra fonts as a dependency of X makes sense (useflag controlled, enabled by default) - that way the unicode capabilities are available without any configuration. Patrick -- Stand still, and let the rest of the universe move signature.asc Description: This is a digitally signed message part
[gentoo-dev] Gentoo-based sysadmin job
Hi peeps, LINX (http://www.linx.net) are looking for a sys-admin with excellent Gentoo knowledge. Hardened toolchain and/or grsec experience are considered a big plus. You will act as the Gentoo guru for the IT department and are expected to be very comfortably with Gentoo on servers. Where you don't know how to do something, you should be able to research and learn it quickly. You would be required to live in/near Peterborough, UK. That's about an hour from London by train. If you are interested, please see: https://www.linx.net/www_public/about/careers Any questions, feel free to ask me and I'll either answer myself or point you towards the correct person at LINX. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Gentoo-based sysadmin job
Would we be required to fix the mess left by the previous sys-admin? :pGeorgeOn 28/02/06, Rob Holland <[EMAIL PROTECTED] > wrote:Hi peeps,LINX (http://www.linx.net ) are looking for a sys-admin with excellentGentoo knowledge. Hardened toolchain and/or grsec experience areconsidered a big plus.You will act as the Gentoo guru for the IT department and are expected to be very comfortably with Gentoo on servers. Where you don't know howto do something, you should be able to research and learn it quickly.You would be required to live in/near Peterborough, UK. That's about an hour from London by train.If you are interested, please see:https://www.linx.net/www_public/about/careersAny questions, feel free to ask me and I'll either answer myself or point you towards the correct person at LINX.-BEGIN PGP SIGNATURE-Version: GnuPG v1.4.2.1 (GNU/Linux)iD8DBQBEBC701lw5L9kbRykRAgwCAJwJAIlG7Dn0wXOLxHCH4b5p+Yii8wCdFjWXV/HipfvjOAZmYS/uRoB0kG0= =Z+cO-END PGP SIGNATURE-
Re: [gentoo-dev] enable UTF8 per default?
On Tuesday 28 February 2006 11:58, Patrick Lauer wrote: > During that discussion we realized that having utf-8 not enabled by > default and no utf8 fonts available by default causes lots of > recompilation and reconfiguration. At the same time, you'll probably hear people bitching about UTF-8 being enabled because "it's not needed for me, should be the rest of the world to change" I'd be the first to be interested in having it enabled by default, tho. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpmhzBPU7ZAR.pgp Description: PGP signature
Re[2]: [gentoo-dev] [RFC] QA Team's role
27.2.2006, 22:32:39, Ciaran McCreesh wrote: > I quote the official policy: > http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1 >> Occasionally, ebuilds will have conflicting USE flags for >> functionality. Checking for them and returning an error is not a >> viable solution. Instead, you must pick one of the USE flags in >> conflict to favour. One example comes from the msmtp ebuilds. The >> package can use either SSL with GnuTLS, SSL with OpenSSL, or no SSL >> at all. Because GnuTLS is more featureful than OpenSSL, it is >> favoured: And - one more note - when and where has been the following change discussed and who approved that?! http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild.xml?r1=1.25&r2=1.26&root=gentoo -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgpAWJJBeYTVG.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo-based sysadmin job
On Tue, 2006-02-28 at 11:18 +, George Prowse wrote: > Would we be required to fix the mess left by the previous > sys-admin? :p Yes :P signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] enable UTF8 per default?
On Tue, 2006-02-28 at 12:32 +0100, Diego 'Flameeyes' Pettenò wrote: > On Tuesday 28 February 2006 11:58, Patrick Lauer wrote: > > During that discussion we realized that having utf-8 not enabled by > > default and no utf8 fonts available by default causes lots of > > recompilation and reconfiguration. > At the same time, you'll probably hear people bitching about UTF-8 being > enabled because "it's not needed for me, should be the rest of the world to > change" It is still optional, just enabled by default :-) All the people with non-ASCII charsets will have less work, only that we switch the load from, say, 75% of the users fixing their environment to 25% of users having to switch. And who doesn't want UTF-8? Just being able to see a Japanese Website as it was intended (even if I can't read it) is a nice feature. So - apart from some users maybe not wanting it, any technical reasons against? > I'd be the first to be interested in having it enabled by default, tho. Yes, otherwise spelling your name is almost impossible :-) Patrick -- Stand still, and let the rest of the universe move signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] enable UTF8 per default?
On Tuesday 28 February 2006 12:47, Patrick Lauer wrote: > It is still optional, just enabled by default :-) Would be enough to be criticized probably, mainly by english-speaking users that doesn't care of extended characters. Although, this would follow also the direction of both Apple and Microsoft, the first providing, the other saying that will provide, an always-unicoded system. That is probably the way to allow an easier access to Gentoo for non-english speaking people, too. > So - apart from some users maybe not wanting it, any technical reasons > against? I'll wait for the "clutter" comment by users and maybe devs. I was criticized for enabling unicode forcefully on vlc because of a source-code bug that prevented non-unicode wxGTK to be used to build it, after that I'm always expecting some sort of problem :P > > I'd be the first to be interested in having it enabled by default, tho. > Yes, otherwise spelling your name is almost impossible :-) That, and I'm actually trying to find time to learn Japanese :P But time is something I don't have abundant :| -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpP7dQ0bttdT.pgp Description: PGP signature
Re: [gentoo-dev] enable UTF8 per default?
* Patrick Lauer <[EMAIL PROTECTED]> [06/02/28 11:58 +0100]: > Enabling the unicode useflag in the profiles should help our > international users and should not cause any problems. Are there any > known bugs / problems this would trigger? Any reasons against that? It is enabled by default. At least on ppc. And that since, uhm, summer 2004? I can't say if there are any problems, as I didn't received a bug for a long time. The only thing that's nasty: we don't have any good utf8-fonts for the console. Regards, Lars -- Lars Weiler <[EMAIL PROTECTED]> +49-171-1963258 Gentoo Linux PowerPC: Developer and Release Engineer Gentoo Infrastructure : CVS Administrator Gentoo Foundation : Trustee -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
You still haven't posted posted a *single example* of webapp-config brokeness. You, I'd say you should either back up claims about "all the ways in which webapp-config is broken" or apologize to the concerned developers for false claims. Still waiting. OK, here is one. It seems that webapp-config silently assumes your webserver is apache by default. If a user uses lighttpd for example, this is totally incorrect. Now, this doesn't cause webapp-config to fail to emerge, but the first time you emerge any webapp, you get a big nasty error about no Apache group available, which further requires the end user to dig around the webapp-config manpage to figure out the correct file to edit *just* to get a silly php script to install in the correct location. And please, don't tell me this is a feature. It breaks noninteractivity for every "webapp" in the entire tree. -Steve -- gentoo-dev@gentoo.org mailing list
Re[2]: [gentoo-dev] [RFC] QA Team's role
28.2.2006, 13:54:36, Stephen P. Becker wrote:
>> You still haven't posted posted a *single example* of webapp-config
>> brokeness. You, I'd say you should either back up claims about "all the ways
>> in which webapp-config is broken" or apologize to the concerned developers
>> for false claims.
>>
>> Still waiting.
>>
> OK, here is one. It seems that webapp-config silently assumes your
> webserver is apache by default. If a user uses lighttpd for example,
> this is totally incorrect.
Why don't you voice your solutions on Bug 11007? The whole underlying stuff
is hell broader than what webapp-config assumes or doesn't assume.
> Now, this doesn't cause webapp-config to fail to emerge, but the first
> time you emerge any webapp, you get a big nasty error about no Apache
> group available, which further requires the end user to dig around the
> webapp-config manpage to figure out the correct file to edit *just* to
> get a silly php script to install in the correct location.
The above is a direct result of purging all kind of useful predefined
users/groups from /etc/{passwd,group} without considering any wider
consequences. It has already caused circular deps and broke a couple of
things, included but non-limited to installing Gentoo itself (search
bugzilla for related bugs). Where is the whole benefit from this, I still
have to see.
webapp-config should be updated to handle such situation more gracefully, so
why don't you file a bug about this? Is that all you have wrt "all the ways
in which webapp-config is broken"? If so, that's not really much of a
justification of the broad claim ciaranm has made as a QA project member.
> And please, don't tell me this is a feature. It breaks noninteractivity
> for every "webapp" in the entire tree.
What kind of non-interactivity? What's this universal non-interactivity
blurb of yours and ciaranm's about? There's no such thing when it comes to
configuration. If you want automated "configuration", then please use
Windows and stop moaning. If you don't want to read manpages or at least
--help, then please use Windows as well. If you want to use non-default
setup, then you need to change default values, that's what common sense
dictates at least. And don't use the (non)-interactivity magical formular in
a context where it has zero sense.
--
Best regards,
Jakub Moc
mailto:[EMAIL PROTECTED]
GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E
... still no signature ;)
pgpFxviIqcbv0.pgp
Description: PGP signature
[gentoo-dev] License advice
I'm not sure how to correctly handle bug #87542. It is about a dev-tex package that doesn't have a license (ctan doesn't state one, and no license can be found anywhere else). By definition I have to assume that it is proprietary. But an eager bug reporter has gotten a statement from the two authors, that the package is meant to be public-domain. Should I require a public statement from the authors, like an update version on ctan that states the license, or is it enough to refer to the bug report? (ie., is it enough that the reporter says that the author said the package is public-domain?) -- Martin Ehmsen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] enable UTF8 per default?
On Tue, 2006-02-28 at 13:50 +0100, Lars Weiler wrote: > * Patrick Lauer <[EMAIL PROTECTED]> [06/02/28 11:58 +0100]: > > Enabling the unicode useflag in the profiles should help our > > international users and should not cause any problems. Are there any > > known bugs / problems this would trigger? Any reasons against that? > > It is enabled by default. At least on ppc. As far as I can tell that's not the case on x86 > And that since, > uhm, summer 2004? Ok, so it should be quite well-tested. > I can't say if there are any problems, as I didn't received > a bug for a long time. The only thing that's nasty: we > don't have any good utf8-fonts for the console. I think that's acceptable. -- Stand still, and let the rest of the universe move signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] QA Team's role
webapp-config should be updated to handle such situation more gracefully, so why don't you file a bug about this? Is that all you have wrt "all the ways in which webapp-config is broken"? If so, that's not really much of a justification of the broad claim ciaranm has made as a QA project member. I only encountered the problem the day before yesterday, and hadn't gotten around to filing the bug yet. I assure you that I intend on doing so. And please, don't tell me this is a feature. It breaks noninteractivity for every "webapp" in the entire tree. What kind of non-interactivity? What's this universal non-interactivity blurb of yours and ciaranm's about? There's no such thing when it comes to configuration. If you want automated "configuration", then please use Windows and stop moaning. If you don't want to read manpages or at least --help, then please use Windows as well. If you want to use non-default setup, then you need to change default values, that's what common sense dictates at least. And don't use the (non)-interactivity magical formular in a context where it has zero sense. No! You are completely missing the point. The non-interactivity of which we speak is the idea that when you emerge some package, it is perfectly reasonable (and in fact should be required) to expect that package to install to your userland with no further prodding. There should be no USE collisions which cause the emerge to die. There should be no default configuration which will break other packages in the tree by default. Note that in no way am I talking about auto-configuration, as that would be silly. The example problem with webapp-config which I have described here forces a user to intervene to get packages to install to the proper location. This is not desirable. Basically, I really don't see why webapp-config can't have some logic built in which makes it smart enough to figure out which webserver somebody is using. -Steve -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] License advice
On Tuesday 28 February 2006 14:46, Martin Ehmsen wrote: > Should I require a public statement from the authors, like an update > version on ctan that states the license, or is it enough to refer to the > bug report? (ie., is it enough that the reporter says that the author > said the package is public-domain?) The best thing is probably if the authors can change that directly on CTAN or if the reporter can provide a signed statement with a public key that is recognized to be of one of the authors at least. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpRgHCjXGW2q.pgp Description: PGP signature
Re: [gentoo-dev] enable UTF8 per default?
On Tuesday 28 February 2006 06:47, Patrick Lauer wrote: > On Tue, 2006-02-28 at 12:32 +0100, Diego 'Flameeyes' Pettenò wrote: > > On Tuesday 28 February 2006 11:58, Patrick Lauer wrote: > > > During that discussion we realized that having utf-8 not enabled by > > > default and no utf8 fonts available by default causes lots of > > > recompilation and reconfiguration. > > > > At the same time, you'll probably hear people bitching about UTF-8 being > > enabled because "it's not needed for me, should be the rest of the world > > to change" > > It is still optional, just enabled by default :-) > All the people with non-ASCII charsets will have less work, only that we > switch the load from, say, 75% of the users fixing their environment to > 25% of users having to switch. hopefully people will fix their packages to respect USE=unicode as to whether they link against libncurses or libncursesw -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
On 2/28/06, Stephen P. Becker <[EMAIL PROTECTED]> wrote: > OK, here is one. It seems that webapp-config silently assumes your > webserver is apache by default. If a user uses lighttpd for example, > this is totally incorrect. > > Now, this doesn't cause webapp-config to fail to emerge, but the first > time you emerge any webapp, you get a big nasty error about no Apache > group available, which further requires the end user to dig around the > webapp-config manpage to figure out the correct file to edit *just* to > get a silly php script to install in the correct location. There's no need to be rude about php scripts. Thank you for reporting this error. We've committed a fix for this problem upstream. We'll probably roll out w-c 1.5.11 at the weekend. That'll give us suitable time to test this, and to incorporate the QA issues from Ciaran that we're still waiting for. Best regards, Stu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
On Tuesday 28 February 2006 04:49, Jakub Moc wrote: > No, that's not a policy document, ebuild policy is documented here: > http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?style=printable&; >part=3&chap=1 so what, you want us to duplicate everything in one document and place it in the other just because one has the title "Policy" ? that's retarded the dev handbook documents proper ebuild development regardless of the title on a particular page -mike -- gentoo-dev@gentoo.org mailing list
Re[2]: [gentoo-dev] [RFC] QA Team's role
28.2.2006, 15:00:49, Stephen P. Becker wrote: >> What kind of non-interactivity? What's this universal non-interactivity >> blurb of yours and ciaranm's about? There's no such thing when it comes to >> configuration. If you want automated "configuration", then please use >> Windows and stop moaning. If you don't want to read manpages or at least >> --help, then please use Windows as well. If you want to use non-default >> setup, then you need to change default values, that's what common sense >> dictates at least. And don't use the (non)-interactivity magical formular in >> a context where it has zero sense. > No! You are completely missing the point. The non-interactivity of > which we speak is the idea that when you emerge some package, it is > perfectly reasonable (and in fact should be required) to expect that > package to install to your userland with no further prodding. There > should be no USE collisions which cause the emerge to die. There should > be no default configuration which will break other packages in the tree > by default. > Note that in no way am I talking about auto-configuration, as that would > be silly. The example problem with webapp-config which I have described > here forces a user to intervene to get packages to install to the proper > location. This is not desirable. Selecting a webserver to use with a webapp package is a part of configuration. So again, the whole non-interactive idea is irrelevant wrt webapp-config and non-default setups. No defaults in default config won't work/won't improve anything either, since some webapps need to have their config files server-owned. Running a server and webapps is not a no-brainer which should just automagically work; to the contrary - users should think about what they are doing or they just should run a server app. > Basically, I really don't see why webapp-config can't have some logic > built in which makes it smart enough to figure out which webserver > somebody is using. Sure, you can make webapp-config depend on virtual/magic where RDEPEND="|| ( app-admin/artificial-intelligence app-admin/mind-reader ) and then emerge lighttpd apache I think it's pretty much obvious that this just won't work since such virtual doesn't and won't exist. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgpZk7zF5dP7K.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, 28 Feb 2006 10:49:13 +0100 Jakub Moc <[EMAIL PROTECTED]> wrote: | No, that's not a policy document, ebuild policy is documented here: | http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?style=printable&part=3&chap=1 No, the whole thing is policy. | Moreover, the cited howto is wrong, since it will break built_with_use | checks No, that's a separate issue. | The howto also doesn't apply to cases like | recode vs. mysql, because that's a completely different | functionality, you can't exactly choose which one is better on behalf | of the user. No, it does apply. | So, to sum it up - you can't make up for portage's lack of features by | inventing a policy that doesn't work. Once again - until portage can | handle USE-based dependencies and until portage can handle | conflicting use flags, there's nothing that could be done here. Until Portage can handle conflicting USE flags, one should take the policy-mandated solution that has been sufficient for everyone else for four years or more. Sure, it's not perfect, but it's a hell of a lot better than repeatedly exploding in the user's face midway through an install. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, 28 Feb 2006 14:21:14 + "Stuart Herbert" <[EMAIL PROTECTED]> wrote: | We've committed a fix for this problem upstream. We'll probably roll | out w-c 1.5.11 at the weekend. That'll give us suitable time to test | this, and to incorporate the QA issues from Ciaran that we're still | waiting for. It's going to take longer than that for me to get you a full, properly explained list of every QA issue I can find. Now, I *could* give you the shorter list of stuff I noticed within half an hour of using it, but I'd rather get this done properly if I'm doing it at all. I'm still not convinced that it's worth my while, however, based upon your past attitude of claiming "it's a feature". My time could better be spent helping out developers who will actually fix their breakages. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] enable UTF8 per default?
I can't say if there are any problems, as I didn't received a bug for a long time. The only thing that's nasty: we don't have any good utf8-fonts for the console. I think that's acceptable. The only issue related to that we really have is this bug, which is annoying but not fatal: http://bugs.gentoo.org/show_bug.cgi?id=107235 -Joe -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, 28 Feb 2006 11:34:49 +0100 Paul de Vrieze <[EMAIL PROTECTED]> wrote: | Once that is supported, I'm also sure that those people involved will | be more than happy to fix their ebuilds to use those features. I do | agree with them though that the distribution should not be held back | by missing features in portage. Especially since those features have | been missing (recognized as such) for ages. So until then, it's perfectly OK to screw over our users and fellow developers by committing any arbitrary mess to the tree and claiming that it's alright because Portage doesn't offer a perfect alternative? -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, 28 Feb 2006 11:21:23 +0100 Paul de Vrieze <[EMAIL PROTECTED]> wrote: | > http://www.gentoo.org/cgi-bin/viewcvs.cgi/*checkout*/sys-apps/bootstrap | >_cmds/bootstrap_cmds-44.ebuild?rev=1.1&content-type=text/plain | | Probably because although it isn't a good ebuild it still works and | does not violate the sandbox. While it does things in the wrong | way/place it does not do the wrong things. Huh? It violates the sandbox even if you do 'emerge sync' and never touch the ebuild. Look at the frickin' mkdir! -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, 28 Feb 2006 10:38:17 +0100 Jakub Moc <[EMAIL PROTECTED]> wrote:
| You still haven't posted posted a *single example* of webapp-config
| brokeness. You, I'd say you should either back up claims about "all
| the ways in which webapp-config is broken" or apologize to the
| concerned developers for false claims.
Fine. If posting a single way in which webapp-config is broken will
make you happy, here you go:
From webapp.eclass:
function webapp_read_config ()
{
This is a whitespace / coding style breakage. The correct format should
be:
webapp_read_config() {
Yes, it's an utterly trivial problem, but it is a QA violation. Getting
a complete list is something that takes a heck of a lot longer, and I
have yet to be convinced that my time would not be better spent
elsewhere.
--
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm
signature.asc
Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On 2/28/06, Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > I'm still not convinced that it's worth my while *You* chose to mention webapp-config in this thread. Stop making excuses. Make good on your claims. Put up, or shut up. Best regards, Stu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
On Tuesday 28 February 2006 15:48, Ciaran McCreesh wrote: > On Tue, 28 Feb 2006 11:21:23 +0100 Paul de Vrieze <[EMAIL PROTECTED]> > > Huh? It violates the sandbox even if you do 'emerge sync' and never > touch the ebuild. Look at the frickin' mkdir! Hmm. Didn't realise that the sandbox is more restrictive in those cases (and that the ebuild is sourced then). The mkdir in toplevel is of course wrong. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpNV2fAU2YPC.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Tuesday 28 February 2006 15:00, Stephen P. Becker wrote: > Basically, I really don't see why webapp-config can't have some logic > built in which makes it smart enough to figure out which webserver > somebody is using. Please remember that the apache group is just another name for httpd group. And it is not linked to the apache webserver. Perhaps the group should be renamed, and webapp-config should require it's presence when it is installed. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpYDF9EeiOEr.pgp Description: PGP signature
Re[2]: [gentoo-dev] [RFC] QA Team's role
28.2.2006, 15:39:40, Ciaran McCreesh wrote: > On Tue, 28 Feb 2006 10:49:13 +0100 Jakub Moc <[EMAIL PROTECTED]> wrote: > | No, that's not a policy document, ebuild policy is documented here: > | > http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?style=printable&part=3&chap=1 > No, the whole thing is policy. No, it isn't. And silently sticking parts of unofficial gentoo devmanual into official Gentoo docs, and then silently turning them into a "policy" enforced under QA disguise is a bad very practice, and pretending that this has been in the mentioned _howto_ (not policy) for a long time as just plain silly. Since you haven't answered the question in one of my previous emails at all, let me ask again: When and where has been the following change discussed and who approved that? http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild.xml?r1=1.25&r2=1.26&root=gentoo > | Moreover, the cited howto is wrong, since it will break built_with_use > | checks > No, that's a separate issue. No, it isn't. If you want something to have as a policy, it needs to be error-free, reasonably applicable and not doing more harm than if it isn't applied at all. And implementing such stuff requires a proper discussion, considering the consequences and some sort of consent among affected developers. (Also, that howto example is less than fortunate/clear, like some user noted in Bug 124401). > | The howto also doesn't apply to cases like > | recode vs. mysql, because that's a completely different > | functionality, you can't exactly choose which one is better on behalf > | of the user. > No, it does apply. No, it doesn't, you can't reasonably favour one of two completely different functionalities based on some automagic assumption/developer discretion. That doesn't benefit users in any way and just produces unexpected results (hey, I explicitely enabled "recode" use flag and php compiled without, the ebuild is broken, fix0r it!) > | So, to sum it up - you can't make up for portage's lack of features by > | inventing a policy that doesn't work. Once again - until portage can > | handle USE-based dependencies and until portage can handle > | conflicting use flags, there's nothing that could be done here. > Until Portage can handle conflicting USE flags, one should take the > policy-mandated solution that has been sufficient for everyone else for > four years or more. Sure, it's not perfect, but it's a hell of a lot > better than repeatedly exploding in the user's face midway through an > install. No, noone should enforce a policy that - doesn't exist (see above) - hasn't been discussed properly and approved (see above) - it's consequences haven't been considered wrt whether its benefits overweight the negatives and whether is useful at all. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgpj5iahK5mPv.pgp Description: PGP signature
Re: [gentoo-dev] SRC_URI component naming collision
Paul de Vrieze wrote: On Sunday 26 February 2006 22:29, Robin H. Johnson wrote: On Fri, Feb 24, 2006 at 02:19:40PM +, Ciaran McCreesh wrote: Side note: if the packages in question are fetch restricted, you're screwed, and will not be able to add them to the tree. Actually, there is a solution for this, and it's reasonable logical. Don't use the same name that upstream does for the files. Simply tell the user to download X and place it in $DISTDIR renaming it to X-foo-bar, where's you've chosen X-foo-bar to avoid conflicts. Is there any valid reason that we can't have portage do this automatically. This particular way is very user-un-friendly. Check your mail archives for the old discussions about distfile name mangling (short version: a lot of stuff relies on distfile-name == basename(src_uri), also if at all this would only be a long term solution due to compat issues involved). Marius -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, 2006-02-28 at 14:52 +, Ciaran McCreesh wrote:
> On Tue, 28 Feb 2006 10:38:17 +0100 Jakub Moc <[EMAIL PROTECTED]> wrote:
> | You still haven't posted posted a *single example* of webapp-config
> | brokeness. You, I'd say you should either back up claims about "all
> | the ways in which webapp-config is broken" or apologize to the
> | concerned developers for false claims.
>
> Fine. If posting a single way in which webapp-config is broken will
> make you happy, here you go:
>
> From webapp.eclass:
>
> function webapp_read_config ()
> {
>
> This is a whitespace / coding style breakage. The correct format should
> be:
>
> webapp_read_config() {
>
> Yes, it's an utterly trivial problem, but it is a QA violation. Getting
> a complete list is something that takes a heck of a lot longer, and I
> have yet to be convinced that my time would not be better spent
> elsewhere.
Wow. That is ... impressive. After about two days of asking for any real
bugs you are able to show a trivial syntax issue?
Please stop yelling "it si teh b0rk!" if you can't even list any serious
issues, and stop being rude to other people.
Thanks,
Patrick
--
Stand still, and let the rest of the universe move
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] QA Team's role
On Tuesday 28 February 2006 15:52, Ciaran McCreesh wrote: > Yes, it's an utterly trivial problem, but it is a QA violation. Getting > a complete list is something that takes a heck of a lot longer, and I > have yet to be convinced that my time would not be better spent > elsewhere. Where is a coding style problem related to quality of code in general and assurance in particular? This is something that repoman might check for, and issue a warning. It has nothing to do with end-user quality. It even is no problem for developers trying to understand the ebuild. It is only a coding style violation, not a QA violation. Coding style is to present a uniform view to things, so things look proper. QA is about things being proper, not looking proper. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgphVi8WirX0J.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, Feb 28, 2006 at 02:52:46PM +, Ciaran McCreesh wrote: > Yes, it's an utterly trivial problem, but it is a QA violation. Getting > a complete list is something that takes a heck of a lot longer, and I > have yet to be convinced that my time would not be better spent > elsewhere. So let me get this straight. You have been claiming that webapp-config is broken, to put it mildly, for quite some time (at least several months). Yet as of now, you are unable to tell us what exactly is wrong. When I asked you on IRC for feedback, you referred me to a private conversation with Stuart, which is just as useless as the rest of your comments. You have not filed a single bug or sent a single email to the maintainers. Your only relevant QA point is a trivial style issue. Your blathering is insulting to the people who actually spend time trying to improve webapp-config. No, it's not perfect. But we want to make it better, and we have asked you for feedback and got none. You, ciaranm, create measurable deadweight loss. Instead of doing productive work, I waste my time replying to your nonsense. I am fed up and will be taking the issue to devrel. -- Renat Lumpau all things web-apps C6A838DA 04AF B5EE 17CB 1000 DDA5 D3FC 1338 ADC2 C6A8 38DA America - land of the free* *Void where prohibited, restrictions apply. Cash value 1/100c. pgpmuYgynOwx3.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Tuesday 28 February 2006 15:47, Ciaran McCreesh wrote: > On Tue, 28 Feb 2006 11:34:49 +0100 Paul de Vrieze <[EMAIL PROTECTED]> > > wrote: > | Once that is supported, I'm also sure that those people involved will > | be more than happy to fix their ebuilds to use those features. I do > | agree with them though that the distribution should not be held back > | by missing features in portage. Especially since those features have > | been missing (recognized as such) for ages. > > So until then, it's perfectly OK to screw over our users and fellow > developers by committing any arbitrary mess to the tree and claiming > that it's alright because Portage doesn't offer a perfect alternative? No, not in an arbitrary way. Those fixes should be discussed, and the path of least problems chosen. Waiting on portage to catch on however has shown to be a dead end. One of the reasons that webapp-config was developed is exactly because of the fact that portage does not offer certain features (although I don't know whether portage should offer these). What I mean is that if portage is a limiting factor, we should try to find a solution that allows incorporation of the package or feature instead of not having it. Doing so is only alright when it has been properly discussed. It is not alright to just introduce mess. There is indeed no strict line between the two. That's where QA comes in. To make the judgement. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpY0jenv87fX.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, 28 Feb 2006 16:08:05 +0100 Jakub Moc <[EMAIL PROTECTED]> wrote: > When and where has been the following change discussed and who > approved that? > > http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild.xml?r1=1.25&r2=1.26&root=gentoo According to my recollection, it was discussed between members of QA and devrel. According to the CVS logs, it was committed by a member of devrel, at QA's request. You can't pass it off as a QA project conspiracy, since they didn't make the change. -- gentoo-dev@gentoo.org mailing list
Re[2]: [gentoo-dev] [RFC] QA Team's role
28.2.2006, 16:12:32, Patrick Lauer wrote:
>> This is a whitespace / coding style breakage. The correct format should
>> be:
>>
>> webapp_read_config() {
>>
>> Yes, it's an utterly trivial problem, but it is a QA violation. Getting
>> a complete list is something that takes a heck of a lot longer, and I
>> have yet to be convinced that my time would not be better spent
>> elsewhere.
> Wow. That is ... impressive. After about two days of asking for any real
> bugs you are able to show a trivial syntax issue?
> Please stop yelling "it si teh b0rk!" if you can't even list any serious
> issues, and stop being rude to other people.
Patrick++
If you can't do any better, then please apologize for your conduct and false
claims and shut up... TIA.
--
jakub
pgpdwtplthOTQ.pgp
Description: PGP signature
Re: [gentoo-dev] SRC_URI component naming collision
On Tuesday 28 February 2006 15:16, Marius Mauch wrote: > Check your mail archives for the old discussions about distfile name > mangling (short version: a lot of stuff relies on distfile-name == > basename(src_uri), also if at all this would only be a long term > solution due to compat issues involved). For this reason a package might just specify a DIST_PREFIX. This would indicate a subdirectory in DISTDIR where the package is stored. When the package is merged, the files are copied from this directory instead of the DISTDIR directory. As the copy is already made, this behaviour should not be problematic. This does however solve 99% of the file name problems. The DIST_PREFIX value could be anything, with empty being the feature disabled, allowing for the much-wanted sharing of files between packages. Even better is that this will even work with portage versions that do not support this feature. They will just store everything in DIST_PREFIX as it is now. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpWhRwKLnlQx.pgp Description: PGP signature
[gentoo-dev] Remove net-im/jive-messenger from the tree
A few days ago I added net-im/wildfire to the tree. This is the sucessor to jive-messenger. The ebuild is diferent and now complays to net-im/jabber-base. In a week or so I'll remove jive-messenger from the tree. -- Gustavo Felisberto (HumpBack) Web: http://dev.gentoo.org/~humpback Blog: http://blog.felisberto.net/ It's most certainly GNU/Linux, not Linux. Read more at http://www.gnu.org/gnu/why-gnu-linux.html . - signature.asc Description: OpenPGP digital signature
[gentoo-dev] SLOTed MySQL or not?
As the title says, what would you prefer for the future of MySQL in Gentoo? Please take a moment to read https://forums.gentoo.org/viewtopic-t-438557.html and vote (and eventually comment on it). Thanks! -- Best regards, Luca Longinotti aka CHTEKK LongiTEKK Networks Admin: [EMAIL PROTECTED] Gentoo Dev: [EMAIL PROTECTED] SysCP Dev: [EMAIL PROTECTED] TILUG Supporter: [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature
[gentoo-dev] SLOTed MySQL or not?
As the title says, what would you prefer for the future of MySQL in Gentoo? Please take a moment to read https://forums.gentoo.org/viewtopic-t-438557.html and vote (and eventually comment on it). Thanks! -- Best regards, Luca Longinotti aka CHTEKK LongiTEKK Networks Admin: [EMAIL PROTECTED] Gentoo Dev: [EMAIL PROTECTED] SysCP Dev: [EMAIL PROTECTED] TILUG Supporter: [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature
Re[2]: [gentoo-dev] [RFC] QA Team's role
28.2.2006, 16:29:07, Stephen Bennett wrote: > On Tue, 28 Feb 2006 16:08:05 +0100 > Jakub Moc <[EMAIL PROTECTED]> wrote: >> When and where has been the following change discussed and who >> approved that? >> >> http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild.xml?r1=1.25&r2=1.26&root=gentoo > According to my recollection, it was discussed between members of QA > and devrel. According to the CVS logs, it was committed by a member of > devrel, at QA's request. You can't pass it off as a QA project > conspiracy, since they didn't make the change. I'm sorry, but discussing such stuff affecting pretty much everyone who writes ebuilds among a couple of people simply isn't enough to make this a policy. And then silently applying this and starting to scream "QA violation, look, what a nasty QA violation!!!" is plain ridiculous. Punting every single piece of broken sh*t from the tree requires notifying everyone on -dev ml and allowing a period of time before it's actually done, so silently changing/stating policies is a very broken practice. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgpOpdcyaXkH8.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, 28 Feb 2006 16:17:20 +0100 Paul de Vrieze <[EMAIL PROTECTED]> wrote: | On Tuesday 28 February 2006 15:52, Ciaran McCreesh wrote: | > Yes, it's an utterly trivial problem, but it is a QA violation. | > Getting a complete list is something that takes a heck of a lot | > longer, and I have yet to be convinced that my time would not be | > better spent elsewhere. | | Where is a coding style problem related to quality of code in general | and assurance in particular? It's more relevant than you might think. Screwing up layout like that breaks various QA checking tools that assume that things are in the standard format. | QA is about things being proper, not looking proper. Proper coding style is part of being proper. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, 28 Feb 2006 16:12:32 +0100 Patrick Lauer <[EMAIL PROTECTED]> wrote: | Wow. That is ... impressive. After about two days of asking for any | real bugs you are able to show a trivial syntax issue? | | Please stop yelling "it si teh b0rk!" if you can't even list any | serious issues, and stop being rude to other people. As I already said, repeatedly, doing a full QA audit takes time. That time can be better spent auditing things that will actually get fixed. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, 28 Feb 2006 16:26:37 +0100 Jakub Moc <[EMAIL PROTECTED]> wrote:
| If you can't do any better, then please apologize for your conduct
| and false claims and shut up... TIA.
Sure I can do better. But you didn't originally ask for better, you
asked for anything. If better's what you're after:
SLOT="${PVR}"
Now, please apologise for insinuating that I don't have any real claims
to make. I find it extremely offensive that you're questioning my
technical ability.
--
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm
signature.asc
Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, 28 Feb 2006 16:08:05 +0100 Jakub Moc <[EMAIL PROTECTED]> wrote: | 28.2.2006, 15:39:40, Ciaran McCreesh wrote: | > On Tue, 28 Feb 2006 10:49:13 +0100 Jakub Moc <[EMAIL PROTECTED]> | > wrote: | > | No, that's not a policy document, ebuild policy is documented | > | here: | > | | > http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?style=printable&part=3&chap=1 | | > No, the whole thing is policy. | | No, it isn't. 'Fraid it is. Everything in the devrel handbook that isn't explicitly marked as a guideline is policy. | And silently sticking parts of unofficial gentoo | devmanual into official Gentoo docs, and then silently turning them | into a "policy" enforced under QA disguise is a bad very practice, | and pretending that this has been in the mentioned _howto_ (not | policy) for a long time as just plain silly. Since you haven't | answered the question in one of my previous emails at all, let me ask | again: | | When and where has been the following change discussed and who | approved that? | | http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild.xml?r1=1.25&r2=1.26&root=gentoo Wouldn't know. That was nothing to do with me. I just wrote the original text (or actually, that might not even have been me). It finding its way into the policy docs was devrel's doing. | > | Moreover, the cited howto is wrong, since it will break | > | built_with_use checks | | > No, that's a separate issue. | | No, it isn't. If you want something to have as a policy, it needs to | be error-free, reasonably applicable and not doing more harm than if | it isn't applied at all. And implementing such stuff requires a | proper discussion, considering the consequences and some sort of | consent among affected developers. (Also, that howto example is less | than fortunate/clear, like some user noted in Bug 124401). built_with_use isn't a question of conflicting USE flags. It's a separate question of dependency resolution, and in this situation it *can't* be solved using the method that's been standard for four years or more. | > | The howto also doesn't apply to cases like | > | recode vs. mysql, because that's a completely different | > | functionality, you can't exactly choose which one is better on | > | behalf of the user. | | > No, it does apply. | | No, it doesn't, you can't reasonably favour one of two completely | different functionalities based on some automagic | assumption/developer discretion. That doesn't benefit users in any | way and just produces unexpected results (hey, I explicitely enabled | "recode" use flag and php compiled without, the ebuild is broken, | fix0r it!) By all means warn the user. There's nothing in policy disallowing that. | No, noone should enforce a policy that | | - doesn't exist (see above) The whole devrel handbook is policy, except where otherwise noted. See Mike's reply. | - hasn't been discussed properly and approved (see above) Nothing in the devrel handbook was discussed properly or approved. | - it's consequences haven't been considered wrt whether its benefits | overweight the negatives and whether is useful at all. This one doesn't rule out the policy item in question. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Monday 27 February 2006 11:47, Lance Albertson wrote: > Ciaran McCreesh wrote: > > On Sun, 26 Feb 2006 17:53:20 -0800 Donnie Berkholz > > > > <[EMAIL PROTECTED]> wrote: > > | The maintainer should be the absolute authority over his/her packages, > > | and only the council should be able to overrule maintainer decisions > > | in the case of disagreement between the maintainer and anybody else. > > > > So if the maintainer sticks SANDBOX_DISABLE="1" rm -fr / in global scope > > and refuses to move it, QA will have to get council approval to fix it? > > Use some common sense when showing an example please. We all know that > something that stupid needs to be delt with quickly. we've had at least one ebuild do stuff in /tmp in global scope ... of course that was a mistake the dev felt really bad about and it was fixed once noticed, so not sure this is an appropriate example ;) -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
On Tuesday 28 February 2006 10:08, Jakub Moc wrote: > 28.2.2006, 15:39:40, Ciaran McCreesh wrote: > > On Tue, 28 Feb 2006 10:49:13 +0100 Jakub Moc <[EMAIL PROTECTED]> wrote: > > | No, that's not a policy document, ebuild policy is documented here: > > > > http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?style=printabl > >e&part=3&chap=1 > > > > No, the whole thing is policy. > > No, it isn't. yes, it is ... that's the point of the handbook -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, 28 Feb 2006 16:42:30 +0100 Jakub Moc <[EMAIL PROTECTED]> wrote: > Punting every single piece of broken sh*t from the tree requires > notifying everyone on -dev ml and allowing a period of time before > it's actually done, so silently changing/stating policies is a very > broken practice. This wasn't a silent change. It's been policy for as long as I can remember; it was just made explicit in the devrel documentation with that commit. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, 2006-02-28 at 15:42 +, Ciaran McCreesh wrote:
> On Tue, 28 Feb 2006 16:26:37 +0100 Jakub Moc <[EMAIL PROTECTED]> wrote:
> | If you can't do any better, then please apologize for your conduct
> | and false claims and shut up... TIA.
>
> Sure I can do better. But you didn't originally ask for better, you
> asked for anything. If better's what you're after:
>
> SLOT="${PVR}"
>
> Now, please apologise for insinuating that I don't have any real claims
> to make. I find it extremely offensive that you're questioning my
> technical ability.
Ok, sorry for being dumb :-)
What exactly is the issue there? I don't see the issue in setting SLOT
depending on ... uhm ... some variable. Looks kinda logical at first
glance, but I'm not aware of the issues it causes.
Thanks for explaining,
Patrick
--
Stand still, and let the rest of the universe move
signature.asc
Description: This is a digitally signed message part
Re[2]: [gentoo-dev] [RFC] QA Team's role
28.2.2006, 16:42:46, Ciaran McCreesh wrote:
> On Tue, 28 Feb 2006 16:26:37 +0100 Jakub Moc <[EMAIL PROTECTED]> wrote:
> | If you can't do any better, then please apologize for your conduct
> | and false claims and shut up... TIA.
> Sure I can do better. But you didn't originally ask for better, you
> asked for anything. If better's what you're after:
> SLOT="${PVR}"
Eh? Seen kernel2.eclass? Going to file a bug about that as well? Seen
gst/gstreamer eclasses? Going to file QA bugs about them as well? And -
what's exactly the QA violation there, if you could enlighten us?
Maybe I could point you to
http://dev.gentoo.org/~plasmaroo/devmanual//general-concepts/slotting/ ?
> Now, please apologise for insinuating that I don't have any real claims
> to make. I find it extremely offensive that you're questioning my
> technical ability.
No, I won't apologize, I don't see any reason to do it after all the baloney
you've shown here. I have to agree w/ rl03 that your benefits for this whole
project are net negative.
--
Best regards,
Jakub Moc
mailto:[EMAIL PROTECTED]
GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E
... still no signature ;)
pgpEIQRV01qb0.pgp
Description: PGP signature
[gentoo-dev] Policies (was: [RFC] QA Team's role)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Jakub, Jakub Moc schrieb: | 28.2.2006, 16:29:07, Stephen Bennett wrote: |>>When and where has been the following change discussed and who |>>approved that? |>> |>>http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild.xml?r1=1.25&r2=1.26&root=gentoo |>According to my recollection, it was discussed between members of QA |>and devrel. According to the CVS logs, it was committed by a member of |>devrel, at QA's request. You can't pass it off as a QA project |>conspiracy, since they didn't make the change. | I'm sorry, but discussing such stuff affecting pretty much everyone who | writes ebuilds among a couple of people simply isn't enough to make this a | policy. And then silently applying this and starting to scream "QA | violation, look, what a nasty QA violation!!!" is plain ridiculous. Well, it was common sense before. Especially because it was part of the devmanual. I know, the next argument will be: The devmanual is not official. However, this particular text had been part of the devmanual for a long time. Many devs read it and afaict nobody objected against it while it was 'unofficial'. In my opinion, there was enough time to raise a hand and yell: 'I don't like it'. Beside this, I'd like to support the non-interactive mode on the base of efficiency: It is better to install a package with a default and sane set of USE flags instead of breaking the whole update process. However, this incident should be logged by portage. | Punting every single piece of broken sh*t from the tree requires notifying | everyone on -dev ml and allowing a period of time before it's actually done, | so silently changing/stating policies is a very broken practice. Nobody changed anything. It was written down before in the devmanual and then incorporated into the developer handbook. If you don't agree with the contents, why didn't you raise your opposition earlier? If you agree with the contents, please ask yourself if the current discussion is necessary. I'm looking forward to your answers on the last 2 points. Danny - -- Danny van Dyk <[EMAIL PROTECTED]> Gentoo/AMD64 Project, Gentoo Scientific Project -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEBHk1aVNL8NrtU6IRAlRbAKCH233GWmOQWlRy/DQQh/aRR++4ZACfd230 rYQgmnvH9Y/0YSijnCSAOIc= =QQEa -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] enable UTF8 per default?
Lars Weiler wrote: > * Patrick Lauer <[EMAIL PROTECTED]> [06/02/28 11:58 +0100]: >> Enabling the unicode useflag in the profiles should help our >> international users and should not cause any problems. Are there any >> known bugs / problems this would trigger? Any reasons against that? > > It is enabled by default. At least on ppc. And that since, > uhm, summer 2004? > > I can't say if there are any problems, as I didn't received > a bug for a long time. Well there are a few problems, but yes I cannot name them now. Using Japanese, Cyrillic and English in a few encodings each is a big nightmare. Nowadays I try to move everything to UTF-8, but there are those windoze users and webdevs that make all Japanese in Shift_JIS ... So support of wide range of encodings is a must, but UTF-8 is the truth. > The only thing that's nasty: we don't have any good utf8-fonts for the > console. And not only the console. Even for xterm there are not many good fonts (known to me) that display both Japanese and Cyrillic in regular and bold. Currently there is only on combination that works for me. So fonts, font config and related stuff is what has to be fixed first. Kalin. P.S. And before fixed, it has to be filed... Promise to take notes (again) when I see something. -- |[ ~~ ]| +-> http://ThinRope.net/ <-+ |[ __ ]| -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, 28 Feb 2006 17:11:58 +0100 Patrick Lauer <[EMAIL PROTECTED]> wrote: | Ok, sorry for being dumb :-) | What exactly is the issue there? I don't see the issue in setting SLOT | depending on ... uhm ... some variable. Looks kinda logical at first | glance, but I'm not aware of the issues it causes. PVR includes the revision of an ebuild. This means that if a revbump is made on a webapp package to fix a critical flaw, users will still have the old broken package installed too. This is especially relevant for security issues, but also applies to other kinds of fix. Ebuilds can't override this either. Read on in the eclass and you'll notice that it checks that SLOT hasn't been changed to something sane. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, 28 Feb 2006 17:22:57 +0100 Jakub Moc <[EMAIL PROTECTED]> wrote:
| Eh? Seen kernel2.eclass? Going to file a bug about that as well? Seen
| gst/gstreamer eclasses? Going to file QA bugs about them as well? And
| - what's exactly the QA violation there, if you could enlighten us?
You're misunderstanding the issue. See my explanation to Patrick.
I don't see the same kind of mistake in gst-plugins.eclass, assuming
you're referring to SLOT=${PV_MAJ_MIN} . And kernel-2 is a special
case, since it's not installing an actual program -- this one's been
explained in depth in the past on various lists. If you can point out
any genuine SLOT screwups that I've missed then I'll work to get those
fixed.
| Maybe I could point you to
| http://dev.gentoo.org/~plasmaroo/devmanual//general-concepts/slotting/ ?
Uh... I know how slotting works. I wrote that page, remember?
--
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm
signature.asc
Description: PGP signature
Re: [gentoo-dev] Policies (was: [RFC] QA Team's role)
28.2.2006, 17:24:21, Danny van Dyk wrote: > Hi Jakub, > If you don't agree with the contents, why didn't you raise your > opposition earlier? I don't feel any need to raise opposition against some unofficial manual, what would be the point in that? I'm raising my hand against silently incorporating parts of it (that affect a lot of stuff in the tree) into official docs without a proper discussion, even more so that they are being claimed as an official QA policy now. Documents located in private devspace of some devs are non-official and noone checks their contents for correctness, they are private activity of those devs. > If you agree with the contents, please ask yourself if the current > discussion is necessary. See above. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgpCnRIPUEj5F.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, Feb 28, 2006 at 05:11:58PM +0100, Patrick Lauer wrote: > Ok, sorry for being dumb :-) > What exactly is the issue there? I don't see the issue in setting SLOT > depending on ... uhm ... some variable. Looks kinda logical at first > glance, but I'm not aware of the issues it causes. One issue here is that security revbumps are no longer effective in that the vulnerable version remains installed and must be unmerged manually by the sysadmin. I started a discussion about this very same issue yesterday on -web-user and we hope to resolve it shortly. -- Renat Lumpau all things web-apps C6A838DA 04AF B5EE 17CB 1000 DDA5 D3FC 1338 ADC2 C6A8 38DA America - land of the free* *Void where prohibited, restrictions apply. Cash value 1/100c. pgpIiKs7bJd1b.pgp Description: PGP signature
Re: [gentoo-dev] enable UTF8 per default?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ooh, I'm very much in favor of unicode being enabled by default. It's not like users would be limited *only* to UTF-8 on their new installs, anyway. I'd love to see this implemented. ++ for the suggestion. :) Patrick Lauer wrote: > Hi all, > > at FOSDEM we had a nice discussion about languages, translations etc. > Having people from the US (wolf31o2) who never have problems and people > from Japan (usata) who always have problems with encodings / > charsets / ... was quite interesting. > > During that discussion we realized that having utf-8 not enabled by > default and no utf8 fonts available by default causes lots of > recompilation and reconfiguration. > > Enabling the unicode useflag in the profiles should help our > international users and should not cause any problems. Are there any > known bugs / problems this would trigger? Any reasons against that? > > If there are no objections this should be a small but helpful change. > > On a tangent I wonder if pulling in extra fonts as a dependency of X > makes sense (useflag controlled, enabled by default) - that way the > unicode capabilities are available without any configuration. > > Patrick -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEBH+YrsJQqN81j74RAr1+AJ44WIZB6nSljue+RC//KWAvAFyFUwCdG5cB khBaPU69f8gAhn1MFN+grLs= =0DAj -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re[2]: [gentoo-dev] [RFC] QA Team's role
28.2.2006, 17:35:32, Ciaran McCreesh wrote: > On Tue, 28 Feb 2006 17:11:58 +0100 Patrick Lauer <[EMAIL PROTECTED]> > wrote: > | Ok, sorry for being dumb :-) > | What exactly is the issue there? I don't see the issue in setting SLOT > | depending on ... uhm ... some variable. Looks kinda logical at first > | glance, but I'm not aware of the issues it causes. > PVR includes the revision of an ebuild. This means that if a revbump is > made on a webapp package to fix a critical flaw, users will still have > the old broken package installed too. This is especially relevant for > security issues, but also applies to other kinds of fix. Not including the revision into the SLOT can break the apps by removing the needed files from a live site... I still can't see any *QA* violation there. > Ebuilds can't override this either. Read on in the eclass and you'll > notice that it checks that SLOT hasn't been changed to something sane. Yeah, it checks for that since that's the way the eclass is designed. You can't declare a slot in a kernel ebuild either. Well, starts to be boring - so, either come with something valid from QA standpoint or stop now. -- jakub pgpdnAxBRtsYS.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, Feb 28, 2006 at 04:35:32PM +, Ciaran McCreesh wrote: > Ebuilds can't override this either. Read on in the eclass and you'll > notice that it checks that SLOT hasn't been changed to something sane. Excepting that you can set WEBAPP_MANUAL_SLOT="yes" and set SLOT to whatever the hell you want. But don't let my facts get in the way of your nonsense. -- Renat Lumpau all things web-apps C6A838DA 04AF B5EE 17CB 1000 DDA5 D3FC 1338 ADC2 C6A8 38DA America - land of the free* *Void where prohibited, restrictions apply. Cash value 1/100c. pgpWvP0y62A0D.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, 28 Feb 2006 18:00:03 +0100 Jakub Moc <[EMAIL PROTECTED]> wrote: | > PVR includes the revision of an ebuild. This means that if a | > revbump is made on a webapp package to fix a critical flaw, users | > will still have the old broken package installed too. This is | > especially relevant for security issues, but also applies to other | > kinds of fix. | | Not including the revision into the SLOT can break the apps by | removing the needed files from a live site... I still can't see any | *QA* violation there. Again, that's a design flaw. It's an eclass that's abusing SLOT, thus it's a QA issue. | Yeah, it checks for that since that's the way the eclass is designed. | You can't declare a slot in a kernel ebuild either. One is a design flaw. The other is not. | Well, starts to be boring - so, either come with something valid from | QA standpoint or stop now. This is a valid issue from a QA standpoint. This is also why I'm not going to waste my time doing a proper list -- rather than addressing issues, they are being passed off as irrelevant or even features. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, 28 Feb 2006 17:02:11 + Renat Lumpau <[EMAIL PROTECTED]> wrote: | On Tue, Feb 28, 2006 at 04:35:32PM +, Ciaran McCreesh wrote: | > Ebuilds can't override this either. Read on in the eclass and you'll | > notice that it checks that SLOT hasn't been changed to something | > sane. | | Excepting that you can set WEBAPP_MANUAL_SLOT="yes" and set SLOT to | whatever the hell you want. But don't let my facts get in the way of | your nonsense. And it sticks out a nasty ewarn and says that the ebuild is probably broken. Again, you're dismissing QA issues as nonsense, and you wonder why I don't waste my time doing a full audit. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re[2]: [gentoo-dev] [RFC] QA Team's role
28.2.2006, 18:09:54, Ciaran McCreesh wrote: > On Tue, 28 Feb 2006 18:00:03 +0100 Jakub Moc <[EMAIL PROTECTED]> wrote: | >> PVR includes the revision of an ebuild. This means that if a | >> revbump is made on a webapp package to fix a critical flaw, users | >> will still have the old broken package installed too. This is | >> especially relevant for security issues, but also applies to other | >> kinds of fix. > | > | Not including the revision into the SLOT can break the apps by > | removing the needed files from a live site... I still can't see any > | *QA* violation there. > Again, that's a design flaw. It's an eclass that's abusing SLOT, thus > it's a QA issue. OK, so kernel-2.eclass is abusing the slot as well, go scream on kernel devs. > | Yeah, it checks for that since that's the way the eclass is designed. > | You can't declare a slot in a kernel ebuild either. > One is a design flaw. The other is not. Ah, tell me about the dual standards :P > | Well, starts to be boring - so, either come with something valid from > | QA standpoint or stop now. > This is a valid issue from a QA standpoint. This is also why I'm not > going to waste my time doing a proper list -- rather than addressing > issues, they are being passed off as irrelevant or even features. Next time, rather think a couple of times up before claiming something very broken on a public mailing list where you have no proof for such claims. Will be immensely helpful for everyone involved. Thanks. -- jakub pgpxuk46qcDZF.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
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.
| > | Yeah, it checks for that since that's the way the eclass is
| > | designed. You can't declare a slot in a kernel ebuild either.
|
| > One is a design flaw. The other is not.
|
| Ah, tell me about the dual standards :P
Not dual standards at all. There's nothing wrong with saying "don't do
x unless you're doing y", with appropriate justification.
| > | Well, starts to be boring - so, either come with something valid
| > | from QA standpoint or stop now.
|
| > This is a valid issue from a QA standpoint. This is also why I'm not
| > going to waste my time doing a proper list -- rather than addressing
| > issues, they are being passed off as irrelevant or even features.
|
| Next time, rather think a couple of times up before claiming
| something very broken on a public mailing list where you have no
| proof for such claims. Will be immensely helpful for everyone
| involved.
No proof?
Sheesh, you'll probably claim that this isn't broken next too:
if [ "${IS_UPGRADE}" = "1" ] ; then
einfo "Removing old version ${REMOVE_PKG}"
emerge -C "${REMOVE_PKG}"
fi
--
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm
signature.asc
Description: PGP signature
Re: [gentoo-dev] enable UTF8 per default?
On Tue, 2006-02-28 at 11:58 +0100, Patrick Lauer wrote: > Hi all, > > at FOSDEM we had a nice discussion about languages, translations etc. > Having people from the US (wolf31o2) who never have problems and people > from Japan (usata) who always have problems with encodings / > charsets / ... was quite interesting. > > During that discussion we realized that having utf-8 not enabled by > default and no utf8 fonts available by default causes lots of > recompilation and reconfiguration. > > Enabling the unicode useflag in the profiles should help our > international users and should not cause any problems. Are there any > known bugs / problems this would trigger? Any reasons against that? > > If there are no objections this should be a small but helpful change. > > On a tangent I wonder if pulling in extra fonts as a dependency of X > makes sense (useflag controlled, enabled by default) - that way the > unicode capabilities are available without any configuration. I forget where I read it but I thought that unicode lead to overflows and was considered a general security risk. I wish I knew where I read that but I'm unable to find it. Any list readers know anything relating to that? -- solar <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, Feb 28, 2006 at 05:11:57PM +, Ciaran McCreesh wrote: > And it sticks out a nasty ewarn and says that the ebuild is probably > broken. Which it _probably_ is. See, this is a numbers game. In most cases, if you use the webapp eclass, setting SLOT="0" is incorrect. There are some cases in which it's just fine. Until FEATURES="mindreader" is implemented, how is the eclass to know what you're trying to do? So it prints a warning and doesn't die. Number of angry users storming bugs.g.o - 0. > Again, you're dismissing QA issues as nonsense, and you wonder why I > don't waste my time doing a full audit. No, what I was trying to do was call your distaste for fact-checking nonsensical, apologies if it wasn't crystal clear. Please keep the QA issues coming. -- Renat Lumpau all things web-apps C6A838DA 04AF B5EE 17CB 1000 DDA5 D3FC 1338 ADC2 C6A8 38DA America - land of the free* *Void where prohibited, restrictions apply. Cash value 1/100c. pgpiWUqXDtNG8.pgp Description: PGP signature
Re: [gentoo-dev] enable UTF8 per default?
On Tue, 28 Feb 2006 12:47:33 -0500 solar <[EMAIL PROTECTED]> wrote: | I forget where I read it but I thought that unicode lead to overflows | and was considered a general security risk. I wish I knew where I read | that but I'm unable to find it. | | Any list readers know anything relating to that? Eh, not really. With non-utf-8 you could argue that it's an increased risk, since you get non-string-terminating nulls, but with utf-8 those aren't an issue. It's not really a very well substantiated claim. It's like saying "GUI programming leads to bugs" or "internationalisation leads to program crashes". Yes, it's possible (in C, anyway) to screw up your buffer routines when converting code to handle utf-8, but then it's always possible to screw up buffer routines. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, 28 Feb 2006 17:38:10 +
Ciaran McCreesh <[EMAIL PROTECTED]> wrote:
> if [ "${IS_UPGRADE}" = "1" ] ; then
> einfo "Removing old version ${REMOVE_PKG}"
>
> emerge -C "${REMOVE_PKG}"
> fi
Uh, what the fuck is that doing in an eclass ?
--
gentoo-dev@gentoo.org mailing list
Re[2]: [gentoo-dev] [RFC] QA Team's role
28.2.2006, 18:11:57, Ciaran McCreesh wrote: > On Tue, 28 Feb 2006 17:02:11 + Renat Lumpau <[EMAIL PROTECTED]> wrote: > | On Tue, Feb 28, 2006 at 04:35:32PM +, Ciaran McCreesh wrote: | >> Ebuilds can't override this either. Read on in the eclass and you'll | >> notice that it checks that SLOT hasn't been changed to something | >> sane. > | > | Excepting that you can set WEBAPP_MANUAL_SLOT="yes" and set SLOT to > | whatever the hell you want. But don't let my facts get in the way of > | your nonsense. > And it sticks out a nasty ewarn and says that the ebuild is probably > broken. > Again, you're dismissing QA issues as nonsense, and you wonder why I > don't waste my time doing a full audit. Ah, so this is the horrible and nasty ewarn? ewarn "This ebuild overrides the default SLOT behaviour for webapps" ewarn "If this package installs files into the htdocs dir, this is" ewarn "probably a bug in the ebuild." Sigh... what kind of QA issue is that? Go file bugs about those nasty QA notices portage spits out every now and then as well, if you are so concerned about warnings. Indeed, please don't waste your time and first of all don't waste ours. Go audit whatever you want, but please keep this off-list. Or maybe don't stare on the screen if ewarns scare you that much. ;) -- jakub pgp9R7YoX0YoI.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, 2006-02-28 at 17:38 +, Ciaran McCreesh wrote:
> Sheesh, you'll probably claim that this isn't broken next too:
>
> if [ "${IS_UPGRADE}" = "1" ] ; then
> einfo "Removing old version ${REMOVE_PKG}"
>
> emerge -C "${REMOVE_PKG}"
> fi
Ciaran,
(and this is valid for all emails to technical lists,)
please save us some time and many emails by stating what is wrong when
you show a QA violation.
Many among us don't think in assembler and don't know enough about the
code to decide if/why something is wrong. This in turn causes someone
(like me) to send an email asking what is wrong, causing another reply
by you etc. etc.
It's a bit like me stating:
"The bug is in line 14:
i+=2
"
If you don't know the code you won't understand why.
Now if I said "line 14 increments by two, but then you won't ever get
out of the loop since the exit condition won't be met" everyone could
understand it and evaluate my statement.
If you show a wrong code snippet please explain _why_ it is wrong in the
same email.
Thanks,
Patrick
--
Stand still, and let the rest of the universe move
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] QA Team's role
On 2/28/06, Patrick Lauer <[EMAIL PROTECTED]> wrote:
> On Tue, 2006-02-28 at 17:38 +, Ciaran McCreesh wrote:
> > Sheesh, you'll probably claim that this isn't broken next too:
> >
> > if [ "${IS_UPGRADE}" = "1" ] ; then
> > einfo "Removing old version ${REMOVE_PKG}"
> >
> > emerge -C "${REMOVE_PKG}"
> > fi
> Ciaran,
> (and this is valid for all emails to technical lists,)
> please save us some time and many emails by stating what is wrong when
> you show a QA violation.
> Many among us don't think in assembler and don't know enough about the
> code to decide if/why something is wrong. This in turn causes someone
> (like me) to send an email asking what is wrong, causing another reply
> by you etc. etc.
>
> It's a bit like me stating:
> "The bug is in line 14:
> i+=2
> "
> If you don't know the code you won't understand why.
>
> Now if I said "line 14 increments by two, but then you won't ever get
> out of the loop since the exit condition won't be met" everyone could
> understand it and evaluate my statement.
>
> If you show a wrong code snippet please explain _why_ it is wrong in the
> same email.
I believe the bug is calling emerge from within the eclass.
>
> Thanks,
>
> Patrick
>
> --
> Stand still, and let the rest of the universe move
>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.2.1-ecc0.1.6 (GNU/Linux)
>
> iD8DBQBEBI+UqER3hOUoZM4RAjzxAJ9tvaSOY3625NaptPTj/yLxXrIXJACeITwy
> 43JQjZpI+HEckc6Mla3f9l0=
> =so5q
> -END PGP SIGNATURE-
>
>
>
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, Feb 28, 2006 at 06:59:49PM +0100, Patrick Lauer wrote: > If you show a wrong code snippet please explain _why_ it is wrong in the > same email. Ehm you mean it is not obvious that calling emerge inside an eclass is utterly wrong ? -- Fernando J. Pereda Garcimartín Gentoo Developer (Alpha,net-mail,mutt,git) 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpCBNysRgMmy.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, 28 Feb 2006 18:59:49 +0100 Patrick Lauer <[EMAIL PROTECTED]> wrote: > (and this is valid for all emails to technical lists,) > please save us some time and many emails by stating what is wrong when > you show a QA violation. This is a technical discussion list, and as such it is fair to assume that anyone getting involved in a discussion on a particularly topic knows enough about said topic to understand what is going on. If you can't see what's wrong with the snippet he gave, then you shouldn't be in the discussion, and, frankly, probably shouldn't have commit rights to the tree either. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, 28 Feb 2006 18:59:49 +0100 Patrick Lauer <[EMAIL PROTECTED]> wrote: | (and this is valid for all emails to technical lists,) | please save us some time and many emails by stating what is wrong when | you show a QA violation. Oh come on. I'm not going to insult the intelligence of people reading this list by explaining something that frickin' obvious. When it's a subtle issue I explain why it's wrong. When it isn't, I try to avoid wasting everyone's time by making them read a huge explanation of something they all already know. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
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.
| > | Yeah, it checks for that since that's the way the eclass is
| > | designed. You can't declare a slot in a kernel ebuild either.
|
| > One is a design flaw. The other is not.
|
| Ah, tell me about the dual standards :P
Not dual standards at all. There's nothing wrong with saying "don't do
x unless you're doing y", with appropriate justification.
| > | Well, starts to be boring - so, either come with something valid
| > | from QA standpoint or stop now.
|
| > This is a valid issue from a QA standpoint. This is also why I'm not
| > going to waste my time doing a proper list -- rather than addressing
| > issues, they are being passed off as irrelevant or even features.
|
| Next time, rather think a couple of times up before claiming
| something very broken on a public mailing list where you have no
| proof for such claims. Will be immensely helpful for everyone
| involved.
No proof?
Sheesh, you'll probably claim that this isn't broken next too:
if [ "${IS_UPGRADE}" = "1" ] ; then
einfo "Removing old version ${REMOVE_PKG}"
emerge -C "${REMOVE_PKG}"
fi
Semantics of the logic aside, calling emerge from within an ebuild is a
BIG nono.
-Alec Warner
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] enable UTF8 per default?
On Tue, Feb 28, 2006 at 12:47:33PM -0500, solar wrote: > I forget where I read it but I thought that unicode lead to overflows > and was considered a general security risk. I wish I knew where I read > that but I'm unable to find it. > > Any list readers know anything relating to that? > It's true that many overflows have been found in unicode aware applications, like the zillion unicode overflows in Internet Explorer for example. But that shouldn't lead to considering unicode a general security risk in my mind even though the apache team uses ascii in the default configuration to protect against bugs in poorly written applications. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Policies (was: [RFC] QA Team's role)
On Tuesday 28 February 2006 11:39, Jakub Moc wrote: > 28.2.2006, 17:24:21, Danny van Dyk wrote: > > If you don't agree with the contents, why didn't you raise your > > opposition earlier? > > I don't feel any need to raise opposition against some unofficial manual, > what would be the point in that? I'm raising my hand against silently > incorporating parts of it (that affect a lot of stuff in the tree) into > official docs without a proper discussion, even more so that they are being > claimed as an official QA policy now. Documents located in private devspace > of some devs are non-official and noone checks their contents for > correctness, they are private activity of those devs. input was solicited from the developer community before about ciaranm's unofficial manual with notes that the plan was to incorporate it piece by piece into the official dev handbook -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
On Tuesday 28 February 2006 13:00, Jakub Moc wrote: > 28.2.2006, 18:11:57, Ciaran McCreesh wrote: > > On Tue, 28 Feb 2006 17:02:11 + Renat Lumpau <[EMAIL PROTECTED]> wrote: > > | On Tue, Feb 28, 2006 at 04:35:32PM +, Ciaran McCreesh wrote: > | >> Ebuilds can't override this either. Read on in the eclass and you'll > | >> notice that it checks that SLOT hasn't been changed to something > | >> sane. > > | > > | Excepting that you can set WEBAPP_MANUAL_SLOT="yes" and set SLOT to > > | whatever the hell you want. But don't let my facts get in the way of > > | your nonsense. > > > > And it sticks out a nasty ewarn and says that the ebuild is probably > > broken. > > > ewarn "This ebuild overrides the default SLOT behaviour for webapps" > ewarn "If this package installs files into the htdocs dir, this is" > ewarn "probably a bug in the ebuild." > > > Sigh... what kind of QA issue is that? which part dont you understand ? the user sets a variable and then is told that the package probably contains a bug ... seems pretty confusing to me -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, 2006-02-28 at 18:19 +, Stephen Bennett wrote: > On Tue, 28 Feb 2006 18:59:49 +0100 > Patrick Lauer <[EMAIL PROTECTED]> wrote: > > > (and this is valid for all emails to technical lists,) > > please save us some time and many emails by stating what is wrong when > > you show a QA violation. > > This is a technical discussion list, and as such it is fair to assume > that anyone getting involved in a discussion on a particularly topic > knows enough about said topic to understand what is going on. If you > can't see what's wrong with the snippet he gave, then you shouldn't be > in the discussion, and, frankly, probably shouldn't have commit rights > to the tree either. Yeah, like it took me about two minutes of staring at the snippet to see why it's evil when reading a short explanation would have made me see that in 15 seconds. After all not everyone reading this list is a code ninja, please just stop this email pingpong and (like we do it with bugs) explain what is the issue instead of letting people guess. That might even teach those that are not yet super-gurus and is in general a nice thing to do. -- Stand still, and let the rest of the universe move signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, Feb 28, 2006 at 06:12:57PM +, Ciaran McCreesh wrote: > Oh come on. I'm not going to insult the intelligence of people reading > this list by explaining something that frickin' obvious. When it's a > subtle issue I explain why it's wrong. When it isn't, I try to avoid > wasting everyone's time by making them read a huge explanation of > something they all already know. Explaining stuff usually helps more than elitism. Those who already know it can simply skip it, those who don't may learn a bit and everyone wins. A lot of people are subscribed to this list and not everyone is an ebuild dev, but some may be tomorrow's devs. cheers, Wernfried -- Wernfried Haas (amne) - amne at gentoo dot org Gentoo Forums: http://forums.gentoo.org IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org pgpaEgvuEtNEa.pgp Description: PGP signature
Re[2]: [gentoo-dev] [RFC] QA Team's role
28.2.2006, 18:38:10, Ciaran McCreesh wrote:
> Sheesh, you'll probably claim that this isn't broken next too:
> if [ "${IS_UPGRADE}" = "1" ] ; then
> einfo "Removing old version ${REMOVE_PKG}"
> emerge -C "${REMOVE_PKG}"
> fi
No, I won't claim that... I'd rather love to know why didn't you point out
to an obvious eclass flaw about 30 emails and many hours ago, saving us from
all the eclass formating, slotting and ewarn blurb. The above needs to be
fixed, period.
To return to the original topic - focus your QA efforts on real issues. Same
goes for that non-interactivity stuff. QA that serves no other purpose than
inventing problems to enforce an inevitably hackish solution (there's no
good one because the needed tools are not available) is not useful at all.
There's nothing useful in inventing policies that create more problems than
they solve and that are forcing shitty bash code into the tree to work
around missing features.
Portage is a tool to install and manage packages, and serves no good purpose
on its own. Crippling installed packages and their available features for
the sole purpose of having nice ebuild tree with clean bash code is not what
QA is for. Improving the whole process is fine and welcome, as long as it
doesn't unnecessarily interfere with the desired outcome. Users need to
install some software they want to use and need its features, portage and
ebuids are only the means to do that, not a holy cow.
--
jakub
pgpbyDVjG5w40.pgp
Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, 28 Feb 2006 13:02:10 -0500,
Alec Warner <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
>
> >if [ "${IS_UPGRADE}" = "1" ] ; then
> >einfo "Removing old version ${REMOVE_PKG}"
> >
> >emerge -C "${REMOVE_PKG}"
> >fi
> >
> >
> >
> Semantics of the logic aside, calling emerge from within an ebuild is
> a BIG nono.
>
Reading the comments in the eclass, i can undestand the motivation.
# why do we do this? well ...
#
# normally, emerge -u installs a new version and then removes the
# old version. however, if the new version goes into a different
# slot to the old version, then the old version gets left behind
#
# if USE=-vhosts, then we want to remove the old version, because
# the user is relying on portage to do the magical thing for it
Two suggestions (don't really know what they are worth though):
* Short term, still evil, but less than calling emerge:
pkg_postinst() {
...
if ! use vhost ; then
echo 0 > ${ROOT}var/db/pkg/${CATEGORY}/${PN}-${PVR}/SLOT
fi
}
This way, emerge's autoclean (the slow one, at the end) would
remove old version of USE="-vhost" packages, since they would be
all slotted "0".
* Long term, don't know how difficult it would be: Do some kind of
USE-expansion of the SLOT variable, to allow something like
SLOT="vhost? ( ${PVR} ) !vhost? ( 0 )"
This would only affect SLOT when read from porttree sure. In vartree,
and in the ebuild env in general, it should still be the reduced
version ("${PVR}" or "0") that is used.
--
TGL.
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] enable UTF8 per default?
On Tue, 28 Feb 2006 12:47:33 -0500 solar <[EMAIL PROTECTED]> wrote: > I forget where I read it but I thought that unicode lead to overflows > and was considered a general security risk. I wish I knew where I read > that but I'm unable to find it. Well, stuff I could find includes: http://www.kde.org/info/security/advisory-20060119-1.txt buggy UTF-8 decoder in KDE - this is an overflow error, which as ciaranm says is a risk applicable to anything. It's a bug in KDE, not in UTF-8 as such. Perhaps this is what was at the back of your mind. http://www.izerv.net/idwg-public/archive/0181.html risks of using UTF-8; in particular the use of separate validators which won't process things exactly the same way the application does. Also homograph risks associated with allowing more than one encoding for a character. http://www.eeye.com/html/Research/Advisories/AD20010705.html example of UTF-8(ish) used to fool IDSs by using alternative non-standard encodings that IDSs aren't aware of. This actually is another example of issues with secondary validators described in the link above - they're not guaranteed to parse things exactly the same way the application does. http://www.microsoft.com/mspress/books/sampchap/5612b.asp describes a number of risks of accepting UTF-8, including the above. So far I haven't found anything that could be considered a general security risk, but that doesn't prove much :) -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, Feb 28, 2006 at 08:11:26PM +0100, Thomas de Grenier de Latour wrote:
> On Tue, 28 Feb 2006 13:02:10 -0500,
> Alec Warner <[EMAIL PROTECTED]> wrote:
>
> > Ciaran McCreesh wrote:
> >
> > >if [ "${IS_UPGRADE}" = "1" ] ; then
> > >einfo "Removing old version ${REMOVE_PKG}"
> > >
> > >emerge -C "${REMOVE_PKG}"
> > >fi
For those who are interested, ciaranm has kindly filed bug #124443, so please
comment there.
--
Renat Lumpau all things web-apps
C6A838DA 04AF B5EE 17CB 1000 DDA5 D3FC 1338 ADC2 C6A8 38DA
America - land of the free*
*Void where prohibited, restrictions apply. Cash value 1/100c.
pgpoiK0UtNaq9.pgp
Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, Feb 28, 2006 at 08:11:26PM +0100, Thomas de Grenier de Latour wrote:
> On Tue, 28 Feb 2006 13:02:10 -0500,
> Alec Warner <[EMAIL PROTECTED]> wrote:
>
> > Ciaran McCreesh wrote:
> >
> > >if [ "${IS_UPGRADE}" = "1" ] ; then
> > >einfo "Removing old version ${REMOVE_PKG}"
> > >
> > >emerge -C "${REMOVE_PKG}"
> > >fi
That's #124440, not #124443 which is the SLOT issue.
--
Renat Lumpau all things web-apps
C6A838DA 04AF B5EE 17CB 1000 DDA5 D3FC 1338 ADC2 C6A8 38DA
America - land of the free*
*Void where prohibited, restrictions apply. Cash value 1/100c.
pgpsXqzpALYvB.pgp
Description: PGP signature
