Re: libewf.so.2 to libewf.so.3

2019-01-15 Thread Hilko Bengen
* Aleksey Kravchenko:

> I would recommend to follow its way, to avoid pitfalls:
>
> src:libewf/20140606-7, stripped-down:
> - libewf2-dev
> - libewf2
>
> src:libewf3/20171104-2, new package for unstable:
> - libewf-dev (Conflicts: libewf2-dev, without Replaces)
> - libewf3
[...]

One pitfall here is that this would mean rebuilds for three packages.
This contitutes a transition and the deadline for buster for such a
transition has passed. And we'd need to get two packages through NEW
instead of one.

> So, when we drop libewf2, the package libewf-dev will not be renamed.

To me, Renaming packages does not look like a great problem once buster
is released.

Cheers,
-Hilko



Re: arno-iptables-firewall 2.0.3-1~rc4

2019-01-15 Thread Samuel Henrique
Hello Sven,

$gbp buildpackage --git-pbuilder --git-dist=stretch
>
> on branch debian/master fails with
>
> [...]
> The following packages have unmet dependencies:
>  pbuilder-satisfydepends-dummy : Depends: debhelper (>= 12) but it is
> not going to be installed
> Unable to resolve dependencies!  Giving up...
> [...]
>
> while
>
> $ gbp buildpackage --git-pbuilder --git-dist=sid
>
> builds successfully.
>
> This seems to convince me we have to roll back the DH level for
> stretch.
>

I use sbuild instead of pbuilder, so I don't know which are the exact steps
you have to follow, but you need to enable the backports repository on your
build environment, debhelper 12 is available there and so the build works :)

..  I would branch a debian/stretch-bpo from 2.0.3-1 and prepare
> d/changelog accordingly. Or is this something I complete have to leave
> to you?


Yep, that's the steps, feel free to do it and ping me once you want me to
review and sponsor, please note that we can only upload after 2.0.3-1 hits
testing.

Thanks for your work Sven,

Regards,

-- 
Samuel Henrique 


Re: arno-iptables-firewall 2.0.3-1~rc4

2019-01-15 Thread Sven Geuer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello Samuel,

$gbp buildpackage --git-pbuilder --git-dist=stretch

on branch debian/master fails with

[...]
The following packages have unmet dependencies:
 pbuilder-satisfydepends-dummy : Depends: debhelper (>= 12) but it is
not going to be installed
Unable to resolve dependencies!  Giving up...
[...]

while

$ gbp buildpackage --git-pbuilder --git-dist=sid

builds successfully.

This seems to convince me we have to roll back the DH level for
stretch.

Best,
Sven

On Tuesday, den 15.01.2019, 19:36 +0100 Sven Geuer wrote:
> Hello Samuel,
> 
> On Monday, 14.01.2019, 21:08 + Samuel Henrique wrote:
> > Hello Sven,
> > 
> > 1. prepare a 2.0.3-1~bpo9+1. This would only require DH level to be
> > > rolled back to 11.
> > > 
> > 
> > I'm lost here, why do we need to roll back to DH 11?
> 
> I believe so as DH on stretch does not support level 12 according to
> the manpage [1]. In case that's not relevant ...
> 
> > 
> > > 2. prepare a 2.0.1.f-2 from 2.0.1.f-1.1 patched for Bug #824684.
> > > This
> > > could be a minimal change leaving all the older packaging flaws
> > > in
> > > place.
> > > 
> > 
> > Let's just backport 2.0.3-1.
> 
> ...  I would branch a debian/stretch-bpo from 2.0.3-1 and prepare
> d/changelog accordingly. Or is this something I complete have to
> leave
> to you?
> 
> Best,
> Sven
> 
> [1] https://manpages.debian.org/stretch/debhelper/debhelper.7.en.html
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEPfXoqkP8n9/QhvGVrfUO2vit1YUFAlw+TeQACgkQrfUO2vit
1YUf0RAAmRub125bfx6LyHWVZvXi10r8fJXaNIc0yi2+wNHKH41npxdTDMNzfjvn
FBm5794N1zjIY1w80usXqfvhnbOcMgPuYLnoO9Omc+USm597hSofjkc98xvuq7Jw
3CBGGwx2tdUWbobsiMS5QEfb6+YN1LdfecJrc9HeAaYB8E63zYzetpd4cJlK0/vp
Bld/kkkeBCy2t5xl1JRgIW32hLZbB2JKMnOjtdNV0bFBcwc10Cl4RZetqMTorG/f
r4KtttXDQIoMBoAsKLCbEQ6ZyMaXsDLr1FhoIH4Gp8mqyWC+qhtucsv0IdDmD8vH
sDOjdBVOesstoYtHPbZwP1ZYf51PAN/EdtFK+d4dXSYi5J+1AErIkESgmerYQP4n
YW3rQ4gdGUDEhVixcvYIqIgKVSzrrPgTiFxq4xWP7R0gGuXZyRskwS9xNNFnsBew
gB4rH5EsbmWYt1sjz1SLC+elCrkj0KKa889Fv4yuxFXfxftEqCtzV81IVbkpkkT7
ZqIPSA+0/FOwofVb1JnQnQVZW1W8wGqKVXj0NTu9H5quZj9H0HvdjRj+XJqAhZM9
kXdYtLHhlk3E2O9uXLkMDa19JkD26feee0x62of7gZ10biy7zMqbX/xIjX8F3Mqg
XZKj4THJ3dzMuVeRR83ggyX2EjO+BICVhIYvNgAGjzTbSqF2E7M=
=xFaj
-END PGP SIGNATURE-



Re: libewf.so.2 to libewf.so.3

2019-01-15 Thread Aleksey Kravchenko
Hello,

The same situation is with libssl1.1/libssl1.0 [1].

I would recommend to follow its way, to avoid pitfalls:

src:libewf/20140606-7, stripped-down:
- libewf2-dev
- libewf2

src:libewf3/20171104-2, new package for unstable:
- libewf-dev (Conflicts: libewf2-dev, without Replaces)
- libewf3
- ewf-tools
- python-libewf
- python3-libewf

So, when we drop libewf2, the package libewf-dev will not be renamed.

[1]
https://tracker.debian.org/media/packages/o/openssl/control-1.1.0f-3deb9u2

  Best wishes,
  Aleksey


Re: arno-iptables-firewall 2.0.3-1~rc4

2019-01-15 Thread Sven Geuer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello Samuel,

On Monday, 14.01.2019, 21:08 + Samuel Henrique wrote:
> Hello Sven,
> 
> 1. prepare a 2.0.3-1~bpo9+1. This would only require DH level to be
> > rolled back to 11.
> > 
> 
> I'm lost here, why do we need to roll back to DH 11?

I believe so as DH on stretch does not support level 12 according to
the manpage [1]. In case that's not relevant ...

> 
> 
> > 2. prepare a 2.0.1.f-2 from 2.0.1.f-1.1 patched for Bug #824684.
> > This
> > could be a minimal change leaving all the older packaging flaws in
> > place.
> > 
> 
> Let's just backport 2.0.3-1.

...  I would branch a debian/stretch-bpo from 2.0.3-1 and prepare
d/changelog accordingly. Or is this something I complete have to leave
to you?

Best,
Sven

[1] https://manpages.debian.org/stretch/debhelper/debhelper.7.en.html
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEPfXoqkP8n9/QhvGVrfUO2vit1YUFAlw+KBgACgkQrfUO2vit
1YXPIA//Uxy1haWxmYcXcg1eVpYMxuG49XtmcfbV/Docl5961wYDaGooDBg74he6
TAZ9Qftp27aEMHQebxu/0qRMonq64K/HX9en8rGeJiXPQcWSx0nWMCHmxYDy+v7r
hnUbuZzpHQrRGWxes+38JIoos1fCyP/N6zF2S9Zng3SVLKbECQpc6ZurWBaGk+2b
qeXjpbjCl1zU4Hei3QW174mOHqqZJvZGT1H4Fk+M9q5dLmzKoXS0CuESKHS+l8R+
ZDQtZ5d33GciGcEgRrp8jqSy1XyWwF+qlzTsH27eFD06+CwmpCqqZkte5oEff63X
/pkLsPFXn311W2FSA+NHSYlYdUbP3HG9jitk46daajUmSUZYc6EpSlXpFUOItqYh
kND+7dlkJBapLnpsnuLvdNpu5WKuzAabLCXGkoZVpLmL7SrdJWoqZr3uG4W6t3ET
NrIsOw4U+q+GRzyh8Lgd5q4vBZSFHmKpC5qYpXXywpXe7MyM3bzOdlerdETOs7e8
FTfhrozoFvbw6MB5+2axHmhAZ9eQFxEtCUxI6QXZu/N8pzubXl/edAr0ZLBZnDrk
0hdHIEoww5zWH47901y61cgjaRtNNDocSkmVf7CbHZGHWuGauOSYTqvBpk0myyZ0
ECPyuFDayvv002Txq+nTsIM3SWPvMrUSLXHYQvS25sicrVH3GTw=
=0Q2z
-END PGP SIGNATURE-



libewf.so.2 to libewf.so.3

2019-01-15 Thread Hilko Bengen
Hello,

Aleksey Kravchenko and I have been working on updating libewf to from
20140608 to 20171104 to, among other things, gain Python3 bindings.
Unfortunately, there are a few incompatible API/ABI changes which are
correctly marked by a SONAME bump from 2 to 3. This in turn would
normally require a transition because some reverse dependencies (xmount,
guymager, sleuthkit) would need to be rebuilt.

But we are past the transition freeze date for buster. Also, even though
the reverse dependencies are also maintained within this team, at least
sleuthkit would need to be patched and guymager would need to be built
without libewf support.

To avoid changes to reverse dependencies, I'd like to keep a package for
the old version of the shared lib and the headers around. It would look
like this:

src:libewf/20140606-7, stripped-down:
- libewf-dev
- libewf2

src:libewf3/20171104-2, new package for unstable:
- libewf3-dev (Conflicts/Replaces: libewf-dev)
- libewf3
- ewf-tools
- python-libewf
- python3-libewf

Any comments?

Cheers,
-Hilko