[gentoo-dev] DNSSEC errors on *.bugs.gentoo.org

2013-01-24 Thread Michael Weber
Hello Robin, looks like we have an little issue using DNSSEC for bugs.gentoo.org, but not signing 339761.bugs.gentoo.org `dig does-not-exist.bugs.gentoo.org @8.8.8.8` returns A record with AD flag. `dig 339761.bugs.gentoo.org @8.8.8.8` returns A record w/o AD flag Both work with local

Re: [gentoo-dev] DNSSEC errors on *.bugs.gentoo.org

2013-01-24 Thread Michael Weber
On 01/24/2013 09:02 AM, Michael Weber wrote: Did you change anything in the last n days? Or is the cache of 141.1.1.1 and 8.8.8.8 really compromised? Me culpa. Looks like these do not support AD now (or never did) And my unbound always used the first resolver, which has AD. As antarus pointed

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

2013-01-24 Thread Michael Haubenwallner
On 01/23/13 19:29, Felix Kuperjans wrote: Samuli Suominen wrote: please review this news item, seems we need one after all /dev/root is no longer available in this udev version, so people who put this in their /etc/fstab might end up with an unbootable system. I suggest including in the

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

2013-01-24 Thread Rich Freeman
On Thu, Jan 24, 2013 at 5:02 AM, Michael Haubenwallner ha...@gentoo.org wrote: The only way I've found to keep the system bootable with both kernels (for the upgrade process until the new kernel config was good enough) was to replace /dev/cciss/c0d0p1 by /dev/root in /etc/fstab. How would

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

2013-01-24 Thread Michael Weber
On 01/24/2013 02:45 AM, »Q« wrote: On Wed, 23 Jan 2013 13:49:09 -0800 Christopher Head ch...@chead.ca wrote: On Wed, 23 Jan 2013 17:03:15 +0100 Michael Weber x...@gentoo.org wrote: udev/openrc stopped re-mounting /dev that last year. Are you sure? I have CONFIG_DEVTMPFS_MOUNT disabled,

Re: [gentoo-dev] Subslots progress in main tree

2013-01-24 Thread Ian Stakenvicius
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 23/01/13 03:42 PM, Tomáš Chvátal wrote: Hi guys, do we have some scans that report libraries converted to subslots and lists their rdeps checked if they are updated accordingly? It might be pretty usefull to actually see where the deps

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

2013-01-24 Thread Ian Stakenvicius
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 23/01/13 05:21 PM, Pacho Ramos wrote: El mié, 23-01-2013 a las 23:45 +0200, Samuli Suominen escribió: On 23/01/13 23:21, Pacho Ramos wrote: El mié, 23-01-2013 a las 15:14 +0200, Samuli Suominen escribió: please review this news item, seems

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

2013-01-24 Thread Michael Orlitzky
On 01/24/13 05:02, Michael Haubenwallner wrote: I've recently upgraded some server from kernel-2.6.28 to kernel-3.5.7 and encountered that the root-device was renamed from /dev/cciss/c0d0p1 to /dev/sda1 due to some kernel driver change (took me a while to find out). I'm not using genkernel

Re: [gentoo-dev] Subslots progress in main tree

2013-01-24 Thread Zac Medico
On 01/24/2013 07:15 AM, Ian Stakenvicius wrote: In general, I would recommend for any library maintainers, to either file bugs against the rdeps of a package or directly update the rdeps (with permission, of course) when implementing sub-slots. Of course, I believe the rdeps of a library can

Re: [gentoo-dev] Subslots progress in main tree

2013-01-24 Thread Ian Stakenvicius
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 24/01/13 11:39 AM, Zac Medico wrote: On 01/24/2013 07:15 AM, Ian Stakenvicius wrote: In general, I would recommend for any library maintainers, to either file bugs against the rdeps of a package or directly update the rdeps (with permission,

Re: [gentoo-dev] Subslots progress in main tree

2013-01-24 Thread Zac Medico
On 01/23/2013 12:42 PM, Tomáš Chvátal wrote: It might be pretty usefull to actually see where the deps needed to be updated so we can take use of this feature where possible (also its a hint for lib maintainers to update their libs and see real impact). Another useful hint, for those that have

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

2013-01-24 Thread Dustin C. Hatch
On 1/22/2013 05:56, Rich Freeman wrote: On Tue, Jan 22, 2013 at 6:11 AM, viv...@gmail.com viv...@gmail.com wrote: IMHO the number of cases where CONFIG_CHECK is reliable is so small that making it fatal will only bloat make.conf and env with a new var for most users. Tend to agree. I just

[gentoo-dev] Re: [PATCH 2/2] Use new multilib flags in autotools-multilib.

2013-01-24 Thread Mike Doty
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/23/13 15:23, Michał Górny wrote: This is mostly a proof-of-concept. If approved, I will work on moving the code into a separate eclass, possibly named 'multilib-build' ;). --- gx86/eclass/autotools-multilib.eclass | 24

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

2013-01-24 Thread Duncan
Rich Freeman posted on Tue, 22 Jan 2013 06:56:08 -0500 as excerpted: I just got an elog out of udisks complaining about USB_SUSPEND not being set, and I have no idea why I'd need that on a system that is powered 24x7. Even the kernel docs suggest that it should be disabled if users aren't

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

2013-01-24 Thread Rich Freeman
On Thu, Jan 24, 2013 at 12:49 PM, Duncan 1i5t5.dun...@cox.net wrote: That said, presumably udisks would choose not to make its check fatal, altho changing the default to fatal could complicate things for existing ebuilds until they're fixed. That was basically my whole point - it can't be

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

2013-01-24 Thread Ian Stakenvicius
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 24/01/13 01:09 PM, Rich Freeman wrote: On Thu, Jan 24, 2013 at 12:49 PM, Duncan 1i5t5.dun...@cox.net wrote: That said, presumably udisks would choose not to make its check fatal, altho changing the default to fatal could complicate things

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

2013-01-24 Thread Dustin C. Hatch
On 1/24/2013 12:18, Ian Stakenvicius wrote: On 24/01/13 01:09 PM, Rich Freeman wrote: On Thu, Jan 24, 2013 at 12:49 PM, Duncan 1i5t5.dun...@cox.net wrote: That said, presumably udisks would choose not to make its check fatal, altho changing the default to fatal could complicate things for

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

2013-01-24 Thread Rich Freeman
On Thu, Jan 24, 2013 at 1:18 PM, Ian Stakenvicius a...@gentoo.org wrote: a fatal die in pkg_pretend could be circumvented by an environment variable such as ${PN}_I_KNOW_WHAT_IM_DOING being set. Just a thought. If we're going to do this I'd definitely have the ${PN} bit as you suggested.

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

2013-01-24 Thread Michael Orlitzky
On 01/24/13 13:25, Rich Freeman wrote: On Thu, Jan 24, 2013 at 1:18 PM, Ian Stakenvicius a...@gentoo.org wrote: a fatal die in pkg_pretend could be circumvented by an environment variable such as ${PN}_I_KNOW_WHAT_IM_DOING being set. Just a thought. If we're going to do this I'd definitely

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

2013-01-24 Thread Ian Stakenvicius
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 24/01/13 01:55 PM, Michael Orlitzky wrote: On 01/24/13 13:25, Rich Freeman wrote: On Thu, Jan 24, 2013 at 1:18 PM, Ian Stakenvicius a...@gentoo.org wrote: a fatal die in pkg_pretend could be circumvented by an environment variable such as

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

2013-01-24 Thread Rich Freeman
On Thu, Jan 24, 2013 at 1:58 PM, Ian Stakenvicius a...@gentoo.org wrote: How about, you know what you're doing and are going to build a new kernel as soon as the emerge finishes (since the emerge is also bringing in a new gentoo-sources)?? Or my earlier example - USB_SUSPEND and such. If

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

2013-01-24 Thread Michael Haubenwallner
On 01/24/13 16:49, Michael Orlitzky wrote: On 01/24/13 05:02, Michael Haubenwallner wrote: I've recently upgraded some server from kernel-2.6.28 to kernel-3.5.7 and encountered that the root-device was renamed from /dev/cciss/c0d0p1 to /dev/sda1 due to some kernel driver change (took me a

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

2013-01-24 Thread Michael Orlitzky
On 01/24/13 13:58, Ian Stakenvicius wrote: How about, you know what you're doing and are going to build a new kernel as soon as the emerge finishes (since the emerge is also bringing in a new gentoo-sources)?? If you're going to upgrade both anyway, you should be upgrading the kernel

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

2013-01-24 Thread Fabio Erculiani
On Thu, Jan 24, 2013 at 1:10 AM, Robin H. Johnson robb...@gentoo.org wrote: On Wed, Jan 23, 2013 at 12:32:40PM +, Fabio Erculiani wrote: I hope this is going to be binary package manager friendly. In Sabayon for instance, kernel sources are not even installed and at the same time,

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

2013-01-24 Thread Diego Elio Pettenò
On 24/01/2013 20:19, Michael Haubenwallner wrote: Yep, this is a HP DL380 G6, and lspci says: 04:00.0 RAID bus controller: Hewlett-Packard Company Smart Array G6 controllers (rev 01) Hrm just for reference, I've got a number of G6s and they all work fine with the old cciss — although they do

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

2013-01-24 Thread viv...@gmail.com
Il 24/01/2013 20:21, Michael Orlitzky ha scritto: On 01/24/13 13:58, Ian Stakenvicius wrote: How about, you know what you're doing and are going to build a new kernel as soon as the emerge finishes (since the emerge is also bringing in a new gentoo-sources)?? If you're going to upgrade both

Re: [gentoo-dev] readme.gentoo.eclass: Add a readme.gentoo_force_print_elog function to force elog printing

2013-01-24 Thread Pacho Ramos
El mar, 22-01-2013 a las 19:42 +0100, Tomáš Chvátal escribió: Dne Út 22. ledna 2013 19:37:12, Pacho Ramos napsal(a): I agree, thanks for pointing it. Just attached patch should handle it. Still not nice enough for me :D Use the ECLASS_VARIABLE to describe it @DEFAULT_UNSET is what you

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

2013-01-24 Thread Michael Orlitzky
On 01/24/13 15:26, viv...@gmail.com wrote: If you're going to upgrade both anyway, you should be upgrading the kernel first. That way if you lose power or the system crashes, the box can reboot. which can be the exact opposite order if instead you have to _disable_ a feature in the kernel

Re: [gentoo-dev] readme.gentoo.eclass: Add a readme.gentoo_force_print_elog function to force elog printing

2013-01-24 Thread Tomáš Chvátal
Dne Čt 24. ledna 2013 21:33:45, Pacho Ramos napsal(a): El mar, 22-01-2013 a las 19:42 +0100, Tomáš Chvátal escribió: Dne Út 22. ledna 2013 19:37:12, Pacho Ramos napsal(a): I agree, thanks for pointing it. Just attached patch should handle it. Still not nice enough for me :D Use the

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

2013-01-24 Thread Michael Orlitzky
On 01/24/13 15:39, Michael Orlitzky wrote: On 01/24/13 15:26, viv...@gmail.com wrote: If you're going to upgrade both anyway, you should be upgrading the kernel first. That way if you lose power or the system crashes, the box can reboot. which can be the exact opposite order if instead you

Re: [gentoo-dev] Re: [PATCH 2/2] Use new multilib flags in autotools-multilib.

2013-01-24 Thread Michał Górny
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, 24 Jan 2013 09:25:48 -0800 Mike Doty kingt...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/23/13 15:23, Michał Górny wrote: This is mostly a proof-of-concept. If approved, I will work on moving the code

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

2013-01-24 Thread Rich Freeman
On Thu, Jan 24, 2013 at 2:21 PM, Michael Orlitzky mich...@orlitzky.com wrote: On 01/24/13 13:58, Ian Stakenvicius wrote: How about, you know what you're doing and are going to build a new kernel as soon as the emerge finishes (since the emerge is also bringing in a new gentoo-sources)??

Re: [gentoo-dev] readme.gentoo.eclass: Add a readme.gentoo_force_print_elog function to force elog printing

2013-01-24 Thread Pacho Ramos
El jue, 24-01-2013 a las 21:42 +0100, Tomáš Chvátal escribió: Dne Čt 24. ledna 2013 21:33:45, Pacho Ramos napsal(a): El mar, 22-01-2013 a las 19:42 +0100, Tomáš Chvátal escribió: Dne Út 22. ledna 2013 19:37:12, Pacho Ramos napsal(a): I agree, thanks for pointing it. Just attached patch

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

2013-01-24 Thread viv...@gmail.com
Il 24/01/2013 21:45, Michael Orlitzky ha scritto: On 01/24/13 15:39, Michael Orlitzky wrote: On 01/24/13 15:26, viv...@gmail.com wrote: If you're going to upgrade both anyway, you should be upgrading the kernel first. That way if you lose power or the system crashes, the box can reboot.

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

2013-01-24 Thread Michael Orlitzky
On 01/24/13 19:29, viv...@gmail.com wrote: actually it wasn't an issue that could made a system un-bootable but was like this: * udev-129 could live with CONFIG_SYSFS_DEPRECATED=y * udev-130 require CONFIG_SYSFS_DEPRECATED not set The example was given just to underline the fact that a

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

2013-01-24 Thread Duncan
Michael Orlitzky posted on Thu, 24 Jan 2013 13:55:46 -0500 as excerpted: On 01/24/13 13:25, Rich Freeman wrote: On Thu, Jan 24, 2013 at 1:18 PM, Ian Stakenvicius a...@gentoo.org wrote: a fatal die in pkg_pretend could be circumvented by an environment variable such as

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

2013-01-24 Thread Robin H. Johnson
On Fri, Jan 25, 2013 at 01:39:08AM +, Duncan wrote: Meanwhile, my vote is for a NON-FATAL pkg_pretend warning. That gets run at the beginning when people are still likely to be watching, so should be good enough. Beyond that, gentoo can't keep the obtuse from ignoring the warnings, so

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

2013-01-24 Thread Michael Orlitzky
On 01/24/2013 08:39 PM, Duncan wrote: Now I've chosen to set that using package.env so it applies only to glibc, but I imagine many users have it set in their make.conf, because a lot of packages use it, and they were forced to set it for one or another at some point. Using package.env

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

2013-01-24 Thread Rich Freeman
On Thu, Jan 24, 2013 at 9:22 PM, Michael Orlitzky mich...@orlitzky.com wrote: Using package.env is preferable, since it basically exists in lieu of prefixing every environment variable with $PN. But I don't particularly care about the details. I was just curious if there are real cases where

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

2013-01-24 Thread Michael Orlitzky
On 01/24/2013 10:12 PM, Rich Freeman wrote: Otherwise we're just finding creative ways to drive away users. Sure, we can call them stupid on their way out the door, but while I can't speak for anybody else, I'm mainly here because I'd like to do some good, and I wouldn't mind it if I found

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

2013-01-24 Thread Duncan
Michael Orlitzky posted on Thu, 24 Jan 2013 21:22:10 -0500 as excerpted: On 01/24/2013 08:39 PM, Duncan wrote: Meanwhile, my vote is for a NON-FATAL pkg_pretend warning. That gets run at the beginning when people are still likely to be watching, so should be good enough. Beyond that,