On Wed, Jan 23, 2013 at 2:14 PM, Samuli Suominen ssuomi...@gentoo.org 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,
On Fri, Jan 25, 2013 at 4:19 AM, Dirkjan Ochtman d...@gentoo.org wrote:
On Wed, Jan 23, 2013 at 2:14 PM, Samuli Suominen ssuomi...@gentoo.org 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
On Fri, Jan 25, 2013 at 12:59 PM, Rich Freeman ri...@gentoo.org 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
-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
ssuomi...@gentoo.org wrote:
Also, after installing udev-197, are there any negative
consequences to just downgrading to -171 again?
Depends on
On Fri, Jan 25, 2013 at 3:17 PM, Ian Stakenvicius a...@gentoo.org 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
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 NOT
functionality is now provided by =net-misc/youtube-viewer[gtk]-3.0.3
bug 453580
removal in 30 days
On Fri, Jan 25, 2013 at 1:24 PM, Nuno J. Silva nunojsi...@ist.utl.pt 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
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, 25 Jan 2013 13:47:05 -0500
Rich Freeman ri...@gentoo.org 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
On Fri, Jan 25, 2013 at 2:05 PM, Pacho Ramos pa...@gentoo.org 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
On Fri, Jan 25, 2013 at 2:19 PM, Christopher Head ch...@chead.ca 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
El vie, 25-01-2013 a las 14:22 -0500, Rich Freeman escribió:
On Fri, Jan 25, 2013 at 2:05 PM, Pacho Ramos pa...@gentoo.org 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
On 2013-01-25, Rich Freeman wrote:
On Fri, Jan 25, 2013 at 1:24 PM, Nuno J. Silva nunojsi...@ist.utl.pt 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
On Fri, Jan 25, 2013 at 2:47 PM, Nuno J. Silva nunojsi...@ist.utl.pt 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,
On 2013-01-25, Rich Freeman wrote:
On Fri, Jan 25, 2013 at 2:47 PM, Nuno J. Silva nunojsi...@ist.utl.pt 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
On Fri, Jan 25, 2013 at 3:06 PM, Nuno J. Silva nunojsi...@ist.utl.pt 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
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
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
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 for
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 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't
22 matches
Mail list logo