[00:14] <nacc> jgrimm: check now?
[00:14] <nacc> jgrimm: on nspr
[01:02] <nacc> infinity: fwiw, i think i figured out the horde-crypt failure. It's actually testing things correctly (using the gpg binary and setting up its own test-internal gpg keys). But it's using deprecated/ignored options to gpg :)
[01:19] <mwhudson> slangasek: oh i didn't realize powerpc was going away quite that much
[01:20] <nacc> wtf gpg
[01:20] <nacc> infinity: have to set GPG_TTY=$(tty) and pass '--pinentry-mode loopback' and the tests seem to work
[01:22] <jgrimm> nacc, worked, thanks!
[01:25] <nacc> jgrimm: great, sorry about that
[01:29] <jgrimm> no worries at all!
[01:52] <nacc> infinity: figured out most of them! gpg changed the output and the tests were parsing it, as well..
[02:05] <tsimonq2> Ok, deciding to pick up bug 1516454 again.
[02:05] <tsimonq2> So I'm curious if anything stands out to anybody, I trid the obvious solution of editing the GTK property as I believe it was missing something?
[03:00] <Umeaboy> Hi!
[03:00] <Umeaboy> Who's the maintainer of the mkvtoolnix package in Ubuntu 16.10?
[03:01] <Umeaboy> Hmmmmmmmmmm. I think I better take this in #ubuntu-app-devel.
[03:02] <sarnold> isn't that channel for the phones?
[03:03] <sarnold> given the long list of debian version numbers here https://launchpad.net/ubuntu/+source/mkvtoolnix/+publishinghistory I suspect there's no one at ubuntu that 'tends' to this package -- it mostly appears to be pulled in from debian unchanged, until toolchain issues cause rebuilds
[03:04] <Umeaboy> It has only been pushed to the development release of Ubuntu.
[03:05] <Umeaboy> Seems odd since 9.6.0 is a stable release and not a development release.
[03:05] <Umeaboy> That's my idea of stable anyhow.
[03:42] <mwhudson> stgraber, slangasek: i finally filed https://bugs.launchpad.net/snappy/+bug/1651936
[03:47] <sarnold> are all the failures coming from expect, and are they all password-related?
[03:48] <sarnold> oh I guess not, there's also this:
[03:48] <sarnold> mesg: ttyname failed: Inappropriate ioctl for device
[03:48] <sarnold> but I suspect that's the usual glibc-vs-kernel disagreement about tty devices in filesystem namespaces
[03:49] <sarnold> also tests/main/chattr -- that's an odd one
[05:13] <slangasek> mwhudson: yup
[06:57] <mwhudson> sarnold: ah hah, go would be particularly susceptible to that
[08:47] <fossfreedom> sil2100: thanks - got an autoemail from launchpad to say you have "fix released" our merge request for lp:ubuntu-cdimage
[08:52] <sil2100> fossfreedom: np, did you get my yesterday's message about the image builds failing?
[08:53] <fossfreedom> sil2100: hmm - have looked.  nothing :(
[08:54] <sil2100> http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-budgie/zesty/
[08:54] <sil2100> We might be missing some enabling of this project on livefs builders
[08:55] <sil2100> cjwatson: hello! Are you still around today by any chance?
[08:57] <sil2100> fossfreedom: might be a bit hard to get things done, a lot of people are on holidays already
[08:58] <fossfreedom> sil2100: ah - yes. with xmas on the weekend ... good excuse to have a very long break!
[10:54] <cjwatson> sil2100: what do you need?
[10:57] <sil2100> cjwatson: hello! We have enabled a new ubuntu flavor in cdimage, ubuntu-budgie - it seems the builds are failing since there's still something missing in the builders to enable that? http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-budgie/zesty/daily-live-20161221.log
[10:57] <cjwatson> sil2100: do you know about the production config branch on nusakan?
[10:58] <sil2100> cjwatson: I see it but never 'used' it before I think
[10:58] <cjwatson> sil2100: that's what you need to edit :)
[10:58] <sil2100> Ah :)
[10:58] <cjwatson> sil2100: did anyone create the livefs objects in LP?
[10:58] <sil2100> cjwatson: I don't think so...
[10:59] <sil2100> cjwatson: is this also something I can do, or does require some special powers?
[10:59] <cjwatson> You should be able to; let me just look it up
[11:00] <cjwatson> lp-shell production devel -> lp.livefses.new(owner='/~ubuntu-cdimage', distro_series='/ubuntu/zesty', name='ubuntu-budgie')
[11:00] <cjwatson> doesn't need any special powers since you're just trying to build it for amd64 and i386, so no devirtualisation needed
[11:01] <sil2100> cjwatson: ok, let me try running this then, thanks :)
[11:01] <cjwatson> then add it to livefs-launchpad in the production config branch
[11:01] <sil2100> And I'll edit the production config then
[11:01] <sil2100> Thanks for the pointers!
[11:01] <cjwatson> and make sure to pull that onto nusakan of course
[14:44] <ginggs> matplotlib, python-stdlib-extensions and pandas show test regressions in lmfit-py on armhf - where lmfit-py is not installable since python-pandas removal. What needs to be done to let them migrate?
[15:45] <jabowery> A July Debian bugfix has not made it into xenial updates.  The advice at the launchpad unassigned bug tracking comments is: A thing the maintainer perhaps could do would be to create a launchpad mirror of the sourceforge repo maxima's code is kept in - and then to initiate a nightly build ppa for maxima.  https://bugs.launchpad.net/ubuntu/+source/maxima/+bug/1602941/comments/8
[15:45] <jabowery> How does one go about identifying or becoming that "maintainer"?
[15:47] <tumbleweed> ubuntu packages usually don't have maintainers, as such
[15:47] <tumbleweed> I'd SRU that patch into xenial
[15:48] <jabowery> What does SRU stand for?
[15:48] <tumbleweed> !sru
[15:48] <tumbleweed> can you find the patch that fixes the bug?
[15:51] <dobey> it looks like 5.37.2-9 could be synced from debian to xenial-updates (and maybe yakkety-updates), as -8 is what's in ubuntu
[15:52] <dobey>    * Bug fix: "maxima do not load the draw package.", thanks to Renato
[15:52] <dobey>      Alvarez Nodarse (Closes: #803251).  rework sys:*load-pathname* patch
[15:52] <tumbleweed> it's a different -8
[15:52] <dobey> ?
[15:53] <tumbleweed> I mean, yakkety is already fixed
[15:53] <cjwatson> maxima/xenial == maxima/yakkety
[15:53] <tumbleweed> I've never heard of syncing into a stable -updates
[15:53] <cjwatson> *zesty* has a different -8
[15:53] <dobey> right
[15:53] <tumbleweed> oh, yes, that's what I was thinking
[15:53] <dobey> yakkety and xenial have the same package
[15:54] <cjwatson> it's certainly *possible* to copy into a stable -proposed and have it verified, but it wouldn't suit the tools very well because it wouldn't refer to a Launchpad bug
[15:54] <cjwatson> so verification wouldn't work right
[15:54] <cjwatson> better to just cherry-pick into 5.37.2-8ubuntu1, even if that ends up essentially identical to 5.37.2-9
[15:55]  * tumbleweed has a poke at it
[16:57] <jabowery> So I take it I should pursue a different procedure than submitting an SRU on the debian fix to maxima?
[16:58] <nacc> jabowery: SRU is not a debian thing
[16:58] <nacc> jabowery: SRU is an ubuntu thing :)
[16:58] <nacc> jabowery: oh i see what you were saying -- the right approach is to SRU the debian change to ubuntu's packages where relevant, but I think tumbleweed may be doing it
[16:58] <jabowery> Great!
[17:00] <tumbleweed> I did it. jabowery will you test it once it's published?
[17:00] <tumbleweed> subscribe to the bug now, if you haven't
[17:01] <jabowery> Sure I'll test it.  I'm subscribed to https://bugs.launchpad.net/ubuntu/+source/maxima/+bug/1602941
[17:03] <jabowery> I presume that means I'll receive an email notifying me it has been published.  I've just received an email saying "** Changed in: maxima (Ubuntu)        Status: Confirmed => Fix Released  ** Also affects: maxima (Ubuntu Yakkety)    Importance: Undecided        Status: New", but that's not a notice that it's been published, right?
[17:04] <tumbleweed> jabowery: you will
[17:10] <nacc> infinity: mdeslaur: after some wrangling, debian maintainer has bumped the abi for imagemagick :)
[17:26] <smoser> hey, i'm using apt.Cache() from python apt package.
[17:27] <smoser> im' using it on zesty, and want to be able to apt.Cache(rootdir=foo)
[17:27] <smoser> cache.update()  is failing
[17:27] <smoser> due to i think no keyrings
[17:27] <smoser> to read xenial data
[17:28] <smoser> http://paste.ubuntu.com/23669428/
[17:28] <smoser> what is the right way to tell it that i want it to use the old keyrings ?
[17:33] <nacc> smoser: add_key_from_keyserver? (just paging through the files/APIs)
[17:34] <smoser> whered you see that ?
[17:34] <nacc> smoser: it's in apt/auth.py
[17:34] <smoser> i dont think iw ant to add from a keyserver, but i do wan tot add a key
[17:34] <nacc> you can also add from a file, i think
[17:34] <nacc> add_key_from_file
[17:35] <nacc> or even just add_key :)
[17:46] <smoser> nacc, hm... no dice.
[17:46] <smoser> all that does is run apt-key
[17:47] <nacc> smoser: rbasak: i think this might have been a thinko on my part in the remote addition for `usd clone`: http://paste.ubuntu.com/23669494/; right now, the remote branches in `git branch` do not show up as remote, because they are all fetched into refs/heads (which is the local branches). Thoughts?
[17:47] <nacc> smoser: oh, hrm
[18:32] <sil2100> fossfreedom: ok, with all the builder bits enabled, looks like the images are still failing - I suppose it might be something missing in livecd-rootfs?
[18:33] <sil2100> fossfreedom: from what I see you didn't submit any changes for ubuntu-budgie there? I suppose that should be needed? You mentioned the builds succeeded locally on your build environment though
[18:39] <fossfreedom> sil2100: to be honest - I didnt know there was yet another project to make changes to :(
[18:41] <fossfreedom> sil2100: this project? https://launchpad.net/livecd-rootfs
[18:42] <fossfreedom> looking at the code ... not sure where to make changes.
[18:44] <fossfreedom> maybe this?  - looks to have some flavor specifics http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/view/head:/live-build/auto/config
[19:07] <fossfreedom> sil2100: ok - have created a branch with changes that are very similar to ubuntu-gnome's - https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1652144
[19:24] <sil2100> fossfreedom: ok, let me try taking a look at them but it's a bit lateish here
[19:36] <sil2100> fossfreedom: ok, quick thing - could you switch the changelog entry from 'zesty' to UNRELEASED?
[19:36] <sil2100> We only put series names once the package is released
[19:37] <fossfreedom> yep - doing it now
[19:41] <sil2100> Thanks
[19:41] <sil2100> Ok, I'll try to release this, but then I'm going off ;)
[19:42] <sil2100> fossfreedom: push the change to the branch, I'll merge it, prepare for release and run a test build
[19:43] <fossfreedom> sil2100: ok - thanks - pushed
[19:49] <sil2100> fossfreedom: ok, new livecd-rootfs building
[19:50] <fossfreedom> sil2100: much appreciated!  Have a good night! ... and if you are off for xmas - have a great hols.
[19:50] <sil2100> fossfreedom: thanks for the quick response btw, we might get this building before my EOY ;)
[20:50] <sil2100> fossfreedom: same to you!
[20:50] <sil2100> fossfreedom: I go off now, the package still didn't migrate from -proposed so I can't run the job
[20:50] <sil2100> But when I see it migrated later today I'll just kick a quick build - if not, tomorrow's daily build should catch any possible issues
[20:50] <sil2100> o/
[21:35] <jgrimm> nacc, http://paste.ubuntu.com/23670285/
[21:51] <jgrimm> nacc, ah.. %% will get me what I want.
[22:14] <nacc> jgrimm: ah yes, but even that is incorrect
[22:14] <nacc> err, no, you're right
[22:14] <nacc> it should be fine, sorry!
[22:14] <nacc> jgrimm: can you file a bug on that (or put a comment in the one already filed for logical tag issues)
[22:14] <jgrimm> yeah, %% should escape the % that you've used to represent : for
[22:15] <jgrimm> nacc, yeah, you could probably push out a warning for that at least
[22:15] <jgrimm> will do
[22:16] <nacc> jgrimm: yep, we can do a quick sub in the string to escape certain characters (I think % is the only one we'd need to, actually)
[22:16] <jgrimm> yeah, i had guessed that from the bug you had against logical tag
[23:19] <nacc> infinity: in case you care, and i hope you don't, i think php-horde-crypt's failures are all related to the gpg2 migration: http://paste.ubuntu.com/23670714/. Going to try sending htat upstream as well
[23:40] <nacc> infinity: and nm, i found a even smaller patch for upstream, which doesn't rquire the killall ugliness