from:"Christian Ehrhardt"

Hi,
I'm passing through some long term bugs I have on my list and wanted to ask
if there is any update in considering the updated patch I sent?


Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Bug#823533: ask for update

Hi,
I just wanted to ask again if there is update on considering that patch?

Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Bug#823458: Cleanup

Hi,
again I'm passing a bunch of open bugs and wanted to ask if the
consideration of the patch into Debian ntp packaging got any further in the
meantime?

Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Bug#822961: [pkg-ntp-maintainers] Bug#822961: logcheck file for ntp

Hi Kurt,
any new on integrating this.
I thought dropping the one line we agreed could be done on you applying it.
Did you wait for me to create a line for the leap second thing or are you
waiting on me for something else related to it I didn't realize?


Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

On Fri, May 6, 2016 at 5:20 PM, Christian Ehrhardt <
christian.ehrha...@canonical.com> wrote:

>
> On Fri, May 6, 2016 at 10:16 AM, Kurt Roeckx <k...@roeckx.be> wrote:
>
>> On Fri, May 06, 2016 at 10:09:21AM -0500, Christian Ehrhardt wrote:
>>
>> I think this line shouldn't be ignored:
>> ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ ntpd\[[0-9]+\]: receive: Unexpected
>> origin timestamp from ([0-9.]{7,15}|[0-9a-fA-F:.]{4,39})
>>
>> But it does seem to show up more than it should.
>>
>> I added it as it showed up in the most basic things I did.
> But you are right, we shouldn't ignore this one.
> I found that it is also recommended to monitor for that line (high
> frequent) for https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-7705
>
> So please feel free to just drop this line from the file.
> I wonder thou why it appears in basic execution so often (well different
> bug then)
>

Bug#828864: Reducing the Delta

2016-06-28 Thread Christian Ehrhardt

Package: dovecot
Version: 1:2.2.24-1

Hi,
I was currently merging dovecot for Ubuntu and I thought it really is time
to provide some of the delta for your benefit as well.
Some of them are more "Ubuntu'ish" pieces apport and ufw integration.
But still those things exist and make sense in Debian as well .
And since it is up to you to accept (or not) anyway I should at least
suggest it.

I wanted to suggest the following three changes for your review and
inclusion:

1. lsb-base ad dependency.
There is even a comment in the init script, but no dependency:
debian/dovecot-core.dovecot.init:46:# Depend on lsb-base (>= 3.0-6) to
ensure that this file is present.
debian/dovecot-core.dovecot.init:47:. /lib/lsb/init-functions
Usually "some" packet always refers to lsb-base but I was able to break it
in a sid containter by doing "apt-get remove lsb-base cron logrotate".
That makes /lib/lsb/init-functions unavailable.

Fix is as easy as:
https://git.launchpad.net/~paelzer/ubuntu/+source/dovecot/commit/?h=merge=f06699c206667998f4356b4b66bd7bee77b3ebbf

2. ufw integration
Just allowing easy ufw integration can always be useful to users.
See the change at
https://git.launchpad.net/~paelzer/ubuntu/+source/dovecot/commit/?h=merge=2f445a7f8bdb9f18bdfe39cd55014bdd42447bb8

3. apport hooks
Good if you would like to enable extra data on apport. While not the common
Debian way the change would be not very intrusive - so please take a look.
See
https://git.launchpad.net/~paelzer/ubuntu/+source/dovecot/commit/?h=merge=6b0ed49af2b9b79ce8147f390e0f343eb4e71518

There are slight merge conflicts to last debian due to the fact that these
commits are in the midst of more ubuntu delta. But I can provide a cleaned
diff, debdiff or whatever you want after we had a discussion if you
actually would like the changes.

So please let me know,
thanks in advance
Christian Ehrhardt

Bug#823533: Slight improvement

2016-07-05 Thread Christian Ehrhardt

Testing has shown that an environment var there isn't working well.
Reason is that the call -> ifup -> hook isn't transferring environment.

But checking for alternatives made this even better.

ifup makes all options in e/n/i or ifup -o available (prepended with IF_
and uppercased) to called scripts.
That way one can not only disable per call, but also per device in e/n/i.

So the behavior will be like:

 1. default it is running on ifup (old default)

 2. one can set a global disable in the config file

 3. one disable per device in the devices e/n/i stanza via disable_ntpdate 1
 4. one can disable it per call via -o option setting -o disable_ntpdate=1

The following patch reflects that improvement


Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd
commit 79f5e2bd41f8d23269364c93cf4dad97957b759f
Author: Christian Ehrhardt <christian.ehrha...@canonical.com>
Date:   Mon Jul 4 14:30:26 2016 +0200

d/ntpdate-debian allow disabling the call to ntpdate

Done via setting in /etc/default/ntpdate and environment variable
(LP: #1206164).

So the behavior will be like:
1. default it is running on ifup (old default)
2. one can set a global disable in the config file
3. one disable per device in the devices e/n/i stanza via "disable_ntpdate 1"
4. one can disable it per call via -o option setting -o disable_ntpdate=1

diff --git a/debian/ntpdate-debian b/debian/ntpdate-debian
index 4f5b17b..f4be2c4 100644
--- a/debian/ntpdate-debian
+++ b/debian/ntpdate-debian
@@ -6,6 +6,8 @@ if [ -r /etc/default/ntpdate ]; then
 	. /etc/default/ntpdate
 fi
 
+[ "${IF_DISABLE_NTPDATE:-0}" != "0" -o "${NTPDATE_IFUP_DISABLE}" != "0" ] && exit 0
+
 if [ "$NTPDATE_USE_NTP_CONF" = yes ]; then
 	for f in /etc/ntp.conf /etc/openntpd/ntpd.conf; do
 		if [ -r "$f" ]; then
diff --git a/debian/ntpdate.default b/debian/ntpdate.default
index f239b18..8d98440 100644
--- a/debian/ntpdate.default
+++ b/debian/ntpdate.default
@@ -5,6 +5,13 @@
 # so you only have to keep it in one place.
 NTPDATE_USE_NTP_CONF=yes
 
+# Set to 1 to disable the automated ntpdate-debian call triggered on ifup
+# For more fine granular control this can also be disabled per device by
+# adding "disable_ntpdate 1" to its stanza in /etc/network/interfaces.
+# Furthermore it can be disabled per ifup call with by adding 
+# "-o disable_ntpdate=1" to it.
+NTPDATE_IFUP_DISABLE="0"
+
 # List of NTP servers to use  (Separate multiple servers with spaces.)
 # Not used if NTPDATE_USE_NTP_CONF is yes.
 NTPSERVERS="ntp.ubuntu.com"

Bug#793837: Adding sntp

2016-08-05 Thread Christian Ehrhardt

Hi,
there is an experimental debdiff on the Ubuntu bug now
=> https://bugs.launchpad.net/ntp/+bug/1604010

Also there is a discussion on the need to drop --disable-local-libopts due
to missing symbols and/or a proper fix for that at ntp.org
=> http://bugs.ntp.org/show_bug.cgi?id=3096

Bug#828864: Reducing the Delta

2016-06-30 Thread Christian Ehrhardt

Hi,
I split the ufw parts as we discussed.
This will give us at Ubuntu a little transition when we merge back next
time, but these files are almost never modified so it should be straight
forward.
Better do the right thing now :-)

I created and attached a debdiff for your review and consideration.

I built it and ensured in a sid container that upgrades with these new debs
work.
I also verified that it shows up in "ufw app" commands after the upgrade.

Kind Regards,
Christian

Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

On Thu, Jun 30, 2016 at 7:13 AM, Christian Ehrhardt <
christian.ehrha...@canonical.com> wrote:

> On Thu, Jun 30, 2016 at 12:07 AM, Jaldhar H. Vyas <jald...@debian.org>
> wrote:
>
>> On Tue, 28 Jun 2016, Christian Ehrhardt wrote:
>>
>> Package: dovecot
>>> Version:  1:2.2.24-1
>>>
>>> Hi,
>>> I was currently merging dovecot for Ubuntu and I thought it really is
>>> time
>>> to provide some of the delta for your benefit as well.
>>> Some of them are more "Ubuntu'ish" pieces apport and ufw integration.
>>> But still those things exist and make sense in Debian as well .
>>> And since it is up to you to accept (or not) anyway I should at least
>>> suggest it.
>>>
>>>
>> It's a good idea.  We haven't synchronized the Debian and Ubuntu packages
>> for a long time.
>>
>> I wanted to suggest the following three changes for your review and
>>> inclusion:
>>>
>>> 1. lsb-base ad dependency.
>>> There is even a comment in the init script, but no dependency:
>>> debian/dovecot-core.dovecot.init:46:# Depend on lsb-base (>= 3.0-6) to
>>> ensure that this file is present.
>>> debian/dovecot-core.dovecot.init:47:. /lib/lsb/init-functions
>>> Usually "some" packet always refers to lsb-base but I was able to break
>>> it
>>> in a sid containter by doing "apt-get remove lsb-base cron logrotate".
>>> That makes /lib/lsb/init-functions unavailable.
>>>
>>> Fix is as easy as:
>>> https://git.launchpad.net/~paelzer/ubuntu/+source/dovecot/commit/?h=merge
>>> d=f06699c206667998f4356b4b66bd7bee77b3ebbf
>>>
>>
>> I have added this.
>>
>>
>>> 2. ufw integration
>>> Just allowing easy ufw integration can always be useful to users.
>>> See the changeat
>>> https://git.launchpad.net/~paelzer/ubuntu/+source/dovecot/commit/?h=merg
>>> e=2f445a7f8bdb9f18bdfe39cd55014bdd42447bb8
>>>
>>>
>> Question:  Why is the ufw support in dovecot-core?  Wouldn't it be more
>> sensible to put the appropriate pieces in dovecot-imapd and dovecot-pop3d
>> respectively?  I am not very familiar with ufw so forgive me if this a
>> silly question.
>>
>
> Not at all a silly question.
> I mean I came to that delta like finding it - which is good as I have no
> parental-love to that code as-is :-)
> Giving your suggestion a thought I'd agree that it would be nicer to split
> it to the respective sub-components.
>
> Thanks for already adding the other two diffs already - I'll submit a
> debdiff of the splitted ufw integration somewhen later today.
>
>
>
>> 3. apport hooks
>>> Good if you would like to enable extra data on apport. While not the
>>> common
>>> Debian way the change would be not very intrusive - so please take a
>>> look.
>>> Seehttps://
>>> git.launchpad.net/~paelzer/ubuntu/+source/dovecot/commit/?h=merge
>>> d=6b0ed49af2b9b79ce8147f390e0f343eb4e71518
>>>
>>>
>> This one also seems ok to me. Added.
>>
>> There are slight merge conflicts to last debian due to the fact that these
>>> commits are in the midst of more ubuntu delta. But I can provide a
>>> cleaned
>>> diff, debdiff or whatever you want after we had a discussion if you
>>> actually
>>> would like the changes.
>>>
>>>
>> debdiff would probably be the easiest or git commits I could cherry-pick
>> from.  But definitely do keep suggesting changes.  They are very helpful.
>
>
> Ok, good to know.
> We have some more delta like a great ADT, but it is tied up closely to
> some other changes we make - and I intend to drop eventually.
> Not for this cycle, but probably next one - I hope we gonna drop this
> functional delta, convert that ADT to match the package as in debian and
> then provide that to you as well.
>
> Thanks already - I'll be back later with a debdiff for the ufw things.
>


ufw-split-debian-sid.debdiff
Description: Binary data

Bug#815760:

2016-07-04 Thread Christian Ehrhardt

On Sun, Jul 3, 2016 at 8:52 PM, Santiago Ruano Rincón <santiag...@riseup.net
> wrote:

> Hi all,
>
> On Thu, 14 Apr 2016 21:34:11 +0100 Luca Boccassi
> <luca.bocca...@gmail.com> wrote:
> > On Wed, 30 Mar 2016 08:38:58 +0200 Christian Ehrhardt
> > <christian.ehrha...@canonical.com> wrote:
> > > On Wed, Mar 30, 2016 at 7:41 AM, C.J. Collier
> > > <cjcoll...@linuxfoundation.org
> > > > wrote:
> > >
> > > > On Wed, 24 Feb 2016 11:51:20 +0100 Christian Ehrhardt
> > > > <pael...@gmail.com>
> > > > wrote:
> > > >
> > >
>
> [...]
>
> > > > > I'm also no DD, so sponsors will be needed.
> > > >
> > > > I'm interested in co-maintaining this package, and I've been a
> > > > Debian user
> > > > for a couple of decades now. I've even been an uploader, years
> > > > ago.
> > > >
> > >
> > > Hi C.J.,
> > > great to hear that you want to help as well - I'm sure it will get
> > > great.
> > > We are Currently three people:
> > > - Luca Boccassi - DM, already applied for package upload permissions
> > > - Martin Thiago - Experienced in experimenting with
> > > DPDK/Debian/Ubuntu,
> > > giving us a broad testing range
> > > - Myself - Packaging DPDK for Ubuntu, Testing DPDK with integrated
> > > tests
> > > and Openvswitch-DPDK
> > >
> > > You would be a great addition to our group - more Debian experience
> > > will
> > > surely help.
> > >
> > >
> > > > I've submitted an ITP for the FD.io group of packages:
> > > >
> > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819516
> > > >
> > > > These depend on DPDK, so I've got an interest in making sure the
> > > > DPDK
> > > > packages are good.
> > > >
> > >
> > > From what I learned with packaging DPDK 2.2 for Ubuntu 16.04 there
> > > are a
> > > lot of things that can fail with DPDK.
> > > It is a great, but also fast moving and bleeding edge project.
> > > So testing and patching is needed - more packages "Consuming" the
> > > library
> > > and thereby more diverse test exposure help exactly with that.
> > >
> > > The three of us kind of agreed on the following rough schedule:
> > > - (Now / Luca) Requesting upload permissions for DPDK
> > > - (Now / Me) Completing testing and fixing DPDK packaging in ubuntu
> > > - (11th of May / All of us) start a kick off for packaging DPDK in
> > > Debian
> > >
>
> It would be great to have DPDK on Debian. I can upload the packages, and
> maybe co-maintain.
>

Hi Santiago,
so far Luca was planned to maintain it, but I'd assume he is no objecting
to a co-maintainer.
Especially if the co-maintainer can help with the initial upload.
It might be good to know about a lot of details in advance out of the scope
of actually uploading it.
We would be happy if you join us in our work even before the initial upload
takes place.


> Would you like to have it on git.debian.org collab-maint?
>

As we had so many different participating parties and needed a place as
initial boilerplate we are currently at:
https://wiki.fd.io/view/Deb_dpdk

There is a lot of preparation, packaging and discussion already ongoing,
with a bit of slack until DPDK 16.07 will be released.
Please feel free to join our weekly meeting as referred on that Wiki page I
linked above.

>From there we will move into Debian/Ubuntu and also contribue to upstream
dpdk to lower the delta we have to maintain.

Kind Regards,
Christian


>
> Santiago
>

Bug#854466: Missing Dependency to binutils

2017-02-07 Thread Christian Ehrhardt

Package: pax-utils
Version: 1.2.2-1
Severity: low

Hi,
mostly binutils are available anyway so it might be rarely seen.
But in e.g. a container with a minimal image I found that "lddree" from
pax-utils reports:

lddtree /bin/true
true => /bin/true (interpreter =>
/lib64/ld-linux-x86-64.so.2)/usr/bin/lddtree: line 163: strings: command
not found

Installing binutils (which the strings command is part of) solves the issue.

It seems to work still, so severity is low IMHO.



-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Bug#828041: Long term bug?

2017-01-26 Thread Christian Ehrhardt

Hi,
I just happened to realize that this seems to be a really long term bug -
maybe it never worked.
I came by an older Ubuntu Report of the same issue.

See: https://bugs.launchpad.net/debian/+source/qemu/+bug/1254828

And based on the info there this might have been broken at least since it
still was
qemu-linaro 1.0.50-2012.03-0ubuntu2.1

Bug#855378: Feed back Ubuntu branches and Delta

2017-02-21 Thread Christian Ehrhardt

On Tue, Feb 21, 2017 at 9:46 AM, Michael Tokarev <m...@tls.msk.ru> wrote:

> Hello Christian!
>
> Thank you for doing this.
>
> 17.02.2017 13:48, Christian Ehrhardt wrote:
>
> > case   sha1 summary
> > a  84dc4d05d3   ubuntu acl fix dependencies changed
>
> This really should be fixed in acl package, not in qemu.  I
> filed a bugreport about this quite some time ago, and actually
> forgot about it.
>

I agree that a correct long term solution would be better.
Yet this change is only modifying the current "workaround" to be slightly
more modern.
And it all is behind an :ubuntu: mask anyway.
So if you could consider to pick it still that would be very kind.
If not I think that is fine as well - as this really isn't the most complex
delta :-)

Do you happen to know/find the bug number you filed on acl?

> > a  0d52ac1285   Make qemu-system-common depend on qemu-block-extra
> > a  b24146b825   Make qemu-utils depend on qemu-block-extra
>
> This is something I really don't want to do. This completely
> defeats the purpose of qemu-block-extra package.
>
> The idea was to be able to ship less commonly used backends
> in a separate package to avoid too much dependencies.
> When you make these a strong dependency, you end up always
> installing this package.
>

To start with the right mindset, I know the concept from many other
packages and understand your position on this.

> I objected when this has been done in Ubuntu, and asked for
> a reason for this, but never seen a reply.  Maybe you can
> re-evaluate the reasons why this has been made in Ubuntu,
> and revert this change.
>

IIRC it was that some of the drivers where considered not so "extra"
but more core for us. Let me look if I can unearth some history on this.

> I can _guess_ this was because some people complained that
> after introducing this new qemu-block-extra package, their
> block devices stopped working (because they've been moved
> to -extra out of main). We can't really deal with this by
> introducing new packages and making transitional packages,
> we can, however, _recommend_ the new package, and we can
> mention this in the NEWS file (both of which I did).
>

I think a recommend would be just as fine for us bug I need to know the
history to really decide.
*digging* Imagine a spinning progress bad | / - \ ...
Ah I found it https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1495895

Reading that I think we would be fine with a recommends as well.
On installing by default recommended packages would be co-installed.
But one "could" install without them via the man apt ways of not installing
recommends.

What do you think now knowing the history of this?
Should we just together go with a recommends in the git for now.
And on the next merge I'll check in Detail if it really does not open an
error window for us and would come back.

> > a  5dea4321d9   qemu-efi is in universe
> > a  4018ada7da   no more skip enable libiscsi (now in main)
> > a  fc0aef8d0c   let qemu-utils recommend sharutils
> > b  a06832a485   avoid people editing d/control
> > b  7a257a6a46   Enable seccomp for ppc64el
> > a  5c4d2d0849   Disable glusterfs (Universe dependency)
> > b  78aaa8e6b0   char: fix ctrl-a b not working
> > b  4aa3e058c2   bump libseccomp-dev dependency
>
> The rest is good small fixes.  78aaa8e6b0 is from upstream and
> should be in next their stable, hopefully. These are good small

changes I'll definitely pick.
>
> At any rate, all this, unfortunately, is post-stretch material,
> as I can't change anything in the main branch at this time,
> unfortunately.  Maybe it's time to create debian-stretch
> branch anyway.
>

It is totally fine that this is post-stretch, but yeah now that you have
released it might be worth to spin of an extra branch for it.

> Thank you very much!
>
> /mjt
>

-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Bug#854997: Upstream Ack

2017-02-20 Thread Christian Ehrhardt

FYI - Upstream PR for pg-repack got an ack for the change (after removing
the Debian delta to the tablespace test).

=> https://github.com/reorg/pg_repack/pull/115

Bug#854997: Just slight but acceptable changes in the expected output

I beg a pardon if that all is trivial to you, I get to this part of
postgres for the first time.

The error around index creation matches the release note changes to index
creation.
But the source for this error that we see is actually an expected fail:

regress/sql/repack.sql:
-- This will fail. Silence the message as it's different across PG versions.
SET client_min_messages = fatal;
CREATE UNIQUE INDEX CONCURRENTLY idx_badindex_n ON tbl_badindex (n);
SET client_min_messages = warning;

When diving into the diff of result vs expected output I found some issues
on the path used for the tablespace.
I needed to add this in my repro iteration
 $ rm -rf /tmp/pg-repack-tablespace/*

The diff then comes down to:
- whitespace
- the explicit listing of TABLESPACE pg_default in some statements

The output of those two calls has changed:
  repack.repack_indexdef(indexrelid, 'testts1'::regclass, NULL, true)
If there is a value instead of NULL the output did not change.

This argument is defined as
* @param»··tablespace»·Namespace for the index. If NULL keep the original.

In the cases with a tablespace already defined as "foo" the expected output
already lists "TABLESPACE foo" that is why it is not changing.
The cases with NULL had nothing about it before but now get "TABLESPACE
pg_default" which exactly matches the defintion of the argument.

Upstream has several changes like [1] to add more accepted output versions.

I think that it might be ok to integrate a new
pg-repack-1.3.4/regress/expected/tablespace_2.out with the new content.
I'm gonna suggest upstream at pg_repack as well, but I'd be happy to hear
your expertise on it as well.

[1]:
https://github.com/reorg/pg_repack/commit/4002b4e18f030c8e265707e0174b184d325eeb1b

-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Bug#854997: new tablespace for me looks like the attached file

new tablespace for me looks like the attached file


-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd


tablespace_2.out
Description: Binary data

Bug#854997: [Pkg-postgresql-public] Bug#854997: new tablespace for me looks like the attached file

FYI - Upstream PR https://github.com/reorg/pg_repack/pull/115

Bug#854997: [Pkg-postgresql-public] Bug#854997: new tablespace for me looks like the attached file

Fix for Debian,
I don't know what you prefer and you very likely want to adapt it anyway to
match your upload plans.
But to be sure here as debdiff (attached) and git branch [1] from latest
debian git on pg-repack

[1]:
https://code.launchpad.net/~paelzer/ubuntu/+source/pg-repack/+git/pg-repack/+ref/fix-pg-feb-2017-microrelease


fix-854997-pg-repack-testcase.debdiff
Description: Binary data

Bug#854997: Some info on reproducing the case

Hi,
I was just about to report to pkg-postgresql-pub...@lists.alioth.debian.org
when I found that Jeremy already opened a bug. I just started on this, but
still I wanted to share the bit I had.

I hit it while trying to prepare the recent postgres mircorelease for
Ubuntu.
At least the issue seems 100% reproducible with autopkgtests and locally as
well.

The error comes down to
pg_buildext installcheck
[...]
test tablespace   ... FAILED
[...]
ERROR:  could not create unique index "idx_badindex_n"
DETAIL:  Key (n)=(10) is duplicated.
STATEMENT:  CREATE UNIQUE INDEX CONCURRENTLY idx_badindex_n ON tbl_badindex
(n);

Jeremy already pointed out the issue is not specific to Ubuntu, Debian hits
the same in debci with the recent 9.6.2 update, see [1].

As mentioned before the case can be reproduced easily in any Debian/Ubuntu
environment with pg-repack, example:
# prep current debian system
 $ lxc launch  95fba011e3ad debiansid-postgres-fail-stableupdate
 $ lxc exec debiansid-postgres-fail-stableupdate bash
# get packages and source
 $ apt-get install postgresql-9.6-repack postgresql-server-dev-all dpkg-dev
 $ echo "deb-src http://httpredir.debian.org/debian sid main" >>
/etc/apt/sources.list
 $ apt-get update
 $ apt-get source pg-repack
# prep test env
 $ cd pg-repack-1.3.4/
 $ mkdir /tmp/pg-repack-tablespace
 $ chown postgres:postgres /tmp/pg-repack-tablespace
# these two commands you can iterate on when debugging
 $ service postgresql stop
 $ pg_buildext installcheck

On Ubuntu you'd need the ppa [2] I currently test on to trigger it - also
Yakkety is the only releases which has pr-repack atm.

[1]: https://ci.debian.net/packages/p/pg-repack/unstable/amd64/
[2]: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2470


-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Bug#854671: Feed back some of the current Ubuntu multipath delta

2017-02-13 Thread Christian Ehrhardt

On Mon, Feb 13, 2017 at 12:27 PM, Ritesh Raj Sarraf <r...@debian.org> wrote:

>
> Why do we need a modprobe when the systemd service does load the module ?
>
> For the SysV initscript, it is missing from the multipath-tools package
> but is
> available in the m-t-boot package.

I beg a pardon, you are right.
The "ExecStartPre=/sbin/modprobe dm-multipath" covers now in the systemd
case.

The split in between the packages, especially for the -boot cases was
different in the past for Ubuntu.
Maybe that is the reason this got added in the past, but you are right this
change is not needed anymore.

But even that extra split might these days no more be needed - as I said
I'm convinced more cleanup on
our side could be done, but I had no time this merge to do so.

What do you think on the other minor deltas I submitted in this series?

-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Bug#854671: Feed back some of the current Ubuntu multipath delta

2017-02-09 Thread Christian Ehrhardt

Package: multipath-tools
Version: 0.6.4-3
Severity: normal

Hi,
I was working on the latest merge of multipath-tools into Ubuntu.
There is a lot of cruft that I have to sort out in detail once I find some
more time - a lot of it might be outdated. Some other parts are for early
boot/install multipath - those might be useful to Debian, but those are not
from me so I have a hard time sorting out what really is still needed.

Never the less there are a few changes which I think would already help
Debian today and can be applied. I ported those onto latest master of [1].

You can find the commits at [2], the TL;DR overview are:
-  debian/control: Bump to an updated udev dependency
- d/multipath-tools.preinst: modprobe dm-multipath
- add dep8 test for kpartx
- add dep8 test using tgt and open-iscsi

I'd be happy if you'd consider those changes to be integrated in the next
Debian upload and I'm totally open for discussion if needed.

[1]: https://anonscm.debian.org/git/pkg-lvm/multipath-tools.git
[2]:
https://code.launchpad.net/~paelzer/ubuntu/+source/multipath-tools/+git/multipath-tools/+ref/zesty-submit-delta

-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Bug#855378: Feed back Ubuntu branches and Delta

2017-02-17 Thread Christian Ehrhardt

Package: qemu
Version: 1:2.8+dfsg-2
Severity: normal

Hi,
the branches for Ubuntu in git.debian.org/git/pkg-qemu/qemu.git gathered a
bit
of dust recently. I was taking over the last Ubuntu qemu merge from Serge.
And while Serge always leaves too big footsteps to fill, I still wanted to
update
the branches and feed back delta again.

I don't really want to continue with the ubuntu-dev branch, as for SRU
maintenance I'd prefer per release branches anyway. Also we maintain many
packages now with [1] and matching these I directly rebase onto a matching
debian released version - that also matches better the per release approach
as
it would mean force pushing the ubuntu-dev branch every release (as history
changed to divert from latest Debian release we based on).

So I added a new and up-to-date "ubuntu-zesty-2.8" branch.

Since I was following the process as described in [1] I was able to crate a
huge
list of Deltas that I think could be mergeable in Debian. Most are minor and
where formerly "hidden" in our merge commits (also caused some changelog
cleanup for us).

The changes are of either case:
- a) Ubuntu only fixes that can be hidden under the vendor based
 control-in -> control mechanism
- b) Fixes applying to Debian as well (only for those there will be a
 debian/changelog entry needed)

Since the ubuntu-zesty-2.8 is available for you as well now this should come
down to evaluating the following list of cherry-picks for acceptance into
latest Debian.

case   sha1 summary
a  84dc4d05d3   ubuntu acl fix dependencies changed
a  0d52ac1285   Make qemu-system-common depend on qemu-block-extra
a  b24146b825   Make qemu-utils depend on qemu-block-extra
a  5dea4321d9   qemu-efi is in universe
a  4018ada7da   no more skip enable libiscsi (now in main)
a  fc0aef8d0c   let qemu-utils recommend sharutils
b  a06832a485   avoid people editing d/control
b  7a257a6a46   Enable seccomp for ppc64el
a  5c4d2d0849   Disable glusterfs (Universe dependency)
b  78aaa8e6b0   char: fix ctrl-a b not working
b  4aa3e058c2   bump libseccomp-dev dependency

I expect you to want to evaluate and pick them individually anyway.
But if you'd prefer me to make a branch with only those changes and a
suggested
debian/changelog that you can "just" merge please let me know.

[1]: https://wiki.ubuntu.com/UbuntuDevelopment/Merging/GitWorkflow

-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Bug#848890: [Pkg-swan-devel] Bug#848890: Bug#848890: Revisiting "Ubuntu strongSwan changes"

2017-01-16 Thread Christian Ehrhardt

On Mon, Jan 16, 2017 at 4:16 PM, Yves-Alexis Perez 
wrote:

>
> In the end, I didn't really have time to work more on this, so I've
> uploaded
> the current situation in order to not miss the freezes. It still lacks some
> bits but it should reduce the diff a little.
>

Thanks a lot for your work on this already!

> Once things have settled down we can revisite some of the changes left.
>

I understand the release rush and that bigger changes like this might be
better right after than right before it.
My "personal" timing is fine with that to be postponed the further cleanup
for another one or two months - so no hurry as long as we do not forget
about it.

Bug#856546: zpac compression crash on non x86

2017-03-02 Thread Christian Ehrhardt

Package: lrzip
Version: 0.631-1
Severity: normal

Hi,
we have found an issue in Ubuntu but it applies to Debian as well, so I
wanted to fix it there.

Test:
$ rm file.lrz; dd if=/dev/zero of=file bs=1 count=64; lrzip -z file

Reason (quote from libzpaq header):
By default, LIBZPAQ uses JIT (just in time) acceleration. This only
works on x86-32 and x86-64 processors that support the SSE2 instruction
set. To disable JIT, compile with -DNOJIT. To enable run time checks,
compile with -DDEBUG. Both options will decrease speed.

Fix:
Disable the JIT at least for all non x86, better for all architectures.
Even guaranteeing SSE2 is not sure on some old machines or some virtual
machines.
Usually runtime detection is recommended to enable/disable such features as
available.

In the past in such discussions on other packages we used the lowest base.
The reason is that you can not guarantee that some old machine or virtual
machine has all the features.
Yet that discussion was on newer SSE levels.
Yet this case might be slightly different as [1] lists pentium 4 as the
minimum and that has SSE2
So if you want feel free to add a filter like that too it:
ifneq (,$(filter $(DEB_HOST_ARCH), x86_64))

I provide a debdiff which adds the needed CXXFLAGS in general and since I
noticed that your custom CFLAGS are missing for CPP as well added that too.

Debdiff suggestion attached.
That was tested in a ppa and is now working on ppc64el which was the
original spot to find the issue.

Related Ubuntu bug in [2]

[1]: https://www.debian.org/releases/stable/amd64/ch03s04.html.en
[2]: https://bugs.launchpad.net/ubuntu/+source/lrzip/+bug/1669069


Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd


fix-lrzip-jit.debdiff
Description: Binary data

Bug#855378: Feed back Ubuntu branches and Delta

2017-02-28 Thread Christian Ehrhardt

On Tue, Feb 28, 2017 at 10:16 AM, Michael Tokarev <m...@tls.msk.ru> wrote:

> 17.02.2017 13:48, Christian Ehrhardt wrote:
>
> > - a) Ubuntu only fixes that can be hidden under the vendor based
> >  control-in -> control mechanism
> > - b) Fixes applying to Debian as well (only for those there will be a
> >  debian/changelog entry needed)
> >
> > Since the ubuntu-zesty-2.8 is available for you as well now this should
> come
> > down to evaluating the following list of cherry-picks for acceptance into
> > latest Debian.
> >
> > case   sha1 summary
> > a  84dc4d05d3   ubuntu acl fix dependencies changed
> > a  0d52ac1285   Make qemu-system-common depend on qemu-block-extra
> > a  b24146b825   Make qemu-utils depend on qemu-block-extra
>
> I already commented on these 3.
>
> You can  drop the last 2 of them completely, I guess.
>

Yeah, as we discussed before if we make it a recommends in general I should
certainly be able to drop the hard depends.

[...]

> a  fc0aef8d0c   let qemu-utils recommend sharutils
>
> Why qemu-utils recommends sharutils, what for?
>

Searched through history on that one as well, but this
clearly is one of those that I quoted as "Several changes were applied
but missing in the changelog so far".

Those were just pulled in by the merge commits without being
mentioned for quite a while - I just "uncovered" them.

I think it is an artifact from
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820449
and can be ignored in the context of this bug (and dropped on my side)

> > b  7a257a6a46   Enable seccomp for ppc64el
>
> This one isn't for stretch, delaying for now.
> Why only ppc64el, why not other ppc variants?
>

Because ppc64el was the only one I could test/verify on.
If you can check more we can enable more, but I had no way to do so.

There actually is another fix needed along that which I intended to submit
in the next set.
But since it fits here, enabling seccomp for ppc64el needs a dependency bump

- libseccomp-dev (>> 2.1.0) [linux-amd64 linux-i386 linux-ppc64el],
+ libseccomp-dev (>= 2.3.0) [linux-amd64 linux-i386 linux-ppc64el],

You can merge that into the change, or wait for my next set of changes to
hit since
you wait on stretch+1 for that change anyway.

[...]

Thanks for all the picks already (I cut them out of my quote to streamline
a bit).
And it is clear and ok for those not for stretch to be picked later.

> So we're left with sharutils and acl changes, and seccomp on ppc.
>

I outlined on ppc/sharutils what I think on inline above.

On the acl change, while I agree the right fix is the bug you filed it is
kind of unclear when this will happen.
If not a maintenance burden for you I'd ask you to accept the minimal
change which modifies the dependencies behind an :ubunu: label only for now
(84dc4d05d3).

Checking if my timing/approach works for you:
- I thought I saw you preparing a new upload (many bugs merged / assigned,
CVEs lining up in debian-unstable branch)
- I expect (please correct me) that to be a 1:2.8+dfsg-3 upload
- If the changes discussed here would be applied there that would be great
and I wanted to remerge
  - not sure since they are no criticals for you, you might push the
changes discussed here only for the next release
  - but even if the changes we discussed here are not in there I'd plan me
to merge that for the CVEs
- After some testing I'd get back to you with any additional Delta/Fixes I
identified to be needed for 2.8.
  - preview: there is already one in my queue which is based on
http://patchwork.ozlabs.org/patch/721974/ (I can't wait that to hit next
stable)

Bug#855378: Feed back Ubuntu branches and Delta

2017-03-01 Thread Christian Ehrhardt

On Wed, Mar 1, 2017 at 9:22 AM, Michael Tokarev <m...@tls.msk.ru> wrote:

> Do you happen to have a bug# reference for this?
>

Only a LP bug on  (LP: #1667033)

> Do you have other bugs which are worth fixing too?
>

Not yet, these (seccomp bump / logging) were the ones in my queue so far.

-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Bug#855378: Feed back Ubuntu branches and Delta

2017-03-01 Thread Christian Ehrhardt

On Tue, Feb 28, 2017 at 10:16 AM, Michael Tokarev <m...@tls.msk.ru> wrote:

> > b  a06832a485   avoid people editing d/control
>
> Cherry-picked and edited a bit, to have comment only
> in d/control not d/control-in (I didn't know comments
> can be at the top of the file)

I just found you picked the (modified) part that added comment but skipped
the drop of write permissions.
My change also did a
  chmod -w $@.tmp

People realize the editor not letting them save things and only then read
the comment :-)
Please consider queuing that bit of the change for the next upload.

-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Bug#815760: dpdk debian packaging

2016-09-16 Thread Christian Ehrhardt

Hi,
I reviewed, split and posted your changes to the project for further review
and acceptance along with my man page changes.
Thanks for your contribution.

With all those applied and the recent work of luca lintian is happy with us
now.

But we should no more hijack that bug.
Please for any further discussion comments use mailing list and gerrit of
https://wiki.fd.io/view/Deb_dpdk


On Fri, Sep 16, 2016 at 9:52 AM, santiag...@riseup.net <
santiag...@riseup.net> wrote:

> El 15/09/16 a las 09:04, Christian Ehrhardt escribió:
> >
> > On Wed, Sep 14, 2016 at 6:28 PM, Luca Boccassi <luca.bocca...@gmail.com>
> wrote:
> >
> > Christian has sent patches upstream a couple weeks back:
> >
> > http://dpdk.org/dev/patchwork/patch/15553/
>
> Great!
>
> > And we carry the former version of that submission as a patch for now to
> fix
> > packaging as-is for now.
> > Once accepted upstream that delta will be rebased for 16.07 topic branch
> to
> > match the accepted version.
> > For 16.11 I expect them to be upstream so on that topic branch we can
> drop the
> > delta then.
>
> So would you like to include it in debian/patches for now?
>
>
> Attached you can find other three patches to fix minor issues, and make
> lintian happier.
> What else would be needed to upload to debian?
>
> Cheers, and thanks a lot for your work!
>
> Santiago
>



-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Bug#815760: dpdk debian packaging

2016-09-15 Thread Christian Ehrhardt

On Wed, Sep 14, 2016 at 6:28 PM, Luca Boccassi <luca.bocca...@gmail.com>
wrote:

> Christian has sent patches upstream a couple weeks back:
>
> http://dpdk.org/dev/patchwork/patch/15553/
>

And we carry the former version of that submission as a patch for now to
fix packaging as-is for now.
Once accepted upstream that delta will be rebased for 16.07 topic branch to
match the accepted version.
For 16.11 I expect them to be upstream so on that topic branch we can drop
the delta then.

Thanks,
Christian

-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Bug#823120: issue occuring again

2016-08-26 Thread Christian Ehrhardt

Hi,
sorry to bother you again - but what you had in p7 a while ago seems lost
now in unstable:

# spawn sid container
# Note: only occurs when ntp is installed
$ apt-get install ntpdate ntp
$ ntpdate-debian
26 Aug 13:08:43 ntpdate[605]: no servers can be used, exiting

-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Bug#845298: Feed back improvements from Ubuntu Delta

2016-11-22 Thread Christian Ehrhardt

Package: tgt
Version:  1:1.0.69-1

Hi,
I just merged a recent tgt into Ubuntu - thanks for all your work on the
package.
I wanted to give back two things I coded due to bug reports on Launchpad.

Fixes are:
1. a fix where the default systemd max threads kills tgt when serving many
targets. In that case it spawns more threads than the default allows. The
fix is a small modification to the service file that lifts that limit - it
is done the same way on libvirt, docker, ... so not a totally uncommon
thing.
2. I wanted to evaluate aio at least a little bit, so I wrote up a small
test that works locally. Then I realized I could trivially convert it into
a dep8 test which I then added. This doesn't cover glusterfs as we don't
support that until gluster would be in main - but if you want/need to do so
you can easily adapt that if you want.

Changelog/Bug-Closing:
I kept the Ubuntu Launchpad references in the commit messages so that
everybody can find more background if needed. But I removed them from the
debian/changelog as they have no reason to be there in the final Debian
package.

Repo:
I cloned you latest VCS and pushed a proposed branch that you can integrate
the way you want.
I never pushed to alioth for a merge proposal, but you might want to sort
out and pick patches individually anyway so that should be good I hope. Let
me know if you have other needs.

Branch available at:
git clone -b debian-delta-reduce-nov2016
https://git.launchpad.net/~paelzer/ubuntu/+source/tgtgit clone -b
debian-delta-reduce-nov2016
https://git.launchpad.net/~paelzer/ubuntu/+source/tgt


-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Bug#846088: Alladin License in krb5

2016-11-28 Thread Christian Ehrhardt

Package: krb5
Version:  1.15~beta1-1
Severity: serious

Hi,
we were made aware of a license violation in krb5 - but the issue applies
to Debian just as well so I wanted to report to you as well

In the file src/ccapi/common/win/OldCC/autolock.hxx is a reference to the
Alladin license.
There is no actual copy of the license file included and no other
mentioning of it, just the hxx files boilerplate mentioning.

The License is listed to be a reason to make a package part of "non-free"
at https://www.debian.org/legal/licenses/.
Be careful when checking for it, while the Licence really is "Aladin" the
code references it as "Alladin".

As a matter of fact it seems that this file is not shipped in the Binaries,
nor used to build them - it only is part of the source that is used. Yet I
think it is a violation that should be fixed.

Reference to the Ubuntu bug:
https://bugs.launchpad.net/ubuntu/+source/krb5/+bug/1644595

-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Bug#844609: api breakage on dn functions

2016-11-17 Thread Christian Ehrhardt

Package: gnutls28
Version:  3.5.6-5

Hi gnutls maintainers,
we ran into an issue due to the latest gnutls which I think applies to
Debian as well.
So I wanted to let you know that the fix of
https://gitlab.com/gnutls/gnutls/issues/111 caused major issues e.g. in
libvirt and is currently being reverted upstream, but notthing got yet
released.

You might take a look at to adopt something like the following backport
until a new version is released
https://launchpad.net/ubuntu/+source/gnutls28/3.5.6-4ubuntu2

I setting  Debian Libvirt Maintainers <
pkg-libvirt-maintain...@lists.alioth.debian.org> on CC as I expect they
might want to do a no change rebuild of libvirt once that is completed on
gnutls28.

-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Bug#844511: [Pkg-libvirt-maintainers] Bug#844511: should libvirt be FTBFS at the moment due to the new gnutls?

2016-11-16 Thread Christian Ehrhardt

On Wed, Nov 16, 2016 at 2:27 PM, Guido Günther <a...@sigxcpu.org> wrote:

> It should, I just pushed a fix.
>  -- Guido
>

Thanks,
FYI I just created a fix for the issue the test triggers on as described in
all the debugging on the linked Launchpad bug.
I'll keep you in the loop by adding you as CC on the libvirt patch
submission later today (waiting for some more tests).

-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Bug#844511: should libvirt be FTBFS at the moment due to the new gnutls?

2016-11-16 Thread Christian Ehrhardt

Package: libvirt
Version:  2.4.0-2

Hi,

#1 - not the bug, but required background
I ran into an issue on Ubuntu recently and along debugging I found that you
have the same issue in regard to the recent gnutls version breaking libvirt
autotests.
I work on that issue in
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1641615 and I think
we need to get a fix upstream to libvirt for that and then pull that into
Debian and Ubuntu.

#2 - the bug?
But in regard to the Debian packaging I wondered why your build succeeds,
but found you have just the same issue.
Search:
https://buildd.debian.org/status/fetch.php?pkg=libvirt=amd64=2.4.0-2=1479241026
For: "FAIL: virnettlssessiontest"

I thought that on the amd64 build the FAIL_CHECK in d/rules should be set
and make this a test result a build breaking error, but it did not.

So I wonder - is it a bug that this actually "should" be a FTBFS for you as
well?

-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Bug#842657: missing dependency

2016-10-31 Thread Christian Ehrhardt

Package: imagination
Version:  3.0-5

Hi,
I just realized that imagination uses avconv but has no dependency.
So one can (I did) run into the case that on export it fails by missing
avconv.

That is easily solved by installing libav-tools, but that could easily be
solved by adding it as dependency.


-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Bug#842657: suggested debdiff

2016-10-31 Thread Christian Ehrhardt

The fix should be as easy as the following debdiff.
Although I never touched the libav/ffmpeg area so I could miss something.

cu
Christian


fix-842657-miss-avconv.debdiff
Description: Binary data

Bug#842153: drac plugin outdated and unsupported

On Wed, Oct 26, 2016 at 2:50 PM, Stephan Bosch <stephan.bo...@dovecot.fi>
wrote:

> I say: drop it. If people really want to use it still, they should compile
> it themselves.

Thanks Stefan for your feedback especially since you kind of represent a
dovecot in that discussion.
I totally agree, so therefore here a debdiff as suggestion to the package
maintainer to help making that hopefully easy.

After this:
- there is no drac file in any package (for i in *.deb; do dpkg -c $i; done
| grep -i drac)
- only remaining reference is from upstream wiki provided as doc in
doc/wiki/*

-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

drop-drac.debdiff
Description: Binary data

Bug#842153: drac plugin outdated and unsupported

Package: dovecot
Version:  1:2.2.25-1

Hi,
I was passing and trying to clean up older bugs for Dovecot on Ubuntu.
I came by this one https://bugs.launchpad.net/ubuntu/+source/dovecot/+bug/
1346740

And while generally correct in the bug description:
"Upstream dovecot has gone from generating the version string from
DOVECOT_VERSION to DOVECOT_ABI_VERSION. However this hasn't been updated in
dovecot-drac.patch"

I think the action should be another one, and that is to drop the drac
support.

Usually when such things are renamed the old define should be gone, build
would fail and things would be spotted.

I took the build of the plugin and modified it to stop after preprocessor:

cc -Wall -W -shared -fPIC -DHAVE_CONFIG_H -I../../.. -I../../../src/lib
-I../../../src/lib-index -I../../../src/lib-mail -I../../../src/lib-storage
-I../../../src/lib-storage/index -I../../../src/lib-storage/index/maildir
-I../../lib drac-plugin.c -E -o drac_plugin.E -ldrac
In the result I see it resolving to a value of "2.2.25"
If DOVECOT_ABI_VERSION would be used it would be "2.2.ABIv25(2.2.25)"

Unfortunately I have no drac setup nor have a good idea what it is in
detail.
I looked into the matter 5 minutes more and I think this is just outdated,
unsupported and should be dropped.

The currently packaged version matches latest version from
https://osdn.net/projects/dovecot2-drac/
No update since 2011 there.
Quoting http://wiki2.dovecot.org/HowTo/PopBSMTPAndDovecot#DRAC the phrases
"historical" and "no more work" together with being out of tree are not
convincing at all and make me even more suggest dropping it.

Sure we could also just make the minor change to DOVECOT_ABI_VERSION, but
as outlined above I'm not convinced.

Just wanted to hear what your opinion on this is?

-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Bug#842152: Suggest ufw

Package: dovecot
Version:  1:2.2.25-1

Hi,
on the last updated you included my changes on ufw integration - thanks a
lot once more.
I have a minimal diff left on that and wanted to ask what you think about
taking that into Debian as well.

What is left is to let dovecot-core suggest ufw.
I think suggest is just right, don't do anything by default but show that
there is an integration that makes life better.

Diff would be as following

diff --git a/debian/control b/debian/control
index bff16a2..16d2df0 100644
--- a/debian/control
+++ b/debian/control
@@ -37,7 +37,7 @@ Vcs-Browser: https://anonscm.debian.org/
gitweb/?p=collab-maint/dovecot.git
Package: dovecot-core
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}, libpam-runtime (>= 0.76-13.1),
openssl, adduser, ucf (>= 2.0020), lsb-base, ssl-cert
-Suggests: ntp, dovecot-gssapi, dovecot-sieve, dovecot-pgsql,
dovecot-mysql, dovecot-sqlite, dovecot-ldap, dovecot-imapd, dovecot-pop3d,
dovecot-lmtpd, dovecot-managesieved
, dovecot-solr, dovecot-lucene
+Suggests: ntp, dovecot-gssapi, dovecot-sieve, dovecot-pgsql,
dovecot-mysql, dovecot-sqlite, dovecot-ldap, dovecot-imapd, dovecot-pop3d,
dovecot-lmtpd, dovecot-managesieved
, dovecot-solr, dovecot-lucene, ufw
Provides: dovecot-common, dovecot-abi-${dovecot:ABI-Version}
Replaces: dovecot-common (<< 1:2.0.14-2~), mailavenger (<< 0.8.1-4)
Breaks: dovecot-common (<< 1:2.0.14-2~), mailavenger (<< 0.8.1-4)


-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Bug#842151: Strip incompatible linker option

Package: dovecot
Version:  1:2.2.25-1

You can find more detail on the actual build issue at
https://bugs.launchpad.net/ubuntu/+source/dovecot/+bug/1636781

The topic itself is not so much a Debian but more of an Ubuntu problem.
We have "-Bsymbolic-functions" linker option enabled by default, while you
have not - and dovecot >=2.2.25 is incompatible with that.
I also reported the issue and analysis for it upstream to Dovecot, but no
reply yet that I could refer to.

Never the less in my strive for a low amount of delta I found that many
packages that are well co-maintained in both distributions just guard fixes
for that inside a dpkg-vendor check.
That way you could consider accepting it without affecting your build, have
a head start on fixing it when you ever enable "-Bsymbolic-functions" and
make my life easier.

I understand that since this is like a no-op for the Debian build this
might be at least discussion worthy. Yet I thought it would be nice and
surely worth to at least ask.

Suggested diff would be that:

diff --git a/debian/rules b/debian/rules
index 11028e4..a2c2b76 100755
--- a/debian/rules
+++ b/debian/rules
@@ -9,6 +9,11 @@ export DEB_BUILD_MAINT_OPTIONS=hardening=+all
# DRAC doesn't build with -fPIE
drac_buildflags = DEB_BUILD_MAINT_OPTIONS="hardening=+all,-pie"
dpkg-buildflags

+# LP: 1636781 - strip incompatible default linker option
+ifeq ($(shell dpkg-vendor --derives-from Ubuntu && echo yes),yes)
+  export DEB_LDFLAGS_MAINT_STRIP = -Wl,-Bsymbolic-functions
+endif
+
# Macros to help move files to the module packages
CORE_DIR=$(CURDIR)/debian/dovecot-core
PKG_DIR=$(CURDIR)/debian/dovecot-PKG

Looking forward to hear your opinion.

-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Bug#848247: Collection of fixes for libvirt smoke tests

2016-12-15 Thread Christian Ehrhardt

Package: libvirt
Version: 2.5.0-1
Severity: normal

Hi,
I just saw a few minute sago that Guido and intrigeri are working on smoke
tests as well when I fond debbug 847370 which I also hit on Ubuntu btw.

So this might all be known, but I wanted to share what I found
experimenting with libvirt 2.5 as in experimental. With some luck I'm not
too late with each of it and can still help.

The attached patch is a collection of really small fixes, so I didn't split
them up and provide them as one patch.
But of course you might just discuss, and accept/reject as you think
individually.

P.S. I just saw in the background that qemu smoke now passed as is and
smoke-lxc as well (the latter only with a further minor skips in place like
the aforementioned debbug).

-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd
commit f0821d74ab540ab59fcd35cdbb895f871c95f45f
Author: Christian Ehrhardt <christian.ehrha...@canonical.com>
Date:   Thu Dec 15 16:21:02 2016 +0100

d/t/control, d/t/smoke-qemu-session, d/t/smoke-lxc: fix up smoke tests

ERR: error: Failed to connect socket to '/var/run/libvirt/libvirt-sock': No
 such file or directory
FIX: install libvirt-daemon-system

ERR: error: Failed to connect socket to '/var/run/libvirt/libvirt-sock':
 Permission denied
FIX: set needs-root

ERR: arch can be x86_64
FIX: modify grep "arch name='x86_64'" -> "arch.*x86_64""

ERR: no os_type hvm in capabilities
FIX: install qemu-system

ERR: /usr/bin/virt-xml-validate: cannot determine schema type for
 smoke-qemu-session.xml
FIX: libxml2-utils is "only" recommend which is right, but that means it is
 needed as a test dependency here, so install libxml2-utils

ERR: error: Cannot check QEMU binary /usr/bin/kvm: No such file or directory
FIX: again only recommend, so test dependency to install qemu-kvm

ERR: potential race, guest dies on most non bare metal platforms after a few
 seconds
FIX: well, not a fix but add FIXME comment on 2nd level virtualization issues

ERR: not all autopkgtest platforms can host containers
FIX: use the existing call to virt-host-validate lxc as early exit

ERR: /usr/bin/virt-xml-validate: cannot determine schema type for smoke-lxc.xml
FIX: again libxml2-utils test dependency

ERR: potential race on the check of lxc log after start
FIX: lacking a better fix a sleep and sync to closen the remaining race window

Signed-off-by: Christian Ehrhardt <christian.ehrha...@canonical.com>

diff --git a/debian/tests/control b/debian/tests/control
index 83ec34f..5071c1c 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -3,8 +3,9 @@ Depends: libvirt-clients
 Restrictions: allow-stderr
 
 Tests: smoke-qemu-session
-Depends: libvirt-daemon, libvirt-clients
-Restrictions: allow-stderr, isolation-container
+Depends: libvirt-daemon-system, libvirt-clients, qemu-system, libxml2-utils,
+ qemu-kvm
+Restrictions: allow-stderr, isolation-container, needs-root
 
 Tests: smoke-lxc
 Depends: libvirt-daemon-system, libvirt-clients
diff --git a/debian/tests/smoke-qemu-session b/debian/tests/smoke-qemu-session
index 4aff627..c238308 100755
--- a/debian/tests/smoke-qemu-session
+++ b/debian/tests/smoke-qemu-session
@@ -31,11 +31,16 @@ fi
 echo echo "Running as $USER"
 virt-host-validate qemu || true
 virsh capabilities
-virsh capabilities | grep -qs "arch name='x86_64'"
+virsh capabilities | grep -qs "arch.*x86_64"
 virsh capabilities | grep -qs 'os_type>hvm'
 virt-xml-validate ${XML}
 virsh define ${XML}
 virsh start ${DOMAIN}
+# FIXME: please do note that this is racy, 2nd level kvm virtualization often
+# does not work well, the domain currently is running about 6 seconds on an
+# average before giving up with e.g. warning: host doesn't support requested
+# feature: CPUID.8001H:ECX.svm [bit 2].
+# That behavior might change and break the test.
 virsh list | grep -qs "${DOMAIN}[[:space:]]\+running"
 virsh destroy ${DOMAIN}
 virsh undefine ${DOMAIN}

diff --git a/debian/tests/control b/debian/tests/control
index 5071c1c..f965827 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -8,7 +8,7 @@ Depends: libvirt-daemon-system, libvirt-clients, qemu-system, libxml2-utils,
 Restrictions: allow-stderr, isolation-container, needs-root
 
 Tests: smoke-lxc
-Depends: libvirt-daemon-system, libvirt-clients
+Depends: libvirt-daemon-system, libvirt-clients, libxml2-utils
 Restrictions: allow-stderr, needs-root
 
 Tests: build-test
diff --git a/debian/tests/smoke-lxc b/debian/tests/smoke-lxc
index 0109705..dc19abf 100755
--- a/debian/tests/smoke-lxc
+++ b/debian/tests/smoke-lxc
@@ -25,7 +25,7 @@ check_domain()
 
 trap cleanup EXIT
 
-virt-host-validate lxc
+virt-host-validate lxc || exit 0
 virsh capabilities
 virsh capabilities | grep -qs 'emulator>/usr/lib/libvirt/libvirt_lxc'
 virsh capabilities | grep -qs 'os_type>exe'
@@ -33,6 +33,8 @@ virt-xml-validate ${XML}
 virsh define

Bug#848247: [Pkg-libvirt-maintainers] Bug#848247: Collection of fixes for libvirt smoke tests

2016-12-15 Thread Christian Ehrhardt

On Thu, Dec 15, 2016 at 6:26 PM, Guido Günther <a...@sigxcpu.org> wrote:

> Thanks for these. I've pulled parts in but I thins some are not needed:
>

Thanks for all the applied's removing those and continuing discussion on
the remaining ones.

> >
> > d/t/control, d/t/smoke-qemu-session, d/t/smoke-lxc: fix up smoke tests
> >
> > ERR: error: Failed to connect socket to '/var/run/libvirt/libvirt-sock':
> No
> >  such file or directory
> > FIX: install libvirt-daemon-system
>
> No, we run as non-root so (so we can use qemu:///session)
>

Yeah - I think I'm good with that.
Initially when in the autopkgtest env I think I missed to export that
properly.
I later fixed it up for my tests on the lxc tests and things were ok.

One thing I also found without "needs-root" was that the
`virt-host-validate qemu` failed on /dev/kvm being root/root and thereby
not accessible from non-root.
Is /dev/kvm set up differently by default on Debian so that it is
accessible to you?

Other than the discussion I think I need adapt and rerun when I re-merge to
your next release with the other fixes accepted here in place.
I'd come back to this bug with more detail then if I still would need
anything of the needs-root/libvirt-daemon-system.

> ERR: arch can be x86_64
> > FIX: modify grep "arch name='x86_64'" -> "arch.*x86_64""
>
> Which versions did you see this with?
>

In terms of qemu still an older one as merging that will follow libvirt, so
atm a combination of libvirt 2.5-experimental and qemu 2.6.1.
Both with Ubuntu Delta, but I'd doubt that would change this part of the
behavior.
But if it is the qemu version - then for all sorts of backporting activity
(if ever) it might be useful to have the more relaxed regexp I suggested.

> > ERR: potential race, guest dies on most non bare metal platforms after a
> few
> >  seconds
> > FIX: well, not a fix but add FIXME comment on 2nd level virtualization
> >  issues
>
> I'm not sure how this helps here.
>

Well it does not "help", it was just a reminder for myself when going
through the code.
I'm perfectly fine not applying that one for now and just forgetting it.

A real fix would be a guest that does not insist on all the features and
would boot up just fine (I haven't found kernel parameters to do so and
building an extra guest for that seems over-engineering).

> ERR: potential race on the check of lxc log after start
> > FIX: lacking a better fix a sleep and sync to closen the remaining
> > race window
>
> Hmm...did you see this? If so we should rather check for running again
> with virsh and then check the log.
>

No I haven't seen it in this test, but I had an almost equal test a while
ago (start, check for running) which worked on x86.
But then when the tests spread to other architectures it sometimes failed
on ppc64el and almost always on s390x.

We could convert it to a retry loop that does
while ! check-running
   sleep
   if > retry FAIL

The same would probably apply

-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Bug#848314: Further fix for discussion in the scope of smoke-qemu-session

2016-12-16 Thread Christian Ehrhardt

Package: libvirt
Version: 2.5.0-1
Severity: normal

This is a continuation of debbug 848247.
But you said you want to close that with next upload but I should come back.

While the tests are now working fine in local autopkgtest I was throwing
them at launchpad this night.
And I think there I had a case where the discussion on "virt-host-validate
qemu".

Maybe we should use it as an early exits as in the lxc case - to detect
incompatible environments.
I've seen this:
+ virt-host-validate qemu
  QEMU: Checking for hardware virtualization
  : PASS
  QEMU: Checking if device /dev/kvm exists
  : FAIL (Check that the 'kvm-intel' or 'kvm-amd' modules are loaded & the
BIOS has enabled virtualization)

[...]

+ virsh start sqs
error: Failed to start domain sqs
error: unsupported configuration: Domain requires KVM, but it is not
available. Check that virtualization is enabled in the host BIOS, and host
configuration is setup to load the kvm modules.

That is IMHO due to only having "isolation-container", but could even
happen in isolaton-machine dependin on the setup.

The TL;DR that I suggest is:
1. tampering with (actually more depending on) modules => needs
isolation-machine
2. if virt-host-validate qemu fails use it as an early exit (as you agreed
for the lxc case) as the env won't be good (in some way at least) to later
on in the test really start the guests

I kept the needs-root for now in my local delta, it will still use the
qemu:/// connection since the env is set.

So for now I'd suggest to add:
diff --git a/debian/tests/control b/debian/tests/control
index f965827..c4f5244 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -5,7 +5,7 @@ Restrictions: allow-stderr
Tests: smoke-qemu-session
Depends: libvirt-daemon-system, libvirt-clients, qemu-system, libxml2-
utils,
 qemu-kvm
-Restrictions: allow-stderr, isolation-container, needs-root
+Restrictions: allow-stderr, isolation-machine, needs-root

Tests: smoke-lxc
Depends: libvirt-daemon-system, libvirt-clients, libxml2-utils
diff --git a/debian/tests/smoke-qemu-session b/debian/tests/smoke-qemu-
session
index c238308..968a3f3 100755
--- a/debian/tests/smoke-qemu-session
+++ b/debian/tests/smoke-qemu-session
@@ -29,7 +29,7 @@ if [ $(uname -m) != "x86_64" ]; then
fi

echo echo "Running as $USER"
-virt-host-validate qemu || true
+virt-host-validate qemu || exit 0
virsh capabilities
virsh capabilities | grep -qs "arch.*x86_64"
virsh capabilities | grep -qs 'os_type>hvm'


P.S. FYI I found another issue with the smoke-lxc on s390x but haven't
debugged it yet - I'll let you know as soon as I know anything more.

-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Bug#848314: [Pkg-libvirt-maintainers] Bug#848314: Further fix for discussion in the scope of smoke-qemu-session

2016-12-16 Thread Christian Ehrhardt

On Fri, Dec 16, 2016 at 10:07 AM, Guido Günther <a...@sigxcpu.org> wrote:

> The fix is to use qemu not kvm in the domain XML in this case.


If that is the way to go - to focus on testing qemu:/// - that is right.
The current call to virt-host-validate qemu already has a || true so it is
not fatal which is good.

What do you think of something like the following then (untested so far):
(this is based on my current d/t/control so your diff might be slightly
different.
That gets more similar again when I rebase to your latest code early next
week.)

diff --git a/debian/tests/control b/debian/tests/control
index c4f5244..cd15424 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -4,7 +4,7 @@ Restrictions: allow-stderr

Tests: smoke-qemu-session
Depends: libvirt-daemon-system, libvirt-clients, qemu-system,
libxml2-utils,
- qemu-kvm
+ qemu-user
Restrictions: allow-stderr, isolation-machine, needs-root

Tests: smoke-lxc
diff --git a/debian/tests/smoke-qemu-session.xml
b/debian/tests/smoke-qemu-session.xml
index 47b33d5..c471ff2 100644
--- a/debian/tests/smoke-qemu-session.xml
+++ b/debian/tests/smoke-qemu-session.xml
@@ -1,4 +1,4 @@
-
+
  sqs
  256000
  256000
@@ -18,7 +18,7 @@
  destroy
  destroy
  
-/usr/bin/kvm
+/usr/bin/qemu-x86_64

  
  


-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Bug#848317: smoke-lxc on different architectures

2016-12-16 Thread Christian Ehrhardt

Package: libvirt
Version: 2.5.0-1
Severity: normal

Hi,
continuing to iron out the smoke tests as I really would like to get them
running stable across all environments and architectures on the 2.5 release.

This time I ran the tests (in the somewhat in flight state that we are
discussing in other bugs) on all architectures.
I found issues on s390x where container-in-container seems not to work as
usual for now.

I succeeded to run the test on Bare Metal and in a KVM Guest, but in a
container I face issues when I want to start the guest. These look like
this on automated tests:

+ virsh start sl
error: Failed to start domain sl
error: internal error: guest failed to start: 2016-12-16 07:41:53.195+000

Not a lot of info to deal with, so I set up manually and even when fixing
up a few minor things I still can't pass over the following error:

# virsh start sl
error: Failed to start domain sl
error: internal error: guest failed to start: Failure in libvirt_lxc
startup: Failed to mount devpts on /var/run/libvirt/lxc/sl.devpts:
Permission
denied

I haven't found much more on it - we could in the long term, but I'd like
to get it working now if possible.

One possible solution would be to do an x86 only like on the qemu test a la:

if [ $(uname -m) != "x86_64" ]; then
...

Another one could be to restrict it for now to isolation-machine - that
seems to get around the issue.
That would allow to run on more platforms than pure x86 only - not sure
thou what is better.

diff --git a/debian/tests/control b/debian/tests/control
index cd15424..3a30399 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -9,7 +9,7 @@ Restrictions: allow-stderr, isolation-machine, needs-root

Tests: smoke-lxc
Depends: libvirt-daemon-system, libvirt-clients, libxml2-utils
-Restrictions: allow-stderr, needs-root
+Restrictions: allow-stderr, needs-root, isolation-machine

Tests: build-test
Depends: libvirt-dev, build-essential, pkg-config

-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Bug#850709: closed by Guido Günther <a...@sigxcpu.org> (Re: [Pkg-libvirt-maintainers] Bug#850709: Add debian/bug-presubj)

Thank you Guido for the confirmation, I almost thought so seeing the
history of debian/libvirt-daemon-system.bug-presubj.
But since I didn't create that part of the delta I wanted to make sure to
mention it at least before dropping.
So in that point of view I guess our remaining delta is just a relic of the
transition off of libvirt-bin and I'll drop ours accordingly.

Bug#848317: [Pkg-libvirt-maintainers] Bug#848317: not arch dependent but racy

2017-01-10 Thread Christian Ehrhardt

Hmm, just applying did not fix it for me.
Needs more debugging on the different group setup on Debian/Ubuntu in
relation to the issue and the upstream fix

I'll come back once I have any new insight to this, but it is at a lower
prio for me now.
Do we have a "deferred" bug state or anything like that to make that clear?h

Bug#848890: [Pkg-swan-devel] Bug#848890: Revisiting "Ubuntu strongSwan changes"

2017-01-03 Thread Christian Ehrhardt

On Wed, Dec 21, 2016 at 11:29 AM, Yves-Alexis Perez <cor...@debian.org>
wrote:

> We did enable REDUCED_KEYLENGTH at one point on !linux and !x86, but it
> still
> wasn't enough, so we completely disabled the test suite on !x86. I'd rather
> not disable more of the test suite, to be honest.
>

Maybe that was an interleaved fix - with the reduced keylength fixing it
for us but not for you.
So you chose to disable !x86 tests.

I think it is fine to ignore that part of the change, thank you to
elaborate on your history on this.

-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Bug#848890: [Pkg-swan-devel] Bug#848890: Revisiting "Ubuntu strongSwan changes"

2017-01-03 Thread Christian Ehrhardt

On Wed, Dec 21, 2016 at 11:22 AM, Yves-Alexis Perez 
wrote:

> > b7754fe changelog: d/rules: Make override_dh_strip a nop
>
> I don't think this one is ok. Stripping the binaries is a Debian Policy
> *should*.
> >
> > The (to be enabled in a later commit in this series) plugin
> "integrity-test"
> > provides a useful extra feature for the cautious strongswan admin.
> > It stores checksums of its libraries and can check non-malicious errors
> to
> > avoid accidentially loading bad libraries.
> > See https://wiki.strongswan.org/projects/strongswan/wiki/IntegrityTest
> for
> > more.
> >
> > It is an experimental feature, but out there for a while and was enabled
> in
> > Ubuntu per user request, so I assume it has its use in the field.
>
> I have my opinion on this, but I'll keep them to that latter mail.
> >
> > To be able to do so it stores the checksums as part of the build process.
> > But to match those sums later on the build is not allowed to strip the
> > plugins.
> > That is listed in the "conflicts" section of the Wiki page.
>
> I think it'd be best to store the checksum of the stripped binaries in any
> case.


Hi Yves-Alexis,
yeah I expected this to be a more discussion-worth one.

I contacted a few more people and it turns out that those that "really
really" need
it e.g. for FIPS create an own checksum checker independent of the
integrity-test plugin.

That said I'm totally ok with not taking the stripping change, but in that
case we should drop the integrity check plugin since we know it won't be
usable.
Change might be something like the following on top on the other enablement
bits:

diff --git a/debian/control b/debian/control
index 343e0bd..7872360 100644
--- a/debian/control
+++ b/debian/control
@@ -106,8 +106,6 @@ Description: strongSwan utility and crypto library
   - resolve (Writes name servers received via IKE to a resolv.conf file or
 installs them via resolvconf(8))
   - test-vectors (Set of test vectors for various algorithms)
-  - libchecksum (not a plugin, but an integrity check to detect
-misconfigurations or non-malicious file manipulations)

 Package: libstrongswan-standard-plugins
 Architecture: any
diff --git a/debian/rules b/debian/rules
index 03592a9..0c6aeda 100755
--- a/debian/rules
+++ b/debian/rules
@@ -51,7 +51,6 @@ CONFIGUREARGS := --libdir=/usr/lib --libexecdir=/usr/lib \
--enable-imv-scanner  \
--enable-imv-swid \
--enable-imv-test \
-   --enable-integrity-test \
--enable-ipseckey \
--enable-kernel-libipsec \
--enable-ldap \

Bug#850711:

Package: libvirt
Version: 2.5.0-3
Severity: normal


Hi,
I'm trying to work on cleaning up Ubuntu Delta on Libvirt submitting all
code that should help Debian just as much.

In this bug that is about enabling some more features on ppc64el and s390x
Debian has those architectures as well and I know from Ubuntu that they
work since we carry that as Delta for a while now.
Thereby it should be pretty safe to let those Architectures benfit from
that in Debian as well.

In particular we do:
* Enable systemtap, zfs, numa and numad on s390x.
* Enable systemtap on ppc64el.


-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd
From: Christian Ehrhardt <christian.ehrha...@canonical.com>
Date: Wed, 14 Dec 2016 16:30:20 +0100
Subject: [PATCH 3/3] Enable some features on ppc64el and s390x

* Enable systemtap, zfs, numa and numad on s390x.
* Enable systemtap on ppc64el.

Signed-off-by: Dimitri John Ledkov <x...@ubuntu.com>
Signed-off-by: Stefan Bader <stefan.ba...@canonical.com>
Signed-off-by: Christian Ehrhardt <christian.ehrha...@canonical.com>
---
 debian/control | 6 +++---
 debian/rules   | 4 ++--
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/debian/control b/debian/control
index ed611c5..093310d 100644
--- a/debian/control
+++ b/debian/control
@@ -33,8 +33,8 @@ Build-Depends:
  libnl-route-3-dev [linux-any],
  libyajl-dev,
  libpcap0.8-dev,
- libnuma-dev [amd64 arm64 i386 ia64 mips mipsel powerpc ppc64 ppc64el],
- numad [amd64 arm64 i386 ia64 mips mipsel powerpc ppc64 ppc64el],
+ libnuma-dev [amd64 arm64 i386 ia64 mips mipsel powerpc ppc64 ppc64el s390x],
+ numad [amd64 arm64 i386 ia64 mips mipsel powerpc ppc64 ppc64el s390x],
  radvd [linux-any],
  libnetcf-dev (>= 1:0.2.3-3~) [linux-any],
  libsanlock-dev [linux-any],
@@ -43,7 +43,7 @@ Build-Depends:
  libapparmor-dev [linux-any],
  libdbus-1-dev [linux-any],
  nfs-common,
- systemtap-sdt-dev [amd64 armel armhf i386 ia64 powerpc s390],
+ systemtap-sdt-dev [amd64 armel armhf i386 ia64 powerpc ppc64el s390 s390x],
  python,
  xsltproc,
  zfsutils [kfreebsd-amd64 kfreebsd-i386],
diff --git a/debian/rules b/debian/rules
index ca93244..d99c3d7 100755
--- a/debian/rules
+++ b/debian/rules
@@ -39,12 +39,12 @@ ifneq (,$(findstring $(DEB_HOST_ARCH_OS), linux))
   WITH_AUDIT  = --with-audit
   WITH_SELINUX= --with-selinux --with-secdriver-selinux --with-selinux-mount=/sys/fs/selinux
   WITH_APPARMOR   = --with-apparmor --with-secdriver-apparmor --with-apparmor-profiles
-  ifneq (,$(findstring $(DEB_HOST_ARCH), amd64 armel armhf i386 ia64 powerpc s390))
+  ifneq (,$(findstring $(DEB_HOST_ARCH), amd64 armel armhf i386 ia64 powerpc ppc64el s390 s390x))
   WITH_DTRACE = --with-dtrace
   else
   WITH_DTRACE = --without-dtrace
   endif
-  ifneq (,$(findstring $(DEB_HOST_ARCH), amd64 arm64 i386 ia64 mips mipsel powerpc ppc64el))
+  ifneq (,$(findstring $(DEB_HOST_ARCH), amd64 arm64 i386 ia64 mips mipsel powerpc ppc64el s390x))
   WITH_NUMA   = --with-numactl --with-numad
   else
   WITH_NUMA   = --without-numactl --without-numad
-- 
2.7.4

Bug#850711: Acknowledgement ()

retitle 850711 Enable some features on ppc64el and s390x

Bug#850709: Add debian/bug-presubj

Package: libvirt
Version: 2.5.0-3
Severity: normal


Hi,
I'm trying to work on cleaning up Ubuntu Delta on Libvirt submitting all
code that should help Debian just as much.

In this bug that is about to improve initial bug report quality by hinting
at
http://wiki.debian.org/libvirt/Debugging.

It is not that important - but I thought either you agree to that or not,
it might still be worth to suggest. Either way I think on next merge we
converge on whatever this bug decides upon.
Especially since for Ubuntu we'd already have apport hooks to help with the
same.

-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd
From: Christian Ehrhardt <christian.ehrha...@canonical.com>
Date: Mon, 8 Aug 2016 15:35:05 +0200
Subject: [PATCH] Add debian/bug-presubj

This is meant to improve initial bug report quality by hinting at
http://wiki.debian.org/libvirt/Debugging.

Signed-off-by: Stefan Bader <stefan.ba...@canonical.com>
Signed-off-by: Christian Ehrhardt <christian.ehrha...@canonical.com>
---
 debian/bug-presubj | 5 +
 1 file changed, 5 insertions(+)
 create mode 100644 debian/bug-presubj

diff --git a/debian/bug-presubj b/debian/bug-presubj
new file mode 100644
index 000..883f5b9
--- /dev/null
+++ b/debian/bug-presubj
@@ -0,0 +1,5 @@
+When reporting issues regarding libvirt and libvirtd please make sure you at
+least include the relevant log parts and your vm configuration.
+
+http://wiki.debian.org/libvirt/Debugging has more information on howto provide
+debugging information for the virt-* tools.
-- 
2.7.4

Bug#850710: Convert more subpackages to multiarch

Package: libvirt
Version: 2.5.0-3
Severity: normal


Hi,
I'm trying to work on cleaning up Ubuntu Delta on Libvirt submitting all
code that should help Debian just as much.

In this bug that is about following multiarch more in some of the libvirt
packages.
This covers libvirt0, libvirt-dev and libnss-libvirt.

The patch originally came from Doko who is well known in the Debian
community.
But while it made it into Ubunut it isn't in Debian, yet OTOH I think it
should make sense for Debian just as much.

If there was any reasoning in the past why this was not taken by Debian
please point me to it, otherwise I'd be hapy if you could review and
hopefully integrate this patch.

-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd
From: Christian Ehrhardt <christian.ehrha...@canonical.com>
Date: Mon, 15 Aug 2016 11:47:49 +0200
Subject: [PATCH] libvirt0 libvirt-dev libnss-libvirt to multi-arch

Convert libvirt0 and libvirt-dev to multi-arch.

We move all libraries into a multi-arch subdirectory then. So the
dh_install command no longer finds it. The destination was already a
multi-arch directory, so it seems to make sense to also set multi-arch
for libnss-libvirt as well.

Signed-off-by: Stefan Bader <stefan.ba...@canonical.com>
Signed-off-by: Christian Ehrhardt <christian.ehrha...@canonical.com>
---
 debian/control |  5 +
 debian/libvirt-dev.install | 10 +-
 debian/libvirt0.install|  8 
 debian/rules   | 13 -
 4 files changed, 26 insertions(+), 10 deletions(-)

diff --git a/debian/control b/debian/control
index 4de7539..ed611c5 100644
--- a/debian/control
+++ b/debian/control
@@ -157,6 +157,8 @@ Description: Libvirt daemon configuration files
 
 Package: libvirt0
 Architecture: any
+Multi-Arch: same
+Pre-Depends: ${misc:Pre-Depends}
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Recommends: lvm2 [linux-any]
 Breaks: selinux-policy-default (<< 2:2.20131214-1~), selinux-policy-mls (<< 2:2.20131214-1~)
@@ -182,6 +184,7 @@ Description: documentation for the libvirt library
 Package: libvirt-dev
 Architecture: any
 Section: libdevel
+Multi-Arch: same
 Depends: ${misc:Depends}, libvirt0 (= ${binary:Version}), libxen-dev [i386 amd64 armhf arm64]
 Replaces: libvirt-bin (<< 1.2.0~)
 Recommends: pkg-config
@@ -216,6 +219,8 @@ Depends:
  ${misc:Depends},
  ${shlibs:Depends},
  libvirt0 (= ${binary:Version}),
+Multi-Arch: same
+Pre-Depends: ${misc:Pre-Depends}
 Priority: extra
 Description: nss plugin providing IP add ress resolution for virtual machines
  Libvirt is a C toolkit to interact with the virtualization capabilities
diff --git a/debian/libvirt-dev.install b/debian/libvirt-dev.install
index 88a6a0b..ff0bdb5 100644
--- a/debian/libvirt-dev.install
+++ b/debian/libvirt-dev.install
@@ -1,7 +1,7 @@
-usr/lib/libvirt.so
-usr/lib/libvirt-admin.so
-usr/lib/libvirt-lxc.so
-usr/lib/libvirt-qemu.so
+usr/lib/*/libvirt.so
+usr/lib/*/libvirt-admin.so
+usr/lib/*/libvirt-lxc.so
+usr/lib/*/libvirt-qemu.so
 usr/include/*
-usr/lib/pkgconfig/*
+usr/lib/*/pkgconfig/*
 usr/share/libvirt/api/*-api.xml
diff --git a/debian/libvirt0.install b/debian/libvirt0.install
index 134edab..897f20e 100644
--- a/debian/libvirt0.install
+++ b/debian/libvirt0.install
@@ -1,4 +1,4 @@
-usr/lib/libvirt.so.*
-usr/lib/libvirt-admin.so.*
-usr/lib/libvirt-lxc.so.*
-usr/lib/libvirt-qemu.so.*
+usr/lib/*/libvirt.so.*
+usr/lib/*/libvirt-admin.so.*
+usr/lib/*/libvirt-lxc.so.*
+usr/lib/*/libvirt-qemu.so.*
diff --git a/debian/rules b/debian/rules
index 36ba507..ca93244 100755
--- a/debian/rules
+++ b/debian/rules
@@ -159,6 +159,15 @@ override_dh_auto_test:
 	fi
 
 override_dh_install-arch:
+	# Multiarch:
+	# don't configure with --libdir, but move the files manually, because
+	# we don't want to change other places in /usr/lib/
+	mkdir -p debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)
+	mv debian/tmp/usr/lib/lib*a \
+	   debian/tmp/usr/lib/lib*.so* \
+	   debian/tmp/usr/lib/pkgconfig \
+	   debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)
+
 	dh_install
 
 	# Copy upstream files to debian/ so dh_* can find them
@@ -191,7 +200,9 @@ ifeq ($(XEN_ENABLED), 1)
 	dh_install -p libvirt-daemon-system etc/libvirt/libxl.conf
 	dh_install -p libvirt-daemon-system etc/libvirt/libxl-lockd.conf
 endif
-	dh_install -p libnss-libvirt usr/lib/libnss_libvirt.so.2 lib/$(DEB_HOST_MULTIARCH)/
+	dh_install -p libnss-libvirt \
+  usr/lib/$(DEB_HOST_MULTIARCH)/libnss_libvirt.so.2 \
+  lib/$(DEB_HOST_MULTIARCH)/
 
 	for l in $(LOGROTATE); do \
 		cp $(CURDIR)/debian/build/daemon/$$l.logrotate \
-- 
2.7.4

Bug#848317: [Pkg-libvirt-maintainers] Bug#848317: not arch dependent but racy

2017-01-08 Thread Christian Ehrhardt

FYI - that http://www.spinics.net/linux/fedora/libvir/msg141665.html
pretty much looks like it.

I'll need to experiment with that applied but wanted to mention it here.

Bug#848846: autofs service dependencies

2016-12-19 Thread Christian Ehrhardt

Package: autofs
Version: 5.1.1-1
Severity: normal

Hi,
FYI - this is a "mirror" of a bug we got, as it affects Debian just as much
we think it should be integrated there.
Reference: https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/1614248

Summary (stripped of Ubuntu references that don't matter to you):
"Package autofs includes SysV startup script (/etc/init.d/autofs), but does
not include systemd service file. As a result, systemd starts autofs as
part of its LSB (sysv) processing, which makes it difficult to ensure that
autofs is started after services that it requires for proper functioning.
In particular, unit autogenerated by systemd-sysv-generator for autofs does
not include dependency on sssd.service.

It appears that on the installation that I tested, systemd starts LSB
services well after sssd is started, so the issue does not cause any
visible problems, but this startup sequence is accidental.

Suggested example service file for autofs that fixes this problem:
https://launchpadlibrarian.net/279497607/autofs.service

In addition to sssd.service, this unit could also list nslcd.service,
slapd.service and ypbind.service/nis.service in its After= line. However,
these service files are also missing from their respective packages, and I
am not even sure how NIS client service file would be called."


-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Bug#848890: [Pkg-swan-devel] Bug#848890: Revisiting "Ubuntu strongSwan changes"

Background to explain the reasoning behind the change 3/7:

Commits:
0af16a2 * d/rules: Set minimal TESTS_REDUCED_KEYLENGTHS
e024f7e changelog: d/rules: Set minimal TESTS_REDUCED_KEYLENGTHS to avoid
hanging builds

There were several cases where low entropy build environments stalled.
This was up to an amount that sometimes builds failed with timeouts.

Obviously the more options that are enabled the more will be tested and the
bigger the effect of this is.

Fortunately the strongswan build/test has an environment variable to control
this behavior and if set to 1 all tests will still be run, but require much
less entropy.
See
https://wiki.strongswan.org/projects/strongswan/wiki/DeveloperDocumentation
for the Strongswan documentation on this option.

Bug#848890: [Pkg-swan-devel] Bug#848890: Revisiting "Ubuntu strongSwan changes"

Background to explain the reasoning behind the change 2/7:

Commits:
944a3c7 * d/rules: Make override_dh_strip a nop.
b7754fe changelog: d/rules: Make override_dh_strip a nop

The (to be enabled in a later commit in this series) plugin "integrity-test"
provides a useful extra feature for the cautious strongswan admin.
It stores checksums of its libraries and can check non-malicious errors to
avoid accidentially loading bad libraries.
See https://wiki.strongswan.org/projects/strongswan/wiki/IntegrityTest for
more.

It is an experimental feature, but out there for a while and was enabled in
Ubuntu per user request, so I assume it has its use in the field.

To be able to do so it stores the checksums as part of the build process.
But to match those sums later on the build is not allowed to strip the
plugins.
That is listed in the "conflicts" section of the Wiki page.

Therefore override "override_dh_strip:" with a comment that explains why
strip
is skipped.

Bug#848890: [Pkg-swan-devel] Bug#848890: Revisiting "Ubuntu strongSwan changes"

Background to explain the reasoning behind the change 7/7:

Commits:
0271917 * Enable more features to to cover more use-cases
bd04b06 changelog: Enable more features to to cover more use-cases

Note: Many of those changes are so correlated that this is a one big change
for
now. If needed and ok that interim commits might not be buildable I could
split
it in maybe 3-5 logical pieces. But for now just explaining all the
reasoning
in Detail.

This change enable more features to to cover more use-cases by the packages
strongswan.

As a start it enables this enables all stable plugins according to
https://wiki.strongswan.org/projects/strongswan/wiki/Pluginlist

The intention is to make the default packages strongswan more usable without
forcing users to rebuild more more sophisticated setups.
Yet on the other hand we don't want to proliferate plugins so most of the
plugins are added to the extra-plugin package.
- This is a (late) follow on to the discussion started in 2014 with the
subject
  "Ubuntu strongSwan changes" on pkg-swan-devel list.
- Some Features might not show up as change in the configure step. That is
  because they are enabled by default or as dependency to others, and get
now
  "enabled" indirectly due to the additional build dependencies.
  "pool" is such an example.
- Of course to be able to enable all stable plugins I had to add several
  additional build-deps to libjson-c-dev, libldns-dev, libmysqlclient-dev,
  libpcsclite-dev, libtspi-dev, libsoup2.4-dev and libunbound-dev.
- In d/control I mention all addtionally enabled plugins in the package
  descriptions.
- d/libbstrongswan-*-plugins.install got all the added plugins, libs and
conf
  files.

On top of the stable default plugins/features this enables two more
functions
based on user request.
- Also enable kernel-libipsec which is not in upstreams "stable" plugins
  list. This is based on user requests to make strongswan more useful in
  userspace of containers.
  To avoid conflicts it is disabled by default via
  d/p/dont-load-kernel-libipsec-plugin-by-default.patch as
  upstream recommends to not load kernel-libipsec by default.
- integrity-test is another feature people sometimes ask for. It can be
  considered as a little step (clearly not enough) towards FIPS compliance.
  It can help the cautious admin to detect accidentially modified plugins.

Additionally Ubuntu got user requests to make charons default plugin
installation more useful (pad.lv/1640826).
That is eap-mschapv2 for Windows 7+ and modern OSX/iOS using IKEv2 and
xauth-generic for Android and older OSX/iOS using IKEv1 and XAUTH.
To be able to do so the change is following the example of the libstrongswan
plugin packaging and moves those common cases from the
"libcharon-extra-plugins"
to the newly added "libcharon-default-plugins" package

Furthermore it was identified that the whole use case around TNC seems to be
a very selective user group.
See https://wiki.strongswan.org/projects/1/wiki/trustednetworkconnect
Those users (again as with other cases mentioned) might not want to install
all
of the extra-plugins that are needed today. Therefore related functionality
is
moved into packages of its own.
This allows to use TNC without installing extra-plugins package.

Debian already stopped to ship libfast as Ubuntu did for a while.
But it did still mention the associated (and now nor more built) medcli and
medsrv elements.
Also it did not disable it on the configure step which should be done if not
shipping it anyway.
Therefore drop it from d/control and d/rules accordingly.

Due to the new plugins and features there are also more libraries being
built.
Those are only needed by plugins in the extras-plugins package, so add the
libraries there.
- libtpmtss.so available since 5.5
- libnttfft.so available since 5.5
- libmgf1.so available since 5.5.1

Bug#848890: [Pkg-swan-devel] Bug#848890: Revisiting "Ubuntu strongSwan changes"

Background to explain the reasoning behind the change 1/7:

Commits:
0733afe * d/rules: Reorganize to ease maintenance
be360c3 changelog: d/rules: Reorganize to ease maintenance
45adecc * d/control: Wrap and sort to ease maintenance
00bcdba changelog: d/control: Wrap and sort to ease maintenance

Background:
Diffs to the enabling / disabling options turned out to be very noisy.
That is due to multiple options being on one line, so a diff can easily be
misread.
Is it adding something, or removing - or actually chaning.

A common recommendation to avoid this issue is to have the entries
"one-per-line" (to avoid the diff noise) and sorted (to avoid duplicates by
adding e.g. at the bottom while being already at the top).

Ubuntu did have the diff of 0733afe this as a Delta to d/rules for quite a
while - and the change is purely cosmetical and should have no
functional impact, but helps maintenance.

The same applies to most files in debian/*. It is such a common need that
there is actually a Tool which does most of that for you "wrap and sort".
I realized while explaining we should add that right away as well,
so this 6872c7c is fixing up d/control by using that tool.

Bug#848890: [Pkg-swan-devel] Bug#848890: Revisiting "Ubuntu strongSwan changes"

Background to explain the reasoning behind the change 5/7:

Commits:
6bf2bf5 * Add basic DEP8 tests
6f408a9 changelog: Add basic DEP8 tests

As basic CI dep8 based autopkgtests provide a very useful level of automated
sanity checks to become part of debci at https://ci.debian.net/.
See https://people.debian.org/~mpitt/autopkgtest/README.package-tests.html
for
basics.

This commit adds some basic smoke tests for strongswan:
- admin-strongswan-charon and admin-strongswan-starter: are the commands
for an
  admin built, installed by the right package and executable.
- daemon: are the daemons running after a default installation
- plugins: check if all expected-to-be-loaded plugins are loaded and vice
versa
  check that all expected-not-to-be-loaded (default off) plugins are not.

Bug#848890: [Pkg-swan-devel] Bug#848890: Revisiting "Ubuntu strongSwan changes"

 Background to explain the reasoning behind the change 4/7:

Commits:
59e9a0b * add and install apparmor profiles
3d124a4 changelog: Add and install strongswan apparmor profiles

Make the usage of strongswan even more secure by providing an apparmor
profile
for it.

This change add the necessary build dependencies, installs the profiles and
provides profiles for charon, lookip and stroke.

As usual best practise in case the profiles turn out to be too restrictive
for
a very special not considered setup they all provide includes to local
overrides. That allows to modify the rules as needed without causing file
conflicts on further updates to the package delivered profiles.

Bug#848890: [Pkg-swan-devel] Bug#848890: Revisiting "Ubuntu strongSwan changes"

I hope that these more detailed explanations help to clarify the reasoning.
I'm likely away for the rest of the Year soon, but please let me know what
might still be missing (or on what particular point you'd like to discuss
some bits).
I really want to work with you to get us in sync as much as possible for
the benefit
of both of us.

P.S. hopefully no debbug spam detector now hates me after this mail flood
:-)

Bug#848890: [Pkg-swan-devel] Bug#848890: Revisiting "Ubuntu strongSwan changes"

Background to explain the reasoning behind the change 6/7:

Commits:
514dc31 * Add updated logcheck rules to match recent strongswan output
ab32a3f changelog: Add updated logcheck rules to match recent strongswan
output

When using logcheck with strongswan as of today there are a lot of unknown
messages reported.
This change updates it to the now used log output, so that logcheck can
ignore
those expected messages.

This change is a carry forward for a while now, we might have to update
it to match strongswan 5.5, yet it should match better than the currently
supplied logcheck files - so it should be a good first step.

Note: The new rules make no difference on the logcheck report levels
anymore.

Bug#848890: [Pkg-swan-devel] Bug#848890: Revisiting "Ubuntu strongSwan changes"

On Tue, Dec 20, 2016 at 5:21 PM, Yves-Alexis Perez 
wrote:

> I hope it's clearer.


Yeah that is good, I'll prep something and reply to this bug with mails
one-by-one once I'm ready.
I might update the branch I had linked if I happen to improve the changelog
and or other comments.

Will submit the reasoning later today - thanks for your guidance!

Bug#848317: [Pkg-libvirt-maintainers] Bug#848317: not arch dependent but racy

On Mon, Dec 19, 2016 at 6:37 PM, Guido Günther  wrote:

> Great. Now that you found a way to reproduce it should be possible to
> cook a patch for upstream that fixes this!
>

While I'd love to do so, a morning of failed debugging cut that approach at
least for now.
I'll share what I found to the bug in consecutive updates and close with a
interim recommendation.

Bug#848317: [Pkg-libvirt-maintainers] Bug#848317: not arch dependent but racy

I was setting up a VM independent of autopkgtests to debug this further,
but so far only confirmed what I had already:
Yet as documentation if we later on need to refer to that data:

Logs of journalctl -fex and the libvirt log on sl guest when doing the
killing restart

# Before:
$ virsh list --all
 IdName   State

 3807  sl running

# Then on restart
$ /etc/init.d/libvirtd restart

# /var/log/libvirt/lxc/sl.log:
 3807: info : hostname: zesty-test-smoke-lxc
 3807: error : virNetSocketReadWire:1801 : End of file while reading data:
Input/output error

# journalctl -fex:
[...] normal stopping / starting message - then after "libvirtd.service has
finished starting up":
 libvirtd[4073]: internal error: No valid cgroup for machine sl
 audit[4125]: AVC apparmor="STATUS" operation="profile_remove"
profile="unconfined" name="libvirt-354e2b39-9c30-4080-9323-23d27f8d2cf8"
pid=4125 comm="apparmor_parser"
 kernel: audit: type=1400 audit(1482226905.416:21): apparmor="STATUS"
operation="profile_remove" profile="unconfined"
name="libvirt-354e2b39-9c30-4080-9323-23d27f8d2cf8" pid=4125
comm="apparmor_parser"
 libvirtd[4073]: End of file while reading data: Input/output error


# The guest appears as shut off now (sometimes I have to restart twice to
get the guest listed here again):
$ virsh list --all
 IdName   State

 - sl shut off


So the "root cause" still appears as: "internal error: No valid cgroup for
machine sl"
After that it is on the kill path, removing the profile but no other error
shows up.

I saved some /etc/libvirt and cgroup info.
But no content in any of those changed between bad case (after first
restart) and good case (after staring the guest once again).

I don't see where it is "fixing itself up" after starting the guest again
:-/
And I'd have hoped that this would be my entry point to find a fix.

Bug#848317: [Pkg-libvirt-maintainers] Bug#848317: not arch dependent but racy

Summary of minimal steps to reproduce:

1. Spawn new KVM Guest of your choice
2. install test dependencies
$ apt-get install libvirt-daemon-system libvirt-clients libxml2-utils
3. run the following sequence as root
export LIBVIRT_DEFAULT_URI=lxc:///
cat << EOF > /tmp/smoke-lxc.xml

  sl
  256000
  256000
  1
  
exe
/bin/bash
  
  

  
  
  
/usr/lib/libvirt/libvirt_lxc

  
  


  

  

EOF
virt-xml-validate /tmp/smoke-lxc.xml
virsh define /tmp/smoke-lxc.xml
virsh start sl
virsh list --all
# is running now
/etc/init.d/libvirtd restart
virsh list --all
# is no more running, but it should

Bug#848317: [Pkg-libvirt-maintainers] Bug#848317: not arch dependent but racy

I agree that it eventually has to be resolved and fixed upstream, but at
least I seem to be unable to find the spot in this haystack of cgroup
things.
So until this bug is properly resolved I'd ask to skip this particular part
of the smoke test.

BTW - the isolation level requirement I mentioned before still applies as
well - the reason is fixed in lxc, but might need an extra tweak to apply
to libvirt-lxc.
https://github.com/lxc/lxc/issues/680 for more on the lxc side of things.

So a "fix" for now to get the smoke test running would be as attached:

Please keep this bug open until the root cause is really resolved.
But I'd ask to apply the patch I atatched to get the rest of your test
coverage up and running independent of this issue for now.
commit fd86517ea921bbcd21f3af678713a2a6f83d0372
Author: Christian Ehrhardt <christian.ehrha...@canonical.com>
Date:   Mon Dec 19 17:05:28 2016 +0100

workaround for debbug 848317 (lxc restart sometimes kills guests)

    Signed-off-by: Christian Ehrhardt <christian.ehrha...@canonical.com>

diff --git a/debian/tests/smoke-lxc b/debian/tests/smoke-lxc
index 7d07815..20e768f 100755
--- a/debian/tests/smoke-lxc
+++ b/debian/tests/smoke-lxc
@@ -37,8 +37,9 @@ virsh start ${DOMAIN}
 grep -qs "starting up" /var/log/libvirt/lxc/sl.log
 check_domain
 # Make sure a restart doesn't termiante the domain
-/etc/init.d/libvirtd restart
-check_domain
+# skip until debbug #848317 is resolved
+#/etc/init.d/libvirtd restart
+#check_domain
 virsh destroy ${DOMAIN}
 virsh undefine ${DOMAIN}
 CLEANED_UP=1
commit 20a59e25a04c81758879bb78b4eb030c50584a25
Author: Christian Ehrhardt <christian.ehrha...@canonical.com>
Date:   Mon Dec 19 17:04:46 2016 +0100

fixup smoke-lxc tests which requires more isolation

Signed-off-by: Christian Ehrhardt <christian.ehrha...@canonical.com>

Notes:
This could be a reoccurance of these issues in a different scope:
https://github.com/lxc/lxc/issues/680
Maybe the rule needs to get in for libvirt-lxc as well?
To get the tests running reliably we now set isolation machine which is
avoiding this for the dep8 test.

diff --git a/debian/tests/control b/debian/tests/control
index 6b99112..f6432d9 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -9,7 +9,7 @@ Restrictions: allow-stderr, isolation-container
 
 Tests: smoke-lxc
 Depends: libvirt-daemon-system, libvirt-clients, libxml2-utils
-Restrictions: allow-stderr, needs-root
+Restrictions: allow-stderr, needs-root, isolation-machine
 
 Tests: build-test
 Depends: libvirt-dev, build-essential, pkg-config

Bug#848317: [Pkg-libvirt-maintainers] Bug#848317: not arch dependent but racy

For the long term solution given that I can't find the root cause I
reported it upstream to libvirt list but kept you on cc there.
Please note that I even reproduced back to libvirt 1.3.1 so I doubt it is a
regression, but more likely never worked.

Bug#848890: Revisiting "Ubuntu strongSwan changes"

Package: strongswan
Version: 5.5.1-2
Severity: normal

Hi,
this is - to some extend - the resurrection of a zombified thread from 3
years ago.
Reference:

http://lists.alioth.debian.org/pipermail/pkg-swan-devel/Week-of-Mon-20131230/09.html

http://lists.alioth.debian.org/pipermail/pkg-swan-devel/Week-of-Mon-20140106/10.html

http://lists.alioth.debian.org/pipermail/pkg-swan-devel/Week-of-Mon-20140106/11.html

http://lists.alioth.debian.org/pipermail/pkg-swan-devel/Week-of-Mon-20140120/12.html

The person who was driving that back then stopped working on it and since
then strongswan was mostly in an "it is what it is" state with a huge Delta
that makes maintenance hard and error prone.
OTOH Debian could not benefit from all the work that was done.

In the least three Ubuntu development cycles a friend of mine and I tried
to clean up the Ubuntu Strongswan packaging as much as possible and I think
it is now ready (again?) to be fed back to improve Debian.

I isolated the less opinionated changes of our Delta and wanted feed all of
them back to Debian.
Some of them are just cleanups and minor fixes to issues that apply to
Debian as well.
The final bigger change is the reworked enablement of more features in
Strongswan as discussed back in 2013/14.

I pushed all the changes in a git branch so you can easily check them out
one by one.
I'd ask you to review and to pick them up if you agree.

LP-GIT:
https://code.launchpad.net/~paelzer/ubuntu/+source/strongswan/+git/strongswan/+ref/debian-submission

(git clone -b debian-submission
https://git.launchpad.net/~paelzer/ubuntu/+source/strongswan)

If there are discussions please reply here and I hope we can hopefully sort
it out.

--
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Bug#848891: Remove outdated code