Re: [gentoo-dev] RFC: new project gentoo-extreme-security
On 10/22/07, Sune Kloppenborg Jeppesen [EMAIL PROTECTED] wrote: On Monday 22 October 2007 06:04:58 Donnie Berkholz wrote: On 01:42 Mon 22 Oct , Alexander Gabert wrote: this is a request for comments on a new project: http://www.gentoo.org/proj/en/extreme-security/ This sounds interesting, though the project page is not very specific. I'm curious whether this would be better-placed as a subproject of either the security or hardened projects. Why do you think it would be better off independent? The Security Team as it stands now is mostly reactive and not proactive so I don't think it would fit very well as a sub project of security. Hardened is another matter. -- Sune Kloppenborg Jeppesen (Jaervosz) Gentoo Linux Security Team http://security.gentoo.org -- [EMAIL PROTECTED] mailing list I live the way you put 'friendly' first :) regarding the past posts about the existing security team, I'm thinking this project is suposed to build up some suite of applications and configurations to let the administrator control his security settings in a more easy way. imo this does not clash with the security team's purpose; this project will that the security team's results and make it into a more frieldy suite I'd be more than happy to assist in this project, or the main security team. -- Thanks, Omer Cohen www.omerc.net [EMAIL PROTECTED] -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Last rites: app-emacs/wanderlust-cvs
# Ulrich Mueller [EMAIL PROTECTED] (23 Oct 2007) # Live CVS ebuild, masked for removal in 30 days. # Use CVS snapshot in app-emacs/wanderlust as replacement. app-emacs/wanderlust-cvs -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-freebsd/freebsd-lib: ChangeLog freebsd-lib-6.2-r3.ebuild
On 12:02 Tue 23 Oct , Roy Marples (uberlord) wrote: 1.1 sys-freebsd/freebsd-lib/freebsd-lib-6.2-r3.ebuild file : http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-freebsd/freebsd-lib/freebsd-lib-6.2-r3.ebuild?rev=1.1view=markup plain: http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-freebsd/freebsd-lib/freebsd-lib-6.2-r3.ebuild?rev=1.1content-type=text/plain PATCHES=${FILESDIR}/${PN}-bsdxml.patch ${FILESDIR}/${PN}-6.0-pmc.patch ${FILESDIR}/${PN}-6.0-gccfloat.patch ${FILESDIR}/${PN}-6.0-flex-2.5.31.patch ${FILESDIR}/${PN}-6.0-binutils-asm.patch ${FILESDIR}/${PN}-6.0-ssp.patch ${FILESDIR}/${PN}-6.1-csu.patch ${FILESDIR}/${PN}-6.2-bluetooth.patch ${FILESDIR}/${PN}-6.2-gcc41.patch ${FILESDIR}/${PN}-6.2-dl_iterate_phdr.patch ${FILESDIR}/${PN}-6.2-as-needed.patch ${FILESDIR}/${PN}-6.2-libthr.patch Would it make this work with space-filled paths to single-quote each patch? I tried a quick test, and it looks like it would. # Add symlinks (- libthr) for legacy threading libraries, since these are # not built by us (they are disabled in FreeBSD-7 anyway). dosym libthr.a /usr/lib/libpthread.a dosym libthr.so /usr/lib/libpthread.so dosym libthr.a /usr/lib/libc_r.a dosym libthr.so /usr/lib/libc_r.so # Add symlink (- libthr) so previously built binaries still work. dosym libthr.so.2 /lib/libpthread.so.2 dosym libthr.so.2 /lib/libc_r.so.6 # Compatibility symlinks to run FreeBSD 5.x binaries (ABI is mostly # identical, remove when problems will actually happen) dosym /lib/libc.so.6 /usr/lib/libc.so.5 dosym /lib/libm.so.4 /usr/lib/libm.so.3 FreeBSD doesn't use get_libdir() ? Thanks, Donnie -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-freebsd/freebsd-lib: ChangeLog freebsd-lib-6.2-r3.ebuild
On Tue, 2007-10-23 at 10:24 -0700, Donnie Berkholz wrote: On 12:02 Tue 23 Oct , Roy Marples (uberlord) wrote: 1.1 sys-freebsd/freebsd-lib/freebsd-lib-6.2-r3.ebuild file : http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-freebsd/freebsd-lib/freebsd-lib-6.2-r3.ebuild?rev=1.1view=markup plain: http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-freebsd/freebsd-lib/freebsd-lib-6.2-r3.ebuild?rev=1.1content-type=text/plain PATCHES=${FILESDIR}/${PN}-bsdxml.patch ${FILESDIR}/${PN}-6.0-pmc.patch ${FILESDIR}/${PN}-6.0-gccfloat.patch ${FILESDIR}/${PN}-6.0-flex-2.5.31.patch ${FILESDIR}/${PN}-6.0-binutils-asm.patch ${FILESDIR}/${PN}-6.0-ssp.patch ${FILESDIR}/${PN}-6.1-csu.patch ${FILESDIR}/${PN}-6.2-bluetooth.patch ${FILESDIR}/${PN}-6.2-gcc41.patch ${FILESDIR}/${PN}-6.2-dl_iterate_phdr.patch ${FILESDIR}/${PN}-6.2-as-needed.patch ${FILESDIR}/${PN}-6.2-libthr.patch Would it make this work with space-filled paths to single-quote each patch? I tried a quick test, and it looks like it would. Probably. I should fix that. FreeBSD doesn't use get_libdir() ? FreeBSD has no concept of multilib as yet. Thanks Roy -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Last rites: dev-java/jdbc2-stdext
# Petteri Räty [EMAIL PROTECTED] (23 Oct 2007) # These classes are included in the JDK since 1.4 # Will be moved to Java overlays after a month dev-java/jdbc2-stdext signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-plugins/compiz-fusion-plugins-main: compiz-fusion-plugins-main-0.6.0.ebuild metadata.xml ChangeLog Manifest
Hanno Boeck (hanno) kirjoitti: hanno 07/10/23 22:33:31 S=${WORKDIR}/${P} This is the default. src_compile() { econf `use_enable jpeg` || die econf failed emake || die make failed } I think it's more common to use the $() syntax for use_enable. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-plugins/compiz-fusion-plugins-main: compiz-fusion-plugins-main-0.6.0.ebuild metadata.xml ChangeLog Manifest
Am Mittwoch 24 Oktober 2007 schrieb Petteri Räty: Hanno Boeck (hanno) kirjoitti: hanno 07/10/23 22:33:31 S=${WORKDIR}/${P} This is the default. src_compile() { econf `use_enable jpeg` || die econf failed emake || die make failed } I think it's more common to use the $() syntax for use_enable. I'll do it later today. They seem to be good candidates for new repoman checks, as we probably have tons of them in the tree. -- Hanno Böck Blog: http://www.hboeck.de/ GPG: 3DBD3B20 Jabber: [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-libs/compiz-bcop: metadata.xml Manifest compiz-bcop-0.6.0.ebuild ChangeLog
On 22:28 Tue 23 Oct , Hanno Boeck (hanno) wrote: 1.1 x11-libs/compiz-bcop/compiz-bcop-0.6.0.ebuild file : http://sources.gentoo.org/viewcvs.py/gentoo-x86/x11-libs/compiz-bcop/compiz-bcop-0.6.0.ebuild?rev=1.1view=markup plain: http://sources.gentoo.org/viewcvs.py/gentoo-x86/x11-libs/compiz-bcop/compiz-bcop-0.6.0.ebuild?rev=1.1content-type=text/plain S=${WORKDIR}/${P} src_compile() { econf || die econf failed emake || die make failed } Both S and src_compile() are the defaults, and this is not the only compiz ebuild committed today where that is the case. Thanks, Donnie -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Last Rites - Oct 14th - 21st, 2007
Attached are the packages that have been scheduled for removal this week. Sorry bout the wait. -- fonts / wxWindows / gcc-porting / treecleaners EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 (0xF9A40662) x11-misc/xcut Krzysiek Pawlik [EMAIL PROTECTED]15 Nov 2007 dev-util/portatosourceview Markus Ullmann [EMAIL PROTECTED]20 Nov 2007 dev-php4/adodb-ext Christian Hoffmann [EMAIL PROTECTED] Jan 2008 dev-php4/creoleChristian Hoffmann [EMAIL PROTECTED] Jan 2008 dev-php4/eaccelerator Christian Hoffmann [EMAIL PROTECTED] Jan 2008 dev-php4/ffmpeg-phpChristian Hoffmann [EMAIL PROTECTED] Jan 2008 dev-php4/jargonChristian Hoffmann [EMAIL PROTECTED] Jan 2008 dev-php4/jpgraph Christian Hoffmann [EMAIL PROTECTED] Jan 2008 dev-php4/pecl-apc Christian Hoffmann [EMAIL PROTECTED] Jan 2008 dev-php4/pecl-crackChristian Hoffmann [EMAIL PROTECTED] Jan 2008 dev-php4/pecl-fileinfo Christian Hoffmann [EMAIL PROTECTED] Jan 2008 dev-php4/pecl-http Christian Hoffmann [EMAIL PROTECTED] Jan 2008 dev-php4/pecl-id3 Christian Hoffmann [EMAIL PROTECTED] Jan 2008 dev-php4/pecl-imagick Christian Hoffmann [EMAIL PROTECTED] Jan 2008 dev-php4/pecl-json Christian Hoffmann [EMAIL PROTECTED] Jan 2008 dev-php4/pecl-mailparseChristian Hoffmann [EMAIL PROTECTED] Jan 2008 dev-php4/pecl-memcache Christian Hoffmann [EMAIL PROTECTED] Jan 2008 dev-php4/pecl-pdflib Christian Hoffmann [EMAIL PROTECTED] Jan 2008 dev-php4/pecl-ps Christian Hoffmann [EMAIL PROTECTED] Jan 2008 dev-php4/pecl-radius Christian Hoffmann [EMAIL PROTECTED] Jan 2008 dev-php4/pecl-sqlite Christian Hoffmann [EMAIL PROTECTED] Jan 2008 dev-php4/pecl-tidy Christian Hoffmann [EMAIL PROTECTED] Jan 2008 dev-php4/pecl-translit Christian Hoffmann [EMAIL PROTECTED] Jan 2008 dev-php4/pecl-yaz Christian Hoffmann [EMAIL PROTECTED] Jan 2008 dev-php4/pecl-zip Christian Hoffmann [EMAIL PROTECTED] Jan 2008 dev-php4/phpdbgChristian Hoffmann [EMAIL PROTECTED] Jan 2008 dev-php4/php-java-bridge Christian Hoffmann [EMAIL PROTECTED] Jan 2008 dev-php4/phpunit Christian Hoffmann [EMAIL PROTECTED] Jan 2008 dev-php4/suhosin Christian Hoffmann [EMAIL PROTECTED] Jan 2008 dev-php4/syck-php-bindings Christian Hoffmann [EMAIL PROTECTED] Jan 2008 dev-php4/xcacheChristian Hoffmann [EMAIL PROTECTED] Jan 2008 dev-php4/xdebugChristian Hoffmann [EMAIL PROTECTED] Jan 2008 dev-php4/ZendOptimizer Christian Hoffmann [EMAIL PROTECTED] Jan 2008 table tr thPackage:/th thRemoval date:/th thContact:/th /tr tr tiuri link=http://packages.gentoo.org/packages/?category=x11-misc;name=xcut;x11-misc/xcut/uri/ti ti15 Nov 2007/ti timail link=[EMAIL PROTECTED]Krzysiek Pawlik/mail/ti /tr tr tiuri link=http://packages.gentoo.org/packages/?category=dev-util;name=portatosourceview;dev-util/portatosourceview/uri/ti ti20 Nov 2007/ti timail link=[EMAIL PROTECTED]Markus Ullmann/mail/ti /tr tr tiuri link=http://packages.gentoo.org/packages/?category=dev-php4;name=adodb-ext;dev-php4/adodb-ext/uri/ti tiJan 2008/ti timail link=[EMAIL PROTECTED]Christian Hoffmann/mail/ti /tr tr tiuri link=http://packages.gentoo.org/packages/?category=dev-php4;name=creole;dev-php4/creole/uri/ti tiJan 2008/ti timail link=[EMAIL PROTECTED]Christian Hoffmann/mail/ti /tr tr tiuri link=http://packages.gentoo.org/packages/?category=dev-php4;name=eaccelerator;dev-php4/eaccelerator/uri/ti tiJan 2008/ti timail link=[EMAIL PROTECTED]Christian Hoffmann/mail/ti /tr tr tiuri link=http://packages.gentoo.org/packages/?category=dev-php4;name=ffmpeg-php;dev-php4/ffmpeg-php/uri/ti tiJan 2008/ti timail link=[EMAIL PROTECTED]Christian Hoffmann/mail/ti /tr tr tiuri link=http://packages.gentoo.org/packages/?category=dev-php4;name=jargon;dev-php4/jargon/uri/ti tiJan 2008/ti timail link=[EMAIL PROTECTED]Christian Hoffmann/mail/ti /tr tr tiuri link=http://packages.gentoo.org/packages/?category=dev-php4;name=jpgraph;dev-php4/jpgraph/uri/ti tiJan 2008/ti timail link=[EMAIL PROTECTED]Christian Hoffmann/mail/ti /tr tr tiuri link=http://packages.gentoo.org/packages/?category=dev-php4;name=pecl-apc;dev-php4/pecl-apc/uri/ti tiJan 2008/ti timail link=[EMAIL PROTECTED]Christian Hoffmann/mail/ti /tr tr tiuri link=http://packages.gentoo.org/packages/?category=dev-php4;name=pecl-crack;dev-php4/pecl-crack/uri/ti tiJan 2008/ti timail link=[EMAIL PROTECTED]Christian Hoffmann/mail/ti /tr tr tiuri link=http://packages.gentoo.org/packages/?category=dev-php4;name=pecl-fileinfo;dev-php4/pecl-fileinfo/uri/ti tiJan 2008/ti timail link=[EMAIL PROTECTED]Christian Hoffmann/mail/ti /tr
Re: [gentoo-portage-dev] Re: About system and world
On Mon, 22 Oct 2007 21:29:02 -0700 Zac Medico [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ryan Hill wrote: Zac Medico wrote: implement greedy atoms for the world set. I've been pondering the idea of making world non-greedy for slots by default [1], since you can add slot atoms to the world file to pull in any specific slot(s) that you want. That would rock. Portage always insisting on pulling in the highest SLOT whether needed or not is one of my biggest pet-peeves. Well, you can already use SLOT atoms in your world file if you don't want the highest available. Packages that pull in =foo are a different story though. I suppose we can add something like a - --upgrade=minimal option that prevents pulling in new slots if they aren't required. Don't restrict it to SLOTs though. minimal implies that only upgrades required to satisfy the depgraph are performed. The described behavior should be another value, e.g. no-slot-change. Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-portage-dev] About system and world
On Sun, 21 Oct 2007 15:12:31 +0200 Marius Mauch [EMAIL PROTECTED] wrote: Well, the primary goal is to make all sets behave in a consistent way. And some sets have the explicit purpose to rebuild stuff, so making sets selective by default also has issues. The proposed change would also make sets behave in the same way as packages which is IMO another benefit. This actually has more consequences: selective is a global setting, you can't enable it just for some arguments. Therefore if packages and sets are treated differently it requires that they can't be mixed on the commandline (and if we'd make the setting configurable for each set then only one set can be used at any time). And right now I can't think of another reason why that restriction would be necessary. Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-portage-dev] Re: About system and world
On 2007/10/23, Marius Mauch [EMAIL PROTECTED] wrote: On Mon, 22 Oct 2007 21:29:02 -0700 Zac Medico [EMAIL PROTECTED] wrote: Well, you can already use SLOT atoms in your world file if you don't want the highest available. Packages that pull in =foo are a different story though. I suppose we can add something like a - --upgrade=minimal option that prevents pulling in new slots if they aren't required. Don't restrict it to SLOTs though. minimal implies that only upgrades required to satisfy the depgraph are performed. Couldn't this minimal behavior just be triggered by lack of the --upgrade option (emerge -D set)? Actually, the current --upgrade behavior (with or without --deep) is a bit weird imho, i would prefer something like this (with foo being either a set or an atom): * emerge foo: do the minimum upgrades or new installs required to get foo satisfied. Only its direct deps are checked (and direct deps of the unsatisfied ones, etc.), with the minimal heuristic (upgrade them only if stricly required). * emerge -u foo: do all required new installs and possible upgrades of foo. Only its direct deps are checked (and direct deps of the unsatisfied ones, etc.), with the minimal heuristic (upgrade them only if strictly needed). * emerge -D foo: do the minimal upgrades or new installs required to get foo satisfied. Also, check all of its direct and indirect deps, with the minimal heuristic (upgrade only if strictly needed). * emerge -uD foo: do all required new installs and possible upgrades of foo. Also, all its direct and indirect deps are checked, and upgraded where possible. For those who wonder, and if i'm not mistaken, current behaviors of this four combinations, expressed in those words, are: * emerge foo: do all required new installs and possible upgrades of foo. Only its direct deps are checked (and direct deps of the unsatisfied ones, etc.), with the minimal heuristic (upgrade them only if strictly needed). = same as my emerge -u foo * emerge -u foo: do all required new installs and possible upgrades of foo and its direct deps. Also, check all of their direct and indirect deps, with the minimal heuristic (upgrade them only if strictly needed). = i don't see usefulness of this special case. Whether some code is direct or indirect dep is often subject to some maintainer's choices, and may vary with time (for instance, an internal lib of a big package being splitted out as a separate dep of this package). * emerge -D foo and emerge -uD foo : do all required new installs and possible upgrades of foo. Also, all its direct and indirect deps are checked, and upgraded where possible. = same as my emerge -uD foo. But waste of one of the four options combinations. -- TGL. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-portage-dev] Re: About system and world
On Tue, 23 Oct 2007 21:11:48 +0200 Thomas de Grenier de Latour [EMAIL PROTECTED] wrote: On 2007/10/23, Marius Mauch [EMAIL PROTECTED] wrote: On Mon, 22 Oct 2007 21:29:02 -0700 Zac Medico [EMAIL PROTECTED] wrote: Well, you can already use SLOT atoms in your world file if you don't want the highest available. Packages that pull in =foo are a different story though. I suppose we can add something like a - --upgrade=minimal option that prevents pulling in new slots if they aren't required. Don't restrict it to SLOTs though. minimal implies that only upgrades required to satisfy the depgraph are performed. Couldn't this minimal behavior just be triggered by lack of the --upgrade option (emerge -D set)? --upgrade != the current --update (at least that's what I assumed) Actually, the current --upgrade behavior (with or without --deep) is a bit weird imho, i would prefer something like this (with foo being either a set or an atom): Yes, --update has a history of being a mess of random behavior. Personally I'd drop it completely, or alias it to --noreplace. * emerge foo: do the minimum upgrades or new installs required to get foo satisfied. Only its direct deps are checked (and direct deps of the unsatisfied ones, etc.), with the minimal heuristic (upgrade them only if stricly required). * emerge -u foo: do all required new installs and possible upgrades of foo. Only its direct deps are checked (and direct deps of the unsatisfied ones, etc.), with the minimal heuristic (upgrade them only if strictly needed). * emerge -D foo: do the minimal upgrades or new installs required to get foo satisfied. Also, check all of its direct and indirect deps, with the minimal heuristic (upgrade only if strictly needed). * emerge -uD foo: do all required new installs and possible upgrades of foo. Also, all its direct and indirect deps are checked, and upgraded where possible. Maybe --upgrade as name was an unfortunate choice, --resolver might be better. What I'd like ideally (as a user) is to replace --update, --deep, --noreplace and --emptytree with the following options: --resolver={minimal,noslotchange,leastchange,default} minimal: select the lowest possible version noslotchange: like default, but try to avoid slotchanges leastchange: select the version with the smallest version delta compared to the installed version, otherwise like default default: current behavior --rebuild={never,always,changeduse,newuse,changeddeps,selected} never: never rebuild packages always: always rebuild packages (like current --emtpytree) changeduse: rebuild packages if $USE has changed newuse: rebuild packages if $USE or $IUSE has changed changeddeps: rebuild packages if any of its direct dependencies were updated selected: rebuild the selected arguments (root nodes) --deplevel=n check n level of dependencies for updates (with -1 == infinite) of course all dependencies have to be satisfied, this controls only what deps should be checked for optional updates current defaults would be --resolver=default --rebuild=selected --deplevel=0 --update would be --rebuild=never --deplevel=1 --deep would be --deplevel=-1 --emptytree would be --rebuild=always --deplevel=-1 But that's just me dreaming of a better world, where we don't have to deal with legacies ;) Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-portage-dev] Re: About system and world
On Wed, 24 Oct 2007 00:03:47 +0200 Thomas de Grenier de Latour [EMAIL PROTECTED] wrote: Bah, you're introducing a new options set, and have (i think) ways to emulate all of the old ones with them, so what is stopping you? You would just have to forbid mixes of old style and new style on the same command line. Mainly the work required to implement it ;) And I'd rather finish dynoparse first so it can be used here. Oh, and ideally the mentioned values wouldn't be hardcoded lists, but come from a pluggable resolver system, but that probably counts as overengineering. Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature