[00:07] <nacc> doko: ok, so the merge for ldb is pretty ugly because of the python3 churn. I've put up what I think is the broken out delta (the order may not be fully correct yet, but I think it's close) at: https://git.launchpad.net/~nacc/ubuntu/+source/ldb?h=merge I've also pushed a few tags (old/debian, old/ubuntu, new/debian which should help give some reference to what is being merged where)
[00:07] <nacc> doko: i put your nick in a few commit messages, if you could look and help me understand then :)
[00:08] <nacc> s/then/them/
=== aet_zombie is now known as aet_rogue
=== marcusto_ is now known as marcustomlinson
[08:33] <cpaelzer> I need an advise how to resolve something in zetsy proposed migration
[08:33] <cpaelzer> I verified DPDK (new version) and Openvswitch (no change rebuild against it) both test fine
[08:34] <cpaelzer> Then I published from bileto
[08:34] <cpaelzer> I have expected that they test the same
[08:34] <cpaelzer> but in my case openvswitch is fine (testing the new OVS vs the new DPDK)
[08:34] <cpaelzer> yet the autopkgtests for DPDK run against the OLDER version of openvswitch
[08:34] <cpaelzer> those fail, but that is clear
[08:35] <cpaelzer> can I in some way tell the autopkgtets on DPDK to run against the newer openvswitch version?
[08:35] <cpaelzer> then all would resolve and both could migrate
[08:36] <cpaelzer> rbasak: ^^ TL;DR copying both from bileto as we discussed yesterday triggered the old OVS to be tested
[08:36] <sarnold> if the package requires the newer version should it use a versoined depends?
[08:38] <cpaelzer> sarnold: openvswitch depends on dpdk, and after build it gains versioned depends automatically by the binaries
[08:38] <cpaelzer> sarnold: but vice versa - DPDK does not depend on openvswitch at all
[08:39] <cpaelzer> sarnold: it only triggers the dep8 test of (the old) openvswitch
[08:40] <sarnold> cpaelzer: oh. ofccourse. because dpdk is useful even without.. isgh. I should have gone to bed an hour ago. :)
[08:41] <cpaelzer> sarnold: I'm happy to discuss any suggestion before I do another "no change upload"
[08:41] <cpaelzer> sarnold: and - yes - sleep well and soon :-)
[08:43] <sarnold> cpaelzer: if you don't get any better answers, this looks promising https://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/tree/doc/README.package-tests.rst#n91
[08:45] <infinity> cpaelzer: So, the new dpdk breaks the old openvswitch?
[08:45] <sarnold> hey look it's better answers :)
[08:47] <infinity> cpaelzer: Why does the new dpdk break the old openvswitch?
[08:49] <cpaelzer> infinity: TL;DR of a more complex detail "by no more providing the same .so version"
[08:49] <infinity> cpaelzer: (Or, put another way: this is exactly why autopkgtests exist)
[08:50] <infinity> cpaelzer: Erm.  Come again?  If there was an ABI bump *and the packages were renamed to match*, there wouldn't be a failure here.
[08:50] <infinity> cpaelzer: If you have an ABI bump/break and the packages are not renamed, you have a bug in your library.
[08:50] <cpaelzer> infinity: you remember our discussion on upstream dpdk craziness
[08:50] <cpaelzer> that is the TL;DR part I meant above
[08:50] <infinity> Yes, and the conclusion of that conversation was that upstream crazy would not affect us.
[08:51] <infinity> You have versioned packages for every library.  So, what went wrong?
[08:51] <cpaelzer> hmm maybe I really need breaks for this special case
[08:51] <cpaelzer> let me try to summarize
[08:51] <infinity> You don't need Breaks yet until you can explain why this isn't working as-is. :P
[08:51] <cpaelzer> hehe
[08:52] <cpaelzer> some of the libraries got abi bumps and thereby new package names
[08:52] <cpaelzer> some other sublibs did not get bumps, so they did not get renames
[08:53] <infinity> So far, all of this should work.
[08:53] <infinity> So, what broke?
[08:53] <cpaelzer> but most sublibs that got a bump, depend on some others that got one
[08:54] <cpaelzer> what I've seen when reproducing locally it ended up with OVS depending on the old soname and another lib, that other lib depended on the new soname
[08:54] <infinity> So, uhm.  WTF.
[08:54] <cpaelzer> I need to start that again locally to get the exact versions, but eventually ldd on ovs ended up referring to BOTH ABI versions
[08:54] <infinity> Why is librte-cryptodev1 in zesty-proposed as an arch:all package?
[08:55] <infinity> And libethdev4
[08:55] <infinity> And librte-eal2
[08:55] <cpaelzer> infinity: the old versions are transitional packages to the newer versions
[08:55] <cpaelzer> yeah that might be the break
[08:55] <infinity> If those are "transitional" packages, someone very much doesn't understand why libraries have package name to sover mappings.
[08:56] <infinity> cpaelzer: DO NOT DO THAT EVER. :P
[08:56] <infinity> If appfoo depend on libbar2, libbar3 is not a replacement.  Thus, you can't have a transitional package.
[08:56] <infinity> Kinda the whole point.
[08:56] <cpaelzer> I tihnk in that case I only missed it on a reivew , but yeah that is it
[08:56] <cpaelzer> I'll tackle that
[08:57] <infinity> If those transitionals go away, then the tests will pull in the right libs, and it should all work.  If that remains untrue, you have an undeclared ABI break somewhere.
[08:57] <infinity> (And when they go away in the packaging, you'll need to ask an archive admin to remove the NBS cruft from -proposed)
[08:57] <infinity> cpaelzer: ^
[08:58] <cpaelzer> infinity: yeah thank you
[08:58] <cpaelzer> infinity: can we remove them right away until ther is a fixed upload available?
[08:58] <infinity> cpaelzer: I'd prefer not to.
[08:59] <infinity> cpaelzer: In that I want to make sure the fix is correct, by seeing britney tell me that you no longer build X/Y/Z package.
[08:59] <infinity> cpaelzer: They do no harm sitting in proposed.
[08:59] <infinity> (I'd be more concerned if there was a similar issue with -dev packages, and thing were being misbuilt, but that doesn't look to be the case)
[09:00] <cpaelzer> infinity: but when I want to verify that a fix in a 16.11-1ubuntu2 helps it will still find and consider the bad trnasitional packages
[09:00] <cpaelzer> infinity: but I'm fine pinging to clean up once there is a new upload
[09:00] <infinity> cpaelzer: Also, please apply a verbal ruler to the knuckles of whoever did this.  It displays a pretty fundamental misunderstanding of why library package names are versioned, so it would be nice to make sure they "get it".
[09:01]  * cpaelzer goes away to clean up and to sort out if he punches himself or others
[09:01] <cpaelzer> thanks infinity
[09:01] <infinity> cpaelzer: Yeah, upload, wait for binaries, ping for removal of cruft, rerun tests, verify in the logs that the tests didn't pull in stuff from the bad version, (hopefully) win.
[09:02] <infinity> Score a win for autopkgtest finding real bugs, though.
[09:05]  * sarnold hangs his head
[09:05] <sarnold> score a loss for sarnold for looking for the 'lets fix it quick' answer
[09:07] <infinity> sarnold: Standard bug reporting practice: Start from the problem (updating dpdk breaks openvswitch) rather than the proposed solution (update both together), and then hunt down the "why".
[09:07] <infinity> sarnold: Alternately, be a jaded jerk like me and just start from the assumption that someone's done something wrong (I don't recommend this method, it's a bitter and lonely world view).
[09:08] <sarnold> infinity: <3
[09:08] <cpaelzer> once asking here the assumption that something is wrong is mostly true
[09:08] <cpaelzer> and better pointing out old mistakes to make a good fix than sneaking by
[09:08] <sarnold> infinity: I think my mistake was starting with the unsaid assumption that a new feature wasn't being tested as expected vs existing stuff broke..
=== _salem is now known as salem_
[12:05] <zul> doko: ping can you have a look ath python-os-xenapi, python-tinyrpc, and python-marathon please?
[12:05] <doko> zul: sorry, forgot about that from yesterday
[12:06] <zul> doko: no problems
=== JanC_ is now known as JanC
[13:02] <coreycb> doko, can you also take a look at neutron-lbaas-dashboard please?  that would cover everything in the new queue for us in openstack!
=== dasjoe_ is now known as dasjoe
[13:24] <hikiko> hey :) @packagers: https://bugs.launchpad.net/ubuntu/+source/libsoxr/+bug/1658318 there's a bug in this package the fix is 1 line (on sid it's ok) could you get a look?
[13:24] <ubottu> Launchpad bug 1658318 in libsoxr (Ubuntu) "libsoxr is built with debug flags and prints too much stderr info" [High,New]
[13:27] <seb128> hikiko, hey, seems like you have a clue what to change, you could perhaps try to see if you can get the package source and provide a patch to sponsor?
[13:29] <seb128> hikiko, in fact seems it bug #1649224 and fixed in zesty so should be easy enough to backport the patch if you want to have a try
[13:29] <ubottu> bug 1649224 in libsoxr (Ubuntu) "Package compiled with DEBUG flag" [Undecided,Fix released] https://launchpad.net/bugs/1649224
[13:30] <doko> zul: done
[13:31] <zul> doko: thanks
[13:31] <zul> doko: tinyrpc as well?
[13:36] <hikiko> seb128, to be honest I don't know how to backport it that's why I only reported it, are there any instructions?
[13:36] <seb128> hikiko, you never backported a patch from e.g a devel compiz to a stable one?
[13:37] <seb128> hikiko, basically apply the diff/commit to the stable codebase the same way you would do for the current one
[13:37] <hikiko> no :) I submit the code on trunk and then Marco decides what to backport :p
[13:37] <seb128> interesting
[13:37] <Laney> hikiko: https://anonscm.debian.org/cgit/pkg-multimedia/libsoxr.git/commit/?id=3e438f41361a533fdefdd270b0326398592fa47b <- probably need to apply that diff
[13:37] <seb128> I suggest that's something you should get familiar with then ;-)
[13:37] <hikiko> yep
[13:37] <hikiko> I agree
[13:37] <hikiko> +all that SRU stuff that sounds chinese to me :)
[13:38] <hikiko> Laney, https://launchpadlibrarian.net/300174877/libsoxr_0.1.2-1_0.1.2-2.diff.gz
[13:38] <hikiko> I think there's already a diff in launchpad
[13:38] <seb128> hikiko, read https://wiki.ubuntu.com/StableReleaseUpdates
[13:38] <hikiko> shouldn't I apply that?
[13:39] <seb128> hikiko, SRUs tend to focus on just applying the strictly required changes so you probably just want the part Laney gently pointed out doing the work for you ;-)
[13:40] <hikiko> ok ok give me a few minutes to read all that
[13:41] <seb128> hikiko, if you have any question let me know
[13:41] <hikiko> thanks seb128
[13:43] <xnox> barry, it looks like armhf (lxd on arm64?!) runners are setup differently to the s390x (lxd on s390x) runners
[13:43] <xnox> e.g. s390x is sufficiently good to pass docker.io smoke-test; but armhf is not.
[13:43] <xnox> E: Cannot install into target '/tmp/tmp.IjgK7JuH0D' mounted with noexec or nodev
[13:43] <xnox> on armhf; which is not seen on s390x.
[13:43] <xnox> see this: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty-ci-train-ppa-service-2430/zesty/armhf/d/docker.io/20170201_115223_319e7@/log.gz
[13:43] <xnox> and https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty-ci-train-ppa-service-2430/zesty/s390x/d/docker.io/20170201_114941_319e7@/log.gz
[13:48] <hikiko> seb128, https://code.launchpad.net/ubuntu/+source/libsoxr/+all-branches there's no xenial package here :s
[13:49] <hikiko> sorry found :)
[13:50] <seb128> hikiko, work from the source package and debdiff, http://packaging.ubuntu.com/html/traditional-packaging.html#
[13:51] <coreycb> doko, i tagged the glanceclient bug as verification-done.  kombu is fix-released now.
[13:51] <seb128> hikiko, UDD is not used much anymore, just read that page it explains what you need
[14:26] <barry> xnox: interesting.  i'll look more closely in a bit
[14:27] <xnox> barry, thanks. Would be nice to make "armhf" more like "s390x" then docker.io smoke-test would pass there too
[14:30] <zul> doko: can we get them out of binary new as well?
[15:04] <CRogers> Hi folks. :)
[15:04] <CRogers> I was wondering if there are plans to remap alt-drag window moving to Super-drag.
[15:05] <CRogers> It interferes with all the creativity tools. Every single one of them.
[15:05] <CRogers> So it's really crippling to new users.
[15:07] <CRogers> With only a few exceptions, I think all wm actions should be mapped to use the super key.
[15:07] <CRogers> so they do not clash with application hotkeys.
[15:08] <CRogers> The only exceptions being alt-tab and alt-shift-tab
[15:08] <CRogers> Because of cross-platform compatibility.
[15:26] <doko> coreycb: does neutron-lbaas-dashboard have a python3 port?
[15:30] <doko> anyway, accepted
[15:32] <Laney> gah at full /boot
[15:52] <Laney> xnox: barry: Looks like mknod works for lxc but not lxd - that much reproduces locally
[15:53] <Laney> i.e. you can debootstrap in the former but not the latter ootb without any special autopkgtest setup
[15:53] <xnox> oh, armhf runners are lxc based, instead of lxd?
[15:53] <Laney> yes
[15:53] <xnox> horum.
[15:53] <Laney> no
[15:53] <Laney> the other way around
[15:53] <xnox> s390x is lxd for sure.
[15:53] <Laney> wrong
[15:53] <xnox> bah
[15:53] <barry> yeah, i thought they were lxd also
[15:53]  * xnox wants scalingstack all the things
[15:53] <Laney> nope
[15:53] <Laney> they're lxc
[15:53] <Laney> you can see that near the top of the log
[15:54] <barry> yep, i see that now
[15:54] <barry> wait
[15:54] <barry> "lxd -r lxd-armhf-10.43.44.70 lxd-armhf-10.43.44.70:autopkgtest/ubuntu/zesty/armhf
[15:54] <barry> autopkgtest [11:47:12]: @@@@@@@@@@@@@@@@@@@@ test bed setup"
[15:55] <barry> so armhf lxd; 390 lxc
[15:55] <Laney> yes
[15:55] <Laney> and that corresponds with what can do debootstrap here too
[15:55]  * barry wonders what stgraber thinks about that difference
[15:57] <barry> Laney: do you know why the two don't use the same thing?
[15:58] <stgraber> barry: LXD is safe by default, LXC isn't
[15:58] <xnox> possibly because lxd cloud images for s390x were not yet published when pitti setup adt runners
[15:59] <stgraber> LXD uses unprivileged containers, LXC runs as real root in the container. And you can't mknod as an unprivileged user as that'd be a straight escalation to real root and escaping the container.
[15:59] <barry> xnox: could be, could be.  if they're published now, it might make sense to switch s390x; seems like we'd want to reduce the environmental differences between the different architectures as much as possible (env differences are hard to discover magic)
[15:59] <stgraber> if you don't care about that kind of security (and it may well be that you don't), then setting security.privileged=true for your LXD container should give you roughly the same behavior as LXC
[15:59] <Laney> barry: s390x runs on some random static machines
[15:59] <Laney> It's not in the cloud
[16:02] <xnox> barry, i'd rather keep s390x as it is; until bos02 is up and we move it to kvm instances off scalingstack.
[16:05] <barry> xnox, Laney i'd be inclined to add isolation-machine to docker.io's basic-smoke test in d/tests/control
[16:06] <xnox> barry, i removed it, such that the test is run on s390x and passes.
[16:06] <xnox> barry, the test passes and would have caught regression of us shipping docker.io into xenial-updates which could not launch any container =)
[16:06] <xnox> barry, also note that currently docker-in-lxd test case is broken too, and I believe it is one of our features to support docker inside lxd.
[16:07] <xnox> barry, i wonder if I can tweak the smoketest to pull/download a container rather than debootstrap it.
[16:07] <xnox> (ibm noticed and it was kind of embarrassing)
[16:08] <Laney> It reproduces perfectly well locally on your x86 system, so go wild :-)
[16:10] <xnox> true.
[16:11] <barry> xnox: yeah, that seems like a good thing to try.  my only question is whether that should be the same basic-smoke test or a copy of it, and whether it should try to do debootstrap if it can (i.e. not deviate too much from debian for the existing test, but add another test that would pass on armhf, since that could be pushed up into debian)
[16:35] <lamont> should I be able to do-release-upgrade -d to zesty ?
[16:39] <slangasek> yes
[16:40] <xnox> and check that update-manager config file specifies non-lts releases as viable options.
[16:41] <xnox> Prompt=normal in /etc/update-manager/release-upgrades
[16:43] <bdmurray> xnox: Do you still have plans to work on bug 1651623? I'd like to turn on crash reporting to LP for Zesty.
[16:43] <ubottu> bug 1651623 in apport (Ubuntu Yakkety) "adt tests fail on zesty for apport" [Undecided,New] https://launchpad.net/bugs/1651623
[16:44] <xnox> yes, i do
[16:44] <bdmurray> hmm, maybe I should have been more specific. ;-)  soon?
[16:45] <xnox> yes. it did slip January target now, which is sad.
[16:46] <lamont> it complains that htere is an unresolvable issue in calculating the upgrade... what file or options do I want to feed it?
[16:46] <lamont> slangasek: ^^
[16:47] <bdmurray> lamont: look at /var/log/dist-upgrade/main.log or apt.log
[16:48] <bdmurray> lamont: or use ubuntu-bug ubuntu-release-upgrader and I can have a look at the logs
[16:49] <lamont> that sounds best, since my next question was "what am I looking for in the logs..." :/
[16:51] <bdmurray> lamont: I've got an errand to run, but let me know the bug and I'll look when I get back.
[16:55] <lamont> bdmurray: it's still churning.  I'll toss you the bug number whne I get it
[17:04] <lamont> bdmurray: specifically, bug 996916
[17:04] <ubottu> bug 996916 in update-manager (Ubuntu) "postgresql packages in the removal blacklist making it hard to upgrade" [Undecided,Confirmed] https://launchpad.net/bugs/996916
[17:10]  * lamont purges postgresql-9.5 and postgresql-common and tries again
[17:19] <lamont> bdmurray: and then also removing postgresql-9.5-postgis-2.2-scripts and postgresql-9.5-postgis-scripts made for a happier upgrade
[18:55] <halvors> Hi!
[18:55] <halvors> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1634855
[18:55] <ubottu> Launchpad bug 1634855 in systemd (Ubuntu) "Assertion 'link->state == LINK_STATE_SETTING_ROUTES' failed at ../src/network/networkd-link.c:697, function link_enter_configured(). Aborting." [Critical,Confirmed]
[18:57] <halvors> I'm experiencing this bug, and i wounder if there is a developer online.
[18:57] <halvors> A developer or maintainer that can backport the fix from upstream systemd.
[18:58] <halvors> This causes a lot of issues since basically if the link goes down for a moment, the whole network stack crashes.
[18:59] <rbasak> networkd isn't default, is it?
[19:06] <rbasak> halvors: see https://wiki.ubuntu.com/StableReleaseUpdates and https://wiki.ubuntu.com/SponsorshipProcess. If you can attach debdiffs to the bug for Zesty (if applicable) and Xenial, follow the SRU procedure and subscribe ~ubuntu-sponsors, somebody will able to process it through the sponsorship queue.
[19:07] <halvors> No it's not. But it's used a lot since the "ifupdown" package is unreliable when it comes to newer network technologies that is not supported by it.
[19:07] <halvors> Also Ubuntu as far as i know is moving towards systemd-networkd.
[19:09] <rbasak> Sure, it's a bug and we should fix it. But it's hardly Critical.
[19:33] <nacc> iiuc, already fixed in z and y (by virtue of upstream version)
[19:42] <halvors> rbasak: Yeah. Anyone here knows how to do a backport with diffs?
[19:42] <halvors> And are willing to do it?
[20:02] <nacc> rbasak: ntfs-3g and snapd failed to import, could you take a look at why that might have happened?
[20:04] <rbasak> nacc: where do I look?
[20:05] <nacc> rbasak: try to run the importer locally :)
[20:05] <nacc> rbasak: on those src pkgs
[20:06] <rbasak> Ah, of course. Thanks :)
[20:06] <nacc> rbasak: np, just got a report of a few failures (first in a while) in the importer report to the list and i'm heads-down on the iscsi stuff
[20:24] <zul> doko: when you get a chance can you review python-murano-pkg-check
=== nacc_ is now known as nacc
[21:08] <nacc> rbasak: is LP: #1661092 also what makes ntfs-3g fail?
[21:08] <ubottu> Launchpad bug 1661092 in usd-importer "Import fails when debian directory is a symlink" [High,Triaged] https://launchpad.net/bugs/1661092
[21:08] <nacc> rbasak: and thanks for tracking that down :)
[21:09] <rbasak> nacc: no, ntfs-3g is a separate failure.
[21:09] <rbasak> I think it's a parent determination problem.
[21:09] <rbasak> It didn't use the parent in the proposed pocket when importing the release pocket.
[21:10] <rbasak> After that parenting is correct.
[21:10] <rbasak> But the result is that ubuntu/yakkety-devel is non-fast-forwarding
[21:10] <rbasak> I don't see any obvious reason for that from the DAG alone.
[21:10] <nacc> hrm
[21:16] <nacc> rbasak: ok, this *might* be a case of ntfs-3g having been imported with an older version of the importer
[21:17] <nacc> rbasak: could you do a run with -o baz or whatever and see if it does use y-p properly (with --no-push --no-clean i suppose)
[21:18] <rbasak> nacc: can do, but I see nothing wrong with the current state.
[21:20] <nacc> rbasak: well, other than y not using y-p as a changelog parent
[21:20] <nacc> rbasak: as, iiuc, that version should have already been imported to y-p when the publish to y was found
[21:20] <rbasak> Ah. I hadn't seen that.
[21:21] <nacc> it might have been imported by a buggy importer (there was some churn a while ago wrt the changelog parent)
[21:25] <nacc> right, so on lp, y-d points to y-p (1:2.016.2.22AR1-3), but the importer is moving it to y-u, which has has parents (going backwards), y-s, and y, and since y does not have y-p in its ancestry, the ff failed.
[21:26] <nacc> i wonder if we should switch the devel pointers from branches to refs
[21:26] <nacc> i'm not entirely sure they are guaranteed to be ff generally
[21:26] <nacc> symbolic refs, that is
[21:26] <rbasak> I see
[21:26] <rbasak> You mean symbolic refs?
[21:26] <rbasak> Or generic refs with no particular type?
[21:27] <nacc> yeah, then we could just move them as we update where they point to (the 'latest' published version in a series)
[21:27] <nacc> it would break existing imports, though, i guess
[21:27] <nacc> i guess we could delete the branches and create the refs, possibly
[21:27] <rbasak> Yeah. Or just delete the branches and re-run the importer on everything?
[21:27] <nacc> right
[21:28] <nacc> that's true, it'd 'fix' them all up
[21:28] <rbasak> I suppose, because of the security trumping proposed thing, logically the devel pointers (or branches or whatever they are) _can't_ be fast forwarding.
[21:28] <nacc> well, first step is seeing if the importer is 'correct' if started fresh, at least for src:ntfs-3g, then we can decide how best to proceed
[21:29] <rbasak> Unless we create another parent to make it so.
[21:29] <nacc> rbasak: right, that's the reason, i agree
[21:29] <nacc> rbasak: they really are meant to just be references, i think -- just shortcut names
[21:29] <rbasak> I can see how a user might expect to follow a -devel branch though.
[21:30] <nacc> rbasak: yeah, i agree -- we probably need to have a think about it
[21:32] <doko> zul: MIRs approved. one lacking a python3 package
[21:32] <doko> zul: will do the other NEW review tomorrow
[21:33] <nacc> doko: if it'd be easier to review the ldb changes / questions, I can send e-mail with a debdiff (I realize the git tree may not be the most clear necessarily)
[21:34] <doko> nacc: sorry. yes, then the chance is lower that I forget about it :-/
[21:35] <nacc> doko: np! thanks :)
[21:59] <rbasak> nacc: re-importing all of ntfs-3g works. Is that because yakkety-devel is only set at the end?
[22:00] <nacc> rbasak: in that import, does y have y-p has an ancestor?
[22:06] <jgrimm> nacc, when you get a moment can you import python-boto? does not seem to be auto imported yet
[22:07] <nacc> jgrimm: running
[22:09] <jgrimm> nacc, thanks, maybe moin too while you are at it?
[22:09] <nacc> jgrimm: also running
[22:09] <jgrimm> :) you rock!
=== JanC is now known as Guest9668
=== JanC_ is now known as JanC
[22:51] <nacc> jgrimm: python-boto is done
[22:52] <jgrimm> nacc, i saw thanks.  i'll watch for moin, no need for you to poll
[22:52] <nacc> jgrimm: ok, np
[22:55] <foli> This it to notify the we are beginning maitenance on Canonical data centre firewalls.
[22:56] <jgrimm> thanks foli
=== ChanServ changed the topic of #ubuntu-devel to: Canonical datacentre firewall maintenance 23:00 - 00:00 UTC | Yakkety Yak (16.10) Released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-yakkety | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots:
[23:33] <rbasak> nacc: git merge-base --is-ancestor lpusip/ubuntu/yakkety-proposed lpusip/ubuntu/yakkety && echo yes || echo no
[23:33] <rbasak> nacc: git merge-base --is-ancestor lpusip/ubuntu/yakkety-proposed lpusip/ubuntu/yakkety && echo yes || echo no
[23:33] <rbasak> git merge-base --is-ancestor lpusip/ubuntu/yakkety-proposed lpusip/ubuntu/yakkety && echo yes || echo no
[23:34] <rbasak> nacc: git merge-base --is-ancestor lpusip/ubuntu/yakkety-proposed lpusip/ubuntu/yakkety && echo yes || echo no
[23:34] <rbasak> I'm sorry. I was scrolled up. Thought it wasn't pasting.
[23:36] <rbasak> Anyway, the answer was "no".
[23:36] <rbasak> I pushed to lpmep:ntfs-3g
[23:55] <nacc> rbasak: ack, will look