After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 764006 - Debug messages for pruning and traversion
Debug messages for pruning and traversion
Status: RESOLVED FIXED
Product: ostree
Classification: Infrastructure
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: OSTree maintainer(s)
OSTree maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2016-03-21 23:10 UTC by Dan Nicholson
Modified: 2016-03-26 15:45 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
core: Add verbose messages for pruning (2.49 KB, patch)
2016-03-21 23:11 UTC, Dan Nicholson
none Details | Review
core: Add debug messages for traversing (2.56 KB, patch)
2016-03-21 23:11 UTC, Dan Nicholson
none Details | Review

Description Dan Nicholson 2016-03-21 23:10:27 UTC
If you have a repo with a missing object, debugging it is painful as you have no idea what's being pruned or traversed.

Here's some debug messages that would help.

BTW, should ostree have G_LOG_DOMAIN set to "OSTree" or something like that?
Comment 1 Dan Nicholson 2016-03-21 23:11:08 UTC
Created attachment 324510 [details] [review]
core: Add verbose messages for pruning

When prune fails, it can be really difficult to figure out why. This at
least lets you know which objects are being considered.
Comment 2 Dan Nicholson 2016-03-21 23:11:17 UTC
Created attachment 324511 [details] [review]
core: Add debug messages for traversing

If you have a repo where a needed object has been inadvertantly removed,
all you'll get is a "No such metadata object" error with no clue about
where it was referenced from.

Add some debug messages to provide clues about which objects are being
traversed and found.
Comment 3 Colin Walters 2016-03-26 13:52:34 UTC
https://github.com/ostreedev/ostree/pull/224
Comment 4 Colin Walters 2016-03-26 13:52:48 UTC
(In reply to Dan Nicholson from comment #0)

> BTW, should ostree have G_LOG_DOMAIN set to "OSTree" or something like that?

Yeah.
Comment 5 Colin Walters 2016-03-26 13:54:44 UTC
FWIW, what I've done in the past to debug this sort of thing is use:

```
ostree ls -C |grep $checksum
```
Comment 6 Dan Nicholson 2016-03-26 15:45:49 UTC
Follow up for the G_LOG_DOMAIN setting in bug764237.

As for debugging, I agree on that. What I've found is helpful for the traversal is to `ostree ls -R <commit>` for each referenced commit and see what breaks. But after this I can run `ostree prune --verbose --refs-only` and it should be pretty clear what's busted.