Opened 10 years ago

Closed 10 years ago

#2208 closed defect (fixed)

time data ... does not match format '%Y-%m-%dT%H:%M:%S'

Reported by: carrott Owned by: alsroot
Priority: Unspecified by Maintainer Milestone: Unspecified
Component: journal Version: 0.84.x
Severity: Major Keywords: dextrose
Cc: Distribution/OS:
Bug Status: Unconfirmed

Description

ValueError: time data dbus.ByteArray('1268087339', variant_level=1) does not match format '%Y-%m-%dT%H:%M:%S'
Traceback (most recent call last):
  File "/usr/lib/python2.6/site-packages/jarabe/journal/listmodel.py", line 124, in on_get_value
    return self._cached_row[column]
IndexError: list index out of range

Saw the above in Samoa on os300py on XO-1. I'm not sure what the context was, if a journal backup helps, I can possibly dig one up.

See the attached log file for more context.

Attachments (2)

shell.log2 (7.2 KB) - added by carrott 10 years ago.
0001-time-data-.-does-not-match-format-Y-m-dT-H-M-S-2208.patch (1.2 KB) - added by alsroot 10 years ago.

Download all attachments as: .zip

Change History (11)

Changed 10 years ago by carrott

comment:1 Changed 10 years ago by sascha_silbe

There was a potentially related thread on sugar-devel recently.

comment:2 Changed 10 years ago by carrott

This appears to be related to #2149. I migrated a bunch of laptops from 767 to os300py, and it appears that even with the patch in #2149, migration does not proceed completely successfully.

I think this ticket could be closed as a dupe of #2149.

comment:3 Changed 10 years ago by sascha_silbe

  • Component changed from untriaged to sugar
  • Owner set to tomeu
  • Severity changed from Unspecified to Major
  • Version changed from Unspecified to 0.84.x

A tarball of the data store (if I don't already have it) and the name or uid of the entry that triggered this bug would be useful as I couldn't reproduce it using the (combined) content of the data stores you sent me. I do get some other errors that we should catch, but not the one about the date format. Maybe I just didn't examine the right entry (by openening the details view).

comment:4 Changed 10 years ago by tomeu

  • Component changed from sugar to sugar-datastore
  • Owner changed from tomeu to alsroot

Guess this got moved to the sugar component by mistake

comment:5 follow-up: Changed 10 years ago by sascha_silbe

  • Component changed from sugar-datastore to sugar
  • Owner changed from alsroot to tomeu

The error message is from sugar and as long as I can't reproduce and diagnose it, that's our best guess as to which component needs to be fixed. Or rather, sugar should be fixed in any case, even if it turns out we're doing something wrong during migration. Invalid metadata should be handled gracefully, not break the Journal.

comment:6 in reply to: ↑ 5 ; follow-up: Changed 10 years ago by tomeu

  • Component changed from sugar to journal
  • Owner changed from tomeu to alsroot

Replying to sascha_silbe:

The error message is from sugar and as long as I can't reproduce and diagnose it, that's our best guess as to which component needs to be fixed. Or rather, sugar should be fixed in any case, even if it turns out we're doing something wrong during migration. Invalid metadata should be handled gracefully, not break the Journal.

In any case, it would be journal, though I don't fully understand why we have only one ticket and not two if the idea is that something is wrong in the DS *and* we want the journal to be more tolerant to bad data coming from the DS.

comment:7 Changed 10 years ago by alsroot

  • Keywords r? added

I've checked ds and sugar sources, except attached patch there are no other not-try-excepted time.strptime calls.

comment:8 in reply to: ↑ 6 Changed 10 years ago by sascha_silbe

Replying to tomeu:

In any case, it would be journal,

Good point. I only thought about the git repo it lives in, but you're right there's a separate component in Trac for this part of the code.

though I don't fully understand why we have only one ticket and not two if the idea is that something is wrong in the DS *and* we want the journal to be more tolerant to bad data coming from the DS.

Because we don't know yet if the data store is to blame. It could very well have been an activity that wrote the invalid mtime property, in which case there probably is nothing else to fix (because it most likely was an ancient version and has long been fixed)..

Replying to alsroot:

I've checked ds and sugar sources, except attached patch there are no other not-try-excepted time.strptime calls.

I would replace the %s with %r so any special characters get escaped and the string gets quoted, but other than that the patch looks obviously fine (haven't tested it).

comment:9 Changed 10 years ago by sascha_silbe

  • Distribution/OS Fedora deleted
  • Keywords r? removed
  • Resolution set to fixed
  • Status changed from new to closed

Fixed in 0.92 by 923a7fc (760deeb for 0.90).

Note: See TracTickets for help on using tickets.