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
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 the new
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, 68
-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 been discussed
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
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'll see...
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
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.
--
On Mon, May 28, 2012 at 11:34 PM, Zac Medico zmed...@gentoo.org 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
-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.
Objections?
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
On Tue, May 29, 2012 at 12:34 AM, Zac Medico zmed...@gentoo.org 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
On Mon, May 28, 2012 at 9:09 PM, Maxim Kammerer m...@dee.su 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
On 05/27/2012 03:27 AM, Pacho Ramos wrote:
I have seen today a fixed bug that was only reproducible for people
(like me) running without userpriv (but maintainer didn't found it
before commiting because he was running with this feature enabled), I
have also seen some packages skipping tests
14 matches
Mail list logo
