Re: [gentoo-dev] i have an idea ! (erescue)
On 5/16/05, David Stanek [EMAIL PROTECTED] wrote: If erescue is a statically built binary that basically untars a backed up copy of a package, why would it depend on Python? It won't. Thats the whole point. Colin -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] i have an idea ! (erescue)
I've been in this position more than once, and had to go through the bootcd+binaries (thanks to http://dev.gentoo.org/~avenj/bins/) restore. Argh. I've often thought that atomic updates and rollback within portage would be useful - maybe it could just be done as a layer over subversion for Gentoo updated binary packages. Or maybe rebuilding from source is preferable. Anyway, it would be very useful to be able to revert to a known good state with a single command. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Strange update world output
I have a cron job on my system which runs emerge --sync emerge -uDf world early in the hours of the morning, so that each day I can login, run emerge -uDp world and if I'm satisfied with what's about to be updated I can upgrade straight away without having to wait for time consuming syncs or downloads. However, this morning I woke up to the following output from emerge -uDp world: Calculating world dependencies ...done! [ebuild N] dev-lang/nasm-0.98.39 [ebuild N] x11-misc/ttmkfdir-3.0.9-r2 [ebuild N] x11-base/opengl-update-2.2.1 [ebuild N] x11-base/xorg-x11-6.8.2-r1 [ebuild N] app-arch/rpm2targz-9.0-r2 [ebuild N] sys-apps/utempter-0.5.5.5-r1 [ebuild N] x11-terms/xterm-200-r1 [ebuild N] media-libs/audiofile-0.2.6-r1 [ebuild N] media-sound/alsa-headers-1.0.8 [ebuild N] media-libs/alsa-lib-1.0.8 [ebuild N] media-libs/libmad-0.15.1b [ebuild N] media-libs/libogg-1.1.2 [[ebuild N] kde-base/kde-env-3-r3 [ebuild N] media-libs/libvorbis-1.1.0 [ebuild N] media-libs/libid3tag-0.15.1b [ebuild N] media-libs/lcms-1.13-r1 [ebuild N] media-libs/libmng-1.0.4 [ebuild U ] dev-db/postgresql-8.0.1-r3 [8.0.1-r2] [ebuild N] x11-libs/qt-3.3.4-r3 [ebuild N] kde-base/arts-1.3.2-r1 [ebuild N] media-libs/libsdl-1.2.8-r1 [ebuild N] sys-libs/lib-compat-1.4 Given that my USE flags include -X, -gtk, -qt etc. (I don't want any graphical stuff as this is a server machine, and I've never had anything like this come up before), why on earth is portage wanting to install all these new packages? The only thing I can think of is that the dependancies for postgresql have somehow changed, running emerge -uDpv postgresql throws up most of what is shown above plus: [ebuild U ] dev-db/postgresql-8.0.1-r3 [8.0.1-r2] -debug -doc -kerberos +libg++ +nls +pam +perl -pg-hier -pg-intdatetime +python +readline (-selinux) +ssl -tcltk +xml2 +zlib 0 kB Have I done something wrong, or has something changed in portage? Thanks in advance. Paul -- Rogue Tory http://www.roguetory.org.uk -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: i have an idea ! (erescue)
David Stanek posted [EMAIL PROTECTED], excerpted below, on Sun, 15 May 2005 21:56:54 -0400: On Sun, May 15, 2005 at 06:12:13PM -0700, John Myers wrote: On Sunday 15 May 2005 16:41, david stanek wrote: Add an option to emerge, --backup or something similar, that will automatically run quickpkg. If you set FEATURES=buildpkg, portage automatically makes binary packages for you. No need to add new support. That would build a binary package for the potentially broken package. What it would need to do is build a binary package of the existing merged package. So a user can recover from a botched upgrade. I think Myers' point was that if buildpkg is set, the system soon builds up a history of /multiple/ versions back of any particular package. Thus, if any new emerge or remerge borks the system (hmm, interesting term, that, particularly at this moment, but then, this isn't supposed to be a political list so enough of that, just a nod to the heritage...), it's normally fairly easy to quickly recover to a fully working system by just emerging the binpkg, going back as necessary to a known working version, taking a step back if it was a remerge and you just borked the previously working current version. That of course brings me to /my/ point, that buildpkg is a very useful thing to have, certainly with toolchain packages, even if the system is space or otherwise limited enough that it's not a desirable option overall. Thus, my suggestion. Why not create a second feature, toolchain-buildpkg, I'm calling it here for purposes of developing the suggestion, that's on by default, as contrasted to the normal buildpkg being off by default. The Gentoo Handbook would then of course be modified to cover it and mention why Gentoo recommends that it stay on. Portage would then always buildpkg anything rescue-critical, including portage itself, gcc, binutils, coreutils, python, etc. Don't forget glibc (which would of course need put in place from a LiveCD, one's emergency copy of the root partition, etc). As mentioned here, tar and bzip2 would be special cases, because while one can untar a package directly over the current filesystem if portage (or python) itself breaks, without tar and bzip2, one is somewhat hosed unless one uses the resources of a backup rootfs or liveCD. Perhaps building them static by default would be a good idea, as well as including them in the toolchain-buildpkg list. With such a feature, and with it on by default, another make.conf parameter would then be useful as well. Call it binver-depth, and set binver-depth=3 in make.globals. Then, when three versions of the binpkg are reached, it would delete the oldest one as it created a new one, thus leaving two presumably known working backups at all times, even if the newest version it just created fails. 0 would special-case to unlimited, of course, since we already have the feature as a toggle. As a bonus, one could then make the normal buildpkg feature follow binver-depth as well, since the code would already be there, or create two separate binver-depth vars so users can control toolchain binver-depth separately from normal binver-depth, if desired. I believe this solution has the merit of requiring the least new code, since we already have the normal buildpkg feature in place and tested. The only new code would be that to control the toolchain package option separate from the others, which should be easy to add, and the rotate functionality (or make it a cron script similar to logrotate), which would be nice but isn't an absolute must. Optionally, we could simply change the default of the buildpkg feature to on, along with appropriate coverage in the usual places (GWN, the forums and user list, the Gentoo home page, and naturally, the Gentoo Handbook, for new users). That wouldn't require /any/ new portage code, altho again, a binpkg-rotate cron script would be rather useful. -- 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] Re: i have an idea ! (erescue)
Duncan wrote: Thus, my suggestion. Why not create a second feature, toolchain-buildpkg, I'm calling it here for purposes of developing the suggestion, that's on by default, as contrasted to the normal buildpkg being off by default. The Gentoo Handbook would then of course be modified to cover it and mention why Gentoo recommends that it stay on. Portage would then always buildpkg anything rescue-critical, including portage itself, gcc, binutils, coreutils, python, etc. Don't forget glibc (which would of course need put in place from a LiveCD, one's emergency copy of the root partition, etc). What is a probability that user running *stable* branch would bork his box by upgrades? Aren't those running ~ARCH expected to make backups? Is it such a problem to reboot their *testing* boxes from some CD and restore backups from such environment? (I know about special cases like machines w/o CD-ROM/netboot, but I think their owners are skilled enough to find other solution which better suits their needs.) Why bother with such a feature which won't be used by most of people, instead of doing something more useful? Just my 2 cents, though. -jkt -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Strange update world output
On 5/16/05, Kevin F. Quinn [EMAIL PROTECTED] wrote: Try emerge -puDvt world, which will give you the list in an indented tree format useful for determining what pulled in the packages you don't want. I think I've found out what the problem was by looking through all those, although the dependancy tree isn't all that easy to follow (it's pretty hard to tell how far something is indented when they're 10+ lines apart). Looks like lib-compat had +sdl set (I presume this is set by default because I've never enabled it) which seemed to be bringing all sorts of rubbish along with it. Adding -sdl and -arts to make.conf got rid of everything bar postgresql and lib-compat (which is what I wanted), although I've no idea why all these extra packages appeared in the first place. Thanks for the help. Paul -- Rogue Tory http://www.roguetory.org.uk -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Re: i have an idea ! (erescue)
Thomas de Grenier de Latour posted [EMAIL PROTECTED], excerpted below, on Mon, 16 May 2005 13:33:15 +0200: There exists a buildsyspkg flag already, which is supposed to build packages for ebuilds that are in the system group. It's probably a bit broken tho (won't catch system packages dependencies that are not explicitly in your profile's system group, and also i don't think the version in portage resolves virtuals). Wow! Before they call, I will answer, and while they are yet speaking, I will hear. =8^) Or, to put it another way, Great minds think alike! g -- 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] Strange update world output
On 5/16/05, Paul Waring [EMAIL PROTECTED] wrote: On 5/16/05, Kevin F. Quinn [EMAIL PROTECTED] wrote: Try emerge -puDvt world, which will give you the list in an indented tree format useful for determining what pulled in the packages you don't want. I think I've found out what the problem was by looking through all those, although the dependancy tree isn't all that easy to follow (it's pretty hard to tell how far something is indented when they're 10+ lines apart). Looks like lib-compat had +sdl set (I presume this is set by default because I've never enabled it) which seemed to be bringing all sorts of rubbish along with it. Adding -sdl and -arts to make.conf got rid of everything bar postgresql and lib-compat (which is what I wanted), although I've no idea why all these extra packages appeared in the first place. For the record, you can put -* in your make.conf. That will disable all of the use flags and you will have to specify only the one you need. That way, this will never happen again. Just make sure you know what you're doing ... Also, since no one mentioned it yet, this is a strickly gentoo developpement oriented mailing list. The Gentoo-User ML exist for these sort of questions :). Regards, JF Thanks for the help. Paul -- Rogue Tory http://www.roguetory.org.uk -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Naming scheme confusion
On Mon, 2005-05-16 at 15:04 +0200, Henrik Brix Andersen wrote: The current ebuild is orinoco-0.15_rc2-r2.ebuild, and the logical name for a CVS snapshot would, as I see it, be orinoco-0.15_rc2_pre20050516.ebuild, but mixing _rcX and _preY is not allowed by portage. I meant to write 'orinoco-0.15_rc3_pre20050516.ebuild' of course. ./Brix -- Henrik Brix Andersen [EMAIL PROTECTED] Gentoo Linux signature.asc Description: This is a digitally signed message part
[gentoo-dev] Request for Permission
Gentoo I am operating a small IT service organization and I would like to put a link to Gentoo on my site. My ad: A href=http://www.gentoo.org; uGentoo Linux /u/A A free linux distribution, they have servers and workstations. This distribution is a build as you go system, it is not for the Linux newbie ( beginner ). If you want to understand what is under the covers, this just might be for you.BRBR If there is a standard ad that you would prefer, I will use it. This is a service for my clients use and reference. If you allow my listing your site, please extend your permission. -- Rick Sivernell Dallas, Texas 75287 972 306-2296 [EMAIL PROTECTED] Registered Linux User .~. / v \ /( _ )\ ^ ^ In Linux we trust! -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] New dev Killerfox (René NussBaumer)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 http://dev.gentoo.org/~sejo/ Gentoo Linux Jochen Maes Defer no time, delays have dangerous ends - -- Jochen Maes greetings, Well that's it for today Ciaranm's house is haunting (would explain a lot) :-) paranormalic. Perhaps he should check whether He's a Swiss bloke interested in astrology and working for hppa. We are proud to announce a new dev in the team KillerFox who will be Hey all, -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCiNKDMXMsRNMHhmARApisAJ4quCgz3MEog7Yz/pF34kQuujyOUQCg1S8W zr97kBByGWE+F2izWCx7z5I= =3LhS -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New dev Killerfox (René NussBaumer)
Nice to finally have you on board! -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Naming scheme confusion
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Henrik Brix Andersen wrote: The current ebuild is orinoco-0.15_rc2-r2.ebuild, and the logical name for a CVS snapshot would, as I see it, be orinoco-0.15_rc2_pre20050516.ebuild, but mixing _rcX and _preY is not allowed by portage. I can't go with just orinoco-0.15_pre20050516.ebuild as _rcX is considered newer than _preY. How about rc2_p20050516? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCiOp3XVaO67S1rtsRAok8AKD3dkxsKsP+zr4F72UgRcEkGzvhYwCfVwB0 KxOD3PruBa+zU5McrlWD5F8= =7q8G -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Request for Permission
Rick Sivernell [EMAIL PROTECTED] wrote: I am operating a small IT service organization and I would like to put a link to Gentoo on my site. My ad: [snip] If there is a standard ad that you would prefer, I will use it. This is a service for my clients use and reference. If you allow my listing your site, please extend your permission. If I'm out of line here, somebody slap me. That being said, You don't really need permission to link to to the Gentoo website. If you really want to be anal-retentive about being letter-perfect to the intellectual property laws, swift maintains a standard boilerplate at http://www.gentoo.org/main/en/name-logo.xml. Therein, you shall find all the dry details about what our legal system considers appropriate use. On the other hand, if you don't care a whit about all that rubbish, I don't think anybody at Gentoo will object to that blurb you quoted. In any case, I suspect that tacking trade; symbols on the end of every mention of Gentoo will suffice to keep you clean. IANAL. I am probably wrong in many strange and dangerous ways. Use your own Judgment, Luke. -- Batou: Hey, Major... You ever hear of human rights? Kusanagi: I understand the concept, but I've never seen it in action. --Ghost in the Shell pgpjvJC1AmQdk.pgp Description: PGP signature
Re: [gentoo-dev] i have an idea ! (erescue)
On 5/16/05, Chris Gianelloni [EMAIL PROTECTED] wrote: This would add quite a bit of space to the mirrors. The average stage3 tarball is about 100MB. So you can assume that the packages would equal about the same. Multiply this by the number of releasing arches, and possibly even subarches, and you have an additional 1GB just from x86/ppc. i don't believe this was meant to be a full replace anything that breaks kind of system here. just a simple rescue program that would get you very basic stuff, like portage, python, the toolchain. for any arch they could be optimized to the lowest common denominator, like i386... and then once they are installed and the user's system works again, they use the again working portage or compiler to rebuild the exact version they want. it isn't a huge substantial hit, and the rescue packages don't have to be the latest version in question, they can be updated once a release, or once a year, leaving a fairly small footprint. i also like the idea of it being wholly seperate from portage, which neatly eliminates several points of failure, and keeps the portage code a bit easier to control. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Another call for BugVoting on bugs.gentoo.org
I just read this: http://www.kdedevelopers.org/node/view/1055 and think it explains things very well. So here is just another call for enabling bug voting on bugs.gentoo.org mfg, heinrich :-) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Another call for BugVoting on bugs.gentoo.org
On Tue, 17 May 2005 00:58:45 +0200 Heinrich Wendel [EMAIL PROTECTED] wrote: | I just read this: http://www.kdedevelopers.org/node/view/1055 and | think it explains things very well. | | So here is just another call for enabling bug voting on | bugs.gentoo.org What, so that you can see which bugs a small but vocal group of ricers are interested in rather than the ones that're actually important? So that users can start whining that this really stupid bug has six zillion votes but no-one's implemented it!? So that certain people can carry on ignoring critical bugs under the pretense that low votes is the same as low importance? -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpYcneJkr1iM.pgp Description: PGP signature
[gentoo-dev] DOWNTIME bugs.gentoo.org
There will be a scheduled upgrade of http://bugs.gentoo.org this evening. I am upgrading Bugzilla after a long hiatus of bug fixes and customizations, and because of the recent rash of instability. I will be shutting down Bugs at 8pm EDT ( UTC), and plan on having it down for one hour, although hopefully much less. I will send out another email once the upgrade is complete with a list of some highlighted features you can expect. Thanks, Jeffrey Forman -- Jeffrey Forman Gentoo Infrastructure Gentoo Release Engineering [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Another call for BugVoting on bugs.gentoo.org
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Heinrich Wendel wrote: I just read this: http://www.kdedevelopers.org/node/view/1055 and think it explains things very well. I blogged [1] about this the other day. It also talks a bit about bounties, which I was actually more interested in. It's worth thinking about that it seems to be working well for KDE, without all the spamming etc that Ciaran thinks will happen. Thanks, Donnie 1. http://www.livejournal.com/users/spyderous/30950.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCiTEFXVaO67S1rtsRAsOQAJ93nN6//Of+AyRHt3VFjSlFqYpvKgCgrESq ya5I9b8AOl4npeeam7avYV0= =bSA/ -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Another call for BugVoting on bugs.gentoo.org
On Monday 16 May 2005 07:08 pm, Ciaran McCreesh wrote: What, so that you can see which bugs a small but vocal group of ricers are interested in rather than the ones that're actually important? once again, voting is optional ... if you dont want to pay attention to them, then dont shut up and let the devs who wish to utilize it do so -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Another call for BugVoting on bugs.gentoo.org
On Mon, 16 May 2005 16:47:17 -0700 Donnie Berkholz [EMAIL PROTECTED] wrote: | Heinrich Wendel wrote: | I just read this: http://www.kdedevelopers.org/node/view/1055 and | think it explains things very well. | | I blogged [1] about this the other day. It also talks a bit about | bounties, which I was actually more interested in. Which would be even worse, since you'd end up getting cash offered for silly version bumps and package adds and nothing at all for critical stuff that the end user doesn't tend to see. Unlike KDE, we have multiple 'layers' -- we're not just working on directly user visible applications. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpbXJjeyWIiN.pgp Description: PGP signature
Re: [gentoo-dev] Another call for BugVoting on bugs.gentoo.org
On Monday 16 May 2005 08:01 pm, Ciaran McCreesh wrote: On Mon, 16 May 2005 19:45:05 -0400 Mike Frysinger [EMAIL PROTECTED] wrote: | On Monday 16 May 2005 07:08 pm, Ciaran McCreesh wrote: | What, so that you can see which bugs a small but vocal group of | ricers are interested in rather than the ones that're actually | important? | | once again, voting is optional ... if you dont want to pay attention | to them, then dont Ok. Please provide me with a procmail rule that will filter bug comment emails which whine about votes being ignored whilst letting legit comments through. i dont see how that differs any from users whining about how a bug has been open foorever or how there's a billion people in the cc list and yet the fix still isnt in portage ! clearly developers are a bunch of jerk offs since my bug hasnt been fixed yesterday ! ive seen users complain on bugs/version bump requests that were open for less than 3 days and dealt with packages that were far from critical (i.e. a package in emulation or games) -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] i have an idea ! (erescue)
On Mon, 2005-16-05 at 09:57 -0400, Chris Gianelloni wrote: This would add quite a bit of space to the mirrors. The average stage3 tarball is about 100MB. So you can assume that the packages would equal about the same. Multiply this by the number of releasing arches, and possibly even subarches, and you have an additional 1GB just from x86/ppc. I would tend to believe that the content of a stage1 or stage2 would be enough and just for the majors architectures (those that have a stage1).. Anyways people will rebuild said packages once that's done, right? That's not much for the mirrors.. Around 168 megs for the content of a stage1 or 300 megs for the stage2.. [EMAIL PROTECTED] releases $ find . -name stage1-*-2005.0.tar.bz2 |xargs du -c 21084 ./amd64/2005.0/stages/stage1-amd64-2005.0.tar.bz2 17292 ./sparc/2005.0/sparc32/stages/stage1-sparc-2005.0.tar.bz2 20520 ./sparc/2005.0/sparc64/stages/stage1-sparc64-2005.0.tar.bz2 18012 ./x86/2005.0/stages/hardened/2.4/stage1-x86-hardened-2.4-2005.0.tar.bz2 18252 ./x86/2005.0/stages/hardened/2.6/stage1-x86-hardened-2.6-2005.0.tar.bz2 16424 ./x86/2005.0/stages/x86/stage1-x86-2005.0.tar.bz2 18720 ./ppc64/2005.0/stages/stage1-ppc64-2005.0.tar.bz2 18756 ./alpha/2005.0/stages/stage1-alpha-2005.0.tar.bz2 19468 ./ia64/2005.0/stages/stage1-ia64-2005.0.tar.bz2 168528 total -- Olivier Crête [EMAIL PROTECTED] x86 Security Liaison signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Another call for BugVoting on bugs.gentoo.org
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: On Mon, 16 May 2005 16:47:17 -0700 Donnie Berkholz [EMAIL PROTECTED] wrote: | Heinrich Wendel wrote: | I just read this: http://www.kdedevelopers.org/node/view/1055 and | think it explains things very well. | | I blogged [1] about this the other day. It also talks a bit about | bounties, which I was actually more interested in. Which would be even worse, since you'd end up getting cash offered for silly version bumps and package adds and nothing at all for critical stuff that the end user doesn't tend to see. Unlike KDE, we have multiple 'layers' -- we're not just working on directly user visible applications. My idea was that the foundation would foot the bounties. It sounds as if you think the users would. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCiVS4XVaO67S1rtsRAnGlAKDrKoEFkfanyg9vewO1vRQ2ynuUbgCgqANv 8E4AnG7wuD8OI6tnSdizBc0= =YW5+ -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] busybox prep
could people update and try out busybox-1.00-r4 ? i finally stopped being lazy and ported all the utils from upstream busybox into 1.00-r4 ... once you emerge it, you'll be left with /bin/bb which is now your fun rescue shell ... simply execute `bb` and you're all set to go ! for a list of commands implemented, just run `busybox` -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Another call for BugVoting on bugs.gentoo.org
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Frysinger wrote: On Monday 16 May 2005 08:01 pm, Ciaran McCreesh wrote: On Mon, 16 May 2005 19:45:05 -0400 Mike Frysinger [EMAIL PROTECTED] wrote: | On Monday 16 May 2005 07:08 pm, Ciaran McCreesh wrote: | What, so that you can see which bugs a small but vocal group of | ricers are interested in rather than the ones that're actually | important? | | once again, voting is optional ... if you dont want to pay attention | to them, then dont I would tend to agree with Klieber when he closed the actual bug about this issue that I read through a few weeks ago. The problem with leaving it optional being users vote a bunch on bug X and then the developer says he doesn't care, and then the users bitch because 'their precious voice was ignored'. Personally if users want crap that bad, they can submit the code themselves. Most if not all of the developers here are volunteers, and just because a bunch of users vote up a bug doesn't particularly make it important to work on. I think that if this is made clear enough somewhere, them this could work. Obviously voting is a very nice tool that could help out a lot of people who use it. It's just not worth it (IMHO) when it annoys the other half of the people who don't use it. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQolna2zglR5RwbyYAQKakw/8DkzL9lx9tILxXaEo3J6e81QcemBmBMtc 5TS3MdSx6H9qGSFwF1OzXF6TNm5PE+mq6TDH9j013+1OY6Wl1Ul9EP+LT+3xdnVQ EJJgxNsDaWdQlxWEHuBZF4gFK/kD2jAmGGNepi2CTMMEKMtHpyuapJHhKeIQdfdr BmZ/TGtFo8CZDnzy/UBOpjKnlBpuBwOrm9yCMlWo9bdyg3YEwbp9W9CLxiCedUIp q2iv8ykgb2/Fx5pEstdeU5fw+qu3mfemjo4ZQNStE/rJNB32BPDqCCvMnWixJ2C7 H8sesBkuwinh7oDSdyv2FhO2qAEJKSFhV9wK1la5nOt9IRyDQtNv5OpLsLw8OwAs /MhhskiLiB8ch4Y2Xr+TmyRlfzvSjmsU/D0K9k0bwFw+c2vDeD7iEEko7zesgTLT irMQ3mjPFvBcHphD3LQICT8/IgbjOJy18TQOShH9WXLTF+glyEBwX/80bTFQ+mLl ZS+ULdeVPs450h7VoOpIiIY4XPN5HDSS/hE87GwnKAUD3n7jUdhYy9bZr87OY0xC ltZIS+0WMSV469Qj5BWMkabmNeLifHfMLLohj2ZJ3L4gAt9rZ1Pb67yzVEXL/pL9 VdY520LUX8dXFOy21kTqSO9cpXfNJaoidXESs1QlgN/RHuCdehHaneOGnYKO6lfu kWUc16pboSw= =6rLe -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] OpenAFS ebuild status
On Tuesday 17 May 2005 01:05 am, John D. Ranson wrote: If the current developers are unable or unwilling to apply snip there are no openafs developers, read the mail archives ive sent a few requests for someone to step up and maintain the package, no one has followed through on it people can complain all they want, openafs will stay broken until a developer decides to maintain it or we bring someone on to do so -mike -- gentoo-dev@gentoo.org mailing list