On Friday 25 January 2013 19:10:53 Gilles Dartiguelongue wrote:
> It's not like libcap is a big dependency
true, but not everyone needs this, nor can everyone leverage it (caps). it's
a linux-centric implementation and is dependent upon filesystem support being
available & enabled.
that doesn'
Nuno J. Silva posted on Fri, 25 Jan 2013 22:06:35 +0200 as excerpted:
> I am almost sure the current check does *not* use config.gz but
> /usr/src/linux/.config. At least, I've not had config.gz enabled for a
> long time, and I've always seen the checks working. In fact, I think the
> checks print
On 26/01/2013 01:10, Gilles Dartiguelongue wrote:
> If the USE flag must stay, how is it different that current caps USE
> flag ? It applies and not just enables support but is that relevant to
> the purpose at hand ?
filecaps require the kernel to support security xattrs on the
filesystems used f
This might be a silly question already answered in a previous thread,
but why make it filecaps a USE-enable capability at all ?
It's not like libcap is a big dependency and it's not like this is an
attempt to make the system more secure by according just the privileges
needed for apps to work as i
i've taken Constanze' work and rewritten it a bit to be easier to use (imo) as
most settings are now defaults
-mike
# Copyright 1999-2013 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: fcaps.eclass
# @MAINTAINER:
# Constanze Hausner
#
On Fri, Jan 25, 2013 at 3:06 PM, Nuno J. Silva wrote:
> Well, we could also get rid of issues with clashing USE flags by getting
> rid of USE flags and offering monolithic binary packages with almost
> every compatible feature enabled by default.
I'm not suggesting that we get rid of options - on
On 2013-01-25, Rich Freeman wrote:
> On Fri, Jan 25, 2013 at 2:47 PM, Nuno J. Silva wrote:
>>
>> Sorry, what's the difference between cheching =y and =m? I thought those
>> were both part of the kernel config...
>
> I'm talking about /proc/config.gz, which only reflects .config at the
> time that
On Fri, Jan 25, 2013 at 2:47 PM, Nuno J. Silva wrote:
>
> Sorry, what's the difference between cheching =y and =m? I thought those
> were both part of the kernel config...
I'm talking about /proc/config.gz, which only reflects .config at the
time that the kernel was built. So, build with config=
On 2013-01-25, Rich Freeman wrote:
> On Fri, Jan 25, 2013 at 1:24 PM, Nuno J. Silva wrote:
>> Is there any syntax to check if something is either disabled or built as
>> a module?
>
> Very problematic. What is built in for the currently running kernel
> can be fairly reliably determined by grepp
El vie, 25-01-2013 a las 14:22 -0500, Rich Freeman escribió:
> On Fri, Jan 25, 2013 at 2:05 PM, Pacho Ramos wrote:
> > Does it apply to /dev/shm? That is the line I have in my fstab:
> > shm /dev/shmtmpfs
> > nodev,nosuid,noexec 0 0
>
> No. It applies ONLY to /dev
On Fri, Jan 25, 2013 at 2:19 PM, Christopher Head wrote:
> Surely even that isn’t good enough, since the user could have built an
> option as a module, tested it out, discovered it worked fine, and then
> rebuilt the kernel with the option set to Y, but the .ko file would
> still be left lying aro
On Fri, Jan 25, 2013 at 2:05 PM, Pacho Ramos wrote:
> Does it apply to /dev/shm? That is the line I have in my fstab:
> shm /dev/shmtmpfs
> nodev,nosuid,noexec 0 0
No. It applies ONLY to /dev - if you even have a /dev line, and if
you don't that is OK.
Rich
On Fri, 25 Jan 2013 13:47:05 -0500
Rich Freeman wrote:
> Very problematic. What is built in for the currently running kernel
> can be fairly reliably determined by grepping /proc/config.gz - IF
> support for that was enabled in the kernel. But, there is no
> guarantee that this kernel will be r
I got today the udev news item and found:
- "The need of CONFIG_DEVTMPFS=y in the kernel; need to verify the
fstype for possible /dev line in /etc/fstab is devtmpfs (and not, for
example, tmpfs)"
Does it apply to /dev/shm? That is the line I have in my fstab:
shm /dev/shm
On Fri, Jan 25, 2013 at 1:24 PM, Nuno J. Silva wrote:
> Is there any syntax to check if something is either disabled or built as
> a module?
Very problematic. What is built in for the currently running kernel
can be fairly reliably determined by grepping /proc/config.gz - IF
support for that was
On 2013-01-22, Robin H. Johnson wrote:
> I'm raising this patch because of the recent spate of bugs with the
> latest udev that now fails to boot your system if CONFIG_DEVTMPFS is
> not available in your kernel.
>
> Bugs: 408947, 409393, 437320, 453074
>
> CONFIG_CHECK has not been fatal for so
functionality is now provided by >=net-misc/youtube-viewer[gtk]-3.0.3
bug 453580
removal in 30 days
On 25/01/2013 15:23, Dirkjan Ochtman wrote:
> Even so, I could downgrade and revdep-rebuild after that, and it
> should Just Work, right?
Yes and no — you're safer if you get rid of the .so.1 first then
revdep-rebuild (if you're using preserved-libs). I know there should be
support for ldconfig NO
On Fri, Jan 25, 2013 at 3:17 PM, Ian Stakenvicius wrote:
> Depends on whether or not you rebuilt the rdeps -- udev-197 provides
> libudev.so.1 while udev-171 provides libudev.so.0 , so there's
> breakage on stuffs like lvm2 and other ebuilds that link to libudev
Even so, I could downgrade and rev
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 25/01/13 04:19 AM, Dirkjan Ochtman wrote:
> On Wed, Jan 23, 2013 at 2:14 PM, Samuli Suominen
> wrote:
>>>
> Also, after installing udev-197, are there any negative
> consequences to just downgrading to -171 again?
>
Depends on whether or not y
On Fri, Jan 25, 2013 at 12:59 PM, Rich Freeman wrote:
> I could see making that the default if there is no .config file
> present and a new one is being created, and perhaps upstream would
> support that since udev is popular. However, make oldconfig is
> usually used when you have a .config file
On Fri, Jan 25, 2013 at 4:19 AM, Dirkjan Ochtman wrote:
> On Wed, Jan 23, 2013 at 2:14 PM, Samuli Suominen wrote:
>> please review this news item, seems we need one after all
>
> Here's a crazy idea: can we patch our kernel to let "make oldconfig"
> default CONFIG_DEVTMPFS to true? Or better yet,
On Wed, Jan 23, 2013 at 2:14 PM, Samuli Suominen wrote:
> please review this news item, seems we need one after all
Here's a crazy idea: can we patch our kernel to let "make oldconfig"
default CONFIG_DEVTMPFS to true? Or better yet, request that this is
changed upstream?
Also, after installing u
23 matches
Mail list logo
