[10:28] <irgendwer4711> the is a big bad regrssions/bug im openssl 0.9.8k!
[15:22] <elopio> ping ubuntu-qa: can somebody please review this one?
[15:22] <elopio> https://code.launchpad.net/~canonical-platform-qa/dialer-app/custom_proxy_objects/+merge/230687
[15:22] <robotfuel> elopio: I'll review
[15:22] <elopio> thanks
[15:23] <elopio> robotfuel: there seems to be something wrong in launchpad, as it doesn't display the rename from tests/autopilot/dialer_app/emulators.py to tests/autopilot/dialer_app/__init__.py
[15:24] <elopio> so you might need to pull the branch or check the commits.
[15:24] <robotfuel> elopio: ok I'll pull from trunk and use meld
[15:24] <robotfuel> elopio: thanks for pointing that out
[15:25] <elopio> meld is sooo good.
[16:34] <elopio> brendand: I think the right testability solution for cases like the camera is to be able to launch it with an argument that disables some optional features. When we are not testing those features, we use the argument.
[16:34] <elopio> http://developer.ubuntu.com/api/qml/sdk-14.10/Ubuntu.Components.Arguments/
[16:35] <elopio> brendand: to see the screenshots, get
[16:35] <elopio> https://github.com/cgoldberg/subunitdetails
[16:35] <elopio> wget https://jenkins.qa.ubuntu.com/job/utopic-touch-mako-smoke-daily/708/artifact/clientlogs/gallery_app/test_results.subunit
[16:36] <elopio> python3 /path/to/subunitdetails.py test_results.subunit
[16:36] <elopio> eog *FailedTestScreenshot
[16:36] <elopio> I do it from the /tmp/ dir because it has some problems with long paths.
[16:37] <brendand> elopio, maybe
[16:39] <brendand> elopio, it feels like testability isn't thought about very much
[16:40] <elopio> brendand: I think we have never been involved in the planning stages of the projects.
[16:40] <brendand> elopio, we need to insist. with a large stick if necessary
[16:41] <elopio> last sprint was already to late. I hope it will get better, and pushing for qml test driven will help.
[16:42] <elopio> I bet the camera doesn't have a single qml test.
[16:45] <alesage> +1 meld
[16:49]  * cgoldberg brb's
[17:16] <robotfuel> elopio: I finished my review of https://code.launchpad.net/~canonical-platform-qa/dialer-app/custom_proxy_objects/+merge/230687
[17:17] <elopio> thanks robotfuel. I will fix the pep8 issues.
[17:17] <elopio> robotfuel: we need a way to do this checks on build time, because I keep fixing them on every branch
[17:17] <elopio> but as pep8 and pyflakes are not on main, I had problems doing that for main packages.
[17:18] <robotfuel> elopio: we need to add flake8 and deps to main :P
[17:20] <elopio> robotfuel: fixed and pushed.
[17:20] <elopio> robotfuel: do you know how to move a package from universe to main?
[17:21] <robotfuel> elopio: pitti would be the best person to ask. maybe jibel will know
[17:25] <jibel> elopio, https://wiki.ubuntu.com/MainInclusionProcess
[17:26] <elopio> thanks jibel.
[17:26] <elopio> jibel: and do you know if there's an alternative? Could we add buid-deps in universe to packages in main?
[17:27] <jibel> elopio, AFAIK it is no possible
[17:27] <cgoldberg> is anyone using one of those fancy new online IDE's for development,  like Cloud9 or Nitrous.io ?  any thoughts on either?
[17:27] <elopio> cgoldberg: brendan is using cloud9
[17:28] <elopio> we have a pending pair-programming session. It looks really cool, but I have only played a little with it.
[17:28] <jibel> elopio, or your package will finish in this list http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.txt
[17:28] <cgoldberg> elopio, thanks.. i'll talk to him... I'm gonna try it out
[17:28] <elopio> jibel: I see.
[17:28] <elopio> jibel: next week I'll try to move pyflakes and pep8 to main.
[17:51] <elopio> ubuntu-qa: this one is ready for review: https://code.launchpad.net/~canonical-platform-qa/ubuntu-autopilot-tests/launcher/+merge/230861
[17:53] <elfy> if anyone else has the time, inclination and unicorns available, can they give recordmydesktop a whirl - crashes for me - want to check it's not just local - thanks peeps
[17:55] <elopio> elfy: seems to work here.
[17:55] <elopio> any steps to reproduce the crash?
[17:57] <elfy> mmm - I was trying to do so with a window
[18:10] <elfy> elopio: thanks for trying though :)
[18:30] <balloons> elfy, no confirmation?
[18:30] <balloons> I've always used kazaam
[19:06] <cgoldberg> elfy, whats the prob your having with recordmydesktop?  it's used inside Autopilot for video recording... haven't heard any peeps about bugs with it recently
[19:07] <elfy> just appears to crash and do nothing cgoldberg - but it's entirely possible it's local - I do muck about a bit
[19:07] <elfy> and if that's the case I'd be more or less positive it's local :)
[19:23] <elfy> balloons: you about? want to report something but have no idea where :(
[19:26] <balloons> elfy, sure
[19:26] <elfy> so this isn't a bug as such, but something we get out there on the coalface
[19:27] <elfy> people choose lvm/encryption during install - that causes a 256Mb /boot partition - people upgrade etc, kernels pile up - they don't find out until they're presented with an upgrade error because the partition is too full
[19:29] <elfy> so it's not a bug - but it is an issue - especially with people coming to *buntu land
[19:31] <elfy> not really sure what to do about that nor who to talk to
[19:31] <knome> to me it sounds like reporting it against ubiquity wouldn't be awfully wrong
[19:31] <elfy> mmm
[19:32] <elfy> ubiquity is doing what it's told to - someone must have told it to use 256Mb
[19:32] <elfy> it's really about education imo
[19:32] <elfy> you could make /boot 1Gb and people would just not know till even later :)
[19:32] <knome> mmh
[19:33] <knome> though aren't older kernels cleaned up automatically? at least if you use apt-get autoremove..
[19:36] <elfy> knome: not afaik - you need to remove the kernel properly - and that's the problem and where the lack of education is
[19:36] <knome> hmm
[19:36] <elfy> yea
[19:47] <balloons> knome, elfy hmmm.. So for stable releases you should get the existing kernel, and the previous. That's it
[19:47] <balloons> everything else should be getting cleaned
[19:48] <elfy> well it's not happening apparently
[19:48] <balloons> and yea I get the issues.. since not everyone will even understand what they've done with encryption, we should keep this complexity away
[19:49] <balloons> hmm
[19:50] <balloons> docs don't seem to back that up.. so I'm living in a drema
[19:50] <elfy> :)
[19:52] <balloons> so elfy I would say making the partition larger doesn't particularly help either
[19:52] <balloons> but meh
[19:53] <balloons> thinking about it, I'm not sure there is an easy solution
[19:53] <elfy> balloons: agreed - you could make it moon big and still - wondering if something as simple as a note on the partitioning stage would at least point people to the fact
[19:55] <elfy> like I said it's not a *bug* as such
[19:55] <balloons> if it helps (and it doesn't) the closest thing I can think of is a chromebook. There are 2 partitions, and updates bounce between them. So you have the new one, and the old one. Next update will flash the one not in use
[20:00] <elfy> so the question is I guess who to talk to about it
[20:02] <balloons> well since we don't have even a notion of a solution, might be worthwhile to spend time researching to come up with one
[20:05] <elfy> mmm
[20:08] <elfy> balloons: I don't believe that increasing it will do anything other than postpone the day - so at least that's one thing not to worry too much about :)
[20:09] <balloons> and we can't automagically remove old kernels actually
[20:09] <elfy> no?
[20:09] <elfy> so it's about education somehow
[20:09] <elfy> not easy :)
[20:10] <balloons> we can technically, sure, but it's a it crazy to remove something like that automatically
[20:10] <balloons> if you think about it a little :-)
[20:10] <balloons> so yea, education so it seems
[20:13] <elfy> is a smallish line of text in ubiquity out of the question?
[20:14] <elfy> currently under the encrypt option we have "You will choosea security key in the next step"
[20:15] <elfy> "You'll get a /boot partition too - do sum lurning bout cleaning up old unused kernels too"
[20:15] <elfy> would not something like that be the simplest and easiest way
[20:41] <elfy> or a slide - not sure - thinking about something else now :)
[21:03] <balloons> elfy, I don't think they would be keen on dumping text on the installer page.. people don't read it anyway :-)
[21:03] <knome> was thiking the same...
[21:03] <knome> thinking too ;)
[21:04] <balloons> having warnings about "are you sure you want to do this?" or "do you understand this?" likely won't help either
[21:04] <elfy> didn't think that would be the case tbh
[21:05] <knome> no, and saying "for advanced users only" makes everybody immediately an advanced user..
[21:05] <elfy> it's a shame that the people who make these decisions are so far removed from the reality of being someone who's not got a clue what they're doing when they click buttons
[21:06] <elfy> ubuntu is a long way away from the old linux for people ideal
[21:17] <elfy> no at all sure what to be about this tbh, possibly just wander off and ignore it
[21:18] <knome> i'd file a bug
[21:18] <elfy> pointless imho
[21:18] <knome> at least it'll get some attention at some point from somebody
[21:18] <elfy> it'll just fester and get marked as dead
[21:19] <elfy> sounds negative - I don't mean it to at all :)
[21:20] <knome> getting marked as invalid is better than no bug; at least somebody has done some thinking and come to the conclusion that things are okay as they are now
[21:22] <elfy> I don't mean invalid :)
[21:22] <knome> heh
[21:22] <elfy> invalid is fine :)
[21:22] <knome> i guess the other thing we should look at is *how* old kernels get purged
[21:22] <knome> because they do get purged for me
[21:24] <elfy> one of the other admins has -24, -27, -29, -30, -32, -33 and -34 in 14.04
[21:24] <elfy> and I never have an install long enough to get that many :)
[21:25] <elfy> none of the new kernels I've been getting in utopic are automatically anything at all
[21:26] <knome> i have 9 kernels; autoremove proposes removing one
[21:27] <knome> wait, not 9
[21:27] <knome> 5
[21:27] <knome> :P
[21:31] <elfy> not even sure how to word a bug ... sigh
[21:32] <knome> ;)
[21:33] <elfy> s/a/this :p
[21:35] <elfy> well reported it for better or for worse
[21:35] <knome> :)
[21:36] <elfy> bug 1357093
[21:37] <elfy> of course that notice lies - emptying trash, removing temp packages or apt-get clean will make no difference at all ;)
[21:37] <elfy> s/in this instance
[21:40] <knome> heh, yeah
[21:42] <elfy> even doing something with that notice - if that can be targetted - would be after the horse has bolted
[21:42] <elfy> anyway - nothing more I can do :)