[01:49] <hyperair> did ssh-agent just go missing?
[01:50] <hyperair> s/ssh-agent/seahorse-agent
[01:53] <TheMuso> hyperair: Seems to be working for GPG and ssh here for me.
[01:54] <hyperair> whoops, looks like it's gnome-keyring-daemon, not seahorse-agent
[01:54]  * hyperair forgot the command required to reinitialize it after it crashes
[01:54] <hyperair> gnome-keyring-start, and then stuff the environment variables into compiz via gdb
[01:55] <hyperair> :D
[01:55] <hyperair> er gnome-keyring-daemon --start
[03:37] <TheMuso> 6@pilot out
[03:37] <TheMuso> @pilot out
[04:00] <obiwandk> hello
[05:03] <pitti> Good morning
[05:03] <pitti> stgraber: \o/ thanks for reviewing
[05:04] <Unit193> Howdy.
[05:04] <pitti> ScottK: I don't know this very well, but it's plausible that its test needs to be updated to use a current release
[06:37] <tjaalton> shouldn't normal upgrades remove ubuntuone from trusty?
[06:54] <pitti> tjaalton: ubuntu-release-upgrader ought to, in the cleanup stage
[06:57] <tjaalton> guess it doesn't work when upgrading trusty->trusty
[06:59] <LocutusOfBorg1> no problem barry :)
[07:11] <tvoss> doko_, good morning :)
[07:12] <tvoss> doko_, I just tried to install C++ pretty printers in gdb without luck. Do we have some instructions online how to enable them?
[07:17] <dholbach> good morning
[07:35] <doko> tvoss, just what is available in the standard docs
[07:35] <tvoss> doko, ack
[07:36] <doko> tvoss, have a look at libstdc++6, a pretty printer just has to be found in some location with a specific name
[07:36] <tvoss> doko, ack
[07:37] <doko> pitti, jibel: I demoted libcursesada to -proposed, however the failing autopkg test still seems to block ncurses. same for libaunit. any idea how to proceed?
[07:40] <pitti> doko: ah, still uninstallable due to missing gnat-4.6 -> 4.9 transitino?
[07:41] <doko> pitti, well, gnat wants to migrate too ...
[07:42] <pitti> so the release team could certainly set an override for ncurses to migrate
[07:42] <pitti> as it's clearly the "ada" part, not the "ncurses" one which is the problem :)
[07:45] <pitti> doko: oh, a solution is in sight: https://ftp-master.debian.org/new/libncursesada_5.9.20140726-1.html
[07:46] <pitti> seems gnat itself will still take a while: https://release.debian.org/migration/testing.pl?package=gnat
[07:47] <pitti> (but we don't really care about ada, do we?)
[07:48] <pitti> ScottK: I had a look at release-upgrader's tests, but they don't mention "quantal" explicitly; I suppose they download some meta-data from archive.u.c., but I'm not familiar with that; I'm afraid we need to wait for mvo for that, and in the meantime you could add a release team override?
[07:49]  * pitti mails him in the meantime
[08:38] <cjwatson> psivaa: Is there any way I can get hold of /var/log/partman for https://bugs.launchpad.net/ubuntu/+source/parted/+bug/1352252 ?  It's the best log to have for this, but unfortunately it doesn't seem to be attached as an artifact to the job
[08:39] <cjwatson> psivaa: I've tried reproducing this locally and so far have been unable to, even with something that's as close as I can manage to the same disk size, so I need the partman log in order to have byte-identical configuration
[08:40] <psivaa> cjwatson: let me take a look, if i can somehow find the log on a manual install
[08:44] <Unit193> cjwatson: Hellos, I would guess now would be a bad time to remind about tasksel?
[08:46] <cjwatson> Unit193: possibly OK, will have a look shortly
[08:46] <Unit193> Great, thanks!
[08:46] <cjwatson> psivaa: Ideally we'd change the utah config to attach that file on all future installations, both d-i and ubiquity
[08:46] <cjwatson> psivaa: It never hurts to have it
[08:48] <psivaa> cjwatson: yes, let me see if i can do this. probably this week.
[08:48] <psivaa> cjwatson: http://pastebin.ubuntu.com/7959356/ is the partman.log
[08:48] <psivaa> cjwatson: i'll attach to the bug too
[08:49] <cjwatson> psivaa: Excellent, thanks
[08:49] <psivaa> yw :)
[10:06] <doko> jamespage, java component mismatch ping ...
[10:56] <LocutusOfBorg1> sil2100, I changed the lucene++ debian/* license to be LGPL-2+ instead of LGPL-3+
[10:56] <LocutusOfBorg1> it should fix the lintian warning
[10:57] <sil2100> LocutusOfBorg1: ok, LGPL-3+ was anyway only a habit, I'm fine with 2 - thanks!
[10:58] <LocutusOfBorg1> I don't know, it fixes this issue
[10:58] <LocutusOfBorg1>  I unused-license-paragraph-in-dep5-copyright
[10:58] <LocutusOfBorg1>     lgpl-2+ (paragraph at line 89)
[10:58] <LocutusOfBorg1> anyway they say it is good for debian files to have the same license as the upstream sources
[10:58] <LocutusOfBorg1> to make it easier to send patches
[10:58] <LocutusOfBorg1> anyway who cares? lintian is happy and if it is fine with you I'm happy too ;D
[11:09] <pitti> dpm: FYI, fresh langpacks (touch and desktop) are in utopic now
[11:10] <dpm> \o/
[11:17] <jibel> could anyone have a look at bug 1351262 it's blocking 12.04.5
[11:23] <doko> tvoss, which team to use for phablet issues?
[11:28] <doko> tvoss, ev, slangasek: looks like the CI train is bypassing our normal build rules ... see LP: #1349834
[11:29] <tvoss> doko, still on my list
[11:29] <slangasek> doko: what rules are you referring to?
[11:29] <slangasek> ah, component-mismatches
[11:29] <slangasek> there's no way to enforce that in ppas, AFAIK
[11:30] <cjwatson> Right, not fixable there, we just have to clean up afterwards as necessary and try to be vigilant
[11:39] <doko> barry, https://launchpad.net/ubuntu/+source/python-keyring/4.0-1  can you have a look at a MIR, or removal of the new build deps?
[11:55] <doko> pitti, jibel: the status of the autopkg tests for libgcrypt11 seem to be out of date
[11:57] <jibel> doko, looking
[12:15] <jibel> doko, results will be synced on next run of britney
[12:36] <barry> doko: will look
[12:42] <michagogo> Hm, am I misunderstanding https://wiki.ubuntu.com/StableReleaseUpdates#Reviewing_procedure_and_tools?
[12:43] <michagogo> pitti sponsored the package for bug 1314616, but it's not listed on https://launchpad.net/ubuntu/precise/+queue?queue_state=1 nor  http://people.canonical.com/~ubuntu-archive/pending-sru
[12:44] <pitti> michagogo: it's in NEW, due to a Launchpad bug
[12:44] <pitti> https://launchpad.net/ubuntu/precise/+queue?queue_state=0
[12:44] <michagogo> What does that mean?
[12:44] <pitti> michagogo: mostly just that the SRU team needs to check there instead of UNAPPROVED (state=1)
[12:44] <michagogo> Ah. (do they know that?)
[12:45] <pitti> michagogo: I was pinging #ubuntu-release when I sponsored it, and wgrant looked into why it got into the wrong queue, but usually the SRU team wouldn't know
[12:45] <pitti> I was going to ping around every couple of days
[12:45] <michagogo> Is there a way to put it in the right place?
[12:46] <pitti> that's a question for wgrant ^ (but I expect him to be tight asleep right now)
[12:46]  * michagogo goes to read -release backlog
[12:46] <pitti> michagogo: not much to worry about for you though
[12:47] <pitti> bdmurray, RAOF, infinity, ScottK: when you process SRU the next time, please look into precise/NEW for the bitcoin one (not actually NEW, just an LP bug)
[12:48] <michagogo> pitti: Okay, thanks.
[12:50] <wgrant> pitti: I'm in Nürnberg, actually.
[12:50] <pitti> wgrant: oh, welcome to Bavaria!
[12:50] <wgrant> michagogo, pitti: Rejecting and reuploading that package which stick it in unapproved. The bug is fixed, but it's not possible to get it from new to unapproved without a fresh upload.
[12:50] <wgrant> s/which/will/
[12:51]  * michagogo hopes (and assumes) pitti knows what that means
[12:51] <pitti> wgrant: ah, fixed? nice; I can do that
[12:53] <wgrant> pitti: Oh yeah, it was fixed on prod like 6 hours after you reported it, sorry.
[12:54] <pitti> https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text=
[12:54] <pitti> and there it goes
[12:54] <pitti> michagogo: ^
[12:54] <pitti> wgrant: thanks!
[12:54] <michagogo> Awesome, thanks pitti and wgrant!
[12:55] <pitti> bdmurray, RAOF, infinity, ScottK: OK, bitcoin is in unapproved, unping
[13:24] <doko> Mirv, ok to NMU malaga, fixing #755915?
[13:24] <pitti> rbasak: oh, no comments on http://www.justgohome.co.uk/blog/2014/08/ubuntu-git-merge-workflow.html?
[13:28] <Mirv> doko: ok, I've had it highlighted in my personal inbox but haven't got to it
[13:29] <doko> barry, a lot of packages start building modules for pypy. any opinion about having it in main? currently we just disabled these
[13:31] <barry> doko: hmm.  haven't thought about it too much, but i like that folks are starting to support pypy better, and i don't like carrying deltas just to manage this distinction.  maybe we should MIR pypy...
[13:31] <doko> barry, after this week you'll be a MIR expert ;-P
[13:32] <barry> doko: that was my hope and dream!
[13:37] <barry> doko: LP: #1352900
[13:57] <ricotz> pitti, hi, please cherry pick https://git.gnome.org/browse/libwnck/commit/?id=063cc9281372815e0bf0a6b2e63f9b07e1769448
[13:58] <pitti> ricotz: you tell me that 10 seconds after I hit dput..
[13:58] <pitti> ricotz: but I can do another upload, if you need it for anything in particular
[13:58] <ricotz> pitti, i just noticed the packaging commits :\
[13:59] <ricotz> this fixes the reported geometry for gtk csd windows
[14:00] <pitti> ricotz: sure, doing
[14:01] <ricotz> pitti, sorry, i was hoping Trevinho would do an actual release ;)
[14:01] <pitti> ricotz: heh, no problem
[14:01] <ricotz> pitti, thanks!
[14:01]  * pitti fights with a svn assert when tagging the recent upload
[14:02] <pitti> subversion, go away!
[14:08] <pitti> ricotz: uploaded
[14:08] <pitti> ricotz: I'll sync tomorrow morning when it got imported
[14:08] <rbasak> pitti: I don't do blog comments. I get one legitimate comment a year, and many many spam messages. Not worth it IMHO.
[14:08] <rbasak> pitti: reply to ubuntu-devel maybe?
[14:08] <pitti> rbasak: that's what I did :)
[14:08] <rbasak> Oh. Thanks!
[14:08]  * rbasak looks
[14:09] <pitti> rbasak: nothing fancy, hence I'd have written it as blog comment, but ML is fine too
[14:12] <ricotz> pitti, great!
[14:22] <bdmurray> pitti: is bug 1352591 clear enough?
[14:25] <pitti> bdmurray: ah yes, it is
[14:25] <pitti> bdmurray: so this needs to keep track of which version of a package is installed, instead of merely checking for existence of the lib
[14:25] <pitti> bdmurray: it's on my todo list
[14:26] <bdmurray> pitti: okay, thanks!
[14:28] <ScottK> pitti: Thanks.
[14:32] <xnox> bdmurray: release-upgrader failing autopkgtests, anything obvious to you ? https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-ubuntu-release-upgrader/38/ARCH=amd64,label=adt/artifact/results/nose-tests-stdout/*view*/
[14:32] <xnox> (why is it using quantal?!)
[14:33] <bdmurray> xnox: I believe quantal to saucy was a supported upgrade path because raring became EoL before Quantal
[14:33] <xnox> bdmurray: not any more, since both quantal and saucy are EOL now.
[14:34] <xnox> (it was interimish)
[14:34] <xnox> and the files are gone from the archive repository and moved to old-releases by now.
[14:42] <bdmurray> xnox: the issue is with "get_new_dist()" in test_dist_upgrade_fecther_core.py
[14:53] <pitti> xnox: I mailed mvo about it; I loked into the tests, and they don't hardcode quantal anywhere
[14:55] <bdmurray> pitti: I found the issue, see my last comment.
[15:09] <pitti> mdeslaur, infinity: reminder: TB in 50 mins, and you wanted to review the juju policy
[15:09] <mdeslaur> pitti: yes, thanks for the reminder
[15:18] <hallyn> cjwatson: for bug 1350435, if you'd like me to apply the patch in the archive until a proper fix hits upstream, let me know
[15:20] <cjwatson> hallyn: well, I think that's up to you and I'm not going to make you apply something over upstream's wishes, but (if it made it to trusty-updates) I understand it would make a pretty massive dent in the failure rate of non-x86 virt PPAs
[15:20]  * cjwatson follows up to the bug
[15:21] <Mirv> might some core-dev be able to give a packaging ack to https://ci-train.ubuntu.com/job/landing-015-2-publish/lastSuccessfulBuild/artifact/packaging_changes_messaging-app_0.1+14.10.20140805-0ubuntu1.diff ?
[15:23] <hallyn> cjwatson: I'm surprised by just how hostile he is toward it, but i think that's just bc he thinks we're whining to get it upstream;  unless he feels that papering over it in the distros will lower priority of a proper fix causing upper linaro management to not ack the work...
[15:23] <cjwatson> I'm certainly not whining to get it upstream; maybe he's inferring that from the upstream bug task
[15:24] <hallyn> right
[15:24] <hallyn> I'm debating whether to drop that part.  Though it does need to also be tracked there.
[15:24] <hallyn> I don't even know how to mark it in lp if I push the patch - 'fix released' wouldn't be right as it's not going to always work :)
[15:24] <cjwatson> hallyn: re testing, while LocutusOfBorg1 can't supply an alternate qemu in their PPA, it's certainly possible to do testing of this kind of thing on staging by way of the (new) ~canonical-is-sa/ubuntu/buildd-staging PPA
[15:25] <hallyn> cjwatson: are you saying a qemu pkg with that patch would go in that ppa, or that that ppa would be using the new qemu as a test?
[15:25] <cjwatson> which we can ask IS nicely to copy stuff into and rebuild the scalingstack staging image
[15:25] <cjwatson> the former
[15:25] <hallyn> cjwatson: and you'd want this ofr utopic, or trusty, ot be useful?
[15:26] <hallyn> I'm going to go off and merge qemu 2.1-rc1 into utopic right now;  then i'll push something with that patch to a ppa.  (then i need to keep testing precise-to-trusty migration using Alex's patch)
[15:26] <cjwatson> hallyn: trusty
[15:27] <cjwatson> scalingstack is all trusty.  p.s. DIE HARDY DIE
[15:27] <hallyn> :)
[15:27] <cjwatson> obviously we use per-distroarchseries chroots but qemu-user-static comes from the base
[15:27] <hallyn> so should i hadn you the pkg source?
[15:28] <hallyn> s/hadn/hand/
[15:28] <cjwatson> stick it in a PPA somewhere
[15:28] <cjwatson> ideally just that patch on top of trusty-updates
[15:28] <hallyn> will do.  yup, it will.  bbl
[15:28] <cjwatson> (I'm probably not going to be able to organise it this week though; already maxing out IS's tolerance of my requests, I think)
[15:29] <hallyn> my kingdom for tiling support in unity!
[15:29] <hallyn> cjwatson: ok, i'll just hand it to you so you'r enot blocked on me
[15:29] <hallyn> unless you're saying i should make the request
[15:32] <LocutusOfBorg1> cjwatson, if you want that I upload qemu in my ppa is fine, I can do it
[15:32] <LocutusOfBorg1> just ask
[15:33] <hallyn> cjwatson: actualy i'm doing it on top of trusty-proposed;  shout if that seems irresponsible
[15:36] <cjwatson> LocutusOfBorg1: no thanks
[15:36] <cjwatson> won't help anyway
[15:36] <cjwatson> hallyn: should be ok
[15:37] <cjwatson> LocutusOfBorg1: (it's going to need to go through hallyn in any event, so he might as well do it ...)
[15:43] <LocutusOfBorg1> I'm here if needed ;)
[15:47] <hallyn> trial pkg pushed to ppa:serge-hallyn/qemu-user-thread
[15:51] <rbasak> pitti, infinity, mdeslaur: would it help if I could get Juju upstream to today's meeting?
[15:51] <rbasak> Particularly for QA questions
[15:52] <mdeslaur> rbasak: it certainly wouldn't hurt
[15:52] <pitti> rbasak: yeah, Curtis' reply was promising, I'm mostly interested in how much it can/will be exercised for SRU testing
[15:54] <rbasak> pitti, mdeslaur: Curtis is unavailable. I can talk about SRU testing though - I've been working with Curtis on a plan for this.
[15:59] <pitti> kees, infinity: #ubuntu-meeting-2 for TB, s'il vous plaît ?
[16:13] <elopio> Hello
[16:13] <elopio> can I get a review to the debian packaging changes here?
[16:13] <elopio> https://code.launchpad.net/~autopilot/autopilot/trunk/+merge/228235
[16:15] <pitti> elopio: err, I was just looking, but I realize that like 90% of the packaging changes are my fault
[16:16] <pitti> so that would be some kind of self-approval (not wrong in principle, as core devs do that all the time when uploading), just mentioning :)
[16:16] <elopio> pitti: :) we can wait a little for somebody else to do the review if you prefer.
[16:16] <elopio> I won't mind.
[16:17] <pitti> elopio: MP updated
[16:18] <elopio> thanks pitti. Mirv: do we need something else?
[16:18] <pitti> elopio: and FWIW, the earlier that lands, the better
[16:19] <elopio> agree. I really need it.
[16:19] <Mirv> elopio: pitti doing the packaging (and review) is quite enough, he could upload it anyhow
[16:19] <Mirv> but does it need a rebuild now?
[16:20] <Mirv> no, just commented, great
[16:20] <elopio> Mirv: nothing has changed, just the approvals.
[16:20] <Mirv> pitti: elopio: umm. 12h ago slangasek directly uploaded this https://launchpad.net/ubuntu/+source/autopilot/1.5.0+14.10.20140716-0ubuntu2
[16:21] <Mirv> which is a problem for publishing this new branch
[16:21] <slangasek> which new branch is this?
[16:22] <pitti> ah, so I guess slangasek's upload needs to be re-folded into trunk first?
[16:22] <slangasek> yes it does
[16:22] <Mirv> slangasek: https://code.launchpad.net/~autopilot/autopilot/trunk/+merge/228235
[16:22] <Mirv> so update trunk, update merge, rinse and repeat
[16:22]  * slangasek nods
[16:23] <Mirv> you can get it done still today easily, but not my today :)
[16:23] <slangasek> Mirv: I'm in Germany at the moment and am also EOD
[16:24] <elopio> ack. Thanks Mirv and pitti.
[16:24] <elopio> I think I'll better leave it to veebers. He will know if we need to do more testing after the merge.
[16:25] <Mirv> elopio: can you give him a note? the patch to fit in (including changelog entry) is http://launchpadlibrarian.net/181532211/autopilot_1.5.0%2B14.10.20140716-0ubuntu1_1.5.0%2B14.10.20140716-0ubuntu2.diff.gz
[16:25] <elopio> Mirv: I'll wait for him and ping him as soon as he wakes up.
[16:25] <Mirv> alright
[16:25] <elopio> he loves me for getting him new things to do while having breakfast :)
[16:28] <pitti> elopio: FWIW, slangasek's dep changes are unrelated to anything I've seen in the MP, and merging that upload should be a no-brainer given that it's already in utopic?
[16:31] <elopio> pitti: you are right. We already got results running with that version.
[16:31] <elopio> I'll do the merges.
[16:31] <elopio> I was scared to break the dashboard somehow.
[16:43] <michagogo> arges: okay, I did as you asked
[16:48] <elopio> pitti, Mirv: there's another entry on the changelog that is not in trunk
[16:48] <elopio> 1.5.0+14.10.20140716-0ubuntu1
[16:50] <pitti> elopio: hm, process fail? https://launchpad.net/ubuntu/+source/autopilot/1.5.0+14.10.20140716-0ubuntu1 was clearly an auto-land CI train thing
[16:51] <rsalveti> pitti: mterry: getting http://paste.ubuntu.com/7962615/ on latest image (emulator), wonder if that is expected
[16:52] <elopio> I'm a little confused. I think I need to get the diff from 1.5.0+14.10.20140716-0ubuntu2 into the 1.5 branch, not into trunk.
[16:52] <elopio> but I'll just wait for veebers. I might make a mess that's harder to fix.
[16:53] <pitti> elopio: to both, presumably
[16:53] <pitti> the 1.5 branch == utopic, trunk is the actual trunk
[16:53] <pitti> (AFAIUI)
[16:53] <pitti> anyway, way past EOD time, cu tomorrow!
[16:54] <mterry> rsalveti, I'm not sure if they are expected or not.  I've not noticed such errors before, but maybe they were there
[17:22] <jtaylor> doko: any hint how to get a --no-as-needed into gccs hidden commandline for a specific gcc library?
[17:22] <jtaylor> the thing it prints when running gcc -v <file>
[17:22] <jtaylor> in ubuntu gcc nicely strips away -l{a,t,ub}san due to as-needed
[18:13] <asomething> Anyone from Canonical IS around  that I can chat with? elmo?
[18:14] <Unit193> Might be better served in -sysadmin?
[18:15] <asomething> Oh there's, a #canonical-sysadmin Didn't know, thanks Unit193
[18:15] <Unit193> Sure thing.
[18:42] <ScottK> Anyone merging the reportbug security fix?
[18:43] <rww> Is there a timeline or todo list for enabling 12.04 to 14.04 updates? Getting quite a few support questions about when it'll happen.
[18:43] <ScottK> "When infinity feels like it" is the answer, AFAIK.
[18:44] <sarnold> ScottK: mdeslaur said he was going to prepare updates
[18:44] <ScottK> No reason people have to wait if they don't want to though.
[18:44] <rww> ScottK: *nod* Last I heard there was a bugfix update pending for update-manager-core, but I think that got sorted. Not sure.
[18:45] <rww> What's the preferred method for updating now? do-release-upgrade -p ?
[18:45] <rww> (since trusty is in meta-release-lts-proposed )
[18:48]  * ScottK does reportbug
[18:49] <mdeslaur> ScottK: you're doing utopic?
[18:49] <ScottK> mdeslaur: Yes.  I was going to do a trusty debdiff too.
[18:49] <ScottK> If you want it, go for it though.
[18:49] <mdeslaur> ScottK: they're the same, so I'll let you handle trusty
[18:49] <mdeslaur> I'll do precise
[18:50] <ScottK> OK.
[18:54] <ScottK> mdeslaur: Did you put a bug in LP yet?
[18:55] <mdeslaur> ScottK: not yet, one sec, I'll create one
[18:55] <ScottK> mdeslaur: Thanks.  Please ping me the # and I'll start uploading.
[18:55] <ScottK> (and give you a debdiff)
[18:57] <mdeslaur> ScottK: bug 1353046
[18:57] <ScottK> Thanks.
[19:06] <ScottK> mdeslaur: Utopic is uploaded and Trusty debdiff is in the bug.
[19:07] <mdeslaur> ScottK: thanks!
[19:07] <ScottK> Well, I'm motivated.  I read the DSN and went "Wait, I use that package!".
[19:07] <ScottK> yw in any case.
[19:09] <ScottK> mdeslaur: Missed a spot.
[19:09] <mdeslaur> ScottK: hrm?
[19:11] <ScottK> My utopic upload failed.
[19:11] <mdeslaur> ah, yes, trusty FTBFS too
[19:11] <mdeslaur> hrm, that's odd
[19:15] <ScottK> Very.
[19:16] <ScottK> python -c "import reportbug; print reportbug.VERSION_NUMBER" in the source works fine locally.
[19:16] <mdeslaur> that's not the one that's weird, it's the other one that specifically excludes the +nmu* part
[19:17] <mdeslaur> $(shell dpkg-parsechangelog | egrep '^Distribution:' | sed 's/^Distrib
[19:17] <mdeslaur> ution: \([^+]*\).*/\1/')
[19:17] <ScottK> Ah.
[19:17] <mdeslaur> that one...so 6.5.0+nmu1ubuntu0.1 becomes 6.5.0
[19:17] <mdeslaur> I'm wondering if we're better to change the regexp and get the real version
[19:17] <ScottK> I think that's more divergence from Debian, so let's not.
[19:17] <mdeslaur> so all ubuntu versions will report as 1.5.0 from now on?
[19:18] <mdeslaur> er...6.5.0
[19:18] <ScottK> Until there's a non-NMU.
[19:18] <mdeslaur> ok
[19:18] <ScottK> Confirmed that works
[19:18] <ScottK> Do you want another debdiff?
[19:19] <mdeslaur> nah, I'm good
[19:19] <mdeslaur> I just changed it to 6.5.0
[19:21] <ScottK> Same here on Utopic.
[20:35] <hallyn> pitti: hi, would you mind sponsoring http://mentors.debian.net/debian/pool/main/c/cgmanager/cgmanager_0.30-1.dsc ?  I'm hoping this'll be it for some time.
[20:36] <hallyn> (next step will be working on getting what we need from systemd itself)
[21:01] <highvoltage> win 24
[21:56] <sarnold> a user in #ubuntu-hardened is complaining about hash-sum mismatches in http://ddebs.ubuntu.com/dists/trusty-security
[22:16] <sn33zy> any devs need someone to help them? im bored and need something to do (and the bugs.launchpad.net is beyond me)
[22:18] <jtaylor> sn33zy: fancy digging around in the gcc-4.9 package? :)
[22:18] <Noskcaj> jtaylor, That is mean
[22:19] <sn33zy> jtaylor, Noskcaj  if its easy task and I know what im looking for I will do it :)
[22:20] <Noskcaj> sn33zy, You could try making an app for ubuntu touch. http://developer.ubuntu.com/
[22:20] <jtaylor> its probably not easy if your unfamiliar with the package :/
[22:21] <sn33zy> ok :(
[22:21] <Noskcaj> Or fixing bugs in the ubuntu phone core apps
[22:21] <Noskcaj> I have to go to school now, bye
[22:21] <sn33zy> bye Noskcaj