[00:06] <ancaemanuel> hloeung: thanks... , permission denied for me.
[00:13] <dx> hi, need some guidance to try to get a bug fixed in wily. the pidgin package has a patch for gstreamer 1.0 support with this bug: https://developer.pidgin.im/ticket/16752
[00:14] <dx> the bug can be summarized as a crash after playing sounds 1000 times (which can be a few hours of receiving messages), so it's quite bad
[00:15] <RAOF> dx: Sounds like a job for a StableReleaseUpdate!
[00:15] <RAOF> https://wiki.ubuntu.com/StableReleaseUpdates being the relevant wiki page.
[00:15] <dx> yup! the problem is that the first step says that i should ensure it's fixed in the testing version
[00:15] <dx> ..does that mean i have to get it fixed in debian, then in ubuntu devel, and then do the SRU?
[00:16] <RAOF> Doesn't have to be fixed in Debian (but it's nice to attach a patch to the relevant Debian bug)
[00:17] <dx> awesome.
[00:17] <RAOF> You should attach a fix for both the xenial and wily packages to the bug report, though.
[00:17] <RAOF> (Assuming you need sponsorship. If you don't need sponsorship, upload a fixed package to xenial and then wily-proposed ☺)
[00:18] <dx> yeah i need sponsorship. the fix would be https://bitbucket.org/pidgin/main/commits/902b1fd334bd4d41ffd217fa4e6864629b7d3edc/raw/
[00:18] <dx> i'll just ignore debian because pidgin 2.10.12 is going to be released very soon, which also includes the fix.
[00:19] <dx> next question: this ticket describes the bug but it's a terrible ticket https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/1479715
[00:20] <dx> do i create a new one or can i just edit that?
[00:20] <RAOF> Edit that one.
[00:20] <sarnold> try hitting the little yellow icon on the same horizontal level as 'bug description'
[00:20] <RAOF> It's the one that's associated with the error bucket!
[00:21] <dx> cool, thanks
[01:04] <dx> okay i think i'm done https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/1479715
[05:03] <pitti> Good morning
[05:03] <pitti> apw: \o/ http://autopkgtest.ubuntu.com/packages/s/systemd/xenial/i386/ is pass again
[05:05] <pitti> blake_r: that's quite simple -- nobody actually starts that unit :)
[05:06] <pitti> blake_r: it's actually a lot simpler than that; just put this "runcmd:" as the last thing in your cloud-init user-data:
[05:06] <pitti> - (while [ ! -e /var/lib/cloud/instance/boot-finished ]; do sleep 1; done; shutdown -P now) &
[05:06] <pitti> blake_r: this avoids all that indirection, does not depend on any particular init, and is much simpler
[05:07] <pitti> blake_r: also, if you create temporary units, please put them into /run/systemd/system/, not /lib
[05:08] <pitti> blake_r: merely creating a unit does not cause it to start -- something (a dependency from another unit) or someone (calling systemctl start) needs to do that
[05:10] <pitti> blake_r: oh sorry, this isn't just cloud-init, it's maas
[05:10] <pitti> blake_r: so, turn that dependency around -- drop the Wants=cloud-final.service and instead add [Install]\nWantedBy=cloud-final.service, then systemctl enable maas-poweroff.service
[05:11] <pitti> blake_r: then maas-final.service will start maas-poweroff.service
[05:11] <pitti> blake_r: but still, please put this into /run; it's dangerous to write it to /lib, you might forget to delete it after installation
[06:17] <pitti> utlemming: can you please build a ppc64el xenial cloud image?
[06:17] <pitti> stgraber: ^ reason for lxc/ppc64el regression, in case you wonder; I'll override
[07:38] <dholbach> good morning
[09:01] <pitti> infinity, cjwatson: do you know why this linux/amd64 upload got stuck in unapproved? (https://launchpad.net/ubuntu/xenial/+queue?queue_state=1)
[09:02] <pitti> I suppose we have a special-case for kernels with signed EFI bits, to manually verify the upload
[09:02] <pitti> but what am I supposed to verify for that?
[09:02] <pitti> LP stripped off the gpg signature of the .changes file, so I can't verify that it was actually uploaded by Tim
[09:06]  * apw believes it is the linux_4.3.0-5.16_amd64.tar.gz that is to be verified, that it only contains expected flavour .efi files, and that the kernel itself comes from a trusted source
[09:06] <pitti> but I have no way to see which source it came from
[09:07] <pitti> if it had rtg's gpg sig on the .changes, I could verify based on that I trust Tim
[09:07] <pitti> but so far I just know that it was uploaded by a core-dev or someone with linux package upload rights
[10:10] <cjwatson> pitti: the main point is just to stop arbitrary other packages being uploaded and gaining signatures
[10:12] <pitti> cjwatson: ah, ok; so I know that the source (https://launchpad.net/ubuntu/+source/linux/4.3.0-5.16) was uploaded by Tim (assuming that this is the signature, not the Changed-By:), and that it's linux where we expect new signatures
[10:26] <mardy> xnox: hi! I'd like to test a branch of libaccounts-glib on s390x; what would be the best way to do that?
[10:26] <mardy> xnox: I could ask for a silo, but is it possible to limit the builds to one arch only?
[10:27] <LocutusOfBorg1> can anybody please retry casablanca/arm64 on xenial?
[10:28] <cjwatson> LocutusOfBorg1: done
[10:29] <LocutusOfBorg1> thanks
[10:30] <LocutusOfBorg1> nobody seems processing backports anymore :(
[10:30] <LocutusOfBorg1> https://bugs.launchpad.net/wily-backports/+bug/1512982
[10:50] <xnox> mardy, you can give me a *.dsc and i can build it for you. Or build it in a silo, as you normally would - it has s390x enabled.
[10:51] <xnox> mardy, or e.g. a branch. where is it staged?
[10:52] <mardy> xnox: excellent; now I've added a commit to the existing silo, but if I will want to build some really experimental branches, I'll ping you then :-)
[10:52] <mardy> xnox: upstream is in gitlab.com, but we have bzr branches with debian packaging in lp
[10:53] <mardy> xnox: so, if the need arises, I might ping you back in a while
[12:51] <cyphermox> good morning!
[14:17] <blake_r> pitti: thanks for the info I gave that a try still didnt work, but I am going to just have cloud-init poweroff the machine which I believe is the more correct way anyway
[14:17] <pitti> blake_r: right, and much simpler too, if you don't have to do anythign after cloud-init
[14:18] <pitti> blake_r: more modern cloud-inits even have that feature builtin, but not yet in older releases (thus I'm not yet using it in autopkgtest)
[14:18] <blake_r> pitti: yeah I am going to use "power_state" in cloud-init
[14:18] <pitti> blake_r: http://cloudinit.readthedocs.org/en/latest/topics/examples.html#reboot-poweroff-when-finished right, that's what I meant
[14:19] <mardy> xnox: ok, I've got something I'd like to you to build on s390x, but I don't know how to generate the .dsc file: debuild complains that it cannot find the upstream tarball
[14:19] <xnox> mardy, i can work with branches too...
[14:19] <cjwatson> Download it from the Ubuntu archive and put it in your parent directory
[14:19] <pitti> blake_r: I just checked, power_state does exist in trusty now, but not yet in precise
[14:20] <blake_r> pitti: thanks for the info, we only support trusty to commision with so that will be perfect
[14:22] <mardy> xnox: ah, that makes it much easier :-) lp:~mardy/libaccounts-glib/s390-tests
[14:32] <xnox> mardy, fail - https://launchpadlibrarian.net/230340565/buildlog_ubuntu-xenial-s390x.libaccounts-glib_1.19-0ubuntu1_BUILDING.txt.gz
[14:35] <mardy> xnox: thanks -- I actually just added some debug messages, so failure was expected :-)
[14:51] <xnox> mardy, what tipe of db is it using?
[14:56] <doko> perl transition has arrived ... texinfo uninstallable
[14:56]  * xnox ponders if we should have used a silo for perl transition
[14:56] <cjwatson> doko: I've uploaded the key rebuilds
[14:56] <cjwatson> doko: working on it anyway
[14:56] <cjwatson> xnox: maybe, but too late now :)
[14:57] <xnox> cjwatson, cowboy developer =)
[14:58] <cjwatson> xnox: hey, it was auto-synced :P
[15:00] <xnox> .....
[15:00]  * xnox ponders if i should or should not point out who implemented autosync...
[15:00] <xnox> >_<
[15:00] <xnox> =)))))
[15:00] <pitti> good that we don't all run away into holidays in two days
[15:01] <cjwatson> xnox: *ahem* I ported it to its current implementation, I didn't write it to start with :)
[15:02] <xnox> cjwatson, ... Keybuk?
[15:02] <cjwatson> xnox: I doubt it
[15:02] <cjwatson> It was in LP
[15:03] <xnox> right. so somebody like lamont or some such then. anyway, history.
[15:13] <jgdxx> greyback, hey, is mir 0.17 too old to get back something that makes sense from mir_connection_create_display_config ?
[15:14] <greyback> jgdxx: no, that should work today
[15:14] <jgdxx> on the device, I'm getting two outputs, one lvds and one displayport (on mako), but only one of them have modes (lvds)
[15:15] <jgdxx> and the only lvds mode is 1280x768x60
[15:15] <greyback> jgdxx: this with mir-on-x?
[15:15] <jgdxx> greyback, on the device, so no x
[15:17] <jgdx> greyback, code http://pastebin.ubuntu.com/14074173/
[15:17] <jgdx> i'm only getting adding mode "1280x768x60"
[15:18] <greyback> jgdx: if you run "mirout" does it match what you're seeing?
[15:18] <jgdx> greyback, getting "Could not connect to a display server: Failed to connect: not accepted by server"
[15:20] <greyback> jgdx: ah, you've unity8 running. Instead run "MIR_SOCKET=/run/mir_socket mirout" as rooy
[15:21] <jgdx> greyback, hm, no. I guess I'm doing something wrong. http://pastebin.ubuntu.com/14074211/
[15:22] <jgdx> well no, that's an exact match
[15:22] <jgdx> hm
[15:22] <jgdx> it only supports that mode :P
[15:22] <jgdx> greyback, thanks!
[15:22] <greyback> jgdx: yep. lvds not flexible
[15:33] <lamont> xnox: not I
[15:35] <cjwatson> xnox: LP's original sync-source.py was ported from the Ubuntu dak instance by James; I believe James wrote the original dak version
[16:06] <infinity> cjwatson: Thanks for handling the perl transition.  I just noticed it had started and panicked that I was going to have to burn my first vacation day fixing it. :P
[16:06] <infinity> cjwatson: Do you need any help with that, or are you carrying state in your head and muscle memory?
[16:06] <cjwatson> infinity: I'll want to hand off at some point, but I'm good for now
[16:06] <infinity> cjwatson: Kay.  Using a tracker, I assume?
[16:07] <cjwatson> infinity: It'll be impeded by the PS4.5 outage anyway, since that's taken out x86 scalingstack
[16:07] <cjwatson> infinity: http://people.canonical.com/~ubuntu-archive/transitions/html/perl5.22.html
[16:07] <infinity> cjwatson: If so, just aim me at it when you're tired.
[16:07] <teward> blurgh... anyone know if it's possible to get a temporary PGP key and SSH key accepted for uploads to the repositories?  (Gotta ask since my main system with my keys and such is down for repairs, for a few days)
[16:07] <cjwatson> infinity: I'm doing lib*-perl from levels 1 and 2
[16:07] <pitti> FTR, autopkgtest workers are all down (PS4.5 too), so tehre won't be progress on that front anytime soon
[16:07] <infinity> cjwatson: Oh, joy.  (re: scalingstack)
[16:07] <cjwatson> teward: as long as you can get at your Launchpad account, you can add new PGP/SSH keys there
[16:08] <cjwatson> teward: if you can't do that, then no
[16:08] <teward> cjwatson, and that's  instantly accepted at upload.u.c?
[16:08] <cjwatson> teward: yes
[16:08] <pitti> but no SSO to add them, I figure :)
[16:08] <teward> cjwatson, thankfully I logged into launchpad *before* SSO took a crap
[16:08] <cjwatson> teward: upload.u.c authenticates against Launchpad
[16:08] <mardy> xnox: it's using sqlite
[16:08] <cjwatson> pitti: SSO was working last I checked
[16:08] <teward> pitti, i'm actually logged in now xD
[16:08] <cjwatson> but maybe flapping
[16:08] <teward> cjwatson, SSO broken on wiki.u.c as of 5 minutes ago
[16:08] <pitti> teward: I'm fairly sure that adding keys will ask you again, but good luck!
[16:08] <xnox> mardy, ack.
[16:08] <cjwatson> right, probably flapping with the PS4.5 outage
[16:08] <teward> i was already logged in on LP this morning around 6AM
[16:08] <cjwatson> and indeed, changing at least some keys (PGP, IIRC) will require reuath
[16:08] <cjwatson> *reauth
[16:08] <teward> pitti, indeed.  first, gotta spin up a temporary VM environment for stuff, being stuck on WINDOWS makes me cringe
[16:09] <teward> (fortunately i keep copies of ISOs, on a private ISO storage disk xD)
[16:09] <cjwatson> things are supposedly coming back up though
[16:09] <cjwatson> login.u.c is responding from here
[16:11] <cjwatson> let's see if x86 scalingstack likes life better now
[16:12] <teward> cjwatson, login.u.c was working for me fine, but the authentication from that -> wiki was timed out for me (10min+)
[16:12] <teward> finally got in just a few seconds ago
[16:12] <cjwatson> ah, well if login.u.c was working then that's not an SSO issue now is it?
[16:13] <cjwatson> I expect the wiki's in prodstack so would have been independently having network trouble
[16:13] <infinity> The wiki SSO bits seems to be rathe more problematic than most.
[16:13] <infinity> (always, not just today)
[16:13] <cjwatson> anyway, I hear things are returning
[16:13] <teward> infinity, true, though it worked fine until this morning :)
[16:13] <teward> cjwatson, thanks :)
[16:14] <infinity> cjwatson: Gave you a bit more ppc horsepower too (ie: revived doko's latest murder spree victims)
[16:15] <cjwatson> infinity: ta
[16:37] <pitti> ah, autopkgtests are back, and busy with perl :) http://autopkgtest.ubuntu.com/running.shtml
[17:04] <didrocks> barry: hey, do you have time for a stacktrace in python3-coverage? (I'm getting a stacktrace everything I'm enabling --cov-report=html)
[17:08] <barry> didrocks: let's see (tho i'm about to break for lunch)
[17:10] <didrocks> barry: I'm getting something like: http://paste.ubuntu.com/14075536/
[17:11] <didrocks> (.coverage is generated as expected)
[17:12] <barry> ran out of input!  that's a new one on me :)
[17:12] <didrocks> barry: if I replace --cov-report=html by xml, it generates the xml as expected
[17:12] <didrocks> yeah, sounds weird ;)
[17:36] <pitti> cjwatson: ah, your lgw buildds are AWOL too
[17:37] <cjwatson> pitti: Yeah, I know
[17:37] <pitti> so that's not just me
[17:37] <cjwatson> It's all dead
[17:37] <cjwatson> mabolo is apparently very very sad
[17:37] <pitti> one day before holidays, big perl 5.22, clouds dead -- what a perfect timing :)
[19:47] <ryao> When is 16.04 Beta 1?
[19:48] <ryao> Nevermind... I found it by googling slightly differently.
[19:48] <sarnold> hey ryao :) https://wiki.ubuntu.com/XenialXerus/ReleaseSchedule note that feature freeze is before that..
[20:25] <ryao> sarnold: Thanks.
[21:01] <mwhudson> i'd like to make a semi official ppa (or two) for golang testing
[21:01] <mwhudson> would it make sense for them to be on the ~ubuntu-toolchain-r team or would a new team be better?
[21:18] <slangasek> mwhudson: well, you'd have to be part of the ~ubuntu-toolchain-r team for that to be useful to you, I guess?  In which case you need to get doko to add you :)
[21:18] <mwhudson> slangasek: yeah, i guess this is a question for doko really
[21:18] <slangasek> it seems reasonable to me, but also not required since you can also easily get another team set up with a devirt ppa for all-arch building
[21:50] <xnox_2016> mwhudson, after all these years doko never added me to ~ubuntu-toolchain-r i would not hold my breath. setting up new team and/or ppa should be fine. I thought there already was devirt ppa for go.... i recall somebody was building golang like on every upstream commit in devirt ppas.
[21:50] <mwhudson> yeah ok new team seems sane then
[21:51] <mwhudson> xnox_2016: gustavo was doing that sort of thing for a while i think, but not recentaly afaik
[21:51] <xnox_2016> mwhudson, maybe you can take over those ppas.
[21:54] <mwhudson> there's https://launchpad.net/~gophers/+archive/ubuntu/go bug that's really pretty old