[00:46] <saiarcot895> Is there any chance that https://code.launchpad.net/~saiarcot895/ubuntu/utopic/openwalnut/armhf-fixes/+merge/232879 will be merged in before Utopic is released?
[00:47] <saiarcot895> or at least sponsored?
[01:25] <dobey> saiarcot895: is it seeded in an image?
[01:25] <saiarcot895> dobey: no
[01:26] <saiarcot895> At least according to http://reqorts.qa.ubuntu.com/reports/sponsoring/index.html
[01:30] <dobey> saiarcot895: shouldn't be too difficult to gt it sponsored if you ping someone then. but final beta freeze is in effect, and beta release tomorrow, so i wouldn't expect too much before friday at least
[04:57] <pitti> Good morning
[04:57] <pitti> infinity: langpack uploads> from cron, yes
[04:58] <pitti> sarnold: yw; the ddeb archive is fixed now
[04:58] <pitti> stgraber: ah, great, thanks
[04:59] <sarnold> pitti: yay :) thanks!
[05:01] <infinity> pitti: Was slightly odd timing, that's why I asked. :)
[05:01] <pitti> infinity: yeah, sorry; if they are inconvenient you can just reject them
[05:02] <pitti> infinity: utopic uploads every wednesday
[05:03] <infinity> pitti: Might make more sense in the future to ensure that devel series uploads happen on Fridays, to minimize possible clashes with milestones.
[05:05] <pitti> wgrant: ^ I'm happy to swap RTM and Utopic, i. e. Wed and Fri; or Tue and Thu for the LP exports
[05:06] <infinity> pitti: Not that it matters for utopic anymore, just in the future. :)
[05:07] <infinity> pitti: For devel series' going forward.
[05:07] <pitti> infinity: yeah, the final langpack should be a full -base update, and coordinated manually indeed
[05:28] <dholbach> good morning
[05:47] <thopre01> Laney: Thanks a lot for the sync
[08:55] <dholbach> can you all please help out review the incoming sponsoring items? there's 94 of them right now.
[09:00] <seb128> dholbach, I did some yesterday, I'm going to try to keep doing a few a day
[09:00] <seb128> like 5 a day or something ;-)
[09:00]  * dholbach hugs seb128
[09:00] <dholbach> haha, yes, that'd be great :)
[09:00]  * seb128 hugs dholbach back
[09:53] <seb128> cjwatson, hey, do you have api documentation somewhere for libclick?
[09:56] <chrisccoulson> hey seb128!
[09:56] <seb128> chrisccoulson, hey, how are you?
[09:56] <chrisccoulson> seb128, not bad thanks, and you?
[09:56] <seb128> chrisccoulson, I'm good thanks ;-)
[10:24] <cjwatson> seb128: just the gtk-doc-style comments in the source, though I'm not sure I've actually generated useful HTML out of them
[10:24] <cjwatson> should sort that out - build system help welcome :)
[10:25] <seb128> cjwatson, is using click_db_new/click_db_read/click_db_get_manifests_as_string the correct way to replace an exec "click list --all --manifest"?
[10:25] <seb128> (seems to work fine)
[10:27] <cjwatson> seb128: right, if you're just replacing a command then you can just read through click/commands/list.py and do the equivalent things
[10:27] <cjwatson> seb128: that's indeed right, you might want to drop _as_string if you want structured output
[10:28] <seb128> cjwatson, that code calls QJsonDocument::fromJson() on the output, seems to work fine like that
[10:28] <cjwatson> ah, yeah, that's fine too
[10:28] <seb128> I don't want to refactor the json/parsing code atm, just replace the call to click
[10:29] <seb128> cjwatson, thanks :-)
[10:29] <cjwatson> you get a few translations back and forward to json, but that has the effect of guaranteeing that it's valid json and normalising, so I don't think I'll "optimise" that
[10:30] <seb128> yeah, I'm not concerned about performance
[10:30] <seb128> the whole listing/parsing takes 100ms with the libclick version
[10:30] <seb128> which is good enough for me
[10:31] <cjwatson> that's probably ok, we can maybe look at profiling it at some point
[10:31] <seb128> yeah, that's good enough for rtm though
[10:31] <seb128> I'm sure we can do better, but let's do that after the important things are in place ;-)
[10:33] <mvo> seb128: just curious, what app is that that will use it?
[10:33] <seb128> mvo, ubuntu-system-settings, about->storage to list the installed clicks
[10:33] <mvo> aha, nice
[10:34] <seb128> we already do that
[10:34] <seb128> but we use a system call to the click command
[10:34] <seb128> replacing it by the lib
[10:34]  * mvo nods
[10:34] <cjwatson> I actually had a stale branch locally for that ages ago :-/
[10:35] <cjwatson> can't remember what I got stuck on - I think I couldn't figure out how to test it
[10:35] <seb128> cjwatson,
[10:35] <seb128> gchar* click_db_get_manifests_as_string (ClickDB* self, gboolean all_versions, GError** error);
[10:35] <seb128> what happen if all_versions is false? it lists only the current/most recent one?
[10:35] <cjwatson> looks like I had http://paste.ubuntu.com/8424573/
[10:35] <cjwatson>          * @all_versions: If true, return manifests for all versions, not
[10:35] <cjwatson>          * just current ones.
[10:36] <seb128> k
[10:36] <cjwatson> if you're emulating click list --all --manifest then you want that as true
[10:36] <seb128> yeah, I did
[10:36] <seb128> but we have a bug about some items being duplicated so I was thinking about that
[10:36] <seb128> but that needs input from design/mpt
[10:36] <seb128> those are the pre-installed clicks
[10:37] <seb128> they have their base image version and the store update listed
[10:37] <seb128> but since they both use space that might be the right thing to do
[10:37] <cjwatson> they do both use space, but the user can't do anything about the preinstalled ones
[10:37] <seb128> right
[10:38] <seb128> but that panel doesn't let you do anything anyway
[10:38] <cjwatson> I mean they can "remove" (hide) them but they'll still take up space
[10:38] <seb128> it just gives you info on what uses space
[10:38] <seb128> https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings/+bug/1325656
[10:38] <seb128> that's the bug, waiting for design input
[10:38] <cjwatson> there are a few things you could do; you could do something with the boolean _removable key, or the _directory key tells you the full path
[10:39] <seb128> cjwatson, you diff looks similar to mine, except you did more and changed some of the json code ... I'm happy to test your version if you want
[10:39] <cjwatson> I don't mind, didn't have time to do it properly, if you have something working then go ahead
[10:39] <cjwatson> was just FYI
[10:39] <cjwatson> if you're using _removable then note the comment in the docs
[10:39] <cjwatson>  * _removable: 1 if a package is unpacked in a location from which it can be
[10:39] <seb128> let me see if yours applies/work
[10:39] <cjwatson>    removed, otherwise 0 (this may be changed to a proper boolean in future;
[10:39] <cjwatson>    client code should be careful to permit either)
[10:40] <seb128> ok, thanks
[10:40] <cjwatson> there's some glib call that makes that natural
[10:44] <seb128> cjwatson, http://paste.ubuntu.com/8424633/ is my diff which is working, I'm trying your in case, since you did a bit more work that would be a shame to see that wasted if it's working :-)
[10:48] <cjwatson> well, ok, your call :)
[10:48] <seb128> cjwatson, none of that applies without conflict :/
[10:48] <cjwatson> I renamed a couple of files to avoid click.h clashing
[10:49] <seb128> cjwatson, I'm going to land my change and keep your diff for inspiration if I want to look at the json changes later
[10:49] <cjwatson> yeah, don't worry about it, it's probably not worth the time
[10:49] <cjwatson> thanks
[10:49] <seb128> thank you for the help!
[10:51] <cjwatson> seb128: your patch looks fine except that you should g_object_unref the db when you're done (looks like I forgot that too)
[10:51] <seb128> cjwatson, ok, good catch, thanks
[11:09] <jamespage> barry, any chance I could persuade you to bump a new version of websocket-client (0.18) into Debian? I'd like to get that into 14.10 to support some updates into jujudeployer/jujuclient to suppport SSL
[11:47] <dgadomski> hello everyone
[11:48] <dgadomski> mlankhorst: hi, I try to solve bug 1104230 for trusty, I checked and the fix for it may be fairly easy to cherry pick for the utopic kernel
[11:48] <dgadomski> is the utopic kernel packaged for trusty anywhere?
[11:49] <dgadomski> I was told that there were some *-lts-* backport packages, but I don't know any details
[11:52] <dgadomski> mlankhorst: I would appreciate your help on this
[12:07] <rbasak> dgadomski: the lts backport kernel package for Trusty will only arrive in trusty-updates in preparation for 14.04.2. That won't be for a while yet.
[12:07] <rbasak> I'm not sure if there's another source to get a packaged Utopic kernel for Trusty though.
[12:08] <dgadomski> rbasak: I see, thank you for info
[12:11] <rbasak> dgadomski: you could see if https://wiki.ubuntu.com/Kernel/MainlineBuilds can help you.
[12:11] <rbasak> That's not exactly the same as Utopic though.
[12:12] <rbasak> Or for testing just try installing a Utopoic kernel .deb directly on Trusty.
[12:12] <rbasak> (unless somebody says there's a reason that won't work)
[12:13] <dgadomski> rbasak: thanks, I will try to get the fix to utopic first (since it will be also useful there) and then will work on finding a way to get it to trusty
[12:22] <mlankhorst> the .deb should work
[12:22] <mlankhorst> but if you have binary package the dkms drivers might now
[12:22] <mlankhorst> not*
[13:13] <barry> jamespage: sure.  will take a look today
[13:13] <jamespage> barry, ++ thanks
[13:30] <rbasak> @pilot in
[14:26] <mdeslaur> Riddell, ScottK: you've probably seen this already, but just in case: http://www.kde.org/info/security/advisory-20140923-1.txt
[14:29] <Riddell> mdeslaur: hmm, I'm sure we had that problem last month
[14:29] <Riddell> mm, a similar one 2014-08-03 krfb integer overflow
[14:29] <mdeslaur> Riddell: was a different one I believe
[14:30] <Riddell> I wonder why I didn't get notification of that issue
[14:30] <Riddell> mdeslaur: anyway, will put on the todo list for today or tomorrow
[14:31] <mdeslaur> Riddell: cool, thanks!
[14:52] <barry> jamespage: websocket 0.18.0 pushed to sid.  when it lands there, it will require an ffe and a merge/sync (we have ubuntu deltas).  do you want to take care of that or should i?
[14:52] <jamespage> barry, I can do that - its OK for a sync - the delta can go now
[14:52] <jamespage> barry, thanks for that!
[14:52] <barry> jamespage: \o/
[15:17] <seb128> zul, hey, is https://bugs.launchpad.net/ubuntu/+source/keystone/+bug/1364854 still on your todolist? (it's in the sponsoring queue for a while, should sponsor be unsubscribed since you are assigned to it)
[15:17] <zul> seb128:  it is
[15:17] <seb128> zul, should I unsubscribe sponsors then?
[15:17] <zul> seb128:  yes please
[15:17] <seb128> zul, thanks
[15:33] <slangasek> apw: so if jodh is right and 'plymouth-ready' is never emitted, that points to a problem earlier with plymouth itself failing to start
[15:34] <apw> slangasek, and indeed plymouth is segv'ing which would be a fail
[15:35] <apw> jodh, ^ we're over here
[15:36] <apw> slangasek, so how can we capture that coredump, i assume we arn't rw yet
[15:37] <ogra_> apw, into /dev
[15:37] <apw> jodh, on my reproduce we the plymouth-upstart-bridge blows up about .5s before plymouth log wise
[15:37] <ogra_> (thats always writable)
[15:38] <apw> ogra_, point
[15:38] <slangasek> not /dev, /run
[15:38] <slangasek> :)
[15:39] <ogra_> both work :)
[15:39] <ogra_> but /dev is there all the time, do we have /run in initrd already ?
[15:41] <infinity> ogra_: We do, yes.
[15:41] <ogra_> ah
[15:41] <infinity> mount -t tmpfs -o "noexec,nosuid,size=10%,mode=0755" tmpfs /run
[15:41] <infinity> mkdir /run/initramfs
[15:41] <infinity> # compatibility symlink for the pre-oneiric locations
[15:41] <infinity> ln -s /run/initramfs /dev/.initramfs
[15:41] <infinity> ^--- The last line being to appease people who are too laze to get with the new world order. :P
[15:41] <ogra_> oh, right, i even remember these lines
[15:42] <infinity> s/laze/lazy/
[15:42] <infinity> (Not that it matters at all for a temporary hack)
[15:42] <infinity> You could write your logs to /dev/bozo-the-clown for all I care.
[15:43] <infinity> apw: Please write your logs to /dev/bozo-the-clown
[15:43] <ogra_> ++
[15:43] <infinity> (This is in no way a statement about your hair style)
[15:43] <infinity> "Style".
[15:44] <infinity> "Hair".
[15:44] <ogra_> lol
[15:51] <apw> i need a longer knee
[16:07] <smoser> hey. can i get someone to move cloud-init from -proposed to trusty-updates ?
[16:07] <smoser> bug 1353008
[16:14] <rbasak> If someone wants to sponsor emacs24 in bug 493766 it looks fine to me but I've just noticed it's in main so I can't upload it.
[16:14] <rbasak> (though a merge would be better)
[16:19] <bdmurray> smoser: I'll have a look at cloud-init
[16:21] <smoser> bdmurray, thank you.
[16:31] <slangasek> cjwatson: is bug #1334189 something I should assign to you, or should someone else look at it?
[16:32] <cjwatson> slangasek: I don't have a *problem* with somebody else looking at it, but I don't think anyone else has any experience at all with the twisty pile of code involved
[16:33] <slangasek> ok
[16:33] <cjwatson> (which, I suppose, isn't a good reason not to assign somebody else to it to learn; just budget a few extra days ...)
[16:34] <rbasak> @pilot out
[17:00] <bdmurray> mitya57: where is the verification for bug 1370443?
[17:12] <Riddell> mdeslaur: bug 1374043 for your review and upload
[17:12] <mdeslaur> Riddell: thanks
[17:20] <bdmurray> seb128: could you have a look at the verification of bug 1353951? one person says it works another says they have an issue…
[17:44] <bdmurray> arges: bug 1174098 is missing SRU information
[18:45] <arges> bdmurray: i'll update
[18:46] <bdmurray> arges: okay, let me know when its good to go
[18:48] <arges> bdmurray: ok updated
[21:58] <nadrimajstor> Why LP keeps eating white space when I copy&paste snippet of patch file in to the comments?
[21:59] <sarnold> probably some "HTML doesn't care about whitespace" thing; everyone's used to it, though, so just paste away and be sure to include the patch as an attachment if you intend someone else to apply it as-is
[22:00] <warptrosse> [B[Bexit
[22:01] <pataq> Sorry but where is the 14.10 final beta? i thought i was supposed to be released yesterday
[22:05] <nadrimajstor> sarnold: A bit annoying... It is snippet of .py to make matters worse... and it strips only lines that begins with `+` :|
[22:06] <sarnold> nadrimajstor: hehe yeah I've had that happen to python snippets before too. not fantastic :) but you can still document what you mean that way..
[22:07]  * nadrimajstor will provide patch as a attachment and appropriately changed bash line for applying patch.
[22:07]  * nadrimajstor popey just loves my rants about LP :D
[22:07] <nadrimajstor> Goodnight everyone o/