On Mon, May 28, 2012 at 9:09 PM, Maxim Kammerer wrote:
> Ditto, ~2 years with regular full @world rebuild.
>
Yup, been years since the last time I even saw a bug for this.
Probably wouldn't hurt to announce in news if it will impact existing
users. I doubt anybody would actually remove the port
On Tue, May 29, 2012 at 12:34 AM, Zac Medico wrote:
> Note that ebuilds can set RESTRICT="userpriv" if they require superuser
> privileges during any of the src_* phases that userpriv affects.
Current list of packages in portage using userpriv restriction:
app-laptop/tp_smapi
dev-db/firebird
gam
Zac Medico posted on Mon, 28 May 2012 14:34:22 -0700 as excerpted:
> 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 users
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 05/28/2012 11:34 PM, Zac Medico wrote:
> 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.
> Objection
On Mon, May 28, 2012 at 11:34 PM, 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
Am Montag 28 Mai 2012, 23:34:22 schrieb Zac Medico:
> 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?
No objections. Excellent idea.
--
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
On 05/28/2012 02:02 AM, Pacho Ramos wrote:
> El dom, 27-05-2012 a las 17:16 -0700, Zac Medico escribió:
>> On 05/27/2012 11:12 AM, Samuli Suominen wrote:
>>> Fedora rawhide and ArchLinux switched to libusbx and followed suit in
>>> our virtual/libusb:1.
>>> Debian is considering the switch also. We
Hi everyone,
while I was looking at various printing bugs, I came across the package net-
print/foomatic-filters-ppds. It claims to provide the non-ps-printer ppd's for
foomatic, but the last version is from 2008.
* foomatic-db (current) contains the same printers "unprocessed"
* there is no up
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 27/05/12 10:56 AM, William Hubbs wrote:
> On Sun, May 27, 2012 at 10:49:07AM -0400, Ian Stakenvicius wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>>
>> On 26/05/12 03:40 PM, William Hubbs wrote:
>>> All,
>>>
>>> I realize this has b
El lun, 28-05-2012 a las 09:58 +0200, Michał Górny escribió:
> As autotools-utils exports phase functions, it will be better if
> remove_libtool_files() functions would be somewhere else.
> ---
> eutils.eclass | 68
> +
> 1 file changed, 6
El dom, 27-05-2012 a las 17:16 -0700, Zac Medico escribió:
> On 05/27/2012 11:12 AM, Samuli Suominen wrote:
> > Fedora rawhide and ArchLinux switched to libusbx and followed suit in
> > our virtual/libusb:1.
> > Debian is considering the switch also. We'll see...
> >
> > I've been in contact with
As autotools-utils exports phase functions, it will be better if
remove_libtool_files() functions would be somewhere else.
---
eutils.eclass | 68 +
1 file changed, 68 insertions(+)
diff --git a/eutils.eclass b/eutils.eclass
index c88ef35.
13 matches
Mail list logo
