[gentoo-dev] Re: /etc/udev/rules.d nightmare - orphaned files in /etc
Sven Köhler skoehler at upb.de writes: Hi, i had some orphaned files in /etc/udev/rules.d. Namely 40-fuse.rules and 60-fuse.rules. The files were never removed, since they are protected - aren't they? So that is _very_, _very_ unpractical, because the older your gentoo gets, the more of such orphaned files you get. Something similar (orphaned HAL policy preventing USB automounting) already has bitten some users recently, including me: http://forums.gentoo.org/viewtopic-t-518094.html BTW, I really like the pace of changes in udev and hal. At least one can see that the projects are live and kicking :-) That said, it would be nice if portage/whatever took care of this so users wouldn't be forced to mess with the udev and/or hal policies... Regards -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New maintainers needed for packages
On 21/11/06, Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote: app-text/txt2man (low maintenance) I'll take this... -- -Charlie -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] /etc/udev/rules.d nightmare - orphaned files in /etc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel Drake wrote: Sven Köhler wrote: Have you ever thought about sollutions of that problem? It's not a real problem, that these files are orphaned - but they are neither removed nor renamed, so they stay in place and in one or the other way, they may start to disturb. Wasn't portage modified to remove unmodified config-protected files on unmerge a while back? It's not quite as simple as it sounds, due to interactions between merge and unmerge phases. If not, is this a sensible suggestion? Daniel Yes, it's quite sensible. It's fixed in svn now and I'll release it as soon as it's had enough testing. Watch bug 8423 for progress... Zac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFaXEZ/ejvha5XGaMRAlZRAKCSF3FThVZKoiSZ3kLAS1McPjOtGgCg3fKv CYNZsSG0moQSKscaSeGr/0I= =AYBj -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New developer: Alexander Gabert (pappy) returns from retirement
It is my pleasure to announce that Alexander pappy Gabert is returning from retirement to battle the hardened bugs. Retired sometime in 2004, he is now again interested in being blessed with a @gentoo.org email address. Nowadays he lives in Trier, Germany and is reaching his thirties. That's about all his quiz told me about him but I am hopeful that all you old farts who remember him are able to spread all kinds of FUD about him. So please welcome pappy back to the dev community with the usual rites. Welcome back to the flock, Alex :) May the force be with you! -- Christian Heim phreak at gentoo.org GPG key ID: 9A9F68E6 Fingerprint: AEC4 87B8 32B8 4922 B3A9 DF79 CAE3 556F 9A9F 68E6 -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: New developer: Alexander Gabert (pappy) returns from retirement
Tach Petteri, 0x2B859DE3 (PGP-PK-ID) Petteri Räty schrieb: It is my pleasure to announce that Alexander pappy Gabert is returning from retirement to battle the hardened bugs. Retired sometime in 2004, he is now again interested in being blessed with a @gentoo.org email address. And I owe him a beer (or two). V-Li -- Fingerprint: 68C5 D381 B69A A777 6A91 E999 350A AD7C 2B85 9DE3 http://www.gnupg.org/ -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: Make 'nls' use flag more generic
On Sunday 26 November 2006 13:24, Charlie Shepherd wrote: The description for the nls use flag is currently 'Adds Native Language Support (using gettext - GNU locale utilities)'. However, in bug 137297, the kde herd would like to pull in kde-i18n from kde-meta, And *how* KDE is using those kde-i18n package? Think about it... Through GETTEXT, INDEED! -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ... pgpLjroBmmUpc.pgp Description: PGP signature
Re: [gentoo-dev] RFC: Make 'nls' use flag more generic
On Sun, Nov 26, 2006 at 03:17:39PM +0100, Diego 'Flameeyes' Pettenò wrote: On Sunday 26 November 2006 13:24, Charlie Shepherd wrote: The description for the nls use flag is currently 'Adds Native Language Support (using gettext - GNU locale utilities)'. However, in bug 137297, the kde herd would like to pull in kde-i18n from kde-meta, And *how* KDE is using those kde-i18n package? Think about it... Through GETTEXT, INDEED! It's using gettext? Maybe I'm just clueless (very well possible), but I was under the impression that KDE had its own internal language handling. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: Make 'nls' use flag more generic
On Sunday 26 November 2006 16:46, Harald van Dijk wrote: It's using gettext? Maybe I'm just clueless (very well possible), but I was under the impression that KDE had its own internal language handling. It uses gettext's format, with gettext's utilities for building the .po files in .mo, and then uses its own internal copy of gettext's functions to load them. There's no way to turn off the KLocale support (of course), but it's still gettext that's being used for the kde-i18n packages, as that is what have been used to build the package. So yes, it uses its own internal language handling _and_ it still uses gettext. Same would apply if a package was using the Perl implementation or the Ruby bindings. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ... pgpQ1WMXDR6yR.pgp Description: PGP signature
Re: [gentoo-dev] RFC: Make 'nls' use flag more generic
On Sun, Nov 26, 2006 at 04:45:59PM +0100, Harald van Dijk wrote: On Sun, Nov 26, 2006 at 03:17:39PM +0100, Diego 'Flameeyes' Pettenò wrote: On Sunday 26 November 2006 13:24, Charlie Shepherd wrote: The description for the nls use flag is currently 'Adds Native Language Support (using gettext - GNU locale utilities)'. However, in bug 137297, the kde herd would like to pull in kde-i18n from kde-meta, And *how* KDE is using those kde-i18n package? Think about it... Through GETTEXT, INDEED! It's using gettext? Maybe I'm just clueless (very well possible), but I was under the impression that KDE had its own internal language handling. Already figured out it really is using gettext, just differently from other packages. So please ignore my previous mail. :) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] ACCEPT_LICENSE revisited
On Saturday 18 November 2006 02:53, Marius Mauch wrote: Anyone interested in this feature should review the attached version. i've come to the party a bit late ... i cant seem to divine the answer to my question from reading this thread and the GLEP and the bugzilla, so perhaps someone can explicitly spell it out for me ... is there a way in the new GLEP to say never bother me with any license bullcrap ? i made sure the current check_license() function respected the idea of * so that i can put this in my make.conf: ACCEPT_LICENSES=* the way this is defined matters not so long as the behavior can be achieved (in other words, i dont care if the required setting is * or or unset or ...) -mike pgpq6PB8qZJ1t.pgp Description: PGP signature
Re: [gentoo-dev] Announcement: New(ish) eclass pax-utils.eclass
On Friday 24 November 2006 11:16, Kevin F. Quinn wrote:
Although I committed it originally almost a year ago, it hasn't been
used yet, so if there's anything fundamentally wrong with whole thing,
now is the time say as it can be removed with impunity.
some suggestions:
you should use $@ rather than $*
looks like every use of ${f} should be quoted
full paths to paxctl/chpax/scanelf seem pretty lame to me, especially since
not having /sbin and /usr/bin in $PATH while executing portage code would
never work
use 'type -p prog /dev/null' rather than '[[ -x /full/path/prog ]]'
host-is-pax() { grep -qs ^PaX: /proc/self/status ; }
-mike
pgp4mlvxQwIVe.pgp
Description: PGP signature
[gentoo-dev] Re: missing metadata.xml
Tach,0x2B859DE3 (PGP-PK-ID) dev-scheme/guile-pg scheme dev-scheme/kawa scheme dev-scheme/mzscheme scheme Done. V-Li -- Fingerprint: 68C5 D381 B69A A777 6A91 E999 350A AD7C 2B85 9DE3 http://www.gnupg.org/ -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] [treecleaner] Last rites: net-p2p/gtkhx
# Deprecated: upstream dead, unsupported, doesn't compile anymore. # Pending removal Dec 26 # See #146571 net-p2p/gtkhx -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] [treecleaner] package removals
# Christian Heim [EMAIL PROTECTED] (14 Oct 2006) # masking media-radio/xastir for treecleaners, bug(s) 109695 # Pending removal 14th November 2006 media-radio/xastir # Christian Heim [EMAIL PROTECTED] (14 Oct 2006) # masking media-libs/gltt for treecleaners, bug(s) 145969 # Pending removal 14th November 2006 media-libs/gltt # Christian Heim [EMAIL PROTECTED] (14 Oct 2006) # masking app-misc/linup for treecleaners, bug(s) 150740 # Pending removal 14th November 2006 app-misc/linup # Christian Heim [EMAIL PROTECTED] (14 Oct 2006) # masking app-admin/sus for treecleaners, bug(s) 148901 # Pending removal 14th November 2006 app-admin/sus -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] ACCEPT_LICENSE revisited
On Sun, 26 Nov 2006 13:07:21 -0500 Mike Frysinger [EMAIL PROTECTED] wrote: is there a way in the new GLEP to say never bother me with any license bullcrap ? i made sure the current check_license() function respected the idea of * so that i can put this in my make.conf: ACCEPT_LICENSES=* Not directly, you'd need to define a local license group including all licenses (could automate that with a postsync hook I guess) and use that in ACCEPT_LICENSE. Marius -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] ACCEPT_LICENSE revisited
On Tue, 21 Nov 2006 14:03:08 -0500 Chris Gianelloni [EMAIL PROTECTED] wrote: It is used to mask the package, correct. When a package is masked, it gives the output of the license, or, if the license it too large (I think Marius set it at 20K) informs the user to read the license file. It also explains to the user that they will need to read and accept the license. The limit was at 2k, however I've dropped that feature before I updated the GLEP as it would only cover about 35% of the licenses in the tree (the rest are 2k) and it would have major issues with non-plaintext licenses (and there are a few licenses using pdf, html or other formats), so now emerge will only refer the user to the licenses file by printing the filename (still need to decide if/how to account for licenses in overlays). Marius -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] ACCEPT_LICENSE revisited
On Sunday 26 November 2006 18:38, Marius Mauch wrote: Mike Frysinger [EMAIL PROTECTED] wrote: is there a way in the new GLEP to say never bother me with any license bullcrap ? i made sure the current check_license() function respected the idea of * so that i can put this in my make.conf: ACCEPT_LICENSES=* Not directly, you'd need to define a local license group including all licenses (could automate that with a postsync hook I guess) and use that in ACCEPT_LICENSE. in other words, your only proposed solution is a hack ? -mike pgpIF5BDaabeJ.pgp Description: PGP signature
[gentoo-dev] Re: FEATURES to cut the excess in portage
Enrico Weigelt [EMAIL PROTECTED] wrote: Can those flags be used in dependencies ? Not as far as I know. They're FEATURES, not flags, and are global. Let's say, some package needs certain tools (ie. TeX) for building its documentation, it would be stupid to build the whole docs and so require these tools, if docs are not wanted at all. That's what the doc USE flag is for. ;) -- by design, by neglect dirtyepic gentoo orgfor a fact or just for effect 9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8) signature.asc Description: PGP signature
[gentoo-dev] Re: spamc standalone package
Enrico Weigelt [EMAIL PROTECTED] wrote: is anyone else working on an standalone spamc package ? I've got several machines where I don't want to have the whole spamassassin installed - they're just calling an remote machine to do this work. Sounds like a good question for the Networking forum and/or gentoo-user ML. -- by design, by neglect dirtyepic gentoo orgfor a fact or just for effect 9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8) signature.asc Description: PGP signature
[gentoo-dev] [treecleaner] Last rites: media-libs/jpeg-mmx
# Upstream wants it dead, we want it dead, it's time to die. # Pending removal Dec 26 2006, bug 156373 media-libs/jpeg-mmx -- gentoo-dev@gentoo.org mailing list
