Re: [kde-linux] Konqueror KDE-4.8 BRANCH
- Date: Tue, 17 Jan 2012 14:14:16 +0000 (UTC)
- From: Duncan <1i5t5.duncan@xxxxxxx>
- Subject: Re: [kde-linux] Konqueror KDE-4.8 BRANCH
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:
> 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
This message is from the kde-linux mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde-linux.
More info: http://www.kde.org/faq.html.