On Mon, Apr 18, 2022 at 07:46:34PM +0200, Sascha Steinbiss wrote:
> Hi,
> > > Do you think we should wait for this to be fixed? As I said before I (just
> > > from my practical point of view) would be in favor of just removing the
> > > problematic architectures.
> > I have no opinion on this.
Hi,
Do you think we should wait for this to be fixed? As I said before I (just
from my practical point of view) would be in favor of just removing the
problematic architectures.
I have no opinion on this. But if you want the package to be releasable,
you will need to change it so that it is
On Thu, Apr 14, 2022 at 09:09:53AM +0200, Sascha Steinbiss wrote:
> Many thanks for reproducing this and for offering a the detailed
> explanation. I would be happy to forward your findings to upstream (however,
> my previous issues/PRs on upstream's GitHub have gone unanswered). For the
> time
Hi Steve,
Many thanks for reproducing this and for offering a the detailed
explanation. I would be happy to forward your findings to upstream
(however, my previous issues/PRs on upstream's GitHub have gone
unanswered). For the time being, I must admit I unfortunately do not
have the time to
Note that this will consistently fail alignment checks on architectures
which require alignment, because the initial buffer is allocated with
reasonable alignment (32bit) but the ethernet header is 14 bytes long, so
the TCP header fields will always be unaligned within the buffer.
On Wed, Apr 13,
Here is a backtrace of the armhf SIGBUS.
Note that not all ARM implementations return SIGBUS which is probably why
this was not reproducible on the porter machine.
# gdb --args pktanon -c /usr/share/doc/pktanon/examples/profiles/profile.xml
./profiles/sample.pcap ./out.pcap
[...]
Reading
Hi Sascha,
On 20-12-2021 15:24, Sascha Steinbiss wrote:
We have porters for architecture specific support. However, I'm not
totally convinced yet it's architecture specific.
Maybe. You noted that it seems to work fine on a machine with the same
architecture but different specs.
I think you
Hi Paul,
sorry for the delay in replying, I was quite busy and now I have some
free time over the holidays to follow up.
>> I am puzzled. The recent upload only changed the watchfile and updated
>> Standards-Version, compat level etc -- packaging things. Nothing touched
>> the code or build
Hi Sascha,
On 14-11-2021 11:03, Sascha Steinbiss wrote:
I am puzzled. The recent upload only changed the watchfile and updated
Standards-Version, compat level etc -- packaging things. Nothing touched
the code or build rules.
Well, but maybe your build dependencies have. Also, compat level
Hi Paul,
> With a recent upload of pktanon the autopkgtest of pktanon fails in
> testing on armhf when that autopkgtest is run with the binary packages
> of pktanon from unstable.
[...]
> Currently this regression is blocking the migration to testing [1]. Can
> you please investigate the
Source: pktanon
Version: 2~git20160407.0.2bde4f2+dfsg-8
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
Dear maintainer(s),
With a recent upload of pktanon the autopkgtest of pktanon fails in
testing on armhf when that
11 matches
Mail list logo
