Your message dated Mon, 22 Apr 2013 21:18:04 +0200
with message-id <[email protected]>
and subject line Re: Bug#672715: Failing lutimes() aborting whole unpacking
has caused the Debian Bug report #672715,
regarding Failing lutimes() aborting whole unpacking
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
672715: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=672715
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
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.
- ML
--- End Message ---
--- Begin Message ---
Hi!
On Fri, 2013-04-05 at 18:29:35 +0200, Guillem Jover wrote:
> 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.
Closing now. Marko, if you can still reproduce this and can provide the
requested information, please reopen, that'd be much appreciated.
Thanks,
Guillem
--- End Message ---
