Re: [gentoo-user] This nite's switch to full multilib
On Monday 30 Mar 2015 09:58:37 Stefan G. Weichinger wrote: On 30.03.2015 00:51, Alan McKinnon wrote: I like Gentoo, you all know, but things like that scare me off a bit. This is Gentoo, it's all about choice. Sometimes there's a downside, like a very long package.use to define to Portage exactly what your choice really is. I don't really know what to decide here Portage ought to ask you to add abi_x86_32 in package.use for the packages that need it. Setting the flag globally is covered in today's news item on the matter, so I assume the devs are supporting it Did that now, yes ... Hmm ... I don't think setting abi_x86_32 globally is necessary, unless you want to have 32bit libs for ALL packages that these exist for, whether you use them or not. I mean that for Skype you have no alternative at present, but if you don't use Skype then you would not need the 32bit versions of Skype's dependencies. If my understanding is wrong, Alan will soon put me right on this. :-) -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] This nite's switch to full multilib
On 30.03.2015 11:39, Alan McKinnon wrote: On 30/03/2015 11:23, Mick wrote: Hmm ... I don't think setting abi_x86_32 globally is necessary, unless you want to have 32bit libs for ALL packages that these exist for, whether you use them or not. I mean that for Skype you have no alternative at present, but if you don't use Skype then you would not need the 32bit versions of Skype's dependencies. If my understanding is wrong, Alan will soon put me right on this. :-) You understand it just fine. OK, then so why do I have to edit files to tell the system to USE this and that after the system tells me it needs that ... ? Why isn't this taken care of within portage itself? I don't *want* to decide 32bit or not ... (I like that I *can* ...) I want a (mostly) stable and current linux system with the necessary choices done by the maintainers ... if Skype needs it ... ok, then make that a dependency/requirement somewhere ... but why force me to set that (for so many packages) ? - I removed the global flag now again and only had to add that flag for a few packages now ... maybe because others have been rebuilt already? Maybe it isn't as bad as I thought in the first place. I hope that this is a desktop/GUI-issue mostly? Having to do that on dozens of customer servers is not on my wishlist right now :-) Stefan
Re: [gentoo-user] This nite's switch to full multilib
Alan McKinnon wrote: On 30/03/2015 00:10, Stefan G. Weichinger wrote: Am 29.03.2015 um 20:16 schrieb Alan McKinnon: I have to do that for 195 ebuilds here and really wonder if that is correct in the end It's a horrible solution, you are right. The problem is that it's not your 32 bit apps that have to be listed, it's all the libs and deps they have that need 32 bit versions to be built. If you have a fast cpu, much disk space and don't care about using some extra resources, you can always add USE=abi_xx86_32 to make.conf and make it global. Every package that supports building 32 bit versions will then be recompiled. Is that as it is meant to be or some not-so-ideal-switch that will soon get some polishing? IMO I shouldn't have to list hundreds of packages (I had to add more and more) in some non-default-list ... even when I decide to run unstable (~amd64). My main system isn't that special at all, gnome, systemd, libreoffice, thunderbird, some browsers ... Stuff like that makes me really wonder if I spend too much of my life time struggling with doing *updates* I like Gentoo, you all know, but things like that scare me off a bit. This is Gentoo, it's all about choice. Sometimes there's a downside, like a very long package.use to define to Portage exactly what your choice really is. Setting the flag globally is covered in today's news item on the matter, so I assume the devs are supporting it Dang. I had to add about 90 packages to my package.use and some more to the keyword file. I wonder if make.conf would be better in my case too? My use file just grew my a huge amount. Dale :-) :-)
Re: [gentoo-user] This nite's switch to full multilib
On Sunday 29 March 2015 20:12:45 Alan McKinnon wrote: ... I think Michael posted the correct cause up-thread: If you're on stable, you'll need to keyword qt-4.8.6 in its entirety. You can't mix and match versions, and 4.8.6 is the only one that supports multilib. Something needs clarifying here. Exactly who will need to keyword qt-4.8.6? So you probably want to add all current Qt4 packages to the list. We should probably start asking all posters with similar problems what is the output of grep -ir qt /etc/portage and help them remove all cruft that's getting in the way of a clean upgrade Just to get you started, here's my list from a system that upgraded smoothly: $ grep qt /etc/portage/package.use app-text/popplercairo qt4 dev-qt/qtcore qt3support dev-qt/qtdeclarativeqt3support webkit dev-qt/qtguiqt3support dev-qt/qtopengl qt3support dev-qt/qtsqlmysql qt3support dev-qt/qtwebkit icu (Package.use is the only place where qt occurs.) -- Rgds Peter.
[gentoo-user] Moving from no-multilib to (true) multilib
Given that the emul-linux-x86 package sets are now deprecated and we can now with USE=abi_x86_32 emerge our own 32bit libraries where needed, is it now easier to move from a no-multilib to a multilib environment, or will it still require a complete reinstall? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] How to poweroff the system from user?
On Monday 30 Mar 2015 01:32:21 Walter Dnes wrote: On Sun, Mar 29, 2015 at 03:30:07PM -0400, Rich Freeman wrote With TPM, full-disk encryption, and a verified boot path, you could actually protect against that scenario (they'd have to tear apart the TPM chip and try to access the non-volatile storage directly, and the chips are specifically designed to defeat this). Secure boot would not hurt either (with your own keys). Of course, they could still try to hack in via USB/PCI/etc, or plant keyloggers and such. I'm not suggesting physical security isn't important. It just isn't a good reason to completely neglect console security. Be careful what you wish for. I have my doubts that TPM chips would boot linux with Microsoft offering volume discounts to OEMS. Call me cynical. Well, yes, post Snowden revelations we can reasonably suspect that the TPM OEMs have degraded the randomness of the chip sufficiently for spooks to be able to crack your keys. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] This nite's switch to full multilib
On 30.03.2015 00:51, Alan McKinnon wrote: I like Gentoo, you all know, but things like that scare me off a bit. This is Gentoo, it's all about choice. Sometimes there's a downside, like a very long package.use to define to Portage exactly what your choice really is. I don't really know what to decide here Setting the flag globally is covered in today's news item on the matter, so I assume the devs are supporting it Did that now, yes ...
Re: [gentoo-user] How to poweroff the system from user?
On Monday 30 Mar 2015 01:52:14 Rich Freeman wrote: On Sun, Mar 29, 2015 at 8:32 PM, Walter Dnes waltd...@waltdnes.org wrote: Be careful what you wish for. I have my doubts that TPM chips would boot linux with Microsoft offering volume discounts to OEMS. Call me cynical. TPM chips don't control what boots. They just accept the hash of the bootloader reported by the firmware and store it (and that is it as far as the OEM's contribution to the process). Rich, the problem with TPM as I understand it is that the private key in the TPM chip is not yours, generated on your trusted platform, but the TPM manufacturer's and is burned into the TPM chip at the time of production. If the TPM OEMs are in US or within the sphere of influence of the US, then I would consider this key as good as compromised. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] This nite's switch to full multilib
On 30/03/2015 11:23, Mick wrote: Hmm ... I don't think setting abi_x86_32 globally is necessary, unless you want to have 32bit libs for ALL packages that these exist for, whether you use them or not. I mean that for Skype you have no alternative at present, but if you don't use Skype then you would not need the 32bit versions of Skype's dependencies. If my understanding is wrong, Alan will soon put me right on this. :-) You understand it just fine. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] This nite's switch to full multilib
On 30/03/2015 12:02, Stefan G. Weichinger wrote: On 30.03.2015 11:39, Alan McKinnon wrote: On 30/03/2015 11:23, Mick wrote: Hmm ... I don't think setting abi_x86_32 globally is necessary, unless you want to have 32bit libs for ALL packages that these exist for, whether you use them or not. I mean that for Skype you have no alternative at present, but if you don't use Skype then you would not need the 32bit versions of Skype's dependencies. If my understanding is wrong, Alan will soon put me right on this. :-) You understand it just fine. OK, then so why do I have to edit files to tell the system to USE this and that after the system tells me it needs that ... ? Why isn't this taken care of within portage itself? I don't *want* to decide 32bit or not ... (I like that I *can* ...) I want a (mostly) stable and current linux system with the necessary choices done by the maintainers ... if Skype needs it ... ok, then make that a dependency/requirement somewhere ... but why force me to set that (for so many packages) ? OK, think it through first. You want skype. Skype is 32bit. So far, we're good. You put an entry in package.use to enable abi_x86_32 for skype. But that's not the end of the story, because *every*single*lib* skype uses now needs a 32 bit, and the skype ebuild cannot change that. That part should be obvious - the skype ebuild cannot make changes to how the qt ebuilds behave, only you can do that. And you do it either with a global flag or by listing what you want in package.use - none of this has changed, you've been doing exactly this for years. The next problem is the sheer number of libs that now have to be tagged as needing 32 bit versions to be built. It's not like deciding you want ffmpeg and now a few odd things need to be rebuilt with ffmpeg support; if you don't rebuild all dep libs with 32 bit versions, then skype does not work at all. You've never had to do this before as we had emul-linux-x86 to provide the needed versions, now we have to do that part ourselves. Ans it's a long list, no getting around that. - I removed the global flag now again and only had to add that flag for a few packages now ... maybe because others have been rebuilt already? Possibly, I'm not sure what steps you already took Maybe it isn't as bad as I thought in the first place. I hope that this is a desktop/GUI-issue mostly? Having to do that on dozens of customer servers is not on my wishlist right now :-) Well, there is legacy grub, that's a 32 bit app and needs to be dealt with. Otherwise in practice it is mostly GUI apps and then mostly only proprietary bundles (skype, flash, and friends). All the regular open source apps you run have been fully 64 bit for ages. It's entirely possible there is some niche app for server situations that is also 32 bit, but I have not come across any yet. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] This nite's switch to full multilib
On Sunday 29 March 2015 17:58:46 Mick wrote: On Sunday 29 Mar 2015 17:43:42 waben...@gmail.com wrote: Mick michaelkintz...@gmail.com wrote: I've also ended up with qt blockers, that I do not seem capable to overcome yet. KDE wants qt 4.8.5 installed which is blocking qt 4.8.6. How did you go about overcoming this? I also have dev-qt/qtcore-4.8.5-r2 and some other qt packages installed but I had no problems with that. I'm on gentoo stable (not ~amd64) and I don't use KDE. I only use some KDE apps, not the full meta. There seems to be a problem with dev-qt/qtchooser and qt-4.8.6 Ah, that explains it. I haven't been adventurous enough to try qt5 yet, so no need for qtchooser. Thank goodness for the quiet life! -- Rgds Peter.
Re: [gentoo-user] How to poweroff the system from user?
On Mon, Mar 30, 2015 at 4:09 AM, Mick michaelkintz...@gmail.com wrote: On Monday 30 Mar 2015 01:52:14 Rich Freeman wrote: On Sun, Mar 29, 2015 at 8:32 PM, Walter Dnes waltd...@waltdnes.org wrote: Be careful what you wish for. I have my doubts that TPM chips would boot linux with Microsoft offering volume discounts to OEMS. Call me cynical. TPM chips don't control what boots. They just accept the hash of the bootloader reported by the firmware and store it (and that is it as far as the OEM's contribution to the process). Rich, the problem with TPM as I understand it is that the private key in the TPM chip is not yours, generated on your trusted platform, but the TPM manufacturer's and is burned into the TPM chip at the time of production. If the TPM OEMs are in US or within the sphere of influence of the US, then I would consider this key as good as compromised. As far as I'm aware, using a TPM for full-disk encryption does not rely on any keys pre-installed in the TPM. Typically you install your own key or have the TPM generate one for you. All the TPM does is refuse to divulge the key unless the firmware reported that the bootloader hash matches what you told it to look out for, and the bootloader reported that the kernel hash matches what you told it to look for (and you can go beyond that, but only if you are using a distro that signs its userspace, which I believe is a direction RedHat is going). However, if the TPM or firmware has a back-door, then I'll certainly grant that the NSA can read your hard drive. They don't even need to compromise the TPM - the firmware alone is capable of compromising the trusted boot path. It just needs to tell the TPM that it booted your trusted bootloader when it really booted something else. Securing your system isn't really about keeping the NSA out. If they want in, they're probably already in. Sure, it might be hypothetically possible to keep them out, but it would take far more effort than almost anybody is going to be willing to put in. A TPM will likely do a very effective job at keeping the 99.999% of people on the Earth who aren't the NSA out, which seems to be good enough for just about every company on the planet, since most secure their laptops with TPMs. -- Rich
[gentoo-user] Re: This nite's switch to full multilib
On Mon, 30 Mar 2015 12:14:29 +0200, Alan McKinnon wrote: OK, then so why do I have to edit files to tell the system to USE this and that after the system tells me it needs that ... ? Why isn't this taken care of within portage itself? I don't *want* to decide 32bit or not ... (I like that I *can* ...) I want a (mostly) stable and current linux system with the necessary choices done by the maintainers ... if Skype needs it ... ok, then make that a dependency/requirement somewhere ... but why force me to set that (for so many packages) ? OK, think it through first. Sure thing. You want skype. Skype is 32bit. So far, we're good. You put an entry in package.use to enable abi_x86_32 for skype. Except..at that point you would have already failed. There is no good reason whatsoever why portage shouldn't be able to treat this like a transitive required USE flag requirement, percolating through all libs from the toplevel requirement's dependency tree. In fact it should do so automatically when the ebuild declares the abi_x86_32 constraint from the start, without requiring the user to do anything. There are other reasons why coupling the native and 32-bit worlds together is a bad idea in the long-term, regardless of understandable technical reasons and good intentions. So yeah: think it through first. -h
[gentoo-user] Re: Moving from no-multilib to (true) multilib
On Mon, 30 Mar 2015 11:20:23 +0100, Mick wrote: Given that the emul-linux-x86 package sets are now deprecated and we can now with USE=abi_x86_32 emerge our own 32bit libraries where needed, is it now easier to move from a no-multilib to a multilib environment, or will it still require a complete reinstall? My understanding is that this has not changed, i.e. the move from prebuilt emul-linux package to abi_x86_32 only applies to existing multilib systems. Moving from plain aka non-multilib to multilib is still more or less unsupported/impossible and requires a reinstall. -h
Re: [gentoo-user] This nite's switch to full multilib
On Mon, Mar 30, 2015 at 6:02 AM, Stefan G. Weichinger li...@xunil.at wrote: OK, then so why do I have to edit files to tell the system to USE this and that after the system tells me it needs that ... ? Why isn't this taken care of within portage itself? I don't *want* to decide 32bit or not ... (I like that I *can* ...) This goes way beyond 32-bit. The way things work in Gentoo right now is that portage can decide to install a package at any time without any config file changes (unless it is keyword/package masked). However, it can't change the USE configuration of a package unless this ends up in a config file. In a sense I think giving portage more freedom to do this would be better. It does increase the likelihood of blockers, but we already deal with those for package blocks. It would also mean that a proper depclean might actually involve package rebuilds (unless we make depclean just remove stuff, and an emerge -N rebuild stuff). I'm trying to think of what the downside is to just letting portage set the flags however seems best unless a flag is explicitly set or unset in configuration. I can't think of any issues offhand - I think that most of the work that needs to be done by emerge to calculate deps needs to be done anyway. Obviously it would take effort to do. I ended up with 800 lines being added to my package.use, which now constitutes 2/3rds of the file. Granted, most of those are comments. Some of the comments are also less than ideal, like: # required by media-libs/libgphoto2-2.5.7 # required by kde-base/kamera-4.14.3 # required by kde-base/kdegraphics-meta-4.14.3 # required by kde-base/kde-meta-4.14.3 # required by @selected # required by @world (argument) =virtual/libusb-1-r1 abi_x86_32 This tends to imply that kde-meta needs 32-bit libusb. I suspect that some other package does need 32-bit libgphoto2, which then needs 32-bit libusb, but kde-meta shows up in the comment instead. The packages that gave me the most trouble were wine and steam. I don't think there were any problems with them - they just pull in a lot of 32-bit deps. -- Rich
Re: [gentoo-user] Re: This nite's switch to full multilib
On Mon, 30 Mar 2015 12:15:01 + (UTC), Holger Hoffstätte wrote: Portage does not override your choices, and it certainly does not allow one single ebuild to automagically change the behaviour of multiple other ebuilds. The correct way to bring about changes in behaviour is to add your global choices to make.conf (which is outside the control of the tree), or to add your explicit changes to package.* ..that just shows the root of the problem: the ABI is not handled consistently, but rather as a per-package configuration choice. The news item also showed how to make it a global choice, avoiding the need to multiple per-package directories. I already *collectively opted into* the 32-bit parallel universe by *choosing multilib*. All the current way is doing is repeating that choice without accomplishing anything, esp. since I cannot reasonably NOT make that choice. It's a hard requirement if I want to run a certain application. That's a fair point. Maybe multilib should default to ABI_X86=64 32 -- Neil Bothwick To the optimist, the glass is half full. To the pessimist, the glass is half empty. To the engineer, the glass is twice as big as it needs to be. pgptLoNXOUQgQ.pgp Description: OpenPGP digital signature
Re: [gentoo-user] This nite's switch to full multilib
On Mon, 30 Mar 2015 05:59:24 -0500, Dale wrote: Neil Bothwick wrote: On Mon, 30 Mar 2015 04:12:59 -0500, Dale wrote: I wonder if make.conf would be better in my case too? My use file just grew my a huge amount. You package.use has grown by one filesystem block at most, how much extra disk space and CPU cycles would you use by compiling 32 bit options for every package that has them? I wasn't worried about disk space, just that I rarely use entries in that file. Heck, it's enough to manage the other package.* files already. I wonder if it may have been better to update the multilib profiles to set the flag globally be default, it would make life easier and you could still turn it off if you wanted to. If you use a single file for package.use, it does make it far more cumbersome to manage, but that's why I switched to separate files many years ago. I've tried separate files and having them all in one file. Either way, each entry requires a person to manage it. For me at least, it's six of one and half a dozen of the other. ;-) Actually, it's one big one vs six small ones :) I find the separate files much easier to manage as all the settings for each package are kept separate, and easily removed or changed - for example when I stop using the package. The alternative would be to comment every entry in the file so I know why I put it there and whether I still needed it. -- Neil Bothwick If a book about failures doesn't sell, is it a success? pgpeFwRhfKmQC.pgp Description: OpenPGP digital signature
Re: [gentoo-user] This nite's switch to full multilib
On Monday 30 March 2015 13:40:12 Neil Bothwick wrote: [Re package.use] I find the separate files much easier to manage as all the settings for each package are kept separate, and easily removed or changed - for example when I stop using the package. The alternative would be to comment every entry in the file so I know why I put it there and whether I still needed it. To each his own, of course, but I find the single file much easier to manage. I only ever put things in there if they're required by portage, and the occasional eix-test-obsolete checks that I'm still efficient. -- Rgds Peter.
[gentoo-user] Re: This nite's switch to full multilib
On Mon, 30 Mar 2015 13:44:59 +0100, Neil Bothwick wrote: On Mon, 30 Mar 2015 12:15:01 + (UTC), Holger Hoffstätte wrote: Portage does not override your choices, and it certainly does not allow one single ebuild to automagically change the behaviour of multiple other ebuilds. The correct way to bring about changes in behaviour is to add your global choices to make.conf (which is outside the control of the tree), or to add your explicit changes to package.* ..that just shows the root of the problem: the ABI is not handled consistently, but rather as a per-package configuration choice. The news item also showed how to make it a global choice, avoiding the need to multiple per-package directories. I'm not sure that's a solution to the problem at all (which is why I didn't do it on my machines either). Apart from always wasting much more work resources than necessary for no good reason it doesn't answer the question what happens as soon as I want to build a package that is 64-bit-only - in which case you'd end up in the same situation we have now, just mirrored. -h
Re: [gentoo-user] Re: configure.ac and Makefile.am easy_view ?
On 03/29/2015 05:46 AM, Peter Humphrey wrote: $ ebuild $(equery w xjobs) prepare Ok, you got me!
Re: [gentoo-user] This nite's switch to full multilib
On Mon, 30 Mar 2015 08:42:07 -0500, Dale wrote: I find the separate files much easier to manage as all the settings for each package are kept separate, and easily removed or changed - for example when I stop using the package. The alternative would be to comment every entry in the file so I know why I put it there and whether I still needed it. What I ran into, I'd update say KDE. It would need some packages added to the keyword file. Some may not be KDE but packages that KDE depends on. Well, should those that are KDE go into the KDE file and the ones that are dependencies but not KDE go into a file of its own or what? You put them wherever you want! I put them in kde, because that's what they are for. That way I know that those entries were required by KDE without having to fill the single file with comments. -- Neil Bothwick O.K. I'm weird, but I'm saving up to become eccentric. pgp9ABDvTJesi.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Re: This nite's switch to full multilib
On Mon, 30 Mar 2015 13:04:47 + (UTC), Holger Hoffstätte wrote: The news item also showed how to make it a global choice, avoiding the need to multiple per-package directories. I'm not sure that's a solution to the problem at all (which is why I didn't do it on my machines either). Apart from always wasting much more work resources than necessary for no good reason it doesn't answer the question what happens as soon as I want to build a package that is 64-bit-only - in which case you'd end up in the same situation we have now, just mirrored. Yes, the only question is would it be a better or worse situation. From a pragmatic point of view it would be better, since the only inconvenience would be in extra builds, nothing would stop working in the meantime and you are far less likely to get blockers. Neither solution is ideal, but the change from the old binary packages had to be made at some point. At least we will now be spared the messages from revdep-rebuild and perl-cleaner about binary packages that won't change no matter how many time we reinstall them. -- Neil Bothwick Processor: (n.) a device for converting sense to nonsense at the speed of electricity, or (rarely) the reverse. pgp8bVa48CzFG.pgp Description: OpenPGP digital signature
Re: [gentoo-user] This nite's switch to full multilib
Neil Bothwick wrote: On Mon, 30 Mar 2015 05:59:24 -0500, Dale wrote: Neil Bothwick wrote: On Mon, 30 Mar 2015 04:12:59 -0500, Dale wrote: I wonder if make.conf would be better in my case too? My use file just grew my a huge amount. You package.use has grown by one filesystem block at most, how much extra disk space and CPU cycles would you use by compiling 32 bit options for every package that has them? I wasn't worried about disk space, just that I rarely use entries in that file. Heck, it's enough to manage the other package.* files already. I wonder if it may have been better to update the multilib profiles to set the flag globally be default, it would make life easier and you could still turn it off if you wanted to. I was wondering the same thing but I guess they have some reason for doing it this way, that we don't know about it would seem. ;-) If you use a single file for package.use, it does make it far more cumbersome to manage, but that's why I switched to separate files many years ago. I've tried separate files and having them all in one file. Either way, each entry requires a person to manage it. For me at least, it's six of one and half a dozen of the other. ;-) Actually, it's one big one vs six small ones :) I find the separate files much easier to manage as all the settings for each package are kept separate, and easily removed or changed - for example when I stop using the package. The alternative would be to comment every entry in the file so I know why I put it there and whether I still needed it. What I ran into, I'd update say KDE. It would need some packages added to the keyword file. Some may not be KDE but packages that KDE depends on. Well, should those that are KDE go into the KDE file and the ones that are dependencies but not KDE go into a file of its own or what? If I split it, how do I keep up with it? If I don't split it, then I have a larger file to deal with. After running in circles with that for a while, I just went with one file and hoped for the best. lol Dale :-) :-)
Re: [gentoo-user] This nite's switch to full multilib
On Mon, 30 Mar 2015 12:02:23 +0200, Stefan G. Weichinger wrote: Hmm ... I don't think setting abi_x86_32 globally is necessary, unless you want to have 32bit libs for ALL packages that these exist for, whether you use them or not. I mean that for Skype you have no alternative at present, but if you don't use Skype then you would not need the 32bit versions of Skype's dependencies. If my understanding is wrong, Alan will soon put me right on this. :-) You understand it just fine. OK, then so why do I have to edit files to tell the system to USE this and that after the system tells me it needs that ... ? Why isn't this taken care of within portage itself? Because this is Gentoo and you are in charge of portage, not the other way around. Portage goes as far as it can without trampling over your choices by saying these are the changes I need you to make, press Y to accept them. It's not like you have to add one atom to package.use manually, run emerge again, add another etc. -- Neil Bothwick Why is the word abbreviation so long? pgpAQbQLb2V7E.pgp Description: OpenPGP digital signature
Re: [gentoo-user] This nite's switch to full multilib
Neil Bothwick wrote: On Mon, 30 Mar 2015 04:12:59 -0500, Dale wrote: Dang. I had to add about 90 packages to my package.use and some more to the keyword file. I wonder if make.conf would be better in my case too? My use file just grew my a huge amount. You package.use has grown by one filesystem block at most, how much extra disk space and CPU cycles would you use by compiling 32 bit options for every package that has them? I wasn't worried about disk space, just that I rarely use entries in that file. Heck, it's enough to manage the other package.* files already. If you use a single file for package.use, it does make it far more cumbersome to manage, but that's why I switched to separate files many years ago. I've tried separate files and having them all in one file. Either way, each entry requires a person to manage it. For me at least, it's six of one and half a dozen of the other. ;-) Dale :-) :-)
Re: [gentoo-user] This nite's switch to full multilib
On Mon, 30 Mar 2015 04:12:59 -0500, Dale wrote: Dang. I had to add about 90 packages to my package.use and some more to the keyword file. I wonder if make.conf would be better in my case too? My use file just grew my a huge amount. You package.use has grown by one filesystem block at most, how much extra disk space and CPU cycles would you use by compiling 32 bit options for every package that has them? If you use a single file for package.use, it does make it far more cumbersome to manage, but that's why I switched to separate files many years ago. -- Neil Bothwick Sigh - An amplifier for people who suffer in silence pgpFFffxI4U1d.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Re: This nite's switch to full multilib
On 30/03/2015 12:42, Holger Hoffstätte wrote: On Mon, 30 Mar 2015 12:14:29 +0200, Alan McKinnon wrote: OK, then so why do I have to edit files to tell the system to USE this and that after the system tells me it needs that ... ? Why isn't this taken care of within portage itself? I don't *want* to decide 32bit or not ... (I like that I *can* ...) I want a (mostly) stable and current linux system with the necessary choices done by the maintainers ... if Skype needs it ... ok, then make that a dependency/requirement somewhere ... but why force me to set that (for so many packages) ? OK, think it through first. Sure thing. You want skype. Skype is 32bit. So far, we're good. You put an entry in package.use to enable abi_x86_32 for skype. Except..at that point you would have already failed. That does not compute. Please explain. There is no good reason whatsoever why portage shouldn't be able to treat this like a transitive required USE flag requirement, percolating through all libs from the toplevel requirement's dependency tree. Correct, there is no good reason why portage *can't* do that. There is a very good reason why portage *won't* do that, it is not the gentoo way and it goes against gentoo's social contract. Portage does not override your choices, and it certainly does not allow one single ebuild to automagically change the behaviour of multiple other ebuilds. The correct way to bring about changes in behaviour is to add your global choices to make.conf (which is outside the control of the tree), or to add your explicit changes to package.* Portage's default behaviour when confronted with incompatible settings has always been to detect them, and print the output to the console telling you what to do. Now, there is a helper function that you as the system owner can enable if you trust portage and the tree to always make the correct decision - autounmask. You can run it with -p to get a full list that you can edit before running it for real, or you can just let portage go ahead and make the changes it feels are correct. But this is not default behaviour and for very good reason. I get the sense that those who are complaining about abi_x86_32 in this thread are mostly not complaining about what portage does, they are complaining about the number of entries they have to make to portage.use I don't understand why you are advocating a dramatic change in portage's behaviour from what it has done for years. Yes, this latest feature does require some work from you. You have been doing this same work for ages, the main difference being that this time it's a large amount of once-off work. In fact it should do so automatically when the ebuild declares the abi_x86_32 constraint from the start, without requiring the user to do anything. So you want a single ebuild to trigger a tree-wide change in behaviour? I don't think that's a good idea There are other reasons why coupling the native and 32-bit worlds together is a bad idea in the long-term, regardless of understandable technical reasons and good intentions. So yeah: think it through first. I already did. Refer this post. I think I thought about it in ways that you have not considered yet. -- Alan McKinnon alan.mckin...@gmail.com
[gentoo-user] Re: This nite's switch to full multilib
On Mon, 30 Mar 2015 13:14:55 +0200, Alan McKinnon wrote: On 30/03/2015 12:42, Holger Hoffstätte wrote: You want skype. Skype is 32bit. So far, we're good. You put an entry in package.use to enable abi_x86_32 for skype. Except..at that point you would have already failed. That does not compute. Please explain. That was my somewhat categorical way of saying that you'd be repeating yourself with no benefit. The ebuild already knows that it's 32-bit only, so making e.g. the user declare the same thing again would be wrong to begin with. I realize of course that's not how it is done, and that the abi constraint is a required part of the ebuild for precisely that reason. That the current transitional situation is a bit messy - fine. There is no good reason whatsoever why portage shouldn't be able to treat this like a transitive required USE flag requirement, percolating through all libs from the toplevel requirement's dependency tree. Correct, there is no good reason why portage *can't* do that. There is a very good reason why portage *won't* do that, it is not the gentoo way and it goes against gentoo's social contract. That sounds great until you realize that selective capability configuration (aka USE flags, which I love and agree with!) is not the same as multilib profile selection. I really do understand the *idea* of strictly driving system capabilities from user-defined USE flags, so when you say: Portage does not override your choices, and it certainly does not allow one single ebuild to automagically change the behaviour of multiple other ebuilds. The correct way to bring about changes in behaviour is to add your global choices to make.conf (which is outside the control of the tree), or to add your explicit changes to package.* ..that just shows the root of the problem: the ABI is not handled consistently, but rather as a per-package configuration choice. I already *collectively opted into* the 32-bit parallel universe by *choosing multilib*. All the current way is doing is repeating that choice without accomplishing anything, esp. since I cannot reasonably NOT make that choice. It's a hard requirement if I want to run a certain application. It's great that Gentoo gives me choice, but I hope you can see how not having a certain capability or not runnig an application at all are two very different shoes. I get the sense that those who are complaining about abi_x86_32 in this thread are mostly not complaining about what portage does, they are complaining about the number of entries they have to make to portage.use No, they are complaining about the effects of the conflation of concepts, which ends up first in their config file (either manually or by portage), and eventually in their face, increasing the possibility of making completely unrelated mistakes later on. It also gives the false impression that this is a configuration choice, which it really isn't (see above). This also alludes to the secondary aspect I mentioned. Tightly coupling configuration choices possible in one world to the parallel world is going to be a real problem moving forward, precisely for the same reason: conflating a single mechanism for two different worlds with possibly different hard requirements. In fact it should do so automatically when the ebuild declares the abi_x86_32 constraint from the start, without requiring the user to do anything. So you want a single ebuild to trigger a tree-wide change in behaviour? Yes, *because I chose multilib*. That is *exactly* what I want, and - judging by some of the posts here and in the forums - also what most people seem to expect. I'm starting to wonder if it wouldn't be much more economical to provide prebuilt stacked layers of Docker images for 32-bit compatibility. That would solve several classes of problems at once, and not pollute the native Gentoo way with ultimately unsolvable problems. -h
Re: [gentoo-user] Re: This nite's switch to full multilib
On Monday 30 March 2015 15:34:55 Neil Bothwick wrote: At least we will now be spared the messages from [...] perl-cleaner about binary packages that won't change no matter how many time we reinstall them. That certainly is an improvement, yes. I was always unsure how safe I was in ignoring those messages. -- Rgds Peter.
[gentoo-user] online browsable ebuilds by arch?
Hello folks, I use this link for browsing ebuilds online[1]. It is escecially useful when non_gentoo folks are discussion how to compile from sources; particularly complex/compound compilations and or difficult codes (except java). I find myself always referring to online ebuilds when in discussions with folks who are not blessed with a gentoo system to view ebuilds. I often use ebuids as a roadmap for folks that are trying to compile things from soureces. Subliminally, there is the backdrop that folks should use gentoo for source_code development and testing. This fantastic repo has very old codes and often the newer codes are mulit-arch. What I cannot seem to find is this sort of organization, filtered by architecture. It's be really keen to see one just for arm and arm64. So the next time I talking about putting gnucash (for example) on a handheld (mips) device, it is easy to quickly find the correct ebuild from which to be a pedantic snob (just teasing). I do collide with egg_heads, quite often, unfortunately. Redhat and it's derivatives seem to collect such folks; but they admit how horrible those distros are for sourcecode efforts. Any git* repos that have a nice, logical frontend for organizing and visually parsing ebuilds, by arch, would be keen; particularly for arm64. Any comments or suggestions are most welcome. James [1] https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/
Re: [gentoo-user] Re: This nite's switch to full multilib
On Mon, 30 Mar 2015 19:46:54 + (UTC), Grant Edwards wrote: The news item also showed how to make it a global choice, avoiding the need to multiple per-package directories. I'm not sure that's a solution to the problem at all (which is why I didn't do it on my machines either). If the problem is that you don't want things to be inconsistent, then it _does_ solve the problem. Apart from always wasting much more work resources than necessary for no good reason The reason is that somebody wanted their system to be consistent. I don't think that's a particulary good reason, but that's the nice thing aboug Gentoo. Everybody gets to decide what is important to them, and build their system accordingly. It's also practical as it requires no other changes to get your system working. However, it is even less efficient than I had envisaged. ABI_X86=64 32 emerge --update --deep --changed-use --with-bdeps y -pv @world gives Total: 237 packages (237 reinstalls), Whereas: grep -cv '^#' /etc/portage/package.use/abi_x86_32 gives 119 packages. So setting it globally would require three times as many packages to be rebuilt on this KDE system. -- Neil Bothwick You are a completely unique individual, just like everybody else. pgpsk8ddTNaMz.pgp Description: OpenPGP digital signature
[gentoo-user] Re: This nite's switch to full multilib
On 2015-03-30, Alan McKinnon alan.mckin...@gmail.com wrote: On 30/03/2015 15:04, Holger Hoffstätte wrote: On Mon, 30 Mar 2015 13:44:59 +0100, Neil Bothwick wrote: On Mon, 30 Mar 2015 12:15:01 + (UTC), Holger Hoffstätte wrote: Portage does not override your choices, and it certainly does not allow one single ebuild to automagically change the behaviour of multiple other ebuilds. The correct way to bring about changes in behaviour is to add your global choices to make.conf (which is outside the control of the tree), or to add your explicit changes to package.* ..that just shows the root of the problem: the ABI is not handled consistently, but rather as a per-package configuration choice. The news item also showed how to make it a global choice, avoiding the need to multiple per-package directories. I'm not sure that's a solution to the problem at all (which is why I didn't do it on my machines either). If the problem is that you don't want things to be inconsistent, then it _does_ solve the problem. Apart from always wasting much more work resources than necessary for no good reason The reason is that somebody wanted their system to be consistent. I don't think that's a particulary good reason, but that's the nice thing aboug Gentoo. Everybody gets to decide what is important to them, and build their system accordingly. it doesn't answer the question what happens as soon as I want to build a package that is 64-bit-only - in which case you'd end up in the same situation we have now, just mirrored. You can have your system be consistent by setting up everything using global values in make.conf, or you can choose to override that consistency by manually enabling/disabling USE variables on a per-package basis. That's how Gentoo works and how Gentoo has always worked. I don't how this is any different. Maybe it's time we asked the multilib devs how they intended to deal with these questions you raise. It seems there are two options: 1) Add abi_x86_32 on a package-by-package basis (or let emerge do it for you when you tell it to install something with 32-bit requirements like acroread). 2) Add ABI_X86=64 32 to make.conf, and then add -abi_x86_32 on a package-by-package basis if/when you want to build something 64-bit-only. It looks like they intended for you to choose whether you want 32 bit versions built as the exception or as the rule. For the former, you do 1). For the latter, you do 2). So far, I'm going with 1). When I decided to install acroread this morning, emerge added abi_x86_32 flags to package.use for about 80 packages. The other option would have re-built about 200 packages. Either way would have worked, but I wanted to see if emerge really was able to selectively rebuild the subset of packages required by acroread. AFAICT, it did just fine. -- Grant Edwards grant.b.edwardsYow! Yes, but will I at see the EASTER BUNNY in gmail.comskintight leather at an IRON MAIDEN concert?
Re: [gentoo-user] Re: This nite's switch to full multilib
On Monday, March 30, 2015 9:09:14 PM Alan McKinnon wrote: On 30/03/2015 15:04, Holger Hoffstätte wrote: On Mon, 30 Mar 2015 13:44:59 +0100, Neil Bothwick wrote: On Mon, 30 Mar 2015 12:15:01 + (UTC), Holger Hoffstätte wrote: Portage does not override your choices, and it certainly does not allow one single ebuild to automagically change the behaviour of multiple other ebuilds. The correct way to bring about changes in behaviour is to add your global choices to make.conf (which is outside the control of the tree), or to add your explicit changes to package.* ..that just shows the root of the problem: the ABI is not handled consistently, but rather as a per-package configuration choice. The news item also showed how to make it a global choice, avoiding the need to multiple per-package directories. I'm not sure that's a solution to the problem at all (which is why I didn't do it on my machines either). Apart from always wasting much more work resources than necessary for no good reason it doesn't answer the question what happens as soon as I want to build a package that is 64-bit-only - in which case you'd end up in the same situation we have now, just mirrored. Maybe it's time we asked the multilib devs how they intended to deal with these questions you raise. I don't have a problem with the way it is, but I think something like the following would be nice: instead of just supporting use_flag and -use_flag you could add something like @use_flag (auto-use flag) that automatically builds the feature only if needed to satisfy a dependency. That way you're not changing anything with existing configuration and still got full control over it. -- Fernando Rodriguez
Re: [gentoo-user] This nite's switch to full multilib
On Sun, 29 Mar 2015 19:53:18 +0200 Stefan G. Weichinger li...@xunil.at wrote: I have to do that for 195 ebuilds here and really wonder if that is correct in the end Have you tried to unmerge all the emulation packages before updating the system, as advised by the news? I did it before the full update. As the result, my system updated/recompiled about 267 packages (that lasted about 6 hours on my computer) but I had no need to add any abi_x86_32 USE flags in my package.use, though I do have wine installed.
Re: [gentoo-user] online browsable ebuilds by arch?
On Mon, 30 Mar 2015 15:49:07 + (UTC), James wrote: I use this link for browsing ebuilds online[1]. It is escecially useful when non_gentoo folks are discussion how to compile from sources; particularly complex/compound compilations and or difficult codes (except java). I find myself always referring to online ebuilds when in discussions with folks who are not blessed with a gentoo system to view ebuilds. I often use ebuids as a roadmap for folks that are trying to compile things from soureces. Subliminally, there is the backdrop that folks should use gentoo for source_code development and testing. [1] https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/ What I cannot seem to find is this sort of organization, filtered by architecture. It's be really keen to see one just for arm and arm64. That's the main portage tree, the name is a misnomer. Although called gentoo-x86, it is really just portage, which does not have specific ebuilds for different architectures. Architecture suitability is governed by the KEYWORDS variable inside the ebuild. -- Neil Bothwick Women live longer than men because they have so many clothes that they wouldn't be caught dead in. pgp3BGM2_mBLe.pgp Description: OpenPGP digital signature
[gentoo-user] Re: This nite's switch to full multilib
On 2015-03-30, Fernando Rodriguez frodriguez.develo...@outlook.com wrote: On Monday, March 30, 2015 9:09:14 PM Alan McKinnon wrote: Maybe it's time we asked the multilib devs how they intended to deal with these questions you raise. I don't have a problem with the way it is, but I think something like the following would be nice: instead of just supporting use_flag and -use_flag you could add something like @use_flag (auto-use flag) that automatically builds the feature only if needed to satisfy a dependency. That way you're not changing anything with existing configuration and still got full control over it. That could be pretty handy in cases like this. I was also wondering if there might a way for emerge to show you which packages have USE flags enabled that aren't required by any dependent package: it would be sort of like emerge --depclean but for USE flags instead of packages themselves. -- Grant Edwards grant.b.edwardsYow! The PILLSBURY DOUGHBOY at is CRYING for an END to gmail.comBURT REYNOLDS movies!!
Re: [gentoo-user] Re: This nite's switch to full multilib
On 30/03/2015 15:04, Holger Hoffstätte wrote: On Mon, 30 Mar 2015 13:44:59 +0100, Neil Bothwick wrote: On Mon, 30 Mar 2015 12:15:01 + (UTC), Holger Hoffstätte wrote: Portage does not override your choices, and it certainly does not allow one single ebuild to automagically change the behaviour of multiple other ebuilds. The correct way to bring about changes in behaviour is to add your global choices to make.conf (which is outside the control of the tree), or to add your explicit changes to package.* ..that just shows the root of the problem: the ABI is not handled consistently, but rather as a per-package configuration choice. The news item also showed how to make it a global choice, avoiding the need to multiple per-package directories. I'm not sure that's a solution to the problem at all (which is why I didn't do it on my machines either). Apart from always wasting much more work resources than necessary for no good reason it doesn't answer the question what happens as soon as I want to build a package that is 64-bit-only - in which case you'd end up in the same situation we have now, just mirrored. Maybe it's time we asked the multilib devs how they intended to deal with these questions you raise. -- Alan McKinnon alan.mckin...@gmail.com
[gentoo-user] Re: This nite's switch to full multilib
Peter Humphrey peter at prh.myzen.co.uk writes: On Sunday 29 March 2015 20:12:45 Alan McKinnon wrote: grep -ir qt /etc/portage grep qt /etc/portage/package.use | wc -l =11 dev-qt/qt-creator android autotools cmake python dev-qt/qtguiqt3support =dev-qt/qtsql-4.8.5 qt3support =dev-qt/qtcore-4.8.5-r1 qt3support # required by dev-qt/qtcore-4.8.5-r1[qt3support] =dev-qt/qtgui-4.8.5-r1 qt3support # required by dev-qt/qtopengl-4.8.5 =dev-qt/qtgui-4.8.5-r2 -qt3support # required by dev-qt/qt3support-4.8.5 =dev-qt/qtgui-4.8.5-r2 qt3support # required by dev-qt/qtwebkit-4.8.5[gstreamer] # grep -ir qt /etc/portage | wc -l =86 # eselect profile list Available profile symlink targets: [1] default/linux/amd64/13.0 * So I am multilib? How/where do I tell, as one reader posted that the profile is not where we designate if we are multilib or not (news to me). I am open to edumacation on this aspect. and help them remove all cruft that's getting in the way of a clean upgrade I just ran a 'depclean' a few days ago. Dozens of my java hacks (overlays) and such got cleaned out and my apache-spark ebuild (hack) does not compile anymore. No big deal, I get to spend another day learning all the neat things I do not know about maven.. I Did not even know a cleanup was needed but 'eix-test-obsolete' broke me down and kicked me in the teeth. I've got a lot to clean up: eix-test-obsolete | wc -l =209 emerge -uDNvp world | wc -l =111 emerge -uDNvp world : Total: 98 packages (2 upgrades, 2 new, 2 in new slots, 92 reinstalls, 3 uninstalls) All I have done so far is run emerge --sync. I previously sync'd up on 28mar2015 before that. I do not run KDE, I use lxde + lots of java (hacks) I refer to 'java(hacks)' because it is mostly a kludge of old portage packages and overlays. I have automask automated via make.conf. EMERGE_DEFAULT_OPTS=--with-bdeps y --autounmask-write y But before I follow the path of others: cat package.use | wc -l =314 package.use via automask is getting a bit out of hand, already. Somehow, I do not feel good about the devs solution is to munge up something I have already been abusing. So, does 'eix-test-obsolete' have some automated option to clean up package.use? I think I need to do this before applying the latest (dev_inspired) kludge to my main workstation? Maybe I should BE the chicken that I am, and wait a few days for others to flush this out a bit more? It's already been a hell(o)Monday for me.. On a brighter note, I do feel good that my instincts on kludging up a gentoo system, seem to be tracking the devs, quite nicely Guidance, humor and spankings are all welcome. James
[gentoo-user] xen on new install reboots by itself
Hello Everyone, New install, on a old server with raid 10 scsi... The normal installation works fine, the only thing is when we try to boot with xen, it gets to the prompt and then reboots by itself. The following message is what differs between normal gentoo and xen kernel Mar 31 06:32:18 test kernel: [0.138644] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S1_] (20140724/hwxface-580) Mar 31 06:32:18 test kernel: [0.138961] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S2_] (20140724/hwxface-580) Mar 31 06:32:18 test kernel: [0.139267] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S3_] (20140724/hwxface-580) I'm never sure how to debug such errors. Some googling suggested adding ACPI flags (ie, force, on, off), when I do that, the system just reboots without getting to the login prompt. The server is an X346 with hardward servraid 7K with raid 10. Your help is greatly appreciated. N.
[gentoo-user] Easy (cough) way to build earlier gentoo-sources 3.18.x kernel?
I'm getting a bit bogged down trying to build an early release of the 3.18 kernel. Since I can't automatically go back before 3.18.9 now (using portage anyway)... Basically I trying to check if a suspend/resume issue I've got was introduced after the 3.18 kernel was released (or was in the base release). I've got a reproduce-able failure to suspend-to-ram with =3.18.x gentoo kernel sources. However this issue is not present with the gentoo kernel sources =3.17.x. (A systemd nfs client mount problem - which blocks the suspend-to-ram process.) I had a look at the kernel-2 eclass and my head started to hurt... Do I need to wade into the weeds or is there a short-cut I can take to go back to the earliest gentoo-sources 3.18 kernel build :-) -- Thanks, Robert
Re: [gentoo-user] Re: online browsable ebuilds by arch?
On Mon, 30 Mar 2015 21:05:46 + (UTC), James wrote: That's the main portage tree, the name is a misnomer. Although called gentoo-x86, it is really just portage, which does not have specific ebuilds for different architectures. Architecture suitability is governed by the KEYWORDS variable inside the ebuild. Yea, I get that. But I want it 100% filtered by arch. So if I'm looking for ppc (a gentoo supported arch) I have an online portage tree for viewing; so that ALL packages listed, are available for a specific arch. There are many amd64/x86/intel only packages that are not yet ported to a specific arch. So how do I filter the above repo to ensure I only see those packages available for other architectures? It's not quite what you are asking for, but packages.g.o lets you filter by arch, and view the contents of ebuilds. -- Neil Bothwick I've got a Mickey Mouse PC with a Goofy operating system. pgpspCYdaRwKW.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Easy (cough) way to build earlier gentoo-sources 3.18.x kernel?
On Mon, 30 Mar 2015 23:22:58 +0100, Bob Wya wrote: I'm getting a bit bogged down trying to build an early release of the 3.18 kernel. Since I can't automatically go back before 3.18.9 now (using portage anyway)... https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-kernel/gentoo-sources/?hideattic=0 Pick the versions you want and copy the ebuilds to a local overlay. -- Neil Bothwick In a classified ad: Tired of cleaning yourself? Let me do it. pgpeQhvVrNjCa.pgp Description: OpenPGP digital signature
[gentoo-user] Re: Easy (cough) way to build earlier gentoo-sources 3.18.x kernel?
On Mon, Mar 30, 2015 at 06:45:40PM -0400, Fernando Rodriguez wrote: You can use git. I believe gentoo patches are only for config options so if you configure it with make oldconfig it *should* be the same as using gentoo- sources. Actually no, gentoo-sources aren't vanilla kernel while efforts are made to avoid including intrusive patches. http://dev.gentoo.org/~mpagano/genpatches/about.htm http://dev.gentoo.org/~mpagano/genpatches ,-) -- Nicolas Sebrecht
[gentoo-user] Re: This nite's switch to full multilib
On 2015-03-30, Neil Bothwick n...@digimed.co.uk wrote: On Mon, 30 Mar 2015 19:46:54 + (UTC), Grant Edwards wrote: The reason is that somebody wanted their system to be consistent. I don't think that's a particulary good reason, but that's the nice thing aboug Gentoo. Everybody gets to decide what is important to them, and build their system accordingly. It's also practical as it requires no other changes to get your system working. However, it is even less efficient than I had envisaged. ABI_X86=64 32 emerge --update --deep --changed-use --with-bdeps y -pv @world gives Total: 237 packages (237 reinstalls), Whereas: grep -cv '^#' /etc/portage/package.use/abi_x86_32 gives 119 packages. So setting it globally would require three times as many packages to be rebuilt on this KDE system. That's roughly what I came up with this morning when I decided to try installing acroread on one of my XFCE boxes: 81 rebuilds one way, a handful over 200 the other. And I think it's at least the third time in the past few months I've looked up llvm to see what it is and why it's getting built -- I keep getting it confused with lvm. -- Grant Edwards grant.b.edwardsYow! Jesuit priests are at DATING CAREER DIPLOMATS!! gmail.com
[gentoo-user] Re: online browsable ebuilds by arch?
Neil Bothwick neil at digimed.co.uk writes: [1] https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/ What I cannot seem to find is this sort of organization, filtered by architecture. It's be really keen to see one just for arm and arm64. That's the main portage tree, the name is a misnomer. Although called gentoo-x86, it is really just portage, which does not have specific ebuilds for different architectures. Architecture suitability is governed by the KEYWORDS variable inside the ebuild. Yea, I get that. But I want it 100% filtered by arch. So if I'm looking for ppc (a gentoo supported arch) I have an online portage tree for viewing; so that ALL packages listed, are available for a specific arch. There are many amd64/x86/intel only packages that are not yet ported to a specific arch. So how do I filter the above repo to ensure I only see those packages available for other architectures? It's a drag and a time sink to have to open up/parse an ebuild to have to grep for a keyword for a given arch and that is not even 100% reliable. I'm surely thinking there be split/separate listing for arm64, forthcoming. Ideas? James
[gentoo-user] Re: Easy (cough) way to build earlier gentoo-sources 3.18.x kernel?
Bob Wya bob.mt.wya at gmail.com writes: I had a look at the kernel-2 eclass and my head started to hurt... Do I need to wade into the weeds or is there a short-cut I can take to go back to the earliest gentoo-sources 3.18 kernel build Might this help [1] ? I always keep at least 6 older kernels around, for this and many other reasons. If I hack at something (kernelish) then what the resultant effect is (on the kernel) is hard to remember 6 months laters. I do not do enough kernel hacking to warrant my own git repo, but I have considered that two. Using gentoo for about a decade now, I found it just easier to keep older kernels around, sometimes for years, but no more than 7 versions. I stay with amd64 and sometimes I boot up an old system, just to scp a kernel from one machine to another.. I have always found that older kernels, particularly less than a year old most always boot too. Sure there is a more modern, savvy method to keep old kernels around, so hopefully somebody else will pipe up about exactly what you need. Add to this the slobberingly stupid pace of linux kernel releases and you'll understand why lots of folks are archiving kernels (sources and binaries) from the stable branches.. Does systemd provide and tools for this? sorry, James [1] http://wiki.gentoo.org/wiki/Kernel/Upgrade/en
Re: [gentoo-user] Easy (cough) way to build earlier gentoo-sources 3.18.x kernel?
On Monday, March 30, 2015 11:22:58 PM Bob Wya wrote: I'm getting a bit bogged down trying to build an early release of the 3.18 kernel. Since I can't automatically go back before 3.18.9 now (using portage anyway)... Basically I trying to check if a suspend/resume issue I've got was introduced after the 3.18 kernel was released (or was in the base release). I've got a reproduce-able failure to suspend-to-ram with =3.18.x gentoo kernel sources. However this issue is not present with the gentoo kernel sources =3.17.x. (A systemd nfs client mount problem - which blocks the suspend-to-ram process.) I had a look at the kernel-2 eclass and my head started to hurt... Do I need to wade into the weeds or is there a short-cut I can take to go back to the earliest gentoo-sources 3.18 kernel build :-) You can use git. I believe gentoo patches are only for config options so if you configure it with make oldconfig it *should* be the same as using gentoo- sources. cd /usr/src git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux- stable.git cd linux-stable git checkout v3.18.9 make oldconfig make You can checkout any version committed prior to your last git pull instantly. -- Fernando Rodriguez
Re: [gentoo-user] Re: Easy (cough) way to build earlier gentoo-sources 3.18.x kernel?
On Tuesday, March 31, 2015 1:16:08 AM Nicolas Sebrecht wrote: On Mon, Mar 30, 2015 at 06:45:40PM -0400, Fernando Rodriguez wrote: You can use git. I believe gentoo patches are only for config options so if you configure it with make oldconfig it *should* be the same as using gentoo- sources. Actually no, gentoo-sources aren't vanilla kernel while efforts are made to avoid including intrusive patches. http://dev.gentoo.org/~mpagano/genpatches/about.htm http://dev.gentoo.org/~mpagano/genpatches ,-) Oh well, my mistake. I think I heard that here :) Thanks. -- Fernando Rodriguez
Re: [gentoo-user] This nite's switch to full multilib
Neil Bothwick wrote: On Mon, 30 Mar 2015 08:42:07 -0500, Dale wrote: I find the separate files much easier to manage as all the settings for each package are kept separate, and easily removed or changed - for example when I stop using the package. The alternative would be to comment every entry in the file so I know why I put it there and whether I still needed it. What I ran into, I'd update say KDE. It would need some packages added to the keyword file. Some may not be KDE but packages that KDE depends on. Well, should those that are KDE go into the KDE file and the ones that are dependencies but not KDE go into a file of its own or what? You put them wherever you want! I put them in kde, because that's what they are for. That way I know that those entries were required by KDE without having to fill the single file with comments. Yea. We just batting ideas around. For me tho, it just turned into a nightmare. If I needed to change something, which file is it in? At one time I had a dozen or so files and digging through each one of them wastes time. If I have just one file, I open the file and do a ctrl f and type in what I am looking for. Of course, some of the script geeks prolly have a sneaky way of searching and finding out which file it is in but I'm not one of those, most days for sure. Anyway, all the diggin just got old for me. You likely have a easy way of finding it whereas I don't. ;-) Dale :-) :-)
[gentoo-user] Re: Easy (cough) way to build earlier gentoo-sources 3.18.x kernel?
On Mon, 30 Mar 2015 23:22:58 +0100, Bob Wya wrote: I'm getting a bit bogged down trying to build an early release of the 3.18 kernel. Since I can't automatically go back before 3.18.9 now (using portage anyway)... Basically I trying to check if a suspend/resume issue I've got was introduced after the 3.18 kernel was released (or was in the base release). I've got a reproduce-able failure to suspend-to-ram with =3.18.x gentoo kernel sources. However this issue is not present with the gentoo kernel sources =3.17.x. (A systemd nfs client mount problem - which blocks the suspend-to-ram process.) You are probably looking at this bug: http://thread.gmane.org/gmane.linux.nfs/69717 This was introduced in 3.18.9 (as you found out), so simply using vanilla 3.18.8 should fix it; I don't remember seeing it before. I never bothered to try and now just stop NFS before suspend. 3.19.x gained the same problem. -h
Re: [gentoo-user] Re: How to poweroff the system from user?
On Sunday, March 29, 2015 12:23:00 PM lee wrote: Philip Webb purs...@ca.inter.net writes: What's the last time you pressed Ctrl+Alt+Del and it actually worked? It's a legacy thing from times when freezes/crashes were common and when it did work and was useful. Nowadays, when you're pressing it, usually nothing happens anyway because the machine is down to where you have to press the reset button or to turn off the power (if you can't log in with ssh). When the machine still works, Ctrl+Alt+Del also works, which means that the default does nothing but create a security hole. On Linux now there's the Magic SysRq Key feature for that. If enabled (I think it is by default, may be wrong) you can use ctrl-alt-sysrq plus one these keys even if your kernel panics or freezes in most cases (ctrl may only be needed from xorg): r - to get the keyboard back so you can switch to VT if xorg freezes e - to terminate all processes gracefully (SIGTERM) except pid 1 i - to terminate all processes forcefully (SIGKILL) except pid 1 s - to sync all filesystems u - to unmount them and remount readonly b - to reboot Easy to remember as Reboot Even If System Utterly Broken There's a lot of other commands in the kernel docs sysrq.txt So how can we have this default changed? Somebody posted that on this very thread. Replace the ctrlaltdel entry on inittab with /bin/false. -- Fernando Rodriguez
Re: [gentoo-user] xen on new install reboots by itself
On Tue, Mar 31, 2015 at 1:07 AM, symack sym...@gmail.com wrote: Hello Everyone, New install, on a old server with raid 10 scsi... The normal installation works fine, the only thing is when we try to boot with xen, it gets to the prompt and then reboots by itself. The following message is what differs between normal gentoo and xen kernel Mar 31 06:32:18 test kernel: [0.138644] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S1_] (20140724/hwxface-580) Mar 31 06:32:18 test kernel: [0.138961] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S2_] (20140724/hwxface-580) Mar 31 06:32:18 test kernel: [0.139267] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S3_] (20140724/hwxface-580) I'm never sure how to debug such errors. Some googling suggested adding ACPI flags (ie, force, on, off), when I do that, the system just reboots without getting to the login prompt. The server is an X346 with hardward servraid 7K with raid 10. Your help is greatly appreciated. N. Please post your emerge --info information along with xen and xen-tools versions / use flags.
[gentoo-user] Re: online browsable ebuilds by arch?
Neil Bothwick neil at digimed.co.uk writes: Yea, I get that. But I want it 100% filtered by arch. It's not quite what you are asking for, but packages.g.o lets you filter by arch, and view the contents of ebuilds. Yea, I have seen that often when I google. Correct but is not comprehensive but chronologically organized. I'm looking for something organized by what your see, when you 'cd' into the /usr/portage dir comprehensive by category but filters so only those packages available for that specified arch are visible. I also need it online so somebody else does not have be sitting at a gentoo system to read the ebuilds. It also would be great if this 'frontend' could source overlays, and git based repos that contain other ebuilds for examinations and discussions. thanks, James
[gentoo-user] Re: Replacement for acroread on 64bit system?
On 2015-03-06, Grant Edwards grant.b.edwa...@gmail.com wrote: What is a good acroread replacement? I'm not sure what changed, but as of a few weeks ago I can no longer install acroread on my AMD64 system (something to do with x86 emulation librarys being blocked by something in the Xorg server). I've been living without acroread for a couple weeks now, and evince has proven to be a good replacement except when I want to print something (usually I only want to print a couple pages or just a portion of a page). After the big multilib switch was thrown over the weeked I removed the one remaining emulation library, and everything is now updated. So far, ncurses has been the only package for which I've had to add the abi_x86_32 USE flag (32-bit ncurses is required for grub-legacy). So, just for the sake of curiousity, I asked emerge what would be needed to install acroread again. I was pleased to see that emerge now thinks it possible and only wants to rebuild 81 packages with an added abi_x86_32 USE flag (I was actually expecting more). Assuming that will work, it appears to be an easier path than getting okular to install. I've been trying to figure out exactly what that would entail, but emerge is as yet unabled to come up with a list of dependencies. I'm currently on emerge iteration number 12 or 13, and we seem to have gone into a loop where emerge alternates between demanding that I add the qt4 USE flag for media-libs/phonon, and then demands that I remove it. I think we'll see how re-installed acroread goes... -- Grant Edwards grant.b.edwardsYow! I need to discuss at BUY-BACK PROVISIONS gmail.comwith at least six studio SLEAZEBALLS!!
