Re: [gentoo-user] This nite's switch to full multilib
Neil Bothwick n...@digimed.co.uk writes: You can win, by running it reasonably often and actually doing something about the output. Ignore a few lines and they soon become a few more, and then a few more still... One thing I have noticed in its output is where it lists installed packages with a version not in the database (or masked), this is often (in my case) due to slotted packages where portage has only kept the 'highest numbered' slot updated. Is there any magic incantation to emerge which would make it keep all installed slots updated?
Re: [gentoo-user] This nite's switch to full multilib
On Friday, April 03, 2015 8:52:18 AM Stroller wrote: On Thu, 2 April 2015, at 4:37 pm, Grant Edwards grant.b.edwa...@gmail.com wrote: I prefer it this way. I do not want all the nice easy-to read/edit configuration stuff in /etc/portage encrypted some Windows Registry break-alike. What's bad about the Windows registry is that its proprietary file format is both poorly constructed (or, rather lacking design) and obscure, and its reputation was for brittleness was built when it was stored on FAT file systems and corrupted when Windows crashed and had to be hard rebooted. And that it became a central repository for *everything*, it wasn't too bad as just a COM registry on Windows 3.11. Microsoft's been pushing developers to use config files for years but they themselves keep using the registry poorly. Install the latest visual studio, then uninstall it and search your registry. You will find over 20,000 registry entries left behind. If you want to store a lot of stuff, then databases are a valid solution. If there's something wrong with sqlite or BerkeleyDB then argue against them, but don't base your objections on a strawman. I agree that a binary db for portage is a good idea, only because it's ridiculous how long it takes portage to resolve dependencies. It could be just a cache that gets rebuilt after syncing or updating config files. -- Fernando Rodriguez
Re: [gentoo-user] This nite's switch to full multilib
On Sun, 5 Apr 2015 07:21:01 -0400, Rich Freeman wrote: It's like being a teenager again, the longer you leave tidying your room, the longer it takes when your mum makes you do it :) Don't want to harp on it, but I almost never have to clean my world file, and when I do I don't need any tools at all to make it happen. This is because the world file revolves around me and my true requirements, and not an endless list of hints to try to get the package manager to do what I want it to do. We're talking about /etc/portage/package.* here. not @world. I too rarely need to touch world. I think we need to get away from solutions that clutter up configuration in the first place. I'm not under any illusions that this will ever be perfect, but I do think we can do better. Agreed, but this is about managing the options we have now. Like it or not, we need to put extra entries in package.use and eix-test-obsolete is the best current way of removing them when they're no longer needed, as portage's autounmask facility only adds to the file, it never cleans up after itself. -- Neil Bothwick Oxymoron: Reagan memoirs. pgpFz9I_H24Yh.pgp Description: OpenPGP digital signature
Re: [gentoo-user] This nite's switch to full multilib
On Sun, Apr 5, 2015 at 8:09 AM, Neil Bothwick n...@digimed.co.uk wrote: Or leave /etc/portage full of cruft and crap and fix any problem it may cause later on, when you have even less time ;-) Hmm, have an hour of free time now, at the cost of maybe having an hour less of free time a year from now, maybe. That's a hard choice. :) -- Rich
Re: [gentoo-user] This nite's switch to full multilib
On Sun, Apr 5, 2015 at 5:07 AM, Neil Bothwick n...@digimed.co.uk wrote: It's like being a teenager again, the longer you leave tidying your room, the longer it takes when your mum makes you do it :) Don't want to harp on it, but I almost never have to clean my world file, and when I do I don't need any tools at all to make it happen. This is because the world file revolves around me and my true requirements, and not an endless list of hints to try to get the package manager to do what I want it to do. I think we need to get away from solutions that clutter up configuration in the first place. I'm not under any illusions that this will ever be perfect, but I do think we can do better. -- Rich
Re: [gentoo-user] This nite's switch to full multilib
On Sun, 05 Apr 2015 04:41:33 -0500, Dale wrote: I got into that situation once, you just need to bite the bullet and work through the output. It's not as bad as it looks as the same entry can cause multiple reports, so once you clean up a couple of entries the output can get significantly shorter. It's like being a teenager again, the longer you leave tidying your room, the longer it takes when your mum makes you do it :) Well, just for giggles I ran it. Ain't no way I got time to go through all that right now. Heck, it took several minutes for it to just to go through all that stuff. O_O Then don't. Just clean up the output from one of the tests, the one with the shortest output if you prefer. Or leave /etc/portage full of cruft and crap and fix any problem it may cause later on, when you have even less time ;-) -- Neil Bothwick Secret hacker rule #11: hackers read manuals. pgpHBFazrP12V.pgp Description: OpenPGP digital signature
Re: [gentoo-user] This nite's switch to full multilib
On 5 April 2015 14:27:27 BST, Rich Freeman ri...@gentoo.org wrote: On Sun, Apr 5, 2015 at 8:09 AM, Neil Bothwick n...@digimed.co.uk wrote: Or leave /etc/portage full of cruft and crap and fix any problem it may cause later on, when you have even less time ;-) Hmm, have an hour of free time now, at the cost of maybe having an hour less of free time a year from now, maybe. That's a hard choice. :) -- Rich Give up 20 minutes when I can afford it or maybe lose a couple of hours and my remaining hair if it goes tits up later, that's an interesting gamble :) -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Re: [gentoo-user] This nite's switch to full multilib
On Sun, 05 Apr 2015 02:24:13 -0500, Dale wrote: It seems you can't win with that thing. LOL You can win, by running it reasonably often and actually doing something about the output. Ignore a few lines and they soon become a few more, and then a few more still... Thing is, it seems to grow faster than I can clean up. I'm scared to even run it now. It would likely take me a week to get a clean output. ROFL It's been a long time since I ran it. I may be better off to move the files, see what emerge wants to change and add stuff back. Just saying. I got into that situation once, you just need to bite the bullet and work through the output. It's not as bad as it looks as the same entry can cause multiple reports, so once you clean up a couple of entries the output can get significantly shorter. It's like being a teenager again, the longer you leave tidying your room, the longer it takes when your mum makes you do it :) -- Neil Bothwick Member, National Association For Tagline Assimilators (NAFTA) pgpiLLVguGyOj.pgp Description: OpenPGP digital signature
Re: [gentoo-user] This nite's switch to full multilib
Neil Bothwick wrote: On Sat, 04 Apr 2015 07:33:06 -0500, Dale wrote: eix-test-obsolete Many thanks, it certainly seems to. It seems to do a bit more besides, unruly in its verboseness, but I won't bother trying to interpret the rest of its output. It's one reason I don't use it much. It spits out so much, it's about overwhelming. Then again, it is usually pointing out the stuff that is no longer needed in some file somewhere. Also, the longer you wait between runs, the more it spits out. It seems you can't win with that thing. LOL You can win, by running it reasonably often and actually doing something about the output. Ignore a few lines and they soon become a few more, and then a few more still... Thing is, it seems to grow faster than I can clean up. I'm scared to even run it now. It would likely take me a week to get a clean output. ROFL It's been a long time since I ran it. I may be better off to move the files, see what emerge wants to change and add stuff back. Just saying. One thing tho, having fewer stuff in those files may speed emerge up just a tiny amount. ;-) Dale :-) :-)
Re: [gentoo-user] This nite's switch to full multilib
Neil Bothwick wrote: On Sun, 05 Apr 2015 02:24:13 -0500, Dale wrote: It seems you can't win with that thing. LOL You can win, by running it reasonably often and actually doing something about the output. Ignore a few lines and they soon become a few more, and then a few more still... Thing is, it seems to grow faster than I can clean up. I'm scared to even run it now. It would likely take me a week to get a clean output. ROFL It's been a long time since I ran it. I may be better off to move the files, see what emerge wants to change and add stuff back. Just saying. I got into that situation once, you just need to bite the bullet and work through the output. It's not as bad as it looks as the same entry can cause multiple reports, so once you clean up a couple of entries the output can get significantly shorter. It's like being a teenager again, the longer you leave tidying your room, the longer it takes when your mum makes you do it :) Well, just for giggles I ran it. Ain't no way I got time to go through all that right now. Heck, it took several minutes for it to just to go through all that stuff. O_O Maybe one day. Maybe. Dale :-) :-)
Re: [gentoo-user] This nite's switch to full multilib
On Fri, 3 April 2015, at 9:30 am, Dale rdalek1...@gmail.com wrote: Slightly OT, but are there any tools for cleaning out old entries? I think this will do what you want. eix-test-obsolete Many thanks, it certainly seems to. It seems to do a bit more besides, unruly in its verboseness, but I won't bother trying to interpret the rest of its output. Stroller.
Re: [gentoo-user] This nite's switch to full multilib
Stroller wrote: On Fri, 3 April 2015, at 9:30 am, Dale rdalek1...@gmail.com wrote: Slightly OT, but are there any tools for cleaning out old entries? I think this will do what you want. eix-test-obsolete Many thanks, it certainly seems to. It seems to do a bit more besides, unruly in its verboseness, but I won't bother trying to interpret the rest of its output. Stroller. It's one reason I don't use it much. It spits out so much, it's about overwhelming. Then again, it is usually pointing out the stuff that is no longer needed in some file somewhere. Also, the longer you wait between runs, the more it spits out. It seems you can't win with that thing. LOL Dale :-) :-)
Re: [gentoo-user] This nite's switch to full multilib
On Sat, 04 Apr 2015 07:33:06 -0500, Dale wrote: eix-test-obsolete Many thanks, it certainly seems to. It seems to do a bit more besides, unruly in its verboseness, but I won't bother trying to interpret the rest of its output. It's one reason I don't use it much. It spits out so much, it's about overwhelming. Then again, it is usually pointing out the stuff that is no longer needed in some file somewhere. Also, the longer you wait between runs, the more it spits out. It seems you can't win with that thing. LOL You can win, by running it reasonably often and actually doing something about the output. Ignore a few lines and they soon become a few more, and then a few more still... -- Neil Bothwick We demand rigidly defined areas of doubt and uncertainty! pgpzr7zkJbtzh.pgp Description: OpenPGP digital signature
Re: [gentoo-user] This nite's switch to full multilib
On Sat, 4 Apr 2015 10:39:18 +0100, Stroller wrote: eix-test-obsolete Many thanks, it certainly seems to. It seems to do a bit more besides, unruly in its verboseness, but I won't bother trying to interpret the rest of its output. eix-test-obsolete is only a shell script that calls eix in test mode several times, with different options. Make a copy of the script that includes only the tests you want. -- Neil Bothwick Fer sail cheep, Windows spel chekcer, wurks grate pgpddwCi2HNoL.pgp Description: OpenPGP digital signature
Re: [gentoo-user] This nite's switch to full multilib
On Thu, 2 April 2015, at 5:24 pm, Rich Freeman ri...@gentoo.org wrote: The alternative is what I have now - a 1200 line package.keywords file that tells portage to build half the system 32-bit, when I could care less … Slightly OT, but are there any tools for cleaning out old entries? I could write a script to go through package.keywords line by line and, for packages where the entry is =package-version.1.2.3, delete those lines where a newer version of the package is now installed on the system. Has anyone done this already? Stroller.
Re: [gentoo-user] This nite's switch to full multilib
On Thu, 2 April 2015, at 4:37 pm, Grant Edwards grant.b.edwa...@gmail.com wrote: I prefer it this way. I do not want all the nice easy-to read/edit configuration stuff in /etc/portage encrypted some Windows Registry break-alike. What's bad about the Windows registry is that its proprietary file format is both poorly constructed (or, rather lacking design) and obscure, and its reputation was for brittleness was built when it was stored on FAT file systems and corrupted when Windows crashed and had to be hard rebooted. If you want to store a lot of stuff, then databases are a valid solution. If there's something wrong with sqlite or BerkeleyDB then argue against them, but don't base your objections on a strawman. Stroller.
Re: [gentoo-user] This nite's switch to full multilib
Stroller wrote: On Thu, 2 April 2015, at 5:24 pm, Rich Freeman ri...@gentoo.org wrote: The alternative is what I have now - a 1200 line package.keywords file that tells portage to build half the system 32-bit, when I could care less … Slightly OT, but are there any tools for cleaning out old entries? I could write a script to go through package.keywords line by line and, for packages where the entry is =package-version.1.2.3, delete those lines where a newer version of the package is now installed on the system. Has anyone done this already? Stroller. I think this will do what you want. eix-test-obsolete Dale :-) :-)
Re: [gentoo-user] This nite's switch to full multilib
On Fri, 3 Apr 2015 09:00:52 +0100, Stroller wrote: Slightly OT, but are there any tools for cleaning out old entries? I could write a script to go through package.keywords line by line and, for packages where the entry is =package-version.1.2.3, delete those lines where a newer version of the package is now installed on the system. eix-test-obsolete will do this, but it won't handle all cases. If foo requires libbar to have a particular USE flag and you unmerge foo, but libbar is still needed by something else, it will continue to be built with the unnecessary flag. -- Neil Bothwick - We are but packets in the internet of Life- pgpiSMnS327ic.pgp Description: OpenPGP digital signature
Re: [gentoo-user] This nite's switch to full multilib
On Fri, 3 April 2015, at 12:25 am, Mick michaelkintz...@gmail.com wrote: When people you need to communicate with on MSWindows boxes only know how to manage Skype-ware and you don't run a SIP proxy server yourself, your choices reduce somewhat. We'll have to reincarnate Alexander Graham Bell and see if he can come up with a solution. Stroller.
Re: [gentoo-user] This nite's switch to full multilib
On Wed, 1 Apr 2015 14:05:28 -0400, Rich Freeman wrote: I think we've just gotten into a mode where we automate user configuration instead of eliminating the need for it. That's a good way of looking at it. Most USE flags are not set by the user by by the profile. By selecting a particular profile you are telling portage to set up suitable defaults for, say, a KDE desktop. Portage should be able to continue to manage that situation and, if a different USE setting is required for a particular situation, and nothing in the user's own settings overrides it, portage should be able to take the appropriate action. The other way of looking at it, from this particular situation, is that maybe he USE system is being forced to take care of more than it was supposed to. Should ABI_* settings even be part of USE? -- Neil Bothwick A friend in need may turn out to be a nuisance. pgpaluJIsVL36.pgp Description: OpenPGP digital signature
Re: [gentoo-user] This nite's switch to full multilib
On Mon, Mar 30, 2015 at 10:23:21AM +0100, 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. :-) I used this opportunity to finally rid myself of Skype entirely. Nobody knows how it’s still possible to use that Microsoft infested spyware on Linux anway, and unless I install pulseaudio, it doesn’t give me any more features than Kopete already does. Once I did emerge -C skype, there even weren’t any blockers left or remerges with x32 abi¹. Packages to install for -uD world went from 117 to 41. So good riddance. ¹ That is on my small laptop. My big desktop has Wine installed, let’s see what it says when I’m back home in two days. -- Gruß | Greetings | Qapla’ Please do not share anything from, with or about me on any social network. Seize the carp. signature.asc Description: Digital signature
Re: [gentoo-user] This nite's switch to full multilib
On Fri, Apr 03, 2015 at 12:40:20AM +0200, me, myself and I wrote: I used this opportunity to finally rid myself of Skype entirely. Nobody knows how it’s still possible to use that Microsoft infested spyware on Linux anway, how it’s possible → how long it’s still possible -- Gruß | Greetings | Qapla’ Please do not share anything from, with or about me on any social network. Never trust an atom... they make up everything! signature.asc Description: Digital signature
Re: [gentoo-user] This nite's switch to full multilib
On Friday 03 Apr 2015 00:08:53 Frank Steinmetzger wrote: On Fri, Apr 03, 2015 at 12:40:20AM +0200, me, myself and I wrote: I used this opportunity to finally rid myself of Skype entirely. Nobody knows how it’s still possible to use that Microsoft infested spyware on Linux anway, how it’s possible → how long it’s still possible When people you need to communicate with on MSWindows boxes only know how to manage Skype-ware and you don't run a SIP proxy server yourself, your choices reduce somewhat. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] This nite's switch to full multilib
On Wed, 1 Apr 2015 14:05:28 -0400 Rich Freeman ri...@gentoo.org wrote: On Wed, Apr 1, 2015 at 1:50 PM, Róbert Čerňanský ope...@tightmail.com wrote: On Mon, 30 Mar 2015 11:31:15 +0100 Neil Bothwick n...@digimed.co.uk wrote: 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. With --pretend and --ask options you would still be in charge. Execute 'emerge -pv foo', if you do not like the changes then tweak USE settings in package.use. I would not feel any less in control if I could see changes that portage wants to do and could force my USE settings in package.use. Honestly, I tend to agree with this approach. Imagine if when you typed emerge kde-meta the emerge program told you that you need to add the following 400 lines to your package installation list. Then we create a install-list-cleanup program that looks at your world file and determines what stuff you have in your package installation list that aren't needed any longer. Very good analogy. Except that for current USE flag situation we do not and even can not provide such install-list-cleanup program. There is no way to tell whether an entry in package.use is a user choice or it is there just to satisfy some dependency. Therefore no program can tell if it can be cleaned or not. Which is another manifestation why current approach is fundamentally wrong. When it comes to what packages are installed the design is to have the user stick the stuff they really care about in the world file and let the PM figure out how to make it happen. You can override masks in config files, but the general intent is that you don't have to do this most of the time. Why not make USE flags work the same way? Why can't emerge steam figure out that half the system needs to be rebuilt with 32-bit support, and then later emerge --depclean steam figures out that half the system can be rebuilt without 32-bit support? You could still specify global or package.use settings when you have specific preferences, of course. However, you wouldn't have to do that just to satisfy dependencies unless there is a blocker that portage can't figure out itself. That is also analogous to what happens when virtuals today - sometimes you have to manually uninstall/install something to get portage past a block, and maybe that will be needed with USE flags too. I think we've just gotten into a mode where we automate user configuration instead of eliminating the need for it. -- Róbert Čerňanský E-mail: ope...@tightmail.com Jabber: h...@jabber.sk
Re: [gentoo-user] This nite's switch to full multilib
On Mon, 30 Mar 2015 11:31:15 +0100 Neil Bothwick n...@digimed.co.uk wrote: 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. With --pretend and --ask options you would still be in charge. Execute 'emerge -pv foo', if you do not like the changes then tweak USE settings in package.use. I would not feel any less in control if I could see changes that portage wants to do and could force my USE settings in package.use. Robert -- Róbert Čerňanský E-mail: ope...@tightmail.com Jabber: h...@jabber.sk
Re: [gentoo-user] This nite's switch to full multilib
On Wed, Apr 1, 2015 at 1:50 PM, Róbert Čerňanský ope...@tightmail.com wrote: On Mon, 30 Mar 2015 11:31:15 +0100 Neil Bothwick n...@digimed.co.uk wrote: 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. With --pretend and --ask options you would still be in charge. Execute 'emerge -pv foo', if you do not like the changes then tweak USE settings in package.use. I would not feel any less in control if I could see changes that portage wants to do and could force my USE settings in package.use. Honestly, I tend to agree with this approach. Imagine if when you typed emerge kde-meta the emerge program told you that you need to add the following 400 lines to your package installation list. Then we create a install-list-cleanup program that looks at your world file and determines what stuff you have in your package installation list that aren't needed any longer. When it comes to what packages are installed the design is to have the user stick the stuff they really care about in the world file and let the PM figure out how to make it happen. You can override masks in config files, but the general intent is that you don't have to do this most of the time. Why not make USE flags work the same way? Why can't emerge steam figure out that half the system needs to be rebuilt with 32-bit support, and then later emerge --depclean steam figures out that half the system can be rebuilt without 32-bit support? You could still specify global or package.use settings when you have specific preferences, of course. However, you wouldn't have to do that just to satisfy dependencies unless there is a blocker that portage can't figure out itself. That is also analogous to what happens when virtuals today - sometimes you have to manually uninstall/install something to get portage past a block, and maybe that will be needed with USE flags too. I think we've just gotten into a mode where we automate user configuration instead of eliminating the need for it. -- Rich
Re: [gentoo-user] This nite's switch to full multilib
On Mon, 30 Mar 2015 19:46:39 -0500, Dale wrote: 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. grep :) -- Neil Bothwick If at first you don't succeed, you'll get a lot of free advice from folks who didn't succeed either. pgpGfrpB6Vt0T.pgp Description: OpenPGP digital signature
Re: [gentoo-user] This nite's switch to full multilib
On 31/03/2015 02:46, Dale wrote: 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. ;-) It's called grep -- Alan McKinnon alan.mckin...@gmail.com
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.
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] 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] 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] 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.
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] 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] 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] 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 :-) :-)
Re: [gentoo-user] This nite's switch to full multilib
On Sunday 29 Mar 2015 16:20:31 Peter Humphrey wrote: On Sunday 29 March 2015 17:03:50 waben...@gmail.com wrote: I'm using grub so I had to add these two lines to packages.use sys-libs/ncurses abi_x86_32 sys-libs/gpm abi_x86_32 I don't know how grub is connected, but I had to add those two as well. and after that doing the following commands: emerge -av -C 'app-emulation/emul-linux-x86*' emerge @preserved-rebuild Both unnecessary. Portage removes emul-linux-x86 itself in a world update and leaves everything tickety-boo. At least, it did here. If definitely did NOT play nicely here. :-( I have some hard blocks with qt: [blocks B ] dev-qt/qtdeclarative-4.8.6:4 (dev- qt/qtdeclarative-4.8.6:4 is blocking dev-qt/qtchooser-0_p20150102) [blocks B ] dev-qt/qttranslations:4 (dev-qt/qttranslations:4 is blocking dev-qt/qtcore-4.8.5-r2) [blocks B ] dev-qt/qtcore-4.8.6:4 (dev-qt/qtcore-4.8.6:4 is blocking dev-qt/qtchooser-0_p20150102) [blocks B ] dev-qt/qtscript-4.8.6:4 (dev-qt/qtscript-4.8.6:4 is blocking dev-qt/qtchooser-0_p20150102) [blocks B ] dev-qt/qtopengl-4.8.6:4 (dev-qt/qtopengl-4.8.6:4 is blocking dev-qt/qtchooser-0_p20150102) [blocks B ] dev-qt/designer-4.8.6:4 (dev-qt/designer-4.8.6:4 is blocking dev-qt/qtchooser-0_p20150102) [blocks B ] dev-qt/qttest-4.8.6:4 (dev-qt/qttest-4.8.6:4 is blocking dev-qt/qtchooser-0_p20150102) [blocks B ] dev-qt/qtxmlpatterns-4.8.6:4 (dev- qt/qtxmlpatterns-4.8.6:4 is blocking dev-qt/qtchooser-0_p20150102) [blocks B ] dev-qt/qtsql-4.8.6:4 (dev-qt/qtsql-4.8.6:4 is blocking dev-qt/qtchooser-0_p20150102) [blocks B ] dev-qt/qtsvg-4.8.6:4 (dev-qt/qtsvg-4.8.6:4 is blocking dev-qt/qtchooser-0_p20150102) [blocks B ] dev-qt/qtgui-4.8.6:4 (dev-qt/qtgui-4.8.6:4 is blocking dev-qt/qtchooser-0_p20150102) [blocks B ] dev-qt/qt3support-4.8.6:4 (dev-qt/qt3support-4.8.6:4 is blocking dev-qt/qtchooser-0_p20150102) !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: dev-qt/qtcore:4 (dev-qt/qtcore-4.8.5-r2:4/4::gentoo, installed) pulled in by ~dev-qt/qtcore-4.8.5[aqua=,debug=] required by (dev- qt/qtsvg-4.8.5:4/4::gentoo, ebuild scheduled for merge) ^ ^ (and 9 more with the same problem) (dev-qt/qtcore-4.8.6-r1:4/4::gentoo, ebuild scheduled for merge) pulled in by dev-qt/qtcore:4[abi_x86_32(-)] required by (net-im/skype-4.3.0.37- r5:0/0::gentoo, ebuild scheduled for merge) ~dev- qt/qtcore-4.8.6[aqua=,debug=,abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?] required by (dev-qt/qtscript-4.8.6-r1:4/4::gentoo, ebuild scheduled for merge) ^ ^ (and 7 more with the same problems) dev-qt/qtgui:4 (dev-qt/qtgui-4.8.5-r4:4/4::gentoo, installed) pulled in by ~dev-qt/qtgui-4.8.5[accessibility=,aqua=,debug=,qt3support=] required by (dev-qt/qtdeclarative-4.8.5:4/4::gentoo, ebuild scheduled for merge) ^ ^ (and 5 more with the same problem) (dev-qt/qtgui-4.8.6-r2:4/4::gentoo, ebuild scheduled for merge) pulled in by dev-qt/qtgui:4[accessibility,abi_x86_32(-)] required by (net- im/skype-4.3.0.37-r5:0/0::gentoo, ebuild scheduled for merge) ~dev- qt/qtgui-4.8.6[aqua=,debug=,abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?] required by (dev-qt/qtwebkit-4.8.6-r1:4/4::gentoo, ebuild scheduled for merge) ^ ^ (and 2 more with the same problems) dev-qt/qtxmlpatterns:4
Re: [gentoo-user] This nite's switch to full multilib
On Sunday 29 Mar 2015 17:08:32 Yanestra wrote: On 03/29/2015 05:03 PM, waben...@gmail.com wrote: In most of the cases, Portage will be able to deliver correct suggestions for that when using the --autounmask feature. The first thing what happens here is that kde wants to upgrade because qtchooser's mask miraculously becomes ignored. And qtchooser itself doesn't install together with the libraries it pretends to control because there masses of conflicts, no matter what combination (qt4, qt5) I try. It has taken months of experimentation to get all the software to work which I need. It was tricky, because in many places only particular versions do. All that dissolves in a giant pile of rubbish... Regards, Yanestra 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? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] This nite's switch to full multilib
On 03/29/2015 05:03 PM, waben...@gmail.com wrote: In most of the cases, Portage will be able to deliver correct suggestions for that when using the --autounmask feature. The first thing what happens here is that kde wants to upgrade because qtchooser's mask miraculously becomes ignored. And qtchooser itself doesn't install together with the libraries it pretends to control because there masses of conflicts, no matter what combination (qt4, qt5) I try. It has taken months of experimentation to get all the software to work which I need. It was tricky, because in many places only particular versions do. All that dissolves in a giant pile of rubbish... Regards, Yanestra
Re: [gentoo-user] This nite's switch to full multilib
Yanestra wysi...@seismic.de wrote: Hi, just one question: I had a working system yesterday afternoon, but after the latest eix-sync my mask settings get ignored and the whole system is about to be updated. I have read the news message, and I am baffled. What can I do to keep my working system as it is? I'm using grub so I had to add these two lines to packages.use sys-libs/ncurses abi_x86_32 sys-libs/gpm abi_x86_32 and after that doing the following commands: emerge -av -C 'app-emulation/emul-linux-x86*' emerge @preserved-rebuild That was all I had to do and it worked for me without problems. If you have installed more packages depending on 32bit support you probably need more entries in packages.use (emerge should tell you what packages that are). The news item said: In most of the cases, Portage will be able to deliver correct suggestions for that when using the --autounmask feature. However, some users may prefer setting ABI_X86 globally to enable 32-bit libraries in all packages that support building them. This can be done using the following package.use entry: */* abi_x86_32 However I hadn't tested this as I have no need for it. I think the best insurance against a broken system is a complete backup. I'm doing this every week anyway but always before a potential risky update procedure. -- Regards wabe
Re: [gentoo-user] This nite's switch to full multilib
On Sunday 29 March 2015 17:03:50 waben...@gmail.com wrote: I'm using grub so I had to add these two lines to packages.use sys-libs/ncurses abi_x86_32 sys-libs/gpm abi_x86_32 I don't know how grub is connected, but I had to add those two as well. and after that doing the following commands: emerge -av -C 'app-emulation/emul-linux-x86*' emerge @preserved-rebuild Both unnecessary. Portage removes emul-linux-x86 itself in a world update and leaves everything tickety-boo. At least, it did here. -- Rgds Peter.
Re: [gentoo-user] This nite's switch to full multilib
On Sun, Mar 29, 2015 at 5:58 AM, Yanestra wysi...@seismic.de wrote: just one question: I had a working system yesterday afternoon, but after the latest eix-sync my mask settings get ignored and the whole system is about to be updated. I have read the news message, and I am baffled. What can I do to keep my working system as it is? If you want more specific instructions than provided by the news item, you'll need to provide more specific details about what is happening to you and what you want to have happen. If your goal is to keep running on the old emul-linux-x86-* packages, then you'll have to maintain them and anything that uses them in your own overlay, which will be a lot of work. Support for them in-tree is being dropped. If you just want to keep your system working using x86 support in the native packages then you probably need to let emerge update your config files to add about 100 use flag accepts. You might also have a package or two which stubbornly refused to do the right thing (wine had the wrong defaults in the tree, and it looks like android-sdk-update-manager needs some love as well which I'll take care of once I confirm how it should act). There are probably other packages in the tree with problems. -- Rich
Re: [gentoo-user] This nite's switch to full multilib
Mick michaelkintz...@gmail.com wrote: On Sunday 29 Mar 2015 17:08:32 Yanestra wrote: On 03/29/2015 05:03 PM, waben...@gmail.com wrote: In most of the cases, Portage will be able to deliver correct suggestions for that when using the --autounmask feature. The first thing what happens here is that kde wants to upgrade because qtchooser's mask miraculously becomes ignored. And qtchooser itself doesn't install together with the libraries it pretends to control because there masses of conflicts, no matter what combination (qt4, qt5) I try. It has taken months of experimentation to get all the software to work which I need. It was tricky, because in many places only particular versions do. All that dissolves in a giant pile of rubbish... Regards, Yanestra 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. -- Regards wabe
Re: [gentoo-user] This nite's switch to full multilib
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. -- Regards wabe 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 -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] This nite's switch to full multilib
Mick michaelkintz...@gmail.com 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. -- Regards wabe 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 dev-qt/qtchooser isn't installed on my system. Some days ago I wanna try out lxqt, but the attempted installation of qt5 (and therefore qtchooser) gives me so much blockers that I decided to wait until the whole thing hits the stable tree. -- Regards wabe
Re: [gentoo-user] This nite's switch to full multilib
On 29/03/2015 19:53, Stefan G. Weichinger wrote: On 29.03.2015 19:30, Mick wrote: I went through that exercise about a month ago, and I needed this: /etc/portage/package.use/abi_x86_32: =dev-qt/qtwebkit-4.8.6-r1:4 abi_x86_32 =dev-qt/qtgui-4.8.6-r1:4 abi_x86_32 =dev-qt/qtdbus-4.8.6-r1:4 abi_x86_32 =dev-qt/qtscript-4.8.6-r1:4 abi_x86_32 =dev-qt/qtcore-4.8.6-r1:4 abi_x86_32 =dev-qt/qtxmlpatterns-4.8.6-r1:4 abi_x86_32 =dev-qt/qt3support-4.8.6-r1 abi_x86_32 =dev-qt/qtsql-4.8.6-r1:4 abi_x86_32 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. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] This nite's switch to full multilib
On 29/03/2015 19:30, Mick wrote: On Sunday 29 Mar 2015 18:07:50 Alan McKinnon wrote: On 29/03/2015 18:21, Mick wrote: On Sunday 29 Mar 2015 17:08:32 Yanestra wrote: On 03/29/2015 05:03 PM, waben...@gmail.com wrote: In most of the cases, Portage will be able to deliver correct suggestions for that when using the --autounmask feature. The first thing what happens here is that kde wants to upgrade because qtchooser's mask miraculously becomes ignored. And qtchooser itself doesn't install together with the libraries it pretends to control because there masses of conflicts, no matter what combination (qt4, qt5) I try. It has taken months of experimentation to get all the software to work which I need. It was tricky, because in many places only particular versions do. All that dissolves in a giant pile of rubbish... Regards, Yanestra 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 went through that exercise about a month ago, and I needed this: /etc/portage/package.use/abi_x86_32: =dev-qt/qtwebkit-4.8.6-r1:4 abi_x86_32 =dev-qt/qtgui-4.8.6-r1:4 abi_x86_32 =dev-qt/qtdbus-4.8.6-r1:4 abi_x86_32 =dev-qt/qtscript-4.8.6-r1:4 abi_x86_32 =dev-qt/qtcore-4.8.6-r1:4 abi_x86_32 =dev-qt/qtxmlpatterns-4.8.6-r1:4 abi_x86_32 =dev-qt/qt3support-4.8.6-r1 abi_x86_32 =dev-qt/qtsql-4.8.6-r1:4 abi_x86_32 Apparently I have some 32-bit app that uses Qt, and wine is also in the mix. I imagine the number of possibilities and complications about this can be huge and many folks will need to make their own unique tweaks to package.use, and it'll take a while to shake out all the cruft in the tree Thanks Alan, after keywording: =dev-qt/qtopengl-4.8.6-r1 ~amd64 =dev-qt/qtscript-4.8.6-r1 ~amd64 =dev-qt/qtsql-4.8.6-r1 ~amd64 =dev-qt/qtsvg-4.8.6-r1 ~amd64 =dev-qt/qttest-4.8.6-r1 ~amd64 =dev-qt/qttranslations-4.8.6-r1 ~amd64 =dev-qt/qtwebkit-4.8.6-r1 ~amd64 =dev-qt/qtxmlpatterns-4.8.6-r1 ~amd64 and adding abi_x86_32 on many packages that emerge asked me to, I am now able to progress with 'emerge -a @preserved-rebuild'. Thanks Mick. 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. 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 -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] This nite's switch to full multilib
On 29/03/2015 18:21, Mick wrote: On Sunday 29 Mar 2015 17:08:32 Yanestra wrote: On 03/29/2015 05:03 PM, waben...@gmail.com wrote: In most of the cases, Portage will be able to deliver correct suggestions for that when using the --autounmask feature. The first thing what happens here is that kde wants to upgrade because qtchooser's mask miraculously becomes ignored. And qtchooser itself doesn't install together with the libraries it pretends to control because there masses of conflicts, no matter what combination (qt4, qt5) I try. It has taken months of experimentation to get all the software to work which I need. It was tricky, because in many places only particular versions do. All that dissolves in a giant pile of rubbish... Regards, Yanestra 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 went through that exercise about a month ago, and I needed this: /etc/portage/package.use/abi_x86_32: =dev-qt/qtwebkit-4.8.6-r1:4 abi_x86_32 =dev-qt/qtgui-4.8.6-r1:4 abi_x86_32 =dev-qt/qtdbus-4.8.6-r1:4 abi_x86_32 =dev-qt/qtscript-4.8.6-r1:4 abi_x86_32 =dev-qt/qtcore-4.8.6-r1:4 abi_x86_32 =dev-qt/qtxmlpatterns-4.8.6-r1:4 abi_x86_32 =dev-qt/qt3support-4.8.6-r1 abi_x86_32 =dev-qt/qtsql-4.8.6-r1:4 abi_x86_32 Apparently I have some 32-bit app that uses Qt, and wine is also in the mix. I imagine the number of possibilities and complications about this can be huge and many folks will need to make their own unique tweaks to package.use, and it'll take a while to shake out all the cruft in the tree -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] This nite's switch to full multilib
On Sunday 29 Mar 2015 18:07:50 Alan McKinnon wrote: On 29/03/2015 18:21, Mick wrote: On Sunday 29 Mar 2015 17:08:32 Yanestra wrote: On 03/29/2015 05:03 PM, waben...@gmail.com wrote: In most of the cases, Portage will be able to deliver correct suggestions for that when using the --autounmask feature. The first thing what happens here is that kde wants to upgrade because qtchooser's mask miraculously becomes ignored. And qtchooser itself doesn't install together with the libraries it pretends to control because there masses of conflicts, no matter what combination (qt4, qt5) I try. It has taken months of experimentation to get all the software to work which I need. It was tricky, because in many places only particular versions do. All that dissolves in a giant pile of rubbish... Regards, Yanestra 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 went through that exercise about a month ago, and I needed this: /etc/portage/package.use/abi_x86_32: =dev-qt/qtwebkit-4.8.6-r1:4 abi_x86_32 =dev-qt/qtgui-4.8.6-r1:4 abi_x86_32 =dev-qt/qtdbus-4.8.6-r1:4 abi_x86_32 =dev-qt/qtscript-4.8.6-r1:4 abi_x86_32 =dev-qt/qtcore-4.8.6-r1:4 abi_x86_32 =dev-qt/qtxmlpatterns-4.8.6-r1:4 abi_x86_32 =dev-qt/qt3support-4.8.6-r1 abi_x86_32 =dev-qt/qtsql-4.8.6-r1:4 abi_x86_32 Apparently I have some 32-bit app that uses Qt, and wine is also in the mix. I imagine the number of possibilities and complications about this can be huge and many folks will need to make their own unique tweaks to package.use, and it'll take a while to shake out all the cruft in the tree Thanks Alan, after keywording: =dev-qt/qtopengl-4.8.6-r1 ~amd64 =dev-qt/qtscript-4.8.6-r1 ~amd64 =dev-qt/qtsql-4.8.6-r1 ~amd64 =dev-qt/qtsvg-4.8.6-r1 ~amd64 =dev-qt/qttest-4.8.6-r1 ~amd64 =dev-qt/qttranslations-4.8.6-r1 ~amd64 =dev-qt/qtwebkit-4.8.6-r1 ~amd64 =dev-qt/qtxmlpatterns-4.8.6-r1 ~amd64 and adding abi_x86_32 on many packages that emerge asked me to, I am now able to progress with 'emerge -a @preserved-rebuild'. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] This nite's switch to full multilib
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 29.03.2015 19:30, Mick wrote: I went through that exercise about a month ago, and I needed this: /etc/portage/package.use/abi_x86_32: =dev-qt/qtwebkit-4.8.6-r1:4 abi_x86_32 =dev-qt/qtgui-4.8.6-r1:4 abi_x86_32 =dev-qt/qtdbus-4.8.6-r1:4 abi_x86_32 =dev-qt/qtscript-4.8.6-r1:4 abi_x86_32 =dev-qt/qtcore-4.8.6-r1:4 abi_x86_32 =dev-qt/qtxmlpatterns-4.8.6-r1:4 abi_x86_32 =dev-qt/qt3support-4.8.6-r1 abi_x86_32 =dev-qt/qtsql-4.8.6-r1:4 abi_x86_32 I have to do that for 195 ebuilds here and really wonder if that is correct in the end -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJVGDwOAAoJEClcuD1V0PzmeWIP/3dMSW72SLuUGHdI538zT+Pd LePwUP4JBlee5zfzwVdCtjFqeY25LThwOHf4PYRtvAVAt9HD/x3ZQFkjTnCffHt2 o9by5eqUyJ7omh5sFIhcBmlwBF2mMCFYWWH9n3X7rJT9W6nvHYL9jz6GxZIANtAE 35qmLom+rl7MBDd3kweUnVx1jQ2jw3NIk2oxlgQv6emyoaQ2v/1WxKWI8xtigbsH 4zlLBGJBtsayVeRyx+nraVa4IyALW+mhFSXoSEzAKQTzlJskn5FhpM0RAomBJomK wjrhqpOYAPQTgkZ5wtqnkIcEvlE6BOx6vlu6Goh4pSmfFkanWSA8uC+LJVKuyklB RvDmMuAs+NMxDAPnHeVX3moN/4KCGB0avyHRNAceFgVkWqo+cDjyCPw33YfPWd2i 96q4NPxrElQkPyF2FB9hT4zB5sF/66psJe17nrScUiYF4nUYMLTlRQ4SJpdC7wNi CQZ5mcBN7kRxrQWEx52AkKi0BTt6O0Aayhn5wgKJqDln9tNql7fLvBXNcxCwl1Rq zc242XzyE4m7hGVXLD3MiXgIeH62nurlyAqKzEuFYsO0BDA63bSwuP1lLJygGmkq EhvG7fDwEK2oCI+cj2jmSMhP4Ij1n0K2nFbDP6y/j9s9wAm/xKJc0thG1eE3+4Xs f3WRliv7KOfAaE9YcRGV =Wpyd -END PGP SIGNATURE-
[gentoo-user] This nite's switch to full multilib
Hi, just one question: I had a working system yesterday afternoon, but after the latest eix-sync my mask settings get ignored and the whole system is about to be updated. I have read the news message, and I am baffled. What can I do to keep my working system as it is? Regards, A Humble Usertm Yanestra
Re: [gentoo-user] This nite's switch to full multilib
On 03/30/2015 12:10 AM, Stefan G. Weichinger wrote: 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. Stefan Yes, actually it can be time consuming to have - and keep - a running Gentoo system. To me, it's something like a life insurance having btrfs on my system disk. So I can step back when I discover something important stopped working without me having noticed immediately.
Re: [gentoo-user] This nite's switch to full multilib
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. Stefan
Re: [gentoo-user] This nite's switch to full multilib
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 -- Alan McKinnon alan.mckin...@gmail.com
