[00:29] <cwayne> mfisch: what are your thoughts on this bug?https://bugs.launchpad.net/ubuntu-nexus7/+bug/1076793
[00:29] <ubot2> Launchpad bug 1076793 in ubuntu-nexus7 "Bad multicore performance" [Undecided,New]
[00:30] <mfisch> cwayne: unsure really
[00:30] <mfisch> cwayne: I'm about eod, lets check it out tomorrow
[00:30] <mfisch> cwayne: I guess we should repro it
[00:31] <mfisch> I'd like to know how it works on a multicore x86 box too
[01:50] <lilstevie> with regards to nexus7 and running android side-by-side can I suggest LVM, it is the solution I have gone down for the tf201 cause repartitioning on these tegra devices is a real pain
[01:54] <infinity> lilstevie: Turn all the Android partitions into one big LVM volume?  I think I suggested that to Oliver a couple of weeks ago. ;)
[01:54] <lilstevie> infinity, well that too, I started with just UDA
[01:55] <lilstevie> but lately yeah, the whole damn lot
[01:55] <infinity> Would be nice if we could just repartition, like I did on my ac100, but that seems to be a non-option on the nexus7.
[01:56] <lilstevie> you need nvflash for that
[01:56] <infinity> Indeed I did, yes.
[01:56] <lilstevie> and the nexus 7 is ODM secure
[01:57] <lilstevie> and our nvflash stuff doesn't work with it
[01:58] <lilstevie> not to mention I don't think canonical could endorse such hackery
[02:00]  * persia considers mobiln-image-creator and smirks
[02:01] <lilstevie> lol
[02:02] <lilstevie> persia, do you have time at the moment?
[02:02] <lilstevie> also hi
[02:02] <lilstevie> :p
[02:02] <persia> Some, not lots.
[02:03] <lilstevie> heh ok
[02:03] <lilstevie> repo.lilstevie.geek.nz is where that kernel is if you get some time to have  a look
[02:03] <persia> Give me a URL, and I'll hit it as soon as I have time, which likely saves scheduling issues (and apologies for not poking you earlier today)
[02:04] <lilstevie> that's ok, you probably wouldn't have reached me
[02:04] <lilstevie> I didn't get up until 10am and it is only 1pm now
[02:04] <persia> What did you have to change in casper?
[02:04] <lilstevie> TheMuso changed something, I think he pushed that for quantal though
[02:04] <persia> Yeah, but I had more time when you got up than I do now :)
[02:06] <lilstevie> it was something to do with not looking at any storage on the usb bus for the tf201
[02:06] <persia> Anyway, unless something comes up, I should be able to look at it in ~6 hours.
[02:06] <lilstevie> ok cool :)
[02:13] <lilstevie> anyway with some minor work, the new kernel should support the entire tegra3 transformer range
[05:21] <mjrosenb> sweet, my chromebook is now running ubuntu!
[05:36] <mjrosenb> ok, does anyone know how software for ubuntu/arm (e.g. firefox) is built?
[05:37] <mjrosenb> is it cross-compiled, or just built nativelty?
[05:37] <TheMuso> mjrosenb: Everything that ships with Ubuntu on Arm is built natively.
[05:37] <mjrosenb> ow
[05:38] <mjrosenb> I tried building firefox on a pandaboard last night
[05:38] <TheMuso> Took a while eh?
[05:38] <mjrosenb> and the linking phase killed it
[05:38] <lilstevie> use that shiny new a15
[05:38] <TheMuso> ...or lots and lots and lots and lots of swap.
[05:38]  * achiang would be interested in seeing chrubuntu build performance
[05:38]  * lilstevie too
[05:38] <achiang> dual a15, 2gb ram... and using usb3 for IO
[05:39] <mjrosenb> yeah, I think my pandaboard has 1G ram + 512m swap
[05:39]  * achiang nominates mjrosenb to do some tests. :)
[05:39] <mjrosenb> I should give it some more swap
[05:39] <TheMuso> Yep, try a lot more swap.
[05:39] <lilstevie> building on my quad a9, 1gb ram with slow mmc is a bit more decent but that a15 should kill it
[05:39] <mjrosenb> achiang: oh, its internal hard disk uses usb3.0?
[05:39] <TheMuso> No, it usees MMC internally.
[05:40] <TheMuso> At least afaik.
[05:40] <achiang> mjrosenb: oh, no. cr-book has an external usb3 port
[05:40] <achiang> internal mmc
[05:40] <mjrosenb> yeah, something or other is showing up as an sdcard
[05:40] <achiang> that's the mmc
[05:41] <mjrosenb> sadly, / is *quite* small
[05:41] <hrw> ogra_: ignored flash. hangouts are handled by plugin (not tried extracting)
[05:41] <achiang> the ubuntu buildds use external USB disks
[05:41] <mjrosenb> you know if the mmc is user-replacable?
[05:41] <hrw> TheMuso: that ppa which persia mentioned is with ucm profile.
[05:42]  * mjrosenb does not have any external usb disks available, but I do have a nice 32g sd card
[05:42] <mjrosenb> (that I need to find)
[05:42] <achiang> hrw: i'd be interested if you were able to figure out the hangout plugin. that's my blocker for getting a chromebook. :)
[05:42] <hrw> TheMuso: what do you think about moving ucm profiles to separate package? would be easier to update and I would love to get them in Debian as well
[05:43] <persia> hrw: How easier to update?
[05:43] <hrw> achiang: hdmi output works fine
[05:43] <achiang> hrw: sorry, i don't understand? how is hdmi related to google hangouts?
[05:43] <lilstevie> hrw, moving the ucm profiles to a separate package would also make tweaking for devices with similar codecs easier
[05:43] <persia> lilstevie: Why?
[05:44] <lilstevie> persia, smaller, more portable package?
[05:44] <persia> lilstevie: more boilerplate documentation bloating deployed images
[05:44] <lilstevie> hm
[05:45] <persia> ucm files are trivially portable.  Uploading them as part of a single thing makes it easy, as long as we effectively collaborate on the uploads.
[05:45] <persia> It's only if one falls into the trap of believing in maintainers and maintainer lock that it could be an issue.
[05:45] <hrw> 23:55 < achiang> the fact that they shipped without getting hdmi working is... lame
[05:46] <achiang> hrw: oh, you're processing old scrollback. :)
[05:46] <hrw> persia: and ucm profiles are ubuntu delta
[05:46] <hrw> achiang: yes, I do
[05:46] <persia> hrw: That makes it even simpler: they just drop in local VCS, and get deployed.
[05:46] <hrw> achiang: its 6:45 here
[05:46] <achiang> nod
[05:46] <achiang> 2146 here
[05:46] <lilstevie> 1646 here :p
[05:47] <mjrosenb> 47 here
[05:47] <lilstevie> just 47?
[05:47]  * persia refutes the concept of timezones, and claims it to be 8:17, based on time since becoming awake.
[05:47] <hrw> persia: my plan is to get all chromebook related to debian rather then ubuntu
[05:47] <mjrosenb> well, 0047 if you want to zero pad it
[05:47] <lilstevie> persia, heh
[05:47] <persia> hrw: I like that plan.  How does Debian deploy ucm today?
[05:47] <hrw> and chromebook can fry speakers when wrong switches are enabled in alsa mixer
[05:48] <hrw> persia: so far not found any
[05:48] <persia> Frying speakers is good: some hardware actually melts.
[05:48] <lilstevie> hrw, ouch, that seems like..... a very poor design decision
[05:48] <persia> hrw: Have you asked #debian-arm@OFTC?
[05:48] <hrw> persia: conferences does not help too much to make real work
[05:49] <persia> hrw: I totally understand (hence you not seeing me last week)
[05:49] <persia> Err, this last week.
[05:50] <hrw> but today I start few days of vacations in 'still not so cold' Spain
[05:50] <persia> Heh.  Enjoy the last breath of summer.
[05:50] <hrw> if 11°C counts as summer ;d
[05:51] <hrw> lilstevie: I have a feeling that chromebook was released in a rush when I use it
[05:51] <lilstevie> hrw, probably, like everything is these days
[05:52] <hrw> alsa mixer without restrictions, power usage during suspend-to-ram
[05:53] <persia> hrw: Anyway, as far as I can remember, we stuck the ucm stuff in libasound2 because it matched /usr/share/alsa/* for the Intel-HDA quirking: if there's a better architecture, then it probably makes sense to abstract out the /usr/share/alsa/cards/* stuff as well.
[05:54] <persia> But, as mentioned before, that would require additional licensing and documentation files, and I suspect achiang will support the idea of having less of that to ease deployment.
[05:54] <hrw> yep
[05:55] <achiang> persia: hm, i'm not planning on doing anything with chromebooks. :)
[05:56] <persia> achiang: Yes, but such extra stuff would be on *all* rootfs constructions, which increases the footprint requirements for every install.
[05:56] <persia> And I thought I remembered you wanting smaller footprints from UDS: my apologies if I'm mistaken.
[05:57] <achiang> ah, yes. sorry, that is still definitely true
[05:58] <TheMuso> hrw, persia, I asked the alsa guys fi they wanted to carry the ucm stuff and I was told no.
[05:59] <TheMuso> And really, it is trivial to carry them.
[06:00] <persia> TheMuso: Do you think it's better to carry them as a distro-patch, or a separate package?
[06:00] <TheMuso> Having said that, if upstrea were convinced to make another package for all ucm stuff, then I wouldn't object, upstrea being alsa devs.
[06:00]  * persia is in favour of the distro-patch model
[06:00] <TheMuso> Me too, only because they are so easy to carry.
[06:00] <TheMuso> If they were hell to patch in, I'd be pushing for a separate package, but since they are only text files...
[06:01] <persia> TheMuso: Have you had any discussions with Debian ALSA folk about them?
[06:01] <TheMuso> persia: As aboev, I asked if debian wanted to carry, and afaicr they said no.
[06:01] <TheMuso> above*
[06:01] <persia> Sorry: I read the above as the ALSA project, rather than Debian.  I understand now.
[06:02] <TheMuso> But this stuff is really alsa upstream stuff.
[06:02] <TheMuso> I need to check the archives to see if any previous discussion was held about sed topic.
[06:02] <persia> I thought UCM was originally done by ALSA upstream folk, but maybe there's still discussions ongoing there.
[06:02] <TheMuso> Well they don't appear to carry any ucm files from what I've seen in git.
[06:03] <hrw> persia: UCM was rather ASoC guys stuff
[06:03] <hrw> Liam G., Mark Brown etc
[06:05] <persia> hrw: Ah, right.  I get asoc confused with ALSA sometimes.
[06:06] <hrw> I still remember discussion from Openmoko times about that stuff
[06:07] <TheMuso> It maybe ASOC but its still part of ALSA.
[06:08] <TheMuso> Ok this is weird. In /proc/asound/cards on the nexus7, I see an HDA driver loaded for NVIDIA Tegra HDA...
[06:09] <persia> Hrm?  I would have expected tegra-alc5632
[06:09] <lilstevie> that isn't totally odd
[06:09] <lilstevie> same thing on the tf201
[06:09] <TheMuso> Sure, there is an rt5xxx card, and the one I mentioned above.
[06:10] <TheMuso> rt5640 to be exact.
[06:10] <TheMuso> Oh its for HDMI.
[06:10] <persia> Interesting: are there actually two different audio interfaces in hardware, both connected to the same speakers/
[06:10] <TheMuso> Which is absolutely crazy, given no HDMI out on the Nexus.
[06:10] <lilstevie> with the tf201 I get HDA NVIDIA Tegra and tegra-codec
[06:11] <lilstevie> TheMuso, I think it is actually integrated into the SoC
[06:11] <persia> Does it not have some sort of dock connector, which maybe carries underdocumented HDMI?
[06:11] <TheMuso> lilstevie: As above, I suspect the second HDA based one is for HDMI.
[06:11] <TheMuso> Mini USB only for the nexus7 afaik.
[06:11] <TheMuso> Or micro USB whatever its called.
[06:11] <lilstevie> the SoC itself supports HDMI
[06:11] <persia> Silly hardware manufacturers: save money by not exposing ports, limiting functionality.
[06:11] <lilstevie> it has 2 outputs
[06:11] <TheMuso> lilstevie: Yeah afaik you can still have an hda codec as part of the SOC.
[06:11] <lilstevie> LVDS and HDMI
[06:12] <lilstevie> I haven't looked at the block diagram but you will probably find the HDA codec is somewhere in that
[06:12] <lilstevie> I know there is something similar with the Tegra 2
[06:12] <TheMuso> lsmod shows snd-hda-codec-hdmi loaded on the n7.
[06:13] <TheMuso> From what I read aon achiang's blog, a new kernel si coming that will disable athat though.
[06:13] <lilstevie> yeah, on the trimslice it has tegra-trimslice-analog and tegra-trimslice-digital
[06:13] <persia> A new kernel isn't the right way to do that: it just pushes us further down the path of device-specific kernels.
[06:13] <lilstevie> I really need a microhdmi cable to test hdmi out with the tf201
[06:14] <TheMuso> Yeah but I am surprised they used HDA for HDMI... but it does make sense.
[06:14] <persia> Better would be to have a framework that lets us blacklist modules based on device name.
[06:14] <lilstevie> persia, yeah, the tf201 kernel needs a crapload of work before that will become an option though
[06:14] <TheMuso> They already have to do the legwork for their desktop hardware, so why not incldue it in the SoC.
[06:15] <persia> lilstevie: Lots of them do, but I still think we want SoC-specific kernels in Ubuntu if we can.
[06:15] <persia> I'd like ISA-specific kernels, or even architecture-specific kernels, but those are significantly harder targets.
[06:15] <lilstevie> persia, I agree, an SoC specific kernel would take a crapload of stress off me with tf201 stuff
[06:16] <TheMuso> In other news, GNOME shell appears not to work on the Nexus 7, I get GNOME fallback.
[06:16] <hrw> microhdmi... I got one yesterday. in a box with some Atom based device
[06:16] <persia> Off everyone, as the SoC licensor could just push upstream (or to gregkh for LTSI) and nobody would have to reimplement.  THe issue being that we don't have any way *other* than kernel patches to turn on or off features on a per-device basis, nevermind the issues with board-bringup on initial boot.
[06:16] <lilstevie> but at this stage it just isn't possible, stupid kernel cross contamination crap asus have done
[06:17] <persia> lilstevie: tf201-not-possible, or tegra-not-possible?
[06:17] <lilstevie> persia, tegra3 transformer not possible
[06:17] <lilstevie> persia, the best I can probably do is all the tegra 3 transformers into 1 kernel
[06:18] <persia> That's a huge step forward though.
[06:18] <lilstevie> yeah, well thankfully the tf201 tf300t and tf700 are very similar devices
[06:18] <lilstevie> and asus have left much of the code for the other devices in the latest kernel
[06:18] <hrw> have a nice day guys. I go for vacations
[06:18] <lilstevie> I still need to do a bit more research into what is missing
[06:18] <persia> Good for them.
[06:18] <lilstevie> hrw, have fun
[06:19] <lilstevie> persia, likely situation is they build for all 3 devices from the same tree
[06:19] <persia> lilstevie: They just need to be convinced to only maintain one kernel.  You don't happen to know folk there, do you?
[06:19] <lilstevie> persia, asus don't like us very much
[06:20] <lilstevie> and I suspect since July they would be even less likely to open dialogue with me
[06:20] <TheMuso> /c/c
[06:20] <persia> lilstevie: Oh well.
[06:21] <lilstevie> persia, yeah, we kinda really broke their platform :)
[06:21] <lilstevie> I don't think nvidia would like talking to us either
[06:24] <lilstevie> persia, not that that matters anyway, I have in the past tried to open communication with them and got ignored
[06:42] <achiang> TheMuso: we have bugs for gnome-shell
[07:29] <mjrosenb> major annoyance #1 about the chromebook
[07:30] <mjrosenb> the power button is evidently right where I expect pageupu to be
[07:30] <mjrosenb> also, it doesn't have a page up
[07:43] <persia> Mapping to Search-UpArrow probably makes sense.  That keyboard should have had a function key.
[07:46] <dholbach> good morning
[07:49] <mjrosenb> dholbach: morning.
[07:49] <mjrosenb> hey, is there a TI guy in here?
[07:50] <mjrosenb> I remember I had an issue with a TI provided library, and someone was pinged
[07:50] <mjrosenb> but I no longer remember who it was.
[07:52] <persia> Do you remember which issue?
[08:06] <mjrosenb> persia: yes, various parts of unity didn't work because libgbm shipped via the omap ppa had the wrong version number.
[08:22] <persia> Just to confirm, this is likely a mesa issue?
[09:04] <mjrosenb> yeah.
[09:29] <persia> Then the person you seek is likely ndec (at least according to my backscroll)
[09:55] <mjrosenb> persia: ahh, yes.  I remember it was a short name
[09:55] <mjrosenb> *remembered
[09:56] <mjrosenb> ndec: ping?
[09:56] <mjrosenb> also, it took me 17 minutes to build the spidermonkey shell
[09:56]  * mjrosenb tries on the pandaboard
[11:00] <ogra_> janimo, did you ping any archive admin about the kernel upload yet ?
[11:00] <ogra_> still in NEW
[11:06] <ogra_> heh
[11:07]  * ogra_ sees an armhf package for fastboot ... so i should be able to flash my nexus from my ac100 or chromebook now
[11:12] <janimo> ogra_, I told infinity yesterday
[11:12] <ogra_> k
[11:13] <janimo> ogra_, would the x86 one not run under qemu?
[11:13] <ogra_> i dont think we have a qemu i386 on arm
[11:13] <persia> There used to be one: was it disabled?
[11:13] <ogra_> iirc i looked at that for last UDS
[11:14] <ogra_> persia, a system one probably
[11:14] <persia> user-mode also, at least at DebConf11, but that was a while ago now.
[11:14] <ogra_> for which you would need to run a full VM ... which in turn would eat all my RAM :)
[11:14] <persia> Get more RAM then (and if it's all soldered, go complain to your manufacturer)
[11:15] <ogra_> i had a discussion with one qemu upstream guy back then and he told me there are too many syscals missing for -user mode
[11:15] <ogra_> persia, well, i fixed that ram issue on the ac100
[11:15] <persia> How?
[11:15] <ogra_> by buying a chromebook :)
[11:15]  * persia fails to see how that fixed the ac100
[11:16] <ogra_> heh
[11:16] <lilstevie> lol
[11:19] <xnox> mfisch: android-tools are built and published in the ppa:ubuntu-nexus7/ubuntu-nexus7-installer, you can update your blog post =))))
[12:00] <victorp> ogra_, I am doing some video test, the nexus7 is really struggling with 720p ogg movie
[12:01] <ogra_> i havent tried ogg yet, but that might well be, i doubt there is an ogg omx plugin
[12:01] <ogra_> it works fine with h264 mp4 files, at lest it did at aome point for me
[12:02] <ogra_> i.e HD movbie trailers
[12:06] <victorp> ogra_, I will try that
[12:06] <victorp> ogra_, different question
[12:06] <ogra_> http://www.dvdloc8.com/list_clip.php
[12:07] <ogra_> there you should be able to find some h264 HD movie trailersa
[12:11] <ogra_> livecd-rootfs (2.94) raring; urgency=low
[12:11] <ogra_>   * add a dependency on android-tools-fsutils for armhf builds
[12:11] <ogra_>   * add nexus7 live-build configuration
[12:11] <ogra_>   * add nexus7 post processing with make_ext4fs for teh tarball to roll a
[12:11] <ogra_>     proper android img file
[12:11] <ogra_> there we go :)
[12:12] <ogra_> oh i hate if i typo changelog entries, damned
[12:47] <angs> I have a beagleboard-xm that runs ubuntu-server. What is the name of the package that I need to install on my laptop (ubuntu 12.10) to cross compile my C code?
[12:54] <victorp> ogra_, hehe
[12:55] <victorp> ogra_, I am using big buck bunny
[12:55] <victorp> much nicer ;)
[12:55] <victorp> anyway I logged a bug for ogg
[12:55] <victorp> is there a way to pull in latest decoders that might speed it up?
[12:59] <ogra_> angs, apt-get install gcc-arm-linux-gnueabihf
[12:59] <ogra_> angs, trhats the cross compiler
[12:59] <ogra_> angs, http://marcin.juszkiewicz.com.pl/2012/03/26/ubuntu-12-04-precise-and-cross-compilation-of-arm-kernels/
[13:09] <ogra_> victorp, sorry, missed your last sentence (life is a bit crazy today over here, lots of people in my house), the codecs come from nvidia, so we wont be able to update unless they release a new version
[13:10] <hrw> ogra_: iirc at uds there was deiscussion to take all linaro crosscomplation pages and make finally some docs for ubuntu ;)
[13:10] <ogra_> hrw, yeah, but its not done yet
[13:23] <angs> ogra_: thank you very much
[13:58] <victorp> ogra_, I am transform it to mp4 h264 and does not playwell
[13:58] <victorp> do you use totem?
[13:58] <ogra_> transform ?
[13:58] <ogra_> yes, you have to
[13:58] <victorp> using vlc in my pc
[13:58] <ogra_> or any othert gstreamer based player
[13:58] <ogra_> the nvidia codecs are only available for gstreamer
[13:59] <victorp> totem plays the mp4 well in my laptop but like an old TV in the nexus 7
[14:00] <victorp> colour all messed up
[14:01] <ogra_> well, use a proper mp4 not something you manually transcoded
[14:01] <ogra_> i have the simpsons trailer here from the page above
[14:01] <ogra_> and that plays fine
[14:01] <ogra_> some audio lag sometimes but i blame pulse for that
[14:02] <dholbach> hum, do we advise nexus7 users to upgrade? http://www.mattfischer.com/blog/?p=298
[14:02] <dholbach> to me it looks like at least nux and unity will be replaced by unpatched versions then: https://launchpad.net/~ubuntu-nexus7/+archive/ppa
[14:02] <dholbach> I'm just asking because it was picked up by http://www.omgubuntu.co.uk/2012/11/ubuntu-for-nexus-7-gets-small-updated
[14:11] <brendand_> ogra_, at risk of being bitten, i'd like the broach the subject of some sort of DMI equivalent on ARM. i've heard DeviceTree mentioned
[14:13] <ogra_> dholbach, well, -updates and -security are disabled by default (on purpose) but fixes that go to the PPA should be updated, yes
[14:14] <dholbach> ogra_, ah ok
[14:14] <ogra_> brendand_, yeah, for kernels using DT that could server as a dim like tool
[14:14] <ogra_> *dmi
[14:14] <ogra_> brendand_, sadly only very few kernels have DT yet
[14:14] <brendand_> ogra_, does the n7?
[14:14] <ogra_> no
[14:14] <brendand_> ogra_, can it/will it?
[14:15] <ogra_> if you find someone to port it :)
[14:15] <ogra_> there are no plans to port the current kernel anywhere on our side beyond adding fixes to make the HW work better
[14:16] <ogra_> but if someone from the community wants to work on a port to i,.e. 3.5 or newer nobody will block him/her
[14:20] <brendand_> ogra_, alright. we have some tests that use DMI, but it may be necessary just to skip them if DMI/DT is not available
[14:20] <ogra_> right
[14:20] <brendand_> ogra_, an example is a test that checks the amount of installed RAM on the system and makes sure the kernel detects it all
[14:20] <ogra_> i was working on a lshw fix for that before releaase
[14:21] <ogra_> seems it has the dmi check hardcoded as the very first test
[14:21] <ogra_> (but there is an option to override that, i was planning to make that a default on arm builds of lshw)
[14:21] <ogra_> ... but didnt manage to finish that bit yet
[14:22] <ogra_> memory should really not be pulled from DMI anyway, you want it from /proc/meminfo
[14:22] <brendand_> ogra_, /proc/meminfo is what the kernel sees, right?
[14:22] <ogra_> yep
[14:23] <ogra_> dmi is what the BIOS sees
[14:23] <ogra_> but arm systems are usually BIOS less
[14:23] <brendand_> ogra_, exactly. they should match up after allowing for UMA, right?
[14:24] <ogra_> well, the bios data usually only tells you about the RAM modules used etc
[14:24] <ogra_> while the values in proc show you the actual currently usable ram
[15:01] <victorp> cwayne, I saw you raised some bugs on video. Did you get any HD video working?
[15:02] <cwayne> victorp: i'm trying it again now.  i had gotten 720p working for a bit in copenhagen, but haven't tried since
[15:02] <cwayne> will keep you updated
[15:02] <victorp> cwayne, I have 720p ogg working but is very very choppy
[15:02] <victorp> http://www.bigbuckbunny.org/index.php/download/
[15:02] <victorp> ^^
[15:02] <cwayne> victorp: yeah, i saw that, im downloading that file now to test
[15:03] <victorp> but I tried mp4/h264 and I get lots of image corruption
[15:03] <ogra_> in my tests before uploading the codecs package it just worked
[15:04] <ogra_> using commercial 720p and 1080p trailers for testing
[15:24] <victorp> ogra_, you wont have a link to the actual files?
[15:25] <ogra_> not direct, i use them from the site i gave you above
[15:26] <ogra_> http://www.dvdloc8.com/view_clip.php?movieid=12167
[15:26] <ogra_> the 720p one should definitely be fine
[15:32] <cwayne> ogra_: i think that's what i used in copenhagen and they seemed to work iirc
[15:32] <ogra_> yup, same for me
[15:33] <achiang> victorp: need to mute and unmute your video button in the indicator again ;)
[15:33]  * cwayne tries again
[15:33] <victorp> achiang, what?
[15:34] <victorp> ogra_, downloading now...
[15:34]  * achiang wonders if victorp knows what a snipe hunt is ...
[15:34] <victorp> achiang, lol
[15:37]  * cwayne tries out mfisch's kernel while waiting for sample videos to download
[15:38] <mfisch> cwayne: great
[15:39] <ogra_> janimo, CONFIG_USB_GADGET=m and CONFIG_USB_CDC_COMPOSITE=m
[15:39] <janimo> ogra_, ack
[15:39] <janimo> will add them in the next kernel upload
[15:39] <ogra_> ++
[15:39] <victorp> ogra_, it is not HD though 1280 x 544
[15:40] <ogra_> victorp, its 720p
[15:40] <janimo> I wonder if these are needed by adb too. I could not get adb to connect to an adbd running on ubuntu, maybe this is why
[15:40] <ogra_> victorp, the content is 1280 x 544 instead of 1280x720 because its a cinema (16:10) format though
[15:41] <ogra_> the black stripes are in the movie as well :) that makes it 720p
[15:41] <mfisch> cwayne: this new video from Blender is much more fun than Big Buck Bunny: http://www.tearsofsteel.org/
[15:42] <victorp> ogra_, ha
[15:42] <victorp> it is not HD is has only 544 horizontal lines
[15:42] <victorp> 1280 x 544
[15:42] <victorp> http://en.wikipedia.org/wiki/720p
[15:43] <cwayne> mfisch: your kernel seems to work!
[15:43] <mfisch> cwayne: great
[15:43] <ogra_> victorp, how else would you display a 16:10 movie on a 16:9 display ?
[15:43] <victorp> ogra_, I am just talking about how hard is making the hardware work
[15:43] <ogra_> its 544 lines of content and 2x88 lines of black
[15:44] <ssweeny> mfisch,  achiang, is it fair to set the brightness bug as "won't fix" since it's working as upstream designed it? the bug doesn't mention the UI, so changing the label on the tickbox seems like a separate task
[15:44] <ogra_> still 720p ;)
[15:44] <cwayne> ssweeny: which brightness bug?
[15:44] <ssweeny> cwayne, https://bugs.launchpad.net/ubuntu-nexus7/+bug/884041
[15:44] <ubot2> Launchpad bug 884041 in ubuntu-nexus7 "Screen brightness not adjusted when switching from AC to battery" [High,Confirmed]
[15:45] <mfisch> ssweeny: at the very least we need an upstream bug about the confusing wording
[15:45] <ssweeny> mfisch, i think the wording is tangential to the bug as filed
[15:45] <ssweeny> i'm going to file a bug with gnome anyway
[15:46] <ssweeny> but i'm not sure it needs to be attached to this one
[15:46] <ssweeny> the filer didn't say "I checked this box and it didn't do what I thought". They said "This thing used to work and now it doesn't"
[15:46] <victorp> anyway, I am sending it to the nexus7 and see if it plays without green shades
[15:47] <cwayne> ssweeny: i think it could be attached
[15:47] <ogra_> if you installed vnc it might have replaced any codecs with its own btw, i'm not sure what vnc pulls in through deps
[15:47] <cwayne> and then won't fix'd for nexus7
[15:47] <cwayne> ogra_: +1 i think we should only use totem for video testing for now
[15:48] <ssweeny> cwayne, vg
[15:48] <ssweeny> cwayne, i will trust your expert opinion :)
[15:48] <cwayne> afaik, vlc brings in a lot of codecs, which is why we don't ship by default i believe
[15:48] <ogra_> cwayne, right, or any other gstreamer based player (are there any ?!?) :)
[15:49] <hggdh> I am getting checksum failed when downloading the new image
[15:49] <ogra_> it can well be that there are still issues with the actual codecs indeed i only did some smoke testing before uploading
[15:49] <ogra_> hmm, why is vanhoof not in this channel ?
[15:50] <cwayne> hggdh: what if you clear out that directory (~/Downloads/UbuntuNexus7) and try again?
[15:50] <victorp> ogra_, is playing extremely choppy
[15:50] <victorp> cwayne, ^^
[15:50] <hggdh> cwayne: on it
[15:50] <cwayne> victorp: which one?  ogra_'s?  damn i need faster internet, mines still downloading
[15:51] <ogra_> victorp, yeah, i fear your vnc installation might have trashed the setup
[15:51] <hggdh> cwayne: a look on the dir shows the sha256 file with a date of Oct 26, not today... I wonder
[15:52] <cwayne> hggdh: hmm, perhaps its not overwriting as it should... i believe vanhoof may have just fixed that
[15:52] <victorp> cwayne, yes, ogra's
[15:52] <victorp> ogra_, that is just random
[15:52] <ogra_> well, it most likely does SW rendering
[15:53] <ogra_> so once the queue is full it chops frames out
[15:53] <victorp> and what does vlc have to do with that?
[15:53] <ogra_> if you let htop run in a terminal window you should actually see one CPU maxed out if thats the case
[15:54] <ogra_> the whole multimedia stack consists of multiple packages
[15:54] <ogra_> vlc might have replaced one or the other through a dependency
[15:54] <victorp> htop not in the image
[15:54] <victorp> :(
[15:55] <ogra_> apt-get install it :)
[15:55] <victorp> I am just complaining that is not in the image ;)
[15:55] <ogra_> we discussed pulling it into the desktop seed for ubuntu during UDS
[15:55] <victorp> shouldnt this tools be pre-install on a dev image?
[15:55] <ogra_> seems everyone is using it anyway and we should have the space
[15:55] <ogra_> you have top
[15:55] <ogra_> its just harder to read
[15:56] <cwayne> fewer pretty  colors :)
[15:56] <victorp> or we could have a meta packages that install all the debug tools
[15:56]  * victorp like colors
[15:57] <victorp> ogra_, cores are not maxed out
[15:57] <ogra_> cwayne, well, the important part for me is always the total ram usage, nothing shows that as nicely as htop
[15:57] <cwayne> ogra_: agreed
[15:57]  * cwayne <3 htop
[15:58] <ogra_> victorp, well, then it uses the omx libs apparently
[15:58] <highvoltage> fun fact: htop actually starts up slightly faster than top
[15:58] <victorp> it is with the ogg 720p
[15:58] <victorp> for bbb
[15:59] <hggdh> cwayne: OK. deleting the sha256 file and re-downloading all causes an Oct 26 sh256 file to be recreated -- and failure ensues
[15:59] <cwayne> hggdh: ruh roh
[15:59] <cwayne> vanhoof: ^^
[16:00] <victorp> cwayne, let me know if you get the simpsons running well
[16:00] <cwayne> victorp: ack.  just finished downloading
[16:01] <achiang> ssweeny: you get an answer re: brightness? my opinion is that we have an opportunity to do better than upstream
[16:01] <ssweeny> achiang, i can take a look at implementing something if you like
[16:03] <cwayne> mine crashes at 9 seconds in victorp... weird
[16:03] <achiang> ssweeny: iow, i think as part of our power savings kick, shouldn't dimming screen make sense? my android phone autodims even when plugged in
[16:03] <victorp> mine plays the second time but not the first
[16:03] <victorp>  :)
[16:04] <ssweeny> achiang, you make a valid point
[16:05] <vanhoof> cwayne: hggdh you've gotta be picking up something cached
[16:05] <vanhoof> have a quick call, ill take a look
[16:05] <victorp> http://status.ubuntu.com/ubuntu-raring/group/topic-raring-desktop-targets-for-embedded.html
[16:08] <cwayne> huh, im always getting it hanging at 9 seconds
[16:08] <cwayne> wtf
[16:08] <hggdh> vanhoof: I do have a cache for packages (squid-deb-proxy), but I do not see how it would get there
[16:08] <hggdh> vanhoof: and certainly not for wget
[16:11] <mfisch> vanhoof: what about the squid proxy?
[16:11] <Laney> hrm
[16:11] <cwayne> ogra_: victorp: i've got it running now, its pretty watchable
[16:11] <cwayne> it stutters on occasion,but not horrible, although there's no sound at the moment
[16:12] <vanhoof> mfisch: not sure otp will check in a sec
[16:12] <vanhoof> hggdh: sending you a couple q's
[16:15] <mfisch> ssweeny: did you look into where the brightness slider gets it's initial value from?
[16:15] <mfisch> ssweeny: or just the dim part
[16:17] <keithzg> I don't see any ARM builds of plasma-active on packages.ubuntu.com, is that indeed missing from the repos? (although it's mostly broken thanks to a drop, I'm hoping to try out Active on my Nexus 7)
[16:18] <cwayne> ogra_: once i get it running (which is difficult sometimes) the simpsons trailer looks great actually
[16:19] <ssweeny> mfisch, there's a helper program that talks to sysfs
[16:19] <mfisch> ssweeny: where is it?
[16:20] <victorp> cwayne, watcheable with no sound.. :)
[16:20] <victorp> I have the same
[16:20] <victorp> but with sound is very choppy
[16:20] <cwayne> victorp: ah, i havent gotten the sound to work yet cus i hadn't suspended
[16:20] <victorp> ah
[16:21] <yofel_> keithzg: packages.ubuntu.com only searches on archive.ubuntu.com I believe. the arm packages are on ports.ubuntu.com
[16:21] <victorp> let me know, might be just me ;)
[16:21] <ssweeny> mfisch, source is in gnome-settings daemon, plugins/power/gsd-backlight-helper.c. binary is /usr/lib/gnome-settings-daemon/gsd-backlight-helper
[16:22] <mfisch> janimo: here's the slider bug, I'm looking at it now: https://bugs.launchpad.net/ubuntu-nexus7/+bug/1077054
[16:22] <ubot2> Launchpad bug 1077054 in ubuntu-nexus7 "in some cases, sliding the brightness slider to the right (brighter) actually dims the screen more" [Medium,New]
[16:22] <mfisch> ssweeny: thanks
[16:22] <ssweeny> mfisch, sure. why do you ask?
[16:22] <mfisch> ssweeny: that bug above ^^
[16:23] <ssweeny> mfisch, ah, right
[16:23] <cwayne> mfisch: confirmed
[16:26] <brendand> these figures are strange in 'upower --dump':
[16:27] <brendand>     energy-full:         41.41 Wh
[16:27] <brendand>     energy-full-design:  18.348 Wh
[16:28] <Laney> on the nexus, does anyone else see webkit being busted? http://paste.ubuntu.com/1345526/
[16:28] <Laney> I am on raring, which may or may not be relevant
[16:29] <xnox> Laney: I like the "soso" bit. =))))
[16:30] <Laney> yeah it's pretty cute
[16:36] <achiang> i think webkit is known to be  broken on arm?

[16:37] <ogra> -updates gas a fix
[16:37] <ogra> has
[16:38] <victorp> achiang, that should be a bug then
[16:38] <ogra> victorp, long fixed in quantal-updates
[16:38] <achiang> so we'll get it as soon as we can move to R :)
[16:39] <ogra> right
[16:39] <ogra> ot you fish it out of updates
[16:39] <ogra> or
[16:40] <brendand> janimo, https://bugs.launchpad.net/bugs/1077062
[16:40] <ubot2> Launchpad bug 1077062 in ubuntu-nexus7 "upower says battery is charged when it is not" [Undecided,New]
[16:41] <Laney> I don't think that is the same as the jit fix
[16:41] <Laney> but that SRU is still pending in the queue :/
[16:42] <achiang> ssweeny: wonder if that webkit thing fixes rb-u1
[16:42] <cwayne> achiang: ah, thatd be cool
[16:42] <ssweeny> achiang, interesting
[16:43] <ssweeny> achiang, i should test if the store page is pre-loaded
[16:43] <victorp> cwayne, so should I re-install the image?
[16:43] <ssweeny> in banshee it wouldn't load until you clicked on it
[16:43] <cwayne> victorp: i think so, although now i'm getting pretty similar results as you
[16:43] <cwayne> but i think it's best to do this on a fresh image anyway :)
[16:44] <victorp> I think i will wait until the raring daylies are out
[16:44] <ssweeny> if the crash was in webkit that would explain why i couldn't get a decent trace out of it. that's the only -dbg package i think i didn't have installed
[16:44] <achiang> ssweeny: right, if the new webkit fixes rb-u1, then that's still a bug
[16:44] <achiang> ssweeny: because we shouldn't be loading webkit until it's needed
[16:45] <ogra-cb> well, ubiquity usies webkit a lot
[16:45] <ssweeny> achiang, i'll take another look at it after i'm done playing with gsd
[16:45] <xnox> ogra-cb: just the slideshow....
[16:45] <ogra-cb> yeah
[16:45] <achiang> ok
[16:45] <ogra-cb> wow, i lkie the chromebook
[16:46] <ogra-cb> the weird uk layout needs some getting used to
[16:46]  * ogra-cb is on 12.04 now
[16:46] <xnox> ogra-cb: do not change to the evil side
[16:46]  * xnox proudly uses us layout regardless of the keyboard stickers
[16:47] <ogra-cb> well, then i always have to search for # and stuff
[16:47] <cwayne> mfisch: wanna mark this fix released?https://bugs.launchpad.net/ubuntu-nexus7/+bug/1072086
[16:47] <ubot2> Launchpad bug 1072086 in ubuntu-nexus7 "Having random hostnames can result in offensive hostnames" [High,Fix committed]
[16:48] <ogra-cb> i would just use a german layout and stuckers, but then i rype so much that the stickers look really ugly at some point
[16:48] <ogra-cb> oh WOW
[16:48] <ogra-cb> even the multitouch stuff and gestures work OOTB
[16:48] <ogra-cb> four finger tap gets me the dash
[16:48] <ogra-cb> like on the nexus
[16:49] <ogra-cb> <3 unity-2d
[16:57] <mfisch> ssweeny: can you run this on your laptop?  /usr/lib/gnome-settings-daemon/gsd-backlight-helper --get-max-brightness
[16:57] <ssweeny> mfisch, i get "7"
[16:59] <mfisch> i'm looking for another device with a large range, like 255
[16:59] <mfisch> mine is 20
[17:02] <ogra-cb> ubuntu@nexus7-roccos:~$  /usr/lib/gnome-settings-daemon/gsd-backlight-helper --get-max-brightness
[17:02] <ogra-cb> 255
[17:03] <ogra-cb> but
[17:03] <ogra-cb> ubuntu@nexus7-roccos:~$ cat /sys/class/backlight/pwm-backlight/brightness
[17:03] <ogra-cb> 40
[17:03] <mfisch> ogra-cb: thanks!
[17:03] <mfisch> ogra-cb: can you try to repro a bug for me?
[17:04] <mfisch> ogra-cb: I cannot repro on laptops they dont have enough steps 0-20 isn't a wide enough range
[17:24]  * ogra-cb looks at https://launchpad.net/ubuntu/raring/+queue and sighs
[17:24] <ogra-cb> still no movement for the nexus kernel
[17:26] <brendand> mfisch, about this bug : https://bugs.launchpad.net/ubuntu-nexus7/+bug/1071259
[17:26] <ubot2> Launchpad bug 1071259 in ubuntu-nexus7 "Setting brightness all the way down actually switches off the display completely" [Medium,Confirmed]
[17:26] <brendand> mfisch, i can't confirm it
[17:27] <mfisch> brendand: I did a fix for it today, but it's not in the wild
[17:27] <brendand> mfisch, interestingly, if i move the slider back up afterwards then after a few steps the display does blank
[17:27] <mfisch> brendand: what happens when you slide it all the way left?
[17:27] <mfisch> brendand: that's another bug: https://bugs.launchpad.net/gnome-control-center/+bug/1077054
[17:27] <ubot2> Launchpad bug 1077054 in ubuntu-nexus7 "in some cases, sliding the brightness slider to the right (brighter) actually dims the screen more" [Low,Confirmed]
[17:28] <mfisch> brendand: the slider seems to have confusion in some cases
[17:28] <brendand> mfisch, you describe it differently though
[17:28] <brendand> mfisch, what's the command to get and set the brightness level again?
[17:29] <mfisch> /usr/lib/gnome-settings-daemon/gsd-backlight-helper --help
[17:29] <mfisch> set it to 0
[17:29] <mfisch> brendand: I've also noticed that the slider is off by a bit
[17:29] <brendand> mfisch, ah - then it goes off
[17:29] <mfisch> brendand: for example, the max should be 255, mine seems to max at 252
[17:29] <brendand> mfisch, i can only get it down to 7 with the slider
[17:29] <mfisch> and if you move the slider real fast, it never keeps up
[17:29] <mfisch> brendand: try moving it very slowly
[17:29] <mfisch> brendand: are you using a mouse?
[17:30] <brendand> mfisch, no - i still don't have a working one
[17:30] <brendand> mfisch, my damn wireless mouse managed to break just after a got home :/
[17:30] <mfisch> I'm filing one more about the slider
[17:30] <brendand> mfisch, so 0 and 1 seem to correspond to off
[17:30] <mfisch> brendand: the issue is that all the laptops I've seen have values from like 0-8 or 0-20
[17:30] <mfisch> the slider seems to do some odd stuff with 0-255
[17:32] <mfisch> brendand: that 0=off is being fixed as soon as we have a new kernel
[17:32] <mfisch> brendand: as it's a rather annoying usability issue
[17:35] <brendand> man this backlight is powerful
[17:35] <ogra-cb> way to bright is you ask me
[17:35] <ogra-cb> *if
[17:35] <brendand> mfisch, setting via gsd doesn't seem to impact the slider
[17:35] <mfisch> brendand: yep
[17:35] <mfisch> the slider is problematic ;)
[17:36] <mfisch> brendand: can you confirm this for me?
[17:36] <mfisch> brendand: https://bugs.launchpad.net/ubuntu-nexus7/+bug/1077096
[17:36] <ubot2> Launchpad bug 1077096 in ubuntu-nexus7 "brightness slider doesn't hit max/min value sometimes even when all the way left/right" [Low,New]
[17:37] <mfisch> brendand: also see the new comment I added there, it's my current theory
[17:38] <brendand> mfisch, hmm. i can't repro it right now
[17:39] <brendand> mfisch, if i use the arrow keys to ensure it's all the way right then it says 255
[17:39] <mfisch> brendand: I see it more on the max side, and it's worse with a mouse, because the faster you slide it, the more transitions it misses
[17:39] <mfisch> brendand: I'm not surprised the arrow keys work
[17:39] <mfisch> can you add that comment?
[17:39] <brendand> mfisch, hmm no - i can repro with the arrow keys
[17:40] <brendand> :)
[17:40] <mfisch> ah cool
[17:40] <mfisch> well kinda cool
[17:41] <brendand> mfisch, i can't get it to zero with the arrow keys either
[17:41] <mfisch> ssweeny: what did we decide on that other brightness bug?
[17:41] <mfisch> brendand: odd, I never had an issue with minimum
[17:42] <brendand> mfisch, check it out. slider at the end '237'
[17:42] <brendand> mfisch, move it to the left, '252'
[17:42] <mfisch> ubuntu@nexus7-265143b8:~$ /usr/lib/gnome-settings-daemon/gsd-backlight-helper --get-brightness
[17:42] <mfisch> 0
[17:42] <ssweeny> mfisch, achiang oh-so-slyly implied that i should try to implement the AC/battery transition
[17:42] <mfisch> brendand: yep, that's the bug.  max should be 255
[17:43] <mfisch> brendand: check out what happens if I use a mouse and drag it as fast as possible to the right
[17:43] <mfisch> this should be "max"
[17:43] <mfisch> ubuntu@nexus7-265143b8:~$ /usr/lib/gnome-settings-daemon/gsd-backlight-helper --get-brightness
[17:43] <mfisch> 45
[17:43] <brendand> mfisch, ok, but i was moving the slider 'downwards
[17:43] <mfisch> this slider is all sorts of broke
[17:44] <brendand> mfisch - new bug: 'brightness slider is generally screwed'
[17:45] <mfisch> ssweeny: was there a good reason why the feature was removed?
[17:45] <mfisch> brendand: it certainly was never designed to handle a system with a range of 0-255
[17:45] <ssweeny> mfisch, i assume it's because it was a useful GNOME feature
[17:46] <brendand> mfisch, i can reproduce similarly on my laptop though
[17:46] <mfisch> brendand: what's the max on your laptop?
[17:46] <brendand> mfisch, 24
[17:46] <mfisch> thats the highest I've seen from a laptop
[17:46] <brendand> mfisch, currently it's full right and the value is '19'
[17:46] <mfisch> please note that if you will, I can't repro here
[17:47] <mfisch> most of the laptops were like 7 for a max, much less chance to miss a signal to raise it since the area for 7 is probably 2 inches wide
[17:47] <achiang> ssweeny: i think it would be worth investigating, and i think it's worth talking it through with the -desktop team. please hook up with didrocks or seb128. they should understand what we're trying to do re: power savings, and may have a better suggestion than carrying a gsd patch
[17:47] <ssweeny> achiang, ack
[17:48] <brendand> mfisch, i confirmed your bug
[17:48] <brendand> achiang, i think gsd is broke, so it's not a matter of carrying a patch (at least for some of the issues)
[17:50] <brendand> mfisch, i think a large part of the problem may be to do with the fact that running gsd-backlight-helper --set does not actually change the slider value. there is no feedback loop between the core and the ui or something
[17:50] <ngharo> Trying to get involved in hacking n7 project.  Curious how rootfs is built.. i see projects such as rootstock and live-build; am i on the right track?
[17:50] <brendand> mfisch, if you set volume level in pulseaudio command line then there is immediate feedback in the ui. same for bluetooth settings etc
[17:51] <mfisch> brendand: that would be yet another bug
[17:51] <mfisch> ngharo: what are you trying to hack?
[17:52] <brendand> mfisch, which is easily reproducible on any system
[17:52] <ngharo> mfisch: I'm interested in different DE images and building a Kiosk image
[17:52] <mfisch> ngharo: see if this helps too: http://www.mattfischer.com/blog/?p=285
[17:52] <ogra-cb> ngharo, we use live-build, rootstock is dead
[17:52] <ngharo> ogra-cb: thanks
[17:52] <mfisch> ngharo: my post will tell you how to proceed after you do your live-build
[17:52] <ogra-cb> there will be daily images for ubuntu, kubuntu and lubuntu soon
[17:53] <ngharo> mfisch: awesome thanks
[17:53] <mfisch> ngharo: you need to set LB_BINARY_IMAGES="tar" in your live-build config
[17:53] <mfisch> ngharo: input to this process is a rootfs.tar.gz and output is rootfs.img/boot.img
[17:54] <ngharo> the tarball installer script lives in boot.img it appears; should that also be in the rootfs.tar.gz then?
[17:55] <NekoXP> yikes does nexus7 really use usb audio?
[17:55] <ngharo> before building boot.img
[17:55] <mfisch> ngharo: you'll need all the packages from our PPA in your image
[17:55] <ngharo> roger that
[17:55] <mfisch> ngharo: https://launchpad.net/~ubuntu-nexus7/+archive/ppa
[17:55] <mfisch> ngharo: "tarball-installer" is one of them
[17:55] <ngharo> :D
[17:56] <brendand> mfisch, is it the case on your laptop that changing the brightness using the hw keys updates the gsd-backlight-helper value but not the slider?
[17:56] <ngharo> very cool.  Thanks.  It's reassuring to know I'm not completely off the broken path
[17:56] <mfisch> brendand: lemme check
[17:56] <mfisch> brendand: yes
[17:57] <NekoXP> anyway question, where's the nexus7 kernel coming from? I can see builds in the ppa but not where the source lives
[17:57] <mfisch> NekoXP: in our wiki, let me find you a link
[17:57] <ogra-cb> on kernel,ubuntu.com
[17:57] <ngharo> https://wiki.ubuntu.com/Nexus7/Developers
[17:57] <mfisch> NekoXP: https://wiki.ubuntu.com/Nexus7/Developers
[17:57] <brendand> mfisch, the slider is completely disconnected
[17:58] <NekoXP> wicked
[17:58] <mfisch> brendand: may I suggest a new bug, "was brightness slider written as a practical joke"
[17:59] <NekoXP> :) I don't think gnome settings has a proper dbus interface for backlight
[17:59] <NekoXP> gsd-backlight-helper just tweaks the backlight class files directly, just like the UI does. but they don't have a nice common interface to communicate.
[17:59] <brendand> mfisch, https://bugs.launchpad.net/gnome-control-center/+bug/893851
[17:59] <ubot2> Launchpad bug 893851 in gnome-control-center (Ubuntu) "Brightness adjustment gauge in gnome-control-center screen not responding to brightness hot-keys" [Low,Fix committed]
[17:59] <brendand> mfisch, it's marked as fix released :(
[18:00] <mfisch> lies!
[18:00] <vanhoof> hggdh: plars: mind giving the sha256sum a hit ( hggdh: no installer changes needed )
[18:00] <NekoXP> most gnome guys would consider implementing a backlight setting API on top of a backlight setting sysfs would be redundant duplication of code and not worthwhile. I am sure the freedesktop guys would pitch a fit too if it was not "standardized"
[18:00] <vanhoof> see if we are in sync now
[18:00] <vanhoof> looking like it may have been a server side caching issue
[18:00] <mfisch> brendand: I'll go ask jm-leddy
[18:00] <vanhoof> but if it is local ISP, then we have a fix as well
[18:01] <plars> vanhoof: sure
[18:01] <plars> 55c9802559118ab40e26a2b9d6be105634cbfcecdd54d0b78db34a8b91bcf23c  boot.img
[18:01] <plars> 5908fcf21c71c0c247848e8b534cacf2a17dd1ca7235ba794567b3b63c0563d5  rootfs.img
[18:01] <plars> same as it was earlier for me
[18:01] <brendand> mfisch, well i'm calling it a week. bet you $50 that bug is the source of all these problems
[18:02] <vanhoof> that's accurate for 16gb
[18:02] <brendand> ttyal
[18:02] <plars> so I'm not sure we'd see it unless we change something
[18:02] <NekoXP> mfisch, you should check if your kernel has inotify/fnotify or something in there
[18:02] <mfisch> NekoXP: that bug exists on the standard ubuntu kernel
[18:02] <vanhoof> plars: can also try
[18:02] <vanhoof> wget --progress=bar:force http://hwe.ubuntu.com/uds-r/nexus7/8GB/ubuntu-nexus7-sha256sum.txt  -O /tmp/ubuntu-nexus7-sha256sum.txt
[18:02] <NekoXP> oh.. then.. ouch?
[18:03] <vanhoof> then ls -ltr /tmp
[18:03] <vanhoof> see if its oct 26th or nov 8th
[18:03] <vanhoof> if 26th, then add --no-cache
[18:03] <vanhoof> but a change was made server side
[18:03] <vanhoof> so it may all be sorted now, just want to be sure
[18:03] <plars> vanhoof: oh, I got nov 8
[18:03] <plars> err
[18:03] <vanhoof> sweet
[18:03] <plars> vanhoof: no
[18:03] <plars> vanhoof: oct26
[18:03] <plars> sorry, typo
[18:04] <vanhoof> heh
[18:04] <plars> I was looking at what you said and not the screen
[18:04] <vanhoof> ok
[18:04] <vanhoof> run the same (keep the old file)
[18:04] <vanhoof> and add --no-cache
[18:04] <plars> vanhoof: so I'm still pulling a cached copy I guess... yes with that I get the nov8 copy
[18:04] <plars> with --no-cache that is
[18:04] <vanhoof> ok
[18:05] <vanhoof> with the updated cache expirary still in question, i'll update the installer too just to be cautious
[18:24] <yofel_> DId someone here ever try to build anything KDE related in a armhf pbuilder on amd64 host? Here it ends in automoc4 segfaulting and I seem to be debugging this wrong: http://paste.kde.org/600374
[18:24] <yofel_> (qemu bug?)
[18:25] <mfisch> cwayne: actually I'm just trying to gather info on this bug: https://bugs.launchpad.net/ubuntu-nexus7/+bug/1077062
[18:25] <ubot2> Launchpad bug 1077062 in ubuntu-nexus7 "upower says battery is charged when it is not" [Undecided,New]
[18:25] <mfisch> cwayne: his energy-full value is way too high
[18:26] <ogra-cb> yofel_, yeah, could be, file it
[18:26] <yofel_> ack
[18:26] <ogra-cb> mfisch, i noticed that it is accurate after a reboot
[18:27] <ogra-cb> when it gets into that state
[18:27] <mfisch> ogra-cb: mine is accurate now
[18:27] <mfisch> wondering how to make it inaccurate ;)
[18:28] <ogra-cb> for me it becomes inaccurate if i leave the device on the charger over night
[18:28] <cwayne> mfisch: added, mine was a bit wrong
[18:28] <mfisch> cwayne: okay, go ahead and confirm
[18:28] <mfisch> ogra-cb: thanks
[18:28] <ogra-cb> its usually wrong when i touch the touchscreen to get it out of dpms
[18:28] <mfisch> it would be interesting if we could test that in Android too
[18:29] <cwayne> mfisch: ah, but i dont see the same symptoms
[18:29] <cwayne> mine doesnt say it's charged
[18:30] <ogra-cb> well, after the power patch to the kernel you cantreally compare to android anymore
[18:30] <ogra-cb> well, you can, but the stuff you compare is now different
[18:31] <ogra-cb> cking should just take another look at his patch
[18:42] <mfisch> ogra-cb: assign it to him?
[18:42] <ogra-cb> ++
[18:56] <ogra-cb> ogra@chromebook:~/linux-ac100-3.0.27$ time dpkg-buildpackage -rfakeroot -b
[18:56] <ogra-cb> ...
[18:56] <ogra-cb> real	44m37.117s
[18:56] <ogra-cb> user	55m16.630s
[18:56] <ogra-cb> sys	7m33.140s
[18:56] <ogra-cb> WOW !!!
[18:57] <ogra-cb> https://launchpad.net/ubuntu/+source/linux-ac100/3.1.10-6.10/+build/3962084 shows the last buiuld of the same thing on a panda took 2h 08min
[18:58] <ogra-cb> and i'm even building on the MMC, nnot any fast USB disk or so
[18:58] <cwayne> mfisch: ping
[18:58] <hggdh> vanhoof: on it (was at lunch). Just a note, I saw it happening with the sha *and* the images (both of them)
[18:58] <mfisch> cwayne: YO
[18:59] <cwayne> mfisch: im thinking of marking this incomplete with my last comment,  thoughts? https://bugs.launchpad.net/ubuntu-nexus7/+bug/1075417
[18:59] <ubot2> Launchpad bug 1075417 in unity (Ubuntu) "Unity panel/launcher/dash don't scale with system DPI/font settings" [Undecided,New]
[18:59] <ogra-cb> iirc there is an older upstream bug for the same issue
[18:59] <mfisch> cwayne: there's another bug about login/logout
[18:59] <ogra-cb> mpt should be able to tell you about it
[19:00] <mfisch> maybe we should just ask mpt before filing any bugs?
[19:00] <ogra-cb> for UI stuff that probably makes sense
[19:00] <cwayne> mfisch: hmm, i suppose so.. should we mark this one a dupe?
[19:00] <mfisch> cwayne: marking incomplete while waiting for a response is the correct flow
[19:00] <mfisch> lemme find it
[19:00] <ogra-cb> yeah
[19:01] <mfisch> cwayne: https://bugs.launchpad.net/ubuntu-nexus7/+bug/1075470
[19:01] <ubot2> Launchpad bug 1075470 in light-themes (Ubuntu) "Titlebar buttons are unusably small for tablets/touchscreens and don't scale with the fonts/titlebar" [Undecided,Confirmed]
[19:01] <mfisch> seems to be some overlap
[19:02] <cwayne> hmm yeah
[19:02] <hggdh> vanhoof: bad sha file
[19:13] <hggdh> vanhoof: I tried 4 downloads of the sha file. One failed. I wonder about how the server(s) are set up. http://paste.ubuntu.com/1345950/
[19:17] <[mbm]> it's not just the titlebar buttns that are small, most of the ui is rather small
[19:17] <ogra-cb> most of it scales properly if you set the font to "gigantic" :)
[19:17] <ogra-cb> the panel doesnt scale at all
[19:18] <ogra-cb> it even cuts off the bottom of the letters in the biggest font size
[19:18] <[mbm]> I think thatfor porting adesktop os like ubuntu it'd be better to toss out this concept of absolute coords and clicking directly on things and instead switchtmore mouse style cntrols
[19:19] <ogra-cb> well, there are no actual plans to touch the UI at all for thhis cycle
[19:20] <ogra-cb> there will be very deep focus on UI stuff in 13.10 on the road to 14.04
[19:20] <[mbm]> well, what I mean is that with a laptop, nobody expects the touchpad to be in absolute coords mode, and yet as soon as you put a screen behind it people expect to click directly
[19:21] <[mbm]> if you treat the touchscreen in relative mode, same as a laptop, all the usability issues of things being too small goes away
[19:22] <[mbm]> no ui changes needed
[19:22] <ogra-cb> well, that implies that we would have any influence on the touchscreen driver ... which is a binary blob
[19:23] <[mbm]> translating from absolute to relative would be easy enough with a shim
[19:24] <[mbm]> (I already tried the obvious thing of toggling it with xinput but that isn't supported by the driver)
[19:39] <ben1066> ogra-cb: haha, touch the ui >_>
[19:39] <ogra-cb> :)
[19:40] <ben1066> Still having annoyance with Ubuntu on my desktop...never mind android...multi monitor + nvidia drivers == hell
[19:40] <ben1066> s/android/nexus 7
[19:40]  * ogra-cb has an ATI in hs desktop and no issues with a tripe monitor setup
[19:41] <ben1066> Both monitors are VGA (yeah go me) and one wont even report it's data
[19:41] <ben1066> At the login screen all is good
[19:41] <ben1066> login, the second monitors res is 640x480
[19:41] <ben1066> YAY
[19:42] <ogra-cb> well, probably a setting issue ... or a limitation of the nvidia driver, i guess they dont put much effort into plain VGA anymore
[20:01] <ben1066> i dont get why the login screen is fine
[20:01] <ben1066> AND THEN it breaks
[20:01] <ogra-cb> because gnome-settings-daemon manages the resolution after the login
[20:02] <ben1066> So it's that cocking up
[20:02] <ogra-cb> likely
[20:03] <ben1066> ill reboot back into ubuntu in a sec
[20:03] <ben1066> Now I know why
[20:03] <ben1066> You have been more helpful than #ubuntu :)
[20:04] <ogra-cb> well, we're not a support channel, mind you
[20:04] <ben1066> I know, and I shan't use it as such
[20:04] <ben1066> Still
[20:04] <ben1066> In #ubuntu they insisted it was because I was using the NVIDIA binary not the Ubuntu one
[20:04] <ben1066> despite it partially working...
[20:05] <ogra-cb> well, thats definitely the root cause
[20:05] <ogra-cb> nvidia and xrandr are known to not work well together
[20:05] <mfisch> we have several bugs filed about it ^^
[20:06] <ogra-cb> and gnome-settings-daemon simply does everthing regarding the resolution settings via xrandr
[20:07] <mfisch> yep
[20:08] <ogra-cb> i doubt it makes much difference which of the binary drivers you use though
[20:08] <ben1066> Is there a proper solution?
[20:08] <ogra-cb> the ubuntu one is simply better maintained, and gets a bunch of tests before going into the distro
[20:09] <ogra-cb> yes, make nvidia fix it :)
[20:09] <ben1066> Other than that, that's hardly an option
[20:09] <ogra-cb> you asked for proper :)
[20:10] <vanhoof> hggdh: still about
[20:10] <ben1066> Apparently the drivers have xrandr now...or is it broken?
[20:11] <ogra-cb> no idea, no first hand experience with recent nvidia here
[20:12] <ogra-cb> i know its accused to be broken, they might have fixed it
[20:12]  * ogra-cb only uses nvidia on arm 
[20:12] <ben1066> Nvidia is great on windows
[20:12] <ben1066> On linux, aparently not so much
[20:12] <ogra-cb> havent touched it in years on x86
[20:13] <ogra-cb> doesnt it come with a gui configuration tool ?
[20:13] <ogra-cb> you should be able to set it up there
[20:13] <ben1066> the nvidia driver does
[20:13] <ben1066> it sets xorg.conf
[20:13] <ben1066> Still gets reset on login
[20:13] <cwayne> ogra-cb: i thought you only used everything on arm :)
[20:14] <ogra-cb> cwayne, i only work on arm stuff since 4 years ... there was a time before that
[20:15] <ogra-cb> i.e. LPIA
[20:15] <ogra-cb> :)
[20:17] <infinity> *shudder*
[20:17] <mfisch> could be worse
[20:18]  * mfisch was working on Intel space heater technology aka Itanium
[20:18] <infinity> ia64 had a much longer life than lpia.
[20:18] <infinity> Though, I'll never forgive ia64 for killing parisc.
[20:19] <mfisch> HP wanted parisc dead though
[20:20] <infinity> mfisch: I'm unconvinced that's true, rather that they were contractually obliged to let it die.
[20:20] <infinity> (Which, sure, means that the people who signed that contract wanted it dead, but... They also didn't realise at the time that trading parisc for ia64 was a very bad idea)
[20:22] <mfisch> infinity: HP co-invented the Itanium chip and handed it to Intel
[20:23]  * mfisch knows because /me was there during the early itanium days
[20:23] <mfisch> infinity: unless you mean once they realized the mistake they made ;)
[20:24] <infinity> mfisch: Where the engineering came from is less interesting than the contract that pretty much tied their hands WRT continuing development on PARISC afterward.
[20:25]  * ogra-cb really loved alpha
[20:25] <mfisch> true, but by then all the HP chip designers were working on Itanium for a few years, right?  they'd be behind.  then in 2003 +/- 1 year, HP essentially "traded" the chip designers to Intel here in Fort Collins, probably elsewhere
[20:27] <vanhoof> ogra-cb: i still have 3 DS10L's that work :D
[20:27] <vanhoof> ogra-cb: all the rest have died :)
[20:27] <ogra-cb> sweet !
[20:27]  * vanhoof loved build server closet cleaning days in the past ;)
[20:27] <ogra-cb> vanhoof, you werent in CPH ... :(
[20:27] <vanhoof> ogra-cb: i tried!
[20:27] <vanhoof> four times
[20:27] <ogra-cb> i actually had the ac100 displays with me
[20:27] <vanhoof> ah crap :\
[20:28] <ogra-cb> well, we just have to convince achiang that we need to do a sprint ;)
[20:28] <vanhoof> ogra-cb: since we moved saturday, i flew sunday, which was a big mistake trying to leave the east coast w/ the hurricane :\
[20:28] <ogra-cb> then i can bring them
[20:28] <ogra-cb> yeah
[20:28] <mfisch> vanhoof: did you get stuck?
[20:28] <vanhoof> best I could get there was tuesday night, jetlag + two days, seemed, meh
[20:28] <vanhoof> ogra-cb: :D
[20:28] <ogra-cb> right, that would be nonsense
[20:29] <vanhoof> mfisch: no just cancelled luckily
[20:29] <vanhoof> mfisch: but sat for many hours here at the airport
[20:29] <vanhoof> all my original flights went through nyc*
[20:29] <vanhoof> newark, then jfk, then chicago, then flat out NO
[20:30] <mfisch> I flew via IAD
[20:30]  * ogra-cb always tries to enter/exit the US via philly
[20:30] <mfisch> that airport is an embarassment
[20:30] <vanhoof> plars: hggdh: ogra-cb: 1.5 of the installer is in the ppa (safety measures) + server side change, should be all good to go
[20:30] <ogra-cb> yay
[20:30] <vanhoof> yeah if I'd have left saturday or even a few hours earlier sunday i would have made it
[20:31] <vanhoof> ogra-cb: i hate squid :D
[20:31] <ogra-cb> heh
[20:31] <mfisch> why dont we just turn squid off?
[20:31] <vanhoof> luckily i was able to finally reproduce it
[20:31] <vanhoof> i thought everyone was crazy :)
[20:31] <mfisch> I assume the number of downloads has dropped off
[20:31] <vanhoof> mfisch: cache timeout is 15m now
[20:32] <vanhoof> and we force --no-cache on downloads client side
[20:32] <vanhoof> so we should be a'ok
[20:32] <vanhoof> there are other large relics on the same machine i'd like to have squid for so I dont get yelled at :D
[20:34] <vanhoof> hggdh++ thanks for help w/ testing today
[20:35] <hggdh> vanhoof: yw
[20:41] <mfisch> vanhoof: can we mark https://bugs.launchpad.net/ubuntu-nexus7/+bug/1077007 as fix released?
[20:41] <ubot2> Launchpad bug 1077007 in ubuntu-nexus7 "Downloaded images failed checksum validation" [Critical,Fix committed]
[20:42] <vanhoof> yeah I was going to wait to hear back from the reporters
[20:42] <vanhoof> but im pretty confident its fixed
[20:57] <hggdh> vanhoof: just confirmed it works. At least so far ;-)
[21:59] <ngharo> Does anyone have a live-build for n7 directory/config checked in anywhere?