Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)

2013-01-25 Thread Dirkjan Ochtman
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,

Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)

2013-01-25 Thread Rich Freeman
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

Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)

2013-01-25 Thread Dirkjan Ochtman
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

Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)

2013-01-25 Thread Ian Stakenvicius
-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

Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)

2013-01-25 Thread Dirkjan Ochtman
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

Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)

2013-01-25 Thread Diego Elio Pettenò
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

[gentoo-dev] Lastrite: net-misc/gtk-youtube-viewer

2013-01-25 Thread hasufell
functionality is now provided by =net-misc/youtube-viewer[gtk]-3.0.3 bug 453580 removal in 30 days

Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

2013-01-25 Thread Rich Freeman
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

[gentoo-dev] Confusing tmpfs information in udev news item

2013-01-25 Thread Pacho Ramos
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

Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

2013-01-25 Thread Christopher Head
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

Re: [gentoo-dev] Confusing tmpfs information in udev news item

2013-01-25 Thread Rich Freeman
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

Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

2013-01-25 Thread Rich Freeman
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

Re: [gentoo-dev] Confusing tmpfs information in udev news item

2013-01-25 Thread Pacho Ramos
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

[gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

2013-01-25 Thread Nuno J. Silva
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

Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

2013-01-25 Thread Rich Freeman
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,

[gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

2013-01-25 Thread Nuno J. Silva
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

Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

2013-01-25 Thread Rich Freeman
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

[gentoo-dev] fcaps.eclass: bringing filesystem capabilities to the tree

2013-01-25 Thread Mike Frysinger
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

Re: [gentoo-dev] fcaps.eclass: bringing filesystem capabilities to the tree

2013-01-25 Thread Gilles Dartiguelongue
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

Re: [gentoo-dev] fcaps.eclass: bringing filesystem capabilities to the tree

2013-01-25 Thread Diego Elio Pettenò
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

[gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

2013-01-25 Thread Duncan
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

Re: [gentoo-dev] fcaps.eclass: bringing filesystem capabilities to the tree

2013-01-25 Thread Mike Frysinger
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