[05:17] <pitti> Good morning
[05:17] <desrt> pitti: hihi
[05:17] <pitti> hey desrt
[05:18]  * desrt is having some trouble with debootstrap :/
[05:18] <desrt> do you know how we build the full package list from a seed?
[05:20] <pitti> desrt: yes, that's "germinate"
[05:21] <pitti> desrt: I don't have too much experience with it, but the metapackages like ubuntu-meta have an ./update script which calls it and inflates it to full lists
[05:21] <desrt> hm
[05:22] <pitti> desrt: I also use it in langpack-o-matic for touch: http://bazaar.launchpad.net/~ubuntu-langpack/langpack-o-matic/main/view/head:/update-touch-packages
[05:22] <desrt> does debian do this in a different way?
[05:22] <pitti> yes, they don't use seeds
[05:22] <desrt> how do they decide what gets in the base system?
[05:22] <pitti> debootstrap just installs everything with Priority: required
[05:22] <desrt> debootstrap has an --include option but it's not very useful :(
[05:22] <desrt> hm.  germinate has python bindings.  interesting!
[05:24] <desrt> i want to fill a deboostrap with the required builddeps for a jhbuild run but the recursive dependency solver of debootstrap has some ... limitations.  the manpage advises to disable it and list all packages explicitly.
[05:25] <pitti> desrt: err yes, don't do that
[05:25] <desrt> seems that germinate may have some similar issues, though
[05:25] <pitti> always start from a plain debootstrap (like schroot or lxc-create), and use normal apt then
[05:25] <desrt> it has a warning in the BUGS section of its manpage that it can get confused
[05:26] <desrt> pitti: ya..... seems like it may be a much better choice
[05:26] <pitti> nothing else handles some corner cases and intricacies of dependencies like apt
[05:26] <desrt> although the idea of doing the full dependency resolution in python is appealing since i have a problem with '|' depends and apt....
[05:27] <pitti> desrt: what I do in autopkgtest is to create a dummy "adt-satdep.deb" with an appropriate Depends: line
[05:27] <desrt> ya.  i have a script that uses equivs to do that
[05:27] <pitti> copy that into the target, dpkg --unpack it, and then call apt-get -f install
[05:27] <desrt> i've seen apt-get -f install "resolve" the situation by uninstalling my .deb :)
[05:27] <pitti> which works reasonably well
[05:28] <pitti> it would only do that for unsatisfiable deps though
[05:28] <desrt> hmmm
[05:28] <pitti> and this should cause an error then
[05:28] <desrt> nah... it just removes the .deb and it's totally happy :)
[05:29] <desrt> anyway... thanks for the advice
[05:29] <desrt> i think i will try to take the equivs approach
[05:30] <pitti> desrt: equivs does just that
[05:30] <desrt> indeed
[05:30] <pitti> build an empty deb with that Depends:, installs it and apt-get -f install
[05:31] <desrt> i meant to say: i intend to follow your suggestion
[05:31] <pitti> TTBOMK there is no other way of saying "dear apt, please install that dependency string"
[05:31] <pitti> I've long wanted "apt-get install foo.deb" :)
[05:32] <desrt> gdebi!
[05:32] <desrt> 'apt install foo.deb' would probably be a security problem
[05:33] <desrt> for all the people who have 'apt-get install' in their sudoers file :)
[05:56] <desrt> pitti: seems that it's also relatively possible to drive apt's python interface in the same way that gdebi does in order to get the job done
[05:58] <pitti> desrt: I find it nice to install a set of given packages
[05:58] <pitti> desrt: did you find a way to parse/resolve a dependency string?
[05:58] <desrt> there is a function called satisfy_depends_str() on apt.debfile.DebPackage
[05:58] <pitti> oh, that sounds promising
[05:59] <desrt> i'm not totally sure about that
[05:59] <desrt> you need to have the package existing first, which is a bit annoying
[06:00] <desrt> okay... so it seems that you can do approximately this:
[06:00] <desrt> c = apt.cache.Cache()
[06:01] <desrt> dp = apt.debfile.DebPackage(cache = c)
[06:01] <desrt> dp.satisfy_depends_str('...')
[06:01] <desrt> dp.check()
[06:01] <desrt> print dp.required_changes
[06:04] <didrocks> good morning
[06:04] <desrt> didrocks: hihi
[06:04] <desrt> how was your weekend?
[06:04] <pitti> bonjour didrocks
[06:06] <didrocks> hey desrt, pitti!
[06:07] <didrocks> desrt: week-end was good, but could have been a little bit longer TBH :) how about you?
[06:07] <desrt> same.  got a lot of interesting things done :)
[06:08] <didrocks> kdus-wise?
[06:08] <desrt> nah... went to see knights fighting each other with swords and helped a friend move to his new place in toronto
[06:09] <desrt> but also got some stuff done with jhbuild and started to learn how to drive apt from python to solve dependencies...
[06:10] <didrocks> ahah, nice! seems you start being a python fan :)
[06:10] <didrocks> the apt bindings in python are quite nice
[06:10] <desrt> i've been a python fan for years
[06:10] <desrt> just now i start to be a real python programmer :)
[06:11] <didrocks> heh
[06:18] <desrt> pitti: http://fpaste.org/171275/64833914/
[06:18] <desrt> so there you have it
[06:19] <desrt> obviously not the intended use of this API, but it gets the job done
[06:20] <didrocks> pitti: seems I was quite right with the * matching issue with the local bridge under systemd
[06:23] <desrt> and if you step away from the idea that the format of the Depends: line in a control file is anything special proably you can avoid the DebPackage interface entirely and just reimplement what it is doing internally
[06:23] <larsu> good morning!
[06:23] <desrt> larsu: good morning
[06:24] <larsu> desrt: good late-evening ;)
[06:24] <desrt> ya ya... just about to go to sleep :)
[06:31] <didrocks> good morning larsu :)
[06:31] <larsu> hi didrocks, again ;)
[06:53] <pitti> desrt: ah, what is an example of required_changes? you somehow need to translate this into apt.Cache()[pkg].mark_install() calls, right?
[06:53] <pitti> didrocks: i. e. you can't match globs, we need to match precise values?
[07:01] <didrocks> pitti: yeah, so if we create an android-property@foo,bar.target, we can't then WantedBy=android-property@*foo*.target in another unit for instance
[07:01] <didrocks> so it means that we will multiply units for values where they can be lists
[07:06] <seb128> good morning desktopers
[07:06] <seb128> hey didrocks larsu pitti
[07:06] <pitti> bonjour seb128 !
[07:06]  * pitti → doctor appointment, TTYL
[07:06] <mlankhorst>  morning
[07:06] <seb128> hey mlankhorst
[07:07] <didrocks> re seb128
[07:07] <seb128> re ;-)
[07:07] <didrocks> hey mlankhorst
[07:23] <mlankhorst> bonjour!
[07:42] <maclin> Hi,  Ubuntu Installer Team,  could someone help to review the merge request: https://code.launchpad.net/~maclin.jun/ubiquity/fix_1304410/+merge/246064
[07:54] <ochosi> morning everyone
[07:55] <ochosi> seb128: may i quickly bug you about the second xdg-utils MR (that i mentioned previously would come at some point) ?
[07:57] <seb128> ochosi, hey, sure
[07:57] <seb128> maclin, hi, you are on the desktop channel, you might rather want to try #ubuntu-devel for installer reviews
[07:58] <ochosi> seb128: so, we've figured out support for light-locker (actually the proper dbus inhibition is totally broken in xdg-utils, so we'll have to go the X11 way for now), here's the MR (which applies on top of my previous MR): https://code.launchpad.net/~thad-fisch/ubuntu/vivid/xdg-utils/lp1363540/+merge/246820
[07:58] <ochosi> sorry for the mess, the .pc dir seems to have been part of the package already
[07:58] <ochosi> i can clean that up though if you want
[07:59] <seb128> ochosi, ok, great, good job figuring it out
[07:59] <seb128> not your fault
[07:59] <seb128> the .pc thing is a known issue with the source import workflow
[07:59] <ochosi> oh ok
[08:00] <maclin> seb128, got it ,thanks:)
[08:01] <ochosi> seb128: oh, also: that patch has been submitted upstream >1 week ago, but since we didn't get any reply and direly need it in xubuntu (it's tested and works), i hoped we could push it into ubuntu first
[08:01] <seb128> yeah, no problem
[08:02] <ochosi> if there's anything else i can do to help move this along, ping me anytime!
[08:03] <seb128> seems things just need sponsoring, we should be fine
[08:03] <seb128> thanks for working on that ;-)
[08:03] <ochosi> cool! well thank you for always supporting me/us here
[08:03] <seb128> oh, dholbach is piloting today and didrocks tomorrow, so I guess we should see some action on the sponsoring queue ;-)
[08:05] <ochosi> nice :)
[08:07] <ochosi> seb128: another quick question: how are the chances we could SRU this to trusty? the same (annoying) bug exists there and it'd be nice to give our LTS users some love
[08:07] <seb128> ochosi, those changes seem fine to SRU
[08:07] <ochosi> great!
[08:07] <seb128> ochosi, somebody should make the bug SRU compliant though (impact/test case/regression potential)
[08:08] <ochosi> i'll wait for it to get pushed to vivid and then prep the SRU paperwork
[08:08] <ochosi> or would it be better to do everything in one go?
[08:09] <seb128> waiting is fine
[08:09] <seb128> the fix needs to go in vivid first and it's always good to have some testing before SRUing
[08:10] <ochosi> yeah, thought so
[08:10] <darkxst> hey seb128
[08:11] <darkxst> is anyone working on gedit update? I vaguely remember some screenshots being shown around?
[08:24] <seb128> hey darkxst
[08:24] <seb128> https://code.launchpad.net/~ari-tczew/gedit/ubuntu/+merge/246239
[08:24] <seb128> I didn't try it, but I think somebody needs to patch it to use wm decorations under !GNOME
[08:30] <darkxst> seb128, I could probably patch it to do that, but I sure I saw screenshots of gedit with the osx UI?
[08:30] <darkxst> a while back
[08:31] <seb128> yeah, they have support for that
[08:31] <seb128> but we might need to add a configure option
[08:32] <seb128> also their is probably buildtime and not runtime
[08:49] <mlankhorst> well xmir rotation sort of works now, at least 180°, having some trouble with 90 and 270 :P
[08:52] <darkxst> seb128,  the currently the only way to get osx ui pulls in lots of !linux stuff as well and yes its build time only
[08:52] <willcooke> morning all
[08:54] <seb128> darkxst, upstream said they would be happy to take a patch for the unity case though
[08:54] <seb128> hey willcooke
[08:54] <mlankhorst> hm or maybe I'm thinking too hard
[09:01] <darkxst> seb128, I'm not volunteering to write the patch, still need to get to totem menu patch! was just asking since someone posted a screenshot on here a while back
[09:01] <darkxst> Laney ^?
[09:03] <darkxst> seb128, and I mean the osx UI patch there, a patch to use traditional titlebars with GNOME UI would only take me 10mins
[09:04] <darkxst> so I could do the latter
[09:07] <Laney> morning
[09:08] <darkxst> hey Laney
[09:19] <Laney> hi darkxst, what's up?
[09:19] <Laney> who looked at gedit/osx?
[09:20] <darkxst> Laney, I have no idea! I saw a screenshot on here a while back with the old UI
[09:20] <Laney> doesn't look like it's as simple as using that
[09:20] <darkxst> Laney, I know its not that simple
[09:22] <mlankhorst> willcooke: Ok I think I have rotation working :P
[09:22] <darkxst> the osx builds bring in a lot of !linux stuff
[09:25] <seb128> hey Laney, had a good w.e ?
[09:29] <willcooke> mlankhorst, amazing!  Thanks
[09:30]  * darkxst has to go do some plastering, seems the gedit mystery shall remain unsolved 
[09:30] <mlankhorst> just a second
[09:31] <mlankhorst> willcooke: https://mblankhorst.nl/etc/Xmir
[09:31] <willcooke> mlankhorst, thx will download and test
[09:32] <Laney> not bad thanks seb128, did some painting downstairs, getting there now ;-)
[09:33] <Laney> darkxst: I'll look, be calm young one
[09:33] <willcooke> I found a cool "bug" over the weekend.  Gears for example has a transparent background in the switcher so you can see through it when moving between running apps.  It's looks sweet :D
[09:33] <darkxst> Laney, pretty sure you are the young one ;)
[09:34] <darkxst> and Jackson is the really young one!
[09:35] <Laney> I'm telling my dad on you
[09:35] <mlankhorst> or are you?!
[09:37] <darkxst> Laney, sure go ahead! I'm pretty safe down here in Aus!
[09:38] <Laney> heh
[09:39] <darkxst> might need to rename Ubuntu GNOME to Ubuntu Australia though
[09:39] <mlankhorst> willcooke: input's going to be a bit weird though
[09:39] <mlankhorst> it's currently not rotating input
[09:39] <willcooke> mlankhorst,  understood
[10:25] <mlankhorst> looks like input will still stay a todo for now.. no support yet for enumerating devices
[10:31] <willcooke> mlankhorst, a topic for the sprint :D
[10:31]  * willcooke adds it to the list
[10:37] <didrocks> FJKong: hey! do you have the list of dependency for your project somewhere? That will help speeding up without looking at your long makefile :)
[10:38] <FJKong> no
[10:38] <FJKong> didrocks: is there any wrong with compiling?
[10:38] <didrocks> FJKong: I have some missing modules it seems
[10:38] <didrocks> $ /usr/lib/x86_64-linux-gnu/qt5/bin/qmake
[10:38] <FJKong> qmake -o Makefile demo.pro
[10:38] <didrocks> Project ERROR: Unknown module(s) in QT: declarative
[10:39] <didrocks> seems that qmake, even without any argument don't find the declarative module
[10:39] <FJKong> oh maybe you need sudo apt-install xxx-dev
[10:39] <didrocks> that is obviously installed :/
[10:39] <FJKong> i remember I installed some dev lib
[10:40] <didrocks> well, qtdeclarative5-dev for sure
[10:40] <FJKong> I use qt4 I think
[10:41] <didrocks> oh?
[10:41]  * didrocks looks
[10:41] <didrocks> well, even qmake alone is using the qt5 version
[10:41] <didrocks> but ok, I'll try with the qt4 version
[10:42] <didrocks> FJKong: right, you are using qt4, qml is not supported with it anymore FYI
[10:43] <didrocks> hum, qmake-qt4 -o Makefile demo.pro -> exit 0, no binary built :/
[10:43] <didrocks> ah, makefile is refreshed
[10:43] <didrocks> ok, compiling
[10:44] <didrocks> FJKong: where are you getting a segfault? It launches here, but I don't have any input method installed
[10:44] <didrocks> ah, on exit :p
[10:44] <FJKong> just close it
[10:44] <didrocks> yeah, ok, good, I can reproduce!
[10:45] <didrocks> FJKong: will keep you posted
[10:45] <FJKong> no  it jsut a demo
[10:45] <didrocks> but if you want to go on with that project, really go on qt5, we are not going to install qt4 by default
[10:45] <didrocks> yeah, looking at why it's segfaulting
[10:48]  * didrocks found the line of the segfault, let's see why this delete makes it fail…
[10:59] <didrocks> FJKong: found it!
[10:59] <FJKong> oh
[10:59] <didrocks> let me see if it's the same in qt4 documentation first
[10:59] <FJKong> great
[11:00] <didrocks> yeah, so:
[11:00] <didrocks> short answer: remove "delete mImageProvider;" in MainController::~MainController()
[11:01] <didrocks> the reason is you are freeing an object that is already freed
[11:01] <didrocks> if you read the addImageProvider() documentation, it's written:
[11:01] <didrocks> "The QDeclarativeEngine takes ownership of provider."
[11:01] <didrocks> (http://qt-project.org/doc/qt-4.8/qdeclarativeengine.html#addImageProvider)
[11:01] <didrocks> same in qt5 btw
[11:02] <didrocks> so, when you call removeImageProvider, it frees it
[11:02] <didrocks> and then, if you call delete on it, well… segfault :)
[11:02] <didrocks> FJKong: making sense?
[11:03] <FJKong> so add and remove need all in that class?
[11:04] <didrocks> FJKong: sorry, not sure I'm getting you
[11:04] <didrocks> just to rephrase what I told:
[11:05] <didrocks> when you run engine->addImageProvider("foo", mImageProvider);
[11:05] <didrocks> then, engine is taking ownership of mImageProvider
[11:05] <didrocks> meaning that when you run:
[11:05] <didrocks> engine->removeImageProvider("foo)
[11:05] <didrocks> engine->removeImageProvider("foo")
[11:05] <didrocks> this is calling for you: delete mImageProvider;
[11:06] <didrocks> so, you don't need (and shouldn't) try on your own to free mImageProvider, it has already been freed for you
[11:07] <FJKong> ok I see
[11:07] <didrocks> tbh, the removeImageProvider could have said that explicitely
[11:07] <didrocks> (the documentation)
[11:10] <FJKong> I have a question: if I need new another provider in MainController class how can I release previous one?
[11:11] <didrocks> FJKong: you remove the first one and add the new one
[11:11] <didrocks> so engine->removeImageProvider("foo")
[11:11] <didrocks> ngine->addImageProvider("foo", mNewImageProvider);
[11:11] <didrocks> e*
[11:12] <didrocks> you can even reuse mImageProvider, as the object is owned by the engine
[11:12] <didrocks> so:
[11:12] <didrocks> engine->removeImageProvider("foo")
[11:12] <FJKong> this part is right
[11:12] <didrocks> mImageProvider = new ResourceImageProvider(QDeclarativeImageProvider::Image);
[11:12] <didrocks> engine->addImageProvider("foo", mImageProvider);
[11:12] <didrocks> and that's it :)
[11:13] <FJKong> hmm
[11:15] <FJKong> the operation new XXX is only once and reuse it later?
[11:19] <didrocks> FJKong: no, you need to create a new one
[11:19] <didrocks> as with my last snippet
[11:20] <FJKong> I use it like what you said
[11:20] <didrocks> as the first one will be freed with removeImageProvider()
[11:20] <didrocks> and recreate a second one?
[11:20] <FJKong> ye
[11:20] <didrocks> good :) everything makes sense?
[11:21] <FJKong> maybe increasing memory is in somewhere else not here
[11:21] <FJKong> yes this is helpful to me
[11:21] <didrocks> good, do not hesitate if you still have any question or something you don't understand :)
[11:22] <didrocks> (you don't increase memory here, as the first object is freed automatically by removeImageProvider())
[11:22] <FJKong> didrocks: nice man + 1024
[11:22] <FJKong> thanks
[11:23] <didrocks> heh, yw! :)
[12:31] <didrocks> hum, seems that Debug: doesn't work in plymouth themes :/
[12:33] <didrocks> tseliot: hey! any trick that you can remember about plymouth themes and debug? I try to Debug("foo"); a command; Debug("bar"). the command is run (like changing opacity) so this code is executed in the ubuntu script
[12:33] <didrocks> tseliot: I tried to add plymouth:debug in --kernel-command-line=, --debug + --debug-file=/tmp/plymouth-debug-out, but no debug info from the theme
[12:36] <tseliot> didrocks: So you can see the "foo" and "bar" lines but you need more information?
[12:38] <didrocks> tseliot: on the contrary, I can't see them
[12:38] <didrocks> neither on the output (with --no-daemon)
[12:38] <didrocks> or in /tmp/plymouth-debug-out
[12:40] <tseliot> didrocks: they are supposed to show up in the bootsplash. You can try DebugMedium() and DebugBottom(), just in case Debug() is writing outside of the visible area
[12:42] <didrocks> tseliot: ah, it's in the splash, not in any debug info, ok, will try other Debug() facilities
[12:42] <tseliot> didrocks: yep
[12:43] <didrocks> tseliot: ok, seeing it now, thanks!
[12:43] <tseliot> didrocks: yw
[13:12]  * didrocks communicates successfully the progress of multiple fsck running in parallel to plymouth through fsckd \o/
[13:12] <didrocks> need to tweak the theme to support that well :)
[13:45] <desrt> pitti: DebPackage is calling mark_install() on the cache
[13:52] <desrt> it all seems a bit impure, to be honest
[13:53] <desrt> unless this is the same algorithm that apt is using internally as well
[13:53] <desrt> but i'm pretty sure that in 'normal apt' Depends: lines are not solved by a python script...
[13:53] <dholbach> hiya
[13:54] <dholbach> for some reason I can't log into unity8 on vivid
[13:54] <dholbach> on lightdm, I choose unity8-mir
[13:54] <dholbach> then I get another login screen
[13:54] <dholbach> where I type my password and it tells me that the password is wrong
[13:54] <dholbach> is this a known issue?
[13:55] <dholbach> seb128, ^ do you know?
[13:56] <seb128> dholbach, that second screen is in qwerty layout most likely, even if your system use e.g qwertzu or whatever .de is
[13:57] <dholbach> qwertz, yes
[13:57] <dholbach> but "German keyboard" was selected in the indicator
[13:57] <seb128> try assuming it's qwerty and type your password on that
[13:57] <seb128> right
[13:57] <seb128> but that's the greeter
[13:57] <seb128> then you get the unity8 lock
[13:57] <seb128> and unity8 doesn't respect the indicator it seems
[13:58] <dholbach> larsu, ^ fix it!
[13:58] <seb128> lol
[13:58] <dholbach> :-P
[13:58] <seb128> dholbach, try and let me know if that works
[13:58] <dholbach> ok, brb
[13:59]  * larsu hides
[14:01] <seb128> larsu, is Daniel in Berlin atm? ;-)
[14:01] <larsu> seb128: no sure. He was an hour ago when I had lunch with him ;)
[14:02] <seb128> haha
[14:02] <didrocks> larsu: don't answer, then, he will trick daniel into harassing you about that bug :)
[14:02] <didrocks> fatal error! :)
[14:02] <larsu> uh oh
[14:02] <seb128> lol, no, larsu has enough to do with gtk & bluetooth indicator/settings work
[14:02] <larsu> \o/
[14:02] <seb128> I was just checking how practical it is for him to hide :p
[14:03] <didrocks> with some creamy css on top of it!
[14:03] <seb128> I hear that didrocks likes web tech and that includes css
[14:03] <seb128> we should maybe reassign that from larsu to didrocks ;-)
[14:04] <didrocks> can we use sass? I'm not that crazy to use bare css without webcomponent and not having any structure :p
[14:04] <dholbach> ok, that worked
[14:04] <dholbach> why do we need two greeters? :)
[14:04] <dholbach> is there a bug open for it?
[14:04] <larsu> didrocks: adwaita uses sass, actually
[14:05] <didrocks> larsu: really? nice! but not our theme I guess?
[14:05] <seb128> dholbach, we don't need 2 greeters, it just happens that the split greeter has issues for the phone usecase and that they implemented in session greeter for v1
[14:06] <seb128> dholbach, but they don't provide a way for lightdm to start the session unlocked
[14:06] <seb128> dholbach, there is a blueprint or bug about it I think, let me check
[14:07] <larsu> didrocks: no. Nobody properly maintains it (I make some changes every now and then to unbreak things)
[14:07] <dholbach> ok, once I can launch gnome-terminal and gnome-xchat from unity8 I might actually try to use it for a day or something :-P
[14:07] <ochosi> larsu, didrocks: knock yourselves out, but porting a theme to SASS basically means rewriting/recreating it... i'm working on that for our (xubuntu) theme, but it's a lot of work initially. hopefully it'll pay off by being easier to maintain/sync with adwaita
[14:07] <didrocks> larsu: interesting, you almost tempted me!
[14:08] <didrocks> ochosi: right, it's quite some work to port to scss, but at least, it's maintainable (theorically)
[14:08] <seb128> dholbach, https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1360307
[14:08] <dholbach> thanks seb128!
[14:08] <seb128> dholbach, yw!
[14:09] <larsu> didrocks: I'm up for it myself as well, but I'm not sure it's worth it until we get a theme refresh from design
[14:09] <larsu> didrocks: I'll let you know when that happens if you want to help out
[14:09] <larsu> (lol)
[14:10] <didrocks> larsu: yeah, I'm in the same undecision about the ubuntu theme
[14:10] <didrocks> (in plymouth)
[14:10] <didrocks> the logo theme would need some cleanup, some features were removed, but code is still there
[14:11] <didrocks> but well, why rewriting without a theme refresh…
[14:11] <didrocks> and will plymouth will still be what's showing up at boot? unsure :)
[14:12] <larsu> right
[14:12] <larsu> I've been thinking of using some assets from the phone (the spinner for example)
[14:12] <larsu> but I'm unsure if we want to just update the design here and there, without a full vision
[14:13] <didrocks> yeah…
[14:21] <seb128> Laney, I saw you just commented on some poppler bug, are you looking at updating to poppler 0.30 (I just noticed the new version was available, I can do the update if you are not on it)
[14:36] <desrt> today's amazing footage: https://www.youtube.com/watch?v=Dwe10pbVPDQ
[14:37] <desrt> along with one of the most hilarious tweets of all time -- https://twitter.com/elonmusk/status/555981841476227072/photo/1
[14:37] <desrt> "rapid unscheduled disassembly"
[14:39] <desrt> not a bad euphemism for "our $50mil piece of equipment violently exploded"
[15:20] <pitti> didrocks: hah, was that the recent attempt to land the rocket on a ship for re-use?
[15:20] <pitti> err, desrt
[15:20] <pitti> desrt: I read about that maybe a week or so ago; not at all bad to hit the ship in the first place :)
[15:21] <desrt> pitti: they released the video just today, i think
[15:21] <pitti> yeah, it's quite obviously that one
[17:14] <seb128> hum
[17:14] <seb128> so it seems the battery usage issues/lack of sleep on touch/rtm is due to the upower transition
[17:15] <seb128> oh, no kenvandine today, u.s holiday ftw for him it seems ;-)
[17:21] <Laney> weird
[17:21] <Laney> does it happen on vivid too?
[17:21] <Laney> why would that be?
[17:22] <seb128> dunno,cking bisected the touch images and found that
[17:34] <cking> that's my current hypothesis, bisecting this device and measuring it in deep suspend is proving to be time consuming and non-trivial
[17:35] <seb128> cking, are you off by one image btw? because the upower change happened on 176 not 177
[17:36] <seb128> cking, http://people.canonical.com/~lzemczak/landing-team/ubuntu-rtm/176.commitlog
[17:38] <pmcgowan> cking, was just commenting the same, we backported upower to silence some dbus events
[17:39] <seb128> the upower transition is quite some code changes though, so there could be side effects
[17:40] <cking> perhaps if I was to try with the older upower and see if that makes the device deep suspend more reliably ~176-ish  seems to be more flakey than earlier revisions
[17:40] <cking> wrt going into deep suspend
[17:43] <pmcgowan> cking, bet youa re on to something, this was the bug that brought it in https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings/+bug/1337200
[17:44] <cking> pmcgowan, it maybe, as it stands, I've heard a pop sound and I can't power on the phone. I've had this before, I need to see what's going wrong
[17:45] <pmcgowan> oh my
[17:45] <cking> i have a spare, don't panic :-)
[17:45] <rsalveti> pop sound was usually related with kernel crash
[17:45] <rsalveti> when handling the sound buffer
[17:45] <cking> yeah, but with blue smoke too?
[17:46] <pmcgowan> oh my again
[17:46] <pmcgowan> software stuff is dangerous
[17:46] <rsalveti> no, that would be news :-)
[17:47] <pmcgowan> rsalveti, we had a new device tarball in 175 fwiw
[17:48] <rsalveti> what are the changes for it?
[17:48] <pmcgowan> http://people.canonical.com/~jhm/barajas/ubuntu-rtm-14.09/device_krillin-20141209-cae2b5f.changes
[17:49] <pmcgowan> oh wait there is more
[17:49] <pmcgowan> http://people.canonical.com/~jhm/barajas/ubuntu-rtm-14.09/device_krillin-20141209-0145438.changes
[17:49] <pmcgowan> http://people.canonical.com/~jhm/barajas/ubuntu-rtm-14.09/device_krillin-20141202-d15a67a.changes
[17:49] <rsalveti> from what I see nothing that could really affect this
[17:49] <pmcgowan> nope
[17:50] <cking> phone resurrected \o/
[17:51] <cking> so it may be sporadic issue like suspend works well and sometimes it does not, so bisecting it can be problematic
[17:52] <cking> if you see my test rig you will understand it's not just a software problem
[18:10] <Laney> darkxst: I'm uploading the a-i-t split, you probably want to switch your seeds to a-i-t-full
[19:03] <darkxst> Laney, ok
[23:32] <robert_ancell> TheMuso`, should the screenreader keybinding in trusty be fixed on the login screen (bug 1407865)?
[23:32] <robert_ancell> We fixed it in utopic