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