[13:34] <ironfisher> hello!
[13:35] <ironfisher> I am translatig the new Nautilus elementary into spanish
[13:35] <ironfisher> How can I translate "clutter view"? It seems to be similar to the cover flow view by MacOS
[13:36] <ironfisher> The translation of the word "clutter" does not look good for this kind of view in spanish
[13:37] <ironfisher> Could you tell me another way to call it in english?


[01:41] <Ubugtu> New bug: #62547 in linux-restricted-modules-2.6.17 (restricted) "no dri cannot init AGP  in 2.6.17-10 AMD64" [High,Fix committed]  http://launchpad.net/bugs/62547
[05:20] <Ubugtu> New bug: #64276 in xorg "Beryl crashes X on starting" [Undecided,Unconfirmed]  http://launchpad.net/bugs/64276
[10:53] <Ubugtu> New bug: #64174 in xserver-xorg-video-ati (main) "GUI doesn't appear on startup, ATI X300 not recognised?" [Undecided,Needs info]  http://launchpad.net/bugs/64174
[11:30] <Ubugtu> New bug: #64304 in xserver-xorg-input-synaptics "ButtonReleased events for left mouse-button not being sent properly to X" [Undecided,Unconfirmed]  http://launchpad.net/bugs/64304
[02:00] <Ubugtu> New bug: #64331 in linux-restricted-modules-2.6.17 "crashing xorg.  unstable behaviour" [Undecided,Unconfirmed]  http://launchpad.net/bugs/64331
[11:20] <Ubugtu> New bug: #64431 in mesa "audio output of SigmaTel* STAC9271 is too silent" [Undecided,Unconfirmed]  http://launchpad.net/bugs/64431


[00:58] <cjwatson> LaserJock: we already have a way to launch the installer without going into the desktop, even though it's hidden. Boot with the 'only-ubiquity' boot option
[00:59] <LaserJock> cjwatson: what does that do?
[00:59] <LaserJock> I remember there being discussion about it
[00:59] <cjwatson> wasabi: you can argue against a text-based UI for ubiquity if you like, but it's mostly already done ...
[00:59] <LaserJock> does it start X and then run ubiquity without any WM?
[00:59] <cjwatson> LaserJock: starts X, metacity, gnome-settings-daemon, and ubiquity
[01:00] <LaserJock> ah, so you still have metacity
[01:00] <cjwatson> it needs a WM, but not the full desktop furniture
[01:00] <LaserJock> right
[01:00] <cjwatson> ubiquity uses dialog boxes - you can't do that without a WM
[01:00] <LaserJock> right
[01:00] <LaserJock> what does that do for the RAM requirements?
[01:00] <wasabi> cjwatson: What are the plans regarding d-i?
[01:00] <wasabi> I'd be very sore if d-i vanished.
[01:00] <cjwatson> wasabi: data.tar.gz can't achieve the same level of compression as squashfs because the blocks can't possibly be as big: squashfs blocks can span multiple packages
[01:00] <cjwatson> wasabi: d-i isn't going away, don't worry
[01:01] <cjwatson> LaserJock: knocks a good chunk off, but I don't have the numbers to hand
[01:01] <cjwatson> we may well switch to that by default in hardy
[01:03] <cjwatson> and the d-i X frontend has never been good enough for my satisfaction, which is why we don't build or ship it
[01:03] <cjwatson> (though I put a lot of work into it myself in the early days)
[01:03] <wasabi> Yeah, I remember that.
[01:03] <StevenK> cjwatson: What's lacking that doesn't make it good enough?
[01:04] <cjwatson> StevenK: plugins for all the complex UI
[01:04] <cjwatson> like the partitioner
[01:04] <StevenK> Oh, right. It's in X, but still uses the horrible menu partitioner. Ew.
[01:04] <cjwatson> the facilities are there (er, mostly; there's still a little bit of libd-i and anna work that needs to be done), but nobody's sat down and written code to make it better than the generated UI
[01:04] <wasabi> That's generally something which is simply lacking mostly in debconf
[01:04] <cjwatson> wasabi: no
[01:04] <wasabi> Good integration with task specific UI
[01:04] <cjwatson> that's simply not true
[01:04] <wasabi> Oh
[01:05] <wasabi> ?
[01:05] <cjwatson> cdebconf supports plugins
[01:05] <cjwatson> I wrote the code
[01:05] <wasabi> plugins for specific UI modules for specific toolkits?
[01:05] <cjwatson> yes
[01:05] <wasabi> Huh. So what is lacking in it then?
[01:05] <cjwatson> somebody actually writing the plugins
[01:05] <wasabi> Why the push for ubiquity instead of that?
[01:05] <wasabi> Simply because of the LiveCD requirements?
[01:06] <cjwatson> partly that it was much harder to do the plugins in d-i than the way ubiquity does it, and partly because we needed to be able to ship an installable live CD for other reasons
[01:06] <cjwatson> being able to ship just a live CD instead of install+live cuts Canonical's shipit costs down to a third of what they were ...
[01:07] <cjwatson> and there was the speed thing too
[01:07] <wasabi> Yeah.
[01:07] <wasabi> So, wonder if there could be an optimization in d-i to use preexisting package source instead of actually doing the work? :)
[01:07] <cjwatson> "preexisting package source"?
[01:07] <wasabi> "oh, you're trying to install foo.deb, how about I just grab these files from /, put them in the right place, and pretend you did install foo.deb"
[01:08] <cjwatson> somebody wrote a live-installer udeb for d-i in Debian
[01:08] <wasabi> What I like about d-i is the ability for me to build my own pieces in it. I do it for large installations.
[01:08] <wasabi> Custom installers for different organizations, that integrate their own UI pieces, and/or apt soruces and package lists.
[01:08] <cjwatson> it doesn't really belong at the level of installing individual .debs though; you won't get a meaningful speedup out of that
[01:08] <wasabi> Usually netbooted, etc.
[01:09] <cjwatson> sure, that's a large chunk of the reason we support d-i
[01:09] <cjwatson> ubiquity's a great desktop installer but I don't expect it ever to be customisable on the fly to the same extent
[01:10] <cjwatson> effort on converting more packages over to triggers would be appreciated
[01:10] <cjwatson> a lot of that will be fixed in Debian as soon as triggers get merged there
[01:10] <cjwatson> Joey is champing at the bit to delete huge wodges of debhelper
[01:12] <StevenK> I can't wait for texlive to get trigger support. That would make upgrades even faster.
[01:12] <cjwatson> I will probably slow them down a bit again with man-db ;-)
[01:13]  * StevenK chuckles
[01:13] <cjwatson> (but doing so fixes an ancient bug so I think it's worthwhile)
[01:13] <StevenK> That's the manual pages encoding one, right?
[01:13] <ion_> Also enhancing linux-images’ trigger support would be nice.
[01:13] <cjwatson> StevenK: no, having the database updated automatically after package installation so that apropos and whatis work immediately
[01:14] <StevenK> Ahh
[01:14] <cjwatson> encoding is nearly all fixed now
[01:14]  * StevenK notices the time and runs off to lunch with his sister in law
[01:14] <cjwatson> modulo a few bugs (fixed upstream) you can use UTF-8 manual pages
[01:14] <cjwatson> need to get the exact layout agreed though
[01:15]  * cjwatson -> bed
[01:15] <ion_> Btw, the version of openssl in gutsy-{security,updates} is greater than the version in hardy.
[05:16] <emgent> heya
[10:23] <beewee> Can anybode tell me whether the browsers in K/Xubuntu send K/Xubuntu or just "Ubuntu" inside the HTTP_USER_AGENT? Nobdody in #ubuntu and #ubuntu-de was able to answer this :/
[10:23] <beewee> *anybody
[10:26] <persia> beewee: I don't know offhand, but I suspect you'll do well to either check the source or with https://answers.launchpad.net/ubuntu/
[10:36] <beewee> ok, I created a question in launchpad
[10:37] <persia> beewee: Thanks.  Sometimes it takes a while to get a response, but that's the best escalation point when #ubuntu doesn't know.  Frequently the developers don't know offhand either, and are working on other things.
[10:40] <beewee> ok :)
[12:54] <shodges> hey, does anyone know of good documentation for packaging a *new* project? The packaging guide on the wiki seems to imply that you are repackaging an existing project...?
[12:57] <IntuitiveNipple> lol yeah, it is a bit mean like that isn't it!
[12:57] <persia> shodges: How do you mean a "New" project?
[12:58] <shodges> well, i'd like to build a deb package for a project i've been working on, but instead of using checkinstall i want to do it properly, so i learn how to package at the same time
[12:58] <IntuitiveNipple> There's one in the 6.10 Wiki, showing how to create a package from scratch, based on simple 'hello' example: https://help.ubuntu.com/6.10/ubuntu/packagingguide/C/basic-scratch.html
[12:59] <persia> IntuitiveNipple: That's a good resource, but it's a little out of date.
[13:00] <persia> shodges: https://wiki.ubuntu.com/PackagingGuide/Basic tries to cover new packaging.  Is there something else you think is missing there?
[13:00] <IntuitiveNipple> persia: no kidding... trying to find anything was hard though, so have to make do
[13:01] <shodges> IntuitiveNipple, persia, thanks i've got that guide in front of me at the moment. The problem i'm having is it seems to imply i want to "apt-source" my project from the repos, but its not there because i made it from scratch
[13:02] <persia> shodges: Aha!  Thanks for pointing that out.  I'll update the docs to be more clear.  If you have a tar.gz, and you rename it to an .orig.tar.gz, you can proceed: the apt-get source hello is only to grab an example.
[13:03] <IntuitiveNipple> Yes, that was my issue when I started with packaging. It all assumes someone else created the code
[13:03] <IntuitiveNipple> It would be good to have a link-out to actually creating a new package from original source-code
[13:04] <persia> IntuitiveNipple: Do you mean including instructions on how to generate an orig.tar.gz from a source tree?
[13:04] <IntuitiveNipple> I wanted to know things like, best-practice in naming directories, common directories to use ( for things like po, etc.,)
[13:04] <shodges> ah ok, i'll give that a try, thanks. just for clarification, i should tar up my code and rename it to *.orig.tar.gz, in the same dir structure that the guide instructs?
[13:05] <IntuitiveNipple> persia: If that requires more than just a simply tar -cxf package.tar.gx ./package-1.0   then yes
[13:06] <IntuitiveNipple> I wanted to create a project template directory I could use as the basis for creating a new ubuntu/debian packages at will... that'd be cool
[13:06] <persia> IntuitiveNipple: That's about it.  I tend to prefer 'tar czf mypackage_1.0.orig.tar.gz ./mypackage-1.0`. :)
[13:06] <IntuitiveNipple> so it'd have the debian/ directory and templates of control changelog and all other required files ready to go
[13:07] <IntuitiveNipple> Spelling it all out is the important thing, because so much of existing docs assumes you understand the nuances of packaging in many ways.
[13:07] <IntuitiveNipple> like the po issue I had, for example.
[13:07] <persia> IntuitiveNipple: There's a package called dh-make that includes templates for most things.
[13:07] <IntuitiveNipple> ahhh see? nuance!
[13:08] <shodges> IntuitiveNipple, persia, i used dh-make to build my template debian dir, glad to hear i'm not going in the wrong direction :)
[13:08] <persia> shodges: You'll want to wrap your code so that the tarball expands with a single top-level directory, and calling the build rules from that directory builds the software.
[13:09] <persia> shodges: You will want to not put debian/ in your orig.tar.gz, to make things easier if the software later also gets distributed in other distributions.
[13:09] <shodges> ok, makes sense
[13:10] <persia> IntuitiveNipple: If you have more suggestions for dh-make, I'd recommend submitting patches.  The more that can be easy to learn, the better.
[13:10] <IntuitiveNipple> I seem to recall using dh_make for the debian bits.
[13:10] <IntuitiveNipple> persia: My main issue was just lack of clear documentation on creating a brand new source project and packaging.
[13:11] <persia> IntuitiveNipple: Hrm.  The lack of documentation on making a brand new project (which would later be packaged) seems separable to me, but it would be nice to have something.  I'm adding the bit about generating an orig.tar.gz from scratch to the packaging guide now.
[13:12] <IntuitiveNipple> Thanks.
[13:12] <persia> IntuitiveNipple: I've never actually created a project from scratch: I don't suppose you'd be willing to author a first draft for that document?
[13:13] <IntuitiveNipple> Yes, a separate recommendation on best-practice in creating a new software project that will not cause issues with debian packaging later, along with the pros and cons of the various patch-management systems, would be ideal
[13:14] <persia> Just basic things like supporting a variable to tell it where to install (for /usr vs. /usr/local), and putting everything in a source tree, and not including debian/, and copyright/licensing for everything, and source for everything, etc.
[13:15] <IntuitiveNipple> persia: I could try, but I'm not sure myself, thats part of the problem! For internationalisation there's all the po stuff. I'm still trying to understand that. Then there's gnome-specific stuff like the glade file (where best to put it/them), having a ./src/ directory, when to use a separate ./include/ directory. How to integrate with what autoconf requires!
[13:15] <persia> IntuitiveNipple: Right,  It's lots of stuff.  I'd suggest putting a big WIP on the top of the page, but if you can get enough started that others contribute, soon we'll have a good reference.
[13:16] <IntuitiveNipple> I end up actually not bothering to package my stuff because I end up wasting time trying to get the packaging sorted out
[13:16] <IntuitiveNipple> I've been flowcharting the entire process, including every patch system, in order to understand it
[13:17] <persia> IntuitiveNipple: That seems a bit extreme.  There's so many different ways to package, that trying to map it all is a huge effort.  Personally, I tend to focus on the couple I know well, and only learn more when I'm working on a package that requires it.
[13:19] <IntuitiveNipple> Well, I'm writing an automated packaging tool for myself so when I'm bug-hunting, actually providing the fixed package debdiff becomes trivial! You saw what happened with my KVM/QEMU packaging :)
[13:19] <IntuitiveNipple> So the flow chart is proving extremely useful because it captures every possible path and makes it easy for me to check my understanding with people who know, simply by showing them the flowchart
[13:21] <persia> IntuitiveNipple: Interesting.  As you get closer to completion, I'd like to see the tool.  There's definitely a gap between checkinstall (easy and produces broken packages) and dh_make (requires lots of understanding, and tries to do too much).
[13:24] <IntuitiveNipple> I was debating whether to write it for Eclipse (where I do all my development) or Gnome (so it can be used by others) I've decided on gnome so I'm working up the GUI now. I can then have a python back-end that can also link into Eclipse
[13:25] <IntuitiveNipple> persia: If you're willing to review/amend the .dia document I use then I'm sure it could be quite bullet-proof
[13:26] <persia> IntuitiveNipple: I'm swamped now.  If you email it to me, I'll take a look when I can, but I suspect you'd do as well to push a couple more revs first (depending on your update rate).  Also, I can't promise complete understanding: I just learned about another packaging tool last week.
[13:27] <IntuitiveNipple> persia: Yes, I can imagine. I know the feeling well :)
[13:27] <persia> shodges: Does the addition of the tar call in  https://wiki.ubuntu.com/PackagingGuide/Basic help, or is it still unclear?
[13:27] <IntuitiveNipple> Once I get my new web-app front-end up and running it'll be online
[13:30] <soc> hi
[13:30] <soc> looks like breakage arrived today :-)
[13:30] <soc> i get /dev/null: permission denied, does someone have an idea?
[13:35] <shodges> persia, the tar call addition clarifies what you both have explained - just one thing, should the command say "tar -zcf hello-2.1.1.tar.gz hello-2.1.1" ?
[13:36] <shodges> it currently says "tar xzf ..."
[13:36] <persia> shodges: I always use "czf", but it the order doesn't matter, so it could be "zcf".
[13:36]  * persia thought that was fixed before the URL announcement, but was perhaps too slow
[13:36] <shodges> cool, good to know
[13:37] <persia> shodges: Thanks for the feedback.  Good luck with packaging.  If you have questions, I'd suggest asking in #ubuntu-motu, as this channel is usually much busier with developer coordination during the week.
[13:39] <shodges> thats great, thanks for your help - i'll switch to ubuntu-motu next time
[13:39] <IntuitiveNipple> while I think about it. Does anyone have any ideas as to what could be keeping a loop-mount busy after chroot-ing into it, or running a chroot shell?
[13:41] <IntuitiveNipple> I've created an automated script that builds  UML Ubuntu file-systems, but after it has run "sudo chroot ./root apt-get install ubuntu-minimal" umount reports it is still busy, although lsof doesn't show anything using it.
[13:41] <persia> IntuitiveNipple: It may be that you've started a daemon?
[13:42]  * Spads suspects dbus
[13:42] <Spads> that's what always holds my chroots open
[13:42] <IntuitiveNipple> Spads: really?
[13:42] <Spads> IntuitiveNipple: statistically, yeah.  You can check yourself though
[13:43] <persia> IntuitiveNipple: You might want to look at schroot: I think there's a patch to that that kills everything when closing the chroot.
[13:43] <IntuitiveNipple> hmmm, I saw mention in my searches of avahi having a chroot helper but stopping avahi didn't help. I can't really stop dbus :)
[13:43] <Spads> do an lsof
[13:43] <IntuitiveNipple> persia: Thanks, that might help, although it would be good to know what is managing to hold it busy and yet not show up
[13:44] <IntuitiveNipple> Spads: Thats the thing, lsof shows nothing at all
[13:44] <IntuitiveNipple> I've tried stracing it too, so far no luck
[13:44] <Spads> there's a +c0 trick you can do that I never had fully explained to me
[13:44] <IntuitiveNipple> with lsof?
[13:44] <Spads> yeah
[13:45] <Spads> lsof +c0 | grep /my/chroot/path
[13:45] <Spads> or something
[13:45] <Spads> you'll want to kill stderr
[13:45]  * Spads vanishes
[13:45] <IntuitiveNipple> " +c w     This  option  defines  the  maximum  number  of  initial characters of the name"
[13:46] <IntuitiveNipple> " If w is zero (’0’), all command characters supplied to lsof by the UNIX dialect will be printed."
[14:03] <IntuitiveNipple> Suggestions for a trivial package to install using apt-get to test this chroot issue - my mind has gone blank!
[14:04] <persia> IntuitiveNipple: hello
[14:04] <IntuitiveNipple> lol
[14:04] <IntuitiveNipple> doh
[14:04] <IntuitiveNipple> grrr, now I can't get it to fail!
[14:23] <Lutin> fabbione: would you mind testing linuxtv-dvb-apps 1.1.1-3 from debian and see if it works for you ?
[14:42] <seb128> Lutin: the checkinstall changes look like things that should be sent to debian, could you do that since you did the package update?
[15:14] <Protheus> Hi all
[15:15] <Protheus> I am looking for ubuntu PS3 development channel. does anyone know its name?
[15:19] <persia> Protheus: https://help.ubuntu.com/community/InternetRelayChat has the channel list.  You might try the powerpc channel.
[15:19] <persia> Protheus: Also, it's the weekend in many places, so the developers may not be around.
[15:24] <Protheus> Thx persia ...
[15:46] <fabbione> Lutin: yes i do because my media box is "stable" and i just disconnected 3 hours ago to mount the new fornitures for the living room that will arrive this week :)
[15:46] <Lutin> fabbione: ok :)
[15:47] <fabbione> if you asked yesterday i might have done it
[15:47] <fabbione> also.. what is the problem that needs testing?
[15:47] <fabbione> the merge or what?
[15:47] <fabbione> because IIRC the only delta was the DK DVB-T channels I added
[15:48] <Lutin> fabbione: yeah, that's it. there are also frequencies for dk in the debian package, but quite different from yours
[15:48] <Lutin> so I wanted to know if that worked, so that we can sync
[15:48] <fabbione> do you have a diff handy? mine were "guessed" and did work..
[15:48] <fabbione> the ones from Debian might be better
[15:49] <fabbione> anyway just sync.. we can always fix it later
[15:49] <Lutin> ok
[15:49] <fabbione> it's in universe AFAIR.. right?
[15:50] <Lutin> fabbione: indeed
[15:51] <fabbione> Lutin: take the ones from Debian. They are good and better than mine
[15:51] <Lutin> fabbione: ok
[15:52] <fabbione> ++# Created from http://www.digi-tv.dk/Indhold_og_tilbud/frekvenser.asp
[15:52] <fabbione> mine was "sniffing" on dk-Copenhagen .. you don't want to know how ;)
[15:52] <Lutin> lol :)
[16:20] <Protheus> can someone point me to a linux kernel source packe? I cannot find the package ... I don't know what do look after.
[16:21] <pochu> Protheus: linux-image-*
[16:21] <Protheus> lol. I did a new approach ... and go through the linux-kernel package ... there it was in the dependencies .... linux-source is it.
[18:02] <jdong> is there any way to extend the sudo password cache for a particular terminal session?
[18:04] <Protheus> hmmm ... I think this is a global setting.
[18:06] <jpatrick> jdong: -v extends to 15 minutes (or whatever the timeout is set as in sudoers)
[18:06] <jdong> interesting....
[18:07] <jdong> I'm looking for something for a continually-pbuildering shell
[18:07] <jdong> because pbuilder invokes sudo to become root and that almost always yields an annoying password prompt
[18:07] <jpatrick> sudo -s?
[18:07] <jdong> jpatrick: is it really safe to be fetching and mangling source archives as root :-/

[18:08] <jpatrick> err, probably not
[19:42] <so1> hi
[19:42] <so1> does someone know why pulseaudio needs an internet connection to work?
[20:41] <superm1> during the debian autosync, do NEW packages (that are in the debian archive but not in Ubuntu) automatically come?
[20:44] <Kmos> superm1: if they're at unstable (main), they'll come
[20:45] <Kmos> for example:
[20:45] <Kmos> !info vodovod hardy
[20:45] <Kmos> is a new one =)
[20:45] <ubotu> vodovod: lead the water from the house to the storage tank. In component universe, is optional. Version 1.10-1 (hardy), package size 419 kB, installed size 916 kB
[20:46] <geser> superm1: "automatically" as in an archive admins needs to start a script
[20:47] <superm1> geser, okay just making sure i didn't need to requestsync it.  there is no urgency to it right now, so whenever they run said script and grab it will be fine
[21:36] <saman> are there any Ubuntu open projects and how do we join
[21:44] <ivoks> ubuntu open projects?
[21:44] <ivoks> ubuntu is an open project :)
[23:32] <Le-Chuck_ITA> Hi there, may I draw your attention to bug #132583? It seems to have a one-line fix
[23:32] <ubotu> Launchpad bug 132583 in openoffice.org "python-uno can't be imported" [Low,Confirmed] https://launchpad.net/bugs/132583
[23:35] <Le-Chuck_ITA> and it's low priority, but it really breaks an important part of openoffice
[23:37] <somerville32> Le-Chuck_ITA, Did you provide a patch?
[23:38] <Le-Chuck_ITA> the quick way
[23:39] <Le-Chuck_ITA> there's a path missing from ld.so.conf, so the patch is to create a single-line file in /etc/ld.so.conf.d
[23:39] <Le-Chuck_ITA> I wrote that in a comment but didn't create a debdiff
[23:41] <Le-Chuck_ITA> somerville32: ping :)
[23:42] <somerville32> Le-Chuck_ITA, Ok. I'm sure someone will get to it. :)
[23:42] <somerville32> Thanks for the help!
[23:42] <somerville32> You might mark it triaged btw
[23:43] <Le-Chuck_ITA> I didn't do anything actually, the merit is due to other commenters
[23:43] <Le-Chuck_ITA> but will mark it as triaged
[23:46] <Le-Chuck_ITA> it's already triaged! :) so my task ends here
[23:46] <Le-Chuck_ITA> thanks and bye


[03:23] <ScottK> micahg: IIRC, yes.
[03:23] <micahg> ScottK: k, we're fixing it anyways :)
[03:24] <ScottK> kpackagekit is broken by design.
[03:24] <ScottK> Actually it's packagekit.
[03:24] <ScottK> kpackagekit does a decent job of making the best of a bad situation.
[03:27] <JontheEchidna> looks like the next rekonq is infact being targeted against qtwebkit 2.2: http://adjamblog.wordpress.com/2011/06/22/back-hacking/
[03:27] <ScottK> Handy.
[07:34] <jussi> JontheEchidna: yay :D
[07:49] <agateau> shadeslayer: I am around, but you are probably asleep :)
[07:53] <jussi> Morning agateau!!!
[07:54] <agateau> Morning jussi!
[07:54] <jussi> agateau: how are things going?
[07:55] <didrocks> hey jussi, agateau :)
[07:55] <jussi> ooh, everyone is just waking up.
[07:56] <agateau> jussi: fine thanks, what about your forking process?
[07:56] <agateau> didrocks: hi!
[07:56] <didrocks> was there for some time, just trying to catch up emails :)
[07:58] <agateau> didrocks is an early riser
[07:59] <didrocks> depends on the day, but generally, yes :-)
[08:03] <didrocks> agateau: FYI, I'm uploading in oneiric today Qt (a11y version and new utouch patch), sni-qt plugin patch will hopefully do it in next cut
[08:03] <agateau> didrocks: ok
[08:03] <agateau> didrocks: still waiting for confirmation from Qt devs :/
[08:04] <didrocks> agateau: right, let's not wait the a11y patch on that then, it will be a separate upload (and I'm sure we will have independant a11y fixes as well, so new uploads will be needed anyway)
[08:04] <agateau> didrocks: yes
[08:06] <jussi> agateau: the process is going well. She just started the second trimester, so Morning sickness is beginning to go away :)
[08:06] <agateau> jussi: good! morning sickness is a pain
[09:03] <jussi> shadeslayer: Quintasan http://www.engadget.com/photos/nokia-n950-press-shots/
[09:21] <sheytan> apachelogger http://www.youtube.com/watch?v=ykwqXuMPsoc&feature=player_embedded#at=55
[09:42] <valorie> sheytan: that's evil!
[09:42] <sheytan> valorie yeah :D
[09:43] <valorie> :-)
[10:07] <Quintasan> jussi: How much for that one?
[10:31] <jussi> Quintasan: they will loan you one...
[10:32] <Quintasan> jussi: where?
[10:34] <jussi> Quintasan: https://meego.com/community/device-program
[10:35] <Quintasan> jussi: Is working on Kubuntu Mobile enough to get this device?
[10:36] <jussi> Quintasan: I doubt it, I dont think they will be very interested in that commercially. Find something interesting you are willing to port...
[10:36] <jussi> Probably something with a large userbase ;)
[10:41] <jussi> Quintasan: video :) http://thenokiablog.com/2011/06/22/nokia-n950-hands-on/
[10:45]  * jussi is in love :D
[10:47] <jussi> Quintasan: Candidates must be community developers ready to start working on new or existing open source applications, to be published in apps.meego.com and the Nokia Store. Links to your current projects are relevant! Deadline for applications: end of Tuesday, June 28th.
[10:52] <jussi> Quintasan: if you have questions--- http://forum.meego.com/showthread.php?t=3597
[11:38] <yofel> morning
[11:38] <yofel> oh, 4.6.90 is up
[11:55]  * yofel goes updating the dep-graph again...
[11:55] <yofel> morning QuintasanDroid
[11:58] <yofel> at least Dirk cleaned up the tars this time, the empty ones are gone
[12:01]  * apachelogger giggles
[12:03] <apachelogger> Quintasan: plasma mobile i ssoooo sluggish because of no hardware accel and because of SD slowness
[12:04] <apachelogger> shadeslayer: yes you can over draw your card, in which case you need to pay big time moniez
[12:04] <apachelogger> Quintasan: why you be waiting for me?
[12:04] <apachelogger> jussi: stop making people long for microsoft^Wnokia products :P
[12:05] <jussi> apachelogger: awww
[12:06] <QuintasanDroid> apachelogger: ohk
[12:06] <QuintasanDroid> then Ill try compiling the kernel later
[12:06] <QuintasanDroid> it was a 700 mb download
[12:06] <QuintasanDroid> not 320 :O
[12:07] <yofel> this dep graph is becoming unreadable...
[12:07]  * QuintasanDroid looks at his todo and feels overwhelmed
[12:07] <QuintasanDroid> time to split it a little bit
[12:08] <apachelogger> Quintasan: you do not need to build the kernelz
[12:08] <apachelogger> dude
[12:08] <apachelogger> read what I wrote yesterday :P
[12:08] <apachelogger> you only need to build like 3 source packages for the graphics stack
[12:11] <QuintasanDroid> cool
[12:20] <yofel> great, wiki is utterly broken
[12:21] <yofel> open attachment page -> login to edit -> login -> {back to main page -> open attachment page -> login to edit -> login ->}*
[12:24] <yofel> hm, got it to work in konqueror
[12:26] <ScottK> didrocks: We need to coordinate on Qt.
[12:26] <didrocks> ScottK: I think we did? I talked to you some weeks ago about adding the accessibility with the Qt guys and on Monday that it was almost there, isn't it?
[12:26] <ScottK> didrocks: Quintasan did an updated merge from Debian that debfx was reviewing for upload.
[12:26] <didrocks> oh :/
[12:27] <ScottK> So we need to make sure we have this coordinated.
[12:27] <didrocks> right, as when you are merging from debian and bumping the revision just before an alpha, we should avoid that
[12:27] <ScottK> Additionally, IIRC, I asked you to discuss the accessibility stuff with fabo.
[12:27] <didrocks> was there a merge request somewhere?
[12:27] <ScottK> I think it was just coordinated on IRC.  That's usually how we do it.
[12:27] <didrocks> ScottK: right, and I told you that I will do once I'll explain the rationale (which is just done today)
[12:28] <didrocks> so debfx was also aware about a11y then, in both ways as I did it on IRC. Anyway, rebasing shouldn't be hard as it's just a patch apart
[12:28] <ScottK> Even if it doesn't go into Debian first, I want to see if we can have something fabo considers suitable so we don't add more diff than we need to.
[12:29] <didrocks> fabo: do you have some time to talk now?
[12:29] <didrocks> ScottK: well, I tried that for qtcreator and it ends up in a dead wait for 3 weeks as fabo is really busy and I didn't answer my ping on those
[12:30] <didrocks> so I don't want to put more charge when people are busy, especially when Qt upstream is onboard
[12:30] <ScottK> I'm not saying the upload should be blocked on his ack.
[12:30] <ScottK> Since this is a backport from 4.8 I'm less worried about coordination for it.
[12:31] <didrocks> no worry about coordination with debian people, I tend to do that a lot with GNOME components and other stuff already, even if it's done a day after the upload :)
[12:31] <ScottK> Now that Debian has armhf our armv6+ changes got into Debian.
[12:31] <ScottK> I'm mostly concerned that we've got two branches that need to be consolidated for upload.
[12:32] <ScottK> If you can rebase your update on Quintasan's merge (and check that) then upload I think that'd be great.
[12:32] <didrocks> ScottK: hum, I tend to use the branches for that, I think bzr-rebase should work in a very straightforward way
[12:32] <didrocks> I can do it if you can point me to a branch
[12:32] <ScottK> I'll get it.
[12:32] <didrocks> did the merge has been reviewed/tested?
[12:33] <didrocks> even with unity 2d? I don't want that the same thing happens again
[12:33] <ScottK> debfx had looked at it some, I don't know how much.
[12:34] <didrocks> ok, keep me posted then once we will know more about it
[12:34] <yofel> !ninjas
[12:34] <neversfelde> ha
[12:34] <yofel> 4.6.90 tars are up and the wiki and dep-graph are updated
[12:35] <neversfelde> still no idea where the tarballs are :)
[12:35] <yofel> I'll do kdelibs in a bit
[12:35] <yofel> neversfelde<EMAIL_ADDRESS>(sftp)
[12:35] <yofel> your ssh key is there, I checked
[12:35] <ScottK> didrocks: I see you uploaded Qt 4 hours ago.
[12:35] <yofel> (at least one)
[12:36] <didrocks> ScottK: right, the version which was staging in the ppa. There was nothing more in the bzr branch
[12:36] <ScottK> I'm not sure where Quintasan's branch is at the moment.
[12:36] <ScottK> didrocks: If you're going to upload Qt I would appreciate it if you would coordinate with us first.
[12:37] <ScottK> Now the merge that Quintasan spent a lot of yesterday working on is obsolete.
[12:37] <didrocks> ScottK: I was thinking the discussion on Monday was enough for you to know about it
[12:37] <didrocks> and the merge than Quitasian shouldn't conflict?
[12:37] <didrocks> how it is obsolete?
[12:38] <ScottK> It needs to be updated.
[12:38] <didrocks> apart from the debian/changelog, it should be ok
[12:38] <didrocks> and we would have the conflict anyway as it wasn't merged in trunk
[12:38] <shadeslayer> apachelogger: how much?
[12:38] <didrocks> so yeah, let's agree that if you or I upload Qt, let's know each other
[12:38] <fabo> didrocks: where's your a11y patch?
[12:38] <neversfelde> yofel: ah, now it works, no idea what was wrong yesterday. but it wants my password, shure that my key is there? https://launchpad.net/~neversfelde/+sshkeys
[12:39] <neversfelde> I changed it several times in the last half year
[12:39] <ScottK> Perhaps the styles of the two teams are a bit different between desktop and Kubuntu, but I absolutely do not think mentioning something 4 days ago is sufficient coordination for uploading something like Qt today.
[12:39] <yofel> ah, I only checked for your name, sec
[12:40] <yofel> neversfelde: try again
[12:40] <didrocks> ScottK: well, kubuntu guys uploaded a Qt making the unity-2d broken for alpha1, so notice should go in both way IMHO
[12:40] <didrocks> fabo: http://bazaar.launchpad.net/~kubuntu-packagers/qt/ubuntu/revision/174
[12:40] <fabo> thks
[12:41] <shadeslayer> jussi: sawn
[12:41] <didrocks> ScottK: for staging changes, we tend to just put in the vcs (we don't push every changes), maybe we should do that
[12:41] <shadeslayer> agateau: still around? :D
[12:41] <agateau> shadeslayer: yes
[12:41] <shadeslayer> ok #kde-usability then :)
[12:42] <jussi> shadeslayer: ?
[12:42] <shadeslayer> jussi: the N950 shots
[12:42] <neversfelde> yofel: works, thx
[12:42] <jussi> shadeslayer: and the video
[12:42] <jussi> ?
[12:42] <ScottK> didrocks: This is where we discuss Qt maintenance.  Being here for the discussion should be enough coordination.  That upload was very much discussed here when it was being prepared.
[12:43] <didrocks> ScottK: well, some people on the desktop team thinks that toolkit is impact more than one project and should be discussedd on #ubuntu-devel rather
[12:43] <didrocks> so I'm still joining there, but I can't follow everything
[12:43] <didrocks> as I guess debxx or Quintasan didn't follow the discussion about the a11y patch
[12:43] <ScottK> didrocks: Anyone is welcome to join here.  It's part of the Kubuntu packageset so this is the right place.
[12:44] <didrocks> ScottK: maybe now that it's in the ubuntu cd as well, we shoull revisit the packageset
[12:44] <didrocks> but TBH, I don't care, it's just that I think you can understand I can't follow the discussion 100% of the time here
[12:44] <ScottK> I would fight against that.
[12:44] <ScottK> I understand.
[12:45] <shadeslayer> jussi: nope, haven't seen the vid
[12:45] <jussi> shadeslayer: http://thenokiablog.com/2011/06/22/nokia-n950-hands-on/
[12:45] <didrocks> ScottK: should be rather easier to fix that the social way and just tell that for things which impacts other, we just ping people, agrred?
[12:45] <ScottK> I hope you equally understand that mentioning something to me over half a week ago doesn't mean that everyone on the team will know.
[12:45] <didrocks> agreed*
[12:45] <didrocks> sure, I was thinking it was enough, but I agree that it could have be missed :)
[12:45] <ScottK> Agreed, but it's hard to know what those things are.
[12:46] <ScottK> I  don't think anyone viewed the update before Alpha 1 as risky for unity-2d.
[12:46] <ScottK> Because Qt takes soooooo long to build any upload of it needs some coordination.
[12:47] <didrocks> I tested a lot this update for a11y for a couple of days, didn't think someone was merging from debian in the same time. I just focus on Qt regression (upstream as well did the work)
[12:47] <ScottK> That's good.
[12:47] <didrocks> ScottK: hum, I'm not sure, there is Qt/dbusmenu-qt/qt-at-spi/qt-sni (soon)
[12:47] <didrocks> also qtcreator, qtquick3D?
[12:48] <didrocks> I don't know, or we can just think about the biggest one, Qt?
[12:48] <didrocks> as you prefer
[12:48] <ScottK> It's less important for the smaller packages.
[12:48] <didrocks> the other, in case of issue, are easier to quickly fix
[12:48] <didrocks> right
[12:48] <ScottK> The dbusmenu stuff we're still waiting for upstream feedback.
[12:49] <didrocks> you mean dbusmenu or qt-sni?
[12:49] <ScottK> qt-sni (more specifically the Qt changes it needs)
[12:49] <ScottK> We want upstream to agree the approach is acceptable for eventual merge upstream.
[12:50] <ScottK> (now isn't the right time since Qt 4.8 is past feature freeze)
[12:50] <didrocks> right, that's why I'm still waiting before pushing the patch
[12:50] <didrocks> as I hope you noted :)
[12:50] <didrocks> (and the new package as well)
[12:50] <ScottK> I see it wasn't pushed.  I wasn't sure you were aware of all the coordination.
[12:51] <didrocks> makes sense to me, and hence the ping to you and debfx about Qt things when I have things to touch on. I was thinking Monday ping was enough, sorry, my bad :)
[12:52] <ScottK> This is a new thing to need to work together on.
[12:52] <didrocks> let's just coordinate for next time (in particular for this incoming merge)
[12:52] <ScottK> It's natural to have a few rough edges for a while.
[12:52] <didrocks> sure
[12:52] <didrocks> I just hope you notice that I'm trying my best to avoid those and I think you know I'm coming from the community and still feel part of it :)
[12:52] <didrocks> (and I still have a lot of pure-community things related to ubuntu outside of my work)
[12:54] <shadeslayer> jussi: fooey, that hinge looks like it'll break after a opening/closing the device a couple of times
[12:54] <jussi> shadeslayer: nah, its pretty much the same as on the E7 - and they are nice.
[12:55] <shadeslayer> oh
[12:56] <ScottK> didrocks: Sure.  I would hope you would still view yourself as part of the community.  I really don't like this idea of Canonical/Community.  I think that many Canonical employees are part of the community.
[12:57] <ScottK> didrocks: Is there any chance you pushed over Quintasan's merge?  I checked my backscroll and when he and debfx were discussing it, they didn't specify a location, so I would have assumed it was in the main packaging branch.
[12:58] <didrocks> ScottK: I totally agree with that and I think most of people are feeling this way. Of course (and unfortunatly) they are expection, but my guess is that it applies to for people beeing outside of the community before joining the company
[12:58] <didrocks> ScottK: hum, I didn't found anything and no conflict in the main packaging branch
[12:58] <didrocks> ScottK: I always use that one, let me check again
[12:58] <ScottK> cnd: Can you look at https://code.launchpad.net/qt and mark the ones that are done as merged/obsolete/etc so they don't clutter things.
[12:58] <ScottK> didrocks: In can case one of them will appear eventually and we'll get it sorted out.
[12:59] <didrocks> ScottK: lp:~kubuntu-packagers/qt/ubuntu right? Don't tell me I'm pushing to the wrong location :)
[12:59] <ScottK> That's right.
[12:59] <didrocks> ok, so yeah, I pulled and pushed there
[12:59] <didrocks> let's see with debfx and Quintasan once they are back
[13:00] <ScottK> OK.  That's the correct place.
[13:04] <didrocks> ScottK: no idea on qtcreator? it's more on my "quickly" role, but I'm interested in pushing QML (and the editor) a little bit, do you want special warning when merging from debian or things like that?
[13:04] <ScottK> I think it needs some coordination.
[13:04] <didrocks> ok, no worry :)
[13:04] <ScottK> I think if you discuss your plans here it's sufficient.
[13:05] <didrocks> no worry for that
[13:05] <ScottK> I also think you should talk to fabo about such things as well as it's nicer to get stuff in Debian.
[13:05] <didrocks> I already disussed with debfx and fabo about qtcreator and enabling the design view
[13:05] <ScottK> (and if he's too busy, I'm glad to do team upload for him there)
[13:05] <ScottK> Sounds good.
[13:06] <didrocks> just now that I've been at the Qt summit, I have a clearer view from upstream, just need to refresh them (probably later, next week or the week after)
[13:07] <ScottK> That's good.
[13:07] <fabo> didrocks: you're talking about the qml designer plugin?
[13:07] <fabo> "qtcreator and enabling the design view"
[13:08] <didrocks> fabo: right
[13:08] <didrocks> fabo: so, at the summit, I raised the issue about private header which have to be shipped
[13:08] <didrocks> fabo: they are aware of this, and will load a separate process in Qt 5
[13:08] <fabo> didrocks: oh that's why daniel was annoyed :)
[13:09] <didrocks> fabo: right now, there advise are to copy the headers, they don't see changing coming in 4.7 and 4.8
[13:09] <didrocks> that's what fedora and opensuse are doing
[13:09] <fabo> didrocks: it's shipped in latest qtcreator
[13:09] <didrocks> fabo: oh? you did it in debian?
[13:09] <fabo> yes
[13:09] <didrocks> awesome :)
[13:09] <didrocks> so yeah, you're blessed by upstream with that decision ;)
[13:10] <didrocks> anyway, qml designer is still young and quite experimental
[13:10] <didrocks> but better to try a little bit to play with it
[13:10] <didrocks> so ok, no need to discuss about it more, I'll just merge from you
[13:10] <didrocks> fabo: also, they are interested in the patches from library pathes we are, do you have an upstream contact?
[13:10] <fabo> 2.2.1 is coming in the next couple of hours
[13:11] <didrocks> s/are/have
[13:11] <fabo> both are stuck in NEW
[13:11] <didrocks> oh nice, that was my second question
[13:11] <ScottK> didrocks: The Qt change is part of the merge we were just discussing.
[13:13] <didrocks> ScottK: oh, so it's not a copy but a new binary package?
[13:13] <ScottK> Yes.
[13:14] <didrocks> (others distro choosed to rather copy in the source to avoid people waiting to do bad things with private headers)
[13:14] <ScottK> One that creator can depend on that is very clearly marked as private.
[13:14] <ScottK> Anyone who uses it deserves what they get.
[13:14] <didrocks> yeah, like "You Don't Want To Install This Package" :)
[13:14] <ScottK> Just installing the headers won't cause problems.  You'd have to write code that used them.
[13:14] <didrocks> right :)
[13:15] <didrocks> I just meant, it's more tempting :)
[13:15] <didrocks> but it's nice to know, thanks for the heads' up
[13:22] <ScottK> didrocks: Would you have a chance to work with cnd and get his touch fixes uploaded to natty-proposed?  I'm good with having my pending SRU rejected and replaced now that a proper fix is available.
[13:22] <didrocks> ScottK: oh sure, we can probably do that starting next week. I don't have the hardware handy to test it on a natty box there. cnd ?
[13:24] <ScottK> He's had some natty testers via his PPA.
[13:24] <ScottK> Next week is fine.
[13:25] <didrocks> if it's enough tested (the latest fix we push), I can bindly backport of course, just waiting for him to be awaken there
[13:25] <ScottK> Given it's tested in oneiric and in natty via the PPA I think that it's probably tested enough for -proposed.
[13:25] <ScottK> Let's wait for him though.
[13:30] <yofel> now this is great, kdelibs 4.6.90 tar contains 4.6.80...
[13:30]  * yofel sends a mail
[13:31] <ScottK> Go yofel go.
[13:31] <shadeslayer> btw they're going to have something called superbuilds
[13:32] <yofel> I'm in favour of split packages though, even if they're a bit more work
[13:34] <ScottK> shadeslayer: Those are for lazy people unwilling to joing the modern age.
[13:34] <ScottK> We might use some of them as a transition if we don't get the splitting done, but it shouldn't be more than that.
[13:34] <shadeslayer> i'm just saying :P ... i had a look at the project page, looks icky
[13:35] <shadeslayer> won't work for us i think because it uses cmake commands to download the git branches
[13:36] <Quintasan> didrocks, ScottK: I did not push anything to lp:~kubuntu-packagers/qt/ubuntu yet
[13:36] <ScottK> Quintasan: OK.  You'll need to merge from there first since didrocks did an upload this morning.
[13:36] <Quintasan> Since I was awaiting more comments from debfx
[13:37] <ScottK> OK.
[13:37] <didrocks> Quintasan: apart from the changelog, I don't think you will get any conflict
[13:37] <ScottK> Quintasan: Where is it?
[13:37] <Quintasan> ScottK: I'll upload the diff I've got somewhere, please wait a second
[13:37] <ScottK> Quintasan: It's better you push a branch to LP.
[13:42] <Quintasan> ScottK: diffs are http://people.ubuntu.com/~quintasan/merges/
[13:42] <Quintasan> I'll push somewhere in a second
[13:44] <yofel> bah, not only kdelibs but other tars also say 4.6.80, Dirk sure seems overwhelmed by git
[13:45] <Quintasan> yofel: Sounds like someone needs a guide :P
[13:45] <yofel> I think they wrote a git guide
[13:45] <yofel> somewhere
[14:01] <ScottK> micahg: Why is firefox 5.0 carrying a canonical-1.0 version number in the about box?
[14:02] <ScottK> It sounds like a candidate for Partner rather than Ubuntu.
[14:14] <Quintasan> ScottK: I tried keeping delta to minimum but no matter what I do diff still show some differences between two copyrights
[14:14] <Quintasan> Any idea what the hell is wrong?
[14:15]  * Quintasan even copied the whole file
[14:15] <ScottK> No idea.  Sometimes you have to take the diff and make a patch out of what you want to keep and then start from what Debian has and apply that as a patch.
[14:15] <ScottK> Weird.
[14:18] <Quintasan> https://code.launchpad.net/~quintasan/qt/debian-merge/+merge/65662
[14:20] <Quintasan> debfx: ^
[14:20] <Quintasan> Unless I did something wrong it should be fine
[14:21] <Quintasan> It builds and installs sucessfully
[14:22] <Quintasan> -installs
[14:29] <ScottK> Quintasan: Did you update that to base it from the upload didrocks did this morning?
[14:29] <Quintasan> yofel: I'll start pacakaging 4.6.90 Tomorrow
[14:29] <Quintasan> ScottK: Yes, I've tried merging it and it worked
[14:30] <ScottK> Great.
[14:30] <Quintasan> It also did build
[14:30] <yofel> look at -packagers first though, the current tars are junk
[14:30] <Quintasan> God damn
[14:30] <ScottK> So keep working on splits with the beta.
[14:30] <Quintasan> yofel: Are we getting the old layout or the splitted one?
[14:30] <ScottK> Quintasan: Splitted.
[14:30] <yofel> splitted one
[14:31] <Quintasan> Oh k, I'll start later since I have some business to attend to
[14:31] <Quintasan> Like Father's Day for example.
[14:31] <yofel> right, you can do all packages from the beta except for kdegraphics, that changes for the RC
[14:32] <Quintasan> This whole split was HIGHLY unorganised
[14:32] <Quintasan> Really.
[14:32] <yofel> sure it was, thanks to that they even skipped beta2
[14:32] <yofel> the RC layout looks like the neon one though. So I guess we won't get anymore changes
[14:32]  * Quintasan has to compile the ARM magic tooday too
[14:33] <Quintasan> yofel: PROTIP: copy over the packaging from neon ;)
[14:33] <yofel> not doable, but you can use most of the build-deps
[14:33] <yofel> and I already based the dep-graph on neon :P
[14:33] <Quintasan> Yeah, good work there Project Neon Brigade :D
[14:34] <Quintasan> kubotu: order cookies for yofel
[14:34] <yofel> lol
[14:34]  * kubotu slides a whole bunch of world's finest cookies down the bar to yofel.
[14:34] <Quintasan> kubotu: order cookies for shadeslayer
[14:34]  * kubotu slides a whole bunch of world's finest cookies down the bar to shadeslayer.
[14:34] <Quintasan> kubotu: order cookies for Quintasan
[14:34]  * kubotu slides a whole bunch of world's finest cookies down the bar to Quintasan.
[14:34] <yofel> :D
[14:56] <ScottK> didrocks: qtcreator 2.2.1 is now accepted in Debian.
[14:56] <didrocks> ScottK: thanks, I'll merge it later today or tomorrow :)
[14:57] <ScottK> didrocks: We'll need Qt updated first and it'll hit binary New.  Feel free to sponsor Quintasan's merge as I think debfx is away.
[14:57] <didrocks> ScottK: it can wait a little bit, but yeah, I add that on my schedule if debfx isn't there
[14:58] <ScottK> Thanks.
[15:30] <ScottK> didrocks: I told you wrong about qtcreator.  It's uploaded to Debian (and in New there). Sorry for any confusion.
[15:30] <ScottK> Debian New is pretty fast these days though.
[15:30] <ScottK> We should have it soon.
[15:30] <didrocks> ScottK: no worry, can wait a little bit then
[15:30] <didrocks> oh really?
[15:31] <didrocks> the New queue is processed more regularly? I probably was out of luck last time I experienced this :)
[15:35] <ScottK> It's been much better than the historical average recently.  Last time I hit New in Debian for binary changes it was ~a day.
[15:40] <didrocks> waow, nice to hear!
[15:49] <didrocks> ScottK: have you seen Thiago's answer for the sni patch?
[15:50] <ScottK> didrocks: I did.  agateau also wrote Denis  Dzyubenko.  I'd like to see his input too.
[15:50] <didrocks> sure
[15:51] <ScottK> I took Thiago's answer as kind of a non-answer due to the timing.
[15:51] <ScottK> Not suprising, but ....
[15:51] <didrocks> yeah
[15:55] <agateau> ScottK: I wrote to Denis because I thought Thiago would be too busy to answer. Now Denis seems to be away (those Qt developers can't be trusted! :)) but he told me yesterday in private the patch makes sense (I could paste it privately to you, but I don't like pasting private conversations on public channels). Thiago answer suggests we ship the patch, so I would go for it. We can start the upstream process when it makes sense for 5.0.
[15:56] <ScottK> agateau: I think that is fine.
[15:56] <ScottK> As long as you don't forget ....
[15:57] <ScottK> didrocks: Perhaps you could look at a combination of agateau's Qt patch and Quintasan's merge?
[15:58] <didrocks> ScottK: sure, that was my intent when pinging you about that email, if you are fine with it, I will do both in a row :)
[15:58] <ScottK> didrocks: Based on what agateau just said about Denis review, I'm fine with it.
[15:58] <didrocks> can't commit for tonight, but for tomorrow morning, sure
[15:58] <ScottK> debfx: ^^^ Please coordinate with didrocks for further Qt update reviewing.
[15:58] <ScottK> Thanks.
[15:59] <didrocks> debfx: ScottK: ok, so tomorrow morning (my morning), will probably see an upload of Qt with both if they make sense. Tell me if something is going wrong with that
[15:59] <ScottK> didrocks: It might be good to let the current build finish on all archs first.
[15:59] <ScottK> I suspect that will be tomorrow afternoon for you.
[16:00] <didrocks> ScottK: hum, I don't like pushing things on Friday afternoon. So I can make it staging in a ppa maybe and if everything's fine push on Monday?
[16:00] <didrocks> especially for week-end I'm travelling for the platform rally, can't be online to look if everything's fine
[16:01] <ScottK> didrocks: Up to you.  Next week will be busy for you I'm sure.
[16:01] <ScottK> If you want to upload in the morning, it should be OK.
[16:01] <didrocks> ScottK: I would prefer, right, I'll look at the build state tomorrow morning
[16:02] <ScottK> The next upload will hit binary New.  If you upload tomorrow I can review it with my archive admin hat on over the weekend.
[16:04] <didrocks> ScottK: oh, as long as it's blocked on binary New, I'm fine with uploading even in the afternoon then :) (didn't check the merge yet)
[16:04] <didrocks> but yeah, with the new private header package, I'm dummy :)
[16:04] <didrocks> so it's fine, I'll upload tomorrow's afternoon
[16:24] <darkwingduck> nixternal: are you just lurking or have you actually returned?
[16:24] <nixternal> don't know yet :p
[16:25] <DarkwingDuck> nixternal: epic.
[16:25] <DarkwingDuck> nixternal: I have a meeting with Jono in 30 min...
[16:25] <nixternal> need my server to do some work and this crap fires up automagically
[16:25] <nixternal> gl
[16:25] <DarkwingDuck> ty
[16:25] <cnd> didrocks, ScottK: I was planning to work on the SRU after the the last fix was pushed
[16:26] <cnd> so I'll probably document the second SRU today (the first is already documented)
[16:27] <cnd> and then I'll prepare a patch for SRU against natty
[16:28] <didrocks> cnd: excellent, thanks!
[16:43] <bambee> evening
[16:47] <DarkwingDuck> hey bambee
[16:48] <micahg> ScottK: that's been there as long as I can remember
[16:48] <ScottK> micahg: OK.  I guess I don't check about Firefox very often.
[16:49] <ScottK> It seems like an odd reference though.
[16:58] <Quintasan>  bambee, DarkwingDuck: sup
[16:58] <bambee> ;)
[16:58] <DarkwingDuck> hey Quintasan. Have a job meeting with Jono in a couple minutes.
[16:58] <Quintasan> DarkwingDuck: Good luck
[16:58] <DarkwingDuck> Quintasan: Thanks mate. :)
[16:58] <bambee> mhhh kde 4.6.90 is out... so I've a lot of packages to bump for this week end :D
[17:00] <bambee> DarkwingDuck: good luck;)
[17:00]  * DarkwingDuck crosses fingers
[17:26] <didrocks> Quintasan: I reviewed your merge request, some small fixes needed: https://code.launchpad.net/~quintasan/qt/debian-merge/+merge/65662
[17:26] <Quintasan> Okay
[17:27] <didrocks> fabo: thanks for the "only one dep for each line" that makes life so easier in the future :)
[17:27] <didrocks> Quintasan: should be easy to fix :)
[18:29] <Quintasan> debfx: https://code.launchpad.net/~quintasan/qt/debian-merge/+merge/65662
[18:56] <Quintasan> apachelogger: IMX_MMCODECS_11.01.tar.gz <--  any idea how these are better than what we have in ports?
[19:07] <ScottK> yofel: New tarballs for RC1.
[19:08] <yofel> yay
[19:08]  * yofel rsyncs
[19:08] <ScottK> He renamed the directories, so make sure you get the right one (see -packager)
[19:09] <yofel> well, the new one replaces the old one, and old one was renamed
[19:36] <yofel> yep, good tars this time :)
[20:02] <cnd> ScottK, I've uploaded a debdiff and source package for qt4-x11 to bug 762938
[20:02] <cnd> it also includes the fix for bug 785433
[20:02] <cnd> could you upload it to natty-proposed for me?
[20:03] <ScottK> cnd: Great.  I'm slammed with work so hopefully didrocks will have time to look at it tomorrow.  Please make sure he's aware.
[20:03] <cnd> ok
[20:07] <ScottK> yofel: It might be good to reply to packagers that the problem is fixed.
[20:07] <yofel> true
[20:31] <Quintasan> apachelogger: ungzipping magic and trying building
[20:38] <Quintasan> apachelogger: That amd* stuff are only binaries
[20:39] <Quintasan> at least in L2.6.35_11.05.01_ER_source
[20:43] <Quintasan> amd-gpu-x11-bin-mx51-11.05.01.tar.gz and amd-gpu-bin-mx51-11.05.01.tar.gz
[20:43] <Quintasan> OR I am doing something wrong
[20:52] <Quintasan> shadeslayer: http://paste.kde.org/86863 <-- debug form Lancelot crash
[20:52] <Quintasan> can't get any more than this
[20:53] <sheytan> is there PIM update for natty already?
[21:17] <Quintasan> shadeslayer: in staging
[21:17] <Quintasan> it's still not stable imo
[21:26] <Quintasan> FFS Y U INSTALL SO LONG
[21:42] <Quintasan> apachelogger: stuck on video-imx
[21:42] <Quintasan> linux/mxcfb.h
[21:42] <Quintasan> missing
[21:53] <Quintasan> oh wait
[21:54] <Quintasan> this is sick
[21:54] <Quintasan> apachelogger: http://boundarydevices.com/blogs/building-gstreamer-plugins-under-ubuntu
[21:54] <Quintasan> apachelogger: http://boundarydevices.com/blogs/freescale-gstreamer-plugins
[21:54] <Quintasan> build imx-lib according to instructions
[21:54] <Quintasan> then try building xorg-imx driver
[21:55] <Quintasan> apachelogger: also, show up at least once a day
[21:55] <Quintasan> :P
[21:58] <Quintasan> DarkwingDuck: ping
[22:04] <Quintasan> rbelem: ping
[22:04] <Quintasan> eventually jussi
[22:20]  * Quintasan laughts maniacally
[22:20]  * Quintasan stabs everyone around
[22:20]  * Quintasan kills himself
[22:23]  * Quintasan tries the LTIB stuff
[22:25] <valorie> Quintasan: you OK?
[22:25] <Quintasan> valorie: No.
[22:25] <Quintasan> going apeshit over iMX magic
[22:25] <valorie> {{{{{{{{{{{{{{{{hugs}}}}}}}}}}}}}}}}
[22:25] <Quintasan> valorie: Thanks :D
[22:25] <valorie> sounds serious
[22:32] <Quintasan> I'm somewhere in the middle of complation and it misses some damn header files
[22:33] <Quintasan> Can't find them
[22:37] <Quintasan> apachelogger: ping ping ping ping
[22:42] <Quintasan> apachelogger: You made me descend into this madness myself? How far did you get?
[22:45] <Quintasan> persia: Any ideas about where I could possibly find shw_driver.h? Google yields linux-fsl-imx51 but if I try to install that it pulls other kernel
[22:46] <persia> Quintasan, Dunno.  Maybe I should get one of these devices myself :)
[22:46] <persia> So, for in-the-archive source, everything is kinda old.
[22:47] <Quintasan> persia: No, really, I'm trying to compile their own video driver with their own sources and I can't because there are missing headers :S
[22:47] <persia> The freescale team at Linaro (see https://wiki.linaro.org/LandingTeams ) may have newer code, but the rumour is that there are licensing issues with putting it in the archive.
[22:47] <persia> And Freescale has some code.
[22:48] <persia> Aha.  Let me look.
[22:48] <Quintasan> persia: Oh wait, that PPA sounds promising
[22:49] <Quintasan> persia: I've got some code from Freescale -> L2.6.35_11.05.01_ER_source_bundle
[22:49] <persia> You might also try looking in linux-headers-2.6.38-1002-linaro-mx51
[22:49] <Quintasan> Already installed
[22:49] <persia> I don't know if that has the right headers, as it's supposed to be upstreamable stuff though.
[22:49] <Quintasan> now trying linux-headers-2.6.38-1003
[22:50] <Quintasan> This Class 4 Card...
[22:50]  * Quintasan grits his teeth
[22:50] <persia> SATA ought work, and would be *lots* faster.
[22:50] <persia> Mind you, this needs an external drive, case, power, cabling, etc.
[22:51] <Quintasan> Just found the connector, but I do not have a HDD
[22:51] <Quintasan> maybe my USB drive would be better
[22:51] <persia> USB drive is a bit better.
[22:52] <persia> And, depending on your taste in hardware hacking, many USB drives can be disassembled to get SATA drives.
[22:52] <Quintasan> You got me there.
[22:52]  * Quintasan looks for instructions
[22:52] <persia> (note that USB *rotary* drives are better.  Most USB flash drives aren't that much better.)
[22:55] <Quintasan> hmm 3GB HDD
[22:55] <Quintasan> That's magic
[22:55] <persia> 3 *giga* byte?
[22:56] <Quintasan> persia: Yes. Something old most likely
[22:56] <Quintasan> WD Caviar 33200
[22:57] <Quintasan> 3249,3 MB :D
[22:57] <persia> Wow!
[22:58] <Quintasan> CCC: 19 Jan 98
[22:58] <persia> So, that's a PATA drive.  You'd need a converter to use SATA.
[22:58] <Quintasan> I know, I just looked around if something useful is not laying around
[22:59] <Quintasan> If I get this driver to work then this means two things
[23:00] <Quintasan> GL and video decoding acceleration
[23:00] <persia> And huge kudos from all sorts of folk :)
[23:00] <Quintasan> K, plasma-mobile starts up as expected
[23:01] <persia> ericm (the person who uploaded everything in that PPA) is usually in #ubuntu-arm, although in UTC+8, so maybe not yet.  He might have more information about kernel porting for that hardware.
[23:03]  * Quintasan tries adding that PPA
[23:04] <persia> I downloaded the header debs from there, and didn't see shw_driver.h (although maybe I didn't look hard enough).
[23:06] <Quintasan> persia: So I far I figured out I need linux/mxcfb.h to build the driver which is apparently provided by imx-lib which in turn needs that shw_driver.h to compile
[23:06] <Quintasan> If we are to somehow package all that stuff into a working image that will be a massive PITA
[23:09] <persia> Why?  Does it need to compile-at-runtime or something annoying like that?
[23:09] <persia> Otherwise it seems doable (although we'll want to share the work with lots of other folk with the board).
[23:11] <Quintasan> persia: I mean packaging the driver if we don't have the headers :D
[23:11] <Quintasan> There is an ITP in Debian but it was untouched
[23:11] <persia> Aha!  "the sahara/ and rng/ sub-projects won’t compile without a full kernel source installation, since they refer to headers that are not in the public include/linux tree.", and from looking at the docs for shw_driver.c, it seems to be RNG related.
[23:11] <Quintasan> Which makes me sad
[23:11] <persia> Err, shw_driver.h
[23:12] <Quintasan> Shouldn't linux-headers be enough?
[23:12] <persia> Well, the trick there is to find someone who *does* have the headers.  I very strongly suspect that the Freescale Landing Team at Linaro would have access to them (as some of those guys work on kernels at Freescale).
[23:13] <persia> Yes, for sane values of "should".
[23:13] <persia> In practice, some companies will sign licensing agreements with other companies to use their technologies, and then use those technologies in their products.
[23:14] <persia> Often these agreements include disclosure restrictions, which prohibit the licensee from disclosing the source, even if they wished.
[23:15] <Quintasan> Urgh.
[23:15] <persia> I don't happen to know the terms of the contract between Freescale and AMD for the Z180 core, but unless someone was extra careful, it probably has that sort of restriction (just because the boilerplate contracts all have this by default).
[23:16] <Quintasan> Would answer the amd-gpu-bin-mx51-11.05.01.tar.gz question :)
[23:16] <Quintasan> It's binary only installation
[23:16] <persia> In some cases, vendors will make binary drivers available.  On the other hand, many of the silicon vendors who license the ARM ISA are used to working in the embedded market, so these binary drivers are typically only made available in a single revision for a combined hardware/software "product".
[23:18] <persia> However, if you happen to know someone who has access to the code that needs to be compiled, you may be able to get them to release binaries based on it (although it depends on the specific terms of the arrangement).
[23:20] <Quintasan> Looks like I'll stay at #linaro a little bit longer
[23:21] <persia> There or #ubuntu-arm.  Many of the Ubuntu-friendly Linaro folk are there (but not the Android folk, etc.)
[23:23] <Quintasan> persia: Where did you find that "the sahara/ and rng/ sub-projects won’t compile....." ?
[23:23] <persia> Note, the other option is `rm -rf sahara2/ rng/` (unless you have something *else* requiring shw_driver.h)
[23:23] <persia> From your URL: http://boundarydevices.com/blogs/building-gstreamer-plugins-under-ubuntu
[23:23]  * Quintasan facepalms
[23:23] <persia> Mind you, that's outdated...
[23:23] <Quintasan> I've read that two times
[23:24] <Quintasan> Well, no harm in trying out
[23:24] <persia> The difference might be that you expected things to work, and I'm surprised you're making the progress you have.
[23:25] <persia> Note that you may need to use "PLATFORM=IMX53".
[23:25] <persia> If I recall correctly, i.MX51 uses an AMD Z160 and i.MX53 uses an AMD Z180.
[23:25] <persia> Which quite possibly means differing code paths.
[23:26] <Quintasan> persia: Well, I'm the adamant type, I usually sit until I get stuff done :P
[23:27] <persia> And for this you are to be commended.
[23:29]  * valorie adds kudos to Quintasan
[23:30] <Quintasan> Someone should rather invent a way not to sleep and be effective as usually
[23:30]  * Quintasan installs headers once again
[23:31] <valorie> coffee
[23:31] <valorie> and the occasional walk around outside in the fresh air
[23:32]  * Quintasan wonders if it would be possible to have XMBC on this board
[23:32] <Quintasan> I wanted a small PC in living room to watch movies
[23:32] <Quintasan> if that small board can decode 1080p then I'm buying the HDMI port extension
[23:33] <apachelogger> baruba
[23:33] <Quintasan> LOOK WHO'S HERE
[23:33]  * Quintasan throws bricks at apachelogger
[23:33] <apachelogger> I actually shall be going to bed soonish
[23:33]  * Quintasan throws more bricks at apachelogger
[23:34] <valorie> exams a bit exhausting, apachelogger?
[23:34] <apachelogger> gotta pack up my life and move tomorrow and study for exams at some point
[23:34] <Quintasan> Excuses, all excuses apachelogger
[23:34] <apachelogger> valorie: nah, drinking
[23:34] <apachelogger> I blame all the drinking
[23:34] <valorie> ah
[23:34] <Quintasan> How come I am not surprised?
[23:34] <apachelogger> yesterday I was so drunk I, my bike, my laptop and everything ended up in a mud hole
[23:34] <valorie> welll, your .prn is already on your devices, so that's done
[23:34] <apachelogger> later on the better part of those things moved into the shower altogether
[23:35] <valorie> you took your bike into the shower?
[23:35] <valorie> unusual
[23:35] <apachelogger> I know
[23:35] <Quintasan> apachelogger: Bike and drinking? Does not compute the same way as skateboarding and drinking
[23:35] <apachelogger> then I went to sleep for 12 hours and was all surprised that the entire house is drity
[23:35] <apachelogger> Quintasan: my sober biking is already about as bad as my sober skateboarding
[23:36]  * valorie fears for the apachelogger health
[23:36] <Quintasan> apachelogger: Are you going to Akademy or Desktop Summit?
[23:36] <apachelogger> imagine that combined with wet ground and drunkeness
[23:36] <apachelogger> all wicked up
[23:36] <apachelogger> Quintasan: perhaps I am and perhaps I am not
[23:36] <valorie> !
[23:36] <apachelogger> the future will tell
[23:36] <Quintasan> apachelogger: http://www.youtube.com/watch?v=McO1cH54vEU
[23:36] <Quintasan> Problem?
[23:36]  * valorie gives the future a talking-to
[23:36] <apachelogger> also I fear that godzilla might come after berlin, in which case I'd rather not be there
[23:37] <valorie> great laugh on that one, Quintasan
[23:37] <apachelogger> ah, I know it, I know it all too well
[23:38] <Quintasan> valorie: It's not me laughing :D
[23:38] <apachelogger> like if I were not wearing cloths most of the time in consideration of other people I'd look like a wreak really
[23:38] <Quintasan> valorie: I'm the one landing on face
[23:38] <valorie> :(
[23:38] <apachelogger> it shows
[23:38] <valorie> that's not good for your face
[23:39] <persia> Quintasan, http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=IMX53QSB claims it does 1080p (but you will need to sort the codecs first)
[23:39]  * apachelogger points out that the codecs likely need accel first
[23:39] <Quintasan> valorie: Well, not that I expected one of bearings would suddenly refuse cooperation with the rest of the wheels
[23:39] <apachelogger> as otherwise openmaxil won't do zip
[23:39] <Quintasan> apachelogger: Guess what I'm trying to do Sherlock
[23:39] <persia> I think rsalveti was looking at XBMC (and other set top box solutions).  Might ask him in #ubuntu-arm.  I don't think he has a Quckstart, but he has similar hardware.
[23:40] <apachelogger> the more you fix the less I have to fix
[23:40] <apachelogger> the less I have to fix the more time I can spend drinking
[23:40] <apachelogger> the more time I can spend on drinking the more creative ideas I have
[23:40] <apachelogger> it is a win for everyone really
[23:40] <apachelogger> also I need to organize a flipping meating next week
[23:40] <Quintasan> apachelogger:  the more you fix the less I have to fix, the less I have to fix the more time I can spend drinking
[23:41] <Quintasan> persia: \o/ imx-lib compiled
[23:41] <persia> \o/
[23:41] <persia> Does it work?
[23:41] <Quintasan> Can't install it via make install :O
[23:41] <persia> Heh.
[23:41] <persia> Did you happen to end up with the code with a license that lets you upload it?
[23:41] <apachelogger> ahh, the joys of not proper free software
[23:42] <persia> There are folk hanging around in #ubuntu-arm with commit access to trunk, so we can arrange for patches to be taken.
[23:42] <Quintasan> persia: Probably not since contents of sim are not compiled due to yet another "missing" header
[23:42] <persia> Oh, ugh.
[23:42] <Quintasan> linux/mxc_sim_interface.h this time
[23:43] <persia> http://linux-fsl-imx51.sourcearchive.com/documentation/2.6.31-605.8/mxc__sim__interface_8h-source.html ?
[23:43] <Quintasan> Okay, removed sim/ as well
[23:43] <Quintasan> Exactly
[23:43] <persia> But that file is *GPLv2*.  It ought be around somewhere.
[23:43] <Quintasan> hmm
[23:44] <Quintasan> linux/mxcfb.h still missing
[23:44] <persia> Even the implementation is available: http://linux-fsl-imx51.sourcearchive.com/documentation/2.6.31-606.11/imx__sim_8c-source.html
[23:44] <persia> (yes, these examples are from an *old* kernel, but still ...)
[23:44] <Quintasan> looks like imx-lib providing that was a wild guess
[23:44] <persia> Should be in the kernel source.
[23:45] <persia> (or it was for 2.6.31)
[23:45] <Quintasan> I'll install that linux-fsl-imx51
[23:46] <persia> I suspect you'll get the newest code from *-linaro-lt-mx53 from the PPA.
[23:47] <Quintasan> https://launchpad.net/~canonical-kernel-team/+archive/ppa/+build/2282720
[23:47] <Quintasan> I'm not going to bother with apt magic and I'll just force the debs
[23:47] <persia> My understanding (the people who really do this know more) is that *-linaro-lt-* includes random code that makes the board happy but is expected to make Linus cry, and linux-linaro-* contains code that is expected to be upstreamable, but may not provide full board support.
[23:48] <persia> I wouldn't use that one, unless you want older code.
[23:48] <persia> I believe the latest version they have there is from lucid.
[23:48] <persia> (but, yeah, if there's no other way to get it)
[23:49] <persia> The main issue being that the i.MX53 *didn't exist* for lucid, so that code is guaranteed not to have ever been tested on your processor.
[23:49] <Quintasan> It can't burn the board, can it?
[23:50] <persia> Did you install a heatsink?
[23:50] <Quintasan> nope
[23:50] <persia> Then it can.
[23:50] <persia> Unfortunately, all pre-3.0 kernels require that all the resistor values, board voltages, etc. be specified in the source code.
[23:51] <persia> Mind you, the values might not have changed much, but one never knows.
[23:52] <persia> With 3.0 and later, *some* drivers will be using "devicetree" to specify these details outside the kernel, as an extra datafile.
[23:52] <persia> I have no idea if the drivers for i.MX* are included in the set of drivers that have been ported to use devicetree.
[23:53] <persia> That said, since we don't actually have any kernels newer than 2.6.38 for that board, we can be sure that none of the available kernels use devicetree.
[23:53] <Quintasan> I'll just copy over the headers
[23:53] <persia> That's probably safer :)
[23:54] <Quintasan> Unless Google has been trolling me and those headers are not really in there
[23:54] <Quintasan> Oh wait, it's 01:00 in the morning.
[23:54] <Quintasan> I thought it's more like 03:00
[23:56] <Quintasan> I have linux-headers-2.6.35-1001-linaro-lt-mx53_2.6.35-1001.1_armel.deb installed
[23:56] <persia> That's ericm's latest, from what I can tell.
[23:56] <persia> He might have newer in git somewhere, but I don't see any packages.
[23:57] <Quintasan> I guess I'll go to bed if that doesn't work. Not much I can do at this phase.


[10:25] <tsdgeos> cimi: any chance you can re-review https://code.launchpad.net/~unity-team/unity8/audioCardSupport/+merge/260613 ? it's relatively urgent
[10:25] <tsdgeos> ideally we'd have to land it "today"
[10:25] <tsdgeos> lol
[10:25] <tsdgeos> :D
[10:34] <cimi> tsdgeos, on my way :)
[10:35] <tsdgeos> cimi: for easier testing silo 38 + silo 4
[10:54] <mvvvv> ca-y-est ... ça leur reprend  :https://fr.news.yahoo.com/video-%C3%A0-pourrait-ressembler-clavier-dordinateur-ann%C3%A9es-091324648.html
[12:00] <cimi> tsdgeos, ok did some comments
[12:27] <pstolowski> jhodapp, ping
[12:30] <jhodapp> pstolowski, pong
[12:30] <pstolowski> jhodapp, hey! how much work is still needed in your mediahub stuff to enable sound indicator integration?
[12:32] <jhodapp> pstolowski, I need to debug why the link to the MediaPlayer2 interface doesn't seem to be working
[12:33] <jhodapp> I was able to see it make calls via dbus-monitor, but it's not quite right and I'm not sure why yet...after that I need to go through each function, play/pause, next, prev and make sure they work with right context
[12:36] <pstolowski> jhodapp, if we have FFe for the feature, will you be able to complete it by final ota6 freeze?
[12:36] <jhodapp> pstolowski, potentially, depends on the stakeholders for my team setting the priorities
[12:37] <jhodapp> pstolowski, but after debugging the dbus issue, in theory it'd be a fairly easy task
[12:39] <alecu> jhodapp: hi! we are very close to getting this feature in, so we are keen on having it be the top priority
[12:40] <alecu> jhodapp: are there other items that may have more priority? when is your stakeholders meeting, I'd like to join it.
[12:40] <jhodapp> alecu, yeah indeed, I have to get the base background playlist landed first...it's in testing right now
[12:40] <jhodapp> I'll keep you posted
[12:41] <alecu> jhodapp: please do, thanks.
[12:41] <pstolowski> jhodapp, ok, good, thanks for update. fingers crossed for the missing bit
[12:41] <jhodapp> yeah indeed, working as quickly as I can...it's complex code that affects every type of media playback so that's why it's a hard and slow one to land
[12:41] <jhodapp> big risk
[12:44] <pstolowski> jhodapp, sure, fair enough, i know it's complex
[12:44] <alecu> jhodapp: btw, what's the missing thing in the MediaPlayer integration?
[12:44] <alecu> jhodapp: is that enabling/disabling the next/prev buttons when not needed?
[12:45] <jhodapp> alecu, the MediaPlayer2 MPRIS interface isn't quite hooked up to media-hub correctly yet
[12:45] <jhodapp> that's the main issue
[12:45] <alecu> jhodapp: oh, so no play/next either
[12:46] <jhodapp> no, nothing until that interface works from the indicator-sound
[12:46] <alecu> jhodapp: ok. I know that enabling/disabling is not implemented in the sound indicator, but the rest should be there, because it's used and working in desktops, and it's the same indicator code.
[12:47] <alecu> jhodapp: surely it's not a confinement/AppArmor issue?
[12:47] <jhodapp> alecu, indeed, I can confirm that...I traced the indicator's calls with dbus-monitor and I see it making those calls
[12:47] <jhodapp> alecu, don't know what the issue is yet, most likely on the media-hub side
[12:47] <jhodapp> could be confinement as play/pause used to work
[12:49] <alecu> jhodapp: ok. Please let me know if we can help with anything of this, from the indicator side.
[12:49] <jhodapp> thanks alecu
[12:50] <alecu> jhodapp: charles and xavigarcia are doing other bits in the sound indicator these days, so they may provide a hand there.
[12:50] <jhodapp> alright
[13:56] <tsdgeos> greyback: ping
[14:03] <greyback> tsdgeos: splat
[14:03] <tsdgeos> greyback: yoiu guys killed applicationmanager suspended
[14:03] <tsdgeos> greyback: what do we do with test_suspend in tst_ShellWithPin.qml ?
[14:04] <greyback> tsdgeos: lemme see
[14:08] <greyback> tsdgeos: use applicationsDisplayLoader.item.suspended instead I guess. AppMan doesn't keeping track of the system suspended state any more, unity8 does
[14:09] <tsdgeos> greyback: yeah that works
[14:09] <tsdgeos> i'll put a MR up
[14:10] <greyback> tsdgeos: sorry about that
[14:12] <tsdgeos> greyback: https://code.launchpad.net/~aacid/unity8/make_testShellWithPin_pass/+merge/267821
[14:12] <tsdgeos> greyback: next beer it's on you :P
[14:28] <pstolowski> jhodapp, hey, i'm using your media hub silo 48; during playback pulseaudio takes ~24% cpu, mediahub takes ~20% cpu; ui becomes a little sluggish (mako); expected?
[14:29] <jhodapp> pstolowski, yeah mako isn't optimized
[14:29] <jhodapp> for pulse
[14:29] <jhodapp> 20% for media-hub is about right
[14:29] <pstolowski> jhodapp, ah, ok. thanks
[14:30] <jhodapp> np
[14:30] <greyback> jhodapp: is it decoding on the CPU?
[14:30] <jhodapp> greyback, for audio, yes always
[14:31] <greyback> jhodapp: ok. We can't trust the hardware decoder?
[14:32] <jhodapp> greyback, there wasn't hardware decoding available for the device that I developed this all on originally, not every device has hardware decoders for audio
[14:33] <greyback> jhodapp: ok
[14:33] <greyback> just curious
[14:33] <jhodapp> greyback, yeah no worries, just another thing we could do but add it to a long list of things ;)
[14:34] <greyback> right ;)
[14:34] <jhodapp> it's pretty efficient when pulsedroid is tuned well
[14:34] <jhodapp> for software decoding
[15:06] <greyback> tsdgeos: a tag sneaked into https://code.launchpad.net/~aacid/unity8/make_testShellWithPin_pass/+merge/267821
[15:06] <tsdgeos> greyback: it's again that local vs remote tag stuff
[15:06] <tsdgeos> greyback: for some reason the checkout has a wrong tag
[15:06] <tsdgeos> but the remote one no
[15:07] <tsdgeos> greyback: run ./strip-tags.py lp:~aacid/unity8/make_testShellWithPin_pass and it'll tell you it's fine
[15:07] <tsdgeos> i can't understand how that happens tbh
[15:07] <greyback> tsdgeos: you're right
[15:07] <greyback> me neither
[15:07] <greyback> anyway, branch acked
[15:17] <tsdgeos> greyback: can you have a look at https://code.launchpad.net/~aacid/unity8/make_testPhoneStage_pass/+merge/267830 ? it fixes the other failing test
[15:17] <tsdgeos> or want me to find someone else?
[15:17] <greyback> tsdgeos: I can, just gimme build time
[15:18] <tsdgeos> cool tx
[15:18] <greyback> must play with bzr colo, save me rebuilding so often
[15:45] <cimi> tsdgeos, my arale didn't like silo 8 and 34
[15:46] <tsdgeos> cimi: what happened¿
[15:46] <cimi> white screen
[15:46] <cimi> :/
[15:46] <tsdgeos> ouch
[15:51] <tsdgeos> i don't think we're landing it today anyhow
[15:51] <tsdgeos> have a bit of a headache
[15:51] <tsdgeos> eod'ing now
[15:51] <tsdgeos> tty tomorrow
[15:51] <cimi> tsdgeos, get better
[15:51] <cimi> so fast! :D
[19:08] <josharenson> How can I trigger a trusted prompt? I have an old app that I wrote that clears the trust store and asks for GPS location, but its not prompting