Monday, 17 September 2018

Re: Transition of LXD from deb to snap

On Wed, Sep 12, 2018 at 02:42:00PM -0400, Stéphane Graber wrote:
> On Tue, Aug 21, 2018 at 04:39:46PM -0400, Stéphane Graber wrote:
> > On Tue, Aug 21, 2018 at 03:35:11PM -0400, Stéphane Graber wrote:
> > > On Tue, Aug 21, 2018 at 12:25:33PM -0700, Steve Langasek wrote:
> > > > On Tue, Aug 21, 2018 at 03:03:48PM -0400, Stéphane Graber wrote:
> > > > > > > A branch of the stable channel of those tracks will be created and
> > > > > > > closed per policy on seeded snaps (allowing to push emergency snaps to
> > > > > > > those users bypassing the upstream).
> > > >
> > > > > > Excellent!
> > > >
> > > > > I actually had a question about that part, the wiki says to create an
> > > > > ubuntu-18.10 branch and use that during snap installation.
> > > >
> > > > > But then what's responsible for switching this to a ubuntu-19.04 branch
> > > > > during the next upgrade?
> > > >
> > > > Support for this has landed in ubuntu-release-upgrader 1:18.10.8 in cosmic;
> > > > LP: #1748581. Note that this is based on a whitelist of known seeded snaps
> > > > that are encoded in u-r-u as part of the quirks handling (which is not ideal
> > > > since it duplicates the package seeds), so this will need to be updated to
> > > > include the lxd snap here.
> > >
> > > Hmm, interesting, though it looks like the logic in the upgrader here is
> > > a bit lacking and may lead to data corruption or at least broken snaps.
> > >
> > > It appears to just run "snap refresh <name>
> > > --channel=stable/ubuntu-18.10" which means a potential track switch and
> > > channel switch for users that have seen decided to switch to another
> > > channel or track.
> > >
> > >
> > > Commented in the bug, I suspect this bug needs to be re-open and the
> > > logic revisited.
> > >
> > > https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1748581
> > >
> > > > > Since the same version of the snap will be pushed to all Ubuntu series,
> > > > > wouldn't it make more sense to have it just be "ubuntu", saving us the
> > > > > trouble of having to figure out what to do on Ubuntu release upgrades
> > > > > and reflecting the fact that the snap is the same for all series.
> > > >
> > > > This escape hatch exists precisely for the case that the upstream stable
> > > > snap does not integrate correctly in a release-agnostic fashion and
> > > > per-Ubuntu-release quirking is needed. Better to have it and never use it
> > > > than to need it and not have it.
> > >
> > > Yeah, if we fix the upgrader to handle the above properly
> > > (and as suggested in the LP bug), then that should be fine.
> >
> >
> > I've now updated the PPA with version ~ppa5.
> >
> > This includes:
> > - Using the ubuntu-XX.XX branches (created and closed)
> > - Debconf prompts are now high except for the unreachable store one
> > which is critical
> > - Added logic to select the "3.0" track for LTS releaes
> > - Added noninteractive logic to print a message a 0, 10 and 20 minutes,
> > trying connection every minute and giving up after 30.
> > - Stop & disable the old systemd services to avoid any conflicts
> >
> > I've validated all combinations of those variables:
> > - series: 18.04 and 18.10
> > - debconf: interactive (curses), interactive (text) and noninteractive
> > - connectivity: available, unavailable, available after a few minutes
>
> All rdepends of lxd and lxd-client have been tested to behave properly
> with the LXD snap and our deb shim.
>
> I will now be uploading the transitional LXD deb to the archive, holding
> it in -proposed until Monday so anyone interested can test it that way
> and we can sort out any autopkgtest issue that may arise.
>
> On Monday, I'll remove the blocker tag which should have it migrate to
> the release pocket, I'll land a seed change at the same time, removing
> lxd and lxd-client from the supported server seed and replacing lxd with
> snap:lxd in the server ship seed.
>
>
> This will then cause our images to start shipping the LXD snap rather
> than the deb, we can then sort out any issue that show up as a result
> of that change (should there be any).
>
>
> Note that at this time, the LXD snap isn't using socket activation yet.
> We have code in place for that in the edge channel but want to do more
> tests on it before we roll it out to all our users. This means that
> starting on Monday, LXD will be starting up unconditionally on 18.10
> images. This is a temporary situation and will be corrected by release.

The package is now in the release pocket and the seeds have been updated.

--
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
Posted by at

Friday, 14 September 2018

Cosmic Cuttlefish test rebuilds

The first test rebuild of Cosmic Cuttlefish was started on September 11 2018 for
all architectures, all components (main component and seeded packages finished,
unseeded packages still building). The number of build time failures
unfortunately is again high.

The test rebuild was done using the openjdk-11 packages from the openjdk-r/ppa
PPA (cosmic still has OpenJDK-10, instead of the OpenJDK-11 packages used for
the rebuild.

Results (please also look at the superseded builds) can be found at

http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20180911-cosmic.html

The report uses some additional color coding, marking packages different which
always failed to build, or where the build failure is no regression compared to
bionic.

Additional build failures for packages in bionic-proposed (not yet in bionic)
can be found at http://qa.ubuntuwire.com/ftbfs/

Please help fixing the build failures.

Matthias

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Posted by at

xenial (16.04 LTS) and bionic (18.04 LTS) test rebuilds

There are four test rebuilds done for xenial and bionic (main only), both the
release and the updates pockets. The results of both builds are combined in one
table. Please see

http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20180727-main-xenial.html

http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20180730-bionic.html

The table also has some new color codes to mark packages which always failed to
build, and for packages which failed to build in a reference release.

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Posted by at

Wednesday, 12 September 2018

Re: Transition of LXD from deb to snap

On Tue, Aug 21, 2018 at 04:39:46PM -0400, Stéphane Graber wrote:
> On Tue, Aug 21, 2018 at 03:35:11PM -0400, Stéphane Graber wrote:
> > On Tue, Aug 21, 2018 at 12:25:33PM -0700, Steve Langasek wrote:
> > > On Tue, Aug 21, 2018 at 03:03:48PM -0400, Stéphane Graber wrote:
> > > > > > A branch of the stable channel of those tracks will be created and
> > > > > > closed per policy on seeded snaps (allowing to push emergency snaps to
> > > > > > those users bypassing the upstream).
> > >
> > > > > Excellent!
> > >
> > > > I actually had a question about that part, the wiki says to create an
> > > > ubuntu-18.10 branch and use that during snap installation.
> > >
> > > > But then what's responsible for switching this to a ubuntu-19.04 branch
> > > > during the next upgrade?
> > >
> > > Support for this has landed in ubuntu-release-upgrader 1:18.10.8 in cosmic;
> > > LP: #1748581. Note that this is based on a whitelist of known seeded snaps
> > > that are encoded in u-r-u as part of the quirks handling (which is not ideal
> > > since it duplicates the package seeds), so this will need to be updated to
> > > include the lxd snap here.
> >
> > Hmm, interesting, though it looks like the logic in the upgrader here is
> > a bit lacking and may lead to data corruption or at least broken snaps.
> >
> > It appears to just run "snap refresh <name>
> > --channel=stable/ubuntu-18.10" which means a potential track switch and
> > channel switch for users that have seen decided to switch to another
> > channel or track.
> >
> >
> > Commented in the bug, I suspect this bug needs to be re-open and the
> > logic revisited.
> >
> > https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1748581
> >
> > > > Since the same version of the snap will be pushed to all Ubuntu series,
> > > > wouldn't it make more sense to have it just be "ubuntu", saving us the
> > > > trouble of having to figure out what to do on Ubuntu release upgrades
> > > > and reflecting the fact that the snap is the same for all series.
> > >
> > > This escape hatch exists precisely for the case that the upstream stable
> > > snap does not integrate correctly in a release-agnostic fashion and
> > > per-Ubuntu-release quirking is needed. Better to have it and never use it
> > > than to need it and not have it.
> >
> > Yeah, if we fix the upgrader to handle the above properly
> > (and as suggested in the LP bug), then that should be fine.
>
>
> I've now updated the PPA with version ~ppa5.
>
> This includes:
> - Using the ubuntu-XX.XX branches (created and closed)
> - Debconf prompts are now high except for the unreachable store one
> which is critical
> - Added logic to select the "3.0" track for LTS releaes
> - Added noninteractive logic to print a message a 0, 10 and 20 minutes,
> trying connection every minute and giving up after 30.
> - Stop & disable the old systemd services to avoid any conflicts
>
> I've validated all combinations of those variables:
> - series: 18.04 and 18.10
> - debconf: interactive (curses), interactive (text) and noninteractive
> - connectivity: available, unavailable, available after a few minutes

All rdepends of lxd and lxd-client have been tested to behave properly
with the LXD snap and our deb shim.

I will now be uploading the transitional LXD deb to the archive, holding
it in -proposed until Monday so anyone interested can test it that way
and we can sort out any autopkgtest issue that may arise.

On Monday, I'll remove the blocker tag which should have it migrate to
the release pocket, I'll land a seed change at the same time, removing
lxd and lxd-client from the supported server seed and replacing lxd with
snap:lxd in the server ship seed.


This will then cause our images to start shipping the LXD snap rather
than the deb, we can then sort out any issue that show up as a result
of that change (should there be any).


Note that at this time, the LXD snap isn't using socket activation yet.
We have code in place for that in the edge channel but want to do more
tests on it before we roll it out to all our users. This means that
starting on Monday, LXD will be starting up unconditionally on 18.10
images. This is a temporary situation and will be corrected by release.

--
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
Posted by at

Thursday, 6 September 2018

Re: call for testing -- qemu / libvirt sandboxing on 18.04 LTS


On Thu, Sep 6, 2018 at 8:20 PM Seth Arnold <seth.arnold@canonical.com> wrote:
Hello,

Jann Horn has discovered that qemu's seccomp blacklist is not properly
applied to all threads. This means the security hardening is nearly
useless.

We'd like to fix this issue so the users who opt-in to the seccomp
filtering will get the benefits they expect. However, this change feels
like it brings more than the usual amount of regression risk, so we'd like
to call for tests from the wider community.

If you're in a position to try an updated qemu package on 18.04 LTS,
we'd like to hear your results.

Hi Seth,
after none of us sent the mail it seems now we both did :-)
So let me add some references here FYI.
I had already sent the same at [1][2]

We had one reply [3] so far with a TL;DR of:
- yes sandbox feature is used
- proposed change works

 
The bug report to coordinate the effort:
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1789551
The package repository:
https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3395

You may need to set seccomp_sandbox = 1 in your /etc/libvirt/qemu.conf
and restart the libvirt service and any running VMs.

Some errors may be difficult to spot. Some kernels will report seccomp
denials to dmesg or auditd and some kernels will not report anything.

Thanks
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel


--
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd
Posted by at

Tuesday, 4 September 2018

Call for testing to qemu -sandbox users

Hi,
TL;DR: If you enabled -sandbox in your Bionic qemu, please test the PPA [2]

Details:
There is a CVE [1] which we fixed in Cosmic [3], but are unsure to backport to Bionic.
Reasons for that are:
- there is some regression risk associated which we want to minimize
- the sandbox feature it fixes is not enabled by default on Bionic (it is in Cosmic)

Per discussion between me and the security Team there are two things gating the backport of this to Bionic.
1. We'd want to know if anybody actually enables -sandbox explicitly in Bionic?
2. if so, it would be great if one of those with a real case could do a verification based on the ppa [2]

In case there is no feedback here (this poll might work, but no reply doesn't mean too much) we likely will wait until Cosmic is released for quite a while. That will implicitly test the -sandbox feature including the fix.


P.S.: sorry for the cross post, but this is trying to maximize the chance to actually find somebody with the conditions in a real setup

--
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd
Posted by at

Monday, 3 September 2018

Re: glibc 2.28 autopkgtest failures

On Tue, 4 Sep 2018 at 13:26, Michael Hudson-Doyle <michael.hudson@canonical.com> wrote:
tl;dr we should force things through :)

There are at the time of writing two autopkgtest failures preventing glibc from migrating: r-cran-rgenoud and python-cffi

The r-cran-genoud failure is mystifying in that I have no idea how the glibc version is affecting the package (it doesn't call many libc or libm functions!). I've spent far too long trying on this but as the package has no rdeps we should probably just remove it and whoever brings it back can try to understand why it changes behaviour with new libc. (The test also looks a bit fragile, it is asserting that optimizing a particular function with the rng seeded a particular way finds a different maxima to seeding the rng a different way, afaict).

The python-cffi is exposing a bug that exists already. A minimal failing example is this:

[...]
 
The bug is that when you lie to cffi about the return type of a variable, in particular when you say a function returning a float does not return a float, the x87 stack is not wiped to the extent required by the calling convention. glibc 2.28 rewrote the cos function in a way that apparently now cares about this (or I guess gcc now compiles the function in a way that cares about this) but make no mistake, it only ever worked by chance before. So I think the test_sin_no_return_value test should be skipped on i386. 

Unfortunately, python-cffi is now failing to build on ppc64el. Code like this (where "source" is a double and target is a valid pointer):

    float r = (float)source;
    memcpy(target, &r, sizeof(float));

is getting compiled into code which doesn't call frsp (round to single precision), which seems very wrong to me. It works if you compile it with gcc-7 or with gcc-8 and no optimization. I've managed to reproduce it like this:

(cosmic-ppc64el)root@diamond:/# cat u.c
#include <math.h>
#include <stdlib.h>
#include <stdio.h>
#include <string.h>

char buf[4];

void write(double x) {
        float y = (float)x;
        memcpy(buf, &y, 4);
}

float read(void) {
        float r;
        memcpy(&r, buf, 4);
        return r;
}

int main(int argc, char**argv) {
        double x;
        x = strtod(argv[1], NULL);
        write(x);
        printf("%g\n", (double)read());
        return 0;
}
(cosmic-ppc64el)root@diamond:/# gcc -fno-inline -O1 -o u u.c
(cosmic-ppc64el)root@diamond:/# ./u 1e200
2.19181e+07

and unless someone can see something wrong in my C code, this looks like a compiler bug :(

Cheers,
mwh
Posted by at
Subscribe to: Posts (Atom)