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, a
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 t
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?
>>>
>
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 aw
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
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 userpri
-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
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 h
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
>> eb
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 poi
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 fea
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 no
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 def
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".
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 n
-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.
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
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 b
-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.
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 fe
-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 tha
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'r
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-c
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:
> >>
> >>
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.
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
>> po
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
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 l
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
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
30 matches
Mail list logo
