Re: [gentoo-dev] RFC: tcsh vs. csh, removal of the latter
On Срд, 2006-01-25 at 20:57 +0100, Grobian wrote:
Are there any objections to removing csh from the tree? If there are no
problems with csh removal before Feb 1st 2006, then I will starting from
that date work on getting csh removed by masking it, blocking tcsh and
csh, and request for updates of the packages that depend on csh.
Thinking a little bit on subject I'd say I object. There is a big
difference in size between csh and tcsh:
-rwxr-xr-x 1 root root 130148 Янв 28 08:11 /bin/csh
-rwxr-xr-x 1 root root 299136 Янв 28 08:13 /bin/tcsh
So tcsh is *2.3 times bigger* then csh. Of course, that's not a big pain
for current desktop or server systems. But gentoo is used for different
purposes... Also personally I like small system and I'm not using csh
for anything except for installing packages. So I do not need anything
except basic csh functionality. Thus for me it's better to leave csh and
remove tcsh (I know this is bad solution ;) ).
Problem here is that creating a conditional symlink for csh - tcsh is a
bit dirty, and leaves the user with a system that has no csh in case the
csh is unmerged after tcsh was installed.
To solve symlink problem I can suggest the following.
1. As it should be done now, tcsh should create symlink csh - tcsh if
csh does not exist (in src_install()).
2. csh ebuild should create csh - tcsh symlink if tcsh exist during
unmerge. This is possible with pkg_postrm:
pkg_postrm () {
[ -e /bin/tcsh ] ln -s /bin/tcsh /bin/csh
}
3. tcsh should remove csh - tcsh symlink on unmerge.
pkg_postrm () {
[ -e /bin/tcsh ] ln -s /bin/tcsh /bin/csh
}
Not a very clean solution, but works.
BTW. Why tcsh is a blocker for csh?
Peter.
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: tcsh vs. csh, removal of the latter
On Sat, 28 Jan 2006 10:31:55 +0100 Grobian [EMAIL PROTECTED] wrote: | In fact, I'd like to have only sh, because I never use bash. How did you become a Gentoo developer? -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: tcsh vs. csh, removal of the latter
On Sat, Jan 28, 2006 at 12:05:30PM +0300, Peter Volkov (pva) wrote: To solve symlink problem I can suggest the following. Rather than handling it manually, perhaps eselect can help handle it consistently, and allow users to switch when they have both csh and tcsh installed. -- Robin Hugh Johnson E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpWb2Gww9a9O.pgp Description: PGP signature
[gentoo-dev] New developer: Jokey (Markus Ullmann)
Hi all. Markus has been contributing to gentoo through bugzilla and bugdays for a few months and have now finally joined the ranks of official Gentoo developers. Markus is going to help with netmon related ebuilds. Markus tells us about himself: I'm a 23 year old geek, trying to spread linux around the world ;) At the moment I live at my parents near Hamburg/Germany and I'm studying electrical engineering at University of Applied Sciences, Hamburg. I greatly enjoy watching all forms of Star Trek and Star Wars. For non-computerized balance I enjoy doing some Tae-Bo and go swimming with Friends and other LUGs taking part 'LUG in motion'. Please welcome Markus to the team. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New developer: Jokey (Markus Ullmann)
heya, On Saturday 28 January 2006 11:37, [EMAIL PROTECTED] wrote: Please welcome Markus to the team. Great to have you onboard Markus. Welcome :) -- Benjamin Smee (strerror) net-mail/netmon/forensics/crypto Fingerprint: 497F 5E98 1FA0 C313 EA0B 08C7 004A 66ED 448B E78C pgpcJ3zjS50kH.pgp Description: PGP signature
Re: [gentoo-dev] New developer: Jokey (Markus Ullmann)
[EMAIL PROTECTED] wrote: Please welcome Markus to the team. Welcome to the team! :-) -- Sandro (Sanchan) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: tcsh vs. csh, removal of the latter
On Saturday 28 January 2006 10:47, Robin H. Johnson wrote: Rather than handling it manually, perhaps eselect can help handle it consistently, and allow users to switch when they have both csh and tcsh installed. I started working on something like that for gtar/bsdtar, but I found that I don't have knowledge of eselect to do that, but this might be interesting in a generic way for alternatives, and I'd like to help if someone would start something. -- Diego Flameeyes Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpwgxJy7wNB0.pgp Description: PGP signature
Re: [gentoo-dev] New developer: Jokey (Markus Ullmann)
On Sat, 2006-01-28 at 12:37 +0100, [EMAIL PROTECTED] wrote: Please welcome Markus to the team. ... and once again a candidate for the one and only German conspiracy :) Welcome aboard, Markus! wkr, Tobias signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Re: Re: Re: bootstrapping since gcc 3.4 is stable
On Friday 27 January 2006 16:32, MIkey wrote: Paul de Vrieze wrote: Would you mind sharing the useflags you mean, and which packages you want to build? It might be bugs in the packages involved. My standard USE flags for building a lamp server. No X, no cruft. USE=-X -alsa -apm -arts -avi -cups -doc -eds -emboss -gnome -gpm -gstreamer -gtk -gtk2 -imlib -info -ipv6 -kde -mad -man -mikmod -motif -mp3 -mpeg -nls -ogg -oggvorbis -opengl -oss -pam -qt -quicktime -sdl -vorbis -xmms -xv apache2 mysql nptl nptlonly php userlocales Using this flags on a freshly compiled stage3 (from a stage1, just running emerge system without setting useflags) I get no blockers at all, when setting the useflags at the point that system has been recompiled. Depclean does suggest removing a number of packages though. Some of which can be dangerous to remove (like pam). I'm sorry, but I can't replicate the problem with regard to merging php for these useflags on a fresh stage3. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpjwOUsIOwm1.pgp Description: PGP signature
Re: [gentoo-dev] New developer: Jokey (Markus Ullmann)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 28 Jan 2006, Marcus D. Hanwell wrote: On Saturday 28 January 2006 16:34, Markus Dittrich wrote: Good to have some more Markuses on the team :) Welcome! Am I the only one who spells it properly? :D My apologies, that should have been Mar[ck]uses! cheers, Mar[ck]us - -- Markus Dittrich (markusle) Gentoo Linux Developer Scientific applications -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD26EKxlRwCwb7k40RAnayAJ9CHtE+BYJJLXhRuf86GEBqOry31QCfVbC2 kDGLeXKx2SRbJPRxT+PNUwk= =QIiD -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New developer: Jokey (Markus Ullmann)
On Saturday 28 January 2006 16:34, Markus Dittrich wrote: On Sat, 28 Jan 2006 [EMAIL PROTECTED] wrote: Please welcome Markus to the team. Good to have some more Markuses on the team :) Welcome! cheers, Markus Am I the only one who spells it properly? :D pgpfrwzFPfDxr.pgp Description: PGP signature
[gentoo-dev] Re: Re: Re: Re: Re: bootstrapping since gcc 3.4 is stable
Paul de Vrieze wrote: Using this flags on a freshly compiled stage3 (from a stage1, just running emerge system without setting useflags) I get no blockers at all, when setting the useflags at the point that system has been recompiled. Are you suggesting that on fresh installs, after editing your use flags, you should _NOT_ recompile, taking into account the new use flags? That is not what the documentation tells you what to do: A full description on USE can be found in the second part of the Gentoo Handbook, USE flags. A full description on the available USE flags can be found on your system in /usr/portage/profiles/use.desc Click on that link to the USE flag section in the handbook: If you have altered your USE flags and you wish to update your entire system to use the new USE flags, use emerge's --newuse option: emerge --update --deep --newuse world I'm sorry, but I can't replicate the problem with regard to merging php for these useflags on a fresh stage3. Follow the instructions in the official handbook to replicate the problem, what any new user to gentoo would need to go through. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New developer: Jokey (Markus Ullmann)
On Sat, 2006-01-28 at 17:09 +, Ciaran McCreesh wrote: On Sat, 28 Jan 2006 16:51:20 + (UTC) Markus Dittrich | | My apologies, that should have been Mar[ck]uses! No, that would be Marci. Now write it down a hundred times. If it's not done by sunrise, I'll cut your balls off. Now, you need to right it a hundred times... Mar[ck]i Weclome Markus -Lares -- Lares Moreau [EMAIL PROTECTED] | LRU: 400755 http://counter.li.org lares/irc.freenode.net | Gentoo x86 Arch Tester | ::0 Alberta, Canada Public Key: 0D46BB6E @ subkeys.pgp.net | Encrypted Mail Preferred Key fingerprint = 0CA3 E40D F897 7709 3628 C5D4 7D94 483E 0D46 BB6E signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: tcsh vs. csh, removal of the latter
On 1/28/06, Grobian [EMAIL PROTECTED] wrote: The question here now actually is: is csh worth the hassle, or not? My opinion is that it is not. csh_is_not_worth_it++; It is causing trouble and not adding functionality. Unless there are cases where tcsh is not backwards compatible, I say it is a good riddance. -- Marcelo Góes [EMAIL PROTECTED] [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Re: Re: Re: bootstrapping since gcc 3.4 is stable
MIkey wrote: Paul de Vrieze wrote: Using this flags on a freshly compiled stage3 (from a stage1, just running emerge system without setting useflags) I get no blockers at all, when setting the useflags at the point that system has been recompiled. Depclean does suggest removing a number of packages though. Some of which can be dangerous to remove (like pam). I'm sorry, but I can't replicate the problem with regard to merging php for these useflags on a fresh stage3. On second thought, never mind :) I am not sure what you are trying to point out here in the first place. He is trying (quite successfully) to show that you are full of shit. -Steve -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Make logrotate a global USE flag?
Marcelo Góes wrote: It seems there are some ebuilds with a logrotate USE flag: use.local.desc:34:app-backup/bacula:logrotate - Install support files for logrotate use.local.desc:550:mail-filter/dspam:logrotate - Install support files for logrotate use.local.desc:899:net-ftp/vsftpd:logrotate - Use logrotate for rotating logs use.local.desc:1011:net-misc/ntp:logrotate - Install support files for logrotate use.local.desc:1079:net-proxy/squid:logrotate - Use logrotate for rotating logs use.local.desc:1284:sys-power/acpid:logrotate - Use logrotate for rotating logs use.local.desc:1290:sys-power/hibernate-script:logrotate - Use logrotate for rotating logs use.local.desc:1303:www-apps/dspam-web:logrotate - Build logrotate support for dspam Perhaps it should be a global USE flag? Marcelo -- Marcelo Góes [EMAIL PROTECTED] [EMAIL PROTECTED] How about the packages that don't even ask and just install logrotate stuff? Like Apache, lighttpd, and mysql? -- Doug Goldstein [EMAIL PROTECTED] http://dev.gentoo.org/~cardoe/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Make logrotate a global USE flag?
Doug Goldstein wrote: Marcelo Góes wrote: It seems there are some ebuilds with a logrotate USE flag: use.local.desc:34:app-backup/bacula:logrotate - Install support files for logrotate use.local.desc:550:mail-filter/dspam:logrotate - Install support files for logrotate use.local.desc:899:net-ftp/vsftpd:logrotate - Use logrotate for rotating logs use.local.desc:1011:net-misc/ntp:logrotate - Install support files for logrotate use.local.desc:1079:net-proxy/squid:logrotate - Use logrotate for rotating logs use.local.desc:1284:sys-power/acpid:logrotate - Use logrotate for rotating logs use.local.desc:1290:sys-power/hibernate-script:logrotate - Use logrotate for rotating logs use.local.desc:1303:www-apps/dspam-web:logrotate - Build logrotate support for dspam Perhaps it should be a global USE flag? Marcelo -- Marcelo Góes [EMAIL PROTECTED] [EMAIL PROTECTED] How about the packages that don't even ask and just install logrotate stuff? Like Apache, lighttpd, and mysql? they should use it, MySQL will be updated when Marcelo make logrotate uf global -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Make logrotate a global USE flag?
On 1/28/06, Francesco Riosa [EMAIL PROTECTED] wrote: Doug Goldstein wrote: How about the packages that don't even ask and just install logrotate stuff? Like Apache, lighttpd, and mysql? they should use it, MySQL will be updated when Marcelo make logrotate uf global Indeed, logrotate functionality should be optional. Ebuilds that install logrotate stuff without asking should be updated to use the logrotate USE flag. I'm making it a global USE flag if nobody complains. -- Marcelo Góes [EMAIL PROTECTED] [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Make logrotate a global USE flag?
Marcelo Góes wrote: Indeed, logrotate functionality should be optional. Ebuilds that install logrotate stuff without asking should be updated to use the logrotate USE flag. I'm making it a global USE flag if nobody complains. You want people to recompile the whole package to get another text file installed? People who don't want it can set INSTALL_MASK. It should be installed by default and not switchable with a USE flag. Thanks, Donnie -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Make logrotate a global USE flag?
Marcelo Góes wrote: It seems there are some ebuilds with a logrotate USE flag: snip Perhaps it should be a global USE flag? We have discussed this fairly recently[1] so I'll post the link to save everyone the hassle. [1] http://marc.theaimsgroup.com/?l=gentoo-devw=2r=1s=logrotateq=b Marcelo -- Marcelo Góes [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Make logrotate a global USE flag?
Reposting since I don't think my last e-mail got through... On 1/29/06, Donnie Berkholz [EMAIL PROTECTED] wrote: People who don't want it can set INSTALL_MASK. It should be installed by default and not switchable with a USE flag. If INSTALL_MASK is the correct way to prevent logrotate stuff from being installed, then those 8 ebuilds I mentioned earlier should drop the USE flag and install it by default. That's probably easier to fix, too. Regardless of how one controls whether logrotate stuff is installed or not, we should make it one way only. Each package doing its own thing is confusing. While at it, we might want to mention it in our documentation, too (cron-guide.xml and/or hb-install-tools.xml perhaps?). I don't remember reading anything about this, and neither does grep/Google. Marcelo -- Marcelo Góes [EMAIL PROTECTED] [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Re: Re: Re: bootstrapping since gcc 3.4 is stable
On Saturday 28 January 2006 12:39, Stephen P. Becker wrote: On second thought, never mind :) I am not sure what you are trying to point out here in the first place. He is trying (quite successfully) to show that you are full of shit. In this particular case, I might have to agree with you Steve. He was actually confirming what I have been saying all long. So thanks for gracing me with your brilliant, well reasoned insights. Always nice to know that when I make an ass of myself, you will be there to let me know... pgpIbicruU0Lj.pgp Description: PGP signature
[gentoo-dev] xinetd use flag and xinetd files being installed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, Jan 28, 2006 at 08:33:26PM -0500, Doug Goldstein wrote: How about the packages that don't even ask and just install logrotate stuff? Like Apache, lighttpd, and mysql? What about xinetd? The same thing is happening there. I have some files in /etc/xinetd.d but I do not use xinetd. I don't really like the install_mask idea for this because you can't set that on a per-package basis that I am aware of, and we have several packages that have an xinetd use flag. What do you all think? William -- Doug Goldstein [EMAIL PROTECTED] http://dev.gentoo.org/~cardoe/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD3EB6blQW9DDEZTgRAuoCAKCw4y2yMizmPZxQaz8gMZ5nu2lf/gCdHMHu gZ3NTUG0r6dWA2teNextCyM= =W+pj -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] xinetd use flag and xinetd files being installed
William Hubbs wrote: I don't really like the install_mask idea for this because you can't set that on a per-package basis that I am aware of, and we have several packages that have an xinetd use flag. Why would you want it on a per-package basis? Thanks, Donnie -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Make logrotate a global USE flag?
On Sat, 28 Jan 2006 18:58:52 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: | Marcelo Góes wrote: | Indeed, logrotate functionality should be optional. Ebuilds that | install logrotate stuff without asking should be updated to use the | logrotate USE flag. | | I'm making it a global USE flag if nobody complains. | | You want people to recompile the whole package to get another text | file installed? | | People who don't want it can set INSTALL_MASK. It should be installed | by default and not switchable with a USE flag. We already had this discussion. It's not that it's another file, it's that it's another file in /etc, which is backed up and requires administrator attention on every upgrade. Packages shouldn't stick stuff in /etc on a whim. -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] rsync metadata cache patch (obsoletes metadata transfer on sync)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Zac Medico wrote: I was playing with the metadata cache stuff this weekend and decided to write a patch that obsoletes metadata transfers on sync. I have reimplemented the previous patch as a normal cache module that adds a writable layer on top of the pre-generated metadata. If you'd like to try this out (with portage-2.1_preX), simply copy metadata_overlay.py into /usr/lib/portage/pym/cache/ and add portdbapi.auxdbmodule = cache.metadata_overlay.database to /etc/portage/modules. I haven't tested this much, but like the previous patch, this shouldn't cause any harm. Feedback would be appreciated. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD20nu/ejvha5XGaMRAumKAJ9iyEsxsyi59Iri+fZ3pA6bWs38xwCeI5SW D3OJhsbTGr8w+BviOEpfAIA= =v/bi -END PGP SIGNATURE- # Copyright: 2006 Gentoo Foundation # Author(s): Zac Medico ([EMAIL PROTECTED]) # License: GPL2 import template, flat_hash, metadata if not hasattr(__builtins__, set): from sets import Set as set from flat_hash import database as db_rw from metadata import database as db_ro class database(template.database): autocommits = True serialize_eclasses = False def __init__(self, location, label, auxdbkeys, **config): super(database, self).__init__(location, label, auxdbkeys) self.db_rw = db_rw(location, label, auxdbkeys, **config) self.db_ro = db_ro(label,metadata/cache,auxdbkeys) def __getitem__(self, cpv): try: return self.db_rw[cpv] except KeyError: return self.db_ro[cpv] def _setitem(self, name, values): self.db_rw[name] = values def _delitem(self, cpv): try: del self.db_rw[cpv] except KeyError, ke: if not self.db_ro.has_key(cpv): raise ke def has_key(self, cpv): return self.db_rw.has_key(cpv) or self.db_ro.has_key(cpv) def iterkeys(self): s = set() for db in (self.db_rw, self.db_ro): for cpv in db.iterkeys(): if cpv not in s: yield cpv s.add(cpv)
Re: [gentoo-portage-dev] [PATCH] rsync metadata cache patch (obsoletes metadata transfer on sync)
Zac Medico wrote:
I have reimplemented the previous patch as a normal cache module that adds a
writable layer on top of the pre-generated metadata. If you'd like to try this
out (with portage-2.1_preX), simply copy metadata_overlay.py into
/usr/lib/portage/pym/cache/ and add portdbapi.auxdbmodule =
cache.metadata_overlay.database to /etc/portage/modules.
I haven't tested this much, but like the previous patch, this shouldn't cause
any harm. Feedback would be appreciated.
Portage didn't explode and dep calculation is pretty damn quick with an empty
/var/cache/edb/dep/, so I assume that it's working properly. Is it normal for
/var/cache/edb/dep/${PORTDIR}/ to be re-created (it's still empty) when this new
module is in use?
--
Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/
Gentoo Linux Developer Installer Project
--
gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] [PATCH] rsync metadata cache patch (obsoletes metadata transfer on sync)
On Sat, Jan 28, 2006 at 02:39:42AM -0800, Zac Medico wrote: def _delitem(self, cpv): try: del self.db_rw[cpv] except KeyError, ke: if not self.db_ro.has_key(cpv): raise ke You need white outs here (lifting a unionfs term); this won't actually change state in any way if you're trying to delete a bad entry from the underlying metadata cache. def has_key(self, cpv): return self.db_rw.has_key(cpv) or self.db_ro.has_key(cpv) def iterkeys(self): s = set() for db in (self.db_rw, self.db_ro): for cpv in db.iterkeys(): if cpv not in s: yield cpv s.add(cpv) Should just do s=set() for cpv in self.db_rw: yield cpv s.add(cpv) for cpv in self.db_ro: if cpv not in s: yield cpv Slightly faster (1us per yield for the set lookup), but mainly less memory usage. Aside from that, the label trick is icky. ;) pgpKDjdHMWon3.pgp Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] rsync metadata cache patch (obsoletes metadata transfer on sync)
On Sat, Jan 28, 2006 at 11:24:18AM -0600, Andrew Gaffney wrote:
Zac Medico wrote:
I have reimplemented the previous patch as a normal cache module that adds
a writable layer on top of the pre-generated metadata. If you'd like to
try this out (with portage-2.1_preX), simply copy metadata_overlay.py into
/usr/lib/portage/pym/cache/ and add portdbapi.auxdbmodule =
cache.metadata_overlay.database to /etc/portage/modules.
I haven't tested this much, but like the previous patch, this shouldn't
cause any harm. Feedback would be appreciated.
Portage didn't explode and dep calculation is pretty damn quick with an
empty /var/cache/edb/dep/,
Shouldn't be any difference here, if you are seeing a difference
please time it and post the stats here- it should actually be slightly
slower then a straight flat_hash cache since it's 2 lookups worst case
instead of single lookup.
If you're seeing a difference, indicative of one of the
following
1) I'm a moron and am missing something,
2) innefficiency in flat_hash pulls (since you should be using
metadata for most of the queries, the actual underlying ro cache)
3) something is funky.
Is it normal for /var/cache/edb/dep/${PORTDIR}/ to be re-created
(it's still empty) when this new module is in use?
Flat_hash does that up front so it doesn't have to do tests for the
directory on __setitem__ calls; so yes, normal :)
Additional issue here zach pointed out is that the current flat_list
cache format used for rsync metadata/cache doesn't actually bundle
eclass mtimes, so stale detection for eclasses won't work via this.
Part of the reason the metadata class exists (and can handle
flat_list/flat_hash internally on it's own)- until flat_hash is the
rsync tree format, staleness detection won't work for running straight
from $PORTDIR/metadata/cache
~harring
pgpDodbkhjTKl.pgp
Description: PGP signature
Re: [gentoo-portage-dev] emerge-default-opts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All, disreguard this message; it seems to work now. I didn't change anything so I have no idea what happened. Thanks, William On Sat, Jan 28, 2006 at 02:25:18PM -0600, William Hubbs wrote: All, I'm not sure if this is a bug or if I am doing something wrong. I have portage 2.1_pre4 installed and the following in make.conf: EMERGE_DEFAULT_OPTS=--nocolor --nospinner But at least the --nospinner option isn't working. Since I am blind and use a screen reader, the spinner is annoying and I would like to turn that off. I can't be sure about the --nocolor option yet unless I do another test real quick. Is --nospinner supposed to work in emerge_default_opts? Thanks, William -- gentoo-portage-dev@gentoo.org mailing list -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD29hIblQW9DDEZTgRAoH3AKCGdcweg5PPL7ZrQCTnfFxTLQh3UgCbB7p0 TVXcbWcmi8XF7FiZTH+ZP88= =k/kN -END PGP SIGNATURE- -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] --nospinner in emerge_default_opts
William Hubbs wrote: I just ran a test with this again, and it does look like --nospinner is not allowed in emerge_default_opts. If this should be filed as a bug, let me know, or if it isn't a bug, would it be possible to allow this option? Is there a reason you can't just alias it? -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] --nospinner in emerge_default_opts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrew Gaffney wrote: William Hubbs wrote: I just ran a test with this again, and it does look like --nospinner is not allowed in emerge_default_opts. If this should be filed as a bug, let me know, or if it isn't a bug, would it be possible to allow this option? If in doubt, file one and if it isn't one we can always close it later. Just double check that you can reproduce the outcome. Is there a reason you can't just alias it? Er, if it's a bug it's a bug ;) Although that is probably a solution in the meantime :) - -Alec Warner (antarus) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQ9wn32zglR5RwbyYAQKMwBAAkMsuOiscuSnOH92/8hpbWljI+bCM2EWz 8RAGv7yJX3CohhmmZLTMWuimJFmrwHuu8eVddZlzVeBacv/oCuu2faP0HenKnejc iXmIW5pGMYDY7W/dy5bW7lPfrU610kV/ePhnnVjSXBL8kpTBVJu56bOcSVQBD0S9 3xDPfzk4Rj0PYJtv+pUtqKjcFsCku2hnEDIa4j1kYbJxJU6acFVrCbaD8VQ1F6Sz nGYbMpWnvv17vhie++i1/HkIZ2QXnyIVxzYudkbMjzYU+Dwyhkts4zvrOQixI3jN OzC8SdNUbjs2BMQ5932DgrroY63aLBKUjNbqKFdeS/sAhXe578kFfLZvI/HVSYK2 WC0ywoeuGZX/ZischYaHfCnOPAtRLwMeLab62/3+e0niuHaN4lvdGXjHTv+dzl4x jUVw5NEUZCgOCNK/aTYmVcx+0OUAQaskRIdINCBqNTuelAAmqo94XfdHqfJKLfve LVoPqS2dQQp9Wj4akQiEVZgihrPtNtaTQS7q7BA2BUJCcGpSyAVmOZ/hHmByd5nJ mSkEBuSr22hLl9xF+BMEZvldw2t7fi3uBczC4fUC81O4jd9fDjqlEpS/o6wdKtUP Q8Z3oanNoP4Ao2seL9ZWx6+H2RnwvwnqwQqRAmkH1BAljpNTtowDdxwooWc81NAW jVJsCbhFYRg= =81H2 -END PGP SIGNATURE- -- gentoo-portage-dev@gentoo.org mailing list
