ancaemanuel | hloeung: thanks... , permission denied for me. | 00:06 |
---|---|---|
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:13 |
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:14 |
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:15 |
RAOF | Doesn't have to be fixed in Debian (but it's nice to attach a patch to the relevant Debian bug) | 00:16 |
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:17 |
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:18 |
dx | next question: this ticket describes the bug but it's a terrible ticket https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/1479715 | 00:19 |
ubottu | 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:19 |
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:20 |
dx | cool, thanks | 00:21 |
dx | okay i think i'm done https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/1479715 | 01:04 |
ubottu | Launchpad bug 1479715 in pidgin (Ubuntu) "Crash due to fd leak when playing sounds in pidgin" [Undecided,Confirmed] | 01:04 |
pitti | Good morning | 05:03 |
pitti | apw: \o/ http://autopkgtest.ubuntu.com/packages/s/systemd/xenial/i386/ is pass again | 05:03 |
pitti | blake_r: that's quite simple -- nobody actually starts that unit :) | 05:05 |
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:06 |
pitti | blake_r: also, if you create temporary units, please put them into /run/systemd/system/, not /lib | 05:07 |
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:08 |
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:10 |
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 | 05:11 |
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 | 06:17 |
=== cpaelzer_afk is now known as cpaelzer | ||
dholbach | good morning | 07:38 |
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:01 |
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:02 |
* 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:06 |
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 | 09:07 |
cjwatson | pitti: the main point is just to stop arbitrary other packages being uploaded and gaining signatures | 10:10 |
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:12 |
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:26 |
LocutusOfBorg1 | can anybody please retry casablanca/arm64 on xenial? | 10:27 |
cjwatson | LocutusOfBorg1: done | 10:28 |
LocutusOfBorg1 | thanks | 10:29 |
LocutusOfBorg1 | nobody seems processing backports anymore :( | 10:30 |
LocutusOfBorg1 | https://bugs.launchpad.net/wily-backports/+bug/1512982 | 10:30 |
ubottu | Launchpad bug 1512982 in wily-backports "Please backport hedgewars 0.9.22-dfsg-2 (universe) from xenial" [Undecided,New] | 10:30 |
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:50 |
xnox | mardy, or e.g. a branch. where is it staged? | 10:51 |
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:52 |
mardy | xnox: so, if the need arises, I might ping you back in a while | 10:53 |
=== cpaelzer is now known as cpaelzer_afk | ||
=== cpaelzer_afk is now known as cpaelzer | ||
cyphermox | good morning! | 12:51 |
=== davidcalle_ is now known as davidcalle | ||
=== davidcalle__ is now known as davidcalle_ | ||
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:17 |
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:18 |
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:19 |
blake_r | pitti: thanks for the info, we only support trusty to commision with so that will be perfect | 14:20 |
mardy | xnox: ah, that makes it much easier :-) lp:~mardy/libaccounts-glib/s390-tests | 14:22 |
xnox | mardy, fail - https://launchpadlibrarian.net/230340565/buildlog_ubuntu-xenial-s390x.libaccounts-glib_1.19-0ubuntu1_BUILDING.txt.gz | 14:32 |
mardy | xnox: thanks -- I actually just added some debug messages, so failure was expected :-) | 14:35 |
xnox | mardy, what tipe of db is it using? | 14:51 |
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:56 |
xnox | cjwatson, cowboy developer =) | 14:57 |
cjwatson | xnox: hey, it was auto-synced :P | 14:58 |
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:00 |
cjwatson | xnox: *ahem* I ported it to its current implementation, I didn't write it to start with :) | 15:01 |
xnox | cjwatson, ... Keybuk? | 15:02 |
cjwatson | xnox: I doubt it | 15:02 |
cjwatson | It was in LP | 15:02 |
xnox | right. so somebody like lamont or some such then. anyway, history. | 15:03 |
jgdxx | greyback, hey, is mir 0.17 too old to get back something that makes sense from mir_connection_create_display_config ? | 15:13 |
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:14 |
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:15 |
=== jgdxx is now known as jgdx | ||
jgdx | greyback, code http://pastebin.ubuntu.com/14074173/ | 15:17 |
=== caribou_ is now known as caribou | ||
jgdx | i'm only getting adding mode "1280x768x60" | 15:17 |
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:18 |
greyback | jgdx: ah, you've unity8 running. Instead run "MIR_SOCKET=/run/mir_socket mirout" as rooy | 15:20 |
jgdx | greyback, hm, no. I guess I'm doing something wrong. http://pastebin.ubuntu.com/14074211/ | 15:21 |
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:22 |
lamont | xnox: not I | 15:33 |
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 | 15:35 |
=== caribou is now known as caribou_ | ||
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:06 |
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:07 |
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:08 |
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:09 |
cjwatson | let's see if x86 scalingstack likes life better now | 16:11 |
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:12 |
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:13 |
infinity | cjwatson: Gave you a bit more ppc horsepower too (ie: revived doko's latest murder spree victims) | 16:14 |
cjwatson | infinity: ta | 16:15 |
=== cpaelzer is now known as cpaelzer_afk | ||
pitti | ah, autopkgtests are back, and busy with perl :) http://autopkgtest.ubuntu.com/running.shtml | 16:37 |
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:04 |
barry | didrocks: let's see (tho i'm about to break for lunch) | 17:08 |
didrocks | barry: I'm getting something like: http://paste.ubuntu.com/14075536/ | 17:10 |
didrocks | (.coverage is generated as expected) | 17:11 |
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:12 |
=== xnox is now known as xnox_2016 | ||
pitti | cjwatson: ah, your lgw buildds are AWOL too | 17:36 |
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 :) | 17:37 |
=== dpm is now known as dpm-afk | ||
ryao | When is 16.04 Beta 1? | 19:47 |
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.. | 19:48 |
ryao | sarnold: Thanks. | 20:25 |
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:01 |
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:18 |
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:50 |
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:51 |
mwhudson | there's https://launchpad.net/~gophers/+archive/ubuntu/go bug that's really pretty old | 21:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!