All KNotes gone

[Duncan]

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.