**** BEGIN LOGGING AT Wed Nov 07 03:00:02 2012 Nov 07 08:07:00 so I boot ubuntu-12.04 on my pandaboard Nov 07 08:07:19 and it gets to X, but I don't seem to have any sort of a window manager running Nov 07 08:07:30 I can right click on the desktop to get a small context menu Nov 07 08:07:37 but no more menus. Nov 07 08:10:03 ok, if I run gnome-terminal from ssh, that seems to work Nov 07 08:10:15 I guess it is just the launcher that is broken/not running. Nov 07 08:11:48 <[mbm]> what session are you trying to use? if you're running a *dm you can set the session on the login screen Nov 07 08:15:50 the default one. Nov 07 08:15:58 I also set it up to not have a login screen, evidently? Nov 07 08:16:42 what is the default these days, unity? Nov 07 08:32:13 <[mbm]> lightdm Nov 07 08:37:54 ps says lightdm is in fact running. Nov 07 09:57:18 I see (in backlog) that so far we do not got chromebook users here Nov 07 09:57:51 hrw, waiting for mine :) Nov 07 09:58:19 ogra_: you still use ac100? Nov 07 09:58:51 sure Nov 07 09:59:08 i didnt use it much at UDS but always had it with me Nov 07 09:59:22 i doubt the chromebook will change that, lets see Nov 07 11:19:18 janimo, did you upload the kernel to raring yet ? Nov 07 11:19:34 * ogra_ doesnt see it in any queue Nov 07 11:23:47 ogra_, not yet Nov 07 11:24:34 I wonder if I should keep both quantal and raring branches in git Nov 07 11:25:12 well, essentially the difference should just be in the changelog entry Nov 07 11:25:35 i.e. the distro name Nov 07 11:26:49 http://www.broadcom.com/products/Wireless-LAN/802.11-Wireless-LAN-Solutions/BCM4330 Nov 07 11:26:52 oh, wow Nov 07 11:27:05 i didnt know our wlan chip also has an FM radio builtin Nov 07 11:27:37 i noticed that NM offers WIMAX .... Nov 07 11:29:19 <[mbm]> hmm never thought of chromebook; figured they would be locked down and only run chromeos Nov 07 11:29:55 janimo: Better to keep both branches, in case there is a reason to folk based on SRU vs. development release in the future. Nov 07 11:29:58 i think they already offer an ubuntu image Nov 07 11:30:10 persia, there wont be SRUs Nov 07 11:30:28 I heard they took extra effort to make it easy to replace the OS in the Chromebook Nov 07 11:30:29 as soon as we have working raring images we'll mainly care for raring only Nov 07 11:30:31 ogra_: Why not? Nov 07 11:30:51 ogra_: You will. Maybe someone else cares. It's not like an extra git branch is that much overhead. Nov 07 11:30:55 and will ask people to either upgrade or do a fresh install off an "alpha" Nov 07 11:31:03 <[mbm]> I remember there was a pc bios for the early chromebooks, just haven't heard anything about the latest Nov 07 11:31:11 (and if apw's new system for universe kernel management happens, it would be nice to be prepared to match it) Nov 07 11:31:15 persia, for only a handfull of chars difference ? Nov 07 11:31:19 i think it is :) Nov 07 11:31:37 its really only the distro name in the changelog entry that should differ Nov 07 11:31:48 It is? I find it more work to *delete* a branch than leave it there, if there are no changes for it. Nov 07 11:31:59 uploads should go simultaneously to both places Nov 07 11:32:08 until we abandon one of them Nov 07 11:33:10 * persia grumbles about policies and compliance and best practices and bows to the inevitable pragmatism that comes when folk believe they have limited developer resources Nov 07 11:33:14 but currently even an empty package in raring would help me, starting images is blocked on missing a kernel atm Nov 07 11:33:30 haha Nov 07 11:33:37 Why didn't the quantal kernel get copied over when raring opened? Nov 07 11:33:50 because it doesnt exist in quantal Nov 07 11:34:21 Ah. That's a good reason. It's so good that I don't care if there's a quantal branch anymore. Nov 07 11:34:27 we started working on that three weeks before release Nov 07 11:34:59 and the release team had better stuff to do than reviewing new kernels at that time Nov 07 11:35:06 So, in fact, there *shouldn't* be any SRUs: just raring backports. Nov 07 11:35:18 just PPA uploads in fact Nov 07 11:35:34 Why not backports? Nov 07 11:35:49 well, if someone from the backports team wants to care Nov 07 11:36:00 the 12.10 image is largely a throw away thing Nov 07 11:36:39 its heavily hacked in many places and should only serve as a demo Nov 07 11:36:51 the "real thing" will be the raring image Nov 07 11:37:53 ogra_: As I understand it, arranging a backport consists of running `requestbackport packagename` and confirming the test result. But if the image itself is hacked, rather than just the kernel, yeah, nobody should run quantal. Nov 07 11:38:33 the image has -updates,-security and -backports enabled anyway and we dont encourage people to enable them Nov 07 11:38:49 in fact it will break your desktop since yesterday Nov 07 11:38:54 For a demo, that's probably best. Nov 07 11:39:12 I'll stop heckling for now, as the answer to everything will be the same :) Nov 07 11:39:23 (since there is a new unity that overrides our version in the PPA and no intend to update the PPA package) Nov 07 11:58:21 persia, do i read that right that this license allows redistribution as long as nobody sues broadcom because we distributed it ? https://android.googlesource.com/platform/hardware/broadcom/wlan/+/43362466e68ebaed8b7ca5eaf5c9cede8b7a0f57/bcmdhd/firmware/LICENSE.TXT Nov 07 11:59:01 janimo, ^^^ that sounds like we could use it legally Nov 07 11:59:08 to me at least Nov 07 11:59:26 ogra_, pftt, but I wanted to sue Broadcom! Nov 07 11:59:31 haha Nov 07 11:59:57 ogra_, I will wait till kernel-team/legal whoever gives a verdict :) Nov 07 12:00:10 yeah, i added a ling to it to the bug Nov 07 12:00:16 *link Nov 07 12:00:51 * janimo installs bash-completion on the nexus7 Nov 07 12:02:09 brave ! Nov 07 12:06:08 ogra_: I don't read it quite that way. Nov 07 12:06:29 :( Nov 07 12:07:30 2.3(b) makes me think that it's unsuitable for mirroring Nov 07 12:07:45 Check with the mirrors team, but I suspect it needs to be distributed a different way. Nov 07 12:08:00 sigh Nov 07 12:08:05 Because mirrors distribute Ubuntu under the assumption that they accept no liability in doing so. Nov 07 12:08:30 well, i wonder if thats true for all the closed bits we have Nov 07 12:08:50 The above does not represent legal advice: if actually intending to distribute this software, confer with your own counsel and counsel for any organisations providing hosting services Nov 07 12:09:00 I don't propose to do an audit :) Nov 07 12:09:18 * persia gets in enough trouble for reading licenses already Nov 07 12:10:52 The provision in 3.2 to promptly report all bugs fails the desert-island test for DFSG too, although the word "reasonable" might be sufficient to make it pass. Nov 07 12:11:28 well, i doubt linux-firmware is anywhere close to DFSG anywaqy Nov 07 12:11:49 I do like the wording of 3.3 though: it doesn't actually discriminate against field of endeavour, but not for lack of trying :) Nov 07 12:12:24 I did review chunks of linux-firmware at some point in the past, and most of it was only modification-restricted. Nov 07 12:12:45 I didn't review all of it, and this was enough years ago that much has probably changed, so you could be right today. Nov 07 12:13:05 i think it had a real audit at some point Nov 07 12:13:09 beyond developers Nov 07 12:13:21 Mind you, modification-restriction makes it non-DFSG-free, but the rest of the tests pass. Nov 07 12:13:49 heh Nov 07 12:14:03 its hard to modify binary blobs anyway Nov 07 12:14:10 The question to ask when being told that is "on whose behalf"? The license you showed me is likely suitable for Canonical to distribute it if Canonical wants, but may not be acceptable to some mirrors. Nov 07 12:14:22 Um, no. That'S why xxd is shipped by default. Nov 07 12:16:16 Anyway, I have a warm bed I wish to use. Ask an archive admin for an official Ubuntu opinion, or ask the mirrors team for a hint if you don't want to bother the archive admins yet. Nov 07 12:16:41 yeah, i asked at the bug, lets see what the kernel team thinks Nov 07 12:16:47 sleep well ! Nov 07 12:41:16 janimo, so rtg asks us to not ship it in linux-firmware at all but in our kernel package Nov 07 12:41:32 (there was just a discussion on #ubuntu-kernel) Nov 07 12:41:56 ogra_, ok. But that has little to do with legality to distribute right? Nov 07 12:42:25 right, just with "pfft its a special device, come back if more people use it" Nov 07 12:42:34 or something along these lines Nov 07 12:43:20 apparently linux-firmware is mostly generated by looking at the mainline kernel and checking for MODULE_FIRMWARE() calls Nov 07 12:43:45 if ours does show up there at some point it will be auto-included Nov 07 12:43:54 (or at least attempted to) Nov 07 12:44:38 ogra_, I thought this broadcom chip combo was also in quite a few x86 machines Nov 07 12:44:48 i thought so too Nov 07 12:45:14 and theoretically http://linuxwireless.org/en/users/Drivers/brcm80211 should actually work for us Nov 07 12:45:22 (the SDIO driver) Nov 07 12:45:23 but anyway, we can include it in the kernel Nov 07 12:45:31 ogra_, is that in 3.1? Nov 07 12:45:48 practically i didnt get it to work, though that might be totally my fault Nov 07 12:45:52 having a newer kernel would help in many regards I think Nov 07 12:45:54 janimo, in staging iirc Nov 07 14:04:17 janimo, btw, i think our kernel really has a math problem, most numbers i see seems to be doubled up ... i.e. these 600M ram used in hatp, or the charging time in upower -d output Nov 07 14:04:21 *htop Nov 07 14:06:28 ogra_, where can you see the alternate/real numbers? Nov 07 14:14:33 does anyone running Android on nexus7 see ambient light having any effect on screen brightness? I keep changing the light or even covering what I think is the sensor aperture but nothing changes Nov 07 14:25:10 janimo: I'll ask our team, I think a few have personal devices Nov 07 14:30:39 carif: janimo has some questions about the ambient light sensor in Android Nov 07 14:30:47 janimo: carif is still running Android Nov 07 14:32:02 mfisch, janimo, pl walk me through the test you want? Shine some light on tne n7 and see if it changes brightness? Nov 07 14:32:55 carif, well I have no idea what it would take for it to change brightness. That's the issue I see, I don't see a difference in brightness even if it is set to automatic Nov 07 14:34:07 janimo, i have the brightness setting to be automatic and about midway for the slider Nov 07 14:34:16 carif, I can adjust it manually if automatic is not on though Nov 07 14:34:52 janimo, very good, so you're asking the question what changes the brightness when automatic is actually set? Nov 07 14:35:01 carif, yes Nov 07 14:35:20 my experiment in covering the sensor or shining a lamp on the tablet do not seem to have an effect Nov 07 14:35:30 or if there is one it is unnoticable Nov 07 14:37:13 janimo, i confirm your experiment, i don't know what makes the brightness change however Nov 07 14:37:25 carif, ok thank for the confirmation Nov 07 14:37:48 I'll check on another android device too later Nov 07 14:40:19 janimo, no idea, but i simply cant belive we eat over 600M nor are the estimated hours for charging (18h in the beginning, after 4 it dropped to 9h) in upower -d right Nov 07 14:41:37 to me everything seems doubled up Nov 07 14:41:39 ogra_, so maybe bugs in battery level reporting and memeory measurements are known to not be very accurate :) Nov 07 14:42:13 i also see a constant load of 2.xx Nov 07 14:42:20 but nothing that produces it Nov 07 14:42:46 and iirc marvin24 once added as fix for to high load reporting to the ac100 tree Nov 07 14:42:54 (or nvidia did and he merged it) Nov 07 14:44:53 ogra_, never heard of this before. If it happened in ac100 then hopefully we can fix it too Nov 07 14:51:45 janimo, bug 985661 Nov 07 14:51:46 Launchpad bug 985661 in linux (Ubuntu) "High load average" [Medium,Triaged] https://launchpad.net/bugs/985661 Nov 07 14:51:58 I can confirm that following commit is responsible: "sched: Fix nohz load accounting" Nov 07 14:51:58 SHA: 3a50863f6706ece7719a68be0ae57957164a0f0c Nov 07 14:52:05 (comment #35) Nov 07 14:52:36 though that claims the breakage was originally added in a 3.2 kernel Nov 07 14:53:07 ogra_, I think our 3.1 tree has backports of several commits Nov 07 14:53:43 http://thread.gmane.org/gmane.linux.kernel/1310462 Nov 07 15:04:41 * marvin24 can't remember fixing something like this Nov 07 15:08:19 well, i think it might just have been mentioned in #ac100 Nov 07 15:08:44 or i saw it in a erge in the changelog osr so Nov 07 15:11:53 xnox, the resultimg images from the tools look good, i havent flashed one yet but what the tools produce seems to definitely be fine Nov 07 15:13:02 -rw-rw-r-- 1 ogra ogra 1,7M Nov 7 16:13 test2.img Nov 07 15:13:02 -rw-rw-r-- 1 ogra ogra 6,0G Nov 7 16:12 test.img Nov 07 15:13:19 test2 is the sparse one (both are empty) Nov 07 15:14:16 hmm, producing the saem with ext2simg instead of using img2simg gets it even smaller Nov 07 15:14:37 err, no, bigger Nov 07 15:14:39 misread Nov 07 15:29:08 ogra_: I'd like to add an autopkgtest for it. Does the test_* utility do anything useful? Nov 07 15:29:22 no idea Nov 07 15:29:24 ogra_: does it simply need an ext4 image - which can be created on the fly? Nov 07 15:29:32 ack Nov 07 15:29:55 ogra@anubis:~/Desktop/nexus/builder/tmp$ test_ext4fixup -3 5 rootfs_test.img Nov 07 15:29:55 error: ext4_parse_sb: superblock magic incorrect Nov 07 15:29:55 test_ext4fixup: ext4fixup failed!\n Nov 07 15:30:44 hmm... Nov 07 15:31:13 well, that one was built with img2simg Nov 07 15:31:28 likely not the right tool for ext4 images if there is edxt2simg ;) Nov 07 15:32:28 xnox, so, hmm ... it even fails with an image properly created using make_ext4fs Nov 07 15:35:02 interesting so what does test_* thingy suppose to do then? =P Nov 07 15:35:35 heh, i wonder that too Nov 07 15:35:52 i like that it so nicely adds a \n :) Nov 07 15:37:17 in any case the image size isnt acceptable that i get with ext2simg Nov 07 15:45:40 hey guys Nov 07 15:45:51 yo ! Nov 07 15:46:14 dholbach, welcome to ARM :) Nov 07 15:46:28 hello ARM hippies :) Nov 07 15:46:31 This channel sure has gotten busier since UDS. :P Nov 07 15:46:41 heh, yeah Nov 07 15:47:01 infinity, we lost Grue though Nov 07 15:47:17 he went away grumpy yesterday Nov 07 15:48:06 bugs 297368 and 1049935 are tagged 'mobile' but are not nexus7 related - do you think it'd make more sense to use a more specific tag than 'mobile'? Nov 07 15:48:06 Launchpad bug 1049935 in modemmanager (Ubuntu) "Crash on connecting Sierra Wireless mobile hotspot" [Low,Incomplete] https://launchpad.net/bugs/1049935 Nov 07 15:48:07 Launchpad bug 297368 in gnome-phone-manager (Ubuntu) "Sony-Ericsson W910i Not Supported in USB Mode" [Undecided,New] https://launchpad.net/bugs/297368 Nov 07 15:48:18 I was just reviewing the bug filing instructions on https://wiki.ubuntu.com/Nexus7 Nov 07 15:49:09 achiang, ^^^ Nov 07 15:49:14 dholbach, I think it should be up to you, you know best practices better and what makes sense globally for ubuntu Nov 07 15:49:24 is someone regularly triaging https://bugs.launchpad.net/ubuntu/+bugs?field.tag=mobile and adding the ubuntu-nexus7 task? Nov 07 15:49:27 mobile was the initial tag but it may have been misused at times Nov 07 15:49:33 dholbach, these tags are most likely 4 years old or older from the original ubuntu-mobile team Nov 07 15:49:37 I don't care too much :) Nov 07 15:49:47 I was just wondering when I went through the list Nov 07 15:49:51 we used to use that tag before we got renamed to -arm Nov 07 15:50:02 luckily enough it's just 2 out of 12 bugs Nov 07 15:50:06 they should all be invalidated actually Nov 07 15:50:19 so theoretically we could just leave things as they are and untag the two I mentioned Nov 07 15:50:26 ++ Nov 07 15:50:51 ok, WFM Nov 07 15:51:16 dholbach: as for triaging, we do triage bugs, but mostly in the ubuntu-nexus7 project. Nov 07 15:51:40 we could start triaging that tag though Nov 07 15:52:03 maybe running a script which spits out a list of bugs which are 1) against Ubuntu with tag 'mobile' and 2) not in the ubuntu-nexus7 project might help Nov 07 15:52:11 just so we don't overlook bugs filed by testers Nov 07 15:59:46 achiang, well, i thought the idea was to have the tag in raring through apport/ubuntu-bug Nov 07 15:59:57 right Nov 07 16:00:00 ubuntu-bug Nov 07 16:00:09 who is signed up for that WI? :) Nov 07 16:00:11 so future bugs will definitely carry it Nov 07 16:00:17 might be me Nov 07 16:00:26 still wading through WIs this week :) Nov 07 16:01:13 achiang, though we should probably reconsider the choice of "mobile", we might come across some old LPIA cruft :) Nov 07 16:01:49 ogra_: i don't think i suggested it... ;) Nov 07 16:01:57 * achiang twitches re: lpia Nov 07 16:02:07 someone suggested it in the discussion Nov 07 16:02:13 cant remember who that was Nov 07 16:02:46 is anyone interested in a way to see the 'top' entry for a specific binary? Nov 07 16:06:45 surely you'd get that from "ps aux | grep name" Nov 07 16:07:15 or some variant Nov 07 16:12:51 NexoXP - well yeah, exactly. but it's nowhere near that short Nov 07 16:13:17 NekoXP, problem is top only accepts PIDs to filter the list Nov 07 16:13:41 top -p `ps aux | grep $1 | head -n1 | awk '{print $2}'` Nov 07 16:14:04 point taken Nov 07 16:14:04 infinity, debuild creates a new orig.tar.gz by default if there is no orig. Can it be told to use one of the other compression methods Nov 07 16:14:20 brendand, pgrep ? :) Nov 07 16:14:21 infinity, I just debuild out of the git tree with no orig at all so far Nov 07 16:15:03 janimo: Erm, if there's no orig, it builds natively. But yes, I'm pretty sure you can tell it to compress the native package differently in debian/source/options Nov 07 16:15:22 infinity, thank. I'll check that out Nov 07 16:15:22 janimo: (Only if using a v3 source format, I suspect) Nov 07 16:15:36 infinity, yes just switched linux-nexus7 to 3.0 to see how it works Nov 07 16:15:52 and tought of taking advantage of alternate compressions Nov 07 16:15:53 janimo: did you look into the "Dim screen to save power" bug also or just the ambient light bug Nov 07 16:16:19 mjust the ambient one as I have a WI to enable the get the light sensor in the kernel working Nov 07 16:18:14 ok Nov 07 16:26:05 " Your Amazon.co.uk order of "Samsung Chromebook Wifi (L..." has been dispatched" Nov 07 16:26:08 \o/ Nov 07 16:28:51 wow Nov 07 16:49:41 ogra_: ping re: https://bugs.launchpad.net/ubuntu-nexus7/+bug/1065644 - do we have a theory that it is an nvidia driver problem or a plymouth problem? Nov 07 16:49:42 Launchpad bug 1065644 in ubuntu-nexus7 "plymouth causes a hard reset of the nexus" [Critical,Confirmed] Nov 07 16:50:23 achiang, well all i know is that nvidia recommends to remove plymouth completely because it breaks your system Nov 07 16:50:50 we dont really know which side of the fence is at fault, but i have a WI somewhere to research that Nov 07 16:50:51 ogra_: hm, so known issue for them Nov 07 16:50:59 right Nov 07 16:51:11 its prominently in their usage docs on developer.nvidia.com Nov 07 16:51:45 (for tegra2/3) Nov 07 16:52:51 achiang, i'll do some debugging and add inof to the bug once i'm through the image build stuff Nov 07 16:52:56 *info Nov 07 16:53:08 ogra_: np, just going through some of my WIs Nov 07 16:53:29 right, i did the same today :) Nov 07 16:53:42 ogra_: btw, how do you find your WIs? /me has never really used blueprints before Nov 07 16:54:09 you can check the blueprints you are involved in on your presonal LP page Nov 07 16:54:26 ok, i've done that Nov 07 16:54:27 what i personally do though is to just take my personal schedule on summit.u.c Nov 07 16:54:38 but i have to go through the blueprints and then troll for WIs? Nov 07 16:54:38 and go through the sessions i attended Nov 07 16:54:45 there's no way to automatically see my WIs? Nov 07 16:54:58 ojnce your WIs are proper and the specs are approved you can use status.ubuntu.com though Nov 07 16:55:10 ah Nov 07 16:55:17 its just inconvenient during the approval phase Nov 07 16:55:23 later it gets easy Nov 07 16:55:52 hm, i don't appear here - http://status.ubuntu.com/ubuntu-raring/people.html Nov 07 16:56:06 your team isnt on there i guess Nov 07 16:56:25 achiang: do you have workitems on blueprints that are "accepted for raring" in the series goal? Nov 07 16:57:12 ah, i was looking at this one -- https://blueprints.launchpad.net/ubuntu/+spec/desktop-r-tablet-desktop-convergence-divergence which does not have it Nov 07 16:57:23 right, it might needs at least one WI in an approved spec for even generating a report Nov 07 16:57:59 ok Nov 07 16:58:17 http://status.ubuntu.com/ubuntu-raring/u/ogra.html definitely has something for me already Nov 07 16:58:20 unrelated question: if we're not going to have alphas, when do we expect to start generating dailies? :) Nov 07 16:59:13 ah, no, it doesnt need to be approved, needs to be "accepted for raring" i think Nov 07 16:59:22 achiang, asap Nov 07 16:59:40 I see x86 already has dailies so we should too. ogra is probably waiting for my kernel upload :) Nov 07 16:59:46 achiang, i would like to get going this week but fiurst need a kernel package ... that takes a bit Nov 07 16:59:48 achiang: we have dailies. and we are meant to have a fully working set every two weeks. Nov 07 16:59:49 ogra_: ok, thanks Nov 07 16:59:50 re firmware I still want to know whether we can ship it Nov 07 17:00:02 janimo, well, for more than that ... Nov 07 17:00:03 I mean we were told by rtg not to put it in linux-firmware Nov 07 17:00:10 but yeah, kernel is one blocker Nov 07 17:00:12 achiang: so we don't have alphas just many more littlealphas Nov 07 17:00:18 but that does not mean we can put it anywhere for that matter Nov 07 17:00:44 janimo: we are meant to have a bi-weekly testing senergy on a known set. Nov 07 17:01:02 janimo, well, i think the other fw i found in the generic android wlan tree has a looser licence Nov 07 17:01:27 we might be able to ship that, someone has to test if it actually works though :) Nov 07 17:01:37 xnox: ogra_: which blueprint talks about installer support in ubiquity? Nov 07 17:01:37 it claims to be for 4330 Nov 07 17:02:06 achiang: huh? ubiquity is the installer.... Nov 07 17:02:12 achiang, https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-arm-ubiquity Nov 07 17:02:21 achiang: or are you after usb-creator? Nov 07 17:02:22 xnox: sorry, me english no good, but ogra_ figured out what i was asking ;) Nov 07 17:02:23 xnox, i bet he meant nexus :) Nov 07 17:02:33 ack. Nov 07 17:02:35 achiang, thats for oem-config though Nov 07 17:03:08 https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-arm-usb-creator-fastboot-support Nov 07 17:03:15 is the installation/flashing Nov 07 17:03:25 ogra_: ah, ok. i'm just trying to close out as WONTFIX - https://bugs.launchpad.net/ubuntu-nexus7/+bug/1072681 Nov 07 17:03:25 Launchpad bug 1072681 in ubuntu-nexus7 "ubuntu-nexus7-installer should have some logging" [Medium,Confirmed] Nov 07 17:03:40 heh Nov 07 17:04:06 achiang, i commented Nov 07 17:04:43 brendand surely has a point there ... and its easy to add logging to the traball extraction Nov 07 17:05:25 ogra_: no, he was talking about our zenity installer, not tarball-installer Nov 07 17:05:32 ah Nov 07 17:05:41 well, usb-creator does logging already i think Nov 07 17:05:44 ogra_: brendand ran into issues with our zenity installer at UDS, but eventually got it working Nov 07 17:05:45 so does oem-config Nov 07 17:05:54 but the tarball installer should surely get some Nov 07 17:05:56 ogra_: right, and we won't invest anymore time into the zentiy installer Nov 07 17:06:02 ogra_: sure, file a new bug then. :) Nov 07 17:06:10 k, just close that one then Nov 07 17:06:32 already done, we spent another 5m talking about it. ;) Nov 07 17:06:33 i wont file a bug, i'll just implement it with the first upload :) Nov 07 17:06:43 oh come on ... you manager you Nov 07 17:06:45 :P Nov 07 17:07:28 :) Nov 07 17:12:36 does charging the nexus take extremely long for anyone else or is it just me ? Nov 07 17:13:19 ogra_: yes, but it's quicker if you use "official" cable & plug. Nov 07 17:13:27 probably these 18h it showed me initially were actually correct ... it definitely hangs on the charger since i started my workday Nov 07 17:13:32 xnox, i do Nov 07 17:13:36 its at 41% Nov 07 17:13:39 hmm =/ Nov 07 17:13:42 after a fukll workday Nov 07 17:14:11 also I found that the connectors on the nexus are not that good. E.g. the headphones fall-out and the charger disconnects often. Nov 07 17:14:58 ubuntu@nexus7-roccos:~$ upower -d|grep state Nov 07 17:14:58 state: fully-charged Nov 07 17:14:58 ubuntu@nexus7-roccos:~$ upower -d|grep percentage Nov 07 17:14:59 percentage: 41.4464% Nov 07 17:14:59 ubuntu@nexus7-roccos:~ Nov 07 17:15:02 OH ! Nov 07 17:15:16 janimo, there is something wrong here Nov 07 17:15:57 so I have a weird question, has anyone ever seen any sd cards that actually support trim or secure trim or is this just one standard that got stuck on eMMC? Nov 07 17:15:59 * ogra_ guesses thats ckings work Nov 07 17:18:13 ogra_, mine is not fully charged but either charging or discharging depending on whether the cable is plugged in or not Nov 07 17:18:22 ogra_, but probably a bug indeed Nov 07 17:18:37 janimo, well, if you keep the cable plugged it should at some point go to 100% Nov 07 17:18:47 sure Nov 07 17:18:52 in a few hours I guess Nov 07 17:18:55 and not think it is fully charged and report 41% :) Nov 07 17:19:06 6.0 according to upower Nov 07 17:19:25 and i'm pretty sure after more than 8h charging it should be at 100% it surely was with the former kernel Nov 07 17:20:07 i think chraging it to 100% never took me more than 2h actually Nov 07 17:20:32 so i guess cking has to revisit it :) Nov 07 17:20:45 any reason I should not use xc compression on the kernel package (besides compressing it being sloow) ? Nov 07 17:20:54 infinity, ^ ? Nov 07 17:20:56 bootspeed Nov 07 17:21:04 oh, the package Nov 07 17:21:04 ogra_, the source package Nov 07 17:21:09 not vmlinuz Nov 07 17:21:13 * ogra_ doesnt care Nov 07 17:21:31 ogra_, I am not sure whether build servers can handle it, whether it is all stable etc Nov 07 17:21:45 60M vs 100M for the sourece tarball Nov 07 17:21:49 well, someone has to try it anyway :) Nov 07 17:22:08 i think we have some xz packages already though Nov 07 17:22:19 and havent seen issues about it on arm Nov 07 17:22:39 iirc xnox had a list in the xz packages session ;) Nov 07 17:22:59 * ogra_ remembers some font package Nov 07 17:25:39 heh, so my percentage jups back and forth between 41.4464% and 41.4364% Nov 07 17:25:45 doesnt move beyond that Nov 07 17:27:20 it's trying to converge to 42, of course Nov 07 17:27:52 janimo: We have lots of xz source packages, infrastructure all deals with it fine. Nov 07 17:27:58 well, if it wouldnt go down to .4364 all the time i would tend to belive that Nov 07 17:28:05 janimo: It may take longer to decompress at build time, but meh. Nov 07 17:29:25 ogra_, it does converge on 42 but due to miscalibration you see the values shifted a bit Nov 07 17:30:14 well, i'm pretty sure it sits at 41.xxxx% since more than 1h ... and it thinks its fully charged, if the kernel thinks the same its very unlikely to ever go beyond Nov 07 17:30:47 ogra_, having android dual boot now to see what it says would sure be handy Nov 07 17:30:59 are there sys files that can be read, do they say the same thing? Nov 07 17:31:02 you wont find uppower in android : Nov 07 17:31:05 :) Nov 07 17:31:39 /sys/devices/platform/tegra-i2c.4/i2c-4/4-0055/power_supply/battery/ Nov 07 17:31:43 janimo: with source package - go ahead as much as you want =) Nov 07 17:32:02 xnox, alright :) Nov 07 17:32:19 janimo: ubiquity, libreoffice and emacs all do that ;-) Nov 07 17:32:31 ah, I'm in good company then Nov 07 17:32:41 libreoffice is hardly "good company". Nov 07 17:32:59 my sarcasm key ain't working Nov 07 17:33:19 janimo, i'm pretty sure it is caused by d017332e756ba9294679c453431bf39507fd176e in our tree Nov 07 17:33:20 I thought that's what AltGr was for. Nov 07 17:33:25 Alternative Grin, or something. Nov 07 17:33:29 mine is remapped to Facebook Like Nov 07 17:34:02 it wasnt like that in the -6 kernel Nov 07 17:34:02 ogra_, that is cking's patch to fix reporting Nov 07 17:34:05 janimo: Damnit, I nearly have a beverage->laptop incident, thanks. Nov 07 17:34:10 so maybe it had side effects Nov 07 17:34:10 janimo, right Nov 07 17:34:17 s/have/had/ Nov 07 17:34:18 infinity, I must try harder next time Nov 07 17:34:30 janimo: If you want to buy me a new laptop, carry on trying. Nov 07 17:34:45 janimo, wait until you two are in a hangout together so you can record it Nov 07 17:34:58 ogra_: did you test flashing nexus7 with fs-utils now? Nov 07 17:35:13 * xnox is pondering if it's safe to flash my own nexus using those =) Nov 07 17:35:23 infinity, what model doth your heart desire? Nov 07 17:35:42 xnox, no, and i want to back up my rootfs first ... soo many chganges i dont want to lose already Nov 07 17:35:48 janimo: A T430s to replace my T420s wouldn't hurt my feelings. Nov 07 17:35:53 i'll keep that bit for tomorrow Nov 07 17:36:11 ogra_: interesting, how do I back it up? Nov 07 17:36:22 with fast boot? Nov 07 17:36:32 xnox, i think ext2simg is a no go, the image is around 100M bigger than with make_ext4fs Nov 07 17:36:42 *sigh* Nov 07 17:37:41 xnox, i do boot into the initrd with usb hub attached, on the hub i have kbs and usb key ... then i just dd /dev/mmcblk0p9 into an image file on the usb key Nov 07 17:37:46 ogra_, maybe the mkfs part does things differently by not emulating what make_ext4fs does? Nov 07 17:38:09 janimo, yeah, i think it compresses bits of the filesystem Nov 07 17:38:23 *filesystem meta data Nov 07 17:38:53 does things that e2fsutils cannot do? That would be strange, but I know too little about these tools Nov 07 17:39:04 same here Nov 07 17:39:32 ogra_: was slangasek suggesting some other way of creating sparse images? Nov 07 17:39:39 but slangasek asked me to look into the possibility to only use ext2simg and stick to our existing sparse img creation we already have Nov 07 17:39:41 at the closing plenery. Nov 07 17:39:59 dd if=/dev/zero of=test.img bs=1M seek=6144 count=0 Nov 07 17:40:17 mkfs.ext4 test.img Nov 07 17:40:30 then i loop mount and cp the tarball into it Nov 07 17:40:52 and then: ext2simg test.img rootfs_test.img Nov 07 17:41:26 thats largely the way we discussed (and the way debian-cd and friends etc use) Nov 07 17:41:37 ack. Nov 07 17:44:35 ogra@anubis:~/Desktop/nexus/builder/tmp$ ls -lh rootfs_test.img Nov 07 17:44:35 -rw-r--r-- 1 ogra ogra 783M Nov 7 18:43 rootfs_test.img Nov 07 17:44:35 ogra@anubis:~/Desktop/nexus/builder/tmp$ make_ext4fs -l 6G -s rootfs.img mnt/ Nov 07 17:44:36 .... Nov 07 17:44:45 ogra@anubis:~/Desktop/nexus/builder/tmp$ ls -lh rootfs.img Nov 07 17:44:46 -rw-r--r-- 1 ogra ogra 646M Nov 7 18:44 rootfs.img Nov 07 17:45:02 quite a size difference Nov 07 17:45:30 content is identical Nov 07 17:46:26 i suspect make_ext4fs does something like compressing the unused inode tables or so which fastboot uncompresses while flashing Nov 07 17:53:32 ogra_, uploaded kernel and meta packages to raring NEW. I hope it builds. I just remembered I tested on quantal only. This bit me recently with precise/quantal gcc switch. Oh well Nov 07 17:54:06 Does anyone have a minimal nexus7 rootfs image floating around? Nov 07 17:54:20 janimo, thanks so much ! Nov 07 17:54:59 ngharo, not to my knowledge Nov 07 18:29:08 I am having the weirdest experience here Nov 07 18:29:28 mkdir qm && mount /dev/sde2 qm && mount /dev/sde1 qm/boot && umount /dev/sde? Nov 07 18:29:33 the qm directory disappears Nov 07 18:30:00 unity is deleting it because it assumes if I mount it manually that it's the same as being in /media and being removed Nov 07 18:30:38 can anyone reproduce that quickly on something safe? I dunno if I found a bug or if I'm being a moron about something Nov 07 18:30:50 also this is precise and I can't get a quetzal running to test :D Nov 07 18:43:30 hi, I have a gooseberry running ubuntu 12.04 armhf and the loadaverage is at 2.x just after boot.. The system is idle. I have no clue what is going on but other users have no problems with the system load at all... Nov 07 18:49:50 achiang & ssweeny: I'm picking this bug up: https://bugs.launchpad.net/ubuntu-nexus7/+bug/1071259 Nov 07 18:49:51 Launchpad bug 1071259 in ubuntu-nexus7 "Setting brightness all the way down actually switches off the display completely" [Medium,Confirmed] Nov 07 18:51:26 mfisch: cool, i'm assuming we're using the normal process of assigning to ourselves, etc. Nov 07 18:58:39 ogra_, see the 2.0 loadaverage happening above too^ Nov 07 18:58:56 r0k5t4r, that is seen on the nexus7 as well Nov 07 18:58:59 with 12.10 Nov 07 18:59:40 achiang: yes Nov 07 18:59:47 janimo: ok, thought I'm the only one as others on the gooseberry forum didn't report this Nov 07 19:00:07 r0k5t4r, what kernel are you using? Nov 07 19:03:53 janimo: 3.0.36 Nov 07 19:04:21 r0k5t4r, what source? Is there a goosberry kernel and you built it using Ubuntu's gcc? Nov 07 19:04:50 janimo: I downloaded the ubuntu image from someones dropbox account. there was a link on the gooseberry forum Nov 07 19:05:11 ok Nov 07 19:06:06 janimo: The users account on the gooseberry forum was alanb and i just saw that here is some called AlanBell... It can hardly be a coincidence :) Nov 07 19:06:30 janimo: brb Nov 07 19:07:00 r0k5t4r: oh? Nov 07 19:07:11 I suspect it is a coincidence, I am AlanBell in most places Nov 07 19:19:19 AlanBell: :) sorry Nov 07 19:19:53 thats fine :) Nov 07 19:20:01 what is the gooseberry forum? Nov 07 19:21:54 oh, right, that certainly isn't me, I don't have one of those, I have a raspberry pi and a nexus 7 (well, my family has the nexus 7, I am not allowed to play with it) Nov 07 19:22:12 play/break Nov 07 19:23:04 are there any howto's for making a VM with a nexus 7 environment in it? Nov 07 19:24:18 AlanBell: you are lucky not to have one. I have one since day one and there is really nothing that really works except the default android that comes with it Nov 07 19:44:58 yofel: why would you want to? Nov 07 19:45:02 achiang: ping Nov 07 19:45:19 yofel: it's just the standard ubuntu desktop on arm, minus thunderbird and open office Nov 07 19:46:04 mfisch: pong Nov 07 19:46:33 mfisch: well, I would prefer to have something where I could build packages in. Other than the actual tablet itself Nov 07 19:46:40 achiang: an update on the brightness issue, it seems to be up to the device that at brightness 0 you can still see the screen Nov 07 19:46:46 yofel: give me 5 mins and I can help Nov 07 19:46:55 sure :) Nov 07 19:47:18 achiang: what I mean is that on my laptop and the other ARM device I have, you can still see the screen when brightness is set to 0 Nov 07 19:47:42 achiang: I can take it to 0, which also implies that the brightness control has no hard stop at say, 1 Nov 07 19:47:54 mfisch: that's interesting. maybe we need to add logic to our brightness controller that can figure out what "0" actually means and then set in a minimum if necessary Nov 07 19:48:06 if we can't figure that out dynamically, then perhaps we should add a quirk system Nov 07 19:48:16 achiang: yeah, I'll poke around some more, but best I can figure now is that we need to hard stop at 1 for this device Nov 07 19:48:21 yep Nov 07 19:48:43 yofel: have you used a pbuilder before? Nov 07 19:49:29 yes, I'm a kubuntu packager so I know that part Nov 07 19:49:39 I just have very little ARM experience Nov 07 19:49:47 yofel: so we're recommending people just setup an armhf pbuilder Nov 07 19:50:01 yofel: you can install pbuilder-scripts which came from Canonical and it will make life significantly easier Nov 07 19:50:19 pcreate -a armhf -d quantal Nov 07 19:50:26 and when that's done Nov 07 19:50:36 ptest gives you a shell inside a qemu chroot Nov 07 19:50:53 ptest -p ^^ Nov 07 19:51:17 writing up notes on pbuilder scripts is on the to do list Nov 07 19:51:31 pbuilder image is being created, thanks! Nov 07 19:51:38 np Nov 07 19:51:58 yofel: did I talk to you at UDS? Nov 07 19:52:05 in the bar at the closing Nov 07 19:52:16 impossible, I wasn't there ;) Nov 07 19:52:25 okay, I met the rest of your Kgang though Nov 07 19:52:36 heh Nov 07 19:56:04 mfisch: where's the pad re: memory debugging? i'll work on writing up the wiki page today Nov 07 19:57:33 achiang: looking Nov 07 19:58:11 achiang: http://summit.ubuntu.com/uds-r/meeting/21394/how-do-i-know-my-code-is-not-consuming-too-much-memory/ Nov 07 19:58:28 thanks Nov 07 20:05:43 achiang: does ARM have a sys firmware interface analogous to ACPI? Nov 07 20:05:53 not really Nov 07 20:05:58 there is device tree Nov 07 20:06:05 but i think that is more for topology Nov 07 20:06:16 acpi covers so many bases Nov 07 20:06:31 what about SMBIOS/DMI? Nov 07 20:06:33 i don't know if device tree allows you to query for capabilities Nov 07 20:06:48 those are both x86 specs Nov 07 20:07:00 the best i've been able to find on ARM is lsusb Nov 07 20:07:00 just wondered if there was an analog Nov 07 20:07:03 :-/ Nov 07 20:08:27 there's an entry in sys called "bl_power", and even the great wiki page I found doesn't know what it's supposed to do Nov 07 20:10:03 well the way sysfs works, any vendor can create any entry there Nov 07 20:10:23 so that may (or may not) be a standard interface Nov 07 20:10:28 it can be hard to tell Nov 07 20:10:31 where does bl_power live? Nov 07 20:10:33 full path Nov 07 20:11:30 /sys/class/backlight// Nov 07 20:12:06 it's set to 0 on every device i've tried, I was hoping it would be useful Nov 07 20:12:14 but I'm doubting it Nov 07 20:12:51 achiang@yew:~$ cat /sys/class/backlight/intel_backlight/bl_power Nov 07 20:12:52 849009384 Nov 07 20:12:52 achiang@yew:~$ cat /sys/class/backlight/acpi_video0/bl_power Nov 07 20:12:52 0 Nov 07 20:13:08 interesting Nov 07 20:13:40 I only have the acpi_video0 on my amd64 box, the 2 ARM devices have "pwm-backlight" Nov 07 20:16:49 achiang: does bl_power change as you change the display brightness? Nov 07 20:17:35 nope Nov 07 20:18:12 oddly if I set mine to 1, the display turns off Nov 07 20:19:08 achiang: I found docs: http://www.mjmwired.net/kernel/Documentation/ABI/stable/sysfs-class-backlight Nov 07 20:20:53 ok, so /sys/class/backlight/acpi_video0/brightness echos the current status of my backlight Nov 07 20:22:08 yep Nov 07 20:22:19 and you can echo to it Nov 07 20:22:33 my laptop goes from 0-20, the N7 is 0-255 Nov 07 20:22:51 the other ARM device is 0-7 Nov 07 20:23:08 achiang: squirrel this away in your notes: https://wiki.kubuntu.org/Kernel/Debugging/Backlight Nov 07 20:25:09 interesting but too x86 focused Nov 07 20:25:13 those are all acpi assumptions Nov 07 20:25:14 yep Nov 07 20:26:58 bl_power is the on/off switch for backlight. the value is kind of meaningless Nov 07 20:28:21 but on and off for backlight are different from brightness. brightness 0 is the *lowest* brightness it can have, and most backlight controllers have a lower safe limit of operation on PWM frequency and period. Nov 07 20:29:39 so what we have is a PWM period control button which is abstracted to a set of reasonable levels (0-7 or 0-20 or 0-255) and a PWM off button which disables anything going out. Actually cutting power would be done via regulators, and the backlight driver may do this or may not (on ACPI it's hidden, so.. ) Nov 07 20:29:52 what are you trying to do? :) Nov 07 20:35:27 NekoXP: brightness 0 on the Nexus7 turns the display full off Nov 07 20:35:41 NekoXP: which makes it challenging to get lit back up, unless you don't move your finger Nov 07 20:36:49 this is just how LCD panels work. It's a little window with a liquid crystal in front of it. The liquid crystal turns from clear to black when voltage is applied. But, if you don't shine light through the window, you don't see anything Nov 07 20:37:13 brightness 0 could mean anything to different backlight implementations, but what it usually means is the lowest possible PWM frequency Nov 07 20:37:50 It seems of the devices I've tried that they have set 0 to be "still on" to avoid this Nov 07 20:37:53 that may be a "safe" low PWM value to not have to actually tear down a PWM controller or disable a clock, but it may be lower than you actually need to turn a lught on Nov 07 20:38:57 lets get technical. I have a panel here that says it has an upper and lower bound pwm period for safe operation, and a minimum and maximum frequency. the frequency generally doesn't change (although depending on he backlight, it may). the important thing is the period. Nov 07 20:39:54 all it does is turn on and off fast enough that the device at the other end feels like it's getting a constant power, but it actually isn't. for an LED it doesn't just go on and off, it turns on and it needs to warm up a bit, so the light is not instant. and turning off, it will actually fade a little before turning completely off. Nov 07 20:40:33 that gives you varying levels of brightness, and the trick is not to have it flicker because of the fading Nov 07 20:42:02 but, you can't just say don't generate a pwm waveform, you have to actually supply enough power for it to not drop out completely, which means just a low period. that's why you have a 0 (which may be no light coming out) *and* a power on/off. Nov 07 20:42:29 ok Nov 07 20:42:30 some backlight controllers spec that you can't turn them completely off via pwm, some do. it's implementation dependent in the driver *and* the hardware Nov 07 20:43:00 so that all makes sense Nov 07 20:43:11 also the power off switch may turn off the pwm controller, disable it's parent clock so it doesn't soak power itself, and disable the regulator feeding the supply for the backlight anyway Nov 07 20:43:30 and I think the fix from a user-experience POV will be to not allow the brightness controller to go to 0 on this device, in whatever form that takes Nov 07 20:43:31 you shouldn't do that with just a request for brightness 0, even if it "feels" like it's doing that. Nov 07 20:43:58 on the N7 what's the driver called again? Nov 07 20:44:39 maybe pwm_bl or something? or tegra_pwm_bl? it's the name of the /sys/class/backlight/ Nov 07 20:45:18 pwm-backlight is what's in /sys/class/backlight Nov 07 20:46:17 okay so probably there is a control in the board support file platform data that supplies the frequencies, periods etc. it needs Nov 07 20:46:26 I need a copy of the N7 kernel.. hang on :D Nov 07 20:47:51 ah no, here it is Nov 07 20:48:12 drivers/video/backlight/pwm_bl.c:51 Nov 07 20:48:13 if (brightness == 0) { Nov 07 20:48:13 pwm_config(pb->pwm, 0, pb->period); Nov 07 20:48:13 pwm_disable(pb->pwm); Nov 07 20:48:13 } else { Nov 07 20:48:13 brightness = pb->lth_brightness + Nov 07 20:48:15 (brightness * (pb->period - pb->lth_brightness) / max); Nov 07 20:48:17 pwm_config(pb->pwm, brightness, pb->period); Nov 07 20:48:21 pwm_enable(pb->pwm); Nov 07 20:48:23 } Nov 07 20:48:27 ^^ this is so wrong I can't describe, but it does actually disable the pwm Nov 07 20:49:56 it's still drawing power technically (leaking at least) but there's no waveform going out to the backlight at 0. acpi etc. stuff, 0 doesn't mean off it means first in a list of values passed back by some call to _BLQ or something Nov 07 20:50:19 NekoXP: what's in the board support file? Nov 07 20:50:56 period, brightness default, "top" brightness, max brightness value.. that kind of thing Nov 07 20:51:21 I was wrong in that it would be controlled by the board file, whatever you do there, the backlight driver itself will turn off the pwm at brightness 0 which is despicable :) Nov 07 20:52:07 there are two options.. one of which depends on kernel version Nov 07 20:53:12 firstly, modify the userspace that is controlling the backlight, probably gnome-power-manager, to never set 0 if the backlight name is pwm-backlight. Then you have to figure how you turn the backlight off in any case.... but it should be kicking bl_power for that. I'd need to look at gpm Nov 07 20:53:59 second, modify pwm_bl.c so that it says if (brightness == 0 && !machine_is_nexus7()) { or something similar. That really depends on if you can even tell it's the nexus 7 inside the driver... :D Nov 07 20:54:25 if it's a device tree kernel you might have to do a string match on probe, and store a little value to change behavior and check for that value, which is clumsy as hell Nov 07 20:56:07 the behavior of pwm_bl just seems not to be correct, this is kind of a bug I would think. I bet the driver was written before bl_power was implemented. Nov 07 20:56:31 it's been updated to take it into account but it hacks it above those lines; Nov 07 20:56:35 if (bl->props.power != FB_BLANK_UNBLANK) Nov 07 20:56:36 brightness = 0; Nov 07 20:56:36 if (bl->props.fb_blank != FB_BLANK_UNBLANK) Nov 07 20:56:36 brightness = 0; Nov 07 20:56:45 this is wrong. it should deal with power off completely differently. Nov 07 20:57:51 lth_brightness should be involved here; Nov 07 20:57:59 I just saw a patch for DT kernels that adds this; https://lkml.org/lkml/2012/9/26/271 Nov 07 20:58:35 brightness == 0 should be setting the low threshold brightness Nov 07 20:58:45 props.power or props.fb_blank should unconfig the pwm Nov 07 20:58:58 not a mishmash of the two Nov 07 21:00:07 can you tell I spent weeks crying over how awful backlight support is on the linux kernel? we still have problems with our stuff and that godforsaken driver :D Nov 07 21:01:48 mfisch, so, ultimate solution, add lth_brightness to board support or device tree if possible, based on the panel spec. I doubt you have that.. but.. oh well. A good guess might suffice. And fix pwm_backlight_update_status() to deal with the blanking and power controls independently, and NOT just set the brightness to 0. That brightness thing actually meant on our systems that we had to add a copy of the "previous" brightness to come back out from standb Nov 07 21:01:48 y and set the correct brightness value (otherwise it would come back and it would be "off") Nov 07 21:01:48 NekoXP: someone just called me, so hold on a sec Nov 07 21:08:11 http://pastebin.com/gYdPs0fV Nov 07 21:08:24 I didn't compile check it or even test it, but that might be a more favorable behavior Nov 07 21:09:23 even if you set the brightness to 0 it will always be the minimum duty cycle. if you tweak bl_power it will unconfig the pwm... and config it again with the stored brightness... Nov 07 21:10:00 I'd need to fully test the userspace that goes with it to be sure what it tries to do Nov 07 21:10:05 but there's your start Nov 07 21:10:33 you would have to be sure lth_brightness is set somewhere though :] Nov 07 21:16:55 NekoXP: I'll catch up in about 30 mins, long phone call then I'm stepping out for a bit Nov 07 21:17:59 I might be gone in 30 mins :] Nov 07 21:30:47 i think we should put a quirk in the kernel, not in userspace Nov 07 22:04:03 * mfisch catches up Nov 07 22:04:33 achiang: do you know how to do that process? Nov 07 22:12:16 mfisch, apply that patch, thats the starting poiint, but I don't have the nexus7 kernel ubuntu guys are using nor a nexus 7 to test (actually one of the staffers here does but I doubt he will install ubuntu on it) Nov 07 22:12:29 the pwm_bl driver is dead to rights wrong in it's behavior so it needs fixing Nov 07 22:13:28 ok Nov 07 22:13:37 NekoXP: I'll give it a shot today or tomorrow Nov 07 22:14:09 NekoXP: thanks Nov 07 22:15:30 no guarantees, but it should at least stop it from being able to set brightness = 0 and turn off the backlight. that will only happen now if the bl_power is tweaked. brightness = 0 still could be black though or barely visible.. this is a tweak you need to figure out based on usage ;) Nov 07 22:16:16 lth_brightness definitely needs to be set (it'll be in mach-tegra/board-nexus7.c or something or a device tree) for it to work otherwise brightness = 0 is still pwm off, but it will actually be running under minimum duty cycle which COULD damage a backlight Nov 07 22:16:17 be warned Nov 07 22:16:51 you could set it to 10 and should be fine. 13 if you want to be safe. I've never seen a panel say it had a higher minimum duty cycle than 12.5% Nov 07 22:16:59 ok Nov 07 22:17:09 hopefully asus gave it a good value to start Nov 07 22:17:41 but that's a percentage so 10% brightness is as low as it goes.. that may still be "too bright". you'd need the panel specs. Nov 07 22:17:45 I'm sure they're online somewhere. Nov 07 22:17:55 anyway I'm off home Nov 07 22:18:02 ok Nov 07 22:18:04 have fun, I'm sure there are people around here who can help at some point Nov 07 22:18:04 have a nice day Nov 07 22:46:52 mfisch: ping Nov 07 22:50:44 cwayne: yo Nov 07 23:05:05 mfisch: isnt this fixed in our image? https://bugs.launchpad.net/ubuntu-nexus7/+bug/1055949 Nov 07 23:05:06 Launchpad bug 1055949 in unity (Ubuntu) "Unity panel shadow appears as solid black bar on GLES/ARM (Pandaboard, Nexus 7)" [Medium,Confirmed] Nov 07 23:10:04 cwayne: I was going to ask you about that one Nov 07 23:10:36 mfisch: afaik its fixed in ours, but not upstreamed yet. I'm gonna mark it fix committed on our project Nov 07 23:12:16 cwayne: is it in image? Nov 07 23:12:21 cwayne: or in the public PPA? Nov 07 23:12:25 if so mark it released Nov 07 23:12:36 mfisch: in the image, may be in the ppa as well, let me check Nov 07 23:12:39 and note when it was fixed "fixed in first release" Nov 07 23:18:41 hello Nov 07 23:23:17 hi Nov 07 23:30:20 excume me can i ask you a question= Nov 07 23:30:21 ? Nov 07 23:32:10 mordicchio_: go ahead Nov 07 23:33:21 i m searching a irc client for my raspberry pi Nov 07 23:33:35 can you help me? Nov 07 23:35:09 mordicchio_: see the topic :) better ask in #raspbian Nov 07 23:36:31 With the emergence of our armhf environment, was the downgrading of the armel environment sufficient to run on a Pi? Nov 07 23:50:15 persia: yes, but a) pi wasn't the target of that downgrade, b) the fact that armel is v5 instead of v6 makes it largely uninteresting, c) there's no kernel in the archive or image for it, d) armel is going away now Nov 07 23:50:49 What's the rationale for d)? c) is fixable in the meantime. Nov 07 23:51:18 persia: the rationale for d) is that we have no rationale for not-d Nov 07 23:51:34 So, lack of users? Nov 07 23:51:36 armel was always intended to go away once armhf was on its feet Nov 07 23:52:03 the armv5 rebuilt was a speculative repurposing for a contract that never panned out Nov 07 23:52:11 s/rebuilt/rebuild/ Nov 07 23:52:46 Ah, Canonical doesn't want to host the buildds, and there's not lots of protest about it. That makes sense as a rationale for d) Nov 07 23:52:59 right Nov 07 23:53:07 rather, we want to host the buildds but want them to be armhf buildds ;) Nov 07 23:53:31 I say that's effectively the same as saying there's a desire not to host armel buildds :) Nov 07 23:54:00 In that case, I suppose I oughtn't push kirkwood kernels and migrate those devices to Ubuntu. Nov 07 23:54:15 unless you want to stick with 12.10, probably not Nov 07 23:54:48 * persia still has devices running 9.10 as a result of participating in discussions with folk who were less forthcoming, and doesn't especially want to repeat Nov 08 00:00:33 wow Nov 08 00:00:39 persia, haven't seen you around in ages Nov 08 00:01:19 lilstevie: I had some administrative issues, now sorted. Have you been well? Nov 08 00:01:57 yeah :) Nov 08 00:02:39 persia, I have the tf201 kernel building as a deb now :) finally got my way through setting that up Nov 08 00:03:39 Cool! At UDS there was some discussion on the *right* way to do universe kernels, so if it's a working quantal kernel, we can probably get that sorted sanely. Nov 08 00:03:57 Err, raring. Nov 08 00:04:03 * persia pushes brain faster to catch up Nov 08 00:05:01 persia, well it is the same vintage as the n7 Nov 08 00:05:22 both 3.1.10 nvidia kernels Nov 08 00:05:29 :p Nov 08 00:05:32 * persia worries more about userspace compatibility than version numbers Nov 08 00:05:58 Is that kernel DT friendly enough that we could run one kernel with different DT files for both devices? Nov 08 00:06:06 persia, no Nov 08 00:06:14 Oh well. One can dream :) Nov 08 00:06:21 however it may be possible to enable both boards Nov 08 00:06:52 I don't have an n7 though, so I haven't checked out the machine id Nov 08 00:07:12 if it isn't cardhu then they may very well co-exist Nov 08 00:07:22 I suspect there's someone else on the channel who might be able to dig up that information :) Nov 08 00:07:22 however there still is the issue of the dock keyboard driver Nov 08 00:07:43 that thing has infected many parts of the system Nov 08 00:07:51 That's not implemented as USB or something else sane? Nov 08 00:07:55 Audio, Battery, and Board Nov 08 00:08:01 oh, it is i2c Nov 08 00:08:17 but they have functions injected all over the place Nov 08 00:08:21 Oh, ugh. That makes it ever so much trickier :( Nov 08 00:09:10 the core driver itself is fine, but the offload functions to other drivers Nov 08 00:09:29 things like the battery status get offloaded through special calls in the battery driver Nov 08 00:10:02 That should really just be another pluggable battery, rather than so closely tied. I suspect someone was in a hurry. Nov 08 00:10:50 the worst one though is they have a dock with speakers (never released or announced) that offloads audio based off headset detect and the audio codec Nov 08 00:10:58 Manufacturers are always in a hurry. Nov 08 00:11:08 it is a giant deps tangle Nov 08 00:11:24 And the nexus7 machine ID is grouper Nov 08 00:11:31 I tried to modularise some of that stuff, but it is just impossible due to how tied up they are Nov 08 00:11:38 TheMuso: Yes, but some of them ask their board vendors to supply a board that is already ported, rather than hiring someone to hack it in ugly ways. Nov 08 00:11:42 TheMuso, right, silly me :p Nov 08 00:11:55 Right. Nov 08 00:12:17 persia, as it is this is all hacked over the top of the support for the cardhu development platform Nov 08 00:13:43 tf101 did that with ventana, but they were much more similar, to the point where with a few small mods you could get the kernel to boot Nov 08 00:45:03 persia, do you want to see if there is anything I need to change with how my kernel is packed for universe? I have it on my repo at the moment for precise Nov 08 00:46:27 I'm tight on time today, but I can probably look at it tomorrow. Nov 08 00:46:53 I know there *will* be changes required, but I haven't seen publication of the new procedure yet. Nov 08 00:46:57 persia, oh no hurry Nov 08 00:47:03 (so we can use the old one for now) Nov 08 00:47:20 the kernel itself is old (and poorly named) Nov 08 00:47:40 I need to start again for the new one cause of a different base Nov 08 00:48:51 Heh. Old kernel, old procedure, new kernel, new procedure :) Nov 08 00:49:06 that was what I was thinking Nov 08 00:50:21 so, what is the name of the program that provides all of the on screen menus, and the activation area in the top left of the screen on 12.04? Nov 08 00:51:23 "dash" maybe? Nov 08 00:57:34 Thats part of unity. Depends on what version of Unity you are running. Nov 08 01:06:26 TheMuso: how do I find that out? Nov 08 01:06:56 mjrosenb: You would have to check the list of currently running processes I think, I can't think of an easy visual way to determine that. Nov 08 01:07:44 TheMuso: well, the issue is that the menu bar and other things are not worknig Nov 08 01:07:47 *working Nov 08 01:07:55 I have a context menu when I right click on the desktop Nov 08 01:08:11 under gnome, i'd say that mean that nautilus was running Nov 08 01:08:18 suckless-tools has some useful widgets to query the current set of represented X apps, which may help. Nov 08 01:08:19 but I have no clue who handles that these days Nov 08 01:08:52 it appears as if lightdm is in fact running. Nov 08 01:09:58 of course lightdm is running Nov 08 01:15:27 mjrosenb, if you kill lightdm it will take everything running in X with it Nov 08 01:15:56 (assuming you haven't done any fancy process reparenting beforehand) Nov 08 01:16:08 well yeah Nov 08 01:18:33 I just killed lightdm and restarted it, but still just the desktop. Nov 08 01:19:42 what is this on? Nov 08 01:19:58 pandaboard Nov 08 01:20:13 running 12.04 Nov 08 01:20:45 12.04 does have nautilus providing the desktop Nov 08 01:21:07 indeed, it does. Nov 08 01:21:35 what does it have providing the upper bar with the time + some menus on it? Nov 08 01:21:49 or the meta-key functionality? Nov 08 01:27:47 meta is dash. I forget what the upper bar that hosts the indicators is called (and it's not obvious from running lsw on 12.04) Nov 08 01:39:22 unity-panel-service Nov 08 01:39:40 Unity-panel-service doesn't actually do any of the rendering however. Nov 08 02:18:39 ps aux | grep unity does not return anything Nov 08 02:18:49 so presumably the backgronud service isn't running Nov 08 02:19:20 unity-2d-panel: error while loading shared libraries: libgbm.so.1: cannot open shared object file: No such file or directory Nov 08 02:19:23 oh. Nov 08 02:22:41 http://pastebin.mozilla.org/1923408 Nov 08 02:22:43 interesting. Nov 08 02:30:35 ok, making a symlink fixed the issue Nov 08 02:30:39 but man that feels like a hack **** ENDING LOGGING AT Thu Nov 08 03:00:01 2012