On Wed, Mar 16, 2016 at 1:02 PM, Josh Durgin <jdurgin@xxxxxxxxxx> wrote: > On 03/16/2016 12:34 PM, Gregory Farnum wrote: >> >> On Wed, Mar 16, 2016 at 11:27 AM, Willem Jan Withagen <wjw@xxxxxxxxxxx> >> wrote: >>> >>> >>> ../ceph-object-corpus/archive/0.61.4-60-g24c59be/objects/RGWBucketEnt >>> >>> ../ceph-object-corpus/archive/0.61.4-60-g24c59be/objects/RGWBucketInfo >>> error: buffer::end_of_buffer >>> **** failed to decode >>> >>> ../ceph-object-corpus/archive/0.61.4-60-g24c59be/objects/RGWBucketInfo/25f5ff183bba6da708243a0bbbe40a2e >>> **** >>> error: buffer::end_of_buffer >>> **** failed to decode >>> >>> ../ceph-object-corpus/archive/0.61.4-60-g24c59be/objects/RGWBucketInfo/54f53e3e301071f48247d59272b27b53 >>> **** >>> >>> >>> ../ceph-object-corpus/archive/0.61.4-60-g24c59be/objects/rgw_bucket_pending_info >>> >>> "Just" a matter of rebase? >>> Or does it need more tinkering. >> >> >> Well, ceph-object-corpus is a bunch of old encoded versions of our >> objects, and it's validating that current code is still capable of >> decoding them. 0.61.4 is pretty old but I *think* should still work >> (maybe check that your submodules are all up to date; maybe some of >> them got dropped?). Assuming that still works on Linux, it's not a >> rebase problem; I would guess maybe these types just never worked >> because it wasn't BSD cross-compatible until more recently. You might >> want to explore how they're failing exactly; obviously it's running >> out of data to decode but the *why* is interesting. > > > It's broken on linux on master: > > http://gitbuilder.sepia.ceph.com/gitbuilder-ceph-tarball-trusty-amd64-basic/log.cgi?log=188644cb753fe304d941051b75b9eac49ede1086 > https://jenkins.ceph.com/job/ceph-pull-requests/3220/console > > Probably snuck in while 'make check' was broken from the crush update. Oh, and the very next commit after that is the fix, so yes, a rebase should fix it. (Thanks Kefu+Casey!) -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html