[10:43] <ePierre> Hi everyone!
[10:45] <ePierre> I'm working in the Checkbox team <https://launchpad.net/checkbox-project> and we just raised two issues to get packages removed from Xenial repositories: pad.lv/1512641 and pad.lv/1512642 ; please let me know if there are anything else I need to do or provide for this to happen. Thanks!
[10:52] <Mirv> has anyone running 14.04 LTS been able to workaround bug #1497420 to attach to xenial lxc?
[11:01] <mardy> seb128: hi! Did you have time to look at https://requests.ci-train.ubuntu.com/#/ticket/446 ?
[11:49] <Laney> utlemming / Odd_Bloke / smoser: know when we'll get the first cloud images?
[11:50]  * Laney is trying to use adt-buildvm-ubuntu-cloud :)
[11:52] <Odd_Bloke> Laney: We're doing a major rework of how we build images for xenial, so dailies on cloud-images.ubuntu.com aren't imminent.
[11:53] <Odd_Bloke> Laney: I did point pitti at some sample images for him to test out, but I don't know that he's managed to get to them yet (I believe he's sprinting this week).
[12:00] <Laney> Odd_Bloke: OK, thanks, I'll check if a-b-u-c can use those somehow
[12:14] <pitti> Odd_Bloke: oh, you did? sorry, missed them
[12:22] <pitti> Odd_Bloke: ETA 4 hours, go hotel network :)
[12:24] <mgedmin> huh, collectd in debian testing is 5.5.0; collectd in xenial is still 5.4.1
[12:31] <mgedmin> ah, judging from the .ubuntu1 version it needs a merge
[12:31] <seb128> mardy, sorry for the delay, published now
[12:32] <mardy> seb128: nw, thanks a lot! :-)
[12:33] <mardy> seb128: ah looks like it failed
[12:34] <mardy> seb128: packages changed in the archive, let me sync them...
[12:34] <seb128> mardy, if they are no change upload we can override
[12:34] <seb128> but please check if there is content to include
[12:35] <mardy> seb128: ok, I'll let you know in a minute
[12:37]  * mgedmin finds and reads https://merges.ubuntu.com/c/collectd/REPORT
[12:37] <mardy> seb128: yes, all three are "no change rebuild"
[12:40] <seb128> mardy, ok, published again with override which worked
[12:44] <Odd_Bloke> pitti: :)
[12:47] <mardy> seb128: thanks!
[12:48] <seb128> mardy, yw!
[14:18] <rbasak> pitti: taking the nis merge to work on with cpaezler. I trust that's OK.
[14:18] <pitti> rbasak: please
[14:19] <rbasak> Thanks
[14:19] <pitti> rbasak: no, thanks to you :)
[14:33] <pitti> Odd_Bloke: http://people.canonical.com/~dwatkins/20151028/ amd image is working fine here! I tested it with local qemu, not with an actual cloud, but I guess you already did that
[14:41] <seb128> what's the way to let britney to let a package through if it reduced the list of archs it's building a binary on? deleting the binary for those archs in the release pocket?
[14:46] <cjwatson> seb128: that
[14:46] <cjwatson> though obviously check reverse-dependencies first
[14:46] <seb128> right, I just did
[14:47] <seb128> it's for xserver-xorg-video-vmware
[14:47] <seb128> (I hope I didn't overlook thing)
[14:47] <seb128> cjwatson, thanks
[15:03] <mardy_> seb128: the message about the packages being "in the proposed pocket", does it mean that it's all right, or is it an error? https://requests.ci-train.ubuntu.com/#/ticket/446
[15:04] <seb128> mardy_, it's normal, things go through proposed and migrate when/if they are ok (tests passing, not creating un-installability issue, etc)
[15:05] <mardy_> seb128: ok, thanks
[15:05] <seb128> mardy_, see https://wiki.ubuntu.com/ProposedMigration if you are interested by the detailzs
[15:12] <ogra_> cjwatson, infinity, does either of you know how live-build enforces immediate execution of triggers ? (i have a problem installing the raspi2 kernel package during a livefs build, afaik it is 100% based on the -generic package so it should work, yet it defers the update-initramfs trigger, so the postinst fails) https://launchpadlibrarian.net/224109673/buildlog_ubuntu_xenial_armhf_ubuntu-core-system-image_BUILDING.txt.gz
[15:13] <ogra_> the apt.conf manpage only seems to have options to suppress trigger execution
[15:18] <TJ-> ogra_: I may be mis-remembering but from a looong way back I seem to recall seeing/using OrderList::Score::Immediate
[15:18] <ogra_> TJ-, hmm, i'll try
[15:23] <cjwatson> ogra_: as far as I know, it doesn't
[15:24] <ogra_> weird, so that would be a packaging bug in the raspi2 package ?
[15:24] <cjwatson> that would be my first guess
[15:24] <ogra_> hmm and the kernel team is traveling :(
[15:24] <cjwatson> deferring triggers isn't really a thing
[15:24] <cjwatson> err
[15:24] <ogra_> enforcing :)
[15:24] <cjwatson> I mean, enforcing immediate execution of triggers isn't really a thing
[15:25] <cjwatson> OrderList::Score::Immediate is a bit different really
[15:25] <ogra_> yeah, thats how i read the manpage
[15:31] <Laney> doko: Do you have an idea on how we can get past https://sourceware.org/bugzilla/show_bug.cgi?id=19188 ?
[15:32] <Laney> it's breaking webkit2gtk/arm64 which is going to be the last thing holding up a big-ish migration soon
[15:43] <seb128> hum
[15:43] <seb128> gdb doesn't work on xenial for me :-/
[15:43] <seb128> (gdb) bt
[15:43] <seb128> Python Exception <class 'SystemError'> <built-in function isinstance> returned a result with an error set:
[15:44] <seb128> those python errors is everything it returns
[15:45] <sarnold> seb128: maybe disable autoloading python? https://sourceware.org/gdb/onlinedocs/gdb/Python-Auto_002dloading.html#Python-Auto_002dloading
[15:45] <seb128> sarnold, thanks
[15:45] <seb128> Laney, you could have updated python-pgmagick to 0.5.12 that patch is basically all there is in the new version ;-) (I pinged slangasek about that yesterday)
[15:46] <seb128> sarnold, that works ;-)
[15:46] <sarnold> yay :)
[15:46]  * Laney shrugs
[15:47] <Laney> why didn't you upload it?
[15:47] <seb128> Laney, because slangasek said it was on his list
[15:47] <Laney> didn't see a bug
[15:47] <seb128> he was the one who uploaded the version that failed to build
[15:47] <seb128> yeah, I should probably have opened one
[15:47] <seb128> sorry about that :-)
[15:47] <seb128> I though he would handle it yesterday
[15:47] <doko> Laney, sorry, not yet. gold fails too. for unity it only showed up build the test cases, so I proposed to disable these.
[15:47] <doko> Laney, this is https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1511542
[15:48] <seb128> doko, hey, gdb giving the python errors I just copied, is that known? what component should that be reported against?
[15:50] <Laney> doko: :(
[15:53] <doko> seb128, do you have a test case, or is this just loading the pretty printer?
[15:53] <seb128> doko, I just do "gdb something" and "run" and ctrl-C and bt
[15:53] <seb128> or attach to an existing process
[15:53] <stgraber> cyphermox: hey, who's in charge of network-manager these days? we've got a very serious regression affecting wily and xenial
[16:00] <stgraber> slangasek, cyphermox: bug 1512749
[16:06] <barry> Laney: matplotlib 1.5.0~rc2-1ubuntu3 \o/
[16:06] <barry> Laney: i was just about to start looking at that one :)
[16:07] <Laney> barry: hehe
[16:07] <Laney> you should make more things depend on glib
[16:07] <Laney> then you get people like me to care :P
[16:08] <barry> Laney: :)
[16:08] <barry> Laney: now i know how to trick you into fixing all the bugs
[16:18] <sil2100> slangasek, doko, cyphermox, any-other-core-dev: could you release https://bugs.launchpad.net/ubuntu/+source/ledit/+bug/1512776 for me? Thanks!
[16:19] <yofel> pitti: fixes for some of the kubuntu autopackagetest failures uploaded, sorry that it took a while (some still need to be uploaded once I fixed our packageset..). Is there some way to list all kubuntu packages with test failures?
[16:20] <pitti> yofel: I think the easiest thing to start from is http://autopkgtest.ubuntu.com/data/status/xenial/amd64/packages.json
[16:21] <yofel> ah nice, that works
[16:21] <yofel> thanks
[16:21] <pitti> yofel: probably easiest with three lines of python -- iterate over status "fail" and "kde" in package, or so?
[16:22] <pitti> I'm fairly sure one can do it with json_pp, but I never learned the magic of this; Laney knows this
[16:23] <yofel> if the naming would be that easy I wouldn't have trouble :P
[16:23] <yofel> but we have lists of all our maintained sources, so filtering that won't be hard
[16:24] <Laney> pitti: yofel: The tool that I used was called 'jq'
[16:25] <pitti> ah, or that
[16:25] <yofel> thanks, I'll look at that
[16:25] <pitti> not knowing that i'd just do something like "for p in json.load(f.read()): if p['package'] ...
[16:32] <cyphermox> sil2100: looking
[16:38] <cyphermox> sil2100: done.
[16:39] <bdmurray> tumbleweed: did you say you had updated distro-info-data?
[16:41] <sil2100> cyphermox: thanks!
[16:42] <sil2100> doko: https://bugs.launchpad.net/ubuntu/+source/unity-api/+bug/1512784 - MIR request pretty please
[16:45]  * ogra_ wonders whats up with the arm builders ... 
[16:51] <cjwatson> ogra_: ?
[16:52] <ogra_> cjwatson, well, they seem busy https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/xenial/ubuntu-core-system-image/ (i had them starting immediately all day during test builds)
[16:53] <cjwatson> ogra_: they have about a ten-minute queue at the moment due mostly to a batch of KDE uploads, but nothing serious
[16:53] <cjwatson> ogra_: see https://launchpad.net/builders/
[16:53] <ogra_> ah, k
[16:53] <ogra_> well, i'll wait
[16:53] <cjwatson> arm64 will take longer, but that's normal
[16:53] <cjwatson> I think the 28 minutes on your page is a misestimate
[16:53] <ogra_> yeah, for test builds i dont care for arm64 ... i should have excluded it from ARCHES=
[17:05] <bdmurray> tumbleweed: I ask as I don't seem them in the unapproved SRU queues
[17:08] <stgraber> cyphermox: did you see my question above?
[17:08] <cyphermox> I had not
[17:08] <cyphermox> so, the short answer is "nobody really".
[17:09] <cyphermox> NM shouldn't touch the interfaces it doesn't manage, especially not bridges, at all, so something clearly got broken
[17:09] <stgraber> I just uploaded a very very ugly workaround to xenial now, if that does the trick, we'll have to SRU this very quickly to wily too until NM gets fixed
[17:09] <cyphermox> ok
[17:09] <cyphermox> which package?
[17:10] <stgraber> lxc
[17:10] <stgraber> cyphermox: http://paste.ubuntu.com/13092923/
[17:10] <cyphermox> oh yuck
[17:11] <stgraber> yeah
[17:11] <stgraber> as I said, very very ugly workaround, does the trick though
[17:11] <stgraber> the alternative was a "sleep 5" but well, that'd just be racy :)
[17:11] <cyphermox> yeah
[17:12] <cyphermox> so, I think we're running into more of the veth vs. straight ethernet device issue
[17:12] <stgraber> and nmcli doesn't seem to have a "wait until we reach some kind of final state"
[17:12] <stgraber> cyphermox: nah, it's a bridge here and NM does try to do stuff with the bridge backend code
[17:13] <stgraber> cyphermox: run: ip link add dev test type bridge && ip link set dev test up && ip addr add 1.2.3.4/24 dev test && sleep 2 && ifconfig test && ip link delete test
[17:13] <stgraber> cyphermox: you'll get an interface without an IP
[17:14] <stgraber> Nov  3 12:13:17 castiana NetworkManager[21958]: <info>  (test): new Bridge device (carrier: OFF, driver: 'bridge', ifindex: 94)
[17:14] <stgraber> so NM does detect it as a bridge and then still does stuff to it...
[17:14] <stgraber> it doesn't seem to start DHCP on it though, but it still does flush any pre-existing config from it
[17:15] <seb128> cyphermox, you are not maintainin n-m anymore? do you still plan to do the point release updates?
[17:16] <cyphermox> I do what I can given available time; but these days there's a lot of things going in front of NM in the todo queue.
[17:18] <seb128> k, just wondering if we should do updates like we handle GNOME ones
[17:40] <bdmurray> tumbleweed: Ah, I see its in -proposed for everything except wily.
[17:41] <Laney> presumably because we have it in there as Xenial X, so might as well wait for the real release date before SRUing again
[17:42] <bdmurray> Laney: got it thanks
[17:53] <cyphermox> seb128: by all means, feel free to do the updates for NM, but some may be quite involved :/
[17:54] <seb128> cyphermox, right...
[18:07] <mterry> pitti, hi!  I'm looking at the strip-nondeterminism MIR.  Looks fine, but I had a question about if enabling this means we'll fail a build if the tool has a problem or if it continues the build in that case (there are several bugs in Debian about strip-nondeterminism having problems on weird files)
[18:09] <pitti> mterry: haven't checked for sure, but I'd expect it to FTBFS if dh_strip_nondeterminism fails
[18:10] <pitti> mterry: but Debian has run it in production for some time, so I figure the worst bugs have been shaken out already
[18:10] <pitti> mterry: and as I said on the bug, if this causes extra FTBFS the foundations team will certainly deal with this
[18:10] <pitti> (in the worst case by disabling it for that package or in general)
[18:10] <mterry> pitti, OK.  Well that's a decision for integration into debhelper anyway.  Not a reason to block the MIR.  This package itself is maintainable
[18:10] <mterry> pitti, cool, thanks!
[18:11] <pitti> mterry: right; once approved, I'll revert the delta of dropping the dep from debhelper
[18:16] <tumbleweed> bdmurray: oh, yes, I forgot to verify them
[18:17] <mterry> bdmurray, the foundations team is looking after strip-nondeterminism in main, FYI
[18:18] <bdmurray> tumbleweed: I've verified Trusty and Vivid.
[18:20] <tumbleweed> bdmurray: thanks
[18:32] <cyphermox> stgraber: what about this? http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=e29ab54335c6a5ef1ce6bac525f1f18a8e81b96e
[18:37] <stgraber> cyphermox: the reproducer in that commit is identical to what we're doing, so that's probably right
[19:04] <mterry> bdmurray, and unity-api is being looked after by unity-ui-team in main, FYI!
[19:35] <decci> I am trying to build .DEB package
[19:36] <decci> I ran dh_make -f ../.tar.gz , then  debian/rules clean, build and binary. It went good and built .DEB package
[19:38] <decci> Now when I again re-run the debian/rules binary it threw error override_dh_auto_install
[19:38] <decci> Error code 2
[19:38] <decci> Any idea how to  fix this
[19:38] <ricotz> decci, you should use "debuild" or "dpkg-buildpackage" to build a source package
[19:39] <decci> ricotz: Do you mean use it instead of debian/rules build
[19:40] <mterry> jdstrand, and alabaster in main is also looked after by foundations team, fyi!
[19:40] <decci> ricotz: So whats the correct way of building .DEB
[19:40]  * mterry is clearing out MIRs  :)
[19:41] <decci> ricotz: All I follow: 1. dh_make 2. debian/rule clean 3. debian/rules build 4. debian/rules binary
[19:41] <decci> ricotz: Where do I need to run debuild?
[19:41] <decci> ricotz: I mean after which step
[19:42] <ricotz> decci, you downloaded a source package, e.g. having a *.dsc file lying around?
[19:42] <ricotz> do "dpkg-source -x *.dsc", go into the src folder and run "dpkg-buildpackage" or "debuild"
[19:43] <decci> ricotz: I have source code, when I run dh_make it creates debian folder where rules, preinst and postinst gets created and .dsc gets created at ../
[19:44] <ricotz> so you want to create a debian package from some tarball without any existing packaging information?
[19:44] <decci> ricotz: This is a source code internal to company..pre-compiled and linked already
[19:45] <decci> ricotz: All I am trying to do is build it to .deb
[19:45] <decci> ricotz: yes
[19:45] <ricotz> decci, you might want to use "checkinstall" then
[19:46] <decci> ricotz: checkinstall doesnt handle rules, preinst and postinst
[19:46] <decci> ricotz: I dont see any option for rules specification
[19:46] <ricotz> you don't have any packaging information in the first place
[19:47] <decci> ricotz: I have rules, postinst and preinst, control files in place
[19:47] <ricotz> so simply use the tarball and build it and checkinstall creates a deb
[19:47] <ricotz> ok, because you ran dh_make
[19:47] <decci> ricotz: All I want to build .DEB package using these rules, preinst and postint
[19:48] <ricotz> then debuild from within the root srcdir should work
[19:48] <decci> ricotz: dh_make gives me debian folder with rules, post and preinst file created to add the rules
[19:48] <ricotz> search for debian packaging details to make further adjustments if needed
[19:49] <decci> ricotz: I can try debuild , so do I need to run under my source
[19:49] <decci> ricotz: which has Makefile, configure.ac
[19:49] <decci> ricotz: CMakeCache.txt
[19:50] <decci> ricotz: What could be reason of override_dh_auto_install Error: code 2
[19:51] <ricotz> debuild looks for the debian folder and its content
[19:51] <ricotz> sound like an error in your changes to rules
[19:52] <ricotz> better paste a more detailed error output (via pastebin), so someone can look at it
[19:53] <ricotz> I need to go
[19:53] <decci> ricotz: dpkg-source: error: unwanted binary file: debian/CMakeFiles
[19:54] <decci> ricotz: dpkg-source: error: detected 4 unwanted binary files (add them in debian/source/include-binaries to allow their inclusion).
[19:54] <mterry> bdmurray, and foundations for python-hypothesis too!
[19:56] <bdmurray> mterry: got it, thanks
[19:56] <decci> dpkg-buildpackage: error: dpkg-source -b dcde_source gave error exit status 29
[19:57] <mterry> bdmurray, (is this the easiest way to update the list? -- I'm fine with it, just curious if these pings get annoying)
[20:00] <bdmurray> mterry: the list of teams I'm already aware of can be found here - http://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk/view/head:/package-subscribers#L107
[20:01] <bdmurray> mterry: If the team isn't in that list then being notified would be useful
[20:01] <mterry> bdmurray, ahh...  so if a team subscribes to a bug, you assume they are looking after it as long as they are in this list.  It's not a granular team->package thing
[20:02] <bdmurray> mterry: right, we look at the packages to which those teams are subscribed
[20:03] <mterry> bdmurray, cool OK, then I can drop a lot of pings  :)
[20:03] <bdmurray> mterry: indeed!
[20:35] <cyphermox> stgraber: looks like it's good; I'll upload to xenial now and then we can look at the SRU for this. Can you update the bug to add the template?
[20:36] <stgraber> cyphermox: sure, I'll add a testcase once we have it in xenial and working
[20:36] <stgraber> cyphermox: I was going to SRU the ugly lxc workaround but if we can get network-manager fixed itself, even better
[21:02] <chiluk> slangasek: I know you are busy, but can I get an upload for nfs-utils done for https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1509120  I have a feeling it will look familiar to you.
[21:09] <slangasek> chiluk: oh hah, is that really just a keyutils upcall bug?
[21:14] <cyphermox> stgraber: yeah, feel free to not SRU your ugly lxc fix now if this NM update works :)
[21:15] <stgraber> cyphermox: already reverted it in xenial, it's clearly not something I wanted to have to keep around :)
[21:15] <cyphermox> ack.
[21:19] <chiluk> slangasek: yes it is.
[21:20] <slangasek> chiluk: I notice the rationale for adding the dependency in vivid+ was that this is required for systemd compatibility, because in the systemd case everything assumes we only use /usr/sbin/nfsidmap as an upcall *instead* of running idmapd (/etc/request-key.d/id_resolver.conf).  So this certainly seems to be a workaround rather than a proper fix
[21:20] <slangasek> do I have that right?
[21:23] <chiluk> slangasek: it's not a workaround when communicating with old nfsv4 servers that don't support sec=sys, and thus aren't using idmapd.
[21:23] <slangasek> hmm
[21:24] <chiluk> afaik.. but I wouldn't consider myself an nfs expert by any stretch of the imagination
[21:24] <slangasek> should anyone? ;)
[21:24] <chiluk> we were only able to rerpoduce the hang by using an ancient 2.6.32 centos machine
[21:24] <chiluk> precisely because sec=sys isn't supported by such an ancient kernel.
[21:24] <slangasek> do you know what the RPC is that triggers this path, vs. working via idmapd?
[21:25] <chiluk> I don't.
[21:25] <slangasek> ok
[21:25] <chiluk> I could tcpdump it real quick if you'd like.
[21:25] <chiluk> slangasek: ^^
[21:25] <slangasek> chiluk: hit me
[21:26] <chiluk> don't tempt me...
[21:26] <slangasek> chiluk: has this been reproduced cross-architecture?
[21:27] <slangasek> chiluk: because my next question is, is it reproducible with the 14.04.0 kernel or only with hwe-v?
[21:27] <chiluk> yeah ppc is hitting it although I don't have a trustable backtrace yet from them, and I'm seeing it on x86_64
[21:27] <chiluk> oh no, I'm using 3.13.
[21:27] <slangasek> ok
[21:28] <chiluk> do you still want that tcpdump?  I just realized that the machine will become unusable once I instantiate the crash.. so we'll see what kind of messages actually can get logged.
[21:29] <chiluk> nm I can capture from the server.
[21:30] <slangasek> chiluk: I think I'm happy without the tcpdump
[21:30] <chiluk> slangasek, yeah .. I was a bit curious myself about the rejected rpc call.
[21:49] <Unit193> FWIW, Debian 786690 still affects wily.
[22:59] <xnox> i'm blinking over "1TB PCIe Solid State Drive" whilst starring at XPS 15 (9550).
[23:00] <sarnold> ooo
[23:00] <sarnold> chrisccoulson: ^^^
[23:00] <xnox> the new XPS 15, however so far it's with windows only, and i don't see a developer edition with ubuntu yet.
[23:00] <xnox> http://www.dell.com/uk/p/xps-15-9550-laptop/pd
[23:01] <xnox> superm1: is XPS 15 (9550) pre-orderable as a developer edition? i shall give them a call tomorrow.
[23:05] <sil2100> doko: so, to continue on the ocaml transition I need multiple arm64 binaries built from the dependency level 3 uploads I made, meaning I'm currently stalled on that
[23:05] <sil2100> But tomorrow at least some of them should be available, so I can continue from there then
[23:07] <superm1> xnox: not currently. It's a work in progress still.
[23:07] <superm1> danjared: will know current status better than I
[23:09] <cjwatson> sil2100: yeah, for that number it's sensible just to wait - at least the ocaml stack isn't too deep
[23:09] <cjwatson> the queue's "only" an hour long at the moment
[23:41] <danjared> what'd I do?
[23:42] <danjared> xnox: no, no current plans for an Ubuntu version of the XPS 15. there are plans for the Precision Mobile 5510