vcswatch reports that
this package seems to have new commits in its VCS but has
not yet updated debian/changelog. You should consider updating
the Debian changelog and uploading this new version into the archive.
Here are the relevant commit logs:
commit 889f32e344c2ed76326331d9462d34e72dd98e3c
Author: Clint Adams <clint@debian.org>
Date: Sun Jul 1 15:01:09 2018 -0400
convert doc/po4a/addendum.1.sv to utf-8
commit dc2e20a65d1fb3a4c49bb6121a0e5caf3f1b321a
Author: Clint Adams <clint@debian.org>
Date: Sun Jul 1 14:58:15 2018 -0400
changelog for 1.23-1
commit d18b5a49ec60e806ff426878aa958b870eaf512f
Author: Clint Adams <clint@debian.org>
Date: Sun Jul 1 14:57:54 2018 -0400
Add autopkgtests
commit 3cc4a7245670c2de08948ceb8c6e25948659704a
Author: Clint Adams <clint@debian.org>
Date: Mon Jun 25 12:54:52 2018 -0400
Update Vcs-* fields
commit 992421073b401c58ae58c9ce57efedabd85961f7
Author: Clint Adams <clint@debian.org>
Date: Mon Jun 25 12:52:28 2018 -0400
bump to version 1.23
commit 9d642bf28417d8f50b52cac8b01ad4971e2609a8
Author: Clint Adams <clint@debian.org>
Date: Mon Jun 25 12:47:19 2018 -0400
Patch from Loïc Minier to use getopt -T to test for GNU. closes: #758728
commit a8fa088314f2d13a6ed478347d719d265d795691
Author: Clint Adams <clint@debian.org>
Date: Mon Jun 25 12:39:20 2018 -0400
Swedish man page translation from Sebastian Rasmussen (Debian bug #876053)
commit facb2ac70d9a52913cbba78ac58beb7c96b886f1
Author: Clint Adams <clint@debian.org>
Date: Fri Nov 10 14:28:32 2017 -0500
changelog for 1.22-2
commit cbd39dfbc3c0071de3afb9f0f5c78248ae1a5189
Author: Clint Adams <clint@debian.org>
Date: Fri Nov 10 14:27:17 2017 -0500
Rules-Requires-Root: no
commit d399b7ee2c71f1c697607d7d4596a4c506ab1a6c
Author: Clint Adams <clint@debian.org>
Date: Wed Aug 16 22:28:47 2017 -0400
changelog for 1.22-1
commit cd2a5cdb19f1cae80cbaf900e3c54f4d77a6ce75
Author: Clint Adams <clint@debian.org>
Date: Wed Aug 16 22:27:58 2017 -0400
update Vcs-Git and Standards-Version
commit 021c9d87cc73c0e5ac6ff3245442763ec38369a1
Merge: d196c0f dbc38c7
Author: Clint Adams <clint@debian.org>
Date: Wed Aug 16 22:26:48 2017 -0400
Merge branch 'upstream'
commit dbc38c79fa9da9b2d3a90447085cdc7ed6fe54d9
Author: Clint Adams <clint@debian.org>
Date: Wed Aug 16 22:26:13 2017 -0400
bump to version 1.22
commit 16b032c682851e27cc975542891c1e74364caec2
Author: Yann E. MORIN <yann.morin.1998@free.fr>
Date: Mon Aug 14 19:23:34 2017 +0200
communicate: check return status of msgrcv()
msgrcv can return with -1 to indicate an error condition.
One such error is to have been interrupted by a signal.
Being interrupted by a signal is very rare in this code, except in a
very special condition: a highly parallel job, like a makefile with
hundreds jobs, which all compete to read extended attributes from
different files.
For example, see: https://bugs.busybox.net/show_bug.cgi?id=10141, where
a highly-parallel (1000 threads!) mksquashfs on a filesystem with
extended attributes, where we see errors like (those are mksquashfs
errors):
llistxattr for titi/603/883 failed in read_attrs, because Unknown
error 1716527536
However, when a signal is delivered, the content of the message (aka
buf) is not changed, so the various fields will contain whatever they
contained before the call. One field is especially critical,
buf->xattr.flags_rc that can contain either the flags when passed
One way to solve this would be to simply return the error condition to
the caller. However, not all the calls we wrap may return EINTR, so some
callers would be very disapointed if we were to return them EINTR.
Instead, it is guaranteed that no message is delivered in case msgrcv()
is interrupted by a signal, so we simply attempt to receive again.
As for other error conditions, there is not much we can do either: none
are restartable. If any would occur, it would mean we had incorrect
setup on our side, and nothing would work to begin with.
Note: the other error conditions in msgrcv() are:
- E2BIG. the message is too big: nothing would work at all anyway, as
we would not be able to exchange any message with faked;
- EACCES: we would not own the IPC we created ourselves;
- EFAULT: the pointer we allocated ourselves would not be in our
own address range;
- EIDRM: someone killed faked, or called ipcrm... We're doomed, but
we can't exit(), because we still want to allow the caller
to recover and take action, like saving its state to storage
(although that may backfire with more calls to wrapped
functions);
- EINVAL: incorrect message ID, which would mean the msg_get variable
got overwritten by something, like a memory leak, which
could very well come from somewhere else in the process
(i.e. not in our code);
- ENOMSG: can't occur, since we never specify IPC_NOWAIT; and if it
did occur, we could not do much either;
- ENOSYS: can't occur, we don't use MSG_COPY; ditto, we could not do
much if it occured anyway.
So, basically any other error condition would mean the internal state
would be completely fsked-up, so we should just return that error
condition to the caller, in the hope that it can cope. Yet, we can't
always do that, because we don't have a way to convey that error to the
internal caller: we don't know if it is interested in the stat field or
the xatttr one, so even though we could well put the errno in the xattr
field, it might still get missed by the other callers.
Yet, that's what we do, since we can't do much more, and we also print
a warning message, and hope for the best, or at least not the worst...
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
commit 4216200315ad75174d666609891d38ddfacd76d3
Author: Clint Adams <clint@debian.org>
Date: Mon Feb 20 21:13:11 2017 -0500
Don't process message when msgrcv has failed
Patch by Martin Dorey <martin.dorey@hds.com>
commit 52025b61ee5856ced263bbdafa5131167d512305
Author: Clint Adams <clint@debian.org>
Date: Tue Jan 26 13:33:59 2016 -0500
faked: bind to INADDR_LOOPBACK instead of INADDR_ANY (Debian bug#812795)
![[bug history graph]](https://qa.debian.org/data/bts/graphs/f/fakeroot.png){kind=link}