Sorcery always complains that the tablet is broken (Bug #378)

Well, I was going to provide a debug log, but a recast of the same spell seems to have rectified the issue. It doesn't show up again...

I remember the same problem. Eventually I looked into /var/state/sorcery/versions and I was suprised. When I removed suspicious lines cast and cleanse work like the charm.

2ping 1.1 0 0 0
Error repairing tablet at /var/state/sorcery/tablet/mpc/20091231105923
Error repairing tablet at /var/state/sorcery/tablet/notify-python/20090610012512
...
Error repairing tablet at /var/state/sorcery/tablet/xkeyboard-config/20101204012159
Missing spell dir in tablet, this shouldnt happen.
...
Missing spell dir in tablet, this shouldnt happen.
Please run cleanse --tablet
...
Please run cleanse --tablet
a52dec 0.7.4 0 0 20021006
aalib 1.4rc5 0 0 20031124
accountsservice 0.6.12 0 0 0
acct 6.5.5 0 0 0
acetoneiso 2.3 0 0 0
acl 2.2.51 0 0 0
acpi 1.6 0 0 0
acpid 1.0.10 1 0 0
acpitool 0.5.1 0 0 0
adns 1.4 0 0 0

I captured a superdebug log from when I ran sorcery queue-security on a box that evidences this problem. No spells were queued for security updates which I find highly unlikely as I've not updated this box in quite a while.

Superdebug log is captured here: http://sprunge.us/QiXd

Everything here went fine, but the superdebug log does shows one bug. Fixing ...

So, using devel, I still have the same problem. I'll attach another superdebug log using devel.

Florian Franzmann wrote:

I'm using devel sorcery and whenever I cast a spell I get this message:

The tablet version cache is damaged, removing it!

Creating the tablet version cache, this can take a while ...

Also 'sorcery queue' produces an empty list of spells to update even though there are spells that are out of date. Any idea how I can fix this? I'm attaching superdebug.log.

I have the exact same problem. I cannot update systems because something is terribly broken.

on devel sorcery I get something slightly different:

root@dkowis:~# sorcery queue
Generating the list of spells to update...  
Creating the tablet version cache, this can take a while ...
Creation of the cache failed at linux, please run cleanse --tablet and retry. If some spells have unfixable tablet pages, recast them.

The following spells will be updated:

Do you wish to edit /var/log/sorcery/queue/install ? [n]  

a fix can be: export OLD_QUEUING_METHOD=1

Sorcery will then use the old queueing method, it'll be a lot slower, but it won't fail. This is a reasonable work-around until the actual problem gets fixed (no tablet dir existing for a spell, and sorcery aborts it's version cache stuff when doing version cache updates)

I added the third option to the suggested solutions. The second one is still the best though.

What do i need to do to see those suggestions? Is this issue closed because it is a problem on the user side? If that is not the case, i still have the problem with current devel sorcery:

1. sorcery --version
   20120624
2. sorcery queue
   Generating the list of spells to update...
   Creating the tablet version cache, this can take a while ...
   OLD_QUEUING_METHOD=1 sorcery queue
   The following spells will be updated:
   Do you wish to edit /var/log/sorcery/queue/install ? [n]

I wrote:

What do i need to do to see those suggestions?

I just did some digging, the result first: Rebuilding the cache does not create a cache file (or removes it). For reference:

$ rm /var/state/sorcery/versions
$ cast -c xsel
[...]
Creating the tablet version cache, this can take a while ...
[...]
$ ls -l /var/state/sorcery/versions
ls: cannot access /var/state/sorcery/versions: No such file or directory

Also, i could not see the informative message because there were no errors...
The problem is here in libtablet:

[libtablet:774] if [[ ${#ok_spells[@]} != $(wc -l $file) ]]; then

which should probably explicitly hinder wc to show the filename:

[libtablet:774] if [[ ${#ok_spells[@]} != $(wc -l < $file) ]]; then

because on my box wc -l file output looks like this:

$ wc -l ~/x
1819 /root/x

i'm not sure if wc's behaviour is broken in coreutils 8.15 (running here) or changes in 8.19 (current version in test), maybe someone else can comment on that.

there is a typo in [*libtablet*:774]:
- if [[ ${#ok_spells[]} != $(wc -l $file) ]]; then
+ if [[ ${#ok_spells[]} != $(wc -l < $file) ]]; then
don't think i have access to the repo or do i?

patch can be found in this issue:
#448

So just installed an x86 box from the Source Mage GNU/Linux 0.10.1-rc1 and had this issue, even after updating Sorcery to latest stable (1.15.2). Using the OLD_QUEUING_METHOD=1 work-around allows `sorcery queue` to function.