=== jono is now known as Guest11562 === sunweave1 is now known as sunweaver === jono is now known as Guest60019 [10:43] Hi everyone! [10:45] I'm working in the Checkbox team 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] has anyone running 14.04 LTS been able to workaround bug #1497420 to attach to xenial lxc? [10:52] bug 1497420 in lxc (Ubuntu) "systemd 226 (moving pid 1 into /init.scope cgroup) breaks lxc-attach" [High,Triaged] https://launchpad.net/bugs/1497420 [11:01] seb128: hi! Did you have time to look at https://requests.ci-train.ubuntu.com/#/ticket/446 ? [11:49] 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] 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] 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). === _salem is now known as salem_ [12:00] Odd_Bloke: OK, thanks, I'll check if a-b-u-c can use those somehow === dpm__ is now known as dpm [12:14] Odd_Bloke: oh, you did? sorry, missed them [12:22] Odd_Bloke: ETA 4 hours, go hotel network :) [12:24] huh, collectd in debian testing is 5.5.0; collectd in xenial is still 5.4.1 [12:31] ah, judging from the .ubuntu1 version it needs a merge [12:31] mardy, sorry for the delay, published now [12:32] seb128: nw, thanks a lot! :-) [12:33] seb128: ah looks like it failed [12:34] seb128: packages changed in the archive, let me sync them... [12:34] mardy, if they are no change upload we can override [12:34] but please check if there is content to include [12:35] seb128: ok, I'll let you know in a minute === Zic is now known as Guest20486 [12:37] * mgedmin finds and reads https://merges.ubuntu.com/c/collectd/REPORT [12:37] seb128: yes, all three are "no change rebuild" [12:40] mardy, ok, published again with override which worked [12:44] pitti: :) [12:47] seb128: thanks! [12:48] mardy, yw! === Guest20486 is now known as Zic === hikiko is now known as hikiko|ln === lool- is now known as lool === rickspencer3_ is now known as rickspencer3 === zul_ is now known as zul [14:18] pitti: taking the nis merge to work on with cpaezler. I trust that's OK. [14:18] rbasak: please [14:19] Thanks [14:19] rbasak: no, thanks to you :) === hikiko|ln is now known as hikiko === mwenning is now known as mwenning-wfh [14:33] 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] 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] seb128: that [14:46] though obviously check reverse-dependencies first [14:46] right, I just did [14:47] it's for xserver-xorg-video-vmware [14:47] (I hope I didn't overlook thing) [14:47] cjwatson, thanks [15:03] 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] 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] seb128: ok, thanks [15:05] mardy_, see https://wiki.ubuntu.com/ProposedMigration if you are interested by the detailzs [15:12] 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] the apt.conf manpage only seems to have options to suppress trigger execution [15:18] ogra_: I may be mis-remembering but from a looong way back I seem to recall seeing/using OrderList::Score::Immediate [15:18] TJ-, hmm, i'll try [15:23] ogra_: as far as I know, it doesn't [15:24] weird, so that would be a packaging bug in the raspi2 package ? [15:24] that would be my first guess [15:24] hmm and the kernel team is traveling :( [15:24] deferring triggers isn't really a thing [15:24] err [15:24] enforcing :) [15:24] I mean, enforcing immediate execution of triggers isn't really a thing [15:25] OrderList::Score::Immediate is a bit different really [15:25] yeah, thats how i read the manpage [15:31] doko: Do you have an idea on how we can get past https://sourceware.org/bugzilla/show_bug.cgi?id=19188 ? [15:31] sourceware.org bug 19188 in ld "[2.26 Regression] binutils assertion fail ../../bfd/elfnn-aarch64.c:4631" [Normal,Assigned] [15:32] it's breaking webkit2gtk/arm64 which is going to be the last thing holding up a big-ish migration soon [15:43] hum [15:43] gdb doesn't work on xenial for me :-/ [15:43] (gdb) bt [15:43] Python Exception

returned a result with an error set: [15:44] those python errors is everything it returns [15:45] seb128: maybe disable autoloading python? https://sourceware.org/gdb/onlinedocs/gdb/Python-Auto_002dloading.html#Python-Auto_002dloading [15:45] sarnold, thanks [15:45] 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] sarnold, that works ;-) [15:46] yay :) [15:46] * Laney shrugs [15:47] why didn't you upload it? [15:47] Laney, because slangasek said it was on his list [15:47] didn't see a bug [15:47] he was the one who uploaded the version that failed to build [15:47] yeah, I should probably have opened one [15:47] sorry about that :-) [15:47] I though he would handle it yesterday [15:47] 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] Laney, this is https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1511542 [15:47] Launchpad bug 1511542 in unity (Ubuntu) " [2.26 Regression] binutils assertion fail ../../bfd/elfnn-aarch64.c:4631" [High,In progress] [15:48] doko, hey, gdb giving the python errors I just copied, is that known? what component should that be reported against? [15:50] doko: :( [15:53] seb128, do you have a test case, or is this just loading the pretty printer? [15:53] doko, I just do "gdb something" and "run" and ctrl-C and bt [15:53] or attach to an existing process [15:53] cyphermox: hey, who's in charge of network-manager these days? we've got a very serious regression affecting wily and xenial === mitya57_ is now known as mitya57 [16:00] slangasek, cyphermox: bug 1512749 [16:00] bug 1512749 in network-manager (Ubuntu Xenial) "lxcbr0 dissappears on Ubuntu 15.10" [Critical,Triaged] https://launchpad.net/bugs/1512749 [16:06] Laney: matplotlib 1.5.0~rc2-1ubuntu3 \o/ [16:06] Laney: i was just about to start looking at that one :) [16:07] barry: hehe [16:07] you should make more things depend on glib [16:07] then you get people like me to care :P [16:08] Laney: :) [16:08] Laney: now i know how to trick you into fixing all the bugs [16:18] slangasek, doko, cyphermox, any-other-core-dev: could you release https://bugs.launchpad.net/ubuntu/+source/ledit/+bug/1512776 for me? Thanks! [16:18] Launchpad bug 1512776 in ledit (Ubuntu) "Release no-change rebuild for ocaml transition" [Undecided,In progress] [16:19] 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] yofel: I think the easiest thing to start from is http://autopkgtest.ubuntu.com/data/status/xenial/amd64/packages.json [16:21] ah nice, that works [16:21] thanks [16:21] yofel: probably easiest with three lines of python -- iterate over status "fail" and "kde" in package, or so? [16:22] I'm fairly sure one can do it with json_pp, but I never learned the magic of this; Laney knows this [16:23] if the naming would be that easy I wouldn't have trouble :P [16:23] but we have lists of all our maintained sources, so filtering that won't be hard [16:24] pitti: yofel: The tool that I used was called 'jq' [16:25] ah, or that [16:25] thanks, I'll look at that [16:25] not knowing that i'd just do something like "for p in json.load(f.read()): if p['package'] ... [16:32] sil2100: looking [16:38] sil2100: done. [16:39] tumbleweed: did you say you had updated distro-info-data? [16:41] cyphermox: thanks! [16:42] doko: https://bugs.launchpad.net/ubuntu/+source/unity-api/+bug/1512784 - MIR request pretty please [16:42] Launchpad bug 1512784 in unity-api (Ubuntu) "[MIR] unity-api" [Undecided,New] [16:45] * ogra_ wonders whats up with the arm builders ... [16:51] ogra_: ? [16:52] 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] ogra_: they have about a ten-minute queue at the moment due mostly to a batch of KDE uploads, but nothing serious [16:53] ogra_: see https://launchpad.net/builders/ [16:53] ah, k [16:53] well, i'll wait [16:53] arm64 will take longer, but that's normal [16:53] I think the 28 minutes on your page is a misestimate [16:53] yeah, for test builds i dont care for arm64 ... i should have excluded it from ARCHES= === hikiko-lpt is now known as hikiko [17:05] tumbleweed: I ask as I don't seem them in the unapproved SRU queues [17:08] cyphermox: did you see my question above? [17:08] I had not [17:08] so, the short answer is "nobody really". [17:09] NM shouldn't touch the interfaces it doesn't manage, especially not bridges, at all, so something clearly got broken [17:09] 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] ok [17:09] which package? [17:10] lxc [17:10] cyphermox: http://paste.ubuntu.com/13092923/ [17:10] oh yuck [17:11] yeah [17:11] as I said, very very ugly workaround, does the trick though [17:11] the alternative was a "sleep 5" but well, that'd just be racy :) [17:11] yeah [17:12] so, I think we're running into more of the veth vs. straight ethernet device issue [17:12] and nmcli doesn't seem to have a "wait until we reach some kind of final state" [17:12] cyphermox: nah, it's a bridge here and NM does try to do stuff with the bridge backend code [17:13] 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] cyphermox: you'll get an interface without an IP [17:14] Nov 3 12:13:17 castiana NetworkManager[21958]: (test): new Bridge device (carrier: OFF, driver: 'bridge', ifindex: 94) [17:14] so NM does detect it as a bridge and then still does stuff to it... [17:14] it doesn't seem to start DHCP on it though, but it still does flush any pre-existing config from it [17:15] cyphermox, you are not maintainin n-m anymore? do you still plan to do the point release updates? [17:16] 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] k, just wondering if we should do updates like we handle GNOME ones === Ursinha is now known as Ursinha-afk [17:40] tumbleweed: Ah, I see its in -proposed for everything except wily. [17:41] 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] Laney: got it thanks [17:53] seb128: by all means, feel free to do the updates for NM, but some may be quite involved :/ [17:54] cyphermox, right... [18:07] 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] mterry: haven't checked for sure, but I'd expect it to FTBFS if dh_strip_nondeterminism fails [18:10] mterry: but Debian has run it in production for some time, so I figure the worst bugs have been shaken out already [18:10] mterry: and as I said on the bug, if this causes extra FTBFS the foundations team will certainly deal with this [18:10] (in the worst case by disabling it for that package or in general) [18:10] 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] pitti, cool, thanks! [18:11] mterry: right; once approved, I'll revert the delta of dropping the dep from debhelper [18:16] bdmurray: oh, yes, I forgot to verify them [18:17] bdmurray, the foundations team is looking after strip-nondeterminism in main, FYI [18:18] tumbleweed: I've verified Trusty and Vivid. [18:20] bdmurray: thanks [18:32] stgraber: what about this? http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=e29ab54335c6a5ef1ce6bac525f1f18a8e81b96e [18:37] cyphermox: the reproducer in that commit is identical to what we're doing, so that's probably right [19:04] bdmurray, and unity-api is being looked after by unity-ui-team in main, FYI! === _salem is now known as salem_ [19:35] I am trying to build .DEB package [19:36] I ran dh_make -f ../.tar.gz , then debian/rules clean, build and binary. It went good and built .DEB package [19:38] Now when I again re-run the debian/rules binary it threw error override_dh_auto_install [19:38] Error code 2 [19:38] Any idea how to fix this [19:38] decci, you should use "debuild" or "dpkg-buildpackage" to build a source package [19:39] ricotz: Do you mean use it instead of debian/rules build [19:40] jdstrand, and alabaster in main is also looked after by foundations team, fyi! [19:40] ricotz: So whats the correct way of building .DEB [19:40] * mterry is clearing out MIRs :) [19:41] ricotz: All I follow: 1. dh_make 2. debian/rule clean 3. debian/rules build 4. debian/rules binary [19:41] ricotz: Where do I need to run debuild? [19:41] ricotz: I mean after which step [19:42] decci, you downloaded a source package, e.g. having a *.dsc file lying around? [19:42] do "dpkg-source -x *.dsc", go into the src folder and run "dpkg-buildpackage" or "debuild" [19:43] 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] so you want to create a debian package from some tarball without any existing packaging information? [19:44] ricotz: This is a source code internal to company..pre-compiled and linked already [19:45] ricotz: All I am trying to do is build it to .deb [19:45] ricotz: yes [19:45] decci, you might want to use "checkinstall" then [19:46] ricotz: checkinstall doesnt handle rules, preinst and postinst [19:46] ricotz: I dont see any option for rules specification [19:46] you don't have any packaging information in the first place [19:47] ricotz: I have rules, postinst and preinst, control files in place [19:47] so simply use the tarball and build it and checkinstall creates a deb [19:47] ok, because you ran dh_make [19:47] ricotz: All I want to build .DEB package using these rules, preinst and postint [19:48] then debuild from within the root srcdir should work [19:48] ricotz: dh_make gives me debian folder with rules, post and preinst file created to add the rules [19:48] search for debian packaging details to make further adjustments if needed [19:49] ricotz: I can try debuild , so do I need to run under my source [19:49] ricotz: which has Makefile, configure.ac [19:49] ricotz: CMakeCache.txt [19:50] ricotz: What could be reason of override_dh_auto_install Error: code 2 [19:51] debuild looks for the debian folder and its content [19:51] sound like an error in your changes to rules [19:52] better paste a more detailed error output (via pastebin), so someone can look at it [19:53] I need to go [19:53] ricotz: dpkg-source: error: unwanted binary file: debian/CMakeFiles [19:54] ricotz: dpkg-source: error: detected 4 unwanted binary files (add them in debian/source/include-binaries to allow their inclusion). [19:54] bdmurray, and foundations for python-hypothesis too! [19:56] mterry: got it, thanks [19:56] dpkg-buildpackage: error: dpkg-source -b dcde_source gave error exit status 29 [19:57] bdmurray, (is this the easiest way to update the list? -- I'm fine with it, just curious if these pings get annoying) [20:00] 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] mterry: If the team isn't in that list then being notified would be useful [20:01] 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] mterry: right, we look at the packages to which those teams are subscribed [20:03] bdmurray, cool OK, then I can drop a lot of pings :) [20:03] mterry: indeed! [20:35] 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] cyphermox: sure, I'll add a testcase once we have it in xenial and working [20:36] cyphermox: I was going to SRU the ugly lxc workaround but if we can get network-manager fixed itself, even better === salem_ is now known as _salem [21:02] 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:02] Launchpad bug 1509120 in nfs-utils (Ubuntu) "Process accounting deadlock with idmapd callout when writing to NFSv4 mount" [Medium,In progress] [21:09] chiluk: oh hah, is that really just a keyutils upcall bug? [21:14] stgraber: yeah, feel free to not SRU your ugly lxc fix now if this NM update works :) [21:15] cyphermox: already reverted it in xenial, it's clearly not something I wanted to have to keep around :) [21:15] ack. [21:19] slangasek: yes it is. [21:20] 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] do I have that right? [21:23] 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] hmm [21:24] afaik.. but I wouldn't consider myself an nfs expert by any stretch of the imagination [21:24] should anyone? ;) [21:24] we were only able to rerpoduce the hang by using an ancient 2.6.32 centos machine [21:24] precisely because sec=sys isn't supported by such an ancient kernel. [21:24] do you know what the RPC is that triggers this path, vs. working via idmapd? [21:25] I don't. [21:25] ok [21:25] I could tcpdump it real quick if you'd like. [21:25] slangasek: ^^ [21:25] chiluk: hit me [21:26] don't tempt me... [21:26] chiluk: has this been reproduced cross-architecture? [21:27] chiluk: because my next question is, is it reproducible with the 14.04.0 kernel or only with hwe-v? [21:27] 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] oh no, I'm using 3.13. [21:27] ok [21:28] 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] nm I can capture from the server. [21:30] chiluk: I think I'm happy without the tcpdump [21:30] slangasek, yeah .. I was a bit curious myself about the rejected rpc call. [21:49] FWIW, Debian 786690 still affects wily. [21:49] Debian bug 786690 in pbuilder "pdebuild fails to builds package with dpkg-dev 1.18.0 (dpkg-buildpackage -S failing with missing build-deps)" [Important,Fixed] http://bugs.debian.org/786690 [22:59] i'm blinking over "1TB PCIe Solid State Drive" whilst starring at XPS 15 (9550). [23:00] ooo [23:00] chrisccoulson: ^^^ [23:00] 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] http://www.dell.com/uk/p/xps-15-9550-laptop/pd [23:01] superm1: is XPS 15 (9550) pre-orderable as a developer edition? i shall give them a call tomorrow. [23:05] 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] But tomorrow at least some of them should be available, so I can continue from there then [23:07] xnox: not currently. It's a work in progress still. [23:07] danjared: will know current status better than I [23:09] sil2100: yeah, for that number it's sensible just to wait - at least the ocaml stack isn't too deep [23:09] the queue's "only" an hour long at the moment [23:41] what'd I do? [23:42] xnox: no, no current plans for an Ubuntu version of the XPS 15. there are plans for the Precision Mobile 5510