Re: [gentoo-dev] suspicious code in gnustep eclasses

[Paweł Hajdan, Jr.]

On 3/31/12 8:45 AM, Fabian Groffen wrote:
> On 30-03-2012 13:00:33 +0200, "Paweł Hajdan, Jr." wrote:
>> This is from gnustep-base.eclass:
>>
>>> egnustep_doc() {
>>> if [[ -d ./Documentation ]] ; then
>>> # Check documentation presence
>>> cd "${S}"/Documentation
>>> if [[ -f ./[mM]akefile || -f ./GNUmakefile ]] ; then
>>> emake "${GS_ENV[@]}" all || die "doc make failed"
>>> emake "${GS_ENV[@]}" install || die "doc install failed"
>>> fi
>>> cd ..
>>> fi
>>> }
>>
>> Shouldn't those cd calls above rather be pushd/popd? It seems the above
>> assumes that CWD is "${S}" when egnustep_doc is executed, which is
>> probably true, but pushd/popd seems just safer.
> 
> Go ahead.

I've checked in this and all other changes to CVS, after testing gnustep
packages locally.

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?

[Agostino Sarubbo]

On Monday 28 May 2012 14:34:22 Zac Medico wrote:
> Hi,
> 
> In case you aren't familiar with FEATURES=userpriv, here's the
> description from the make.conf(5) man page:
> 
>   Allow portage to drop root privileges and compile packages as
>   portage:portage without a sandbox (unless usersandbox is also used).
> 
> The rationale for having the separate "usersandbox" setting, to enable
> use of sys-apps/sandbox, is that people who enable userpriv sometimes
> prefer to have sandbox disabled in order to slightly improve
> performance. However, I would recommend to enable usersandbox by
> default, for the purpose of logging sandbox violations.
> 
> Note that ebuilds can set RESTRICT="userpriv" if they require superuser
> privileges during any of the src_* phases that userpriv affects.
> 
> I've been using FEATURES="userpriv usersandbox" for years, and I don't
> remember experiencing any problems because of it, so I think that it
> would be reasonable to have it enabled by default. Objections?

I'm using usersync since a long time, how about add it too?
-- 
Agostino Sarubboago -at- gentoo.org
Gentoo/AMD64 Arch Security Liaison
GPG: 0x7CD2DC5D


signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] RFC: trivial chromium.eclass patch

[Paweł Hajdan, Jr.]

I'd like to commit the following chromium.eclass patch.

The rationale is that checked kernel config options are not needed for
SELinux sandbox.

After that patch gets committed, I plan to modify the ebuilds in tree.
Can the deprecated function be removed immediately after that, or should
it stay longer? If the latter, how long?

It seems gentoo-dev review is not strictly needed for non-general
eclasses (), but
I'd just make sure I'm making those changes correctly.

Paweł
--- chromium.eclass.orig2012-05-29 10:33:45.0 +0200
+++ chromium.eclass 2012-05-29 10:36:59.0 +0200
@@ -17,11 +17,11 @@
IUSE+=" custom-cflags"
 fi
 
-# @FUNCTION: chromium_check_kernel_config
+# @FUNCTION: chromium_suid_sandbox_check_kernel_config
 # @USAGE:
 # @DESCRIPTION:
-# Ensures the system kernel is configured for full Chromium functionality.
-chromium_check_kernel_config() {
+# Ensures the system kernel supports features needed for SUID sandbox to work.
+chromium_suid_sandbox_check_kernel_config() {
has "${EAPI:-0}" 0 1 2 3 && die "EAPI=${EAPI} is not supported"
 
if [[ "${MERGE_TYPE}" == "source" || "${MERGE_TYPE}" == "binary" ]]; 
then
@@ -34,6 +34,16 @@
fi
 }
 
+# @FUNCTION: chromium_check_kernel_config
+# @USAGE:
+# @DESCRIPTION:
+# Ensures the system kernel is configured for full Chromium functionality.
+chromium_check_kernel_config() {
+   eqawarn "chromium_check_kernel_config is deprecated."
+   eqawarn "Please use chromium_suid_sandbox_check_kernel_config if 
applicable."
+   chromium_suid_sandbox_check_kernel_config
+}
+
 # @ECLASS-VARIABLE: CHROMIUM_LANGS
 # @DEFAULT_UNSET
 # @DESCRIPTION:


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?

[Richard Yao]

On 05/29/12 04:43, Agostino Sarubbo wrote:
> I'm using usersync since a long time, how about add it too?

This is also a good idea. I second it.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?

[Zac Medico]

On 05/29/2012 01:43 AM, Agostino Sarubbo wrote:
> On Monday 28 May 2012 14:34:22 Zac Medico wrote:
>> Hi,
>>
>> In case you aren't familiar with FEATURES=userpriv, here's the
>> description from the make.conf(5) man page:
>>
>>   Allow portage to drop root privileges and compile packages as
>>   portage:portage without a sandbox (unless usersandbox is also used).
>>
>> The rationale for having the separate "usersandbox" setting, to enable
>> use of sys-apps/sandbox, is that people who enable userpriv sometimes
>> prefer to have sandbox disabled in order to slightly improve
>> performance. However, I would recommend to enable usersandbox by
>> default, for the purpose of logging sandbox violations.
>>
>> Note that ebuilds can set RESTRICT="userpriv" if they require superuser
>> privileges during any of the src_* phases that userpriv affects.
>>
>> I've been using FEATURES="userpriv usersandbox" for years, and I don't
>> remember experiencing any problems because of it, so I think that it
>> would be reasonable to have it enabled by default. Objections?
> 
> I'm using usersync since a long time, how about add it too?

Yeah, I think that would be a good default too. I guess the portage
ebuild can do a recursive adjustment of $PORTDIR permissions in
pkg_postinst, in order to solve bug #277970 [1].

For userpriv, it will have to do a similar recursive adjustment of
permissions for directories inside $DISTDIR (such as git-src and
svn-src), since userpriv causes src_unpack to run with lower privileges.

[1] https://bugs.gentoo.org/show_bug.cgi?id=277970
-- 
Thanks,
Zac

[gentoo-dev] Re: [PATCH eutils] Move remove_libtool_files() from autotools-utils for wider use.

[Steven J Long]

Michał Górny wrote:

> +  find "${D}" -type f -name '*.la' -print0 | while read -r -d '' f; 
..
> + rm -f "${f}" || die
..
> +  done

Don't pipe to read like that; it means the final command is in a subshell 
and "die is /not/ guaranteed to work correctly if called from a subshell 
environment."[1]

More seriously, the script doesn't actually get the correct filenames, 
despite being written to handle any filename.
eg:
$ touch $'  foo bar \n\t  '
$ while read -r -d '' f; do echo "'$f'"; done < <(find . -type f -print0)  
'./  foo bar'

You do it like this:

while read -rd ''; do
   f=$REPLY;
   ..
done < <(find "$D" -type f -name '*.la' -print0)

eg:
$ while read -rd ''; do f=$REPLY; echo "'$f'"; done < <(find . -type f -
print0) 
  
'./  foo bar
 
  '

Or use: while IFS= read -rd '' f; do .. if you prefer.
See: help read # in a terminal.

It's called 'Process Substitution' if anyone wants to read about it in
man bash. The classic example with find is to get the list in an array:
arr=()
while read -rd ''; do
  arr+=("$REPLY")
done < <(find "$dir" -type f .. -print0)

(perhaps conditionally though that's usually better done within find
 which can later be handled on a per-file basis, or passed to:
foo "${arr[@]}"

..or if you just want to know whether there is a matching file:
if read -rd '' < <(find . -type f -print0); then
   something matched
else nothing did
fi

They're both things I came up with a few years ago when I was learning
from #bash, which you are in dire need of, based on reading git-2.eclass.

[1] http://dev.gentoo.org/~ulm/pms/head/pms.html#x1-12600011.3.3
(11.3.3.6)
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?

[Michał Górny]

On Tue, 29 May 2012 02:05:08 -0700
Zac Medico  wrote:

> On 05/29/2012 01:43 AM, Agostino Sarubbo wrote:
> > On Monday 28 May 2012 14:34:22 Zac Medico wrote:
> >> Hi,
> >>
> >> In case you aren't familiar with FEATURES=userpriv, here's the
> >> description from the make.conf(5) man page:
> >>
> >>   Allow portage to drop root privileges and compile packages as
> >>   portage:portage without a sandbox (unless usersandbox is also
> >> used).
> >>
> >> The rationale for having the separate "usersandbox" setting, to
> >> enable use of sys-apps/sandbox, is that people who enable userpriv
> >> sometimes prefer to have sandbox disabled in order to slightly
> >> improve performance. However, I would recommend to enable
> >> usersandbox by default, for the purpose of logging sandbox
> >> violations.
> >>
> >> Note that ebuilds can set RESTRICT="userpriv" if they require
> >> superuser privileges during any of the src_* phases that userpriv
> >> affects.
> >>
> >> I've been using FEATURES="userpriv usersandbox" for years, and I
> >> don't remember experiencing any problems because of it, so I think
> >> that it would be reasonable to have it enabled by default.
> >> Objections?
> > 
> > I'm using usersync since a long time, how about add it too?
> 
> Yeah, I think that would be a good default too. I guess the portage
> ebuild can do a recursive adjustment of $PORTDIR permissions in
> pkg_postinst, in order to solve bug #277970 [1].

Wouldn't that break users who sync using a regular user? And then break
again, and again every time portage is merged?


-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

[gentoo-dev] Re: [PATCH eutils] Move remove_libtool_files() from autotools-utils for wider use.

[Steven J Long]

Steven J Long wrote:
> More seriously, the script doesn't actually get the correct filenames,
> despite being written to handle any filename.

This doesn't actually apply in this case with -name '*.la' but it still
looks wrong, and implies one doesn't really grok the usage. *shrug*

-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?

[Rich Freeman]

On Tue, May 29, 2012 at 10:11 AM, Michał Górny  wrote:
>
> Wouldn't that break users who sync using a regular user? And then break
> again, and again every time portage is merged?

Yup, unless that regular user is the same one used for userpriv (if
I'm correctly understanding the problem that you're pointing at).  I
don't see this as a show-stopper - just a reason to have a news item.
Those not using userpriv can always disable it and run as root as they
are already doing.  Those who are using a regular user to sync could
ensure that their make.conf uses the same user for userpriv.

Rich

Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?

[hasufell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/29/2012 04:50 PM, Rich Freeman wrote:
> On Tue, May 29, 2012 at 10:11 AM, Michał Górny 
> wrote:
>> 
>> Wouldn't that break users who sync using a regular user? And then
>> break again, and again every time portage is merged?
> 
> Yup, unless that regular user is the same one used for userpriv
> (if I'm correctly understanding the problem that you're pointing
> at).  I don't see this as a show-stopper - just a reason to have a
> news item. Those not using userpriv can always disable it and run
> as root as they are already doing.  Those who are using a regular
> user to sync could ensure that their make.conf uses the same user
> for userpriv.
> 
> Rich
> 

- -1

I am against too many defaults. It's documented and people can
activate it.
I'm already annoyed by pre-set stuff like "cups" in
releases/make.defaults.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPxOPzAAoJEFpvPKfnPDWz9d8H/A0AQr57nDv/0n0+jN8bxdxc
nPQyBN9faSuh8IYztQmFe1Xpn/JFx9LoqRGQrvncMmzjmPkM1iaoXUpuo/qw5Fys
ar9pN84yZoAJuzgMdLzLs0U/6lqkvLzO+x1Y5DkNU2F+h3Bx9sAk+4vCUjEYg/pC
UdXkeRONaB62p/D2T2ucP6IuG6qBI/raW7vvDvkiDGzVbNnDBe4hGESh3Fb4Gd/Y
x/P/QJ+cZvFF3SvqhORMeXlgccbqU2kBy2Bwcq2GwKKmYIdKwnA2J0KKwqLkHraD
8pkTzUsvqxnQVqFGfCvFyJe3uwiJKQoTIAGugf3n9irvczuZTQ9MDWoZkGKiaNI=
=eo74
-END PGP SIGNATURE-

Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?

[Rich Freeman]

On Tue, May 29, 2012 at 10:57 AM, hasufell  wrote:
> I am against too many defaults. It's documented and people can
> activate it.
> I'm already annoyed by pre-set stuff like "cups" in
> releases/make.defaults.

While universal agreement is a bit much to hope for, I just wanted to
point out that fewer defaults is really just an illusion.

There is ALWAYS a default, anytime you have an option.  The default
might be one thing, or it might be another, but there is ALWAYS a
default.  My thinking is that our defaults should generally reflect
the most mainstream or least-surprising behavior, especially where
there are upstream projects.  in the case of portage, we are the
upstream, so we should do whatever is most useful and least obnoxious
to our users.

If you're running something other than a generic desktop/server, there
will always be a need to tweak things.

Rich

Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?

[hasufell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/29/2012 05:23 PM, Rich Freeman wrote:
> On Tue, May 29, 2012 at 10:57 AM, hasufell 
> wrote:
>> I am against too many defaults. It's documented and people can 
>> activate it. I'm already annoyed by pre-set stuff like "cups" in 
>> releases/make.defaults.
> 
> While universal agreement is a bit much to hope for, I just wanted
> to point out that fewer defaults is really just an illusion.
> 
> There is ALWAYS a default, anytime you have an option.  The
> default might be one thing, or it might be another, but there is
> ALWAYS a default.  My thinking is that our defaults should
> generally reflect the most mainstream or least-surprising behavior,
> especially where there are upstream projects.  in the case of
> portage, we are the upstream, so we should do whatever is most
> useful and least obnoxious to our users.
> 
> If you're running something other than a generic desktop/server,
> there will always be a need to tweak things.
> 
> Rich
> 

Well then let my clarify: I'm against too many pre-set (meaning
"activated") features/useflags.

That's probably a seperate discussion, but I myself would expect the
_default_ profile/config to have almost nothing activated. No
useflags, no features etc.

That may imply that this default is "broken", but it takes more time
to do reverse-configuration while looking for things that someone
considered "sane" and has set for your "convenience".

I discovered this the first time I set up a blank chroot and got a
load of stuff pulled in by some trivial emerges. Some set by already
mentioned releases/make.defaults and similar, some set by ebuilds etc.

What you do with other profiles is a completely different topic,
because I'm not forced to use them.

means: I don't like the fact that I have to set
FEATURES="-foobar"
or
USE="-foobar"

That should almost never be the case (unless I set some globally and
unset some locally or use desktop-profiles etc).

am I offtopic already? Hope you got the point though.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPxPkHAAoJEFpvPKfnPDWzejcH/3g1VGmSRHufoQMHUpi6X1x3
31pNy2Q+SKxo4voy5Y1/mt+0lKGrhyDq6npmBY+7n5RlhdKrn8J3VyQ7HQ1jBGiS
nEdSVb6BCHtFeWWWYRo6efooQFsGT+6NOFQgX/xXXgk9Ndzk8LtURGp8oP0oucNt
YWfhDruoUzJXRyIMP9u6SbbDVXOnYVP+WUniNJ855l2Q1jg5lrwE6f6dD7wsbtyp
3PGBEtMqX9nAtzFZ8blUHngyrMP9J/GcJ3OVQkLXla7WBCWLqKlN0pIIiVqe2L5V
45MPQ/Muhyy0JUKLmLJLvx/2c+1I4mCt1lrfZNNN3zhepnjZSLn/uiGZk3JVEQs=
=KNF8
-END PGP SIGNATURE-

Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?

[Jeff Horelick]

On 29 May 2012 12:27, hasufell  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 05/29/2012 05:23 PM, Rich Freeman wrote:
>> On Tue, May 29, 2012 at 10:57 AM, hasufell 
>> wrote:
>>> I am against too many defaults. It's documented and people can
>>> activate it. I'm already annoyed by pre-set stuff like "cups" in
>>> releases/make.defaults.
>>
>> While universal agreement is a bit much to hope for, I just wanted
>> to point out that fewer defaults is really just an illusion.
>>
>> There is ALWAYS a default, anytime you have an option.  The
>> default might be one thing, or it might be another, but there is
>> ALWAYS a default.  My thinking is that our defaults should
>> generally reflect the most mainstream or least-surprising behavior,
>> especially where there are upstream projects.  in the case of
>> portage, we are the upstream, so we should do whatever is most
>> useful and least obnoxious to our users.
>>
>> If you're running something other than a generic desktop/server,
>> there will always be a need to tweak things.
>>
>> Rich
>>
>
> Well then let my clarify: I'm against too many pre-set (meaning
> "activated") features/useflags.
>
> That's probably a seperate discussion, but I myself would expect the
> _default_ profile/config to have almost nothing activated. No
> useflags, no features etc.
>
> That may imply that this default is "broken", but it takes more time
> to do reverse-configuration while looking for things that someone
> considered "sane" and has set for your "convenience".
>
> I discovered this the first time I set up a blank chroot and got a
> load of stuff pulled in by some trivial emerges. Some set by already
> mentioned releases/make.defaults and similar, some set by ebuilds etc.
>
> What you do with other profiles is a completely different topic,
> because I'm not forced to use them.
>
> means: I don't like the fact that I have to set
> FEATURES="-foobar"
> or
> USE="-foobar"
>
> That should almost never be the case (unless I set some globally and
> unset some locally or use desktop-profiles etc).
>
> am I offtopic already? Hope you got the point though.
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.19 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJPxPkHAAoJEFpvPKfnPDWzejcH/3g1VGmSRHufoQMHUpi6X1x3
> 31pNy2Q+SKxo4voy5Y1/mt+0lKGrhyDq6npmBY+7n5RlhdKrn8J3VyQ7HQ1jBGiS
> nEdSVb6BCHtFeWWWYRo6efooQFsGT+6NOFQgX/xXXgk9Ndzk8LtURGp8oP0oucNt
> YWfhDruoUzJXRyIMP9u6SbbDVXOnYVP+WUniNJ855l2Q1jg5lrwE6f6dD7wsbtyp
> 3PGBEtMqX9nAtzFZ8blUHngyrMP9J/GcJ3OVQkLXla7WBCWLqKlN0pIIiVqe2L5V
> 45MPQ/Muhyy0JUKLmLJLvx/2c+1I4mCt1lrfZNNN3zhepnjZSLn/uiGZk3JVEQs=
> =KNF8
> -END PGP SIGNATURE-
>

I disagree with this. I think Gentoo should be about SANE defaults. If
you want a minimal system, you can turn off all the USE flags and/or
FEATURES and/or use the standard (not desktop/) profile. SANE defaults
like FEATURES="userpriv usersandbox" are optimal for probably 90% of
users and if you're not one of those 90%, there'll be a news item,
just turn them off...

[gentoo-dev] [PATCH] games.eclass: allow EAPI=4

[Sergei Trofimovich]

Nice to drop '|| die' and have REQUIRED_USE in games ebuilds

OK to push?

Thanks!

-- 

  Sergei
Index: games.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/games.eclass,v
retrieving revision 1.147
diff -u -u -r1.147 games.eclass
--- games.eclass	27 Dec 2011 17:55:12 -	1.147
+++ games.eclass	29 May 2012 18:53:22 -
@@ -15,7 +15,7 @@
 
 case ${EAPI:-0} in
 	0|1) EXPORT_FUNCTIONS pkg_setup src_compile pkg_preinst pkg_postinst ;;
-	2|3) EXPORT_FUNCTIONS pkg_setup src_configure src_compile pkg_preinst pkg_postinst ;;
+	2|3|4) EXPORT_FUNCTIONS pkg_setup src_configure src_compile pkg_preinst pkg_postinst ;;
 	*) die "no support for EAPI=${EAPI} yet" ;;
 esac
 


signature.asc
Description: PGP signature

Re: [gentoo-dev] [PATCH] games.eclass: allow EAPI=4

[hasufell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/29/2012 09:00 PM, Sergei Trofimovich wrote:
> Nice to drop '|| die' and have REQUIRED_USE in games ebuilds
> 
> OK to push?
> 
> Thanks!
> 

+1 for bumping

but is this known to not break anything?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPxSUhAAoJEFpvPKfnPDWzGqEH/0gcLXA11HtHwYTKwVI7eEak
9BucZAJm+M98+UW6DJQq9UeU+Yu4W478K+d8ntI09VHqnJ6/Khy3xGeXMU1Sq6Lh
whtg8kGvxgjxhDRbkUTUdCQAdG1l5aTr3ZiHP5pp9ykwmgiAXEctHy11SeKtjpNd
dP94BLxrDTMZRFC5N8H4+OhgT0lUdLv1yFUYRNn9kJNVXPVo+YD6XF1urOe39TQi
lkX5dUT+mXTp66g3bt1VE9aq5XfFYFaqoCzZSo9+T1K0LhO7wyxfEUxwLa3t+vbR
mmm7U9A+kODE1Lc0lBRf4jV5yqkrRMcSFcwdcJnUxVmsRN0mkz2WjcnYsUf9Vfs=
=HfDy
-END PGP SIGNATURE-

Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?

[Ralph Sennhauser]

On Tue, 29 May 2012 18:27:51 +0200
hasufell  wrote:

> Well then let my clarify: I'm against too many pre-set (meaning
> "activated") features/useflags.

Think of it as nouserpriv feature. ;) Either way, to disable userpriv
is kind of working against QA as a package really should be build-able
as non root user but then.

Have userpriv and usersandbox enabled since it's became available, no
issues to report.


signature.asc
Description: PGP signature

Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?

[Michael Orlitzky]

How about introducing e.g. FEATURES="nouserpriv", and make the current
userpriv behavior the default?

The migration might be a bit more confusing, but it allows portage to
gradually adopt better stuff without having FEATURES="everything under
the sun".

Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?

[Mike Gilbert]

On Tue, May 29, 2012 at 3:46 PM, Michael Orlitzky  wrote:
> How about introducing e.g. FEATURES="nouserpriv", and make the current
> userpriv behavior the default?
>

Portage currently defaults to running the build process as root. The
entire point of this thread is that Zac wants to change the default to
build as the portage user (FEATURES="userpriv" in make.globals).

Re: [gentoo-dev] [PATCH] games.eclass: allow EAPI=4

[Mike Gilbert]

On Tue, May 29, 2012 at 3:36 PM, hasufell  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 05/29/2012 09:00 PM, Sergei Trofimovich wrote:
>> Nice to drop '|| die' and have REQUIRED_USE in games ebuilds
>>
>> OK to push?
>>
>> Thanks!
>>
>
> +1 for bumping
>
> but is this known to not break anything?

The easiest way to determine that is to remove the die from the eclass
and start bumping ebuilds to EAPI=4. Any issues can be addressed as
ebuilds are migrated.

Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?

[William Hubbs]

On Tue, May 29, 2012 at 03:46:39PM -0400, Michael Orlitzky wrote:
> How about introducing e.g. FEATURES="nouserpriv", and make the current
> userpriv behavior the default?

No. Please stay away from things like this.
It is reverse logic and can be very confusing. Just adding "-userpriv"
to your features would do exactly the same thing.

William



pgpDBWymIk6cT.pgp
Description: PGP signature

Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?

[Michael Orlitzky]

On 05/29/12 15:58, Mike Gilbert wrote:
> On Tue, May 29, 2012 at 3:46 PM, Michael Orlitzky  
> wrote:
>> How about introducing e.g. FEATURES="nouserpriv", and make the current
>> userpriv behavior the default?
>>
> 
> Portage currently defaults to running the build process as root. The
> entire point of this thread is that Zac wants to change the default to
> build as the portage user (FEATURES="userpriv" in make.globals).
> 

Right, I was just offering a way to change the default behavior without
adding another value to the FEATURES variable, which seems to be
hasufell's objection.

Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?

[Zac Medico]

On 05/29/2012 07:11 AM, Michał Górny wrote:
> On Tue, 29 May 2012 02:05:08 -0700
> Zac Medico  wrote:
> 
>> On 05/29/2012 01:43 AM, Agostino Sarubbo wrote:
>>> I'm using usersync since a long time, how about add it too?
>>
>> Yeah, I think that would be a good default too. I guess the portage
>> ebuild can do a recursive adjustment of $PORTDIR permissions in
>> pkg_postinst, in order to solve bug #277970 [1].
> 
> Wouldn't that break users who sync using a regular user?

No, because the "usersync" feature causes the rsync process to inherit
the UID and GID of the PORTDIR directory (obtained using the stat function).

> And then break
> again, and again every time portage is merged?

No, I would not want to trigger an relatively expensive operation like
this more that once. So, it would only be triggered in pkg_postinst if
the replaced version of portage did not have usersync enabled by default.
-- 
Thanks,
Zac

Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?

[Hilco Wijbenga]

On 29 May 2012 12:46, Michael Orlitzky  wrote:
> How about introducing e.g. FEATURES="nouserpriv", and make the current
> userpriv behavior the default?

rootpriv instead of nouserpriv?

> The migration might be a bit more confusing, but it allows portage to
> gradually adopt better stuff without having FEATURES="everything under
> the sun".

Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?

[Zac Medico]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/29/2012 07:57 AM, hasufell wrote:
> I am against too many defaults. It's documented and people can 
> activate it. I'm already annoyed by pre-set stuff like "cups" in 
> releases/make.defaults.

In the case of userpriv and usersync, I expect that we can eventually
make them unconditional, so that they'll no longer need to be listed
in FEATURES.
- -- 
Thanks,
Zac
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/FSSIACgkQ/ejvha5XGaPTnwCg0QAe1WtZv/wMlMvb5WrxbTk+
jq4AnjTTo77BXYr0d+4F/6P3/447Jk7t
=CuDh
-END PGP SIGNATURE-

Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?

[Zac Medico]

On 05/29/2012 02:47 PM, Hilco Wijbenga wrote:
> On 29 May 2012 12:46, Michael Orlitzky  wrote:
>> How about introducing e.g. FEATURES="nouserpriv", and make the current
>> userpriv behavior the default?
> 
> rootpriv instead of nouserpriv?

What's the use case for this? Can't we just enable userpriv
unconditionally, so that it doesn't have to be listed in FEATURES? Note
that ebuilds will still be able to use RESTRICT=userpriv if necessary.
-- 
Thanks,
Zac

Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?

[Richard Yao]

On 05/29/12 18:11, Zac Medico wrote:
> On 05/29/2012 02:47 PM, Hilco Wijbenga wrote:
>> On 29 May 2012 12:46, Michael Orlitzky  wrote:
>>> How about introducing e.g. FEATURES="nouserpriv", and make the current
>>> userpriv behavior the default?
>>
>> rootpriv instead of nouserpriv?
> 
> What's the use case for this? Can't we just enable userpriv
> unconditionally, so that it doesn't have to be listed in FEATURES? Note
> that ebuilds will still be able to use RESTRICT=userpriv if necessary.

Would FEATURES=-userpriv still work at the command line? It could be
useful for debugging to keep that working.



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] RFC: Virtual for awk implementation

[Christoph Junghans]

Hi,

recently I stumbled across a problem with mawk, which is apprearly
Ubuntu's default awk interpreter.
This brought the idea to my mind of adding a virtual for awk. Beside
the fact that we already have 3 awk interpreters in gx86 (gawk, mawk
and busybox awk), there are other ones like nawk and awka.

I had some discussions with spanKY on that topic in bug #415689, which
summarizes in the following:

Advantages:
- mawk is faster - useful for scientific purposes
- busybox awk could replace gawk on minimal systems
- more POSIX conform systems

Disadvantages:
- some awk code in the tree and portage is probably using GNU
extensions without executing gawk explicitly
- gray zone of Posix 1003.2  (e.g. substr() function and an index of 0)

What we would need:
- virtual/awk
- app-admin/eselect-awk (version available in cj-overlay)
and
- testing and migration of existing packages using gawk

and

to name a few.

I have tested mawk as default interpreter for a while on my x86 boxes
and didn't observed any problems so far.

Cheers,

Christoph

-- 
Christoph Junghans
http://dev.gentoo.org/~ottxor/

Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?

[Zac Medico]

On 05/29/2012 04:22 PM, Richard Yao wrote:
> On 05/29/12 18:11, Zac Medico wrote:
>> On 05/29/2012 02:47 PM, Hilco Wijbenga wrote:
>>> On 29 May 2012 12:46, Michael Orlitzky  wrote:
 How about introducing e.g. FEATURES="nouserpriv", and make the current
 userpriv behavior the default?
>>>
>>> rootpriv instead of nouserpriv?
>>
>> What's the use case for this? Can't we just enable userpriv
>> unconditionally, so that it doesn't have to be listed in FEATURES? Note
>> that ebuilds will still be able to use RESTRICT=userpriv if necessary.
> 
> Would FEATURES=-userpriv still work at the command line? It could be
> useful for debugging to keep that working.

Yeah, I guess it would be bad for it to be unconditional, because
permission issues seem to be a really common source of trouble for
people. Even something as seemingly simple as userfetch probably
shouldn't be unconditional, due to issues like the ACLs discussed in bug
#416705 [1].

[1] https://bugs.gentoo.org/show_bug.cgi?id=416705
-- 
Thanks,
Zac

Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?

[Hilco Wijbenga]

On 29 May 2012 15:11, Zac Medico  wrote:
> On 05/29/2012 02:47 PM, Hilco Wijbenga wrote:
>> On 29 May 2012 12:46, Michael Orlitzky  wrote:
>>> How about introducing e.g. FEATURES="nouserpriv", and make the current
>>> userpriv behavior the default?
>>
>> rootpriv instead of nouserpriv?
>
> What's the use case for this? Can't we just enable userpriv
> unconditionally, so that it doesn't have to be listed in FEATURES? Note
> that ebuilds will still be able to use RESTRICT=userpriv if necessary.

Absolutely, this was more in response to the "please no reverse logic"
(which I agree with).

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Rich Freeman]

On Sat, May 26, 2012 at 12:18 PM, Alexey Shvetsov  wrote:
> Since most of us want "clean cut" solution so i will close bug #333699 as
> WONTFIX

Along these lines, I'm looking at 333531 (the git migration tracker),
and it seems like there isn't actually much to do:

333685 - Seems like no action, and not sure how critical
333687 - while the bug is still open, as far as I can tell it seems
good enough to me to move forward
333697 - ditto
333701 - paused since there are other tasks to do first, though it
seems to me that little remains

333705 - not sure how critical this actually is - do we care if in
some obscure case history is lost?  Nothing says that we have to
completely destroy the old cvs repo.  Maybe we should just do a mock
migration now and post copies of the before/after somewhere public and
let people have at them.

333709 - seems like there is legitimate work to be done here, but
again nothing that big

So, what is the big issue?  Is there something not being tracked, or
is one of those items a lot harder than it looks?

Rich