[00:20] <nacc> rbasak: if you get a chance take a look at the latest commits on lpusip:memcached#ubuntu/yakkety,{-proposed}
[00:20] <nacc> rbasak: those are achieved with the importer/ namespace implemented and with upload/ tag support (so in this case, I had the upload/ tag in my local repository that i then used as the basis for import)
[00:46] <halvors1> Hi. There is core dumps in systemd for last patch for systemd in xenial as well as yakkety.
[00:47] <halvors1> What happend here? Everything worked just fine before the "security update" and the last "change" in yakkety way after the freeze zone...
[00:55] <sarnold> halvors1: what bug number?
[01:17] <halvors1> sarnold: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1633274
[01:17] <ubottu> Launchpad bug 1633274 in systemd (Ubuntu) "Systemd-networkd crashes with core dump" [Undecided,New]
[01:20] <sarnold> halvors1: very nice, thanks
[01:23] <halvors> I don't know exactly how yakkety is affected as well, the bug seems to be appearing only when i attach the VTI interface to a physical interface.
[02:09] <Bluefoxicy> I can't find the bug for "flash is completely broken in 16.10"
=== _salem is now known as salem_
=== salem_ is now known as _salem
[05:29] <pitti> Good morning
[08:46]  * Mirv frequently refreshes https://launchpad.net/ubuntu/+series
[08:53]  * acheronuk prays for a slight break with the animal theme (zombie)
[09:44] <rbasak> nacc: nice!
[09:44] <rbasak> Interesting that the commit date appears to go backwards.
[09:44] <rbasak> (in ubuntu/yakkety)
[09:45] <rbasak> I guess that's just a consequence of the test using historical data in this case.
[11:12] <tsimonq2> cyphermox: Hello, what should I reply with here? https://www.reddit.com/r/Lubuntu/comments/57eg8q/vpn_icon_in_applet_tray/
[11:12] <tsimonq2> cyphermox: Afair, that's your specialty ;)
[11:18] <brendand> tsimonq2, ask them to post 'nmcli conn'
[11:22] <tsimonq2> brendand: ok
[11:50] <pitti> smoser: I revisited bug 1629797 and now sent a D-Bus patch upstream which solves this in a more intrusive, but also much more elegant way, FYI
[11:50] <ubottu> bug 1629797 in dbus (Ubuntu) "resolve service in nsswitch.conf adds 25 seconds to failed lookups before systemd-resolved is up" [Undecided,Triaged] https://launchpad.net/bugs/1629797
[11:50] <pitti> smoser: so I'll see to getting this into z and Debian unstable soon, and at some point we can backport it to x and lose that workaround in cloud-init.service
[11:59] <rbasak> pitti: do you have a link to the upstream patch please? I'm curious.
=== _salem is now known as salem_
[12:23] <vip> hello
=== Guest76323 is now known as tlbr
[12:55] <pitti> rbasak: I linked it from the bug, freedesktop bug 98254
[12:55] <ubottu> Freedesktop bug 98254 in core "Deadlock/timeout if early boot services try to connect to D-Bus" [Normal,New] http://bugzilla.freedesktop.org/show_bug.cgi?id=98254
[12:56] <rbasak> Thanks!
[13:04] <smoser> pitti, link to upstream in the bug ?
[13:05] <pitti> smoser: I did
[13:09] <coreycb> pitti, hello, bug 1623107 is ready for another look if you have a chance
[13:09] <ubottu> bug 1623107 in python-pylxd (Ubuntu Xenial) "[SRU] python-pylxd 2.0.5" [Undecided,In progress] https://launchpad.net/bugs/1623107
[13:15] <pitti> coreycb: http://launchpadlibrarian.net/289337158/python-mock-services_0.2-0ubuntu3_0.2-0ubuntu0.16.04.1.diff.gz looks a bit strange -- why did you remove the changelog?
[13:16] <pitti> coreycb: this is a build dep only, right? so it'll go into universe
[13:16] <coreycb> pitti, hmm, confused.. I didn't think python-mock-services existed in xenial
[13:17] <coreycb> pitti, it is a build dep only, yes.  I adjusted the changelog from yakkety so that the version is < yakkety
[13:17] <pitti> coreycb: I mean normally you'd take the y package, add a new changelog record for 0.2-0ubuntu3~16.04 (or ~xenial) and keep the rest
[13:17] <pitti> coreycb: but, nitpicking
[13:17] <coreycb> pitti, yeah I should have done that
[13:18] <pitti> coreycb: accepted; I'll let it build and binNEW it after that, then pylxd should start building
[13:18] <coreycb> pitti, thanks
[13:23] <coreycb> infinity, RAOF:  hello, any chance one of you could put xenial nova and neutron* in your sru review list for next week?
[13:23] <pitti> coreycb: …done
[13:23] <coreycb> pitti, thanks again
[14:44] <smoser> is there some tool that i can point at a changelog and it will download me the right orig tarball from launchpad ?
[14:46] <smoser> i'm aware of pull-lp-source, but basically want to run 'get-orig-source' in some directory, have it read the debian/changelog, and downlaod the .orig.tar.gz (or .tar.xz)
[14:46] <smoser> probably of the last non-UNRELEASED version
[14:46] <pitti> no, I don't think there's something that general
[14:46] <pitti> well, uscan --download-current-version --rename
[14:46] <pitti> that shold actually do what you want
[14:46] <cjwatson> only if it actually matches upstream
[14:47] <cjwatson> I'd be inclined to build something out of dpkg-parsechangelog + dget
=== salem_ is now known as _salem
[15:02] <nacc> smoser: to make it easier to build with teh importer, right?
[15:04] <smoser> yeah.
[15:05] <smoser> i just git clone, but then build says E_NO_ORIG_TARBALL
[15:05] <cjwatson> I always preferred the pristine-tar approach to this personally, although I've sensed that falling out of favour a bit
[15:05] <nacc> rbasak: yeah, i think that's an artifact of my local git-dsc-commit reconstruct having been done a few days ago, and the publish actually haveing occurred a week ago
[15:05] <cjwatson> and it does require tool support
[15:06] <nacc> cjwatson: right, that's what i was considering adding, although it will slow down our importer more
[15:06] <cjwatson> (all my git-dpm-managed packages have a pristine-tar branch that stores deltas versus commits on the upstream branch)
[15:06] <nacc> smoser: but agreed, it's a needed functionallity
[15:06] <smoser> i'm working on one.
[15:07] <rbasak> I imagined a tool that would use a cache somewhere in .git, and populate that if required, only on user demand.
[15:08] <nacc> rbasak: ack, i'm just worried about how large that cache might get, and it's a bit of complication to the 'importer' code proper -- i guess it could live in a different tool, though
[15:09] <barry> smoser: http://paste.ubuntu.com/23323900/
[15:09] <rbasak> Different tool is what I had in mind. Though if somehow the same cache could be used for both, that would be nice.
[15:09] <barry> that's what i've been using for a while now.  requires chdist.  not sure it's what you want, but you can easily run `gbp build-package` over the result
[15:10] <smoser> barry, thanks.
[15:11] <nacc> rbasak: ack, agreed
[15:12] <nacc> rbasak: at the minimum, i think the importer can stash the 'last' imported debian and ubuntu orig tarballs in there
[15:12] <nacc> rbasak: as those seem the 'most' valuable for the development side
[15:12] <rbasak> Yeah, but in smoser's clone use case, his cache would start off empty.
[15:13] <nacc> ack, we'd need to have a separate tool still, no matter what i tihnk
[15:13] <nacc> which is good, as 'building' is different from 'importing' :)
[15:21] <nacc> smoser: in your c#3 to LP: #1633114, doesn't that leave the trailing maintainer entry
[15:21] <ubottu> Launchpad bug 1633114 in usd-importer "provide debian/changelog information in commit messages" [Medium,Triaged] https://launchpad.net/bugs/1633114
[15:22] <rbasak> Perhaps even a tool that shares its cache with pull-lp-source?
[15:22] <rbasak> Using ~/.cache (XDG-ized) etc perhaps.
[15:23] <rbasak> But YAGNI, perhaps.
[15:27] <smoser> cjwatson, dget would require deb-src lines, right ? nacc that was by design
[15:27] <smoser> shoot
[15:27] <smoser> sorry, cjwatson . that was just in by buffer
[15:27] <cjwatson> er possibly, yeah
[15:28] <smoser> nacc, that was by design, as it is in the commit Author
[15:28] <smoser> right?
[15:29] <nacc> smoser: i agree, but it *does* leave the line in my case -- but in your comment
[15:31] <nacc> *but not
[15:31] <nacc> http://paste.ubuntu.com/23324002/
[15:32] <nacc> git diff import/1.4.1-1^..import/1.4.1-1 -- debian/changelog | sed -e '/^[+]/!d' -e 's/^[+]//' -e '/^ /!d'
[15:49] <smoser> alright...
[15:49] <smoser> so
[15:49] <smoser>  https://launchpad.net/ubuntu/+archive/primary/+files/isc-dhcp_4.3.3-5ubuntu14.dsc
[15:49] <smoser> dget https://launchpad.net/ubuntu/+archive/primary/+files/isc-dhcp_4.3.3-5ubuntu14.dsc
[15:49] <smoser> always fails for me, and i have to pass '-u'
[15:49] <smoser> what is the right way to m ake it pass ?
[15:52] <bdmurray> happyaron: Are you about? Your fcitx upload has no Launchpad-Bugs-Fixed in it.
[15:52] <smoser> nacc, did you figure it out ? i probably changed something and didn't update what i put inthe comment
[15:52] <nacc> smoser: no, i just wanted to make sure i wasn't missing something obvious, i can tweak the regexs
[15:57] <nacc> smoser: for dget, wouldn't it need to know the public key for whoever uploaded that version? is that what is' verifying?
[15:57] <nacc> *it's
[15:57] <cjwatson> smoser: there isn't necessarily a good reason to expect that you'll have the necessary public key, for Ubuntu.  For Debian, where that tool was written, they're generally in the debian-keyring package.
[15:58] <cjwatson> smoser: transport security is probably OK in this case ...
[16:00] <smoser> cjwatson, yeah. thats what i was thinking. i justdidn't know if in general i was missing some obvious thing.
[16:07] <rbasak> nacc: do you have SRU information for bug 1629241 please?
[16:07] <ubottu> bug 1629241 in strongswan (Ubuntu Trusty) "crash strongSwan in Ubuntu Trusty" [High,In progress] https://launchpad.net/bugs/1629241
[16:07] <nacc> rbasak: let me fill it out
[16:08] <smoser> https://gist.github.com/smoser/fa77f61a2b650d115b5fc2a8ab028ede
[16:08] <smoser> nacc, cjwatson that is probalby over-engineered in many ways, but works for me.
[16:08] <smoser> bad thing is that it downloads more than just the dsc and the orig tarball (gets the debian tarball too)
[16:12] <rbasak> nacc, caribou: you have both uploaded an SRU for multipath-tools in Trusty for different bugs. Could you coordinate and consolidate these into one upload, please?
[16:12] <rbasak> So I propose to reject both from the queue unless you object?
[16:13] <caribou> rbasak: I'm fine with it, I'll ping nacc to coordinate
[16:14] <nacc> rbasak: fine with me, sorry about that!
[16:14] <nacc> rbasak: LP: #1629241 updated; however, I'm not sure the test case is sufficient
[16:14] <ubottu> Launchpad bug 1629241 in strongswan (Ubuntu Trusty) "crash strongSwan in Ubuntu Trusty" [High,In progress] https://launchpad.net/bugs/1629241
[16:16] <rbasak> nacc: will you be able to exercise that test case if required? If not, I suggest asking the reporter to commit to doing the SRU verification - otherwise we sometimes end up stuck blocking other SRUs and have to reject it in the end.
[16:16] <rbasak> bdmurray: any opinion?
[16:16] <bdmurray> rbasak: The reporter verified from a PPA so I think they are willing
[16:17] <caribou> nacc: I just pulled your source, want me to merge it with mine (got two patches)
[16:17] <rbasak> caribou, nacc: sounds like you could have fun with the git workflow there :-)
[16:18] <caribou> rbasak: nacc: this is something that came up within our team : how do we handle post-merge uploads to dev
[16:18] <nacc> rbasak: bdmurray: yeah, they already were very prompt in our testing
[16:18] <nacc> *prior testing
[16:18] <rbasak> bdmurray: OK, so shall we accept that one?
[16:18] <nacc> caribou: fine with me, thanks!
[16:18] <caribou> rbasak: nacc: do we keep using the git repo or just debdiffs
[16:19] <nacc> caribou: yeah, that's on my todo list for today (hopefully)
[16:19] <nacc> caribou: using the git workflow for bugfixes
[16:19] <caribou> nacc: ok, will merge both & post the debdiff in a few minutes
[16:20] <nacc> caribou: debdiffs will also still be supported and handled, but if one knows to use the git repo (and hopefully that population grows), then MRs can be used, etc.
[16:24] <caribou> nacc: here is the debdiff : http://paste.ubuntu.com/23324297/
=== blaroche is now known as blaroche_
[16:25] <nacc> caribou: looks good to me!
[16:25] <caribou> nacc: ok, uploading
[16:28] <caribou> rbasak: nacc: ok, merged multipath-tools trusty SRU uploaded
[16:29] <rbasak> Thanks!
[16:29] <nacc> apw: query on the overlay stuff in y -- given that overlayfs is no longer recognized, should there be something that goes into /etc/schroot/chroot.d/ and post-install of an appropriate kernel ensures that it says overlay for each schroot? I guess that could be a sbuild change. Wasn't sure if there was already a bug for this
[16:30] <nacc> apw: i'll re-ask that in #ubuntu-kernel
[16:36] <nacc> smoser: if we import a version and it's a copy-forward from another release, do you want the most recent chagnelog entry to be present still?
[16:36] <rbasak> nacc: could you add SRU paperwork to bug 1628723 please?
[16:36] <ubottu> bug 1628723 in multipath-tools (Ubuntu Trusty) "Trusty: multipathd SIGSEGV on path addition or removal" [High,In progress] https://launchpad.net/bugs/1628723
[16:38] <rbasak> caribou: looks like someone messed with the bug status in bug 1621835, but it should have been Fix Released in the development release if it already has the fix.
[16:38] <ubottu> bug 1621835 in multipath-tools (Ubuntu Trusty) "multipathd reconfigure does not update /etc/multipath/wwids file on trusty" [Medium,In progress] https://launchpad.net/bugs/1621835
[16:40] <nacc> rbasak: done, similar statement regarding testing as the strongswan one (they already tested via PPA)
[16:40] <rbasak> OK, thanks.
[16:42] <smoser> nacc, i guess all the interim, wouldnt you think ?
[16:43] <nacc> smoser: what do you mean by interim? e.g., 1.4.25-2ubuntu1 published in x, then copied to y, what do you think should be in y's importer commit message
[16:45] <nacc> keeping in mind that x's commit message may also be affected by your choice (because it was copied from x-proposed)
[16:48] <smoser> hm..
[16:48] <smoser> i dont know.
[16:52] <nacc> smoser: yeah it's tricky, if we say it's the most recent changelog entry (whcih corresponds to the version in that import), then i have to probably use dpkg-parsechangelog or similar manual munging (btw, i'm basically taking the middle route on that issue, after talking with rbasak, i'll add some manual fallback in the code if dpkg-parsechagnelog fails, so hoepfully we won't need source patches anymore
[16:52] <nacc> (but we'll still keep that support around))
[16:52] <nacc> smoser: if we say it's the diff, it might be empty often
[16:52] <smoser> when would it be empty ?
[16:53] <smoser> only rally on "first copy to branch"
[16:53] <nacc> and every series starts with that :)
[16:53] <nacc> and some series get no updates
[16:53] <nacc> so it depends on 'often'
[16:53] <nacc> i'm fine either way, just trying to match what you expect
[16:54] <nacc> diff is probably easier for me to code, tbh
[17:03] <nacc> smoser: let me generate an example tree and we can use that as the basis for discussion
[17:07] <smoser> nacc, another possibity is to just push this to a tool
[17:07] <smoser> that looks at git log debian/changelog
[17:11] <nacc> smoser: sorry, i'm a bit confused; i thought the point was you wanted to see the corresponding changelog entry in the `git log` ?
[17:13] <smoser> right. i did.
[17:13] <smoser> and i do think that woudl be useful.
[17:14] <smoser> but if you can't figure out the right way to do it, i thin it may be sufficient to say "thats a user problem"
[17:14] <nacc> smoser: ah ok :)
[17:15] <nacc> smoser: i think i can get us something that is useful, and i agree in principe that our current `git log` output is not the most helpful
[17:38] <smoser> so lets say i had a fix for a bug (bug 1629972)
[17:38] <ubottu> bug 1629972 in MAAS "networking stop incorrectly disconnects from (network) root filesystem" [Undecided,Triaged] https://launchpad.net/bugs/1629972
[17:38] <smoser> where would i upload that ?
[17:38] <smoser> shall ijust upload it to yakkety-proposed ?
[17:42] <nacc> smoser: iiuc, based upon prior discussions, you can just upload to ubuntu and it will dtrt?
[17:43] <nacc> smoser: ah but you mean because z isn't open yet?
[17:43] <smoser> right
[17:44] <nacc> good question :)
[17:50] <slangasek> smoser: yes, yakkety-proposed for now.  I guess this is an SRU candidate regardless, right?
[17:53] <smoser> slangasek, yes.
[17:53] <slangasek> then definitely yes :)
[17:55] <nacc> slangasek: process-wise, given that the 'development release' should always have the fix first, how is the devel release defined right now?
[17:55] <nacc> *for an SRU, I mean
[18:04] <nacc> smoser: any idea why the single-quote escape isn't working? http://paste.ubuntu.com/23324761/
[18:07] <smoser> to escape single ticks you need '\''
[18:07] <smoser> but probably best to avoid the shell interpretation
[18:07] <smoser> unless you're just asking about you typing things.
[18:08] <smoser> or if you prefer, "" can do same as \ there: echo 'you can'"'"'t do that.'
[18:09] <nacc> smoser: well, i mean if i do git commit -m '<result of git-diff>' and git-diff contains '
[18:09] <nacc> smoser: it doesn't go so hot :/
[18:10] <smoser> but why are you passing that to the shell
[18:12] <nacc> smoser: sorry, not sure i understnd? we use subprocess.call(shell=True) throughout th eimporter
[18:12] <smoser> yeah, thats wrong.
[18:12] <smoser> almsot always
[18:12] <nacc> smoser: i could switch those around, but i ran into plenty of other issues
[18:13] <smoser> almost always better to not have the shell involved.
[18:16] <nacc> smoser: ok, so not using the shell, i probably need to pass absolute paths to everything?
[18:16] <nacc> smoser: as just switching shell=True off broke just about every subprocess call :)
[18:16] <smoser> yeah, because you invoke with "git log" rather than ["git", "log"]
[18:20] <nacc> smoser: ah ok
[18:20]  * nacc switches over to shlex.split
[18:20] <smoser> nah.
[18:20] <smoser> just drop the shell
[18:20] <smoser> i promise, it will only get in the way.
[18:21] <nacc> dropping the shell requires me to switch everything to []
[18:21] <nacc> which i just did by using shlex.split
[18:21] <nacc> the only ones that still use shell are those using pipes
[18:21] <nacc> i will change those over later
[18:23] <nacc> lol, shlex.split also has an issue with nested '
[18:25] <smoser> nacc, http://paste.ubuntu.com/23324843/
[18:25] <smoser> that handles ithink all but the pipes
[18:25] <smoser> ican fix those too
[18:26] <nacc> smoser: right, that is what shlex.split() is supposed to be doing :)
[18:26] <nacc> let's just say it doesn't work so hot :)
[18:26] <nacc> ok i'll do the same locally
[18:26] <smoser> well, no.
[18:27] <smoser> it is actually doing the righ tthing
[18:27] <smoser> its splitting as the shell would split
[18:27] <smoser> which is why you have bug for bug compatibility
[18:27] <nacc> even if i use shlex.quote first, it bugs out
[18:27] <nacc> it's fine
[18:27] <nacc> i'm changing to your format
[18:45] <slangasek> nacc: we batch-copy packages forward from yakkety-proposed to z-proposed once it opens
=== nacc_ is now known as nacc
=== arlen_ is now known as arlen
=== sinzui_ is now known as sinzui
=== Spads_ is now known as Spads
=== xnox_ is now known as xnox
=== mterry_ is now known as mterry
=== dobey_ is now known as dobey
=== Trevinho_ is now known as Trevinho
=== wolsen_ is now known as wolsen
=== freyes__ is now known as freyes
=== lewq_ is now known as lewq
=== kees_ is now known as kees
=== _fortis_ is now known as _fortis
=== cjwatson_ is now known as cjwatson
=== deltab_ is now known as deltab
[20:49] <smoser> bah
[20:49] <smoser> slangasek, i remember at soem point in the long past making changes to dhclient so that if it failed to get a lease it would die
[20:49] <tsimonq2> smoser: bah
[20:49] <smoser> and exit failure
[20:50] <smoser> but it seems it does nto do that now
[20:51] <smoser> dhclient -v -4 ... echo $?; seems to say 0
[20:51] <smoser> http://paste.ubuntu.com/23325534/
[20:52] <slangasek> smoser: did you forget the -1 option?
[20:52] <slangasek> not according to your pastebin
[20:52] <smoser> no. i typo'd -4 for -1 above
[20:53] <slangasek> ok
[20:53] <smoser> do you remember doing this too ? or did i make it up.
[20:53] <smoser> the man page seems to say it will act like i expect
[20:53] <slangasek> smoser: dhclient was always supposed to work that way on -1, we changed other things to make use of that behavior
[20:54] <slangasek> smoser: so clearly that's misbehaving per manpage; file a bug with deets?
[20:54] <smoser> deets ?
[20:54] <slangasek> details ;)
[20:55] <nacc> heh
[20:56] <smoser> people commonly over-guess on my hipness factor.
[20:56] <smoser> thats either because a.) i just look hip
[20:57] <smoser> b.) i'm more lame than people expect is possible.
[20:57] <slangasek> you've apparently ruled out c) slangasek uses dated slang to keep people guessing if he's retro or just old
[20:59] <nacc> all of the above?
[21:06] <dobey> when people say "deets" it makes me think of https://en.wikipedia.org/wiki/DEET
[21:07] <smoser> https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1633619
[21:07] <ubottu> Launchpad bug 1633619 in isc-dhcp (Ubuntu) "dhclient -1 exits 0 when no lease found" [Undecided,New]
=== kitterma is now known as ScottK
[22:12] <srwarren> Does anyone know how/why/when /etc/default/locale is created when running the Ubuntu installer?
[22:12] <srwarren> Related, if a system is being installed a different way, e.g. by untaring a root file system .tar file supplied by Canonical, what's the suggested way of creating config files like that; just untar another overlay .tar with manually created file content, do something at first-boot, or ?
[22:19] <nacc> smoser: if you're around: https://git.launchpad.net/~nacc/ubuntu/+source/memcached
[22:19] <nacc> smoser: that has changelog entries
=== Anja_ is now known as Anja