/srv/irclogs.ubuntu.com/2015/12/14/#ubuntu-devel.txt

=== wolsen_ is now known as wolsen
pittiGood morning05:48
=== fabo_ is now known as fabo
dholbachgood morning07:29
sladenMorgen07:31
=== Mirv__ is now known as Mirv
=== tvoss is now known as tvoss|errands
mvopitti: 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:22
juliankMaybe because those are run on lxc?09:23
pittiyes, those are in LXC, the other arches run in VMs09:23
pittiI guess you can't chroot() in LXC09:23
=== tvoss|errands is now known as tvoss
juliankpitti: On Debian's amd64 lxc instance it works, though09:27
pittijuliank: I suppose  it's limited by the apparmor profile09:28
pitti(which Debian doesn't have)09:28
juliankCan 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 things09:29
jjohansendepends, Debian can have the lxc profile, but they are running the mainline kernel version of apparmor09:30
jjohansenso it is missing some things, the userspace side is largely up to date09:30
pittijuliank: with chroot() you can easily escape the container, so I'd rather leave tests as "always failed" on the LXC arches09:36
juliankOK.09:39
juliankI'll try to at least get the i386 tests passing, currently they only work on amd6409:39
pittijuliank: which package is that, OOI?09:39
juliankpitti: apt09:39
juliankThe failure on i386 is just because we only run the suite on amd64, and thus have bugs...09:40
pittijuliank: right, so they are "always failed" on all but amd64, so they won't hold up proposed migration09:40
pittiso that's not urgent09:40
juliankpitti: It's annoying me a bit, though :) [ppc64el should work too, then]09:41
juliankpitti: 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:07
juliankWe get a "No such file or directory" when trying to execute the rewritten script path10:08
juliankFor example, /tmp/tmp.Z4pabkgrXk/rootdir/var/lib/dpkg/info/triggerable-interest-noawait.postinst10:08
juliankexecvp(), not execvpe()10:09
* juliank would have expected some permission denied thing, though10:10
juliankIf we could get a log of apparmor during an autopkgtest run, that would probably be useful.10:13
pittijuliank: I can start a test run manually and check in the container, hang on11:22
=== yuning is now known as yuning-afk
xnoxpitti, 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:29
xnoxor what do those numbers mean?11:30
pittixnox: that actually seemse right11:30
pittixnox: as over the weekend I triggered *all* available autopkgtests on s390x11:30
pittixnox: but we don't do that for the other arches, they only run if britney triggers them11:30
pittixnox: and there's a bunch of packages which haven't changed since wily and thus never ran for xenial11:30
xnoxpitti, hm, so there are tests that never been run on amd64?11:31
pitti(or their dependencies)11:31
xnoxoh.11:31
pittixnox: not in xenial; they ran in wily (or even earlier for packages that seldomly change)11:31
xnoxthat makes comparison between arches odd.11:31
xnoxpitti, can you trigger *everything* on amd64 & ppc64el?11:32
pittixnox: I'd need to trigger only the ones which didn't run since wily11:32
pitti"everything" on these will take way too long11:32
xnoxyeap, like that.11:32
pittixnox: yes, I can, the main piece of work is to figure out the list of packages11:33
xnoxcause i want to compare the same ballpark numbers on s390x vs others. for test-report...11:33
xnoxpitti, i can do that from json for you, if you wish?11:33
pittixnox: you mean the pass/fail ones?11:33
pittixnox: that'd be great, yes11:33
pittixnox: btw, fancy graphs: http://autopkgtest.ubuntu.com/status/11:33
xnoxpitti, 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:34
xnoxi'm doing what nobody should do, that is rerun tests to bring amd64 to reality such that it is comparable with s390x ;-)11:35
pittixnox: so, ~ 92% pass rate on i386, ~ 80% on armhf (using LXC), and roughly 70% on s390x (also LXC)11:35
xnoxwhen opening new series, can you not copy over old results from previous release? such that we get pkg count continuity?11:36
xnoxor trigger all on opening...11:36
pittixnox: I could; so far I only copy over the last successful result (if any), to tell apart "always failed" vs. "regression" across new series11:36
pittixnox: but as this isn't necessary for "always failed" packages I don't copy those11:36
pittijuliank: btw, there's other errors like11:39
pitti-fancy11:39
pitti specific11:39
pitti+fancy11:39
pittijuliank: (i. e. ordering); I'm running the apt test on armhf manually, so far I haven't run into apparmor violations yet11:39
pittiah, but it's only at test 45, the first of that is 13211:40
juliankpitti: Yeah the other issues are somewhat strange but unrelated.11:46
juliankIt's just ordered differently for whatever reasons11:46
xnox$ wc -l *.missing11:50
xnox  553 amd64.missing11:50
xnox  585 armhf.missing11:50
xnox  500 i386.missing11:50
xnox  799 ppc64el.missing11:50
xnox    0 s390x.missing11:50
xnox 2437 total11:50
xnoxpitti, http://bazaar.launchpad.net/~xnox/+junk/missing-autopkgtests/files11:50
xnoxpitti, 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
pittixnox: heh, e. g. http://autopkgtest.ubuntu.com/packages/libx/libxml-tidy-perl/ never ran :)11:51
xnoxpitti, so it is correct right? =) only ever run on xenial/s390x =)11:52
pittiI guess the autodep8 stuff landed later than the last change to it11:52
pittixnox: and e. g. http://autopkgtest.ubuntu.com/packages/l/lmod/ is a case where xenial version == wily version11:53
pittixnox: so some spot checks seem fine11:53
pittijuliank: I'm getting the chroot warnings now, no apparmor violations11:53
juliankpitti: OK. Then something stranger is going on. Thanks for testing.11:54
xnoxpitti, well please trigger these then =)11:54
=== cpaelzer is now known as cpaelzer_afk
pittijuliank: as soon as the test finishes I can ssh into the container, if you want me to run anything11:54
=== _salem is now known as salem_
=== xavigarcia is now known as xavigarcia_lunch
juliankpitti: I'm looking at building something, it's somewhat hard though. We build this library: https://paste.debian.net/344216/.12:06
juliankpitti: I think I found the bug. It's an off by one, newfile is one byte to short12:06
pittijuliank: ah!12:07
pittijuliank: please consider using this:12:07
pittichar newfile[PATH_MAX];12:07
pittisnprintf(newfile, sizeof(newfile), "%s/%s", path1, path2);12:07
pittijuliank: snprintf() is so much safer and avoids these gotchaas12:07
pittievery strcpy() and strcat() eliminated from production code makes a dead kitten get back to life somewhere! :-)12:08
=== cpaelzer_afk is now known as cpaelzer
pittixnox: do you really need all the arches for comparison? isn't amd64 or armhf sufficient?12:10
pittixnox: I now transformed your lists into run-autopkgtest commands with appropriate --trigger arguments, running amd64 now12:10
xnoxpitti, amd64 will do for this week, and rerun everything else on the weekend / holidays?12:10
pittibut running 500 tests will take a fair while, I'm not going to launch the i386 ones right away12:11
pittixnox: sounds fine12:11
pittixnox: http://autopkgtest.ubuntu.com/running.shtml#queue-xenial-amd6412:11
xnoximho for next series you should copy all the results otherwise we under-report the amount of testing we do.12:11
pittiyeah, can do12:11
xnoxpitti, \o/ thanks.12:11
pittixnox: you are the first to notice/ask about statistics12:11
xnoxhehe.12:12
pete-woodspitti: sorry to keep nagging, but is there any chance you could do a backport of the latest dbusmock release into the vivid overlay?12:14
pittipete-woods: it hasn't landed in xenial yet, stuck on the test regression12:15
pittiso, don't want to backport yet, this first needs looking into12:15
pete-woodspitti: ah, hadn't realised that12:15
pete-woodsokay12:15
pete-woodsI will have a look at that then12:15
pete-woodspitti: 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-woodsto me it looked like *something* was running the tests individually12:20
pittipete-woods: oh nice! do you know what triggered that in your last PR?12:20
pete-woodspitti: I added a test that did sorta async stuff from the bluez test12:21
pete-woodswhere you wait for a bunch of signals to be emitted12:21
pittiah, async needs a main loop indeed12:21
pete-woodsbut the weird thing is the tests work fine when you run the full suite12:21
pete-woodsmaybe that's because the bluez one has already setup the mainloop..12:21
pitticd tests12:22
pittifor f in *.py; do12:22
pitti    python3 $f12:22
pittidone12:22
pittipete-woods: ^ the autopkgtest does that12:22
pete-woodsright12:22
pittipete-woods: yeah, very likely12:22
pete-woodswell that would explain it12:22
pittipete-woods: we want to run the tests against the installed py module, so we can't use ./setup.py12:23
pete-woodsfair enough12:23
pete-woodsI have no python-fu12:23
pete-woodsI just type til it stops erroring12:23
pittipete-woods: works fine, thanks12:25
pete-woodscool12:25
pittipete-woods: 0.16.3 released and uploaded to Debian; for the backport, I take it vivid+wily?12:32
pittipete-woods: uploaded backports to both; thanks for the fix!12:34
pete-woodspitti: thanks very much, I don't really care about wily too much, but may as well do both just in case12:36
=== xavigarcia_lunch is now known as xavigarcia
xnoxinfinity, may i steal your strace pending merge?13:35
infinityxnox: Sure.13:36
xnoxinfinity, fails on i386 with one fail, fails a lot more on s390x =( here is to new upstream release fixing nothing....13:56
infinityxnox: Looks fine in Debian build logs.  So, that's curious.13:58
xnoxmono gdoc fails to bootstrap with -O2, strace failures. something odd is going on.13:59
xnox*mdoc13:59
tewardshould 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:47
cyphermoxhas it already done some upgrades before showing that message?14:53
infinityteward: That's because the user doesn't exist outside the chroot, and schroot copies in your external /etc/passwd14:54
infinityteward: It's mostly harmless.14:54
xnoxinfinity, retrying strace/i386 made it "pass" the test-suite.....15:05
* xnox looses confidence in strace testsuite15:05
thebwthowdy 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:05
geofftcan someone who can see private bugs tell me what LP #723515 is?15:07
ubottuError: Launchpad bug 723515 could not be found15:07
geofftor where should I ask?15:07
infinitygeofft: Ask the security team.  If it's an ubuntu bug, they can see it.15:08
geofftI believe that it is a bug in Ubuntu glibc15:08
infinitygeofft: If it's not, then the only people likely to be able to see it are LP admins, to #canonical-sysadmin15:08
geoffter, gcc15:08
infinityActually, wait, I'm in the security team and I can't see it. :P15:08
infinitySo, no.  It's probably not an Ubuntu bug.15:08
xnoxinfinity, >_< #identitycrisis15:09
infinityxnox: *cough*15:09
* xnox slowly backs away15:09
infinityxnox: Using hashtags on IRC should be punishable by death.15:09
geofftI am pretty sure the kids these days are saying things like "hashtag ubuntu-devel"15:10
xnoxinfinity, 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
infinitygeofft: *cry*15:10
infinityxnox: Are you going to grow a beard and roll up your jeans to fit in?15:10
infinityxnox: I can send you some nice plaid flannel from Canada.15:10
dobeyinfinity: don't forget the butter scones and women's clothing too15:12
xnoxthebwt, 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
xnoxand merged when developers see fit / need / or have time.15:12
xnoxthebwt, further reading is at: https://wiki.ubuntu.com/UbuntuDevelopment https://wiki.ubuntu.com/UbuntuDevelopment/ReleaseProcess https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive#SyncingAndMerging15:13
thebwtxnox: but https://launchpad.net/ubuntu/wily says derived from stretch15:13
thebwtreading15:14
xnoxthebwt, 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:14
infinitythebwt: 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
xnoxif all packages, from all ubuntu releases debdiff against sid.... the diffs will have little meaning.15:15
thebwtmakes sense15:15
thebwtthanks guys, chart just exploded15:15
thebwt:p15:15
xnoxinfinity, https://wiki.ubuntu.com/DebianImportFreeze is telling lies15:16
* xnox edit.15:16
infinityxnox: Is it not the nature of documentation to be full of lies?15:18
xnoxthebwt, https://wiki.ubuntu.com/DebianImportFreeze updated with slightly less lies.15:18
thebwtshould have asked here instead of google....15:24
tewardinfinity: OK, just making sure i don't have to beat my system into submission15:24
tewardcyphermox: 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
tewardbut as infinity says it's mostly harmless, and nothing else seems to be broken... :p15:25
cyphermoxyeah15:25
cyphermoxI never noticed it ;)15:25
teward... well, except my packages, of course, 'cause i made a typo in a patch :/15:25
infinitycyphermox: You've never noticed it because your host system is an up to date xenial, probably.15:26
cyphermoxyeah mostly up to date15:26
infinityAnd we don't see it on LP because we don't do the fiddly update-databases-from-the-host-system thing there.15:27
tewardas long as it doesn't break anything (it appears to just be a warning), I guess I don't have to wrry about it15:29
tewardthough I'll be testing the output packages anyways ('cause testing a package before submitting it as a merge)15:29
mterrybdmurray, you probably want to add ~maas-devel to your package-subscribers script15:43
=== cpaelzer is now known as cpaelzer_afk
=== cpaelzer_afk is now known as cpaelzer
gQuigshow 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:29
seb128gQuigs, no they don't?16:31
seb128https://launchpad.net/ubuntu/+source/gnome-shell/3.18.2-0ubuntu2/+build/837452016:31
seb128n-m-applet is blocked on libappindicator to be available16:32
seb128which is blocked on the mono transition16:32
xnoxwhich is in a landing silo, which still ftbfs on s390x due to dbus test suite error16:32
xnoxand yes mono16:32
xnoxgQuigs, please do not do !s390x unless you are building i386 specific bootloader code =)16:32
xnoxgQuigs, it should not matter at all, why do you care? is something blocked for you?16:33
xnoxin practice s390x build-failures do not matter most of the time, at the moment, unless it's a real regression.16:33
gQuigsxnox: yea, I did a bad sync request - https://bugs.launchpad.net/ubuntu/+source/meta-gnome3/+bug/152365716:33
ubottuLaunchpad bug 1523657 in meta-gnome3 (Ubuntu) "Sync meta-gnome3 1:3.14+3 (universe) from Debian unstable (main)" [Wishlist,Fix released]16:33
gQuigstrying to fix it16:33
xnox(or entangled in funny ways)16:33
xnoxgQuigs, 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-gnome316:34
gQuigsit usedto specify [amd64] [other archs]. but since s390x is the only one that's failing16:34
xnoxgQuigs, it's uninstallable on _all_ architectures in ubuntu.16:35
xnoxgQuigs, i think you should copy that output back to the bug report, and ask release/archive admins to remove that sync from -proposed.16:35
gQuigsxnox: 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
xnoxgQuigs, yes, and the rest will be available on s390x eventually. So just leave it as is for me to clean up.16:36
xnoxgQuigs, 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
xnoxs390x is circa 80% built now, so soon thse high level things will be installable too.16:37
gQuigsxnox: 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:39
xnoxgQuigs, 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
gQuigsk, will do, thanks!16:40
=== cpaelzer is now known as cpaelzer_afk
=== cpaelzer_afk is now known as cpaelzer
mitya57pitti, the autopkgtest triggers display is *awesome* :)19:30
=== cpaelzer is now known as cpaelzer_afk
rharperrbasak: 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 ?20:38
rbasakrharper: it looks like it's regular quilt, just with patches that have debian/ prefixed to it.21:00
rbasakrharper: 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
rharperrbasak: yeah; I just can't figure out why when I quilt new mypatch; quilt add path/to/file; apply diff, refresh21:00
rharperit captures the new changes into the previous patch21:00
rharperok, I can try manually21:01
rharperjust very strange behavior, but also the first time I've seen subdirs of patches (though that really shouldn't matter)21:01
rbasakrharper: 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:01
rharper=(21:02
rharperprobably a PEBCAC but figured I'd ask21:02
rbasakrharper: you're right to ask. There are many historical variations on patch mechanisms that we see from time to time.21:03
rharperpop'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 collision21:03
rharperbut I am still somewhat concerned that I have to do it this way21:03
* rharper will try out on a clean env instead of laptop21:04
rharperrbasak: 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:22
bdmurraymterry: maas-maintainers seems like a better team (more canonical / likely to be responsible) than maas-devel21:24
mterrybdmurray, 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
rbasakrharper: I think so, yes. Certainly with an Ubuntu hat on21:25
rbasakrharper: 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
rharperrbasak: ok, then I'll update the bug with my analysis and request that submitter look at modifying changes to work with the version in trusty21:25
mterrybdmurray, but I'm just the messenger here.  I can ask if they want to reconsider on the bug21:26
rbasakrharper: great. Thanks!21:26
rharperrbasak: yep21:26
rbasakrharper: did the principle of the patch itself look OK to you, OOI? I was a little dubious.21:26
rharperrbasak: it *looked* OK, but it had enough extra non-obvious math that I was going to have to write test cases21:27
rbasakOK. It seemed to me to be far too much complexity. There should be a better way.21:27
bdmurraymterry: what is the bug?21:27
rharperhonestly, the psuedo random selection in the array seemed overly complicated21:28
rharperbut it's gone upstream (still scary)21:28
mterrybdmurray, bug 152218221:28
rbasakI wonder if there's a much simpler fix that could fix their use case.21:28
ubottubug 1522182 in python-petname (Ubuntu) "[MIR] python-petname" [High,Fix committed] https://launchpad.net/bugs/152218221:28
rharperrbasak: indeed21:30
rtginfinity, 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.gz23:29

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!