Re: [gentoo-dev] RFC: Package Manager Specification: configuration protection
Protected Locations === Protected locations are determined by the ``CONFIG_PROTECT`` environment variable, which is defined in the profiles and which may be augmented or overridden by the current environment and user configuration files. This variable contains a space separated list of values which are matched against the beginning of a full file path and name of files to be installed. which are matched against the beginning of a full file path would mean that e.g. CONFIG_PROTECT=/etc/foo would protect the following: /etc/foobar/doh /etc/foo /etc/foobaz .. or did I misunderstand something here? I don't know whether that is the current behaviour of portage, but IMO it certainly shouldn't be. It should rather be /etc/foo (file) or, if /etc/foo is a dir: /etc/foo/* -- Kind Regards, Simon Stelling Gentoo/AMD64 developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: Package Manager Specification: configuration protection
On Tue, 12 Sep 2006 10:19:40 +0200 Simon Stelling [EMAIL PROTECTED] wrote: | Protected Locations | === | | Protected locations are determined by the ``CONFIG_PROTECT`` | environment variable, which is defined in the profiles and which | may be augmented or overridden by the current environment and user | configuration files. This variable contains a space separated list | of values which are matched against the beginning of a full file | path and name of files to be installed. | | which are matched against the beginning of a full file path would | mean that e.g. CONFIG_PROTECT=/etc/foo would protect the following: | | /etc/foobar/doh | /etc/foo | /etc/foobaz | | .. or did I misunderstand something here? I don't know whether that is | the current behaviour of portage, but IMO it certainly shouldn't be. | It should rather be | | /etc/foo (file) | or, if /etc/foo is a dir: | /etc/foo/* Mm. I had a play with this. I'd like someone else to do independent tests, because I'm seeing something weird here. But it looks like Portage's current behaviour is: with CONFIG_PROTECT=/foo: * if /foo is a file, it's not protected * if /foo is a directory, its contents (including subdirectories) are protected * /foofoo (file) is not protected * /foobar/baz is not protected and weirdly, with CONFIG_PROTECT=/foo/ * if /foo/ is a directory, its contents are protected during unmerge but not during merge All of this is rather weird, and doesn't match up to what I've been told by Portage people that Portage is supposed to do... -- Ciaran McCreesh Mail: ciaranm at ciaranm.org signature.asc Description: PGP signature
Re: [gentoo-dev] GIMP 1.2 has gotta die
Hanno Böck wrote: Am Dienstag, 12. September 2006 02:46 schrieb Michael Cummings: Looks like that will break media-gfx/frontline (=media-gfx/gimp-1.2*) and gimp-freetype-0.2-r3 (also =media-gfx/gimp-1.2*). frontline is dead upstream, has no metadata and last changelog-entry is about a year old, so I suspect there's not much interest in it. gimp-freetype has newer versions stable on all archs, so removal of old versions shouldn't hurt. I'd kill them all. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] profiles/default-linux/$arch/ChangeLog reminder
Several architectures now have a ChangeLog for their default-linux/$arch directories. If you make changes to these architecture's profiles, please put a ChangeLog entry. [EMAIL PROTECTED] /var/cvsroot/gentoo-x86/profiles/default-linux $ find -name ChangeLog | sort ./alpha/ChangeLog ./amd64/ChangeLog ./hppa/ChangeLog ./ia64/ChangeLog ./sparc/ChangeLog ./x86/ChangeLog Thanks, -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
[gentoo-dev] Toys for arch / release people
According to some arch / release types, there're a few simple queries and reports they'd find very useful. Since these kinds of things are very easy to do if you have a decent API, I put together a tool for a few of them. As of sys-apps/paludis-0.6.2, the adjutrix client can: * display a lagging stable / dropped keywords chart, similar to imlate, but a) SLOT aware and b) not tied to using a single 'target' architecture. I believe the sparc people are using this for their reporting now, and they can probably set up other archs for automatic emailage if desired. * display an eshowkwish graph, but without the nasty bash hacks. * display the profile-provided values for USE and the USE_EXPAND variables for a given or all profiles. * display the default resolution for the system set (stable or ~arch) for a given or all profiles. Note that adjutrix doesn't require a Paludis configuration setup (it deliberately ignores all user configuration and environment settings), and it doesn't require that you use Paludis as your package manager in any way. It's shipped as part of sys-apps/paludis merely because we don't consider it worth making separate libpaludis, paludis, qualudis, adjutrix, gtkpaludis etc packages at this point. If anyone has any other suggestions for this kind of user configuration independent tool, give me a prod here or in #paludis. Writing these is really trivial and almost certainly worth the effort... I remain, Sirs, your most humble and obedient servant, -- Ciaran McCreesh Mail: ciaranm at ciaranm.org signature.asc Description: PGP signature
Re: [gentoo-dev] Suggestion: Globalization of some USE flags
I would like to suggest to globalize cairo, openexr and udev USE flags. These USE flags are used by enough amount of packages. Also cairo and udev USE flags are set defaultly in many profiles. Arfrever -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] hackergotchis + rss feeds
I finally got off my butt and added a small tweak to the feeds for Planet Gentoo, and now you get to see the hackergotchis in your RSS reader as well. Which brings me to my next point -- hardly anyone on planet has one. Send one in! It doesn't have to be a headshot either, an avatar will do nicely. Steal the one from your forums account if you want. Just send in *something*. :) Steve -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: Package Manager Specification: configuration protection
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: On Tue, 12 Sep 2006 10:19:40 +0200 Simon Stelling [EMAIL PROTECTED] wrote: | Protected Locations | === | | Protected locations are determined by the ``CONFIG_PROTECT`` | environment variable, which is defined in the profiles and which | may be augmented or overridden by the current environment and user | configuration files. This variable contains a space separated list | of values which are matched against the beginning of a full file | path and name of files to be installed. | | which are matched against the beginning of a full file path would | mean that e.g. CONFIG_PROTECT=/etc/foo would protect the following: | | /etc/foobar/doh | /etc/foo | /etc/foobaz | | .. or did I misunderstand something here? I don't know whether that is | the current behaviour of portage, but IMO it certainly shouldn't be. | It should rather be | | /etc/foo (file) | or, if /etc/foo is a dir: | /etc/foo/* Mm. I had a play with this. I'd like someone else to do independent tests, because I'm seeing something weird here. But it looks like Portage's current behaviour is: with CONFIG_PROTECT=/foo: * if /foo is a file, it's not protected * if /foo is a directory, its contents (including subdirectories) are protected * /foofoo (file) is not protected * /foobar/baz is not protected and weirdly, with CONFIG_PROTECT=/foo/ * if /foo/ is a directory, its contents are protected during unmerge but not during merge All of this is rather weird, and doesn't match up to what I've been told by Portage people that Portage is supposed to do... When I've looked at the relevant code, it's given me the impression that it could use some improvement. Frankly, I'm not surprised that portage's CONFIG_PROTECT handling doesn't behave quite like one would hope/expect in the cases mentioned above. Anyway, I'd like to fix it so that it behaves better in all of those cases. Note that bug 14321 already exists for that specific case that Simon has mentioned. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFBvAU/ejvha5XGaMRAidrAJ9jQfHIHuDLomohU0JURE9f4fwPggCgvmhb hnnzooKZCwmdDl4mG8wsqIA= =J3/L -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GIMP 1.2 has gotta die
On Tue, 2006-09-12 at 11:56 +0200, Luca Barbato wrote: Hanno Böck wrote: Am Dienstag, 12. September 2006 02:46 schrieb Michael Cummings: Looks like that will break media-gfx/frontline (=media-gfx/gimp-1.2*) and gimp-freetype-0.2-r3 (also =media-gfx/gimp-1.2*). frontline is dead upstream, has no metadata and last changelog-entry is about a year old, so I suspect there's not much interest in it. gimp-freetype has newer versions stable on all archs, so removal of old versions shouldn't hurt. I'd kill them all. I agree with killing gimp 1.2. The last gentoo revision to the ebuild was October 7th, 2005. Nearly a year old. Theres also a ton of bugs (just looking at the bug list, #123028, #135566, and probably others that I'm too tired to look up) on it. For frontline, if I found the right frontline, its made for Gnome 1.4. Kill it as well. Or, if people complain enough, put it in an overlay so the few people that *do* need to use it can. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] xinitrc/startx scripts unification
Lukasz Pawelczyk wrote:
I wanted to fill bugzilla report about this but found few existing
without neither serious solution nor being current.
There is an incosistency in current xinitrc behaviour (i'm only talking
about xinitrc run through startx, not {k,g,x}dm).
Either Joshua Baergen or I are the right people to work with on this.
You can catch up with us on IRC in #gentoo-desktop as Josh_B and
dberkholz to discuss this in more detail.
I haven't had time to look through your patch, but I do want to explain
the philosophy. Our xinit has diverged way too far from upstream. What
needs to happen is for us to first determine what the correct behavior
is, IOW what upstream does. Next, we need to fix our stuff to do that.
Then, we need to make any necessary changes to add functionality like
xinitrc.d, and create patches to merge those changes upstream.
The goal is to create a modernized, upstreamable setup that reduces our
maintainance and patch size to near zero and allows other distributions
to also benefit from our work. I think Red Hat also has some nice xinit
patches, they forked off their own version a few years back.
Thanks,
Donnie
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Package Manager Specification: configuration protection
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: On Tue, 12 Sep 2006 10:19:40 +0200 Simon Stelling [EMAIL PROTECTED] wrote: | Protected Locations | === | | Protected locations are determined by the ``CONFIG_PROTECT`` | environment variable, which is defined in the profiles and which | may be augmented or overridden by the current environment and user | configuration files. This variable contains a space separated list | of values which are matched against the beginning of a full file | path and name of files to be installed. | | which are matched against the beginning of a full file path would | mean that e.g. CONFIG_PROTECT=/etc/foo would protect the following: | | /etc/foobar/doh | /etc/foo | /etc/foobaz | | .. or did I misunderstand something here? I don't know whether that is | the current behaviour of portage, but IMO it certainly shouldn't be. | It should rather be | | /etc/foo (file) | or, if /etc/foo is a dir: | /etc/foo/* Mm. I had a play with this. I'd like someone else to do independent tests, because I'm seeing something weird here. But it looks like Portage's current behaviour is: with CONFIG_PROTECT=/foo: * if /foo is a file, it's not protected * if /foo is a directory, its contents (including subdirectories) are protected * /foofoo (file) is not protected * /foobar/baz is not protected and weirdly, with CONFIG_PROTECT=/foo/ * if /foo/ is a directory, its contents are protected during unmerge but not during merge All of this is rather weird, and doesn't match up to what I've been told by Portage people that Portage is supposed to do... I've attached to bug 14321 [1] a patch that I believe implements the CONFIG_PROTECT behavior that most people would expect from portage. The differences from previous behavior are as follows: 1) Allows files (not just directories) in CONFIG_PROTECT and CONFIG_PROTECT_MASK. 2) Properly accounts for an optional trailing slash on directory paths. 3) Prevents /etc/foo from matching /etc/foobaz or /etc/foobaz/bar. Testing of the patch (against portage-2.1.1) would be appreciated. Zac [1] http://bugs.gentoo.org/show_bug.cgi?id=14321#c15 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFBzhF/ejvha5XGaMRApxqAJ0XcfuqkfNn8L68HLRRynSyXf9grgCcCgok CNysJhEHA5mUvX84vmB8PU0= =KPm0 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] hackergotchis + rss feeds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sep 12, 2006, at 11:55, Steve Dibb wrote: Which brings me to my next point -- hardly anyone on planet has one. Send one in! It doesn't have to be a headshot either, an avatar will do nicely. Is my commonly used buddy icon pic[1] good enough? It's not exactly a hackergotchi, but it is _something_... -Hasan [1] http://blog.charlies-server.no-ip.com/hasan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (Darwin) iD8DBQFFBzm6zsotBnB7jxgRAiHeAJ9edDfGTVtY1UvVQkxMyXVT718WWgCgjA/G Mns0GESUmHaGOEP5yYtrLws= =41Cj -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: Package Manager Specification: configuration protection
On Tue, 12 Sep 2006 15:44:22 -0700 Zac Medico [EMAIL PROTECTED] wrote: | 3) Prevents /etc/foo from matching /etc/foobaz or /etc/foobaz/bar. Is this really desired behaviour? Once we decide that, I'll have a testsuite we can use. It's written for Paludis, but easily portable. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org signature.asc Description: PGP signature
Re: [gentoo-dev] hackergotchis + rss feeds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sep 12, 2006, at 18:50, Hasan Khalil wrote: Is my commonly used buddy icon pic[1] good enough? It's not exactly a hackergotchi, but it is _something_... Oops, meant to send that only to Steve. Sorry for the excess traffic. While I'm at it though, I figured I might ask... Are there any available (traffic) statistics on the RSS feeds? I think that might be interesting to some of us... -Hasan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (Darwin) iD8DBQFFBzzKzsotBnB7jxgRAtL0AJ0Zyo+gSP1ZNps3nJ6Xf9vq5ZpizACfWRXQ lo0rOZtRa6w1M1EIlT4ZGgc= =8/Fx -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: Package Manager Specification: configuration protection
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: On Tue, 12 Sep 2006 15:44:22 -0700 Zac Medico [EMAIL PROTECTED] wrote: | 3) Prevents /etc/foo from matching /etc/foobaz or /etc/foobaz/bar. Is this really desired behaviour? In my opinion, it is a desirable change. I doubt that many people (if anyone?) will miss that particular matching behavior. If so, please speak up now. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFB0la/ejvha5XGaMRAiTgAKDgoV3Vasw2Fk5r2mKy5FlltoCa2gCfXNj1 E/rA0gJXmwiZFZEnrlU7e+Q= =+zAN -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] New libcaca license
So, I was working on updating libcaca to 0.99_bea4 version, but there's a new license to add, and I'd liek to know if anybody has a problem with this ... http://sam.zoy.org/wtfpl/ -- DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE Version 2, December 2004 Copyright (C) 2004 Sam Hocevar 22 rue de Plaisance, 75014 Paris, France Everyone is permitted to copy and distribute verbatim or modified copies of this license document, and changing it is allowed as long as the name is changed. DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 0. You just DO WHAT THE FUCK YOU WANT TO. -- If nobody has a problem with this next evening (UTC+2), I'll commit libcaca-0.99 under p.mask and this license to the licenses directory. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgp6SkTIZtfzD.pgp Description: PGP signature
Re: [gentoo-dev] New libcaca license
Diego 'Flameeyes' Petten wrote: So, I was working on updating libcaca to 0.99_bea4 version, but there's a new license to add, and I'd liek to know if anybody has a problem with this ... http://sam.zoy.org/wtfpl/ -- Diego, The DO WHAT THE FUCK YOU WANT license is apparently a perfectly valid (though amusing) Free software license, according to an old post [1] on the debian-legal list. Thus, I see no reason for no qualms against its terms. []1 http://lists.debian.org/debian-legal/2002/09/msg00032.html -- Peter Gordon (codergeek42) Gentoo Forums Global Moderator GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 My Blog: http://thecodergeek.com/blog/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Package Manager Specification: configuration protection
Ciaran McCreesh wrote: On Tue, 12 Sep 2006 15:44:22 -0700 Zac Medico [EMAIL PROTECTED] wrote: | 3) Prevents /etc/foo from matching /etc/foobaz or /etc/foobaz/bar. Is this really desired behaviour? Once we decide that, I'll have a testsuite we can use. It's written for Paludis, but easily portable. Yes, it's desired behavior. I can't think of half-measure as being useful - either drop it completely, or implement full wildcard support. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New libcaca license
On Wed, 13 Sep 2006 02:16:19 +0200 Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote: If nobody has a problem with this next evening (UTC+2), I'll commit libcaca-0.99 under p.mask and this license to the licenses directory. You appear to be violating the license by considering anyone else's opinion but your own :-P -- Jason Wever Gentoo/Sparc Team Co-Lead signature.asc Description: PGP signature
Re: [gentoo-dev] New libcaca license
On Wednesday 13 September 2006 02:37, Peter Gordon wrote: The DO WHAT THE FUCK YOU WANT license is apparently a perfectly valid (though amusing) Free software license, according to an old post [1] on the debian-legal list. I never intended otherwise, but better safe than sorry, I'd rather check this with other people ;) -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgppGPfZaQxPg.pgp Description: PGP signature
Re: [gentoo-dev] New libcaca license
On Wednesday 13 September 2006 03:19, Jason Wever wrote: You appear to be violating the license by considering anyone else's opinion but your own :-P I never said I will consider other opinions anyway ;) But you're probably right. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpV7Zui4rPe4.pgp Description: PGP signature
Re: [gentoo-dev] Need guidance for updating CHOST
On 9/12/06, Mike Frysinger [EMAIL PROTECTED] wrote: On Tuesday 12 September 2006 22:23, Richard Fish wrote: What I've basically been telling people is to: please god stop telling people that ive given Wernfried Haas proper instructions, he just needs to write them up Is there a Readers Digest version you can give the userreps so we can at least answer the question properly when it comes up? -Richard -- gentoo-dev@gentoo.org mailing list
