Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib
On Mon, 21 Jan 2013 10:27:30 -0300 Alexis Ballier aball...@gentoo.org wrote: To be honest, I don't know if there's other way to hide USE flags than using USE_EXPAND_HIDDEN. If we want to use that, we'd have to split the flags per-arch, i.e. have: MULTILIB_AMD64=abi1 abi2 abi3 MULTILIB_PPC64=abi1 abi2 abi3 with appropriate USE_EXPAND_HIDDEN set by profiles. I don't like that at all. I'd go for ABI= the union of all the MULTILIB_ABIS variables (if there is no name collision) we certainly want skype to depend on libitneeds[abi_x86], not 'amd64? ( libitneeds[abi_amd64_x86] ) x86? ( libitneeds )' Just a quick idea. How would you feel about abi_x86_32? (similarly _64, _x32) That would be almost natural names with the trick variable being ABI_X86, therefore having all the fore-mentioned advantages. The deps would look like: libitneeds[abi_x86_32] -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] stabilization candidates rss feed html pages
If the euscan guys want to integrate the feature, nice. If not, lets just stick with this script. It is simple enough that even ruby n00bs like me can understand what it does :P I'm a ruby noob and seems pretty simple, I don't think that porting it to python would be a huge effort. Moreover we can base it on existing euscan code. I'll talk with Corentin about that ;) Thanks! -- f. There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] stabilization candidates rss feed html pages
On Wed, Jan 23, 2013 at 1:57 AM, Brian Dolbec dol...@gentoo.org wrote: Second reason, I believe it is getting or already has deployment on gentoo infra servers. euscan is not getting implemented on infra server because noone requested it. Again, whoever is responsible for any service and wants it implemented in our servers needs to file a bug assigned to infra Theo
Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib
On Wed, 23 Jan 2013 09:24:26 +0100 Michał Górny mgo...@gentoo.org wrote: On Mon, 21 Jan 2013 10:27:30 -0300 Alexis Ballier aball...@gentoo.org wrote: To be honest, I don't know if there's other way to hide USE flags than using USE_EXPAND_HIDDEN. If we want to use that, we'd have to split the flags per-arch, i.e. have: MULTILIB_AMD64=abi1 abi2 abi3 MULTILIB_PPC64=abi1 abi2 abi3 with appropriate USE_EXPAND_HIDDEN set by profiles. I don't like that at all. I'd go for ABI= the union of all the MULTILIB_ABIS variables (if there is no name collision) we certainly want skype to depend on libitneeds[abi_x86], not 'amd64? ( libitneeds[abi_amd64_x86] ) x86? ( libitneeds )' Just a quick idea. How would you feel about abi_x86_32? (similarly _64, _x32) That would be almost natural names with the trick variable being ABI_X86, therefore having all the fore-mentioned advantages. The deps would look like: libitneeds[abi_x86_32] Sounds good too, I just would want it to be shared between arches that can: amd64/x86/x32, ppc/ppc64, mips, sparc32/sparc64, etc. You mean you will hide ABI_X86 USE_EXPAND on non-x86 arches, right ? This would have all the benefits I think, very good idea :) Alexis.
Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
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. -- Fabio Erculiani
Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
On Wed, Jan 23, 2013 at 7:32 AM, Fabio Erculiani lx...@gentoo.org 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. Another issue with this sort of thing is that the kernel in /usr/src/linux might not be the kernel that is running, and the kernel that is running might not be the kernel that is running upon the next boot. I think warnings just make sense, but if we're going to make them fatal then at least print out instructions on how to disable them. I suspect that a large number of users will end up disabling config checks though, in which case this feature will provide a false sense of security. If an upgrade could make a user's system unbootable then we should really be warning them about it BEFORE they merge the package. A news item before the change is committed to portage would be more appropriate. I don't want a fatal error during pkg_setup that isn't fatal for 90% of our users because of all the false alarms to be an excuse for developers to put the blame on the user. That amounts to telling our users that if they don't enable some make.conf option then half of the Gentoo devs will cause their builds to break randomly, and if they do enable it the other half of the Gentoo devs will cause their systems to not boot. Rich
[gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
please review this news item, seems we need one after all Title: Upgrading udev from 171 (or older) to 197 Author: Samuli Suominen ssuomi...@gentoo.org Content-Type: text/plain Posted: 2013-01-23 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: sys-fs/udev- Upgrading udev from 171 (or older) to 197 will require special attention: - Remove udev-postmount from runlevels. - 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) - The case of predictable network interface names; if the file /etc/udev/rules.d/70-persistent-net.rules is being used for renaming network interface names to already existing names, then you need to read following bug[1] because it's no longer possible. This won't be a problem with the new predictable network interface name scheme[2]. [1] http://bugs.gentoo.org/453494 [2] http://www.freedesktop.org/wiki/Software/systemd/ PredictableNetworkInterfaceNames - Support for older kernels than 2.6.39 is dropped. If you need older kernel we recommend you to look into sys-fs/eudev or use local overlay for keeping the old ebuild. Remember to also get the distfiles where the patchsets are. The upgrade into current stable version of gentoo-sources is recommended. - The case of separate /usr; if it worked for you with 171 it will continue to work for you with 197. We still recommend initramfs with separate /usr mounting capabilities because you might need packages like sys-apps/kbd (keymaps in /usr) or net-wireless/bluez (possible keyboard) in early boot. And read every message printed by the emerge of udev and udev-init-scripts to ensure the system is in order before booting as this news item might not be complete. Apologies if this news came too late for you.
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
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 +1, this would have been useful.
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
On 23 January 2013 13:32, 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 +1, this would have been useful. Looks ok but as the news item says, it's a bit too late ... -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
On 23/01/13 15:34, Markos Chandras wrote: On 23 January 2013 13:32, 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 +1, this would have been useful. Looks ok but as the news item says, it's a bit too late ... not for everyone, not everyone upgrades this often, and it's usually the servers that get updated last
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
On Wed, Jan 23, 2013 at 8:41 AM, Samuli Suominen ssuomi...@gentoo.org wrote: not for everyone, not everyone upgrades this often, and it's usually the servers that get updated last Agreed, but best to get this out ASAP. Only question - display-if-installed is set to . Would it make sense to make it 198 instead? Does a new install 5 years from now really need to see this? If sent out in advance I'd make it 197, but if we want to catch anybody who hasn't rebooted yet or who might have missed a detail 198 would handle that. Rich
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
130123 Samuli Suominen wrote: please review this news item, seems we need one after all ... - 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) ... I have 2 such lines : tmpfs /tmptmpfs defaults,noatime,mode=1777 0 0 none /dev/shmtmpfs defaults 0 0 Are either or both involved ? -- if so, what to do ? -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
On 23/01/2013 15:02, Philip Webb wrote: - 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) ... I have 2 such lines : tmpfs /tmptmpfs defaults,noatime,mode=1777 0 0 none/dev/shmtmpfs defaults 0 0 Are either or both involved ? -- if so, what to do ? None are involved. The second column would read /dev if it was involved. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
On 23/01/13 15:44, Rich Freeman wrote: On Wed, Jan 23, 2013 at 8:41 AM, Samuli Suominen ssuomi...@gentoo.org wrote: not for everyone, not everyone upgrades this often, and it's usually the servers that get updated last Agreed, but best to get this out ASAP. Only question - display-if-installed is set to . Would it make sense to make it 198 instead? Does a new install 5 years from now really need to see this? If sent out in advance I'd make it 197, but if we want to catch anybody who hasn't rebooted yet or who might have missed a detail 198 would handle that. Rich Right, I've used 198 and pushed the item now I welcome anyone to edit it if it needs editing, just do it
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
On Wed, Jan 23, 2013 at 9:05 AM, Diego Elio Pettenò flamee...@flameeyes.eu wrote: None are involved. The second column would read /dev if it was involved. The news item doesn't mention what to do if there is no line to mount /dev. I don't see one in my fstab, and I simply followed the handbook (as it was written ~2001), and all announced migration documents since. I can't imagine I'm the only one... System seems to work fine, so I'm not sure how essential that line is. The fact that I'm using an initramfs might also have an effect. Rich
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
On 23/01/2013 16:04, Rich Freeman wrote: System seems to work fine, so I'm not sure how essential that line is. The fact that I'm using an initramfs might also have an effect. AFAICT if you do NOT have a /dev entry you're the best off because the init script will mount it for you. I think the same is true of /sys and /proc. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib
On Wed, 23 Jan 2013 08:03:56 -0300 Alexis Ballier aball...@gentoo.org wrote: On Wed, 23 Jan 2013 09:24:26 +0100 Michał Górny mgo...@gentoo.org wrote: On Mon, 21 Jan 2013 10:27:30 -0300 Alexis Ballier aball...@gentoo.org wrote: To be honest, I don't know if there's other way to hide USE flags than using USE_EXPAND_HIDDEN. If we want to use that, we'd have to split the flags per-arch, i.e. have: MULTILIB_AMD64=abi1 abi2 abi3 MULTILIB_PPC64=abi1 abi2 abi3 with appropriate USE_EXPAND_HIDDEN set by profiles. I don't like that at all. I'd go for ABI= the union of all the MULTILIB_ABIS variables (if there is no name collision) we certainly want skype to depend on libitneeds[abi_x86], not 'amd64? ( libitneeds[abi_amd64_x86] ) x86? ( libitneeds )' Just a quick idea. How would you feel about abi_x86_32? (similarly _64, _x32) That would be almost natural names with the trick variable being ABI_X86, therefore having all the fore-mentioned advantages. The deps would look like: libitneeds[abi_x86_32] Sounds good too, I just would want it to be shared between arches that can: amd64/x86/x32, ppc/ppc64, mips, sparc32/sparc64, etc. You mean you will hide ABI_X86 USE_EXPAND on non-x86 arches, right ? This would have all the benefits I think, very good idea :) Yes. I'm currently looking for a clean way to hide it without having to repeat that in a dozen profiles. But it seems that portage and PMS disagree again about the shape of USE_EXPAND_HIDDEN... -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib
On Wed, 23 Jan 2013 16:27:17 +0100 Michał Górny mgo...@gentoo.org wrote: On Wed, 23 Jan 2013 08:03:56 -0300 Alexis Ballier aball...@gentoo.org wrote: On Wed, 23 Jan 2013 09:24:26 +0100 Michał Górny mgo...@gentoo.org wrote: On Mon, 21 Jan 2013 10:27:30 -0300 Alexis Ballier aball...@gentoo.org wrote: To be honest, I don't know if there's other way to hide USE flags than using USE_EXPAND_HIDDEN. If we want to use that, we'd have to split the flags per-arch, i.e. have: MULTILIB_AMD64=abi1 abi2 abi3 MULTILIB_PPC64=abi1 abi2 abi3 with appropriate USE_EXPAND_HIDDEN set by profiles. I don't like that at all. I'd go for ABI= the union of all the MULTILIB_ABIS variables (if there is no name collision) we certainly want skype to depend on libitneeds[abi_x86], not 'amd64? ( libitneeds[abi_amd64_x86] ) x86? ( libitneeds )' Just a quick idea. How would you feel about abi_x86_32? (similarly _64, _x32) That would be almost natural names with the trick variable being ABI_X86, therefore having all the fore-mentioned advantages. The deps would look like: libitneeds[abi_x86_32] Sounds good too, I just would want it to be shared between arches that can: amd64/x86/x32, ppc/ppc64, mips, sparc32/sparc64, etc. You mean you will hide ABI_X86 USE_EXPAND on non-x86 arches, right ? This would have all the benefits I think, very good idea :) Yes. I'm currently looking for a clean way to hide it without having to repeat that in a dozen profiles. But it seems that portage and PMS disagree again about the shape of USE_EXPAND_HIDDEN... Sorry, my bad. Read the wrong section of the well-organized PMS. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
Hi, On 01/23/2013 04:04 PM, Rich Freeman wrote: System seems to work fine, so I'm not sure how essential that line is. The fact that I'm using an initramfs might also have an effect. I'd strongly suggest using CONFIG_DEVTMPFS_MOUNT=y. and stop worring about udev/openrc. udev/openrc stopped re-mounting /dev that last year. Michael -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber x...@gentoo.org
Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib
В письме от 23 января 2013 08:03:56 пользователь Alexis Ballier написал: On Wed, 23 Jan 2013 09:24:26 +0100 Michał Górny mgo...@gentoo.org wrote: On Mon, 21 Jan 2013 10:27:30 -0300 Alexis Ballier aball...@gentoo.org wrote: To be honest, I don't know if there's other way to hide USE flags than using USE_EXPAND_HIDDEN. If we want to use that, we'd have to split the flags per-arch, i.e. have: MULTILIB_AMD64=abi1 abi2 abi3 MULTILIB_PPC64=abi1 abi2 abi3 with appropriate USE_EXPAND_HIDDEN set by profiles. I don't like that at all. I'd go for ABI= the union of all the MULTILIB_ABIS variables (if there is no name collision) we certainly want skype to depend on libitneeds[abi_x86], not 'amd64? ( libitneeds[abi_amd64_x86] ) x86? ( libitneeds )' Just a quick idea. How would you feel about abi_x86_32? (similarly _64, _x32) That would be almost natural names with the trick variable being ABI_X86, therefore having all the fore-mentioned advantages. The deps would look like: libitneeds[abi_x86_32] Sounds good too, I just would want it to be shared between arches that can: amd64/x86/x32, ppc/ppc64, mips, sparc32/sparc64, etc. You mean you will hide ABI_X86 USE_EXPAND on non-x86 arches, right ? This would have all the benefits I think, very good idea :) Alexis. Shared abi names are bad idea. For example mips abis : o32 n32 n64 eabi x86: x86_32 x86_x32 x86_64 Actualy first three one are equivalent in their internal behavior. But i dont think that its good idea to have one name for all. Think about multiarch installs where you can have binaries from different architectures in one system. -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, Gatchina, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
Samuli Suominen wrote: please review this news item, seems we need one after all Hello Samuli, /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. Regards, Felix
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
On Wed, Jan 23, 2013 at 1:29 PM, Felix Kuperjans fe...@desaster-games.com wrote: Samuli Suominen wrote: please review this news item, seems we need one after all Hello Samuli, /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. fstab is not consulted for mounting the root filesystem, so it doesn't really matter what you have in there. Either the kernel mounts it based on the kernel command line, or your initramfs mounts it based on whatever your /init programs does.
Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib
On Wed, 23 Jan 2013 21:36:22 +0400 Alexey Shvetsov ale...@gentoo.org wrote: В письме от 23 января 2013 08:03:56 пользователь Alexis Ballier написал: On Wed, 23 Jan 2013 09:24:26 +0100 Michał Górny mgo...@gentoo.org wrote: On Mon, 21 Jan 2013 10:27:30 -0300 Alexis Ballier aball...@gentoo.org wrote: To be honest, I don't know if there's other way to hide USE flags than using USE_EXPAND_HIDDEN. If we want to use that, we'd have to split the flags per-arch, i.e. have: MULTILIB_AMD64=abi1 abi2 abi3 MULTILIB_PPC64=abi1 abi2 abi3 with appropriate USE_EXPAND_HIDDEN set by profiles. I don't like that at all. I'd go for ABI= the union of all the MULTILIB_ABIS variables (if there is no name collision) we certainly want skype to depend on libitneeds[abi_x86], not 'amd64? ( libitneeds[abi_amd64_x86] ) x86? ( libitneeds )' Just a quick idea. How would you feel about abi_x86_32? (similarly _64, _x32) That would be almost natural names with the trick variable being ABI_X86, therefore having all the fore-mentioned advantages. The deps would look like: libitneeds[abi_x86_32] Sounds good too, I just would want it to be shared between arches that can: amd64/x86/x32, ppc/ppc64, mips, sparc32/sparc64, etc. You mean you will hide ABI_X86 USE_EXPAND on non-x86 arches, right ? This would have all the benefits I think, very good idea :) Alexis. Shared abi names are bad idea. For example mips abis : o32 n32 n64 eabi x86: x86_32 x86_x32 x86_64 Actualy first three one are equivalent in their internal behavior. But i dont think that its good idea to have one name for all. Sorry, I don't get it. What was meant here was one USE_EXPAND variable per group of similar arches. Different abis are, of course, distinguished within each variable. Think about multiarch installs where you can have binaries from different architectures in one system. It depends what we want through multilib. I personally think multiarch is out of scope: there is crossdev for that. Alexis.
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
On Wed, Jan 23, 2013 at 1:42 PM, Mike Gilbert flop...@gentoo.org wrote: fstab is not consulted for mounting the root filesystem, so it doesn't really matter what you have in there. Either the kernel mounts it based on the kernel command line, or your initramfs mounts it based on whatever your /init programs does. Keep in mind that for some implementations whatever your /init programs does includes checking fstab. When I switched to dracut I discovered this when the system would not boot - my fstab had the wrong filesystem type for the root (it dated back to the ext2 days)... Rich
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
On Wed, Jan 23, 2013 at 1:52 PM, Rich Freeman ri...@gentoo.org wrote: On Wed, Jan 23, 2013 at 1:42 PM, Mike Gilbert flop...@gentoo.org wrote: fstab is not consulted for mounting the root filesystem, so it doesn't really matter what you have in there. Either the kernel mounts it based on the kernel command line, or your initramfs mounts it based on whatever your /init programs does. Keep in mind that for some implementations whatever your /init programs does includes checking fstab. When I switched to dracut I discovered this when the system would not boot - my fstab had the wrong filesystem type for the root (it dated back to the ext2 days)... Ah, good to know. I'm used to dealing with my little homegrown initramfs, where I parse root from the kernel command line in /init. genkernel does the same thing.
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
Mike Gilbert: On Wed, Jan 23, 2013 at 1:29 PM, Felix Kuperjans fe...@desaster-games.com wrote: Samuli Suominen wrote: please review this news item, seems we need one after all Hello Samuli, /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. fstab is not consulted for mounting the root filesystem, so it doesn't really matter what you have in there. Either the kernel mounts it based on the kernel command line, or your initramfs mounts it based on whatever your /init programs does. Well, *if* a line with /dev/root is present in /etc/fstab, the system does not boot up properly (tested it right now). I always though such a line in /etc/fstab is needed so that fsck is run on the root filesystem... Removing the line completely boots up fine, but the filesystem has not been fscked on boot. Regards, Felix
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
On Wed, Jan 23, 2013 at 1:56 PM, Mike Gilbert flop...@gentoo.org wrote: Ah, good to know. I'm used to dealing with my little homegrown initramfs, where I parse root from the kernel command line in /init. genkernel does the same thing. Yeah, dracut generally does the right thing but that generally assumes that things like fstab are correct. It still uses the root= option (I'm not sure if it can work without it - I believe it does snapshot the fstab at time of creation). My understanding is that dracut actually remounts root a few times as it moves along, starting with the kernel command line, then after setting up mounts in fstab.sys (which is how you handle a separate /usr), and finally based on the contents of fstab (which it can't read until it actually has root mounted). When it is done the root filesystem is mounted using all options in /etc/fstab, which is probably a good thing. That said, it hasn't been without bugs. I think they're mostly fixed at this point, but I haven't tried removing all of my workarounds (mainly around the fact that it wasn't auto-assembling my raid unless I hardcoded an mdadm -As in a script). The best thing about dracut though is that it is pretty powerful, with modules/hooks/etc. When it wasn't quite working right for me I just added my own module to it. It also has the side-benefit of working well even when mdadm decides to renumber all my md minor device numbers (tends to happen when booting for CD or whatever - probably because I'm using older metadata for some of the arrays). Rich
[gentoo-dev] Subslots progress in main tree
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
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
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? signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
I think that the problem is that it is trying to be smart when it's not really possible (unless you want to cover all the corner cases, which is a pain). -- Fabio Erculiani
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
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
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
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. Chris On Wed, 23 Jan 2013 17:03:15 +0100 Michael Weber x...@gentoo.org wrote: Hi, On 01/23/2013 04:04 PM, Rich Freeman wrote: System seems to work fine, so I'm not sure how essential that line is. The fact that I'm using an initramfs might also have an effect. I'd strongly suggest using CONFIG_DEVTMPFS_MOUNT=y. and stop worring about udev/openrc. udev/openrc stopped re-mounting /dev that last year. Michael
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
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 signature.asc Description: This is a digitally signed message part
[gentoo-dev] [PATCH] gst-plugins10.eclass support for multiple plugin build directory
Hi all,
this patch adds support for building plugins in different directory.
This has been a long TODO item but there is now a need for it since the
amrnb and amrwb codecs both depend on the same lib and I see no reason
to not have them under the same ebuild.
I am attaching the sample ebuild with it.
AMR* ebuild request is here:
https://bugs.gentoo.org/show_bug.cgi?id=306855
--
Gilles Dartiguelongue e...@gentoo.org
Gentoo
[1;32mIndex: gst-plugins10.eclass[0;0m
[1;32m===[0;0m
[1;32mRCS file: /var/cvsroot/gentoo-x86/eclass/gst-plugins10.eclass,v[0;0m
[1;32mretrieving revision 1.9[0;0m
[1;32mdiff -u -B -r1.9 gst-plugins10.eclass[0;0m
[1;31m--- gst-plugins10.eclass 16 Jan 2013 22:52:37 - 1.9[0;0m
[1;34m+++ gst-plugins10.eclass 23 Jan 2013 22:56:06 -[0;0m
[1;35m@@ -58,13 +58,13 @@[0;0m
[0;0m # Defines the plugins to be built.[0;0m
[0;0m # May be set by an ebuild and contain more than one indentifier, space[0;0m
[0;0m # seperated (only src_configure can handle mutiple plugins at this time).[0;0m
[1;31m-GST_PLUGINS_BUILD=${PN/gst-plugins-/}[0;0m
[1;34m+: ${GST_PLUGINS_BUILD:=${PN/gst-plugins-/}}[0;0m
[0;0m [0;0m
[0;0m # @ECLASS-VARIABLE: GST_PLUGINS_BUILD_DIR[0;0m
[0;0m # @DESCRIPTION:[0;0m
[0;0m # Actual build directory of the plugin.[0;0m
[0;0m # Most often the same as the configure switch name.[0;0m
[1;31m-GST_PLUGINS_BUILD_DIR=${PN/gst-plugins-/}[0;0m
[1;34m+: ${GST_PLUGINS_BUILD_DIR:=${PN/gst-plugins-/}}[0;0m
[0;0m [0;0m
[0;0m # @ECLASS-VARIABLE: GST_TARBALL_SUFFIX[0;0m
[0;0m # @DESCRIPTION:[0;0m
[1;35m@@ -142,20 +142,24 @@[0;0m
[0;0m }[0;0m
[0;0m [0;0m
[0;0m # @FUNCTION: gst-plugins10_find_plugin_dir[0;0m
[1;34m+# @USAGE: gst-plugins10_find_plugin_dir [build_dir][0;0m
[0;0m # @INTERNAL[0;0m
[0;0m # @DESCRIPTION:[0;0m
[0;0m # Finds plugin build directory and cd to it.[0;0m
[1;34m+# Defaults to ${GST_PLUGINS_BUILD_DIR} if argument is not provided[0;0m
[0;0m gst-plugins10_find_plugin_dir() {[0;0m
[1;31m- if [[ ! -d ${S}/ext/${GST_PLUGINS_BUILD_DIR} ]]; then[0;0m
[1;31m- if [[ ! -d ${S}/sys/${GST_PLUGINS_BUILD_DIR} ]]; then[0;0m
[1;34m+ local build_dir=${1:-${GST_PLUGINS_BUILD_DIR}}[0;0m
[1;34m+[0;0m
[1;34m+ if [[ ! -d ${S}/ext/${build_dir} ]]; then[0;0m
[1;34m+ if [[ ! -d ${S}/sys/${build_dir} ]]; then[0;0m
[0;0m ewarn No such plugin directory[0;0m
[0;0m die[0;0m
[0;0m fi[0;0m
[1;31m- einfo Building system plugin ${GST_PLUGINS_BUILD_DIR} ...[0;0m
[1;31m- cd ${S}/sys/${GST_PLUGINS_BUILD_DIR}[0;0m
[1;34m+ einfo Building system plugin in ${build_dir}...[0;0m
[1;34m+ cd ${S}/sys/${build_dir}[0;0m
[0;0m else[0;0m
[1;31m- einfo Building external plugin ${GST_PLUGINS_BUILD_DIR} ...[0;0m
[1;31m- cd ${S}/ext/${GST_PLUGINS_BUILD_DIR}[0;0m
[1;34m+ einfo Building external plugin in ${build_dir}...[0;0m
[1;34m+ cd ${S}/ext/${build_dir}[0;0m
[0;0m fi[0;0m
[0;0m }[0;0m
[0;0m [0;0m
[1;35m@@ -171,15 +175,16 @@[0;0m
[0;0m local directory libs pkgconfig pc tuple[0;0m
[0;0m pkgconfig=$(tc-getPKG_CONFIG)[0;0m
[0;0m [0;0m
[1;31m- gst-plugins10_find_plugin_dir[0;0m
[1;31m-[0;0m
[1;31m- for tuple in $@ ; do[0;0m
[1;31m- directory=$(echo ${tuple} | cut -f1 -d':')[0;0m
[1;31m- pc=$(echo ${tuple} | cut -f2 -d':')-${SLOT}[0;0m
[1;31m- libs=$(${pkgconfig} --libs-only-l ${pc})[0;0m
[1;34m+ for plugin_dir in ${GST_PLUGINS_BUILD_DIR} ; do[0;0m
[1;34m+ gst-plugins10_find_plugin_dir ${plugin_dir}[0;0m
[0;0m [0;0m
[1;31m- sed -e s:\$(top_builddir)/${directory}/.*\.la:${libs}: \[0;0m
[1;31m- -i Makefile.am Makefile.in || die[0;0m
[1;34m+ for tuple in $@ ; do[0;0m
[1;34m+ directory=$(echo ${tuple} | cut -f1 -d':')[0;0m
[1;34m+ pc=$(echo ${tuple} | cut -f2 -d':')-${SLOT}[0;0m
[1;34m+ libs=$(${pkgconfig} --libs-only-l ${pc})[0;0m
[1;34m+ sed -e s:\$(top_builddir)/${directory}/.*\.la:${libs}: \[0;0m
[1;34m+-i Makefile.am Makefile.in || die[0;0m
[1;34m+ done[0;0m
[0;0m done[0;0m
[0;0m }[0;0m
[0;0m [0;0m
[1;35m@@ -253,29 +258,37 @@[0;0m
[0;0m # @DESCRIPTION:[0;0m
[0;0m # Compiles requested gstreamer plugin.[0;0m
[0;0m gst-plugins10_src_compile() {[0;0m
[1;34m+ local plugin_dir[0;0m
[1;34m+ [0;0m
[0;0m has ${EAPI:-0} 0 1 gst-plugins10_src_configure $@[0;0m
[0;0m [0;0m
[1;31m- gst-plugins10_find_plugin_dir[0;0m
[1;34m+ for plugin_dir in ${GST_PLUGINS_BUILD_DIR} ; do[0;0m
[1;34m+ gst-plugins10_find_plugin_dir ${plugin_dir}[0;0m
[0;0m [0;0m
[1;31m- if has ${EAPI:-0} 0 1 2 3 ; then[0;0m
[1;31m- emake || die[0;0m
[1;31m- else[0;0m
[1;31m- default[0;0m
[1;31m- fi[0;0m
[1;34m+ if has ${EAPI:-0} 0 1 2 3 ; then[0;0m
[1;34m+ emake || die[0;0m
[1;34m+ else[0;0m
[1;34m+ default[0;0m
[1;34m+ fi[0;0m
[1;34m+ done[0;0m
[0;0m }[0;0m
[0;0m [0;0m
[0;0m # @FUNCTION: gst-plugins10_src_install[0;0m
[0;0m # @DESCRIPTION:[0;0m
[0;0m
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
2013/1/23 Pacho Ramos pa...@gentoo.org 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 Pacho, see the message from robbat2 titled RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
2013/1/23 Fabio Erculiani lx...@gentoo.org I think that the problem is that it is trying to be smart when it's not really possible (unless you want to cover all the corner cases, which is a pain). Hum, but if we could not be smart enough we can at least try to be very annoying. what about a delay of some seconds, exactly like `emerge -C portage` or something very similar? Trying to cover the corner cases but without pretend to be omniscent?
[gentoo-dev] [RFC] Initial proof-of-concept for explicit x86 multilib flags
Hello,
Following my earlier mail, I'm sending two patches which describe how
I see the potential of introducing explicit multilib flags.
The idea is that each arch has its own ABI_arch USE_EXPAND, specifying
the multilib ABIs for choice. For example, x86 has ABI_X86=32 64.
All of those USE_EXPANDs are hidden (using USE_EXPAND_HIDDEN)
in the base profile, and all of their flags are masked.
In the proper multilib profiles, e.g. the amd64 multilib profile,
the relevant USE_EXPAND is removed from USE_EXPAND_HIDDEN, the flags
are unmasked and the default ABI flag is use.forced.
The eclass exports *all* possible ABIs for all arches in IUSE (due
to the necessity of constant metadata). However, it checks only
the flags relevant to the arch (avoids wasting time) and when no flags
are set (e.g. non-multilib system) does a non-multilib build.
The use.force default ABI means that for a typical user the native build
is forced and therefore regular package dependencies are correct.
The user is allowed to disable it in his own profile but he does that
on his own responsibility.
For multilib or non-native builds, a proper USE dependencies need
be used. Multilib builds take [${MULTILIB_USEDEP}] for them; the Skype
example mentioned by aballier would use [abi_x86_32].
I think those are all the important ideas. The patches shall be
considered mostly proof-of-concept, and I'm awaiting further discussion
on the topic.
If anyone is interested in testing the multilib work of mine (which
doesn't use the new flags yet, just the profile-forced 'multilib' flag),
I have converted the live ebuilds corresponding to packages from
emul-linux-x86-xlibs. The packages can be found in the x11 overlay,
'multilib' branch.
$ layman -a x11
$ ( cd /var/lib/layman/x11; git checkout multilib )
$ diffmask -a libX11 # yep, X11 live ebuilds are package.masked
$ emerge -v emul-linux-x86-xlibs
For easier testing, there's media-libs/libtxc_dxtn in the gx86 tree.
But it's nothing really special to see, it doesn't even have
dependencies to prove the major points.
[gentoo-dev] [PATCH 1/2] Add multilib flags for x86.
64- and 32-bit libs involved. No x32 yet since I have no idea about it. --- gx86/profiles/arch/amd64/make.defaults | 4 gx86/profiles/arch/amd64/use.force | 4 gx86/profiles/arch/amd64/use.mask | 5 + gx86/profiles/base/make.defaults | 4 ++-- gx86/profiles/base/use.mask| 5 + gx86/profiles/desc/abi_x86.desc| 9 + 6 files changed, 29 insertions(+), 2 deletions(-) create mode 100644 gx86/profiles/desc/abi_x86.desc diff --git a/gx86/profiles/arch/amd64/make.defaults b/gx86/profiles/arch/amd64/make.defaults index bd020bb..27c480a 100644 --- a/gx86/profiles/arch/amd64/make.defaults +++ b/gx86/profiles/arch/amd64/make.defaults @@ -45,3 +45,7 @@ VIDEO_CARDS=fbdev glint intel mach64 mga nouveau nv r128 radeon savage sis tdfx # 2006/12/22 - Danny van Dyk kugelf...@gentoo.org # Default for ALSA_CARDS USE_EXPAND variable. ALSA_CARDS=ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci + +# Michał Górny mgo...@gentoo.org (23 Jan 2013) +# Make the ABI_X86 multilib USE_EXPAND visible for the profile. +USE_EXPAND_HIDDEN=-ABI_X86 diff --git a/gx86/profiles/arch/amd64/use.force b/gx86/profiles/arch/amd64/use.force index b54bac8..51d7a75 100644 --- a/gx86/profiles/arch/amd64/use.force +++ b/gx86/profiles/arch/amd64/use.force @@ -1,2 +1,6 @@ # Force the flag which corresponds to ARCH. amd64 + +# Michał Górny mgo...@gentoo.org (23 Jan 2013) +# Force building native libraries for the platform. +abi_x86_64 diff --git a/gx86/profiles/arch/amd64/use.mask b/gx86/profiles/arch/amd64/use.mask index 123bdfc..4fc14c3 100644 --- a/gx86/profiles/arch/amd64/use.mask +++ b/gx86/profiles/arch/amd64/use.mask @@ -177,4 +177,9 @@ capslib # fdk-aac is already keyworded here -fdk +# Michał Górny mgo...@gentoo.org (23 Jan 2013) +# Unmask multilib flags for the platform. +-abi_x86_32 +-abi_x86_64 + # NOT NECESSARY - SECTION diff --git a/gx86/profiles/base/make.defaults b/gx86/profiles/base/make.defaults index 00761b6..07e19cf 100644 --- a/gx86/profiles/base/make.defaults +++ b/gx86/profiles/base/make.defaults @@ -16,11 +16,11 @@ USE_EXPAND_VALUES_USERLAND=BSD GNU # Env vars to expand into USE vars. Modifying this requires prior # discussion on gentoo-...@gentoo.org. -USE_EXPAND=APACHE2_MODULES APACHE2_MPMS CALLIGRA_FEATURES ENLIGHTENMENT_MODULES FOO2ZJS_DEVICES MISDN_CARDS FRITZCAPI_CARDS FCDSL_CARDS VIDEO_CARDS DVB_CARDS LIRC_DEVICES INPUT_DEVICES LINGUAS USERLAND KERNEL ELIBC CROSSCOMPILE_OPTS ALSA_CARDS ALSA_PCM_PLUGINS LCD_DEVICES CAMERAS NETBEANS_MODULES QEMU_SOFTMMU_TARGETS QEMU_USER_TARGETS SANE_BACKENDS RUBY_TARGETS PHP_TARGETS NGINX_MODULES_HTTP NGINX_MODULES_MAIL XFCE_PLUGINS XTABLES_ADDONS GPSD_PROTOCOLS COLLECTD_PLUGINS DRACUT_MODULES OFED_DRIVERS GRUB_PLATFORMS FFTOOLS PYTHON_TARGETS CURL_SSL OPENMPI_FABRICS OPENMPI_RM OPENMPI_OFED_FEATURES LIBREOFFICE_EXTENSIONS VOICEMAIL_STORAGE PYTHON_SINGLE_TARGET +USE_EXPAND=APACHE2_MODULES APACHE2_MPMS CALLIGRA_FEATURES ENLIGHTENMENT_MODULES FOO2ZJS_DEVICES MISDN_CARDS FRITZCAPI_CARDS FCDSL_CARDS VIDEO_CARDS DVB_CARDS LIRC_DEVICES INPUT_DEVICES LINGUAS USERLAND KERNEL ELIBC CROSSCOMPILE_OPTS ALSA_CARDS ALSA_PCM_PLUGINS LCD_DEVICES CAMERAS NETBEANS_MODULES QEMU_SOFTMMU_TARGETS QEMU_USER_TARGETS SANE_BACKENDS RUBY_TARGETS PHP_TARGETS NGINX_MODULES_HTTP NGINX_MODULES_MAIL XFCE_PLUGINS XTABLES_ADDONS GPSD_PROTOCOLS COLLECTD_PLUGINS DRACUT_MODULES OFED_DRIVERS GRUB_PLATFORMS FFTOOLS PYTHON_TARGETS CURL_SSL OPENMPI_FABRICS OPENMPI_RM OPENMPI_OFED_FEATURES LIBREOFFICE_EXTENSIONS VOICEMAIL_STORAGE PYTHON_SINGLE_TARGET ABI_X86 # USE_EXPAND variables whose contents are not shown in package manager # output. Changes need discussion on gentoo-dev. -USE_EXPAND_HIDDEN=USERLAND KERNEL ELIBC CROSSCOMPILE_OPTS +USE_EXPAND_HIDDEN=USERLAND KERNEL ELIBC CROSSCOMPILE_OPTS ABI_X86 CONFIG_PROTECT=/etc CONFIG_PROTECT_MASK=/etc/env.d /etc/gconf diff --git a/gx86/profiles/base/use.mask b/gx86/profiles/base/use.mask index 811fa3b..3dc0c36 100644 --- a/gx86/profiles/base/use.mask +++ b/gx86/profiles/base/use.mask @@ -323,3 +323,8 @@ python_targets_pypy2_0 python_single_target_pypy1_8 python_single_target_pypy1_9 python_single_target_pypy2_0 + +# Michał Górny mgo...@gentoo.org (23 Jan 2013) +# Mask all of the multilib flags for non-multilib profiles. +abi_x86_32 +abi_x86_64 diff --git a/gx86/profiles/desc/abi_x86.desc b/gx86/profiles/desc/abi_x86.desc new file mode 100644 index 000..5a11f2a --- /dev/null +++ b/gx86/profiles/desc/abi_x86.desc @@ -0,0 +1,9 @@ +# Copyright 2013 Gentoo Foundation. +# Distributed under the terms of the GNU General Public License v2 +# $Header: $ + +# This file contains descriptions of ABI_X86 USE_EXPAND flags. + +# Keep it sorted. +64 - 64-bit (amd64) libraries +32 - 32-bit (x86) libraries -- 1.8.1.1
[gentoo-dev] [PATCH 2/2] Use new multilib flags in autotools-multilib.
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
--
1.8.1.1
Re: [gentoo-dev] [PATCH 2/2] Use new multilib flags in autotools-multilib.
On Thu, 24 Jan 2013 00:23:57 +0100
Michał Górny mgo...@gentoo.org 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.
+
+ debug-print-function ${FUNCNAME} ${@}
+
+ if use amd64; then
+ use abi_x86_64 echo amd64
+ use abi_x86_32 echo x86
+ fi
+}
I would rather iterate over a variable than hardcoding and duplicating
it here:
MULTILIB_ABIS='abi_x86_32:x86 abi_x86_64:amd64'
IUSE=
for i in $MULTILIB_ABIS ; do
IUSE+= ${i%:*}
done
_autotools-multilib_get_enabled_abis() {
for i in $MULTILIB_ABIS ; do
use ${i%:*} echo ${i#*:}
done
}
(maybe protect it with has_multilib_profile if you wish)
[...]
Alexis.
Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
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). -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
[gentoo-dev] Re: news item for udev 197-r3 upgrade (yes, I know, it's late)
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: On 01/23/2013 04:04 PM, Rich Freeman wrote: System seems to work fine, so I'm not sure how essential that line is. The fact that I'm using an initramfs might also have an effect. I'd strongly suggest using CONFIG_DEVTMPFS_MOUNT=y. and stop worring about udev/openrc. 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.
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
On 23/01/13 21:06, Felix Kuperjans wrote: Mike Gilbert: On Wed, Jan 23, 2013 at 1:29 PM, Felix Kuperjans fe...@desaster-games.com wrote: Samuli Suominen wrote: please review this news item, seems we need one after all Hello Samuli, /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. fstab is not consulted for mounting the root filesystem, so it doesn't really matter what you have in there. Either the kernel mounts it based on the kernel command line, or your initramfs mounts it based on whatever your /init programs does. Well, *if* a line with /dev/root is present in /etc/fstab, the system does not boot up properly (tested it right now). I always though such a line in /etc/fstab is needed so that fsck is run on the root filesystem... Removing the line completely boots up fine, but the filesystem has not been fscked on boot. I don't think we ever instructed users for adding such line... if we did, I'll eat my words. So, I don't think it's necessary to instruct them away from it either, never seen such fstab line. Maybe I'm too naive. - Samuli
[gentoo-dev] Re: news item for udev 197-r3 upgrade (yes, I know, it's late)
Samuli Suominen posted on Thu, 24 Jan 2013 04:04:19 +0200 as excerpted: On 23/01/13 21:06, Felix Kuperjans wrote: On Wed, Jan 23, 2013 at 1:29 PM, Felix Kuperjans fe...@desaster-games.com wrote: Samuli Suominen wrote: please review this news item /dev/root is no longer available in this udev version 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. Well, *if* a line with /dev/root is present in /etc/fstab, the system does not boot up properly (tested it right now). I always though such a line in /etc/fstab is needed so that fsck is run on the root filesystem... Removing the line completely boots up fine, but the filesystem has not been fscked on boot. I don't think we ever instructed users for adding such line... if we did, I'll eat my words. So, I don't think it's necessary to instruct them away from it either, never seen such fstab line. Well technically, we used (and still use, see below) the uppercase /dev/ROOT, with instructions documenting what to replace it with. But some users apparently simply lowercased that ROOT, and for years it just worked. (Below output edited slightly for posting. $ indicates the shell prompt.): $equery b fstab * Searching for fstab ... sys-apps/baselayout-2.2 (/usr/share/baselayout/fstab) $grep -i /dev/root /usr/share/baselayout/fstab /dev/ROOT /ext3 noatime 0 1 $ [TLDR folks can stop there. The rest is historic observation, arguably interesting, admittedly ranty, but not vital.] Years ago (remember, my first successful gentoo install was 2004.1), the fstab example file found in /usr/share/baselayout/fstab was packaged as /etc/fstab directly. Now, the handbook of the era took great pains to guide people thru editing it appropriately, saying the ALLCAPS entries were intended to be replaced as appropriate for the individual install, AND people were expected to actually use etc-update or the like for its intended purpose, so people weren't /supposed/ to have it simply overwritten. Unfortunately, a lot of folks (sarcasm yes, gentooers, could you believe it? /sarcasm) couldn't read instructions properly, and I'd say gentoo-user averaged at least two threads a month from folks who had killed their fstab with an update and a simple etc-update direct-replace, or couldn't get gentoo self-booting in the first place due to not editing the file at all, despite the instructions to do so. And I'm sure many more read the threads on the list and in the forums, and didn't make a mistake they otherwise would have... I know I certainly did. I've said before that I was actively helping people on the lists well before I got my own gentoo system up and running. (Turned out there was a bug in at least amd64's 2004.0 handling of the then still new NPTL, that I ran into somewhere along the way. I don't know what the fix was, but 2004.1 installed just fine from stage-1, so it must have been fixed... As a result, I was active on the lists for several months before I actually got my own install working, by which time I knew the documentation pretty well, given the help I was giving to others based on it the whole time.) Some of us were actually rather sad to see the file moved to /usr/share, since with it working as it did, gentoo newbies tended to learn to actually pay attention to the instructions reasonably early on, after being pointed to them. As I've said before, it was well known and frequently posted in the user lists back then that gentoo wasn't a handholding distribution. Gentooers, as sysadmins of their own systems, were expected to take responsibility for them, reading instructions, etc. If they preferred not to or couldn't learn to do so after a couple mistakes like that, well, there were (and are still) other distributions more suited to them, and in all seriousness, not to put people down but simply to recommend a distro that would be a better fit for them, it wasn't rare at all to see a recommendation that people seriously assess whether they wanted to take on that responsibility, and if not, they really should be on a different distro, as gentoo definitely wasn't for them! So a /dev/ROOT entry was and actually still is part of the default fstab, it's just that the baselayout package places that fstab elsewhere, these days. Evidently, some users saw the example and simply lowercased that /dev/ROOT entry into /dev/root, despite the handbook specifically recommending replacing it with the appropriate /dev/[sh]daX parameter, and because of the kernel/devfs/udev entry for that, it just worked. Now that long stale entry is beginning to cause issues. Meanwhile, if we still shipped /etc/fstab directly, as back then, I expect we'd have way less troubles with people not paying attention to instructions and trying to foist their responsibilities as sysadmin
Re: [gentoo-dev] Re: news item for udev 197-r3 upgrade (yes, I know, it's late)
Duncan wrote: Samuli Suominen posted on Thu, 24 Jan 2013 04:04:19 +0200 as excerpted: On 23/01/13 21:06, Felix Kuperjans wrote: On Wed, Jan 23, 2013 at 1:29 PM, Felix Kuperjans fe...@desaster-games.com wrote: Samuli Suominen wrote: please review this news item /dev/root is no longer available in this udev version 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. Well, *if* a line with /dev/root is present in /etc/fstab, the system does not boot up properly (tested it right now). I always though such a line in /etc/fstab is needed so that fsck is run on the root filesystem... Removing the line completely boots up fine, but the filesystem has not been fscked on boot. I don't think we ever instructed users for adding such line... if we did, I'll eat my words. So, I don't think it's necessary to instruct them away from it either, never seen such fstab line. Well technically, we used (and still use, see below) the uppercase /dev/ROOT, with instructions documenting what to replace it with. But some users apparently simply lowercased that ROOT, and for years it just worked. (Below output edited slightly for posting. $ indicates the shell prompt.): $equery b fstab * Searching for fstab ... sys-apps/baselayout-2.2 (/usr/share/baselayout/fstab) $grep -i /dev/root /usr/share/baselayout/fstab /dev/ROOT /ext3 noatime 0 1 $ [TLDR folks can stop there. The rest is historic observation, arguably interesting, admittedly ranty, but not vital.] Years ago (remember, my first successful gentoo install was 2004.1), the fstab example file found in /usr/share/baselayout/fstab was packaged as /etc/fstab directly. Now, the handbook of the era took great pains to guide people thru editing it appropriately, saying the ALLCAPS entries were intended to be replaced as appropriate for the individual install, AND people were expected to actually use etc-update or the like for its intended purpose, so people weren't /supposed/ to have it simply overwritten. I started using Gentoo in the 1.4 days. I to changed /dev/ROOT to /dev/root and added the proper locations/options for root and every other mount point I have. This is the first I have heard of fstab not needing the root mount line. If this is a change, someone needs to tell the users, even us old timers. ;-) Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
