[gentoo-dev] DNSSEC errors on *.bugs.gentoo.org
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 unbound resolver with forwarders removed. It looks like stale, unsigned entries. 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? How do you sign these wildcards anyway? Would be interested. Michael [1] http://domainincite.com/2361-dnssec-to-kill-the-isp-wildcard -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber x...@gentoo.org
Re: [gentoo-dev] DNSSEC errors on *.bugs.gentoo.org
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 out, [1] and [2] report positive validation. Michael [1] http://dnssec-debugger.verisignlabs.com/339761.bugs.gentoo.org [2] http://dnsviz.net/d/339761.bugs.gentoo.org/dnssec/ -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber x...@gentoo.org
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
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 news item, that /dev/root must be replaced with the actual root device or LABEL=..., UUID=... and the like in /etc/fstab. 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 or any initramfs, nor do I have separate /usr. 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 this be done when there is no /dev/root any more? So yes, please include the /dev/root drop (at least) in the news item. /haubi/
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
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 this be done when there is no /dev/root any more? I would think that you could just use LABEL=, UUID=, or /dev/disk/by-uuid/foo. Those device names only work on the kernel boot line if you're using an initramfs, but I suspect that they'd work fine in fstab regardless. Situations like this of course are one of the reasons initramfs is so popular - they can be far smarter about finding the root filesystem. Disclaimer: I'm using an initramfs, so I can't vouch for what happens without one. Rich
Re: [gentoo-dev] Re: news item for udev 197-r3 upgrade (yes, I know, it's late)
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, latest stable udev (197-r3) and openrc (0.11.8), and no /dev line in my fstab, yet my /dev is still a devtmpfs with a proper set of device nodes. Me too. It looks like /etc/init.d/udev-mount mounts it if the kernel hasn't, but I'd like to know more about whatever best practice is. Mind the _re_-mount, if udev discovers /dev not being mounted, udev does. if udev discovers /dev mounted, no mount action is taken. Earlier versions remounted /dev regardless. My best practice is to have CONFIG_DEVTMPFS_MOUNT enabled: I don't use initrd (except for disk encryption) and I still find my disks during init=/bin/bash recovery. and it does not hurt, anymore. -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber x...@gentoo.org
Re: [gentoo-dev] Subslots progress in main tree
-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 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). Cheers Tom No, we don't -- and I agree, it would. I'll look into it. 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 add slot operators to their *DEPEND atoms even if the library doesn't have a sub-slot (yet); this would be useful anyways, as a new sub-slot in the lib will automatically trigger appropriate rebuilding. The only issue here is a maintainer would need to know how sensitive their package is to changes in the library it deoends on (ie whether it actually needs to use a := slot operator or not). -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlEBUBMACgkQ2ugaI38ACPDlOgD/THUYZLcO8wT3TRdv/gsEXGsK aM75M3N/Pu7aFlRd/NIA/05THq9ndnFYO7umS4nYa20E2806B4D8sMEmXoHiUOSc =35iX -END PGP SIGNATURE-
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
-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 we need one after all Why don't you drop ~ from: CONFIG_CHECK=~DEVTMPFS to ensure people really changes it in their kernel and prevent breakage? That won't work because the host you run the package isn't necessarily same as the one you are building it on The build host doesn't need DEVTMPFS And couldn't that be done at install time? I mean, you can build and package new udev but installation will die if udev is going to be installed on a system without DEVTMPFS There's too many variables, though -- firstly, /usr/src/linux/.config may not match /proc/config.gz. And even if both are checked there's nothing to say that the next boot is going to use a kernel that matches either one. Realistically, what udev needs is something at runtime to report the error and temporarily bypass the requirement, because this really is a runtime issue instead of something that can be properly controlled or contained at build/install time. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlEBVgIACgkQ2ugaI38ACPBzfQD/ZAE4UHgQJ3zB9wuVkCcPAhXS 21C+7k+mjS2YSg8BgqcA/0iv12JreFnvmybX2H8a/g8BBKm30+Xbt1+bGC+rijYN =qA5Y -END PGP SIGNATURE-
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
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 or any initramfs, nor do I have separate /usr. 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 this be done when there is no /dev/root any more? These are the Compaq SmartArray controllers (usually found in HP Proliants). They used to have their own block driver, but these days they're just grouped with the rest of the SCSI drives. The old driver: Block Devices - BLK_CPQ_CISS_DA The new one is under, SCSI device support - SCSI low-level drivers - SCSI_HPSA This driver supports HP Smart Array Controllers (circa 2009). It is a SCSI alternative to the cciss driver, which is a block driver. Anyone wishing to use HP Smart Array controllers who would prefer the devices be presented to linux as SCSI devices, rather than as generic block devices should say Y here. The HPSA driver does *not* work on older Proliants, so I can only assume that HPSA is receiving active maintenance while the old block driver is not. Nevertheless, if the block driver worked for you in an old kernel, you could simply disable HPSA on the new one. When the time comes that you need to boot two newish kernels, you can re-enable HPSA and update fstab to use the new name.
Re: [gentoo-dev] Subslots progress in main tree
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 add slot operators to their *DEPEND atoms even if the library doesn't have a sub-slot (yet); this would be useful anyways, as a new sub-slot in the lib will automatically trigger appropriate rebuilding. Yes, that's a good idea. However, it means that the introduction of the first sub-slot will trigger a rebuild of the dependent package. So, it's a good idea to introduce the first sub-slot during a version bump where something has changed that justifies a sub-slot bump. -- Thanks, Zac
Re: [gentoo-dev] Subslots progress in main tree
-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, of course) when implementing sub-slots. Of course, I believe the rdeps of a library can add slot operators to their *DEPEND atoms even if the library doesn't have a sub-slot (yet); this would be useful anyways, as a new sub-slot in the lib will automatically trigger appropriate rebuilding. Yes, that's a good idea. However, it means that the introduction of the first sub-slot will trigger a rebuild of the dependent package. So, it's a good idea to introduce the first sub-slot during a version bump where something has changed that justifies a sub-slot bump. That seems to be what dev's are doing anyways, though. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlEBaK4ACgkQ2ugaI38ACPAAfgD+Ja3RKlfv1uWn7e3/V2rnGNQQ YY2NHIgQLQxp/Dx66hcA/iPoA7tF6cME8MtqmOumIEVrDzQpE8LEARPmCeQOlqwd =HzQM -END PGP SIGNATURE-
Re: [gentoo-dev] Subslots progress in main tree
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 FEATURES=preserve-libs enabled, is the @preserved-rebuild suggestion that emerge shows before it exits when there are remaining preserved libraries. Any time that you see this message, it means that there was a missed opportunity for an automatic rebuild, due to sub-slot and/or slot-operator not being used by the involved ebuilds. -- Thanks, Zac
Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
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 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 sure if they need it. Maybe we need some way to distinguish between must-have and nice-to-have situations? Clearly failure to boot is in a different category than not-able-to-suspend. Rich I agree. During an update recently, I noticed that qemu complains if KVM_INTEL isn't set on an AMD CPU. Making this fatal would be stupid, but then nobody who runs qemu-kvm would ever get a fatal error about missing DEVTMPFS. -- ♫Dustin
[gentoo-dev] Re: [PATCH 2/2] Use new multilib flags in autotools-multilib.
-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 +---
1 file changed, 21 insertions(+), 3 deletions(-)
diff --git a/gx86/eclass/autotools-multilib.eclass
b/gx86/eclass/autotools-multilib.eclass
index 7c8697a..eef7bcc 100644
--- a/gx86/eclass/autotools-multilib.eclass
+++ b/gx86/eclass/autotools-multilib.eclass
@@ -32,7 +32,23 @@ inherit autotools-utils multilib
EXPORT_FUNCTIONS src_configure src_compile src_test src_install
-IUSE=multilib
+# Declare all of them, profiles will control their visibility.
+IUSE='abi_x86_32 abi_x86_64'
+
+# @FUNCTION: _autotools-multilib_get_enabled_abis
+# @DESCRIPTION:
+# Get the list of enabled ABIs. The returned names are suitable for use
+# with multilib.eclass.
+#
+# If multilib is not enabled or not supported, returns an empty list.
+_autotools-multilib_get_enabled_abis() {
+ debug-print-function ${FUNCNAME} ${@}
+
+ if use amd64; then
+ use abi_x86_64 echo amd64
+ use abi_x86_32 echo x86
+ fi
+}
# @FUNCTION: autotools-multilib_foreach_abi
# @USAGE: argv...
@@ -46,9 +62,11 @@ IUSE=multilib
autotools-multilib_foreach_abi() {
local initial_dir=${BUILD_DIR:-${S}}
- if use multilib; then
+ local multilib_abis=$(_autotools-multilib_get_enabled_abis)
+
+ if [[ ${multilib_abis} ]]; then
local ABI
- for ABI in $(get_all_abis); do
+ for ABI in ${multilib_abis}; do
multilib_toolchain_setup ${ABI}
BUILD_DIR=${initial_dir%%/}-${ABI} ${@}
done
Why CC devrel on this?
- --
===
Mike Doty kingtaco -at- gentoo.org
Gentoo Infrastructure Operations Manager
Gentoo/AMD64 Strategic Lead
GPG: 0094 7F06 913E 78D6 F1BB 06BA D0AD D125 A797 C7A7
===
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
iEYEARECAAYFAlEBbpwACgkQ0K3RJaeXx6cwsgCg1tVjaMe3iEJEdAaUpRQhJy6v
q0kAnjjil5zCt19Ep08O5hLVQ2BvRwTc
=HgIF
-END PGP SIGNATURE-
[gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
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 sure if they need it. FWIW, that's for runtime power management. Even a wall-powered system that's always running can shutdown unused USB devices when they're not needed, saving power at the incremental level, anyway. However, that is a rather newer feature, and may cause issues with USB wakeup on obscure or older (say USB-1.x generation) hardware, thus the kernel help recommendation for that option. 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. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
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 one-size-fits-all. Honestly, based on some of the other feedback I'm not convinced it should ever be fatal. Perhaps it should be more or less noisy. Keep in mind that a typical user may be running parallel builds and such - so a delay doesn't really make much sense there either. There should also be some way to kill any interactivity in advance - if I'm running a bootstrap script of some kind and I'm installing/updating udev before I even compile a kernel that shouldn't cause the whole process to die.
Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
-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 for existing ebuilds until they're fixed.
That was basically my whole point - it can't be one-size-fits-all.
Honestly, based on some of the other feedback I'm not convinced it
should ever be fatal. Perhaps it should be more or less noisy.
Keep in mind that a typical user may be running parallel builds
and such - so a delay doesn't really make much sense there either.
There should also be some way to kill any interactivity in advance
- if I'm running a bootstrap script of some kind and I'm
installing/updating udev before I even compile a kernel that
shouldn't cause the whole process to die.
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.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
iF4EAREIAAYFAlEBewoACgkQ2ugaI38ACPA5fQEAucffX2nqeFvlE+WTdY9xbWTY
zDiKIRofsFlsgSOscOMA/3iqGLolGVDlYR3YyLfform8udhz1deAYSyA4tabq4zH
=ky38
-END PGP SIGNATURE-
Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
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 existing ebuilds until they're fixed.
That was basically my whole point - it can't be one-size-fits-all.
Honestly, based on some of the other feedback I'm not convinced it
should ever be fatal. Perhaps it should be more or less noisy.
Keep in mind that a typical user may be running parallel builds
and such - so a delay doesn't really make much sense there either.
There should also be some way to kill any interactivity in advance
- if I'm running a bootstrap script of some kind and I'm
installing/updating udev before I even compile a kernel that
shouldn't cause the whole process to die.
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.
People keep quoting, on this list and on gentoo-user, that Gentoo is not
a hand holding distribution. Having to set I_KNOW_WHAT_IM_DOING=1 sure
seems to me like I'm telling my dad I don't need him to hold my hand to
cross the street anymore, I'm a big boy. It seems like an added step
that isn't necessary. If users are not reading the messages they're
receiving and it breaks their systems, why should that make extra work
for those of us who do pay attention?
--
♫Dustin
Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
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. Otherwise everybody will just set it in make.conf and the
feature will be pointless. Then we'll yell at users because they
disabled the feature that normally just tends to break half their
builds but this time by some miracle would have actually prevented a
problem.
Rich
Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
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 have the ${PN} bit as you
suggested. Otherwise everybody will just set it in make.conf and the
feature will be pointless. Then we'll yell at users because they
disabled the feature that normally just tends to break half their
builds but this time by some miracle would have actually prevented a
problem.
Are there really that many ways that this could cause false positives?
(Not that I'm against the $PN prefix, just curious).
I've only seen two legitimate examples: catalyst (whose developers are
more than capable of setting a variable) and a supervisor-provided
kernel for which you have no information.
Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
-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 ${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. Otherwise everybody will just set it in make.conf
and the feature will be pointless. Then we'll yell at users
because they disabled the feature that normally just tends to
break half their builds but this time by some miracle would have
actually prevented a problem.
Are there really that many ways that this could cause false
positives? (Not that I'm against the $PN prefix, just curious).
I've only seen two legitimate examples: catalyst (whose developers
are more than capable of setting a variable) and a
supervisor-provided kernel for which you have no information.
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)??
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
iF4EAREIAAYFAlEBhEsACgkQ2ugaI38ACPDYHAD/RCYlN6hcItJYn/gCcEdEgh+C
owE/NaeGNDiH+3H/+uAA/jRfeJ+HPxDLdGNxt/VARcrqYnA15o6SmAiHOIj4i8Au
=FTEj
-END PGP SIGNATURE-
Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
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 there end up being lots of config checks that are fatal then users will inevitably end up overriding them, and then they'll get burned when the check really matters. I think the better option in any case is to use a news item when things change so that users can actually plan for the upcoming changes and not find out in the middle of a build. News can be targeted at those who need to know, it shows up for users 5 years from now if still relevant not if otherwise, and it only shows up once when it matters. Rich
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
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 while to find out). I'm not using genkernel or any initramfs, nor do I have separate /usr. 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 this be done when there is no /dev/root any more? These are the Compaq SmartArray controllers (usually found in HP Proliants). They used to have their own block driver, but these days they're just grouped with the rest of the SCSI drives. 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) The old driver: Block Devices - BLK_CPQ_CISS_DA The new one is under, SCSI device support - SCSI low-level drivers - SCSI_HPSA The HPSA driver does *not* work on older Proliants, so I can only assume that HPSA is receiving active maintenance while the old block driver is not. Nevertheless, if the block driver worked for you in an old kernel, you could simply disable HPSA on the new one. Well, I'm pretty sure to have started with BLK_CPQ_CISS_DA=y in the new kernel config, but this driver doesn't seem to feel responsible for that controller any more - or what else could have make me wonder where /dev/cciss/* has gone? Finally I went along [1] to identify SCSI_HPSA as the correct driver. [1] http://www.linuxtopia.org/online_books/linux_kernel/kernel_configuration/ch08s02.html When the time comes that you need to boot two newish kernels, you can re-enable HPSA and update fstab to use the new name. So this didn't work out IIRC - but I won't retest that now. For the curious: $ cat /sys/bus/pci/devices/\:04\:00.0/vendor 0x103c $ cat /sys/bus/pci/devices/\:04\:00.0/device 0x323a /haubi/
Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
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 first. That way if you lose power or the system crashes, the box can reboot.
Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
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, /proc/config.gz may not even be available. There were some corner cases in where pkg_setup failed because this kernel config check stuff was trying to be smarter than the user. That was before we made it possible to have CONFIG_CHECK=~FOO without /proc/config.gz, for the bugs you yourself submitted, and I fixed years ago. I would expect that ALL Sabayon users would have CONFIG_CHECK_FATAL=0, because they run your kernel (if you have your kernel in a package, maybe even distribute a file that triggers it, so anybody else with their own kernel still has the default CONFIG_CHECK_FATAL=1). But we cannot assume that the environment in where packages are built is the same as the environment in where packages are installed and run. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 -- Fabio Erculiani
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
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 work better with HPSA. It's the same RAID bus controller there. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
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 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 which would make udev not bootable. Don't remember exactly what, but it happened in the past when Greg was still maintainer and an obsolete feature was making udev confused.
Re: [gentoo-dev] readme.gentoo.eclass: Add a readme.gentoo_force_print_elog function to force elog printing
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 seek, see
git-2.eclass.
Tom
What about this one?
--- readme.gentoo.eclass 2013-01-20 12:42:30.0 +0100
+++ /usr/portage/eclass/readme.gentoo.eclass 2013-01-24 21:30:09.0 +0100
@@ -36,6 +36,11 @@
EXPORT_FUNCTIONS src_install pkg_postinst
+# @ECLASS-VARIABLE: FORCE_PRINT_ELOG
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# If non-empty this variable forces elog messages to be printed.
+
# @FUNCTION: readme.gentoo_create_doc
# @DESCRIPTION:
# Create doc file with ${DOC_CONTENTS} variable (preferred) and, if not set,
@@ -68,13 +73,20 @@
# @FUNCTION: readme.gentoo_print_elog
# @DESCRIPTION:
-# Print elog messages with ${T}/README.gentoo contents.
+# Print elog messages with ${T}/README.gentoo contents. They will be
+# shown only when package is installed at first time.
# Usually called at pkg_postinst phase.
+#
+# If you want to show them always, please set FORCE_PRINT_ELOG to a non empty
+# value in your ebuild before this function is called.
+# This can be useful when, for example, DOC_CONTENTS is modified, then, you can
+# rely on specific REPLACING_VERSIONS handling in your ebuild to print messages
+# when people update from versions still providing old message.
readme.gentoo_print_elog() {
debug-print-function ${FUNCNAME} ${@}
if [[ -f ${T}/README.gentoo ]]; then
- if ! [[ ${REPLACING_VERSIONS} ]]; then
+ if ! [[ ${REPLACING_VERSIONS} ]] || [[ ${FORCE_PRINT_ELOG} ]]; then
eshopts_push
set -f
cat ${T}/README.gentoo | while read -r ELINE; do elog ${ELINE}; done
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
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 which would make udev not bootable. Don't remember exactly what, but it happened in the past when Greg was still maintainer and an obsolete feature was making udev confused. Suppose, you're on e.g. udev-1, and, * udev-2 requires CONFIG_FOO=n * udev-1 will not boot with CONFIG_FOO=y Then it doesn't make much sense to die without CONFIG_FOO=n, because it can't possibly exist. So we would warn with either a non-fatal config check or news item. Hopefully we would also execute the person responsible.
Re: [gentoo-dev] readme.gentoo.eclass: Add a readme.gentoo_force_print_elog function to force elog printing
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 ECLASS_VARIABLE to describe it @DEFAULT_UNSET is what you seek,
see
git-2.eclass.
Tom
What about this one?
- if ! [[ ${REPLACING_VERSIONS} ]] || [[ ${FORCE_PRINT_ELOG}
]]; then
+ if ! [[ -n ${REPLACING_VERSIONS} || -n ${FORCE_PRINT_ELOG}
]]; then
But thats just cosmetic
Tom
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
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 have to _disable_ a feature in the kernel which would make udev not bootable. Don't remember exactly what, but it happened in the past when Greg was still maintainer and an obsolete feature was making udev confused. Suppose, you're on e.g. udev-1, and, * udev-2 requires CONFIG_FOO=n * udev-1 will not boot with CONFIG_FOO=y Sorry, that should be an 'n' instead of a 'y'. I started out with 'y' and tried to switch to 'n' to match your example.
Re: [gentoo-dev] Re: [PATCH 2/2] Use new multilib flags in autotools-multilib.
-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 into a separate eclass, possibly named 'multilib-build' ;).
---
gx86/eclass/autotools-multilib.eclass | 24 +---
1 file changed, 21 insertions(+), 3 deletions(-)
diff --git a/gx86/eclass/autotools-multilib.eclass
b/gx86/eclass/autotools-multilib.eclass
index 7c8697a..eef7bcc 100644
--- a/gx86/eclass/autotools-multilib.eclass
+++ b/gx86/eclass/autotools-multilib.eclass
@@ -32,7 +32,23 @@ inherit autotools-utils multilib
EXPORT_FUNCTIONS src_configure src_compile src_test src_install
-IUSE=multilib
+# Declare all of them, profiles will control their visibility.
+IUSE='abi_x86_32 abi_x86_64'
+
+# @FUNCTION: _autotools-multilib_get_enabled_abis
+# @DESCRIPTION:
+# Get the list of enabled ABIs. The returned names are suitable for use
+# with multilib.eclass.
+#
+# If multilib is not enabled or not supported, returns an empty list.
+_autotools-multilib_get_enabled_abis() {
+ debug-print-function ${FUNCNAME} ${@}
+
+ if use amd64; then
+ use abi_x86_64 echo amd64
+ use abi_x86_32 echo x86
+ fi
+}
# @FUNCTION: autotools-multilib_foreach_abi
# @USAGE: argv...
@@ -46,9 +62,11 @@ IUSE=multilib
autotools-multilib_foreach_abi() {
local initial_dir=${BUILD_DIR:-${S}}
- if use multilib; then
+ local multilib_abis=$(_autotools-multilib_get_enabled_abis)
+
+ if [[ ${multilib_abis} ]]; then
local ABI
- for ABI in $(get_all_abis); do
+ for ABI in ${multilib_abis}; do
multilib_toolchain_setup ${ABI}
BUILD_DIR=${initial_dir%%/}-${ABI} ${@}
done
Why CC devrel on this?
Oops, sorry. I meant to CC releng...
- --
Best regards,
Michał Górny
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
iJwEAQEIAAYFAlEBpHoACgkQfXuS5UK5QB2znQP/YTR6zos9ATcaXSjoo1+bhiVl
tSpvNXGDRmYEIVGWdW7831oTd1/5bazGaoALnC5Y8iURblI8MUENv7xx4u9RQnQb
okIKHLXWFsirMrx3XAs0nTbRotZxFZY00N93mhYHYGjg4l0bnsIVCQC6dBpHLKRX
wMUEF2WjATT0ACxgyos=
=qTSP
-END PGP SIGNATURE-
Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
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)?? 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. The problem is that we're trying to solve a very specific issue (a udev upgrade, which already happened) with a general solution. Whatever we come up with has to be override-able in a way that doesn't then just come back to haunt them. As far as what order you upgrade what in - in the case where I'd be most likely to run into this the system wouldn't be bootable before I upgrade, or after I upgrade. I'd tend to run into this issue when building a new system from a stage3 - just dump a bunch of stuff in @world (including a kernel) and then run an emerge -uDN world followed by building a kernel. Yes, this isn't a typical case, and neither are the 10 billion other cases where config checks break. However, typical users don't run Gentoo to begin with. Everybody has some odd case or another - so we warn people of potential breakage before we break things and let them use the brains they needed to get Gentoo working in the first place. Rich
Re: [gentoo-dev] readme.gentoo.eclass: Add a readme.gentoo_force_print_elog function to force elog printing
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 should handle it.
Still not nice enough for me :D
Use the ECLASS_VARIABLE to describe it @DEFAULT_UNSET is what you seek,
see
git-2.eclass.
Tom
What about this one?
- if ! [[ ${REPLACING_VERSIONS} ]] || [[ ${FORCE_PRINT_ELOG}
]]; then
+ if ! [[ -n ${REPLACING_VERSIONS} || -n ${FORCE_PRINT_ELOG}
]]; then
But thats just cosmetic
Tom
Done, and committed
+ 24 Jan 2013; Pacho Ramos pa...@gentoo.org readme.gentoo.eclass:
+ Include FORCE_PRINT_ELOG variable to for printing of messages when
desired.
+ Thanks to Tomáš Chvátal for his suggestions.
+
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
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. which can be the exact opposite order if instead you have to _disable_ a feature in the kernel which would make udev not bootable. Don't remember exactly what, but it happened in the past when Greg was still maintainer and an obsolete feature was making udev confused. Suppose, you're on e.g. udev-1, and, * udev-2 requires CONFIG_FOO=n * udev-1 will not boot with CONFIG_FOO=y Sorry, that should be an 'n' instead of a 'y'. I started out with 'y' and tried to switch to 'n' to match your example. 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 different emerge order may be required. cheers
Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
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 different emerge order may be required. So you upgrade the kernel (unsetting CONFIG_SYSFS_DEPRECATED), and then upgrade udev (which would now pass the config check). Same situation?
[gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
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 ${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. Otherwise everybody will just set it in make.conf and the
feature will be pointless. Then we'll yell at users because they
disabled the feature that normally just tends to break half their
builds but this time by some miracle would have actually prevented a
problem.
Are there really that many ways that this could cause false positives?
(Not that I'm against the $PN prefix, just curious).
It's worth noting that for example, glibc uses I_KNOW_WHAT_I_AM_DOING to
bypass its don't-break-the-system-by-downgrading-glibc check.
Unfortunately, due to environment saving and because I have
FEATURES=buildpkg set, that means I have to set it at build-time, in
ordered to have it in the glibc binpkg for the PREVIOUS version (the one
I'd be downgrading to), in ordered to avoid a needless rebuild despite my
having the binpkg I was JUST using until the upgrade and thus KNOW to be
working, right at hand!
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.
Thus, adding the package name to enforce per-package
I_KNOW_WHAT_I_AM_DOING seems a good idea.
Or perhaps use the usual I_KNOW_WHAT_I_AM_DOING var, but instead of just
checking that it's set, check that it's set to the specific package name.
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 if it breaks they get to keep the pieces, and RESOLVED/
READTHEWARNINGS to any resulting bugs.
--
Duncan - List replies preferred. No HTML msgs.
Every nonfree program has a lord, a master --
and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
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 if it breaks they get to keep the pieces, and RESOLVED/ READTHEWARNINGS to any resulting bugs. Ok, I'll see about implementing pkg_pretend in linux-info.eclass as well. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
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 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 the config check would do harm. If there's no downside (i.e. no one will notice, except the people whose machines would be broken), then the whole debate is stupid. Thus, adding the package name to enforce per-package I_KNOW_WHAT_I_AM_DOING seems a good idea. Or perhaps use the usual I_KNOW_WHAT_I_AM_DOING var, but instead of just checking that it's set, check that it's set to the specific package name. 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 if it breaks they get to keep the pieces, and RESOLVED/ READTHEWARNINGS to any resulting bugs. They're not warnings, they're we just broke your system, hope you weren't doing anything tonight! A boulder with WARNING: FALLING ROCKS spray-painted on the bottom. Better to spare the innocents, and for the people who set I_KNOW_WHAT_I_AM_DOING=y in make.conf, we can create RESOLVED:I_THOUGHT_YOU_KNEW.
Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
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 the config check would do harm. A few have come up. They mostly involve with building on systems where the package won't be deployed, in things like chroots, during things like upgrading stage3s before installing the kernel, and so on. The USB_SUSPEND case came up as well - things like that shouldn't be fatal. Does package.env support having more than one environment file per package? If somebody is already using package.env to tweak CFLAGs and such then also using it for this flag means basically doubling the number of configurations (ie having a debug-flags and debug-flags-ikwiad file, and ditto for any other tweaks). If there's no downside (i.e. no one will notice, except the people whose machines would be broken), then the whole debate is stupid. I don't think that we'd have a debate if there wasn't a sense that people would notice. The whole your use case isn't the same as mine thus it doesn't matter thing gets old. I don't expect devs to do a lot of work to maintain corner cases, but in this case the desire is to not make users patch ebuilds if they don't want to have them die when nothing is wrong, and accomplishing this doesn't really cost anybody time. Better to spare the innocents, and for the people who set I_KNOW_WHAT_I_AM_DOING=y in make.conf, we can create RESOLVED:I_THOUGHT_YOU_KNEW. Remember, it isn't the skipped check that broke the system - it was the package change that required the check in the first place. If the package just silently fails (even due to an override) then that is a bad design. It should at least give as many warnings as it does presently (but non-fatally), and it should still be preceded with a news item. 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 useful along the way. I think what we need is a combination of: 1. Only truly critical issues trigger fatal errors. This can't be used for default config checks. 2. The fatal errors are overridable. 3. If overriden the errors are still output. 4. The error output includes instructions on how to override, and the instructions are package-specific (ie don't stick i_know_what_im_doing in make.conf). 5. The change introducing the issue is preceded with a news item. Honestly I think #5 is more important than having the check in the first place. Also, most of these can be handled at the eclass level - the package should explain the issue, but all the instructions/behavior can be generic (that is, generic instructions on how to do the override in a package-specific way, such as through package.env or whatever). Rich
Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
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 useful along the way. I think what we need is a combination of: 1. Only truly critical issues trigger fatal errors. This can't be used for default config checks. 2. The fatal errors are overridable. 3. If overriden the errors are still output. 4. The error output includes instructions on how to override, and the instructions are package-specific (ie don't stick i_know_what_im_doing in make.conf). 5. The change introducing the issue is preceded with a news item. I completely agree with this, so I won't drag the issue out any further.
[gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
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, gentoo can't keep the obtuse from ignoring the warnings, so if it breaks they get to keep the pieces, and RESOLVED/ READTHEWARNINGS to any resulting bugs. They're not warnings, they're we just broke your system, hope you weren't doing anything tonight! A boulder with WARNING: FALLING ROCKS spray-painted on the bottom. But a pkg_pretend warning would happen BEFORE the breakage, normally at --pretend/--ask time, when people are still paying attention. So it wouldn't be a boulder with the warning posted on the bottom, it would be a sign (which retaining the analogy, could be painted on the SIDE of a boulder) posted a kilometre ahead. That's the purpose for which pkg_pretend was created, and AFAIK, the purpose for which it is used, tho there's a limitation on the EAPI it can be used with, since it didn't appear in early EAPIs. Better to spare the innocents, and for the people who set I_KNOW_WHAT_I_AM_DOING=y in make.conf, we can create RESOLVED:I_THOUGHT_YOU_KNEW. The thing is, if we use it so much that most folks have that variable set, then we've defeated the purpose and just executed an exercise in futility. That said, as should be plain from previous posts, I'm certainly of the opinion that once we have the warning, it's no longer our responsibility, and people who ignore it get to keep the pieces. In fact, I'm on record as being of the opinon that if such a case were to happen reasonably early in their gentoo experience (as it did back in the day when baselayout shipped /etc/fstab and some people ended up learning the hard way to actually pay attention to etc-updates as a result), ultimately, we'd have fewer bugs of this sort, because people would quickly learn that they had /better/ pay attention... or find another distro if they weren't willing to do so! So yes, RESOLVED/READTHEWARNINGS or the like could be a viable bug status, indeed. =:^) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
