Alex Schuster posted on Wed, 15 Oct 2014 01:13:42 +0200 as excerpted:
> Finally! The notes are back.
>
> I wrote:
>
>> Some while ago already, KDE killed all my knotes. I think it was when
>> 4.13.0 came out, and some migrator tried to migrate the existing notes.
>> Well, it failed here. Now, I really want to have them back.
>
> I finally fixed this. The reason was that my KDE was built
> inconsistently.
>
> I'm a Gentoo user, so all is built from source. Due to lack of time I
> did not update my system properly in a while, and did not notice that
> not all of KDE's packages were up to date. I was missing the kdepim USE
> flag, which probably had been automatically enabled before. Without it,
> all stuff related to this was not updated since April. The rest was, but
> did not care about the old versions of KDEPIM stuff I had installed.
Hmm... I run with USE="-* ..." so don't have to worry about flags
changing auto-enabled state on me.
> My main fault was not to run emerge --depclean, which would have removed
> obsolete packages like knotes, so I would have noticed. Still, it's
> somewhat weird that the migrator did not check whether the application
> is up to date, but well, I guess that's one of the things I need to care
> about myself.
My gentoo update routine (which includes depclean):
1) Log in as my admin user (which isn't root but has full no-password
sudo privs, so I don't run as that user all the time) in two separate
terminal (konsole) windows.
2) Run esyn in one terminal.
Note it's not esync. Esyn is my sync script that does a bunch of other
stuff too, like remount the root partition read-write (it's read-only by
default), check and mount if not mounted my portage partition, sync both
the gentoo tree and the overlays, run a patcher to automatically patch
ebuilds based on patches in /etc/portage/patches.ebuild just like
epatch_user does for sources, remanifests ebuilds if patched, rebuild the
portage edb, and finally, emerge --fetch --update --deep @world.
3) While esyn is running, in the other terminal window run the scripts
that effectively git log --color --stat --graph the overlays, listing
what changed there. If individual commits look interesting, I'll run the
script that does git show --color --patch-with-stat on the specific patch
in question.
Then I run the script that does an ebuild unpack for a few of the
live-git packages I run (btrfs-progs and pan, at this point), checking to
see if they have updates. If not, a different script deletes the
unpacked workdir. If so, I run the script that displays the git logs for
those changes, and again, drill down to individual patches if any commits
look interesting.
4) By that time esyn is generally about done with its cache update, and I
run my first emerge --ask --verbose --update --deep --newuse @world.
When it spits out the proposed updates, I examine any USE flag changes
(which portage nicely color-highlights) and decide whether I want to
change any of them before I continue. Often that'll involve running
equery uses <pkg> in the other terminal window to see what a USE flag
does. Sometimes it involves running epc (a stub for emerge --changelog
<pkg>, that I mention several times below, as well) on the package or
actually opening the ebuild in an editor.
If I need to make a change, I may run equery hasuse <useflag> to see what
other packages I have installed use that flag, which can determine
whether I make the change in make.conf (actually a file it sources that
only has the USE settings) or in packages.use. I then edit the
appropriate file as necessary.
I also go thru the updates list and see if there's anything interesting.
For core packages like portage or systemd, I epc for a log. For portage,
I generally check every bug listed there, to see if it's anything that
changes things for me. For systemd and a few other packages, if it's a
full version upgrade, I'll check upstream's changelog to see what changes
might affect me.
For less core but still important packages I'll epc gentoo-revision
upgrades too, tho I'll sometimes skip that for codecs and the like. The
idea is that if the change is important enough for a gentoo revision
bump, I want to know why it's happening and how it might affect me and my
installation.
If there's a whole bunch of packages, I'll do some of them and then get
an emerge actually building on them, while I continue to investigate the
others.
5) When I'm done investigating, if there's no changes to make, I'll
answer yes to the emerge --ask and let the emerge run. If there's
changes to make I'll obviously answer no and make the changes, then run
emerge --ask again, as I will if I did a subset of them earlier because
the list was long.
6) I let that run, doing other stuff while it does, checking back
occasionally to see the progress.
7) When done I check all the package specific elog/ewarns to see if
there's anything specific I need to know about the upgrades.
8) Then I run eal (emerge --ask --verbose --oneshot --jobs=N --load-
average=M @smart-live-rebuild) to check all live-build packages for
updates and rebuild them if updated. Mostly that's kde, since I'm
running kde4-live from the kde overlay, but it'll catch whatever other
live-builds I'm running including the btrfs-progs and pan I mentioned
earlier, too.
FWIW, I'm running about 130 live-build packages ATM, and due to
incomplete package splitting in kde4 triggering rebuilds of various
separate packages when their common repository updates, I normally have
about 60-80 packages to rebuild here. But most of these are rebuilt
frequently enough that they're hot in ccache and thus don't take a lot of
time to rebuild.
9) When done I check /those/ elogs. Generally nothing new there, but I
check 'em anyway.
10) When all the updates are done...
10a) I'll ear (my stub for revdep-rebuild, the ea normally means emerge --
ask, but here it's revdep-rebuild --ask, just named ea* to fit in with my
the other ea* stubs) in one terminal...
10b) ... and eup (my stub for etc-update) and then ead (stub for emerge --
depclean), and finally emm (stub to update the whatis/apropos manpage
database) in the other.
(I don't use the manpage database update cronjob for that any more as
it's a relatively short job that only needs done after updates anyway,
and the three jobs eup/ead/emm in the one terminal generally take less
time than the ear in the other, anyway.)
11) umount the packages/portage/ccache partition. Shutdown kde/X since I
just rebuilt much of kde with the live-rebuild. Run lib_users to see
what's still running that was either updated or had libraries it used
updated. Restart them or if there's several it's often simpler to just
do a systemctl emergency and simply ^d it to bring the system back up,
thus restarting most daemons. Do a systemctl daemon-reexec if systemd
itself was upgraded or had component libraries updated.
12) That should leave nothing running with open but deleted files on
root, so I can properly remount it read-only again.
13) Restart kde or do a full shutdown or reboot (I'll often update the
kernel at the same time, and the reboot will load the new kernel), as
appropriate.
The whole process normally takes about two hours, and that's a much more
thoroughly checked update than most admins do, because as sysadmin over
my own systems I take my sysadmin responsibilities seriously, and want to
know about changes that affect me. If I've already updated that week or
there wasn't much going on, it may only take an hour. OTOH, if there's a
big systemd update to figure out what's new in and work out config
updates for, it might take me 3-6 hours. And of course if something
doesn't build or it does but then doesn't work, I have to go on bug
patrol, and for tough bugs, sometimes I'll end up sleeping on it and/or
going to work and coming back to it later.
But two hours isn't too bad as a norm, and I normally update at least
once a week to 10 days on my main machine. Even when I'm busy I tend to
find time for it at least every 10 days or so, tho I think it has been
two weeks a couple times. But go too long and the updates start stacking
up, which brings me to...
My netbook, is quite a different story. I do the builds for it in a 32-
bit chroot on my main machine too, but it can go a year or more between
updates. Actually, I think it's three years now, and I'm considering
simply doing a clean stage-3 reinstall this time around. Or maybe
dumping it and buying a 64-bit amd64-based chromebook or the like, to
wipe and run gentoo on of course, so for the most part I can use the same
binpkgs on both machines.
But contrary to the name I actually don't use it on the net much (I only
connect via Ethernet to my own LAN, behind an OpenWRT-based router, and
don't use it for browsing, except for one period when my main machine was
down due to hardware problems), and I make sure I don't put anything
private on the netbook in case it's lost or stolen, so I don't actually
have to worry too much about security on it, and as long as it's doing
what I need it to do, functioning mainly as a high capacity (120 gig)
media player and ebook reader playing stuff I've downloaded to it from
the main machine, I don't have to worry about updating it too much.
--
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 mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
