[00:01] <infinity> sarnold: Waiting for this test build to finish, but looks like it's a 1-line patch for you, and you can just include that in your security release.
[00:03] <sarnold> infinity: yay \o/ :) thanks
[00:22] <infinity> sarnold: http://paste.ubuntu.com/6298101/ <-- Test-built, seems to DTRT.
[00:24] <sarnold> infinity: thanks!
[02:22] <ScottK> xnox: Feel free to ask me if I'm willing to look at a bug, but assignment rights require a contract.
[02:22] <ScottK> stgraber: Would you please have a look at the upstartification proposed in https://bugs.launchpad.net/ubuntu/+source/quassel/+bug/1244036 ?
[02:27] <stgraber> ScottK: looks to me like he wants "start on filesystem and static-network-up" instead, but the start on condition he's using isn' wrong either. Just because I'm picky, the respawn stanza is usually put before the script section so it's easier to spot.
[02:28] <stgraber> besides that, it should all work fine assuming quasselcore doesn't fork/daemonize
[02:28] <stgraber> oh and hardcoding /usr/bin is usually not considered a good thing
[02:29] <ScottK> So just excec quasselcore?
[02:29] <ScottK> exec even
[02:29] <ScottK> stgraber: ^^^
[02:30] <stgraber> yep
[02:30] <ScottK> Thanks.
[03:55] <Mirv> slangasek: yes phablet-test-run works through adb
[04:04] <pitti> rbasak: thanks (this early> rolling release!! *cough*)
[04:04] <pitti> Good morning
[04:05] <Mirv> robru: xnox: I didn't really push on getting the qtmultimedia in. as I was asked I provided some information and prepared the branch from my side, assuming someone working on the bug is doing the pushes. otherwise I'd have pinged a friendly core-dev about the branch or made the lp:ubuntu/* MP. doing that MP now as robru requested.
[04:05] <robru> Mirv, yes, sorry. I don't have upload rights so I can't sponsor it or anything. but I really need that in ASAP please.
[04:06] <robru> for trusty
[04:06] <Mirv> yep the MP seems the best way to go, and I can ping also didrocks who can sponsor from the packaging branch directly
[04:06] <robru> ok, great, thanks Mirv
[04:06] <pitti> rbasak: so, we are producing cloud images, just no /current symlink
[04:06] <Mirv> np
[04:07] <pitti> rbasak: but "prepare-testbed -b 20131024.3 amd64" FTW :)
[06:11] <mati75> hello
[06:11] <mati75> I have question about upload patched packages to ubuntu repository
[07:20] <pitti> mati75: (just ask your question)
[07:20] <ricotz> doko__, hi, graphviz 2.34.0-0ubuntu4 missed to handle the soname bump "libgvc5: /usr/lib/libgvc.so.6"
[07:21] <ricotz> pitti, hi
[07:21] <pitti> hey ricotz
[07:22] <ricotz> i am curious aren't there checks for the proposed pocket to catch something like that ^
[07:23] <slangasek> normally, it's expected that such changes cause the package to fail to build entirely.
[07:24] <ricotz> if there is no symbols file it wont fail
[07:24] <slangasek> not true; if the library package is done sanely, it will fail to build when it tries to install files that aren't there
[07:25] <ricotz> slangasek, right, but normally the soname isnt mentioned in the install file afaik
[07:25] <ricotz> but yeah, that of course would catch it
[07:26] <slangasek> if you have neither a symbols file nor a version-checking glob in your install rule, your library packaging is not sane
[07:26] <ricotz> alright ;)
[07:31] <mati75> my debian package was copied to ubuntu trusty, but to fine working in ubuntu needs patch
[07:33] <mati75> now I add to ppa: https://launchpadlibrarian.net/154951693/spacefm_0.9.0-1ubuntu1_source.changes
[07:34] <pitti> mati75: ah, thanks! happy to sponsor, do you have the link to the PPA?
[07:36] <mati75> https://launchpad.net/~mati75/+archive/spacefm/+packages
[07:37] <pitti> mati75: oh, what doesn't work with the global menu? (woudl be nice to report this as a bug to the unity guys so that it can be fixed)
[07:40] <mati75> pitti: yes, here is upsteam bug report: https://github.com/IgnorantGuru/spacefm/issues/49
[07:40] <mati75> pitti: ok, I try report to unity guys
[07:41] <pitti> mati75: ah; probably not an upstream bug, but one in the unity menu; I'll add that link to the changelog, ok?
[07:43] <pitti> mati75: uploaded with that
[08:24] <mati75> pitti: ok
[08:59] <borg_> Hi, i still have this problem with python-qwt5-qt4: https://bugs.launchpad.net/ubuntu/+source/pyqwt5/+bug/1243102
[09:00] <borg_> it was assigned to Scott Kittermann but he unasigned it
[09:00] <borg_> how do i get this package rebuild and reuploaded?
[09:00] <borg_> the source of the package is ok, but the build package is broken (no idea what happend during the build process)
[09:29] <doko> apw, aarch64 ping
[09:40] <doko> chrisccoulson, hi, could you have a look at a libticaples merge this cycle?
[09:57] <doko> ricotz, feel free to fix. the graphviz packaging is "interesting" ....
[10:06] <xnox> =)
[10:18] <pitti> I guess it's too late to hold back graphviz in -proposed for that..
[10:19] <cjwatson> given it's migrated, yes
[10:34] <brainwash> can a package maintainer or dev take a look at bug 1183580 please? the actual package maintainer appears to be inactive or just ignores this issue
[14:16] <darkxst> cjwatson, I hear from upstream, that jenkins in running the glib installed tests, can we get the same for gjs?
[14:17] <cjwatson> darkxst: that's up to the gjs packaging I expect
[14:17] <Laney> It does that because I packaged the tests and made an autopkgtest for them
[14:17] <Laney> so do that
[14:18] <darkxst> Laney, ok will do, but how do I make an autopkgtest?
[14:18] <cjwatson> http://anonscm.debian.org/gitweb/?p=autopkgtest/autopkgtest.git;a=blob_plain;f=doc/README.package-tests;hb=HEAD
[14:19] <Laney> You can probably copy debian/tests/* from glib2.0
[14:19] <cjwatson> (linked from http://dep.debian.net/deps/dep8/)
[14:22] <darkxst> Laney, cjwatson ok cool, I will work it out ;)
[14:26] <Laney> darkxst: I think there's a bug that gnome-desktop-testing-runner always returns exit code 0 though
[14:27] <Laney> so the tests actually always pass *cough*
[14:27] <Laney> for example https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-glib-networking/9/ARCH=amd64,label=adt/console should have failed
[14:27] <darkxst> Laney, then thats not a test !
[14:27] <Laney> yeah the runner needs fixing
[14:30] <darkxst> Laney, ok, and I need sleep! big weekend of MTB'ing ahead
[14:34] <Laney> darkxst: maybe fixed in trunk actually, /me checks that
[14:34] <Laney> have fun mtbing
[14:35] <Laney> no, not fixed
[14:38] <darkxst> will do! night!
[14:39] <seb128> ev, is errors.ubuntu.com having issues? it doesn't seem to be replying, not sure if that's my connection
[14:39] <seb128> well it's replying but failing to load reports
[15:13] <pitti> seb128: timing out here, too, I don't even see the front page
[15:14] <seb128> pitti, I've pinged #is about it, lamont said he's going to have a look
[15:14] <seb128> pitti, hey, wie gehts? almost w.e for you?
[15:14] <lamont> believed to be a known issue
[15:15] <pitti> seb128: by and large, yes; just waiting for another ofono-phonesim fix to get published, and then re-re-re-running my messaging-app tests and hoping for the best :)
[15:15] <seb128> pitti, ;-)
[15:19] <pitti> slangasek: WDYT about a blueprint how to automatically do TRIMming on SSDs? high time for 14.04 LTS IMHO, and also quite embarrassing to have to explain that to every Ubuntu user around me..
[15:19] <pitti> slangasek: (there are two well-known approaches, just needs some discussion what is the better default)
[15:24] <stgraber> pitti: are you doing more than adding discard to any SSD+fs that supports it and doing an ATA wipe every once in a while?
[15:29] <slangasek> pitti: sounds like a good topic
[15:29] <pitti> stgraber: I create a cronjob to call fstrim every week
[15:29] <pitti> stgraber: that can be generalized to iterate over mount points and checking if it's an SSD with TRIM capabilities, etc
[15:30] <pitti> stgraber: I think that's better than "discard", but that's a subject for discussion I think
[15:30] <pitti> stgraber: either way, whether discard or cron, we need to do it
[15:30] <pitti> drives get excruciatingly slow (I got 1.5 MB/s!) after half a year or so without out
[15:30] <pitti> s/out/it/
[15:31] <stgraber> pitti: agreed. All my systems run on SSD here and have all been running with discard, haven't seen any obvious side effects and I have some with pretty busy SSDs running for 2-3 years now. But yeah, a vUDS discussion would be a very good thing as what we do by default is clearly wrong ;)
[15:34] <pitti> stgraber, slangasek: ack, I'll register a BP Monday
[15:35] <stgraber> pitti: thanks, can you subscribe me to it?
[15:35] <pitti> stgraber: sure
[15:35] <stgraber> awesome, thanks
[15:36] <pitti> it's primarily a "pick your pain" decision anyway, slow delete vs. a rather unpredictable I/O load every week (or whatever frequency we decide)
[15:39] <cjohnston> lool: did you get my email about the milestones for the trusty cycle?
[15:56] <lamont> seb128, pitti: shoujld be back
[18:05] <kenvandine> @pilot in
[18:33] <roadmr> stgraber: hello, I see the checkbox-0.14.10 package made it into proposed, did the diff turn out to be ok after all?
[20:09] <kenvandine> @pilot out
[20:53] <Noskcaj> rbasak, PING
[20:55] <Noskcaj> rbasak, Do you plan to merge pysvn any time soon?
[20:59] <brainwash> pitti: systemd-shim.c, line 118: the dbus signal does not get emitted occasionally after resuming from suspend. what could be the reason?
[20:59] <brainwash> pitti: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/systemd-shim/saucy/view/head:/src/systemd-shim.c#L118
[21:15] <rbasak> Noskcaj: not right now; do you want to take it?
[21:16] <Noskcaj> rbasak, Sure
[21:18] <rbasak> Noskcaj: thanks!
[21:19] <infinity> Looks like at least one of the patches can probably be dropped.
[21:20] <bdmurray> slangasek: how does trusty get added to extras.ubuntu.com?  bug 1244050
[21:20] <infinity> Possibly both.
[21:24] <infinity> Noskcaj / rbasak: Looks like both our patches made it upstream, I'll just sync pysvn.
[21:24] <Noskcaj> infinity, ok
[21:25] <rbasak> infinity: thanks!
[21:26] <Noskcaj> It's a bit worrying that the actual maintainer of pysvn hasn't done much in the last 2 years
[21:27] <slangasek> stgraber: extras.ubuntu.com> ^^ ?
[21:27] <slangasek> bdmurray: I guess it's in some way an ARB function, but I'm not sure if the ARB is still a going concern
[21:28] <stgraber> slangasek: can't do anything about it, no longer on the TB
[21:28] <slangasek> stgraber: so it's a TB-controlled thing?
[21:28] <infinity> What TB?
[21:28] <Laney> Isn't it a mirrored PPA?
[21:28] <stgraber> slangasek: you need someone on the TB or on the ARB to copy a package between an existing series and trusty in the PPA, wait for it to publish, then remove it
[21:28] <stgraber> that way trusty is created on ppa.launchpad.net
[21:29] <stgraber> and a bit later, that gets mirrored over to extras.u.c
[21:29] <infinity> Which PPA is this?
[21:29] <slangasek> and the ARB doesn't exist anymore either?
[21:29] <slangasek> bdmurray: so... I guess you can assign it to the technical board :)
[21:29] <infinity> I'm sure we can make this happen without a TB.
[21:29] <infinity> stgraber: Which PPA?
[21:29] <stgraber> infinity: https://launchpad.net/~app-review-board/+archive/ppa
[21:30] <Laney> the ARB has members
[21:30] <infinity> Nothing published there for saucy, either.  Shiny.  Though I assume the copy/delete trick happened.
[21:30] <stgraber> yep, I did it back in saucy
[21:30] <stgraber> http://ppa.launchpad.net/app-review-board/ppa/ubuntu/dists/
[21:31] <stgraber> I believe the latest extras.u.c upload was in quantal
[21:31] <infinity> Curious that no one's tried to get it to publish for all arches.
[21:32] <infinity> Anyhow, if you can't find an ARB person to do it, we can get a duckie to.
[21:33] <bdmurray> okay thanks
[21:33] <stgraber> highvoltage, ajmitch: around?
[21:33] <infinity> ajmitch: You arou... What he said?
[21:37] <stgraber> if we had governance bodies who could make that decision, it'd be nice to get rid of extras.u.c with 14.04 since this clearly isn't used
[21:48] <slangasek> stgraber, bdmurray: if extras.u.c should go away for 14.04 anyway, then that means we should really quirk it in u-r-u
[21:49] <CajunTechie> Hey guys, off-topic I know but how do I get in touch with the folks at developer.ubuntu.com?
[21:49] <stgraber> slangasek: it'd have to be discussed with the CC and TB, but since nothing was published in the past two cycles, it'd seem reasonable to consider this a failure and move on
[21:50] <stgraber> in which case we'll indeed need some code to get it out of any system that used to have it enabled
[21:52] <sarnold> CajunTechie: this is probably a reasonable starting point: https://bugs.launchpad.net/ubuntu-website-content
[21:55] <CajunTechie> Sarnold: Nope. Not a mention of it on that site. Can nobody submit apps through developer.ubuntu.com right now?
[21:56] <sarnold> CajunTechie: let's take a quick step back :) what are you trying to accomplish? :)
[22:00] <CajunTechie> Sarnold: I'm trying to submit a new application. It worked last night for the original submission. Then I needed to update and it gives me a 400 error
[22:07] <sarnold> CajunTechie: aha! thanks :) try #ubuntu-app-devel  ?
[22:10] <CajunTechie> Thanks! Didn't know about that one. You're a life-saver Sarnold :-)
[22:10] <sarnold> CajunTechie: happy to help, I hope you can get the problem sorted out quickly! :)
[22:11] <Noskcaj> mdeslaur, Can you look at https://code.launchpad.net/~noskcaj/ubuntu/trusty/libxrandr/libxrandr ? It builds, but the lintian warning about changes to the diff makes me unsure i did this right
[22:14] <mdeslaur> Noskcaj: sure, when I get a minute
[22:22] <ev> bdmurray: thanks for landing the t-series update to the retracer config
[22:24] <bdmurray> ev: no problem, I also added T to errors
[22:24] <bdmurray> ev: I haven't submitted an RT for the update though
[22:27] <ev> bdmurray: we're literally working on the stagingstack retracers deployment now, so it won't be too long until we have proper cloudy retracers set up
[22:35] <slangasek> chiluk: hi, I've just assigned bug #1242746 to you... it appears there's a regression reported in the procps SRU
[23:12] <mdeslaur> Noskcaj: looked good, uploaded, thanks!