Re: [gentoo-user] Qt blocking @world update
Alan McKinnon writes: > On 05/11/2013 15:37, Alex Schuster wrote: [kde-misc/fsrunner pulls in QT 4.8.4] > > This does not make any sense, does it? > > Actually, it does make sense, in a weird kind of way > > kid3 and fsrunner are not part of KDE proper (i.e. they are not shipped > in the huge KDE tarballs). So they may be inconsistent with the main > release due to no QA checks beyond what the dev does. And I doubt the > gentoo KDE team checks such packages before updating ebuilds. But what exactly is it that pulls in the older Qt? > I would use this approach: > > Remove from world every KDE package that is not in kde-base (quickpkg > first to make restores easier), then update world and do a depclean. > Chances are very good it will complete cleanly. Well, I was at this point already, after excluding fsrunner and kid3. > Then emerge all those KDE packages back in using the -t option to emerge > and see what is causing issues. emerge fsrunner would happily just install fsrunner, but emerge -Dpu fsrunner again wants to downgrade Qt to 4.8.4. The same goes for kid3. No big deal, I don't really need those. > I think the odds are very good you will find an out-of-sync package that > directly DEPENDS on some old version of Qt (or something equally silly). > That package might even already be in the emerge output, but buried in > the voluminous output portage gives these days But emerge -uD @world no longer complains. Of course I have other problems now... but I will start a new thread for that. Alex
[gentoo-user] Re: no stinkin bootloaders!
Davide Carnovale gmail.com> writes: > Hi James, > I banged my head a little against this problem as my new laptop has no option to turn the secure uefi off. > I had no success with gentoo, but I was able to install fedora 18. Although when recompiling the kernel to use my security key, I never managed to boot it. I suspect the problem is with signing of the kernel... The guide you posted seems a lot more accurate than the one I used to follow and has pointer to other in depth articles. I think you might have a not too hard time in building your bootable kernel if you follow it. I'll give it a spin myself when I'll have some free time. > > Good luck and thanks for sharing! > D Hello David, You might be interested to install Pentoo on that UEFI lappy: http://code.google.com/p/pentoo/wiki/UEFI Pentoo, is a hardened gentoo targeted with all sorts of tools to keep your network secure, and have fun with those interlopers. Pentoo is very cool and has an old_fashion easy to install iso: pentoo-amd64-2013.0_RC1.9.iso Pentoo installation has worked best for me when I use another tool to setup the drive(s). pentoo-installer is basic and mostly works (I.E. pre --> EFI/GPT/UUID). At the end, you get a gentoo system with the hardened tool chain, a hardened kernel and possible luks: http://hardenedgentoo.blogspot.com/2010/02/installing-pentoo-on-hard-drive-with.html All in all, I'm just learning bout these newest offerings. Later, I hope to successfully put pentoo on top of ZFS as my ultimate goal. Lots of work and lots of experimenting! Good Hunting, and post back what you learn. hth, James
Re: [gentoo-user] no stinkin bootloaders!
Hi James, I banged my head a little against this problem as my new laptop has no option to turn the secure uefi off. I had no success with gentoo, but I was able to install fedora 18. Although when recompiling the kernel to use my security key, I never managed to boot it. I suspect the problem is with signing of the kernel... The guide you posted seems a lot more accurate than the one I used to follow and has pointer to other in depth articles. I think you might have a not too hard time in building your bootable kernel if you follow it. I'll give it a spin myself when I'll have some free time. Good luck and thanks for sharing! D Il 09/nov/2013 04:22 "James" ha scritto: > Here is a very interesting read, posted by GKH: > > http://kroah.com/log/blog/2013/09/02/booting-a-self-signed-linux-kernel/ > > > Anyone tried this yet? > > curiously, > James > > > >
Re: [gentoo-user] Re: resolving blocked packages [media-video/ffmpeg-1.2:0]
On Tuesday 05 Nov 2013 14:40:46 Bruce Hill wrote: > On Tue, Nov 05, 2013 at 06:15:56AM +, Nuno J. Silva (aka njsg) wrote: > > >> On Monday 04 Nov 2013 19:51:32 Alexander Kapshuk wrote: > > >> > On 11/03/2013 02:27 AM, Daniel Campbell wrote: > > >> > > For starters, you should probably merge package.keywords into > > >> > > package.accept_keywords; the latter is the "new" standard name, > > >> > > though Portage will likely support the old names for a while. > > >> > > Just a heads-up on that. > > >> > > > >> > Thanks for a heads-up. I did as you suggested. > > >> > > >> Is there going to be a portage news article on this, or did I miss it? > > > > > > It wasn't two or three years ago... > > > > > > mingdao@server ~ $ eselect news read 5 > > > 2012-09-09-make.conf-and-make.profile-move > > > > > > Title make.conf and make.profile move > > > AuthorJorge Manuel B. S. Vicetto > > >Posted2012-09-09 > > > Revision 1 > > > > > > Starting next week, new stages will have make.conf and make.profile > > > moved from /etc to /etc/portage. This is a change in the installation > > > defaults, that will only affect new installs so it doesn't affect > > > current systems. > > > > > > Current users don't need to do anything. But if you want to follow the > > > preferred location, you may want to take the chance to move the files > > > in your system(s) to the new location. > > > > But that's about make.conf, not about package.keywords. > > mingdao blushes Actually it was in a portage news article, but not an article about portage or /etc/portage/package.* changing its naming convention. It was mentioned in passing in the latest news article about python-exec. I carry on regardless, perhaps foolishly, on the assumption that when stable portage changes its configuration file structure someone will let us know. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
