[gentoo-dev] Re: redistribute intel rpms
Sébastien Fabbro posted on Fri, 06 Nov 2009 16:04:41 -0800 as excerpted: We have a few fetch restricted Intel packages in the main tree (icc, ifc, mkl, ipp, tbb). All except tbb are closed-source but free with non-commercial licenses. Lately upstream has repackaged the icc and ifort (ifc) as a big tar blob containing all of them, but also release some of them separately. For various reasons we would like to keep separate ebuilds. The problem is the separate packages have common libraries, causing duplication and file collisions. So the idea was to download the tar blob which contain a few binary rpms and base new ebuilds on these rpms. To here looks reasonable... This means we will have to re-distribute the rpms on our mirrors. This conclusion doesn't necessarily follow from the above, unless you summarized-out the important technical issues. See below. I can't understand from the many licenses if we are allowed to do it, it surprisingly looks like we can do it. No position on the legal aspect, except that if we can avoid the question by not distributing them at all, much as we do with various other restrict=mirror packages, that would seem to me to be the way to go. What I'm missing is why a combination of the approach used for, say, the kde split ebuilds, and the standard restrict=mirror ebuilds, can't be used. It seems to me that the ebuilds could each require the big combo- tarball, extract only the necessary component rpms, and go from there, much as the kde split ebuilds do with the big combo tarballs that kde ships except they don't have the rpms step to worry about and I expect the kde interdependencies were far more complex to try to work out (you'd need to ask the gentoo/kde folks on that to be sure, but from a user who followed the experimentals to some degree, that certainly seems to be the case). The big combo tarball could then be restrict=mirror or whatever, with or without a specific user click-thru (and restrict=interactive or whatever) as necessary and already used on some packages, following existing policies. Of course, there's certainly the complexity of automating the tarball unpack of only the specific needed components, but gentoo/kde has a **LOT** of experience with that sort of thing by now, and I'm sure they'd be happy to share hints and helpful tactical strategies with you, if you ask, and there's no way I can conceive it being even half as dependency convoluted as kde4 was to figure out, so it should be FAR easier. -- 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
[gentoo-dev] Re: [gentoo-user] got an error while emerging dev-python/setuptools-0.6.4
Xi Shen posted on Sat, 07 Nov 2009 16:31:16 +0800 as excerpted: i am using gentoo amd64, and have just changed my profile to default/linux/amd64/10.0 as it is recommended. then i ran emerge -auvND world, and got the following error while emerging dev-python/setuptools-0.6.4 * Installation of dev-python/setuptools-0.6.4 with Python 2.6... python2.6 setup.py build -b build-2.6 install --root=/var/tmp/portage/dev-python/setuptools-0.6.4/image/ --no-compile /usr/lib64/python2.6/site-packages/Pyrex/Compiler/Errors.py:17: DeprecationWarning: BaseException.message has been deprecated as of Python 2.6 self.message = message Traceback (most recent call last): File setup.py, line 56, in module from distribute_setup import _before_install ImportError: cannot import name _before_install Go to bugs.gentoo.org, search for ALL dev-pyton/setuptools, and check the bugs from say 28 on. In this case, the bottom four bugs as of this writing are all duplicates on this, with http://bugs.gentoo.org/show_bug.cgi?id=292095 ... being the one the other three are duplicates off of. Doing that gets you about the same information you're going to get by posting here, only you don't have to wait for a reply to get it. In this case, the bug should be already fixed. Resync and try again. If it does happen to still be an issue after a sync and retry, then you may have another bug to worry about. File it and mention that you DID sync and try again, and either your mirror is lagging (bug in the mirror infrastructure) or there's another ebuild bug to worry about. -- 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
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-block/gparted: gparted-0.4.3.ebuild
Le samedi 07 novembre 2009 à 09:47 +, Samuli Suominen (ssuominen) a écrit : ssuominen09/11/07 09:47:59 Modified: gparted-0.4.3.ebuild Log: Remove USE kde from this almost unused ebuild to avoid breaking deptree for sparc. (Portage version: 2.2_rc48/cvs/Linux x86_64) No bug report nor changelog entry and no word to herd members, please ? Also, almost unused ? really ? The kde use flag is a request from kde users. -- Gilles Dartiguelongue e...@gentoo.org Gentoo signature.asc Description: Ceci est une partie de message numériquement signée
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-block/gparted: gparted-0.4.3.ebuild
Gilles Dartiguelongue wrote: Le samedi 07 novembre 2009 à 09:47 +, Samuli Suominen (ssuominen) a écrit : ssuominen09/11/07 09:47:59 Modified: gparted-0.4.3.ebuild Log: Remove USE kde from this almost unused ebuild to avoid breaking deptree for sparc. (Portage version: 2.2_rc48/cvs/Linux x86_64) No bug report nor changelog entry and no word to herd members, please ? Also, almost unused ? really ? The kde use flag is a request from kde users. ?! gparted-0.4.3.ebuild:KEYWORDS=amd64 ppc sparc x86 gparted-0.4.5.ebuild:KEYWORDS=amd64 ppc x86 It's only used on sparc and they won't have kde-base/kdesu in stable soon as we mask 3.5.10. The USE=kde is present in all other versions. Let's stop wasting time? Thanks.
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-block/gparted: gparted-0.4.3.ebuild
In the future , please have a discussion on IRC, that's a bit more constructive. I meant why flood on ML for that if we can discuss on IRC together ? We're adults or nop ? (I already said that to ssuominen on #-kde). To conclude, what's Gilles wanted to say is there are rules, so ALL developers (even linus torvalds's father himself) must respect them :). That's not a question in a quizz ;) ? Regards, Romain. -- Romain Perier Gentoo Linux Developer Responsabilities : GNOME/KDE/AMD64/Desktop-effects/Sunrise E-Mail : mrpo...@gentoo.org Site : http://dev.gentoo.org/~mrpouet Blog : http://blogs.gentoo.org/mrpouet GnuPG FP : 5728 DC13 9600 864E 2C37 7D1F 3791 7B66 3B94 72EF GnuPG ID : 3B9472EF signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-block/gparted: gparted-0.4.3.ebuild
Romain Perier wrote: In the future , please have a discussion on IRC, that's a bit more constructive. I meant why flood on ML for that if we can discuss on IRC together ? We're adults or nop ? (I already said that to ssuominen on #-kde). To conclude, what's Gilles wanted to say is there are rules, so ALL developers (even linus torvalds's father himself) must respect them :). That's not a question in a quizz ;) ? Regards, Romain. mrpouet++ That said, I'm seconds away from masking KDE 3.5.10, only fixing gentoo-x86 in a shape it's possible. So sorry everyone for not stopping on every single package and metadata.xml. Just getting this done.
[gentoo-dev] Lastrite: KDE 3.5.10
# Samuli Suominen ssuomi...@gentoo.org (07 Nov 2009) # # Mask KDE 3.5.10 for removal, excluding the dependencies # required for stable koffice. Removed in 30 days. # [ .. ] Everything from kde-base/ matching =3.5* excluding the deps of koffice. # Samuli Suominen ssuomi...@gentoo.org (06 Nov 2009) # Cleaning out packages with KDE3 dependencies. # Masked for removal in 30 days. x11-themes/qinx kde-misc/kopete-antispam-kde3 kde-misc/koppermine www-client/kita sci-mathematics/koctave dev-util/kdesvn-1.4 x11-terms/kuake app-cdr/koverartist net-misc/kbandwidth net-irc/vyqchat net-irc/konversation-1.2 net-im/kopete-otr dev-util/kscope-1.9 net-p2p/kmldonkey-2 app-backup/keep media-sound/musicman app-antivirus/klamav net-p2p/ktorrent-3 net-misc/smb4k-0.10 net-im/kmess-2 x11-themes/domino x11-themes/crystal-2 x11-themes/comix x11-themes/baghira x11-themes/alloy x11-themes/activeheart x11-themes/fahrenheit x11-themes/fusionx-aqua x11-themes/knifty x11-themes/kwin-neos x11-themes/liquid x11-themes/polyester-2 x11-themes/reinhardtstyle x11-themes/ridge x11-themes/thinkeramik x11-misc/karamba x11-misc/dekorator app-pda/libopensync-plugin-kdepim [ .. ] Themes for KDE3, and few unported apps which most, if not all have replacements or KDE4 version available.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-block/gparted: gparted-0.4.3.ebuild
Le samedi 07 novembre 2009 à 13:31 +0100, Romain Perier a écrit : In the future , please have a discussion on IRC, that's a bit more constructive. I meant why flood on ML for that if we can discuss on IRC together ? We're adults or nop ? (I already said that to ssuominen on #-kde). email is a valid method of communication, I'm not in front of my computer all day long... I see no flood either, reviews are meant to be sent to gentoo-dev. Look for yourself when you hit reply-to button on a message from gentoo-commits list. -- Gilles Dartiguelongue e...@gentoo.org Gentoo signature.asc Description: Ceci est une partie de message numériquement signée
Re: [gentoo-dev] Re: [RFC] Improve policy of stabilizations
Hi! On Thu, 05 Nov 2009, Petteri Räty wrote: In the past when smaller arches were not that active we used to mark Java packages stable after testing by at least one arch team. The probability to find arch specific issues in something like Java is not so high so I think arrangements like this are acceptable when the arch teams have problems keeping up. For alpha, the java keywording policy is easy: don't. We currently don't have any working JVM/JRE/JDK, so there's no point in adding Java packages. We *do* have dev-java/java-config keyworded, though the reason escapes me at the moment :) Regards, Tobias -- printk(NONONONOO\n); linux-2.6.6/drivers/atm/zatm.c
Re: [gentoo-dev] Re: [RFC] Improve policy of stabilizations
В Птн, 06/11/2009 в 14:07 -0800, Zac Medico пишет: Fabian Groffen wrote: On 06-11-2009 19:48:16 +0530, Nirbheek Chauhan wrote: On Fri, Nov 6, 2009 at 1:42 AM, Petteri Räty betelge...@gentoo.org wrote: In the past when smaller arches were not that active we used to mark Java packages stable after testing by at least one arch team. The probability to find arch specific issues in something like Java is not so high so I think arrangements like this are acceptable when the arch teams have problems keeping up. I think the same should be extended to other languages such as Perl and Python (unless they have portions which are C/C++) Sounds like we could benefit from the noarch approach known in the RPM world, such that all these packages can also be immediately keyworded and stabilised for all arches. Would greatly simplify things for a great deal of packages, maybe? We could introduce noarch and ~noarch KEYWORDS, add noarch to the default ACCEPT_KEYWORDS setting for all profiles, and instruct unstable users to add ~noarch to ACCEPT_KEYWORDS. Looks like this will not work for all noarch packages. Stardict dictionary itself is noarch, but it RDEPENDS on stardict package which is keyworded only on some archs. So we'll be forced either to keyword stardict on all archs or we need to introduce some new way to work with such situations. -- Peter.
[gentoo-dev] QA: package.mask policies
Hi, since I aint got blag i will polute our lovely mailing list (sorry if i hit some in-middle flame :P). Currently i've been reviewing the package.mask file (since we have to keep with it for a while [no package.mask folder near us :)] we have to trim it down and keep sane). NOTE: The p.mask as folder situation was agreed upon so dont reply about THAT but focus on what follows below this point in your replies. While i was reading it there are 5 major use cases for stuff in it. - Masking beta/rc/alpha/development_branch stuff - Masking live ebuild - Masking stable releases for testing - Masks for removal (those are quite moving in and out ;]) - Masks for security issues (mostly games) So lets go one by one and rationalize on wether we need it or not. * Masking beta... This masks are good if the software release is KNOWN to break previous behaviour or degrade user experience. Otherwise the software should not be masked (its TESTING for purpose, not stable). Also the maintainer should watch if the testing branch is still relevant (why on earth we have masked 4.0.3_p20070403 version of screen when newer 4.3 is stable ;]) and remove the branch+mask when needed. * Masking live... Heck no. This is not proper usage. Just use keywords mask. KEYWORDS=. Problem solved and the package.mask is smaller. (Note, in overlays do what ever you want, since it does not polute the main mask from g-x86). * Masking stable releases... Here i found most interesting stuff around (for example mask for testing from 2006, yeah not ~ material after 3 years?! :P) There should be policy defined that you can add the new release under p.mask if you see it fit, but the mask can stay only for 6 months (less/more, suggestions?) and then it must be unmasked, or have really high activity on tracker bug and good reasoning (mask for ruby-1.9 and so on). * Masks for removal... Nothing to say here, they are done quite well right now, and treecleaners kill them when they got time :] * Masks for security... These are the only one masks that are permanent (probably none will fix the nethack,...). They should be maybe even kept on the bottom of the package.mask file all together and separated with some comment, so they are always easy to spot from first look on that file. Any more ideas/suggestions to the above? Cheers Tomáš Chvátal Gentoo Linux Developer [KDE/Overlays/QA/Sunrise/X11] E-Mail : scarab...@gentoo.org GnuPG FP: 94A4 5CCD 85D3 DE24 FE99 F924 1C1E 9CDE 0341 4587 GnuPG ID: 03414587 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] QA: package.mask policies
Hi all, I'm not QA, but I'll go ahead and add my comments to this also. On Sat, Nov 07, 2009 at 06:24:10PM +0100, Tom Chv??tal wrote: * Masking beta... This masks are good if the software release is KNOWN to break previous behaviour or degrade user experience. Otherwise the software should not be masked (its TESTING for purpose, not stable). Agreed. If it works and does not cause issues for users or degrade their experience, it should be in ~arch, not in p.mask. Also the maintainer should watch if the testing branch is still relevant (why on earth we have masked 4.0.3_p20070403 version of screen when newer 4.3 is stable ;]) and remove the branch+mask when needed. Definitely. If a newer version of a package is stable, or in ~arch for that matter, why do we still have the old version in the tree and masked while the newer version is unmasked? * Masking live... Heck no. This is not proper usage. Just use keywords mask. KEYWORDS=. Problem solved and the package.mask is smaller. (Note, in overlays do what ever you want, since it does not polute the main mask from g-x86). True. If we mask live ebuilds with KEYWORDS=, there isn't a reason to put them in p.mask that I can think of. * Masking stable releases... Here i found most interesting stuff around (for example mask for testing from 2006, yeah not ~ material after 3 years?! :P) There should be policy defined that you can add the new release under p.mask if you see it fit, but the mask can stay only for 6 months (less/more, suggestions?) and then it must be unmasked, or have really high activity on tracker bug and good reasoning (mask for ruby-1.9 and so on). Off the top of my head, I think this falls under category 1 above as well. If a new release of a package and everything that uses the new package can be installed in a way that does not degrade the user's experience if they want to use the older release, it doesn't need to be in p.mask. In general, I don't think a new release of a package should be added to p.mask unless it fits category 1 above. Things that have been masked for testing for years need to have a decision made about them -- keep them in the tree and unmask them or remove them. -- William Hubbs gentoo accessibility team lead willi...@gentoo.org pgpOXpVFPLLey.pgp Description: PGP signature
[gentoo-dev] Re: QA: package.mask policies
Hi, William Hubbs willi...@gentoo.org: * Masking live... Heck no. This is not proper usage. Just use keywords mask. KEYWORDS=. Problem solved and the package.mask is smaller. (Note, in overlays do what ever you want, since it does not polute the main mask from g-x86). True. If we mask live ebuilds with KEYWORDS=, there isn't a reason to put them in p.mask that I can think of. Many users use ** in their p.keywords file and get a live ebuild then. V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://gentoo.faulhammer.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] Re: QA: package.mask policies
On Sat, Nov 07, 2009 at 07:33:12PM +0100, Christian Faulhammer wrote: Hi, William Hubbs willi...@gentoo.org: * Masking live... Heck no. This is not proper usage. Just use keywords mask. KEYWORDS=. Problem solved and the package.mask is smaller. (Note, in overlays do what ever you want, since it does not polute the main mask from g-x86). True. If we mask live ebuilds with KEYWORDS=, there isn't a reason to put them in p.mask that I can think of. Many users use ** in their p.keywords file and get a live ebuild then. If a user runs ~arch even for one package, they should be able to recover if things break temporarily. So, if they are putting ** in their package.keywords for packages, that is another level past ~arch to me. They should definitely be able to recover in that situation. -- William Hubbs gentoo accessibility team lead willi...@gentoo.org pgphl6oorkDVm.pgp Description: PGP signature
[gentoo-dev] Re: QA: package.mask policies
Christian Faulhammer posted on Sat, 07 Nov 2009 19:33:12 +0100 as excerpted: William Hubbs willi...@gentoo.org: * Masking live... Heck no. This is not proper usage. Just use keywords mask. KEYWORDS=. Problem solved and the package.mask is smaller. (Note, in overlays do what ever you want, since it does not polute the main mask from g-x86). True. If we mask live ebuilds with KEYWORDS=, there isn't a reason to put them in p.mask that I can think of. Many users use ** in their p.keywords file and get a live ebuild then. There's two different ways of seeing that. 1) Users using ** in their package.keywords file should know enough about what they're doing to use their own package.mask, as well. If they're using ** in the keywords file, they're /saying/ they're reading to handle such things, after all, why shouldn't we let them? 2) That won't necessarily stop the bugs from rolling in. Some devs may get tired of live pkg bugs and package.mask it, thus putting up a double- barrier to the live ebuild. If users jump BOTH barriers and fall over the ledge, well... maybe they /need/ that Darwin Award! =:^] Thus I can see either way. If a dev's sick of dealing with live package bugs, maybe a package.mask will keep a few more folks from jumping over that ledge and filing them. -- 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
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-block/gparted: gparted-0.4.3.ebuild
On Sat, Nov 7, 2009 at 5:43 AM, Samuli Suominen ssuomi...@gentoo.org wrote: I'm seconds away from masking KDE 3.5.10, only fixing gentoo-x86 in a shape it's possible. So sorry everyone for not stopping on every single package and metadata.xml. Just getting this done. Quantity isn't a replacement for quality. Nobody's pressuring you, so you can take all the time you need to do things properly. You're a volunteer so you can do whatever you want, including a lousy job and not respecting rules. Just don't expect everybody to be happy with that. Denis.
Re: [gentoo-dev] Re: [RFC] Improve policy of stabilizations
Peter Volkov wrote: We could introduce noarch and ~noarch KEYWORDS, add noarch to the default ACCEPT_KEYWORDS setting for all profiles, and instruct unstable users to add ~noarch to ACCEPT_KEYWORDS. Looks like this will not work for all noarch packages. Stardict dictionary itself is noarch, but it RDEPENDS on stardict package which is keyworded only on some archs. So we'll be forced either to keyword stardict on all archs or we need to introduce some new way to work with such situations. Keywording stardict on all archs doesn't sound reasonable, so I guess we just need to make sure that repoman will allow the noarch keyword even though the dependencies aren't keyworded on all architectures. -- Thanks, Zac
Re: [gentoo-dev] Re: QA: package.mask policies
On Sun, Nov 8, 2009 at 12:33 AM, Duncan 1i5t5.dun...@cox.net wrote: 2) That won't necessarily stop the bugs from rolling in. Some devs may get tired of live pkg bugs and package.mask it, thus putting up a double- barrier to the live ebuild. If users jump BOTH barriers and fall over the ledge, well... maybe they /need/ that Darwin Award! =:^] We had something interesting happen with policykit. It was masked for a very long time, and so all users of policykit had sys-auth/policykit in p.unmask. Then it was unmasked, but of course who bothers cleaning up their local configuration as long as it works? Months later, policykit-0.92 was added (masked) which was ABI, API, UI, everything incompatible. Naturally portage on said users' boxes was very happy to see such an update on the system and it very promptly upgraded policykit. And of course it completely hosed everything on top of X. We received bug reports for this a *long* time after adding it. After getting sick of duping, and since the new ebuild was broken in a few ways too (and we had decided to rename policykit-0.92 it to sys-auth/polkit), we finally decided to remove it. Lesson to be learnt: users are morons with short attention spans[1]. But we cannot ignore that fact. 1. Of course, we ourselves come under the definition of users too.. ;) -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Re: [RFC] Improve policy of stabilizations
On Sun, Nov 8, 2009 at 2:19 AM, Zac Medico zmed...@gentoo.org wrote: Peter Volkov wrote: Looks like this will not work for all noarch packages. Stardict dictionary itself is noarch, but it RDEPENDS on stardict package which is keyworded only on some archs. So we'll be forced either to keyword stardict on all archs or we need to introduce some new way to work with such situations. Keywording stardict on all archs doesn't sound reasonable, so I guess we just need to make sure that repoman will allow the noarch keyword even though the dependencies aren't keyworded on all architectures. I think we're going a little far trying to solve a management problem with technology. If a herd thinks that a particular package can be safely keyworded (or stabilized) other arches (it just dumps data, is a simple python module, etc); they should make the call and just do it. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
[gentoo-dev] Re: QA: package.mask policies
Nirbheek Chauhan posted on Sun, 08 Nov 2009 05:38:56 +0530 as excerpted: We had something interesting happen with policykit. It was masked for a very long time, and so all users of policykit had sys-auth/policykit in p.unmask. Then it was unmasked, but of course who bothers cleaning up their local configuration as long as it works? Months later, policykit-0.92 was added (masked) which was ABI, API, UI, everything incompatible. And of course it completely hosed everything on top of X. Lesson to be learnt: users are morons with short attention spans[1]. 1. Of course, we ourselves come under the definition of users too.. ;) Ouch! I've had something like that bite me (user-side) too, when I wondered why my package.mask entry wasn't being honored... I had a package.unmask entry too! In theory that's what those stupid version string thingys are for, but it's s much easier just to forget one! =:^[ Maybe something about this should go in the handbook -- a suggestion that if one is going to use a package.unmask entry, that they copy the package.mask entry over, thus at least letting the devs minimize the version spread damage with their package.mask entries. That's what I've started doing, and it works surprisingly well, as I have right there the comment on why it was masked (and add a comment on why I'm unmasking, when I think I might wonder, later), and it's the exact same versions the devs masked in the first place, so I don't have to worry so much about unintended version spread -- at least as long as the devs doing the masking worried about it then. =:^) What do you devs think? Would that be a practical hint for the handbook? Would it be helpful in allowing /you/ to control the version spread of the unmask, by consequence of your control of the version spread on the mask in the first place? -- 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
Re: [gentoo-dev] Re: QA: package.mask policies
On Sun, Nov 8, 2009 at 1:08 PM, Nirbheek Chauhan nirbh...@gentoo.orgwrote: On Sun, Nov 8, 2009 at 12:33 AM, Duncan 1i5t5.dun...@cox.net wrote: 2) That won't necessarily stop the bugs from rolling in. Some devs may get tired of live pkg bugs and package.mask it, thus putting up a double- barrier to the live ebuild. If users jump BOTH barriers and fall over the ledge, well... maybe they /need/ that Darwin Award! =:^] We had something interesting happen with policykit. It was masked for a very long time, and so all users of policykit had sys-auth/policykit in p.unmask. Then it was unmasked, but of course who bothers cleaning up their local configuration as long as it works? Months later, policykit-0.92 was added (masked) which was ABI, API, UI, everything incompatible. Naturally portage on said users' boxes was very happy to see such an update on the system and it very promptly upgraded policykit. And of course it completely hosed everything on top of X. We received bug reports for this a *long* time after adding it. After getting sick of duping, and since the new ebuild was broken in a few ways too (and we had decided to rename policykit-0.92 it to sys-auth/polkit), we finally decided to remove it. Lesson to be learnt: users are morons with short attention spans[1]. But we cannot ignore that fact. In such cases users should be using version specific/version ranges for p.keywords/p.unmask. I don't recall seeing much literature on this practice though with regards to standard recommendations of users and how they should use their own p.keywords and p.unmask. Maybe a good standard practice would be to *not* use ranged p.masks and have explicit =version p.masks, so that users who use the commonly available scripts that just copy from p.mask to p.unmask don't get silently bitten as a consequence. -- Kent perl -e print substr( \edrgmaM SPA nocomil.i...@tfrken\, \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 ); http://kent-fredric.fox.geek.nz
