Control: tags -1 moreinfo unreproducible On Thu, 2012-06-14 at 01:21:09 +0200, Guillem Jover wrote: > On Sun, 2012-05-13 at 10:14:14 +0300, Marko Lindqvist wrote: > > Source: dpkg > > Version: 1.16.3 > > > > I'm not sure if this counts as dpkg bug, or is the behavior exactly > > correct (for your upstream dpkg), but reporting just for you to > > consider. > > > > I'm using dpkg in building OpenEmbedded image. So I'm unpacking > > packets not to host system, but under custom prefix. Some packets fail > > to unpack. They abort when lutimes() in tarobject_set_mtime() fails > > for some symbolic link. Most of the time problem is that symbolic link > > being unpacked has absolute path, and host system does not have such a > > file (ENOENT) but I've also seen it to complain about permissions > > (EACCES). > > > > >From "man lutimes" I find it surprising that lutimes() cares about > > file being linked to at all. It should operate on link only, so this > > might actually count as lutimes() bug. > > That should not happen, indeed. Could you run one of those failing > invokation under strace to check what's going on?
I'm thinking this might be due to a "non-standard" filesystem perhaps. A recipe to be able to reproduce this would be nice. Tagging accordingly; if I don't hear anything back in few weeks I think I'll be closing this, as I don't see anything wrong with dpkg here. Thanks, Guillem -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
