[kde-linux] Konqueror KDE-4.8 BRANCH

[Duncan]

Dale posted on Tue, 17 Jan 2012 01:16:17 -0600 as excerpted:

> Well, I'm still on Gentoo here.  Of course with the recent talk about
> init thingys, that could change.

Init thingys... not quite that, but FWIW, over this last weekend, I 
unmasked, built, installed, and came upto speed on grub2.  Being on 
gentoo/~amd64/no-multilib, I've had grub-static installed.  It's nice to 
be able to build the proper grub again, and not have to deal with the pre-
build package.  Grub2 also handles md/raid (and I read lvm2 as well, but 
I won't have it on my system as I don't have or want an initrd) FAR 
better, and it makes use of the (unformatted) GPT-BIOS-boot partition so 
there's way less complications with fitting it in the dead space between 
the MBR and the first partition, or with blocklists... as long as you're 
running GPT at least.  I updated to that (using gptfdisk aka gdisk) some 
time ago, doing my research and keeping a BIOS boot partition available, 
for use when the time came, and with the grub2 upgrade, the time finally 
came. =:^)  So further grub2 updates will be a walk in the park both 
compared to this initial upgrade from grub-legacy, AND to grub-legacy 
upgrades, since md/raid "just works" now, thanks to the modular design 
and existence of the raid modules.  No more fiddling with hacks to make 
grub-legacy work with raid, no more worrying about the install to one 
disk referencing the /boot on another, thus breaking if either one of the 
disks dies, because it's so hard to be sure that grub-legacy is 
translating the disk references the same way the BIOS and Linux do, etc. 
=:^)

The biggest problem I had was that the thing is designed to use a bunch 
of config files in /etc/grub.d/ and a grub-mkconfig program to update the 
config, but the grub mkconfig program (in gentoo, as with all the grub2 
utilities, for slotting purposes it's grub2-mkconfig) is a shell-script 
that mostly runs quite fast, **EXCEPT** that it calls an elf-binary grub2-
probe repeatedly, some 20-plus times on my system, AND THOSE CALLOUTS RUN 
9-10 SECONDS EACH!!  As a result, this grub2-mkconfig, which is supposed 
to be run after every kernel update, takes well over 3 minutes (closer to 
four than 3) to run, with the calls to grub2-probe taking well over 90% 
of that time!

That's *ENTIRELY* unsatisfactory, as that's roughly equal to my kernel 
build and install time with grub-legacy, so grub2 would pretty much 
double my kernel build and install time!  This for someone that regularly 
runs linus mainline live-git kernels and who thus routinely rebuilds and 
installs a new kernel several times a week, and up to several times an 
hour when I'm bisecting a new kernel bug!

So I learned the new grub config language (similar to the old one but 
much more powerful, as I said handling md/raid, lvm2, etc, all on its own 
now, with loadable modules) well enough to write my own grub.cfg and a 
couple additional menuentry-loadable subconfig files, kerns.cfg, with a 
list of a bunch of backup kernels load entries, etc, and utils.cfg, with 
entries to reboot, halt, and or load any of my main md/raid partitions 
into a variable so I can easily access them by filesystem label... 
directly from grub, so I don't even have to fully boot to check the 
details in some config file or whatever, and I can load images and fonts 
for grub themes directly from the main system if desired, no longer do 
they need to be in /boot.

Then I deleted grub2-mkconfig and the corresponding config files, and 
setup install-masks so this bit of grub2 wouldn't install again and 
reinstalled from the binpkg, to make sure those programs weren't even 
there, so they couldn't be called accidentally by something, thus ruining 
my hand-configured grub.cfg file!

It was quite a weekend, learning all that stuff, but it's done now, 
tested to boot the system from any of the four drives alone, and up and 
running. =:^)  Now I just have to catch up on all the Linux and world 
news feeds, lists like this, etc, that I hadn't been worrying about over 
the weekend as I had bigger fish to fry, that being grub2!

As for the init stuff you reference, I guess I'm sitting pretty in that 
regard, since I keep the entire installed system on a single 4.75-gig 
root (on a 5-gig md/raid with a separate /usr/local partition on the same 
md/raid), with /home and /var/log and /usr/local and some other stuff on 
other partitions, but /usr/lib(64), etc, on the main rootfs image, so I 
don't have to worry about those changes requiring an initrd.  (That makes 
it real simple to setup a backup rootfs partition of exactly the same 
4.75-gig size, along with another quarter-gig /usr/local partition in 
another 5-gig md/raid, that I can set mdX= to assemble it from the kernel 
command line and root= to boot to as an emergency backup if I screw up my 
main installation, should I need it.)

That it would prevent my having to worry about the coming move of /bin, 
/lib(64) and /sbin to combine with the respective /usr versions, wasn't a 
benefit I foresaw when I setup my scheme, but I'll take it, anyway! =:^)

> I do have this installed tho:
> 
> kde-base/konq-plugins-4.7.4
> 
> I may not have something enabled or something tho.  I mostly mentioned
> because another user posted they couldn't find it either.  I posted so
> that he knows it is not just him.  Of course, I am a bit curious since
> you have it and I don't.  We both run Gentoo.  I also have the .so file
> you posted above too.  Weird, just like me.  lol

Well, if you have that package and *.so file, I don't know what to say.  
You could try moving your user's kde config out of the way and/or setting 
up a new user to test with, and see if it's there by default, thus 
pinning the blame on some bit of your user config.  And of course on 
Gentoo there's the revdep-rebuild thing to worry about but based on 
previous threads, I'm reasonably confident that you know about that and 
haven't forgotten to run it, so that can't be the problem.

I'd suspect it's in your user config, tho, and that running a test with a 
fresh config will load the plugin.  If it does, you can of course bisect 
the problem in your user config... if you care enough about it to do so.

FWIW, AFAIK I've had konq-plugins and that tools entry since the kde3 era 
here, I believe.  I don't use konqueror that much, but I would miss 
various addons (like this one) if they suddenly disappeared or quit 
working here, I think, even if it did take me a month or two to notice.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman