[05:48] <pitti> Good morning
[07:29] <dholbach> good morning
[07:31] <sladen> Morgen
[09:22] <mvo> pitti: hi, juliank discovered that a autopkgtest fails on s390 and armhf with "WARNING: CHROOTing to /tmp/tmp.UsVnmk3JLH/rootdir was ignored!" is there anything we can do about that ?
[09:23] <juliank> Maybe because those are run on lxc?
[09:23] <pitti> yes, those are in LXC, the other arches run in VMs
[09:23] <pitti> I guess you can't chroot() in LXC
[09:27] <juliank> pitti: On Debian's amd64 lxc instance it works, though
[09:28] <pitti> juliank: I suppose  it's limited by the apparmor profile
[09:28] <pitti> (which Debian doesn't have)
[09:29] <juliank> Can we do anything about that? We obviously need that for our test suite to work correctly because we're testing interaction with dpkg amongst other things
[09:30] <jjohansen> depends, Debian can have the lxc profile, but they are running the mainline kernel version of apparmor
[09:30] <jjohansen> so it is missing some things, the userspace side is largely up to date
[09:36] <pitti> juliank: with chroot() you can easily escape the container, so I'd rather leave tests as "always failed" on the LXC arches
[09:39] <juliank> OK.
[09:39] <juliank> I'll try to at least get the i386 tests passing, currently they only work on amd64
[09:39] <pitti> juliank: which package is that, OOI?
[09:39] <juliank> pitti: apt
[09:40] <juliank> The failure on i386 is just because we only run the suite on amd64, and thus have bugs...
[09:40] <pitti> juliank: right, so they are "always failed" on all but amd64, so they won't hold up proposed migration
[09:40] <pitti> so that's not urgent
[09:41] <juliank> pitti: It's annoying me a bit, though :) [ppc64el should work too, then]
[10:07] <juliank> pitti: We are not actually chrooting(), but preloading a no-op chroot() library. What happens is that we rewrite all execvpe() calls to run <CHROOTDIR>/COMMAND instead of COMMAND, with DPKG_ADMINDIR=<CHROOTDIR>/var/lib/dpkg. So, does the apparmor profile prevent us from executing stuff in /tmp?
[10:08] <juliank> We get a "No such file or directory" when trying to execute the rewritten script path
[10:08] <juliank> For example, /tmp/tmp.Z4pabkgrXk/rootdir/var/lib/dpkg/info/triggerable-interest-noawait.postinst
[10:09] <juliank> execvp(), not execvpe()
[10:10]  * juliank would have expected some permission denied thing, though
[10:13] <juliank> If we could get a log of apparmor during an autopkgtest run, that would probably be useful.
[11:22] <pitti> juliank: I can start a test run manually and check in the container, hang on
[11:29] <xnox> pitti, looking at http://autopkgtest.ubuntu.com/data/status/xenial/amd64/status.json and http://autopkgtest.ubuntu.com/data/status/xenial/s390x/status.json -> i do not believe that there are move autopkgtests for s390x than there are for amd64 =)
[11:30] <xnox> or what do those numbers mean?
[11:30] <pitti> xnox: that actually seemse right
[11:30] <pitti> xnox: as over the weekend I triggered *all* available autopkgtests on s390x
[11:30] <pitti> xnox: but we don't do that for the other arches, they only run if britney triggers them
[11:30] <pitti> xnox: and there's a bunch of packages which haven't changed since wily and thus never ran for xenial
[11:31] <xnox> pitti, hm, so there are tests that never been run on amd64?
[11:31] <pitti> (or their dependencies)
[11:31] <xnox> oh.
[11:31] <pitti> xnox: not in xenial; they ran in wily (or even earlier for packages that seldomly change)
[11:31] <xnox> that makes comparison between arches odd.
[11:32] <xnox> pitti, can you trigger *everything* on amd64 & ppc64el?
[11:32] <pitti> xnox: I'd need to trigger only the ones which didn't run since wily
[11:32] <pitti> "everything" on these will take way too long
[11:32] <xnox> yeap, like that.
[11:33] <pitti> xnox: yes, I can, the main piece of work is to figure out the list of packages
[11:33] <xnox> cause i want to compare the same ballpark numbers on s390x vs others. for test-report...
[11:33] <xnox> pitti, i can do that from json for you, if you wish?
[11:33] <pitti> xnox: you mean the pass/fail ones?
[11:33] <pitti> xnox: that'd be great, yes
[11:33] <pitti> xnox: btw, fancy graphs: http://autopkgtest.ubuntu.com/status/
[11:34] <xnox> pitti, yeah those graphs are missleading =) as e.g. amd64/ppc64el have less packages and higher pass rate. s390x has more packages and lower pass-rate (even when package count adjusted) cause loads of things are still uninstallable.
[11:35] <xnox> i'm doing what nobody should do, that is rerun tests to bring amd64 to reality such that it is comparable with s390x ;-)
[11:35] <pitti> xnox: so, ~ 92% pass rate on i386, ~ 80% on armhf (using LXC), and roughly 70% on s390x (also LXC)
[11:36] <xnox> when opening new series, can you not copy over old results from previous release? such that we get pkg count continuity?
[11:36] <xnox> or trigger all on opening...
[11:36] <pitti> xnox: I could; so far I only copy over the last successful result (if any), to tell apart "always failed" vs. "regression" across new series
[11:36] <pitti> xnox: but as this isn't necessary for "always failed" packages I don't copy those
[11:39] <pitti> juliank: btw, there's other errors like
[11:39] <pitti> -fancy
[11:39] <pitti>  specific
[11:39] <pitti> +fancy
[11:39] <pitti> juliank: (i. e. ordering); I'm running the apt test on armhf manually, so far I haven't run into apparmor violations yet
[11:40] <pitti> ah, but it's only at test 45, the first of that is 132
[11:46] <juliank> pitti: Yeah the other issues are somewhat strange but unrelated.
[11:46] <juliank> It's just ordered differently for whatever reasons
[11:50] <xnox> $ wc -l *.missing
[11:50] <xnox>   553 amd64.missing
[11:50] <xnox>   585 armhf.missing
[11:50] <xnox>   500 i386.missing
[11:50] <xnox>   799 ppc64el.missing
[11:50] <xnox>     0 s390x.missing
[11:50] <xnox>  2437 total
[11:50] <xnox> pitti, http://bazaar.launchpad.net/~xnox/+junk/missing-autopkgtests/files
[11:51] <xnox> pitti, run.sh is how i generated them, *.missing files are the ones to trigger per arch, which did not yet run on xenial it would seem. Would you please check my work for sanity before triggering?
[11:51]  * xnox thinks the above triggers are too high.
[11:51] <pitti> xnox: heh, e. g. http://autopkgtest.ubuntu.com/packages/libx/libxml-tidy-perl/ never ran :)
[11:52] <xnox> pitti, so it is correct right? =) only ever run on xenial/s390x =)
[11:52] <pitti> I guess the autodep8 stuff landed later than the last change to it
[11:53] <pitti> xnox: and e. g. http://autopkgtest.ubuntu.com/packages/l/lmod/ is a case where xenial version == wily version
[11:53] <pitti> xnox: so some spot checks seem fine
[11:53] <pitti> juliank: I'm getting the chroot warnings now, no apparmor violations
[11:54] <juliank> pitti: OK. Then something stranger is going on. Thanks for testing.
[11:54] <xnox> pitti, well please trigger these then =)
[11:54] <pitti> juliank: as soon as the test finishes I can ssh into the container, if you want me to run anything
[12:06] <juliank> pitti: I'm looking at building something, it's somewhat hard though. We build this library: https://paste.debian.net/344216/.
[12:06] <juliank> pitti: I think I found the bug. It's an off by one, newfile is one byte to short
[12:07] <pitti> juliank: ah!
[12:07] <pitti> juliank: please consider using this:
[12:07] <pitti> char newfile[PATH_MAX];
[12:07] <pitti> snprintf(newfile, sizeof(newfile), "%s/%s", path1, path2);
[12:07] <pitti> juliank: snprintf() is so much safer and avoids these gotchaas
[12:08] <pitti> every strcpy() and strcat() eliminated from production code makes a dead kitten get back to life somewhere! :-)
[12:10] <pitti> xnox: do you really need all the arches for comparison? isn't amd64 or armhf sufficient?
[12:10] <pitti> xnox: I now transformed your lists into run-autopkgtest commands with appropriate --trigger arguments, running amd64 now
[12:10] <xnox> pitti, amd64 will do for this week, and rerun everything else on the weekend / holidays?
[12:11] <pitti> but running 500 tests will take a fair while, I'm not going to launch the i386 ones right away
[12:11] <pitti> xnox: sounds fine
[12:11] <pitti> xnox: http://autopkgtest.ubuntu.com/running.shtml#queue-xenial-amd64
[12:11] <xnox> imho for next series you should copy all the results otherwise we under-report the amount of testing we do.
[12:11] <pitti> yeah, can do
[12:11] <xnox> pitti, \o/ thanks.
[12:11] <pitti> xnox: you are the first to notice/ask about statistics
[12:12] <xnox> hehe.
[12:14] <pete-woods> pitti: sorry to keep nagging, but is there any chance you could do a backport of the latest dbusmock release into the vivid overlay?
[12:15] <pitti> pete-woods: it hasn't landed in xenial yet, stuck on the test regression
[12:15] <pitti> so, don't want to backport yet, this first needs looking into
[12:15] <pete-woods> pitti: ah, hadn't realised that
[12:15] <pete-woods> okay
[12:15] <pete-woods> I will have a look at that then
[12:20] <pete-woods> pitti: https://github.com/martinpitt/python-dbusmock/pull/18/files how about that?
[12:20] <pete-woods> (copied the same setup from test_bluez5.py)
[12:20] <pete-woods> to me it looked like *something* was running the tests individually
[12:20] <pitti> pete-woods: oh nice! do you know what triggered that in your last PR?
[12:21] <pete-woods> pitti: I added a test that did sorta async stuff from the bluez test
[12:21] <pete-woods> where you wait for a bunch of signals to be emitted
[12:21] <pitti> ah, async needs a main loop indeed
[12:21] <pete-woods> but the weird thing is the tests work fine when you run the full suite
[12:21] <pete-woods> maybe that's because the bluez one has already setup the mainloop..
[12:22] <pitti> cd tests
[12:22] <pitti> for f in *.py; do
[12:22] <pitti>     python3 $f
[12:22] <pitti> done
[12:22] <pitti> pete-woods: ^ the autopkgtest does that
[12:22] <pete-woods> right
[12:22] <pitti> pete-woods: yeah, very likely
[12:22] <pete-woods> well that would explain it
[12:23] <pitti> pete-woods: we want to run the tests against the installed py module, so we can't use ./setup.py
[12:23] <pete-woods> fair enough
[12:23] <pete-woods> I have no python-fu
[12:23] <pete-woods> I just type til it stops erroring
[12:25] <pitti> pete-woods: works fine, thanks
[12:25] <pete-woods> cool
[12:32] <pitti> pete-woods: 0.16.3 released and uploaded to Debian; for the backport, I take it vivid+wily?
[12:34] <pitti> pete-woods: uploaded backports to both; thanks for the fix!
[12:36] <pete-woods> pitti: thanks very much, I don't really care about wily too much, but may as well do both just in case
[13:35] <xnox> infinity, may i steal your strace pending merge?
[13:36] <infinity> xnox: Sure.
[13:56] <xnox> infinity, fails on i386 with one fail, fails a lot more on s390x =( here is to new upstream release fixing nothing....
[13:58] <infinity> xnox: Looks fine in Debian build logs.  So, that's curious.
[13:59] <xnox> mono gdoc fails to bootstrap with -O2, strace failures. something odd is going on.
[13:59] <xnox> *mdoc
[14:47] <teward> should I be highly concerned when my sbuild schroot complains with "W: No sandbox user '_apt' on the system, can not drop privileges"
[14:47] <teward> (it's a Xenial schroot)
[14:53] <cyphermox> has it already done some upgrades before showing that message?
[14:54] <infinity> teward: That's because the user doesn't exist outside the chroot, and schroot copies in your external /etc/passwd
[14:54] <infinity> teward: It's mostly harmless.
[15:05] <xnox> infinity, retrying strace/i386 made it "pass" the test-suite.....
[15:05]  * xnox looses confidence in strace testsuite
[15:05] <thebwt> howdy folks! I'm putting together a chart for a history of Ubuntu. Before lucid, Ubuntu was derived from Debian Sid. Was it a frozen Sid at the time of release? (trying to show the relationship overtime to debian)
[15:07] <geofft> can someone who can see private bugs tell me what LP #723515 is?
[15:07] <geofft> or where should I ask?
[15:08] <infinity> geofft: Ask the security team.  If it's an ubuntu bug, they can see it.
[15:08] <geofft> I believe that it is a bug in Ubuntu glibc
[15:08] <infinity> geofft: If it's not, then the only people likely to be able to see it are LP admins, to #canonical-sysadmin
[15:08] <geofft> er, gcc
[15:08] <infinity> Actually, wait, I'm in the security team and I can't see it. :P
[15:08] <infinity> So, no.  It's probably not an Ubuntu bug.
[15:09] <xnox> infinity, >_< #identitycrisis
[15:09] <infinity> xnox: *cough*
[15:09]  * xnox slowly backs away
[15:09] <infinity> xnox: Using hashtags on IRC should be punishable by death.
[15:10] <geofft> I am pretty sure the kids these days are saying things like "hashtag ubuntu-devel"
[15:10] <xnox> infinity, wait till Ev comes over to london and stays at my place. I'll catch up on my hipster training to make you cry. =)
[15:10] <infinity> geofft: *cry*
[15:10] <infinity> xnox: Are you going to grow a beard and roll up your jeans to fit in?
[15:10] <infinity> xnox: I can send you some nice plaid flannel from Canada.
[15:12] <dobey> infinity: don't forget the butter scones and women's clothing too
[15:12] <xnox> thebwt, it's more fluid than that. each release cycle there are autosyncs happening from debian, in general it's always from debian sid, apart from couple of LTS which we did from testing. but these days it's always from sid. Where there are no changes in ubuntu packages are synced from debian unmodified. Upto debianimport freeze milestone, after that some uploads are cherrypicked. But packages that have ubuntu changes can be ahead or behind debian,
[15:12] <xnox> and merged when developers see fit / need / or have time.
[15:13] <xnox> thebwt, further reading is at: https://wiki.ubuntu.com/UbuntuDevelopment https://wiki.ubuntu.com/UbuntuDevelopment/ReleaseProcess https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive#SyncingAndMerging
[15:13] <thebwt> xnox: but https://launchpad.net/ubuntu/wily says derived from stretch
[15:14] <thebwt> reading
[15:14] <xnox> thebwt, that field is meaningless. where we sync packages from is what matters. It's mostly a thing used to generate useful debdiffs between packages and a "stablish" debian branch to make static debdiffs from.
[15:15] <infinity> thebwt: Read that with a grain of salt.  We always set that to the current "testing", and it detemines where LP decides to generate some deltas from, but our actual imports happen from sid.
[15:15] <xnox> if all packages, from all ubuntu releases debdiff against sid.... the diffs will have little meaning.
[15:15] <thebwt> makes sense
[15:15] <thebwt> thanks guys, chart just exploded
[15:15] <thebwt> :p
[15:16] <xnox> infinity, https://wiki.ubuntu.com/DebianImportFreeze is telling lies
[15:16]  * xnox edit.
[15:18] <infinity> xnox: Is it not the nature of documentation to be full of lies?
[15:18] <xnox> thebwt, https://wiki.ubuntu.com/DebianImportFreeze updated with slightly less lies.
[15:24] <thebwt> should have asked here instead of google....
[15:24] <teward> infinity: OK, just making sure i don't have to beat my system into submission
[15:25] <teward> cyphermox: regarding what I think was a question to me, it happens right after the schroot tries to double check if it's up to date.
[15:25] <teward> but as infinity says it's mostly harmless, and nothing else seems to be broken... :p
[15:25] <cyphermox> yeah
[15:25] <cyphermox> I never noticed it ;)
[15:25] <teward> ... well, except my packages, of course, 'cause i made a typo in a patch :/
[15:26] <infinity> cyphermox: You've never noticed it because your host system is an up to date xenial, probably.
[15:26] <cyphermox> yeah mostly up to date
[15:27] <infinity> And we don't see it on LP because we don't do the fiddly update-databases-from-the-host-system thing there.
[15:29] <teward> as long as it doesn't break anything (it appears to just be a warning), I guess I don't have to wrry about it
[15:29] <teward> though I'll be testing the output packages anyways ('cause testing a package before submitting it as a merge)
[15:43] <mterry> bdmurray, you probably want to add ~maas-devel to your package-subscribers script
[16:29] <gQuigs> how do I tell a package not to build for [!s390x] architecture?  (seems like both gnome-shell and network-manager-gnome do this, but I can't figure out how..)
[16:31] <seb128> gQuigs, no they don't?
[16:31] <seb128> https://launchpad.net/ubuntu/+source/gnome-shell/3.18.2-0ubuntu2/+build/8374520
[16:32] <seb128> n-m-applet is blocked on libappindicator to be available
[16:32] <seb128> which is blocked on the mono transition
[16:32] <xnox> which is in a landing silo, which still ftbfs on s390x due to dbus test suite error
[16:32] <xnox> and yes mono
[16:32] <xnox> gQuigs, please do not do !s390x unless you are building i386 specific bootloader code =)
[16:33] <xnox> gQuigs, it should not matter at all, why do you care? is something blocked for you?
[16:33] <xnox> in practice s390x build-failures do not matter most of the time, at the moment, unless it's a real regression.
[16:33] <gQuigs> xnox: yea, I did a bad sync request - https://bugs.launchpad.net/ubuntu/+source/meta-gnome3/+bug/1523657
[16:33] <gQuigs> trying to fix it
[16:33] <xnox> (or entangled in funny ways)
[16:34] <xnox> gQuigs, i think it should not have been synced.... it's not only a problem on s390x.... http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#meta-gnome3
[16:34] <gQuigs> it usedto specify [amd64] [other archs]. but since s390x is the only one that's failing
[16:35] <xnox> gQuigs, it's uninstallable on _all_ architectures in ubuntu.
[16:35] <xnox> gQuigs, i think you should copy that output back to the bug report, and ask release/archive admins to remove that sync from -proposed.
[16:36] <gQuigs> xnox: right I missed three on all archs, but those can be fixed by a new merge right?
[16:36] <gQuigs> (libreoffice-evolution, iceweasel, and vino)
[16:36] <xnox> gQuigs, yes, and the rest will be available on s390x eventually. So just leave it as is for me to clean up.
[16:37] <xnox> gQuigs, it will be stuck in -proposed for a while, but it's better that way, and spares me finding all the places people did !s390x, or rather explicit arch list and re-enabling it back later.
[16:37] <xnox> s390x is circa 80% built now, so soon thse high level things will be installable too.
[16:39] <gQuigs> xnox: makes sense I guess, the same status as much of the stuff under it... I should still do a debdiff for the stuff broken on all archs though right?
[16:40] <xnox> gQuigs, yes (libreoffice-evolution, iceweasel, and vino) should be still fixed, as those are not in ubuntu and probably will not be ever (if i recall correctly it's intentional delta for us)
[16:40] <gQuigs> k, will do, thanks!
[19:30] <mitya57> pitti, the autopkgtest triggers display is *awesome* :)
[20:38] <rharper> rbasak: looking at that libnl3 bug and patches, I see that it has a debian/patches dir, under which it has another debian dir (with patches, so debian/patches/debian/XXXX.patch)  ; quilt will apply (pop and push) those patches, but when the last patch is applied, quilt diff still shows a delta;  adding a new patch results in diffs being added to the previous patch (even though I've already quilt new/quilt add file.c)
[20:38] <rharper> ... first time seeing that sort of patch setup; what am I missing ?
[21:00] <rbasak> rharper: it looks like it's regular quilt, just with patches that have debian/ prefixed to it.
[21:00] <rbasak> rharper: try popping all patches and adding a new patch and also to the series file manually, maybe, and see if quilt accepts that?
[21:00] <rharper> rbasak: yeah; I just can't figure out why when I quilt new mypatch; quilt add path/to/file; apply diff, refresh
[21:00] <rharper> it captures the new changes into the previous patch
[21:01] <rharper> ok, I can try manually
[21:01] <rharper> just very strange behavior, but also the first time I've seen subdirs of patches (though that really shouldn't matter)
[21:01] <rbasak> rharper: I'm not sure. I've seen subdirs before and they've worked transparently. I don't see anything here that might cause the specialness you're seeing here.
[21:02] <rharper> =(
[21:02] <rharper> probably a PEBCAC but figured I'd ask
[21:03] <rbasak> rharper: you're right to ask. There are many historical variations on patch mechanisms that we see from time to time.
[21:03] <rharper> pop'ing all and applying at the start seems to work, good new is that the subdir of patches are all build file changes, so no chance of collision
[21:03] <rharper> but I am still somewhat concerned that I have to do it this way
[21:04]  * rharper will try out on a clean env instead of laptop
[21:22] <rharper> rbasak: it appears the suggested fixes won't cleanly apply and look like it depends on some newer changes to the repository that aren't present in the version in trusty (library symbol linker scripts as well as a capabilities system).  Is it reasonable to ask the submitter to look at modifying the changes to work with the older version ?
[21:24] <bdmurray> mterry: maas-maintainers seems like a better team (more canonical / likely to be responsible) than maas-devel
[21:25] <mterry> bdmurray, well I didn't decide which to subscribe...  But I could imagine an argument for devel watching bugs rather than the smaller maintainer team...
[21:25] <rbasak> rharper: I think so, yes. Certainly with an Ubuntu hat on
[21:25] <rbasak> rharper: it's still valuable to have found that and put it in the bug though, thanks. It means that they understand what they need to do, rather than think that they're blocked on our sponsorship.
[21:25] <rharper> rbasak: ok, then I'll update the bug with my analysis and request that submitter look at modifying changes to work with the version in trusty
[21:26] <mterry> bdmurray, but I'm just the messenger here.  I can ask if they want to reconsider on the bug
[21:26] <rbasak> rharper: great. Thanks!
[21:26] <rharper> rbasak: yep
[21:26] <rbasak> rharper: did the principle of the patch itself look OK to you, OOI? I was a little dubious.
[21:27] <rharper> rbasak: it *looked* OK, but it had enough extra non-obvious math that I was going to have to write test cases
[21:27] <rbasak> OK. It seemed to me to be far too much complexity. There should be a better way.
[21:27] <bdmurray> mterry: what is the bug?
[21:28] <rharper> honestly, the psuedo random selection in the array seemed overly complicated
[21:28] <rharper> but it's gone upstream (still scary)
[21:28] <mterry> bdmurray, bug 1522182
[21:28] <rbasak> I wonder if there's a much simpler fix that could fix their use case.
[21:30] <rharper> rbasak: indeed
[23:29] <rtg> infinity, apw mentioned last week that you and/or doko were working on the compiler bug that I'm seeing with build a v4.4-rcx arm64  kernel. Any updates ? https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/unstable/+build/8438034/+files/buildlog_ubuntu-xenial-arm64.linux_4.4.0-0.5_BUILDING.txt.gz