#ubuntu-arm 2009-11-02
<pwnguin> hmm. is there a shiva plug with wifi?
<lool> rabeeh: Heya
<eggonlea> lool: there should be still several hours before rabeeh gets up. :)
<eggonlea_> wondering why boot.scr is not included in any installed package so that we could customize it easier. :)
 * eggonlea_ think it's better to manage all installed files to ease package upgrade.
<Mandrew> hello ppl
<Mandrew> i have a pocket loox 600 can i install ubuntu for ARm on it?
<ogra> is it ARMv6 or above ?
<Mandrew> ARMv5TE
<ogra> only with jaunty then
<Mandrew> sorry for the delay
<ogra> (9.04)
<Mandrew> can i run the MID version or?
<ogra> with 9.10 we switched the default compiler options so everything is compiled for ARMv6+vfp now
<Mandrew> ok
<Mandrew> Processor type Intel PXA250 (XScale)
<Mandrew> Processor speed 400 MHz
<Mandrew> Installed RAM 64 MB
<Mandrew> its not so powerful
<ogra> 64MB ? that will get you likely in trouble
<Mandrew> i thought so
<Mandrew> so i cant run something older on it then?
<ogra> you can run jaunty
<ogra> but 64M is very tight
<Mandrew> how about the ubunt 7 or some like that?
<ogra> ubuntu 7 ?
<ogra> whats that ?
<Mandrew> 7.04
<ogra> no arm support
<Mandrew> well i dont know lol
<Mandrew> ok
<ogra> arm was added with 9.04
<Mandrew> ok
<ogra> that verysion still runs on ARMv5 hardware
<Mandrew> ok cool
<Mandrew> well thanks for all the help i need to go and feed my daughter
<ogra> you will need your own kernel and bootloader setup though ... for a rootfs see the cannel topic
<Mandrew> ok
<Mandrew> well thanks again bye
<ogra> bye
#ubuntu-arm 2009-11-03
<BeardedChimp> Can anyone recommend a page for building an ubuntu arm-eabi toolchain for cross compiling? Everything I've come across so far has not worked
<ojn> BeardedChimp: Do you need to build your own? CodeSourcery's compiler works great.
<BeardedChimp> Do I need to recompile their packages, the tarballs have it listed as IA32 and I'm 64
<armin76> really? that sucks
<ogra> armin76, being 64 you mean ?
<armin76> being 64 and codesourcery's not being 64
<amitk> BeardedChimp: Try lool's PPA for the cross compilers: https://edge.launchpad.net/~lool/+archive/ppa
<BeardedChimp> Unfortunately that seems to be mostly karmic im running jaunty
<amitk> ok
<armin76> upgrade!
<BeardedChimp> going to run the codesourcerys stuff anyway, see if i can force it
<ojn> BeardedChimp: Just install the compat libraries and you'll be fine
<BeardedChimp> armin76: Nah for the likes of rootfs etc. I feel better on jaunty atm
<ogra> well, if you refer to the rootfs script (rootstock), it works twice as fast under karmic :)
<Salvad> I want to known something about the ARM version of Ubuntu.
<Salvad> Are the same drivers of X86, for ARM too?
<armin76> what?
<armin76> Salvad: which drivers?
<Salvad> For example: I want to use a Joystick in a device with Ubuntu for ARM.
<Salvad> Have one to recompile them in order to work on ARM?
<Salvad> Recompile the drivers.
<armin76> you need to recompile everything
<Salvad> Is easy to recompile the drivers for ARM?
<Salvad> Does this distribution works with Nvidia tegra?
<armin76> woot
<armin76> Salvad: ARM is not a sub distribution, is an architecture, completely different to x86
<Salvad> Yes, I know that.
<armin76> Salvad: there's no nvidia hardware on arm
<Salvad> Nvidia Tegra integrates an ARM processor.
<armin76> but i doubt it can run a linux distro
<Salvad> Why not?
<armin76> well, i'm no expert, but how do you input data? does it have serial or something?
<armin76> from where do you boot from?
<Salvad> Mmm.
<Salvad> Tegra is a system.
<Salvad> It compunds insternal hardware.
<Salvad> *Internal.
<Salvad> The Zune HD uses it for ezample.
<Salvad> *Example.
<armin76> looks like i talk too much :P
<armin76> well, maybe it could
<armin76> how, no clue
<Salvad> http://www.chw.net/2009/09/nvidia-chrome-os-con-tegra-sera-grito-y-plata/
<Salvad> Al parecer si va a soportar Linux.
<Salvad> Mmm.
<Salvad> Is an article written in Spanish.
<Salvad> It says that it will support Chome OS.
<pwnguin> Salvad: i believe that drivers will cross compile in most cases
<pwnguin> unless they're in arch
<Salvad> What cross compile means?
<pwnguin> well, maybe cross compile is the wrong word
<pwnguin> build on multiple architectures
<pwnguin> for example, a few years ago i discovered that ARM was capable of using standard pcmcia drivers
<Salvad> Does Ubuntu for ARM has great drivers support?
<armin76> Salvad: it has all the drivers the kernel supports
<Salvad> My joystick could possibly run on it so!.
<Salvad> I am waiting for the ARM netbooks to be on the market.
<Salvad> I hope a cheap one supports Ubuntu.
<Salvad> The will be very light in weight, low energy consuming and fanless maybe.
<armin76> Salvad: there's one already, always innovating touchbook
<Salvad> Does it have a Touch scrren?
<Salvad> *Screen.
<armin76> have no clue
<Salvad> *Has.
<Salvad> I am waiting for an Asus.
<Salvad> That will come in 2010.
<Salvad> It will be cheap apparently.
<ryuo> armin76, yes it has a touchscreen. i have one right now.
#ubuntu-arm 2009-11-04
<rcn-ee> ogra, with 2.6.32-rc6 landing alot of the beagleboard now works on mainline.  What's the best way to introduce a new target via config for lucid? ;)
<Ford_Prefect|w> Hello folks
<Ford_Prefect|w> I'm trying to build an ARM cross toolchain to match the native toolchain from Ubuntu's ARM repository
<Ford_Prefect|w> Has anybody done this already?
<Stskeeps> lbt may have
<Stskeeps> we use one in our obs cross setup at least
<Ford_Prefect|w> Um lbt? obs?
<Ford_Prefect|w> Thought I'd try apt-cross but it obstinately refuses to look at Ubuntu source mirrors
<Stskeeps> lbt=a nickname, obs=a builder service
<Ford_Prefect|w> Stskeeps, okay. Will wait till lbt shows up, I guess.
<NCommander> Ford_Prefect|w, why do you want a cross-compiler
<NCommander> The toolchain packages are the same across all architectures. You can get the most recent source suitable for building cross-compilers by installing binutils-source, gcc-source, and glibc-source
<Ford_Prefect|w> NCommander, I'm working on an SDK which provides a cross-compiler
<Ford_Prefect|w> So development happens on the host, binaries are copied to the target
<NCommander> Ford_Prefect|w, with the target running Ubuntu or?
<Ford_Prefect|w> NCommander, I can pull the sources on the host but I was hoping to find scripts to do the whole bootstrapping shebang
<Ford_Prefect|w> NCommander, Ubuntu
<Ford_Prefect|w> On the target and host, both
<NCommander> Ford_Prefect|w, in general, we don't support cross-compiling for Ubuntu.
<NCommander> Everything is natively compiled
<NCommander> There are a few guides though to getting the toolchain off the ground
<Ford_Prefect|w> Okay. I think before long I won't be the only one who needs this. :)
<Ford_Prefect|w> As in, cross-compiling is a common enough use case in a lot of development environments, so it wouild be good to have a standard method to generate and use these.
<Stskeeps> Ford_Prefect|w: talk to lbt for sure :) we have a very cool solution in this regard
<Stskeeps> building qt for armel in 4 hours
<Ford_Prefect|w> Ah, excellent
<Ford_Prefect|w> But wow, 4 hours?
<Ford_Prefect|w> Does it really take that long on the host?
 * Ford_Prefect|w huggles gtk and glib :P
<Stskeeps> it takes 3-4 days natively
<Ford_Prefect|w> <shudder>
<Ford_Prefect|w> These are those orion5x' I've hear of?
<Stskeeps> either way we compiled our entire Mer with gtk,glib,qt in a day :P
<Ford_Prefect|w> Ah, omap2 :)
<Ford_Prefect|w> Reminds me that I need to try Mer out on my N810
<Stskeeps> doesnt have to be omap2 :P
<Ford_Prefect|w> :) True, dat
<Stskeeps> check out http://wiki.maemo.org/Mer/Build , especially the cross section
<Ford_Prefect|w> Thanks! ... looking
<Ford_Prefect|w> We're actually using CodeSourcery's toolchain for cross-compiling right now, but there's potential for ABI breakage there, since they're not the same version as on the target
<Stskeeps> yeah, it is better to have matching
 * armin76 looks at Ford_Prefect|w 
<Ford_Prefect|w> Heya armin76 :)
<Ford_Prefect|w> (don't ask me why we're not just using Gentoo and crossdev :P)
<NCommander> Stskeeps, depends on what hardware you have ;-)
<Stskeeps> NCommander: yes, of course :P
<NCommander> Stskeeps, I can build Qt4 on native hardware in 18-25 hours
<dpb> Anyone know some legal stuff here? If I release an image for some hardware that's mainly Ubuntu but has some other packages added, can it be called an Ubuntu image, or do I need to rename it?
<Ford_Prefect|w> NCommander, out of curiosity, what hardware is that?
<NCommander> Ford_Prefect|w, Marvell Dove Y0/Y1, and Freescale Babbage iMX51
<Ford_Prefect|w> Ah
<NCommander> dpb, http://www.ubuntu.com/aboutus/trademarkpolicy - trademark policy if here
<NCommander> dpb, its pretty clear on what you can and can't call Ubuntu or an Ubuntu Remix
<Stskeeps> Ford_Prefect|w: /msg lbt
<Ford_Prefect|w> Stskeeps, doing so
<BeardedChimp> If I have the source code that compiled the kernel, where from that source code can I extract the headers that are normally downloaded through apt-get install linux-headers-(uname -r)
<dmart> Has anyone tried newest kernel from jaunty-security (2.6.28-16.55) on armel?  It appears badly broken... gdm and X don't work, and logging in is impossible except as root.
<dmart> A simple program which just uses setresgid and setresuid to become a normal user and then exec's a shell receives SIGKILL when the exec is attempted :O
<dmart> The OOM killer did not run though
<ogra> dmart, thats imx51 ?
<dmart> Yes, babbage1
<dmart> Am I doing something stupid... ?
<ogra> bjf, amitk ^^^ ?
<ogra> dmart, definately not, it should work
<bjf> ogra, no idea, should just work
<ogra> you didnt change the patchset or anything in jaunty, right ?
<bjf> ogra, no change to the patchset, I think there may have been a rebase done
<ogra> hrm
<dmart> I think the only think I did was to upgrade the kernel via apt-get install linux-imx51
<dmart> If a roll back to 2.6.28-15.52, that seems to work normally.
<bjf> ogra, we aren't building that kernel for updates are we
<dmart> Dunno, this was from jaunty-security
<bjf> ogra, the only one I work on is the one in the jaunty topic branch
<ogra> bjf, you mean jaunty->karmic ?
<ogra> will likely not workj since the jaunty kernel didnt support B2.x and the karmic kernel doesnt support <B2.x
<dmart> But 2.6.28 isn't the karmic kernel, right?
<bjf> this is a jaunty update
<bjf> dmart, no that's jaunty
<ogra> bjf, so what did you mean with "<bjf> ogra, we aren't building that kernel for updates are we" ?
<ogra> for sure security updates should work
<ogra> release to release wont work because of the different patchsets
<dmart> Sure; that I would expect
<bjf> ogra, the only work I've done w.r.t. imx51 on jaunty is in the imx51 topic branch and that branch doesn't get built for updates (or any other reason that I'm aware of)
<ogra> right
<dmart> There's been a regular trickle of updates to the jaunty kernel through jaunty-security
<ogra> i was just wondering if someone was insane enough to merge that one into the security update for whatever reason
<dmart> Sounds like I should go ahead and raise a bug on this?
<bjf> dmart, can I get you to file a bug on this issue?
<dmart> Yeah, I can.
<dmart> Thought I should check with you guys first though
<bjf> dmart, thanks, what you are seeing should _not_ be happening
<ogra> right
<dmart> It's very weird...  the kernel mostly works, but with some very strange behaviours
<bjf> dmart, if you stick with -15.52 you should be ok, we'll look at the bug and try to get it sorted out
<bjf> dmart, post the bug number here and I'll assign it to myself
<dmart> I can use the older kernel, no problem... but if something got merged in the jaunty imx51 kernel tree that shouldn't have been, I guess that needs sorting out.  I'll raise a bug.
 * bjf-afk will be back in a few minutes
<dmart> I've raised a bug and subscribed you guysâ cheers.
<ogra> thanks
<bjf> dmart, got a bug number for that?
<dmart> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/474322
<ubot4> Launchpad bug 474322 in linux "linux-image-2.6.28-16-imx51 appears broken on armel" [Undecided,New]
<bjf> tanks
<armin76> looks like freescale is now selling an eval board of imx51
#ubuntu-arm 2009-11-05
<zooko> Does anyone know what boards are going to be supported by Lucid?
<eggonlea> hi, here's a question about initramfs: I did see the following scripts in /init which deals with root=/dev/nfs and export BOOT=nfs. Why I still need modify /etc/initramfs-tools/initramfs.conf to change BOOT from local to nfs?
<eggonlea> I tried NOT to modify BOOT from local to nfs. The result is the export BOOT=nfs script in /init do NOT work.
<eggonlea> I still saw BOOT=local by command "env", even if I pass "root=/dev/nfs" in bootargs in uboot.
<eggonlea> PS: I'm using default Karmic release
<eggonlea> linux-image-2.6.31-208-dove_2.6.31-208.16_armel.deb
<eggonlea> Is it necessary to create another special uInitrd.nfs for nfs boot?
<eggonlea> thanks
<eggonlea> Sorry, I double checked the /init script and found I missed the following condition
<eggonlea> /dev/nfs)
<eggonlea>                         [ -z "${BOOT}" ] && BOOT=nfs
<eggonlea> it would NOT export BOOT=nfs if BOOT has another value already (local here).
<lool> eggonlea: You could try passing boot=nfs on the kernel cmdline
<lool> Oh /dev/nfs probably does the trick yes
<eggonlea> let me try
<eggonlea> could we just remove this "[ -z "${BOOT}" ]" in /init?
<eggonlea> well, boot=nfs in cmdline works.
<eggonlea> we have so many args here: netboot, boot, nfsroot=/dev/nfs, BOOT_in_initramfs.conf.
<eggonlea> Have to go through the whole /init script to understand the priority. :(
<eggonlea> anyway, boot_in_cmdline > BOOT_in_initramfs.conf > nfsroot=/dev/nfs_in_cmdline. Thanks!
<lool> Cool
<jean85_> am not getting GUI for ubuntu on dvi... anybody help...
<Stskeeps> check /var/log/Xorg.0.log
<jean85_> but am getting console version on dvi
<jean85_> which image i should get for GUI?
<kblin> just log in and install xfce or whatever gui you want
<kblin> jean85_: You could try installing xubuntu-desktop
<kblin> but maybe even that is too memory-hungry for the ram you have on a beagle
<kblin> as I said, I've never hooked up a monitor to my beagles
<BeardedChimp> I have compiled a kernel for my board, How to I generate the folders for it such that I can insert into my rootfs /lib/modules/2.6.....
<dmart> Try make INSTALL_MOD_PATH=$PWD/modules-tmp modules_install
<dmart> This should build a suitable lib/modules tree in the scratch directory modules-tmp.
<BeardedChimp> dmart: Cheers, I'll try that
<BeardedChimp> dmart: Thank worked great cheers, I'm looking to do something similar for creating the linux-headers do you know a similar command?
<dmart> Can't help you there I'm afraid... I'm guessing that simply copying linux/include may not work well enough.  You could maybe examine debian/rules for the Ubuntu kernel source packages and see how the kernel-headers-* packages are generated.
<dmart> Unless you want to rebuild glibc or other low level components, you may get away with not having the correct kernel headers in your fs though.
<BeardedChimp> Yeah I don't need them at the minute because I compiled a newer kernel than came with the board for some hardware only supported later, before I was trying to compile the kernel module for the old (2.6.21) kernel but was stuggling with getting the correct kernel headers
#ubuntu-arm 2009-11-06
<ojn> How does canonical do the package builds? Natively on arm boards, or in qemu? or distcc:d out of the arm systems onto faster machines for the compiler?
#ubuntu-arm 2009-11-07
<kblin> rcn-ee: evening :)
<rcn-ee> hey kblin..
<kblin> rcn-ee: so it seems like your builders still have a fun time? :)
<rcn-ee> kblin, laughs, it's back up running full speed again.. the musb bug trashed the whole drive (had seperate ext3 partitions..)
<rcn-ee> after i built 2.6.31.5, i rebuilt it again with the new kernel just incase..
<kblin> sounds reasonable :)
<rcn-ee> can't be to safe...  it's working on 2.6.29 again, i double checked it on friday, it should enable the musb port..
<rcn-ee> kblin, now that i got the main builder again, i'd like to find a web gui/script to allow people to upload *.tar.gz & *.dsc... know of anything?
<kblin> not really. but web stuff is kind of off my radar.. I'm pretending to be a systems developer:)
#ubuntu-arm 2009-11-08
<dirk2> Actually, I'm looking into recent rootstock script. For 'karmic' it uses vmlinuz-2.6.31-rc3versatile1-cortex-a8 and -cpu cortex-a8. Is this only the configuration options for QEMU, or are the is the resulting rootfs compiled for A8, too? Or the other way around: Will a karmic rootfs created with rootstock run on ARM11, too?
<ojn> ARM11 is ARMv6. Karmic is built for v6 + VFP, so as long as your specific ARM11 has VFP you should be good
<kblin> ojn: so karmic won't work on the maxwell sheevaplug? that's an ARMv5
<ojn> kblin: Correct, as far as I know.
<kblin> oh well, mine is currently having fu being shipped around the world, I'll start worring as soon as it gets back here :)
<armin76> s/maxwell/marvell
<kblin> fun, as well
<kblin> er, right
<dirk2> ojn: Thanks! Will try it then :)
 * kblin is feeling brave and remote-updates his home server's kernel
<kblin> oh, crap, mkimage failed.. and of course I see that the minute after I hit reboot
<kblin> that was so bound to happen
 * kblin hugs the serial console :)
#ubuntu-arm 2010-11-08
<hrw> morgen
 * cwillu pokes
<cwillu> you're not rcn-ee :/
<hrw> if I want to change something in ubuntu kernel config for panda how to get .config in other way then cp /boot/config-*?
<cwillu_at_work> hrw, that's the only way, unless /proc/config has been enabled in the kernel (which it hasn't in ubuntu afaik()
<hrw> cwillu_at_work: "apt-get source linux-ti-omap4" gave me ubuntu source package but it uses split config
<sebjan_> hrw: to get the running defconfig, just run zcat /proc/config.gz
<hrw> let me rephrase question: how to get kernel config from inside of linux-ti-omap4 source package?
<sebjan_> hrw: ok, sorry. the config shall be in a folder debian.ti-omap4/config/config.common.ubuntu. Do you have this file in the source package?
<hrw> yep - but tahts all?
<sebjan_> hrw: yes, what did you expect?
<hrw> preferred to be sure - split configs exists for a reason
<sebjan_> hrw: right, it is not used in this case, not sure why actually...
<hrw> sebjan_: one flavour only
<sebjan_> yes, it makes sense...
<ogra> hrw, so looking at your genesi f-k patch, it seems to expect that /boot is a vfat
<ogra> that wont work
<hrw> ogra: flash-kernel is set of hacks already
<ogra> hrw, that doesnt solve the probelm that /boot cant be vfat :)
<hrw> on smarttop it is ext2 by default
<hrw> smartbook I mean
<ogra> oh, that seems fine then, is it the same on smartbook ?
<ogra> ah
<hrw> markos_: does smarttop has /boot/ also on pata drive like it is in smartbook?
<ogra> and does it use ext2 too ?
<ogra> :)
<markos_> ogra: initially it used vfat but now with new uboot it's able to use ext2 as wel
<markos_> but yes
<ogra> hrw, well, if its all ext2 then your patch seems fine to me
<markos_> it needs a uboot upgrade though
<hrw> ogra: I would prefer rewrite of whole script but no devices to check does it works properly on all
<markos_> old smarttops will have to be upgraded first
<ogra> hrw, i would prefer we split flash-kernel in functions and device spcific parts ... but i guess that needs wider discussion with debian-arm
<hrw> yep
<ogra> i.e. have a flash-kernel-common package that provides script snippets we can source
<hrw> ogra: even flash-kernel can get rewrite properly
<ogra> well, heh
<ogra> f-k is somewhat constantly being rewritten
<hrw> compare omap_flash_kernel and efikamx_flash_kernel functions
<hrw> both have update_uImage_symlink() update_initrd_symlink()
<ogra> hrw, well, theye functions come from NCommander for his generic update
<ogra> which is very broken anyway
<ogra> they neerd fixing all over
<ogra> *need
<hrw> I am a bit tired of rewriting update scripts again and again
<hrw> few years ago I merged 5-6 zaurus update scripts into one
<ogra> right
<hrw> took year to get it tested on all supported devices and 2-3 developers more
<ogra> what i want is device specific functions separate from HW specific ones
<ogra> i.e. update NAND ... update u-boot_vfat separated from the omap or dove or whatever functions
<hrw> it looks like omap and dove support was added by ubuntu
<ogra> yes
<ogra> omap was initially aded by me, dove comes from NCommander
<ogra> both were completely redone when NCommander added the "improved subarch detection" stuff
<hrw> style is completely different
<ogra> yes
<ogra> it was initally identical
<ogra> but the spec was implemented in a way to use uname instead of /proc/cpuinfo
<ogra> which breaks the style
<ogra> hrw, for that part you should discuss with NCommander
<ogra> this change also introduces bugs for unsupported boards ... i.e. it makes it try to flash to NAND on blaze (where no nand exists)
<hrw> how to get default set of kernel options for arm device in ubuntu?
<ogra_ac> hrw, /boot/config-$(uname -r)
<ogra_ac> for source config, ask the kernel team
<rsalveti> don't know exactly how the kernel selects the default options for arm in general
<hrw> k
<rsalveti> but at the git repository you can already check what is common
<rsalveti> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-maverick.git;a=blob;f=debian.master/config/armel/config.common.armel;h=0f0e053b1780d9d67b9c0ac7d1051fabf3d176b8;hb=HEAD
<rsalveti> for example
<rsalveti> as the master repo has both omap and versatile
<ogra_ac> well, the actual config is merged from nippets during package build iirc
<rsalveti> yup
<ogra_ac> *snippets
<hrw> ok
<hrw> thx
<rsalveti> hrw: but the "default" options is something that maybe someone from the kernel team can help you
<ogra_ac> easiest is really to just wget the binary and dpkg -x it i bet
<hrw> ok
<hrw> trying to make efikasb kernel to be more ubuntu like
<ogra_ac> build a package ;)
<hrw> already did
<ogra_ac> ah, cool
<rsalveti> there are also some extra ubuntu sauce generally applied at ubuntu's kernel
<rsalveti> don't know if you wan to check those too
<rsalveti> hrw: and which version are you building? the stock 2.6.31 kernel?
<ogra_ac> you should add them if possible, often distro userspace features correspond to them
<hrw> rsalveti: yes 2.6.31.14.6
<hrw> and do not plan to add ubuntu patches on top of it
 * hrw is not kernel hacker
<cooloney> oh, are you guys talking about linaro kernel or ubuntu kernel?
<ogra_ac> what i did for the ac100 kernel was to ssh into my panda that had a source tree, copy the config to .config and then run make menuconfig on both
<hrw> none of those cooloney
<cooloney> rsalveti: how's going, had a nice vacation?
<cooloney> hrw: got this, man
<ogra_ac> its very time consuming to do it that way but you will end up with modtly identical configs
<ogra_ac> *mostly
<rsalveti> cooloney: yup, very nice :-)
<cooloney> rsalveti: great. man
 * cooloney just read a news, Marvell release a qual-core ARM chip
<hrw> CONFIG_SCSI_MULTI_LUN is not set in TI-omap4... bad
<rsalveti> cooloney: how was plumbers?
<rsalveti> hrw: ti-omap4 unfortunately doesn't contain all arm common defines at the master repo
<cooloney> http://www.marvell.com/company/news/press_detail.html?releaseID=1447
<cooloney> rsalveti: very good
<cooloney> met several linux-omap folks and other ARM guys
<hrw> rsalveti: extra fun is that efikas have usb-wifi which rt2800usb does not want to load firmware for (and same firmware works with staging driver)
<rsalveti> cooloney: cool :-)
<cooloney> hrw: what's CONFIG_SCSI_MULTI_LUN for?
<rsalveti> hrw: haha :-)
<cooloney> hrw: i guess it is for some multi volume USB disk?
<hrw> cooloney: Prompt: Probe all LUNs on each SCSI device
<hrw> cooloney: think: real multislot card readers for example
<ogra_ac> does the efika have that ?
<hrw> cooloney: and I have one of those
<hrw> ogra_ac: I have such on usb
 * GrueMaster drools over the marvel XP specs.
<ogra_ac> oh, that doesnt show as usb disks ?
<ogra_ac> intresting
<hrw> ogra_ac: without multi_lun only CF works. with: cf, sd, ms, xd
<ogra_ac> well, then we should enable it asap
<ogra_ac> file a bug ;)
<hrw> ogra_ac: popular cheap multislot readers have one controler so one card at time. this one handle 4 cards at same time
<cooloney> hrw: good point. could you please file a bug, then we can SRU a patch
<hrw> bug 672635
<ubot2> Launchpad bug 672635 in linux-ti-omap4 (Ubuntu) "enable CONFIG_SCSI_MULTI_LUN (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/672635
 * ogra_ac triages it properly
<cooloney> hrw: thx, man, you are so quick
<ogra_ac> sbambrough, hey
<sbambrough> hey ogra_ac
<ogra_ac> sbambrough, are you subscribed to ubuntu-devel ?
<ogra_ac> (the mailing list)
<ogra_ac> i sent some questions regarding the possibility about using linaor kernels to it today, might intrest you too
<ogra_ac> *linaro
<sbambrough> ogra_ac,  I don't believe I am
<ogra_ac> https://lists.ubuntu.com/archives/ubuntu-devel/2010-November/031952.html
<ogra_ac> cooloney, ^^^ something to bring up at the kernel team meeting i belive
<sbambrough> ogra_ac, your right they do interest me, though I don't have any answers right now
<cooloney> ogra_ac: ok, got it.
<ogra_ac> sbambrough, yeah, i dont expect answers right now, but we need to find some ;)
<rsalveti> ogra_ac: were you able to test the new qt packages?
<ogra_ac> rsalveti, yes
<rsalveti> and?
<ogra_ac> Illegal instruction
<ogra_ac> :(
<ogra_ac> see the bug
<ogra_ac> tiago also commented
<rsalveti> oh, cool, too much emails at my inbox
<ogra_ac> sadly it doesnt seem to work as expected
<ogra_ac> tiagos test of just running the lib seems to show no misdetectin though
<GrueMaster> Might be another failure point.
<ogra_ac> i.e. i dont get the processor features line he mentions
<ogra_ac> GrueMaster, well, its definitely NEON related given just building it with NEON disabled makes it all work fine
<GrueMaster> What I mean is it may be code that is ouside the run-time detection.
<rsalveti> ogra_ac: remember he's using qt 4.7.1 while posting at the bug
<ogra_ac> rsalveti, yeah
<rsalveti> maybe this processor features is not there for the version we're using
<rsalveti> I don't get it even on panda
<ogra_ac> yup
 * ogra_ac hasnt set up his panda yet for cross checking
<GrueMaster> What's the bug number again?  I can test the code on my dove to verify.
<ogra_ac> i have barely unpacked my suitcase
<rsalveti> bug 664431
<ubot2> Launchpad bug 664431 in qt4-x11 (Ubuntu Natty) (and 2 other projects) "QT on armel is built with NEON by default (affects: 2) (dups: 1) (heat: 30)" [Undecided,New] https://launchpad.net/bugs/664431
<rsalveti> ogra_ac: does it also crashes while running QT_NO_NEON=1 mumble?
<ogra_ac> yep
<rsalveti> could be the case that the features thing is not working the way expected
<ogra_ac> yes, i would expect so
<rsalveti> I don't believe it was ever tested on a no-neon hardware
<ogra_ac> to sad that slangasek already dropped the working packages
<slangasek> "working"?  those packages were sitting verification-failed for some time before I removed them
<rsalveti> would be good to trace the error
<ogra_ac> slangasek, huh ? who did set that ?
 * ogra_ac checks the bug
<Jefro> hi all - if anyone has a second to help me get rcn-ee's scripts working for a beagleboard, I'd love a hand
<ogra_ac> slangasek, now thats weird, while i see that pitti set it to failed i dont get why
<slangasek> ogra_ac: because it was reported to regress on non-NEON systems
<ogra_ac> Jefro, best is to wait for rcn-ee for that
<ogra_ac> slangasek, err, no, exactly the opposite
<ogra_ac> slangasek, it fixed it for non-NEON systems
<slangasek> oh right; it was reported to regress on NEON systems
<Jefro> ogra_ac - thanks
<ogra_ac> which is nonsense
<slangasek> <shrug>
<ogra_ac> given we announce that no library in maverick will do NEON
<ogra_ac> so it breaks a commitment
<slangasek> no library in maverick will *require* NEON
<ogra_ac> right
<ogra_ac> given that QT in maverick can currently only be build with statically having NEON on or off my upload was a proper fix
<ogra_ac> that upstream tried to add dynamic detection doesnt make the fix less valid
<ogra_ac> until we have a dynamic fix in place at least
<rsalveti> ogra_ac: I also believe it is a post release regression to just disable it at qt
<rsalveti> I know we're saying we're building without neon by default
<rsalveti> but would be strange for users to have qt running slower because of an update
<ogra_ac> well
<rsalveti> doesn't make sense to me
<ogra_ac> talk to davidm
<rsalveti> that's why I thought it would be better to just fix the run time detection
<ogra_ac> i had a pretty strict request to switch it off immediately
<rsalveti> ogra_ac: why? it's a ubuntu discussion in general, I understand the problems
<ogra_ac> yes, i agree that runtime detection is a better fix, but if it doesnt work we have to fix it another way
<rsalveti> sure, in case it doesn't work we just disable it
<ogra_ac> and apparently the only way is static atm
<rsalveti> but first let's try to get the proper fix in
<ogra_ac> right
<ogra_ac> but the "proper" fix seems ot require far more currently
<ogra_ac> since just backporting from upstream doesnt seem to work
<rsalveti> it seems, let's at least get the correct trace
<rsalveti> and identify what's happening
<rsalveti> don't think that will take a lot of time
<ogra_ac> no
<ogra_ac> what i'm concerned about it that i already drown in mail from people running QT apps on the ac100, that the working packages were removed from proposed is a bit disturbing
<rsalveti> I know, but let's give at least one or two days to try to get the proper fix
<ogra_ac> yes
<rsalveti> now that you have the hardware and can try to trace the problem
<rsalveti> if we're unable to fix, push the new packages without neon at all and we're fine
<ogra_ac> right, though i wont do that tonight anymore ... i'm jetlagged and did get off a plane less than 24h ago
<rsalveti> ogra_ac: sure, take your time
<rsalveti> ogra_ac: go to sleep then :-)
<ogra_ac> i would have tested during plumbers, but they dont have an elmo (read: the network there was so bad that most of us couldnt even get their mails)
<rsalveti> yeah, elmo rocks
<rsalveti> uds was perfect
<ogra_ac> to early for bed yet ... need to stay up to get my schedule correct
<ogra_ac> just thinking is a bit hard atm :)
<rsalveti> :-)
<ogra_ac> plumbers was depressing overall
<rsalveti> ogra_ac: why? no interesting stuff to discuss this year?
<ogra_ac> now that they are over upstart vs systemd they start bashing us for copyright assignment
<rsalveti> haha, they will always find something to complain :-)
<ogra_ac> well, there was intresting stuff but i didnt like the mood
<ogra_ac> also seeing how lennart pulled strings to make all upstreams use systemd and Keybuk not being there at all to be able to stop that was annoying
<ogra_ac> seems that many userspace things will defauolt to systemd in the  near future
<ogra_ac> i.e. gnome-session will go away
<rsalveti> got it
<ogra_ac> all in all it felt like a redhat/intel conference
<ogra_ac> i felt very misplaced
<rsalveti> but it was, somehow
<ogra_ac> yes
<ogra_ac> its just sad to see that so many important decisions are made there and that they are made with an anti ubuntu attitude in mind
<GrueMaster> ogra_ac: rsalveti:  Ok, after many interruptions, I finally downloaded the QT library from https://launchpad.net/~rsalveti/+archive/armel/+files/libqtcore4_4.7.0-0ubuntu5_armel.deb and it seems to be ok on my dove.
<ogra_ac> GrueMaster, you can run mumble ?
<ogra_ac> thats my testcase on the ac10
<ogra_ac> 0
<GrueMaster> Haven't tried mumble.
<GrueMaster> This is on my dove buildd (rack in basement).
<rsalveti>  should fail while loading mumble
<ogra_ac> right
<GrueMaster> Other system has been offline since Dallas.
<ogra_ac> you should get a SIGILL
<GrueMaster> I ran it according to the instructions in the bug, comment #30.  Will find some test apps.
<ogra_ac> comment 30 is useless with our version
<ogra_ac> 8as you can see from the above discussion)
<rsalveti> could -mfpu=neon optimize general fp code at the qt build?
<rsalveti> then it'll fail for sure
<GrueMaster> I may give my son some spare hw next time I see him.  He knows a lot about QT.
<ogra_ac> GrueMaster, just run mumble ;)
<ogra_ac> thats a safe test
<ogra_ac> no need to install a desktop for that, just use ssh -X user@dove mumble
<GrueMaster> I can't.  The system has a minimal install for building.  No X.
<GrueMaster> Still need to install for dependencies.
<ogra_ac> use a chroot
<ogra_ac> its not that it will take much time with a local mirror
<GrueMaster> I'll unpack my A0 and get it running in a bit.
<GrueMaster> It looks like it will take 64 minutes just to pull the PPA packages.
<GrueMaster> They're not mirrored.
<ogra_ac> ah
<GrueMaster> Not sure if it is my end or lp, but I am only getting 3.8K/s pulling the packages from rsalveti's ppa.
<rcn-ee> Jefro, ping
<Jefro> rcn-ee hey!  thanks - I am having difficulty with the beagleboard script
<rcn-ee> hey Jefro,which of the scripts are you haing issues with? is it doing something odd?
<Jefro> ./setup_sdcard.sh gives me a syntax error
<Jefro> ./setup_sdcard.sh: line 333: syntax error near unexpected token `>'
<rcn-ee> that might be a bashism.. ;)
<Jefro> it must be.  the line has a " &>> " in it.
<rcn-ee> is that the 'sd.log' part of the script? you can just comment that out, it's just to make it less noisy..
<Jefro> I succeeded in getting it to work by putting a space between & and >> but now I think I probably should have just taken out the & and put a 2&>1 at the end
<Jefro> ah, ok - looking
<Jefro> yes, that is the sd.log line
<Jefro> the resulting image, however, fails to boot on my xM A2
<Jefro> well, it boots up to a certain point but then fails with 'no init' and leaves me at an (initrd) prompt
<rcn-ee> yeah, just nuke the "&>> ${DIR}/sd.log"  i'll come up with something else to work better with dash..
<rcn-ee> That's weird, what was your full "./setup..." line?
<rcn-ee> (i have an A2 i test it on..)
<Jefro> ./setup_sdcard.sh --mmc /dev/sdf --uboot beagle --use-default-user
<Jefro> I'll try it again, just a sec (currently running rsalveti's preinstalled image)
<rcn-ee> weird, that's perfect....
<rcn-ee> by chance is it 16/8g card? i've had some users report problems with that, but haven't been able to replicate it..
<Jefro> 4G Kingston card
<Jefro> oops, no, that's the other one - this is a 4G no-name card
<Jefro> I'll try it on the Kingston card
<rcn-ee> another thing, if the script dies on error, it actually doesn't finish building the image..
<Jefro> it looked like it completed - running now on different card
<Jefro> looks like it completed.  the last line is "Formatting Boot Partition."
<rcn-ee> that's not even close.. ;)
<Jefro> hoo boy.  is there a -v I can turn on?
<Jefro> I'm running this on Ubuntu 8.10 BTW
<Jefro> if that makes a dif
<rcn-ee> not really, it's a pretty simple/stupid script.. ;)  the last thing it really says "Populating rootfs Partition"
<Jefro> ha... well, that may be why it only got as far as initrd!
<rcn-ee> i'm suprised it got that far... if it died after building the first fatfs, there shouldn't have even been an uImage...
<Jefro> it looks like it populated the boot partition
<Jefro> this is for a "getting started" article, so I may go with rsalveti's premade script for now and point readers at the rootstock instructions if they want to go further.  Does that sound reasonable?
<rcn-ee> so maybe 8.04 just didn't like the "&>>"...  format fatfs, copy bootloader, format ext, copy rootfs...
<Jefro> very possibly.  I'll try it on my laptop, which has 9.10 installed.
<rsalveti> Jefro: pre-installed image is easier for the first moment
<rsalveti> then you can point for advanced customizations
<rsalveti> and also rcn-ee's kernel
<rsalveti> in case people want to hack the normal ubuntu image
<rcn-ee> rsalveti, you guys ready for another sru the next "xm"? ;) (u-boot)..
<rsalveti> rcn-ee: haha :-)
<rcn-ee> i saw them on the u-boot list, and went oh my..... ;)
<rsalveti> rcn-ee: that's why for natty we'll be upgrading the x-loader/u-boot when needed
<rsalveti> or at least warn the user that he needs to update it, and create a tool for it
<rsalveti> but yeah, sru all around :-)
<rsalveti> GrueMaster: later on if you want to help and have enough time, please help getting the qt trace
<GrueMaster> Will do.
<rsalveti> so we can find where and which instruction is breaking qt
<rsalveti> I'd like to get some kind of qt benchmark, to compare the performance with and without neon
<rsalveti> will try to dig one at the qt examples/tests/demos files at the git tree
<Jefro> rsalveti rcn-ee thanks for the help
<GrueMaster> Thats why I want to get my son involved.  He can create one.
<rlameiro> ogra_ac: are you running on the AC100?
<rsalveti> GrueMaster: do you remember where you got the cpuburn package while stressing panda at dallas?
<rsalveti> don't remember if vstehle gave us or we just got it somewhere
<ogra_ac> rlameiro, yes, i do
<vstehle> rsalveti, GrueMaster, you need to grab the latest cpuburn at http://pages.sbcglobal.net/redelm/ and compile the arm binaries
<rsalveti> vstehle: cool, thanks
<rlameiro> ogra_ac: How is it working? does everything works now? I am lining to buy one... on amazon
<rsalveti> need to push that to our archive
<rsalveti> orbarron: ^
<Jefro> rcn-ee - new data point, when I used 9.10 to write the card it did get all the way to "populating rootfs" but still doesn't boot:  "No init found." and an (initramfs) prompt.
<ogra_ac> rlameiro, nope, things are slowly getting better i think, but i havent tried any of the new hacks from phh yet
<vstehle> (I requested packaging in Bug #651576)
<ubot2> Launchpad bug 651576 in cpuburn (Ubuntu) "cpuburn now has Cortex-A8 and Cortex-A9 versions, please build for armv7a (affects: 1) (heat: 95)" [Undecided,New] https://launchpad.net/bugs/651576
<rlameiro> ok
<rlameiro> i go to the ac100 to see if I can extract more info ;)
<ogra_ac> they are just trying to get backlight on/off on lid close to work
<cwillu_at_work> rcn-ee, poke poke
<ogra_ac> i personally was traveling fo ra few weeks, just got back yesterday
<rcn-ee> hey cwillu_at_work that zippy still failing?
<cwillu_at_work> hey;  only when I start up the network
<cwillu_at_work> haven't been able to get any kernel messages out of it though
<prpplague> cwillu_at_work: zippy giving you trouble?
<rcn-ee> so every boot...  how do you like the ck patchset?
<cwillu_at_work> prpplague, ooo, both of you at the same time :)
<prpplague> cwillu_at_work: zippy or zippy2 ?
<cwillu_at_work> 2
<cwillu_at_work> prpplague, ks8851 troubles, specifically
<cwillu_at_work> rcn-ee, nothing conclusive yet;  I'm using it on this desktop, and it seems to be an improvement, although I'm waiting another week until I say that for sure
<cwillu_at_work> (the problem with long uptimes is that you're never sure if things are faster because you rebooted, or because of the thing you changed that caused you to reboot)
<rcn-ee> okay, cool...  i have a patchset saved on my work machine for the ck stuff that i'm about to push.. ;)
<rcn-ee> true true..
<cwillu_at_work> prpplague, want to know about my ks8851 troubles? :p
<prpplague> cwillu_at_work: yea
<cwillu_at_work> prpplague, cable plug events don't seem to make it to network manager et al
<cwillu_at_work> prpplague, I hacked something up with mii-tool (which polls the mii status directly once per second) to simulate the behaviour
<prpplague> cwillu_at_work: do the events show up on the CL level?
<cwillu_at_work> nope
<prpplague> interesting
<prpplague> you using it with a panda or beagle?
<cwillu_at_work> beagle
<cwillu_at_work> c3 and c4
<GrueMaster> vstehle: pulling it now.
<cwillu_at_work> prpplague, no, the _interesting_ part is that if I restart network manager _while_ copying data to a local machine _while_ mii-tool is running, everything dies
<prpplague> right now i only have panda's at my desk, i'll have to pick up a beagle from the office to do some testing
<prpplague> interestin
<cwillu_at_work> I think I have a stack trace around still
<cwillu_at_work> it dies in a weird fashion too :)
<cwillu_at_work> processes go into uninteruptable state;  I _think_ it's when they try to access the network, but I'm not certain  (x will hardlock, for instance)
<cwillu_at_work> sysrq-w shows them in that state though
<cwillu_at_work> the end of the dmesg is a preempt count oops or something
 * cwillu_at_work looks for it
<cwillu_at_work> sorry, my hairy electrician called
 * cwillu_at_work starts looking again
<cwillu_at_work> prpplague, http://pastebin.com/ZPXdqwfw
 * prpplague looks
<cwillu_at_work> I've got another trace with some magic sysrq info as well
<prpplague> cwillu_at_work: interesting
<cwillu_at_work> sysrq log coming
<cwillu_at_work> prpplague, http://pastebin.com/vdrrr8iL
 * prpplague looks
<cwillu_at_work> prpplague, I don't know that it's related, but::  I had rcn-ee compile me a 2.6.36 with ck2 (con kolivas's patchset with scheduler and vm changes) for kicks;  it works fine under fairly heavy load for days, until I connect the zippy's ethernet and configure the interface;  moments later, the system hardlocks
<cwillu_at_work> I haven't been able to capture any messages from such a failure though
<prpplague> just a rough guess would be that the communication with the KS8851 is getting part of the packet trashed and it is trying to read beyond the allocated packet
<prpplague> i'd have to check but there were some similar problems reported with blaze
<prpplague> (blaze uses the KS8851 in the exact same way as the zippy2)
<cwillu_at_work> prpplague, I _don't_ get the problem unless I have both mii-tool running _and_ I restart network-manager _and_ there's network activity at the wrong time
<cwillu_at_work> I've noticed this sporadically when poking a beagle remotely (i.e., the far end of a 128kb link), but I can trigger it every time if I scp a couple hundred megs locally, with "mii-tool -w" running, and then restarting network-manager with the transfer still running
<cwillu_at_work> my guess is that mii-tool is holding something open that network-manager causes to be reset or whatever, at the same time as a packet comes in and does what you said before
<cwillu_at_work> sporadically == once or twice a day
<prpplague> interesting
<cwillu_at_work> since I disabled my mii-tool hack, (restarting network-manager when an ssh connection dies rather than when mii-tool -w spits out a line), I haven't seen a single crash yet in two weeks
<cwillu_at_work> I'm also suspicious that my ck2 crashes are related, given the scheduling changes + the "note: omap2_mcspi[14] exited with preempt_count 1" I get from a non ck2 kernel
<cwillu_at_work> just can't prove it :p
<cwillu_at_work> I've got several beagles and zippies and sd cards that I can duplicate this on, too :p
<cwillu_at_work> (note, those two traces are on different kernels;  the earlier was 2.6.35rc5, longer one was 2.6.35.7
 * cwillu_at_work pokes at prpplague 
<cwillu_at_work> fixed it yet? :D
<prpplague> cwillu_at_work: i'll have to see if i can replicate it on a beagle, all i have right now are pandas
<cwillu_at_work> can a panda use a zippy2?
<RXShorty> Hello all +~
 * cwillu_at_work shorts RXShorty to ~neutral
<RXShorty> Does anyone here has a Sharp Netwalker?
<RXShorty> The reason I ask that Ubuntu 9.04 is getting old with packages, maybe someone already made a 10.04 version?
 * rsalveti brb
<ndec> rsalveti: hi
<ndec> rsalveti: i was looking at pixman build log on LP, and it seems that it got compiled with NEON enabled. is that expected?
<ndec> ogra: hi. see ^^^ in case you are here too
<armin76> ndec: pixman has runtime neon detection
<ndec> armin76: really? that's cool. i didn't know
<ndec> armin76: is that documented?
<armin76> ndec: i'm not sure, you'd have to ask ssvb since he did the work
<ndec> armin76: looking at src, i think it's implemented in pixman-cpu.c, function _pixman_choose_implementation(). thanks for the tip
<cooloney> ndec: could you please help to take a look at this bug 666267
<ubot2> Launchpad bug 666267 in linux-ti-omap4 (Ubuntu) "Cross compiled headers package breaks DKMS compilation (affects: 1) (heat: 226)" [Medium,New] https://launchpad.net/bugs/666267
<cooloney> ndec: after some discussion with andy and tim, we need some testing
<ndec> cooloney: hi. sure we can test. where you able to test?
<cooloney> ndec: oh, i am working from our Boston office these 2 days, don't have hardware to test
<cooloney> ndec: will be back to home this Thursday
<ndec> cooloney: ok. will try to see tomorrow from the office then. vstehle might be able to test this
<cooloney> ndec: yeah, great.
<cooloney> ndec: i think it's a bit little later for you guys
<cooloney> now.
#ubuntu-arm 2010-11-09
<hrw> elo
<cwillu_at_work> hrw, can you fix my network driver?
<cwillu_at_work> actually, I wonder if they have a useable datasheet
<hrw> cwillu_at_work: I am not kernel hacker sorry
<cwillu_at_work> and?
<suihkulokki> cwillu_at_work: I guess you can google for the datasheet faster than hrw :P
<cwillu_at_work> hmm
<cwillu_at_work> I wonder if this stick on the chip is actually intended for heat sinking purposes or something, or if it's just a qa thing
<cwillu_at_work> given that it completely covers the chip
<cwillu_at_work> also, who took my small screwdriver?
<cwillu_at_work> never a prpplague around when you need one :/
 * cwillu_at_work gets some rubbing alcohol
<cwillu_at_work> 80 pages
<cwillu_at_work> this might be useful
<hrw> ;D
<bernard_> hi. who could i prod to make a change to the images here? http://cdimage.ubuntu.com/ubuntu-netbook/ports/releases/10.10/release/
<bernard_> i'm not sure if the omap4 ones are meant to be pandaboard-specific (some bits are), but currently it doesn't allow overriding the kernel cmdline arguments
<bernard_> which makes it difficult to add a console= argument to get any sign of life
<rsalveti> bernard_: after writing the image to your sd card you're free to mount the first disk partition and change the boot.scr file
<bernard_> yep, i know this
<rsalveti> with the proper cmdline arguments you need
<rsalveti> so, what exactly do you want to do?
<bernard_> but other people are running into the same issue. and it seems odd that it doesn't do so out of the box
<bernard_> i just add console=ttyO2,115200n8 to the cmdline
<bernard_> which if it's a pandaboard-specific image is probably fine to do
<rsalveti> yeah, there was a decision to avoid enabling console by default
<rsalveti> the omap 4 image is basically targeting panda, so that's ok
<bernard_> please take this as a vote to enable console by default :)
<bernard_> the kernel can be booted with quiet, so as to not slow down boot, and then a getty put on the terminal
<rsalveti> yeah, I don't see why we can't at least enable a valid getty for it
<bernard_> that would rock
<bernard_> a way to append to bootargs without having to edit the SD card would be awesome too!
<ogra_ac> wont happen unless you convince TI to add NAND
<ogra_ac> there is no ways to save them
<bernard_> i want to be able to override from u-boot (mainly for dev)
<bernard_> e.g. trying to figure out what args to pass to the kernel to get video working how i want
<rsalveti> iirc sakoman was working in a way to save the env somewhere else than nand
<ogra_ac> if you add the above console= parameter to treh cmdline *before* first boot it will set up a serial console for you automatically
<rsalveti> don't remember if it was just emmc though
<ogra_ac> yes, we might switch to a raw partition intead of vfat in natty
<rsalveti> ogra_ac: did you test that, because the all cmdline arguments kernel patch to init was applied later on
<ogra_ac> that way you can treat iut like NAND and have some area to saveenv to
<rsalveti> and we had to create a different uImage for blaze at least
<ogra_ac> iirc jasper parses /proc/cmdline still
<ogra_ac> so the kernel patch shouldnt be needed
<rsalveti> hehe, some files parse /proc/cmdline and other don't
<rsalveti> ogra_ac: but why can't we just enable the getty for uart by default?
<ogra_ac> i will have to check the code
<rsalveti> I mean, for natty
<ogra_ac> rsalveti, see the jasper-rewrite spec ...
<ogra_ac> we will if upstart allows it
<ogra_ac> it has to happen there
<rsalveti> yeah, it's hardware specific =\
<ogra_ac> for x in $(cat /proc/cmdline); do
<ogra_ac>     case ${x} in
<ogra_ac>         console=tty[A-Z]*)
<ogra_ac> so the kernel patch shouldnt matter
<ogra_ac> but its essential to do it before first boot
<rsalveti> cool
<rsalveti> yep
<bernard_> i found it a little bit creepy that the first boot modified the system and then rebooted. what does it do?
<ogra_ac> all things the debian-installer would do otherwise
<rsalveti> bernard_: mainly resize the sd card
<bernard_> ah, fair enough
<ogra_ac> it also sets up the board specific stuff
<ogra_ac> it will change a lot in next release, but the resizing will have to stay
<bernard_> oh, so an interesting bug report - when I dd'd the image to my SD card, the ext3 partition wasn't where it was supposed to be.
<bernard_> running "file - < /dev/sdb2" just reported "data"
<bernard_> i ended up running mkfs and copying the files in manually from the image.
<ogra_ac> thats why the resizing bit is there
<ogra_ac> you shouldnever tinker with it after dd
<bernard_> the image didn't even boot though, because the partition table was pointing to the wrong place.
<bernard_> i'm not sure what it was about the SD card, but i can dig deeper tomorrow morning (in about 9 hours, here)
<ogra_ac> its a 4G or bigger card, right ?
<bernard_> 4G SD card, yep
 * ogra_ac only has heard of probs if people didnt stick to the minimal card size
<bernard_> dd didn't complain, cmp against the ungzip'd image matched.
<bernard_> i didn't dig much deeper at the time, but i can have another look in the morning.
<ogra_ac> oh, you gunzipped
<ogra_ac> rit, you said dd ...
<ogra_ac> just use zcat ;) dont waste your diskspace
<bernard_> to write the image, i did 'zcat foo.img | dd of=/dev/sdb'. to do a compare, i had to unzip, and then did 'cmp foo.img /dev/sdb'
<ogra_ac> thats completely worng
<ogra_ac> which install doc did you follow
<ogra_ac> https://wiki.ubuntu.com/ARM/OMAP
<bernard_> i was following what i normally do for writing images to media, not the instructions, sorry!
<bernard_> is there really a difference between piping to dd of=/dev/sdb and using > /dev/sdb ?
<ogra_ac> no idea, i never tested, but the instructions on the wiki were tested by many people
<bernard_> the wiki also says that if the > method doesn't work, to gunzip and dd instead.
<ogra_ac> we usually do quite some QA before releasing something ;)
<ogra_ac> hrm, wo added that
<bernard_> maybe there is something crazy about my sd card. i really can't see why they should differ.
<bernard_> as i said, i'll reproduce it tomorrow and find out where exactly the image went.
<bernard_> will anyone here be awake in 9 hours? ;)
<rsalveti> berco: sure
<rsalveti> ops
<rsalveti> bernard_: sure
<bernard_> cool. so i'm not in the craziest timezone!
<lilstevie> heh 9 hours == business hours
<berco> ogra: hi!
<berco> ogra: can you please enable natty on our PPA?
<ogra_ac> hey berco
<davidm> jayabharath, do you have any beyond repair Panda boards?  I need something to test size and spacing with.
<ogra_ac> berco, did you ask in #launchpad ?
<davidm> jayabharath, completely dead is perfect if you have any.
 * ogra_ac doesnt know why that wouldnt happen automatically
<jayabharath> Yes I think we have a couple sitting in our office... will 1 or 2 board do?
<berco> ogra_ac: I think I did last week but never got a real reply
<berco> ogra_ac: maybe everyone was at UDS/ELC...
<ogra_ac> or plumbers :)
<davidm> jayabharath, 2+ is a perfect amount of boards, 1 is better then nothing. :-)
<berco> ogra_ac: I thought it was you. Shall try again on #launcpad?
<davidm> jayabharath, 2+ allows me to test spacing for the 19" rack case
<ogra_ac> ask for a LOSA (launchpad admin)
<jayabharath> I have 1 in my office. I do know we burned one more board recently.. so we can give 2 boards to you. How can we get them to you
<davidm> jayabharath, I am more then happy to drive over to the TI offices to pick them up
<jayabharath> ok great.
<davidm> jayabharath, thanks, that will really help me with the layout of the 19" case and cable assemblies, just let me know when to come get them.  Thanks again.
<jayabharath> I will get my hands on the boards this morning and will email you. You can drop by anytime after 3.30pm today
<davidm> jayabharath, perfect, wow it's coming together nicely
<jayabharath> nice
<rsalveti> ogra_ac: told you that they never tested qt neon autodetection on a non neon capable machine
<rsalveti> it's now an upstream bug
<rsalveti> even affecting natty
<ogra_ac> yeah
<rsalveti> good that this also affects meego
<ogra_ac> do you think that will be solved soon with a suitable patch for maverick ?
<ogra_ac> else i'd prefer to do the static build again
<rsalveti> let's wait until tomorrow's eof
<rsalveti> *eod
<ogra_ac> like if it takes months it doesnt help much in maverick
<ogra_ac> k
<rsalveti> if not, at thursday we just push the disabled neon version for maverick
<ogra_ac> well, i'm fine even waiting another week or so
<rsalveti> the bug is critical, but then I saw that most qt bugs are critical hehe :-)
<ogra_ac> just not months
<rsalveti> ok then, let's wait at least this week then
<prpplague> davidm: ping
<davidm> prpplague, good morning
<prpplague> davidm: greetings earthling
<davidm> by the by the AC100 is 19 V
<prpplague> davidm: i haven't seen an email come across by inbox, just curious if you are still working on the project?
<prpplague> davidm: ahh interesting
<davidm> Yes you might want to have a look at: https://blueprints.launchpad.net/ubuntu/+spec/other-arm-n-public-panda-ppa-build-cluster
<hrw> davidm: let me guess: 19V 2.1A?
<davidm> Where I have the beginnings of the documentatation
<davidm> Nope 1.5x 30W
<davidm> Nope 1.5xA 30W that is
<davidm> Tiny
<davidm> The wiki page has some ASCI art on the relay schematic
<davidm> Very rough
<davidm> I'm coming by TI today to pickup 2 dead panda boards so I can do sizing and such
<davidm> I will then take some perfboard and make "daughter" cards to size
<davidm> and make up my "10" stack for sizing into the 19" rack case
<prpplague> davidm: ok, i'd like to show you something when you come by
<hrw> have a nice rest of day
<prpplague> hrw|gone: later
<davidm> prpplague, OK I'll mention that to jay when I come in.
<prpplague> davidm: i have something that might slightly impact your physical format
<prpplague> davidm: but would make things a little easier to work with
<davidm> I'm not sure how to bias the transistor so the relay will latch and not sure what pin to use to poke it for unlatching
<davidm> prpplague, cool
<ogra_ac> easier ++
<ogra_ac> :D
<devilhorns> ogra_ac, !!!! :P
 * prpplague is still tinkering with a netbook interface kit for the pandaboard
<davidm> prpplague, the transistor must allow latching with the panda board hard off (no power applied)
<prpplague> davidm: yea looking over your diagram now
<davidm> prpplague, please be gentile remember its ascii art ;-P
<prpplague> davidm: np, let me work through the logic and create a schematic over the next few days
<davidm> OK
<prpplague> davidm: here is the relay i suggest using - http://www.mouser.com/ProductDetail/NEC/UB2-3NU/?qs=c5n%252bvICFHOa2OX6vjaAytg%3d%3d
<prpplague> davidm: low noise, surface mount and is available in several different coil configurations
<davidm> prpplague, the URL shows coil voltage at 3V will 5V damage it?
<davidm> Or is that the min pullin voltage?
<prpplague> davidm: it is available in a wide range of coil voltage configurations, that just happens to be the 3V nominal part
<prpplague> davidm: http://www.mouser.com/Electromechanical/Relays-I-O-Modules/_/N-5g31?Keyword=UB2&FS=True
<davidm> Cool, then we are good with 5V, perfect
<davidm> YEs, I like that relay, nice
<rsalveti> ogra_ac: the problem is not only the kernel tree development, it's more the long term maintenance of it
<rsalveti> I know the linaro folks will integrate most ubuntu sauce and stable fixes
<rsalveti> so I believe we'll be ok for the release, but don't know then how the long term maintenance will work
<ogra_ac> as long as the config is fine
<ogra_ac> we might need a different config from what linato wants to use
<ogra_ac> (more drivers)
<rsalveti> that's ok
<rsalveti> we'll have some kind of linaro-ubuntu tree
<rsalveti> and we can use the config we want at the package level
<ogra_ac> right, so security and version alignment is our only issues
<rsalveti> ok, at least for omap 3 I believe we'll be fine
<ogra_ac> right
<rsalveti> I'll also help on what I can to make sure we have a good working kernel for it
<ogra_ac> i'm more concerned about possible upcoming platforms
<rsalveti> my concern is if we get the same kind of request for other hardware vendors
<rsalveti> yup
<rsalveti> :-)
<rsalveti> this shouldn't be a common solution
<rsalveti> omap 3 will be maintained this way because it's important for the community
<ogra_ac> even demoting omap3 to a community image if we cant get security would be fine by me
<rsalveti> yeah
<ogra_ac> but not for possible other arches
<ogra_ac> if we have commitment we need to support them
<rsalveti> sure
<prpplague> davidm: ok i follow the ascii art but it needs some cleanup and conversion into a proper schematic
<prpplague> davidm: i'll start work on that
<prpplague> davidm: have you prototyped the circuit yet?
<davidm> prpplague, nope, I've done the latching side many many times, but first time with a transistor to drop it
<davidm> The prior cases I used a mechanical switch to open the relay
<davidm> different use case
<prpplague> davidm: ok, i'll do a prototype setup along with the schematic
<davidm> By the by I'll be at TI about 3PM today
<prpplague> dandy
<davidm> I'll call Jay for an escort
<prpplague> :)
<davidm> Do you have a suggestion on what GPIO pin might be safest to use?
<prpplague> davidm: generally speaking they will be about the same, but i'd want to read over the x-load code for blaze/sdp/panda to see if there are any commonalities that might create problems
<prpplague> davidm: i'd probably suggest using GPMC_AD13 as an initial item, which is on the secondary expansion header
<prpplague> davidm: this leaves the other ones untouch incase you need to rev the board for other features
<davidm> prpplague, OK that works, thanks.  I figure you know the board better then I do.
<prpplague> davidm: i should be able to get some quick turn boards for the relay section one week from today
<davidm> I have some prototyping boards here I can breadboard if that helps
<davidm> That was what I was going to do anyway
<prpplague> davidm: naw, this will be quick turn boards with the correct footprints and everything
<prpplague> davidm: basically flush out any issues with the schematic and such
<davidm> Works
#ubuntu-arm 2010-11-10
<RobotGuy> I've configured and built a new custom kernel for Ubuntu, but am having difficulty getting it to boot. There is at least one error in the rebuild scrpt in the tools directory - it doesn't pass the correct kernel version (of the new kernel) to the commands. I'm unable to use a keyboard attacked to the Beagle-xM to get more info.
<RobotGuy> Kernel drops me to an (initfs) prompt, but I can't enter anything to get more info.
<RobotGuy> This is under Maverick 10.10
<hrw> hi
<egost> hi all
<egost> i have troubles getting PowerVR SGX driver to work on blaze (omap4 ES1.0).
<egost> can somebody confirm that?
<egost> PVR_K: (FAIL) SGXInit: Incompatible HW core rev (10100) and SW core rev (10200).
<egost> whole dmesg output : http://pastebin.com/raw.php?i=ZzhF7Lzy
<egost> var/log/Xorg.0.log : http://pastebin.com/raw.php?i=w58UUAkU
<bernard_> rsalveti: so, i couldn't reproduce the sd card corruption today, which is somewhat mysterious.
<bernard_> i swear it happened repeatedly on monday, but maybe i was on something good.
<bernard_> on an unrelated note, could this patch be incorporated into the ubuntu omap4 kernel?
<bernard_> http://marc.info/?l=linux-omap&m=128744421925804&w=2
<bernard_> it's upstreamed and in 2.6.37-rc1
 * hrw wants it
<ogra_ac> how would that affect systems where users set the MAC from u-boot already ?
<hrw> anyway my dhcp server forces same ip for device which asks as panda
<bernard_> in theory it shouldn't affect that at all.
<bernard_> it just allows you to override it after boot.
<bernard_> does the ubuntu omap4 kernel have a different patch for setting the mac address?
<ogra_ac> nope
<ogra_ac> file a bug and ask for SRU
<ogra_ac> should be possible to pull it into maverick
<bernard_> so it seems that the "linux" source package is collecting omap kernel bugs too. is that right?
<ogra_ac> for omap3, yes
<ogra_ac> and only in maverick
<bernard_> what about omap4?
<ogra_ac> for panda you want linux-ti-omap4
<bernard_> ah, cheers.
<bernard_> mind you, the beagle has the same ethernet chip.
<ogra_ac> which is fine given we have two different kernel trees
<ogra_ac> for natty omap3 will use upstream
<bernard_> so should i file a bug on the linux package too?
<ogra_ac> for maverick if you want to
<bernard_> ah k
<ogra_ac> natty will get it qutomatically
<bernard_> where does the SRU tag go? subject? or is there a magic setting?
<ogra_ac> https://wiki.ubuntu.com/StableReleaseUpdates
<bernard_> wow. i couldn't even get two consecutive bug numbers within a couple of minutes. that's a disturbing bug rate :/
<bernard_> but done. thanks!
<ogra_ac> well, we have many users ;)
<bernard_> many happy users too, i'm sure :)
<ogra_ac> hopefully :)
 * bernard_ loves having a native ARM build environment where apt-get just works.
<rsalveti> bernard_: what happen when you set the mac address at the cmdline?
<rsalveti> does it works as expected and never reset it again?
<bernard_> rsalveti: cmdline as in kernel cmdline?
<rsalveti> bernard_: yup, the current supported method
<rsalveti> the patch seems fine, but it's something that you can already work with if you set it up at the kernel cmdline
<bernard_> okay, to save me the 15 minutes to download the kernel source, what's the kernel parameter? :)
<rsalveti> 1 sec, changing git branch :-)
<rsalveti> macaddr=01:23:45:67:89:AB
<rsalveti> for example
<rsalveti> so, I agree it makes sense to apply your patch, but the reason would be more to avoid recreating the mac address on every ifdown/ifup
<rsalveti> because we already have a way to stick with only one mac address
<bernard_> cat /proc/cmdline
<bernard_> vram=16M,omapfb.vram=0:5M,1:5M mem=460M@0x80000000 mem=256M@0xA0000000 root=/dev/sda1 fixrtc console=ttyO2,115200n8 rootwait macaddr=00:80:c8:40:8a:de
<bernard_> but: % ip link list usb0
<bernard_> 2: usb0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1492 qdisc pfifo_fast state UNKNOWN qlen 1000 link/ether 7a:ea:e9:22:5a:4b brd ff:ff:ff:ff:ff:ff
<bernard_> uname -a: Linux cachehit 2.6.35-903-omap4 #14-Ubuntu SMP PREEMPT Wed Oct 6 17:23:24 UTC 2010 armv7l GNU/Linux
<rsalveti> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-maverick.git;a=commitdiff;h=10f38b455e75b85f72e98786e5518cf7b0324634;hp=f62e143182cc123fdfdf9bb88952a938af7d86e8
<bernard_> rsalveti: another reason for using that patch is that it's what's in upstream, and consistent with other drivers. it also shouldn't break people who set it with current methods.
<rsalveti> bernard_: sure
<bernard_> ahh. i think it needs smsc95xx.macaddr then
<rsalveti> sure, you're right
<rsalveti> ok, will build a new kernel with your patch, and will put this comment at the bug
<rsalveti> thanks for reporting it
<bernard_> np. thank you!
<bernard_> ack. the smsc95xx.macaddr= indeed works too.
<rsalveti> cool
<sebjan_> rsalveti, bernard_: just reconnecting to irc right now and see your chat:)
<sebjan_> I have already commented on the launchad bug
<rsalveti> sebjan_: after posting my comment I saw that you also commented on it :-)
<bernard_> snap!
<rsalveti> sebjan_: I'm now creating a new deb file to be tested
<bernard_> there is also bug 673509 for omap3
<ubot2> Launchpad bug 673509 in linux (Ubuntu) "Beagleboard-xm chooses a new IP address on each boot (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/673509
<rsalveti> true, this would affect both
<bernard_> (sorry to make you do more work! know that it's all greatly appreciated!)
<rsalveti> one more to the pipeline
<rsalveti> :-)
<rsalveti> np at all
<ogra_ac> NCommander, so i traced down the image build issues we have atm with cjwatson
<ogra_ac> NCommander, seems we have a dpkg bug
<ogra_ac> (telling you that because you wanted to work out why images fail)
 * rsalveti lunch
<rsalveti> ogra_ac: any chance to fix the current alsa-utils issue?
<ogra_ac> rsalveti, not yet, i discussed several solutions and have to pick one
<ogra_ac> generally we need a script that removes itself after first boot and calls the alsactl init
<ogra_ac> s/boot/reboot/
<ogra_ac> i'm just still pondering about the implementation details since all solutions are butt ugly
<rsalveti> ogra_ac: but we still need to explicit call alsactl init?
<ogra_ac> yes
<ogra_ac> once
<ogra_ac> and you need to call it after reboot
<ogra_ac> since the kernel we get at the same upgrade needs to be running first
<rsalveti> but the init is already calling when the  file /var/lib/alsa/asound.state is not there
<rsalveti> but I didn't check if this file is created even with the wrong configuration
<ogra_ac> that file is always there
<ogra_ac> just not on brandnew installs
<ogra_ac> it gets created on every shutdown
<ogra_ac> so the code you look at is for new installs
<ogra_ac> it doesnt help on upgrades
<rsalveti> ok, it worked for me because at the first boot I just installed the new kernel and the patched alsa-utils that avoid calling alsactl init
<rsalveti> then at the next boot everything was working fine
<hrw> race condition
<ogra_ac> no
<hrw> what about systems like mine when upgrade of kernel != reboot?
<ogra_ac> no race condition, expected behavior
<ogra_ac> hrw, then a script has to be in place taking care for that
<hrw> I sometimes do few kernel updates before reboot
<ogra_ac> thats what i was talking about above
<ogra_ac> thats fine
<ogra_ac> the script will check for the right kernel running on boot
<ogra_ac> if it sees the right one, it will call alsactl init
<ogra_ac> and renove itself
<ogra_ac> *move
<rsalveti> don't know if removing itself is the best choice
<rsalveti> maybe creating some kind of stamp somewhere
<hrw> so situation is: kernel has proper alsa setup, but users have wrong one so we need to grab kernel one before alsa will use inproper one?
<ogra_ac> rsalveti, that would mean you check for the stamp on every boot
<rsalveti> ogra_ac: sure, something like what is already happening at [ -f /var/lib/alsa/asound.state ] || alsactl init
<ogra_ac> rsalveti, right, we shouldnt add another one
<rsalveti> just because I don't like stuff being removed from my system without any package removal
<ogra_ac> better have a link somewhere that executes it and remove that link once it was run once
<ogra_ac> as i said, its just about implementation details atm, i discussed all that at UDS with the audio guys
<rsalveti> hrw: users need to update the kernel and then call alsactl init to initialize the correct config
<rsalveti> so to make the sound work you need to reboot anyway
<ogra_ac> right
<ogra_ac> the kernel has the name changes to the alsa devices we require
<ogra_ac> without the new names the alsa-utils changes cant work
<ogra_ac> thats the catch22
<hrw> no more "SDP4430 Media"?
<ogra_ac> rsalveti, persia's suggestion was a here document from postinst, so it wont be handled by any package at all, neither the putting in place nor the removal
<rsalveti> ogra_ac: sorry If I already asked this question, but why alsactl init is not called on every boot anymore?
<ogra_ac> because thats resetting the mixers
<hrw> rsalveti: what if you setup volume?
<ogra_ac> hrw, no, no more SDP4430 Media
<rsalveti> ok, the restore should be called, not init
<hrw> omap4 mixer is not small beast
<rsalveti> and restore also calls init when it fails
<ogra_ac> rsalveti, right, thats the core bug
<ogra_ac> restore should call init but it doesnt with our sound driver
<ogra_ac> that will be investigated for natty
<rsalveti> hm, ok
<ogra_ac> hrw, SDP4430 is used in more boards and all of them require different mixer setups so we added names pre board for the device
<ogra_ac> *per
<ogra_ac> that way tha alsa init scripts can adjust them on a per board base
<hrw> ogra_ac: I remember that discussions
<GrueMaster> *Hopefully* UCM will handle this in the future.
<rsalveti> hrw: http://paste.ubuntu.com/529441/ current result for panda
<ogra_ac> GrueMaster, it will, you really should have been at plumbers
<hrw> rsalveti: which ver of kernel?
<rsalveti> previously was just SDP4430 - SDP4430 for all boards
<GrueMaster> Yea, I figured as much.
 * hrw needs to revert to natty on panda
<rsalveti> hrw: 2.6.35-903-omap4 #17-Ubuntu
<ogra_ac> revert ?
<rsalveti> latest one available at maverick
<hrw> ogra_ac: yes. today was linaro 10.11 testing day which is maverick. yesterday it was running natty
<ogra_ac> ah
<hrw> I do not have maverick on devices
 * ogra_ac has only maverick on all systems here
<hrw> but will reinstall smartbook to maverick to check kde4/armel status
 * hrw reboots to #17 kernel
<hrw> got panda
<ogra_ac> now installinf alsa-utils should get you working sound
<hrw> I did 'alsactl init' by hand
<ogra_ac> that wont give you the right setup if you dont have the proper alsa-utils
<hrw> ok
<rsalveti> ogra_ac: who calls /sbin/alsa-utils start?
<ogra_ac> rsalveti, udev iirc
<rsalveti> hm, ok
<ogra_ac> yeah, through an additionl script
<ogra_ac> from /lib/udev/rules.d/80-alsa.rules
<rsalveti> yup, saw it here now
<ogra_ac> i have a skeleton for the postinst stuff, i'll finish that tomorrow during work hours
<rsalveti> so it calls when it add controlC
<ogra_ac> right
<rsalveti> ogra_ac: sure, np, I'm just trying to understand now why restore is not following init
<ogra_ac> i think its in alsactl itself
<ogra_ac> look at the source there
<rsalveti> yeah, doing that right now
<ogra_ac> but generally init shouldnt be needed at all
<ogra_ac> the driver should properly init and will hopefully do in natty
<rsalveti> sure
<ogra_ac> btw, what happened to the backtrace GrueMaster wanted to supply
<rsalveti> don't know
<ogra_ac> would be intresting to see the offending function
<rsalveti> but it's probably something that the compiler optimized for neon
<rsalveti> as neon is used for everything
<ogra_ac> yeah
<rsalveti> and not just neon capable files
<aju> hi all,how create cross toolchain for ARM from scratch on ubuntu 10
<hrw|gone> aju: "apt-get install arm-linux-gnueabi-gcc" is not enough?
<hrw|gone> ;d
<aju> hrw|gone, want to know complete process for creating toolchain on ubuntu 10
<hrw|gone> aju: apt-get source armel-cross-toolchain-base + build it + install results + apt-get source gcc-4.5-armel-cross + build it + install it + apt-get source gcc-4.4-armel-cross + build it + install it
 * hrw|gone out
<RobotGuy> How do I replace the kernel in Ubuntu? I've built a 2.6.36 kernel and I want to install it.
<RobotGuy> Ubuntu 10.10 built from an image.
<aju> dpkg -i
<aju> RobotGuy, using dpkg -i
<aju> \pkg name
<RobotGuy> I am talking building the kernel from sources, not installing from a binary.
<ogra_ac> https://wiki.ubuntu.com/KernelTeam/GitKernelBuild
<RobotGuy> I think you are not understanding my question..  I have configured and built a 2.6.36 kernel from sources.  I want to install the new kernel and boot it.  How do I do that?
<aju> RobotGuy, now you have .deb package of newly compiled binary?
<aju> i mean for kernel 2.6.36 ?
<RobotGuy> aju: NO I do not have a .deb package for the kernel.
<ogra_ac> RobotGuy, you should build a deb
<ogra_ac> if you know *ecxactly* wht your specific board needs for kernel and initrd treatment you can do that by hand indeed
<ogra_ac> but i would refer to the board documentation for that
<RobotGuy> As I said, I built a kernel from sources - 2.6.36   I want to install my new kernel and boot it.
<aju> RobotGuy, yes either you can create .deb using make-kpkg and then use chroot and install it in target board or using ssh
<RobotGuy> You are making this way over complicated.
<ogra_ac> RobotGuy, then look at your board docs what your board needs exactly
<ogra_ac> i.e. a u-boot booting board needs a uImage made from vmlinuz
<RobotGuy> I have already built a kernel for my hardware.  Now I want to install it and boot it.  What is so difficult here?
<ogra_ac> a redboot based board needs special treatment to dd the kernel into right place
<rsalveti> RobotGuy: the ubuntu way would be to have a package for it
<ogra_ac> that you didnt tell us anything about your hardware yet
<rsalveti> if you already built your own kernel you can just give make deb-pkg
<rsalveti> the upstream kernel also has a way to build a deb from the sources
<rsalveti> and it works quite well with ubuntu too
<RobotGuy> How is this going to help me install my new kernel?
<ogra_ac> what hardware do you have there ?
<RobotGuy> Hardware is a BeagleBoard-xM
<rsalveti> it's easier because if you're installing it on a running board, the initrd will be generated when installing it
<ogra_ac> so you need to run the right mkimage command
<ogra_ac> and create a uImage
<ogra_ac> then put it in the right place
<RobotGuy> I already have a uImage
<rsalveti> RobotGuy: if you just want to use a new uImage, just put it at the right place at the first partition
<rsalveti> and make sure your modules are located at /lib/modules
<ogra_ac> generate a corresponding uInitrd and put that in place as well
<RobotGuy> rsalveti: That does not work.
<ogra_ac> then your mkimage parameters were likely worng
<ogra_ac> where/how does it stop ?
<rsalveti> RobotGuy: it should work fine, if you put the modules in place and call depmod -a
<ogra_ac> a deb cares for all that
<RobotGuy> Is there a .deb package that matches a kernel 2.6.35.7-16, including config??
<rsalveti> RobotGuy: having the deb file is easier, you just need to install it
<rsalveti> and then making sure you're booting with the new uImage and uInitrd
<RobotGuy> rsalveti: You do not understand.  I need sources to match the running kernel for development purposes.
<ogra_ac> flash-kernel will care in this case
<rsalveti> RobotGuy: so just use the new uImage, copy the modules to /lib/modules, update the modules cache with depmod and generate a new initrd
<rsalveti> that should also work
<RobotGuy> rsalveti: I have already tried that and it does not work.
<aju> which emulator or IDE is available for ubuntu armel
<ogra_ac> qemu
<rsalveti> RobotGuy: it should work fine, probably something when wrong
<aju> i mean i like test my app
<ogra_ac> RobotGuy, well, if you dont give us any more info we cant help
<aju> ogra_ac, for qemu need to boot complete os ?
<ogra_ac> what does happen exactly or what doesnt ?
<aju> or just application ?
<ogra_ac> aju, both
<RobotGuy> What more info do you need?
<ogra_ac> you can install qemu-arm-static and run qemu-debootstrap --arch armel to cerate an arm chroot
<ogra_ac> or you can use qemu-system, grab a versatile kernel and run a full VM
<rsalveti> RobotGuy: did you give make modules_install INSTALL_MOD_PATH=/somewhere and then copied the modules to the correct directory?
<ogra_ac> <RobotGuy> rsalveti: That does not work.
<ogra_ac> <ogra_ac> then your mkimage parameters were likely worng
<ogra_ac> <ogra_ac> where/how does it stop ?
<RobotGuy> rsalveti: I know how to build kernels.  I've been doing it for years.
<rsalveti> RobotGuy: so please post the exact error you're getting
<RobotGuy> rsalveti: My problem does not have to do with building the kernel.  There is no error to post.
<rsalveti> RobotGuy: you say it didn't work for you, but didn't say what went wrong
<RobotGuy> First of all, I never said anything went wrong. Secondly, I came here asking how to do something, not how to correct an error.
<rsalveti> RobotGuy: well, I gave you two working methods, and you said you don't want to use deb and the other one simply doesn't work for you, for some unknown reason
<rsalveti> so I don't know how to help you more, unless you post us what went wrong with one of these options
<RobotGuy> rsalveti: I told everyone what I need to do at the start.  Nobody has told me how to accomplish what I want to do.
<rsalveti> RobotGuy: I told you 2 solutions, one is to build a deb and another is to produce a new uImage, install the modules by hand, generate the initrd and then reboot
<rsalveti> as you asked how to replace ubuntu's kernel with your own sources
<RobotGuy> I asked how to replace Ubuntu's kernel with my own kernel that I built from sources.
<RobotGuy> This should not be rocket science.
<rsalveti> and I gave you two working solutions for that
<GrueMaster> RobotGuy: Let's start over.  Are you using our pre-installed image?  Is that the kernel you wish to replace?  Do you want to replace it before or after first boot?
<RobotGuy> I started out from here ---> http://elinux.org/BeagleBoardUbuntu
 * GrueMaster looks.
<RobotGuy> I installed the Ubuntu image from there - 10.10
<GrueMaster> Ok, that lists several images, both Ubuntu supported and some that someone created from ubuntu repos and posted as tarballs.  It also lists different versions (Maverick, lucid).
<RobotGuy> I want to replace the kernel.
<RobotGuy> maverick
<GrueMaster> Please be more specific.  We have a pre-installed image that https://wiki.ubuntu.com/ARM/OMAPMaverickInstall points to, and there is a tarball on the link you posted as well.
<GrueMaster> Two entirely different beasts.
<GrueMaster> The "Demo Image" is not built or supported by Ubuntu other than at the package level.  The ubuntu-netbook-10.10-preinstalled-netbook-armel+omap.img.gz that can be downloaded from http://cdimage.ubuntu.com/ubuntu-netbook/ports/releases/  is supported.
<RobotGuy> All I want to do is have sources matched to the kernel my beagleboard is running.  I need this for development.
<GrueMaster> Either way, we need to know exactly which one because they are completely different and require different approaches to replace the kernel.
<RobotGuy> Which what??
<GrueMaster> Which image.
<RobotGuy> I already gave the info on where I got the image.
<RobotGuy> http://elinux.org/BeagleBoardUbuntu
<RobotGuy> Maverick 10.10
<GrueMaster> I am looking at that link.  There is Maverick 10.10 preinstalled (linked through https://wiki.ubuntu.com/ARM/OMAPMaverickInstall), and below it is the Demo Image based on Maverick 10.10.
<GrueMaster> So again, which image are you using?
<RobotGuy> Demo Image, Maverick 10.10
<GrueMaster> Ok.  Thank you.  Now we have a starting point.
<GrueMaster> Unfortunately, I have know knowledge of that image at this time, but I think rsalveti's point of building a kernel deb package and installing that is the best bet.
<RobotGuy> WHY do I want to build a kernel deb.  That is an unnecessary complication to what I need to do.
<GrueMaster> If you already have a vmlinuz & initrd.img, then you can alternatively use mkimage to make a uImage and uInitrd to boot from.
<aju> i have a basic question why uImage , u boot image x loader need to copy in Fat partition why not in ext ?
<RobotGuy> I already have a uImage.  I need to create the matching uInitrd.
<GrueMaster> If you scroll down the web link you posted, it has how to create a uInitrd from initrd.img.
<RobotGuy> My basic question remains though: How do I get the sources that match the kernel that is installed with the image I am using??
<GrueMaster> By installing the deb packages created when building the binaries.  Or copying the kernel source to /usr/src.
<RobotGuy> The whole reason I went to build my own kernel is that I could not get sources to match the kernel on the image.
<ogra_ac> RobotGuy, ask the person that created the image you used
<ogra_ac> you are obviously not using an ubuntu image
<RobotGuy> I'm using an image with ubuntu on it.
<ogra_ac> right
<ogra_ac> but not an image created by any ubuntu developer or in the ubuntu infrastructure
<GrueMaster> As I said, we can support it at the *package* level (i.e. if there is an ubuntu package in it that is having issues).
<ogra_ac> we can give you advise for ubuntu images
<ogra_ac> or for ubuntu packages
<RobotGuy> How do I know what images are or are not supported?
<GrueMaster> If the images come from *.ubuntu.com.
<ogra_ac> RobotGuy, GrueMaster just pointed you to some urls
<GrueMaster> (or authorized mirrors).
<GrueMaster> Our officially supported omap image for maverick is http://cdimage.ubuntu.com/ubuntu-netbook/ports/releases/maverick/release/ubuntu-netbook-10.10-preinstalled-netbook-armel+omap.img.gz
<RobotGuy> Will that work on a BeagleBoard?
<GrueMaster> Installation instructions are at https://wiki.ubuntu.com/ARM/OMAPMaverickInstall
<GrueMaster> Yes.
<GrueMaster> Tested on Beagle C4 & Beagle XM.
<RobotGuy> OK, thanks.  I guess I need to switch images then.  I have a C3 and an xM.
<GrueMaster> It should also work fine on the C3.  On the XM, be aware that there is a workaround for DVI on XM rev A3 or later.
<RobotGuy> My xM is an A2
<GrueMaster> Then it should just work.
<aju> ogra_ac, i have a basic question why uImage , u boot image x loader need to copy in Fat partition why not in ext ?
<GrueMaster> A3 moved the DVI enable line to a gpio after 10.10 release.  It has been fixed in a kernel update, but is tricky on first boot.
<GrueMaster> But as you have A2, no worries.
<RobotGuy> I'm glad. :D All this time I didn't know I was using an unsupported image of Ubuntu.
<ogra_ac> aju, thats a u-boot limitation we had with the omap u-boot
<GrueMaster> RobotGuy: No problem.  There are a lot of images and even full distributions based on Ubuntu (i.e. Mint) packages.  But we can only support the ones *we* create.
<ogra_ac> and indeed, instead of switching images you can just talk to the creator of the image you use
<ogra_ac> i.e. for a bug in mint you would talk to the mint devs
<aju> ogra_ac, can uboot read kernel from ext3 ?
<ogra_ac> ext2
<aju> ok ext2 ?
<ogra_ac> but not all revisions
<RobotGuy> I don't know who created it apparently. I know you guys didn't make it now.
<aju> because as convention it is required to copy uboot xloader and kernel in fat
<RobotGuy> I'll just switch images.  That seems to be the easist path. :)
<aju> will it work just copy uboot in fat and other in ext2?
<aju> something i want to test and run differently
<ogra_ac> you will have to rebuild u-boot with ext2 support
<ogra_ac> it rpovided to be unstable when we tested it
<RobotGuy> GrueMaster: I understand the whole support thing. ;D
<RobotGuy> I just created an sd card with that image but it says it doesn't have a valid partition table.
<RobotGuy> I forgot to gunzip it
<ogra_ac> you shouldnt gunzip
<ogra_ac> https://wiki.ubuntu.com/ARM/OMAPMaverickInstall has the proper instructions, use zcat
<RobotGuy> That ubuntu supported image just freezed my beagleboard up on kernel boot.
<GrueMaster> Do you see anything on the monitor?
<RobotGuy> Yeah.  It appears there is a wait, reboot, wait cycle for this image to boot.
<RobotGuy> Ahhh, x-image and I don't have keyboard/mouse connected yet.
<GrueMaster> The first boot resizes the rootfs to fill the SD card.  The second one should boot into X with oem-config running so that you can setup keyboard locale, timezone, and user login info.
<RobotGuy> It does.  My misunderstanding.
<RobotGuy> I don't need X for the project I am working on though.
<rsalveti> RobotGuy: you can boot with "text" at the cmd argument and you'll not get X
<RobotGuy> I would prefer to not have X on the SDcard at all.
<RobotGuy> I need dev stuff like gcc, etc.
<RobotGuy> dev libraries.
<RobotGuy> A console only dev image would be what I need/
<GrueMaster> RobotGuy: The other thing you could do is build your own image with rootstock.
<RobotGuy> I may have to do that.
<rsalveti> yep, unfortunately we don't have a minimal image for maverick
<rsalveti> rootstock is the way to go
<rsalveti> at least for natty we'll have it
<RobotGuy> That's too bad.
<RobotGuy> We lose the serial console.
<RobotGuy> At least if there were a minimal image, we could build up exactly what we need.
<GrueMaster> One other (untested) solution is to download the netboot image and use it to install from the pool.
<rcn-ee_at_work> RobotGuy, once you have my image it's easy to transition to ubuntu's kernel. ;)
<RobotGuy> rcn-ee_at_work: What image is that?
<rcn-ee_at_work> i was catching up on the irc log, 'my' image. ;)
<RobotGuy> Would that be the one I am using now?
<rcn-ee_at_work> Yeap it is.. from reading the backlog, you build a uImage and modules right? just dump the uImage in the fatfs and untar the modules to the rootfs.. the boot..
<rcn-ee_at_work> after you build, there's a script under /boot/uboot/tools to rebuild the uInird, then reboot with all new..
<RobotGuy> It can't find the linux partition
<RobotGuy> Yeah, I know the script.  It doesn't do the right thing - uses the wrong kernel version.
<rcn-ee_at_work> it uses the 'kernel' version from "uname -m or -r"
<rcn-ee_at_work> so you need to boot with uImage for it to work..
<RobotGuy> It always uses the version of the running kernel, which is wrong if I just created a new kernel.  It needs to use the version of the new kernel.
<RobotGuy> I know that
<rcn-ee_at_work> yeah, so copy the 'new' uImage to the boot, then reboot with the new uImage...
<RobotGuy> You are not listening to me.
<rcn-ee_at_work> as long as your modules are populate to /lib/modules/new_image/
<RobotGuy> I know how to deal with kernels, but what you are saying does not work.
<rcn-ee_at_work> Yeah i am.. So your running an old kernel.. You build a new one.. Take that new uImage and copy it to the fatfs dir.. then reboot your beagle, it'll run the new uImage..
<RobotGuy> It does not find the rootfs partition.
<RobotGuy> I don't know why.
<rcn-ee_at_work> sounds like a config problem... can you pastebin your .config
<rsalveti> ogra_ac: back to the alsa-utils issue
<rsalveti> alsa-utils is calling alsactl restore with -I
<rsalveti> -I,--no-init-fallback
<rsalveti> it calls with no init fallback, gets the error, tries to sanify it and then calls restore again
<RobotGuy> rcn-ee_at_work:   http://pastebin.com/87rjwxWm
<rcn-ee_at_work> Thanks RobotGuy
<RobotGuy> If it's the config, I don't know what the problem is.
<rcn-ee_at_work> most of the obvious things are right, but "CONFIG_GPIO_TWL4030=m" should be builtin, i belive it sets the power to mmc card...
<rcn-ee_at_work> diff'd mine and ubuntu's config we both got it as "=y"
<RobotGuy> OK.  Would that cause it to not boot and not find things?
<RobotGuy> Yes, I can see where that would make the mmc not available
<rcn-ee_at_work> Well alot of the GPIO's on the TWL4030 control essential things like power control for the ehci/musb/mmc so if they don't get power...
<RobotGuy> Would you fix and repost it for me please?  I just want it to work.
<RobotGuy> I hate dealing with kernel configuration
<rcn-ee_at_work> RobotGuy, i pushed it here: http://pastebin.com/uPS0w5dh  but if you have any more issues, my config for refernence is here: http://bazaar.launchpad.net/~beagleboard-kernel/%2Bjunk/2.6-stable/annotate/head:/patches/lucid-defconfig
<rsalveti> ogra_ac: just tested here, when booting with the old state file, at least for panda it'll be ok because the card name is different anyway
<RobotGuy> Thankyou
<rsalveti> and will store the correct values after first reboot
<rsalveti> the problem will be just blaze, as the card name is the same as before the kernel patches
<rsalveti> and restore with -F will try to restore most it can
<rsalveti> ogra_ac: for panda the state file will be the same if you call alsa-utils start (with the initial wrong description for sdp4430) or call alsactl init
<rsalveti> when giving restore the result is the same here, so don't know why you need to call alsactl init for panda at least one time
 * rsalveti out for now, be back later
<RobotGuy> rcn-ee_at_work: Now I get an internal compiler error. :(
<rcn-ee_at_work> RobotGuy, ouch.. just by changing that one little config?  what file did it ice on?
<rcn-ee_at_work> btw, which compiler? (the cross gcc from maverick's repo so far seems pretty sane..)
<RobotGuy> mm/dmapool.c:351: internal compiler error: in try_ready, at haifa-sched.c:3222
<RobotGuy> gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu5)
<RobotGuy> I am not cross building.
<rcn-ee_at_work> RobotGuy, weird, on my last build with that version, it didn't have any issues with mm/dmapool.c (2.6.35.7)... http://rcn-ee.homeip.net:81/dl/farm/log/COMPLETE-2.6.35.8-l7_1.0-maverick.txt
<RobotGuy> I'm building 2.6.36
<rcn-ee_at_work> i know.. file hasn't really changed; http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.36.y.git;a=history;f=mm/dmapool.c;h=3df063706f53e6d579ec0acabace3503a471ba29;hb=HEAD
<RobotGuy> All I want is the source to match the kernel I am running.
<rcn-ee_at_work> what kernel are you running?
<rcn-ee_at_work> (uname -a)
<RobotGuy> 2.6.35.7-l6
<RobotGuy> Linux tester 2.6.35.7-l6 #1 PREEMPT Wed Oct 20 01:32:27 UTC 2010 armv7l GNU/Linux
<rcn-ee_at_work> 2.6.35 + 2.6.35.7 from kernel.org + http://rcn-ee.net/deb/maverick/v2.6.35.7-l6/patch-2.6.35.7-l6.diff.gz + http://rcn-ee.net/deb/maverick/v2.6.35.7-l6/defconfig
<RobotGuy> OK, thanks. :)
<NCommander> ogra: what's the dpkg bug number?
#ubuntu-arm 2010-11-11
<bernard_> okay, more silly questions. given an installed kernel package, how do i create the uImage file for u-boot?
<bernard_> i'm used to creating them either from vmlinux manually, or running make uImage in the build tree.
<bernard_> but passing a vmlinuz image to mkimage doesn't yield a booting uimage
<bernard_> eeek, i take it back, sorry. never mind.
<rsalveti> bernard_: mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n "Linux" -d vmlinuz uImage
<rsalveti> or, if you're using a pre-installed image, just call flash-kernel
<bernard_> yep, ta. i was smoking something earlier (reusing the mkimage cmd i've been using to try to get a thumb2 kernel working ... exec addr was 0x80008001)
<rsalveti> oh, ok
<bernard_> okay, that was weird. when i booted with the smsc95xx.macaddr= param, the interface is called eth0. without it, the interface is called usb0.
<bernard_> ahh. apparently there are bits in the mac address that the usbnet stack uses to determine what to call it.
<rsalveti> yep
<rsalveti> okey, out for today, have a nice end of the day
<bernard_> cheers. you too!
<sveinse> Hi. I found a description on the web referring to build-arm-rootfs. That's the old name for rootstock, right?
<ogra_ac> sveinse, correct
<ogra_ac> NCommander, which bug number ?
<sveinse> Qt in maverick is built against X, right? (and not for non-X usage, aka Qt embedded)
<rsalveti> sveinse: yep, against x
 * rsalveti lunch
<berco> ogra: ping
<ogra_ac> berco, yes
<berco> ogra_ac: quick question: for our request to get PPA trunk and private-trunk... is that something I shall ask on #Launchpad ?
<ogra_ac> just create it (or let ndec do that) but dont upload to it unless a LOSA in #launchpad has made it private
<berco> ok
<ogra_ac> for the private ones it is essential that no upload happened before it was made private
<berco> ogra_ac: thanks. we created them.. going to #Launchpad now
<ogra_ac> great
 * rsalveti brb
#ubuntu-arm 2010-11-12
<DanaG> http://www.phoronix.com/scan.php?page=news_item&px=ODc3NA
<DanaG> Matches my opinion of ARM stuff.
<RobotGuy> I just built a fresh Ubuntu image using rootstock.  It boots up fine, but won't go to the internet. Network settings are as they should be except for the fact the iface shows as usb0 instead of usb1.
<RobotGuy> Does rootstock not install kernel modules into images??
<rsalveti> RobotGuy: not by default, you need to request it to install the kernel package you want
<RobotGuy> OK, how do I know what kernel packages are available.  I want the latest.
<rsalveti> RobotGuy: it depends on which machine are you using
<rsalveti> there's one kernel for omap 3 and another for omap 4, for example
<RobotGuy> BeagleBoard-xM
<RobotGuy> OMAP3
<rsalveti> then calling with --seed linux-image-omap should get you the latest omap 3 kernel
<RobotGuy> OK, thanks.  I'm rebuilding my image now.
<RobotGuy> Do I need something like kernel-sources to get the sources for the kernel image?
<RobotGuy> Or maybe linux-config-omap ??
<rsalveti> generally to build modules you just need the kernel headers
<rsalveti> but you can also get the sources from the deb package itself
<RobotGuy> I need the entire kernel sources in my case.
<RobotGuy> I need my kernel sources and config to match the kernel that is running.
<rsalveti> maybe linux-source-2.6.35 is what you need
<rsalveti> the config is already installed with the linux-image-omap
<rsalveti> you can find it at /boot
<RobotGuy> OK, good.
<RobotGuy> I think the kernel stuff should be mentioned on the rootstock part of the wiki.
<rsalveti> RobotGuy: sure, feel free to add it there
<RobotGuy> I'm planning to. :)
<RobotGuy> What do I have to do to gain write access to the wiki?  Where do I sign up?
<rsalveti> RobotGuy: if you already have an account at launchpad all you need to do is to sign up
<rsalveti> I believe it's on the left-up corner
<rsalveti> sorry, right-up
<RobotGuy> Seems easy to miss.  I found a create account link by clicking login.
<RobotGuy> I'm getting an Internal Server Error when I try to edit a page.  Do I need special access to edit?  I see the edit link.
<rsalveti> you should be able to edit it normally
<rsalveti> probably a bug at the wiki system, or server atm
<rsalveti> ubuntu
<rsalveti> argh, wrong terminal
<RobotGuy> Are there any know networking issues with a BeagleBoard-xM?? I can't ping out or access the internet in any way and yet all my networking settings are correct. It sees the network interface as usb0.
<RobotGuy> An unoffical "ubuntu" setup works fine on the network.
<DanaG> RobotGuy: there are two network interfaces on xM: usb-ethernet on board, and the host USB thingy (like with mobile phones).
<RobotGuy> Only usb0 is seen as a network device.
<RobotGuy> Which seems odd because another "ubuntu" setup seens usb0 and usb1 but only usb1 works for network.
<RobotGuy> I need the usb-ethernet.
<DanaG> WEird... I'd expect usb-ethernet to be eth0.
<RobotGuy> DanaG: That's not what it comes up as on the other setup. It comes up as usb1
<DanaG> WEird.
<DanaG> Granted, I haven't used xM first-hand.
<RobotGuy> Perhaps.
<DanaG> What's the actual driver behind the usb-ethernet?
<RobotGuy> The only module loaded is usbhid. :(
<RobotGuy> I don't know the actual driver that works for the ethernet on a Beagle-xM.
<DanaG> Weird.  Maybe compiled-in?
<RobotGuy> Well, it isn't working so I am guessing it isn't compiled in.
<ogra_ac> ndec, is there a call today ?
<cwillu_at_work> rcn-ee, hey, anything of interested re: micrel?
<rcn-ee> nope, haven't heard back...
<rcn-ee> how's the week testing of bfs gone? any odd things show up?
<cwillu_at_work> my desktop's still working great
<cwillu_at_work> haven't been able to do much with it on the beagle though, given the network trouble
<cwillu_at_work> (chrome is <3 though :p)
<rcn-ee> it is sweet...  it's after i ran it on the beagle for the first time i switched everything to it..
<cwillu_at_work> I also like how I don't need any extensions to get it running in kiosk mode :)
<cwillu_at_work> although:  css rounded borders kill the scrolling performance on arm, for some reason
<cwillu_at_work> rcn-ee, too bad about the lack of / searching
<cwillu_at_work> ctrl-f is such an annoying combination to type for searching
<rcn-ee> yeah it is.. then if the page isn't fully loaded you have to kill the search and redo..
<rcn-ee> just can't hit enter again..
<cwillu_at_work> rcn-ee, got a maybe-working serial link now, going to try to get more info from that zippy + ck2 lockup
<cwillu_at_work> sysrq-9 is maximum verbosity, or sysrq-1?
<cwillu_at_work> rcn-ee, nothing shows up when it locks up
<rcn-ee> that's a bummer...  did this not occur in a previous version? thinking of bisecting..
<cwillu_at_work> good question, let me check
<cwillu_at_work> (I've been using 2.6.35 for a while)
<cwillu_at_work> will take a minute, need to restore the old uImage before I can download anything :p
<cwillu_at_work> installing v2.6.36-dl3 now
<cwillu_at_work> installed, rebooting
<cwillu_at_work> rcn-ee, no crash on v2.6.36-dl3
<cwillu_at_work> oops, spoke too soon
<cwillu_at_work> rcn-ee, crash on v2.6.36-dl3 :p
 * cwillu_at_work pokes rcn-ee_at_work?
<rcn-ee_at_work> cwillu, any luck with 2.6.36, just drove to work so don't have the backlog.. ;)
<cwillu_at_work> :p
<cwillu_at_work> no.  It still locks up
<cwillu_at_work> I'm testing without network-manager in the loop though
<cwillu_at_work> and bam :p
<cwillu_at_work> it's not network-manager :p
<rcn-ee_at_work> sweet, i was going to skip 2.6.36, to buggy.. ;)
<cwillu_at_work> nothing in the logs either
<cwillu_at_work> I can has a 2.6.35-ck2? :p
<cwillu_at_work> no idea if it applies :p
<rcn-ee_at_work> i tried 2.6.35-ck2 yesterday, it's fails to build some of the crc modules...
<rcn-ee_at_work> any chance does 2.6.37-rc1 work any better.. (the dss2 stuff is iffy in that release) but there's lots of omap changes..
<cwillu_at_work> I'll try it
<rcn-ee_at_work> cool
<cwillu_at_work> also, there's a ck patchset for 2.6.35
<rcn-ee_at_work> i had tried: 2.6.35-ck1
<cwillu_at_work> and it didn't build?
<rcn-ee_at_work> nope, it's failing with some of the crc modules.. (doesn't care if it's builtin or external)
<cwillu_at_work> define failing? :)
<rcn-ee_at_work> (fired off a rebuild.. didn't save error message.. ;) )
 * cwillu_at_work suspects foul play
<cwillu_at_work> downloading 2.6.37-rc1-dl0
<apw> ogra_ac, have we worked out if the omap3 kernels from linaro are good enough as a drop in replacement for our CDs ?
<ogra_ac> apw, no, we havent yet
<ogra_ac> apw, see my mail that i sent to ubuntu-devel
<ogra_ac> apw, they have to be moved to main in any case and we have neither commitment from the kernel team nor from the security team for the maintenance period
<apw> ogra_ac, well my take from that thread was that they weren't that interested in doing supported versions, so it is down to distro to handle support if we go that route
<ogra_ac> i cant move them to main if nobody commits to take over the 18months of security and SRUs
<ogra_ac> apw, right, but nobody in distro spoke up yet
<apw> ogra_ac, yeah its hard for us to commit until the resources settle down
<ogra_ac> apw, right, so i think for A1 we will have to go with omap4 only for now
<ogra_ac> until i can get commitment
<ogra_ac> and hope the things have settled before A2
<apw> ogra_ac, ok that sounds sane i guess
<ogra_ac> if there are new arches (which i'm more concerned about than omap3) we will likely have to revisit that anyway
<ogra_ac> and i dont expect them to show up before A1
<apw> ogra_ac, yeah thats all noise till we have the go to do them, so i am ignoreing them
<ogra_ac> i try to but its hard ;)
<cwillu_at_work> rcn-ee_at_work, booted with network attached, which failed every time on the 2.6.36
<cwillu_at_work> rcn-ee_at_work, heh, on the other hand, picocom is complaining that /dev/ttyS2 isn't a tty :p
<cwillu_at_work> oh, nope
<rcn-ee_at_work> yeap, it's /dev/ttyO2
<cwillu_at_work> just locked up
<cwillu_at_work> rcn-ee_at_work, I still have entries for ttyS2, is that expected?
<cwillu_at_work> and why the hell did that change in the first place? :p
<rcn-ee_at_work> it's using the 'omap' serial driver now over the generic serial... dma/etc improvements..
<rcn-ee_at_work> new in 2.6.37-rc1, so it'll screw every user up.. ;)
<cwillu_at_work> and it had to change the name?
<cwillu_at_work> ... that's gratuitous and borderline abusive
<rcn-ee_at_work> Yeah... compatibility nightmare..  but S is for the serial, and O is for omap serial.. ;)
<cwillu_at_work> I hate you.
<cwillu_at_work> but anyways, 2.6.37 hangs too :p
<rcn-ee_at_work> dang it..
<rcn-ee_at_work> did anything in the old 2.6.34 work?
<cwillu_at_work> let me try again without the network plugged in just to make sure it's the same'ish problem
<cwillu_at_work> rcn-ee_at_work, believe so, used it for a while
<cwillu_at_work> 2.6.34 had that memory leak though
<rcn-ee_at_work> yeah it did.. but if the other thing works, we will have something bisect with. ;)
<cwillu_at_work> can't we bisect 2.6.35 -> 2.6.36?
<rcn-ee_at_work> i thought 2.6.35 failed too.. it worked?
<cwillu_at_work> 2.6.35 is fine, unless I do stupid mii-tool tricks
<cwillu_at_work> I've got 10 days uptime under 2.6.35.7-l6
<cwillu_at_work> twice in a row too :p
<rcn-ee_at_work> ah so a new bug with 2.6.36...
<cwillu_at_work> yes
<rcn-ee_at_work> and that's the one you can't get a backlog with right?
<cwillu_at_work> when it hangs under 2.6.36 or .37, nothing comes over the serial link when it dies
<cwillu_at_work> it just hardlocks
<cwillu_at_work> now, the serial link is coming via rsyslog, so it's possible that a more direct approach would get something, but...
<cwillu_at_work> 2.6.37 seems to have the same hang
<rcn-ee_at_work> fires up his test rig.. it'll take a little bit.
<cwillu_at_work> also, just a reminder in case it's relevant, the ks8851 driver does give some irq warnings
<cwillu_at_work> under all kernel versions
<cwillu_at_work> under 2.6.37, when I attach the network cable (but before I run dhclient or network manager to configure it), I get "NOHZ: local_softirq_pending 08"
<cwillu_at_work> hmm, there's an bug message in 2.6.37's bootup re: ioremap call on system memory
<rcn-ee_at_work> yeah the nohz has been around since like 2.6.32..
<cwillu_at_work> that's in a call from omapfb though, so I don't think it's related
<rcn-ee_at_work> the ioremap has patches for queued for rc2
<rcn-ee_at_work> another one of the reasons i'm planing to skip 2.6.36..
<cwillu_at_work> rcn-ee_at_work, I also get Spurious irq 95: 0xffffffdf, please flush posted write for irq 56
<cwillu_at_work> this happens when the network interface is finally configured
<cwillu_at_work> hmm
<cwillu_at_work> I don't get that in 2.6.36/37 though
<cwillu_at_work> it seems to crash when it would be showing up
 * cwillu_at_work doublechecks
<cwillu_at_work> rcn-ee_at_work, yep, I never see those on kernels that crash
<ndec> ogra_ac: yes, there is a call. i am connected.
<cwillu_at_work> I get the spurious irq's on .35 moments after I start using the network
<ogra_ac> ndec, i'm a few mins late
<rsalveti> ogra_ac: pool/main/a/alsa-utils/alsa-utils_1.0.23-2ubuntu3.4_armel.deb
<ogra_ac> gar
<cwillu_at_work> rcn-ee_at_work, still around?
<rcn-ee_at_work> yeap
<cwillu_at_work> got a stack trace \o/
<cwillu_at_work> however, most of it scrolled off the top of the screen :p
<rcn-ee_at_work> sweet
<cwillu_at_work> omap2_mcspi_work shows up 5th line from the bottom
<cwillu_at_work> let me muck a bit more and see if I can get it to do the same to the serial port
<cwillu_at_work> ooo, hope
<cwillu_at_work> rcn-ee_at_work, got it
<cwillu_at_work> sec while I paste it
<cwillu_at_work> rcn-ee_at_work, http://pastebin.com/tMZ5Lrfh
<cwillu_at_work> that looks familiar :p
<cwillu_at_work> rcn-ee_at_work, for reference, the errors I got with stupid mii-tool tricks:  http://pastebin.com/raw.php?i=vdrrr8iL
<cwillu_at_work> the trace is as identical as can be expected with two different kernel versions
<cwillu_at_work> kthread -> work_threader [-> process_one_work] -> omap2_mcspi_work -> complete [-> __raw_spin_lock_irqsave]
<cwillu_at_work> er, worker_thread
<cwillu_at_work> rcn-ee_at_work, any chance you could spin me a preempt_voluntary kernel?
<rcn-ee_at_work> from stable?
<rcn-ee_at_work> 2.6.35.8?
<cwillu_at_work> no, 2.6.36 or later
<cwillu_at_work> with or without ck2, doesn't matter
<rcn-ee_at_work> sure..
<rcn-ee_at_work> although, my work network is slower then molasses right now so it might take a bit to upload.. ;)
<cwillu_at_work> np, heading out for lunch right away anyway
<cwillu_at_work> (back)
<cipher> how can I build a rootfs for armv7a (beagleboard) without qemu
<cipher> I've been playing with rich nelson's omap-image-builder but run into trouble when trying to do the second-stage stuff
<cwillu_at_work> rcn-ee, your mistake was letting me see you both leave for work and arrive at work this morning :)
<cipher> what happens is the kernel panics when the qemu-system-arm tries to run the lucid kernel
<cipher> not sure if my qemu version is bad but I can provide it if needed
<cwillu_at_work> sorry, you're running it in qemu, or no?
<cipher> I'm using rootstock to try and build a rootfs
<cipher> rootstock uses qemu at some point for secondstage of debootstrap, this is my understanding
<cipher> I'm more than happy to perform the second-stage stuff on the real hardware if that's possible, but I don't know enough about what it's doing
<cwillu_at_work> use the static thingies
<cwillu_at_work> sec
<cwillu_at_work> (there's a comment to that effect in the script
<cipher> I noticed it was looking for qemu-arm-static, but I don't have that
<cipher> not sure what that is either
<cipher> my first guess was that it was a statically compiled arm-softmmu
<cwillu_at_work> it basically allows you to run arm binaries outside of qemu
<cwillu_at_work> er
<cwillu_at_work> that, plus bin-fmt-utils or whichever
<cipher> why does this stuff need to happen with qemu anyway, can't it be done on the live hardware?
<cwillu_at_work> cipher, the real hardware doesn't have much memory, has small slow disks, and a slow single-core processor
<cwillu_at_work> I can do the whole rootstock process in 13 minutes on my server
<cipher> I understand, but without knowing what the secondstage is I can't make that determination. looking through the debootstrap stuff it seemed it was unpacking some packages or some thing
<cwillu_at_work> cipher, it's a debian install
<cwillu_at_work> dpkg
<cipher> I trust that it's done for a reason, just wondered what it is, thanks
<cwillu_at_work> binfmt-support
<cwillu_at_work> that's what I was looking for
<cipher> any reference for what I should do
<cwillu_at_work> install those two
<cwillu_at_work> try it again
<cipher> and what about qemu-arm-static?
<cwillu_at_work> that would be the first
<cipher> that's a package?
<cwillu_at_work> yep
<cwillu_at_work> if you don't see it, check for qemu-kvm-extras-static
<cwillu_at_work> This package provides a static version of the QEMU ARM user mode
<cwillu_at_work> emulation.  This is particularly useful in combination with
<cwillu_at_work> binfmt-support: it permits running ARM binaries in an ARM chroot.
<cipher> so my host system isn't actually ubuntu, I did build my own qemu with --static option.
<cipher> I'm on debian lenny
<cwillu_at_work> qemu-kvm-extras-static comes from debian afaik
<cipher> hrm, sid I guess
<cipher> wonder if I can just use my own qemu static that I compiled --static?
<cipher> ah, from the way it sounds probably  not
<cipher> so I installed the qemu-user-static package (which has qemu-arm-static) and tried again. I got a number of errors related to chown failing
<cipher> /bin/chown: changing ownership of `/proc/sys/net/ipv4/conf/br0': Operation not permitted for example
<cipher> I did run with sudo
#ubuntu-arm 2010-11-13
<RobotGuy> Is there a way to get gcc 4.3 instead of 4.4 or 4.5?
<RobotGuy> Is there a way I can tell rootstock to use gcc 4.3 instead of the later compilers?
<rcn-ee> RobotGuy, are building stuff in roostock? otherwise select the 'gcc-4.3' package..
<RobotGuy> Yes, rootstock.  I tried selecting gcc-4.3 but it doesn't seem to work.
<rcn-ee> what do you mean it doesn't work?
<RobotGuy> It still takes gcc 4.5
<RobotGuy> Or maybe it is 4.4, but not 4.3
<rcn-ee> when you call "gcc" in your image? gcc-default does that, either call "gcc-4.3" in your build script or change the setting in ubuntu..
<RobotGuy> I already told you I did that - selected "gcc-4.3" and it doesn't get me gcc 4.3
<rcn-ee> which distro?
<RobotGuy> Ubuntu built with rootstock.
<rcn-ee> RobotGuy, lucid/maverick?
<RobotGuy> 10.10 Maverick
<rcn-ee> it exists.. http://packages.ubuntu.com/maverick/gcc-4.3 package name "gcc-4.3" to your seed or "sudo apt-get install gcc-4.3" will instal it later..
<rcn-ee> but you 'unverise' enabled in rootstock..
<RobotGuy> I haven't done anything to rootstock - it is as it was installed.
<rcn-ee> RobotGuy, so you added "gcc-4.3" to the seed and you say it doesn't work..  what doesn't work about it in your mind?
<RobotGuy> I still see it pulling "gcc-4.5-base"
<cwillu_at_work> RobotGuy, adding a package won't generally remove a package
<cwillu_at_work> I believe there's an option to remove a package from the seed though
<cwillu_at_work> (not sure, my rootstock is thoroughly hacked up, and I promised to write up my changes and upstream them some day :p)
<RobotGuy> This is not intuitive at all.
<rcn-ee> it's not really suppost to be.. just a quick way to make a base image... add the extra's later...
<cwillu_at_work> RobotGuy, adding a package shouldn't remove packages.
<RobotGuy> I want to replace a package.
<cwillu_at_work> RobotGuy, if you want to replace a desk, how do you go about doing that?
<RobotGuy> There is also apparently a problem with Ubuntu recognizing the ethernet on the Beagle-xM.
<ScottK> RobotGuy: Having GCC 4.5 installed doesn't preclude you from building with 4.3 if it's also installed.  4.5 is part of the build-essential metapackage for 10.10 so it's assume to be there for building.
<cwillu_at_work> unrelated :p
<RobotGuy> cwillu_at_work: I'm not a first grader
<rcn-ee> RobotGuy, pulling in 'gcc-4.5-base' happens.. you want "gcc-4.3" that depends on "libc6" which depends on "libgcc1" which depends on "gcc-4.5-base" ... ;)
<rcn-ee> just a big circle..
<cwillu_at_work> RobotGuy, I didn't say that you were, and supplying an analogous example was recognition of intelligence
<cwillu_at_work> there's that bit, too :)
<RobotGuy> gcc 4.4 and 4.5 just seem to be big problems.
<cwillu_at_work> what problems are you seeing?
<RobotGuy> Internal compiler errors
<cwillu_at_work> I suspect you're doing something wrong somewhere;  what's your build setup like?
<RobotGuy> I'm just trying to build a kernel.
<cwillu_at_work> how?
<cwillu_at_work> native builds?  cross compiling?  qemu?
<RobotGuy> On beagleboard
<cwillu_at_work> c4?
<RobotGuy> No, Beagle-xM A2
<cwillu_at_work> okay;  xm is a different beast from the other beagles
<cwillu_at_work> and one which I don't own  :(
 * cwillu_at_work accepts donations :p
<cwillu_at_work> which distro and version?
<cwillu_at_work> any oddities on how things were installed?
<cwillu_at_work> hell, is the xm even stable in general?  :)
<RobotGuy> Ubuntu 10.10 built from rootstock.
<rcn-ee> the most important thing is 'what' kernel and 'what' clockspeed only angstrom's can handle the full 1Ghz, mine limited to 800mhz otherwise it's unstable..
<cwillu_at_work> not even rcn-ee is perfect :)
<rcn-ee> specially with zippy's... i think it esd'd it today, everything but the ks8851 works on it..
<RobotGuy> It's a 2.6.35 kernel.
<rcn-ee> ubuntu's?
<cwillu_at_work> RobotGuy, the included patches matter
<RobotGuy> Yes
<RobotGuy> I don't have any idea what patches - it comes with linux-image-omap
<rcn-ee> it should work, never tested itmy self.. can you "dmesg | grep mpurate|core"
<RobotGuy> rcn-ee: I haven't changed the clock rate
<rcn-ee> then it should be the default 500ish.. no idea why your board is iceing in gcc, it shouldn't..
<RobotGuy> 500? Mine says 800
<rcn-ee> oh great...
<rcn-ee> your running an image with my install script with ubuntu's kernel and pushing 800... no idea if that's stable, nor have tested it..
<RobotGuy> I didn't change anything.
<rcn-ee> can you pastebin the boot.scr in the fatfs?
<RobotGuy> You're telling me that to use Ubuntu, I have to run at half the speed of my board?
<cwillu_at_work> rcn-ee, your kernel brings up the network on that, no?
<RobotGuy> I've never been  able to get networking to work.
<cwillu_at_work> RobotGuy, you're not using rcn's kernel
<rcn-ee> it should, it does on all my xM boards..
<cwillu_at_work> RobotGuy, rerun rootstock with one of his kernel's (which iirc is how rootstock is intended to be used anyway)
<rcn-ee> RobotGuy, the ubuntu guys didn't get a working xM board till a week before freeze... my timelines are much more relaxed.. 'aka oh crap, lets upload a fix now'
<RobotGuy> You're not listening to me.
<cwillu_at_work> RobotGuy, no, you're not listening to us.
<RobotGuy> I have not changed anything in rootstock.
<cwillu_at_work> you're doing things wrong, and expecting it not to matter.
<RobotGuy> How am I doing things wrong?
<RobotGuy> What am I doing wrong?
<cwillu_at_work> <rcn-ee> then it should be the default 500ish.. no idea why your board is iceing in gcc, it shouldn't..
<cwillu_at_work> because
<cwillu_at_work> <rcn-ee> RobotGuy, the ubuntu guys didn't get a working xM board till a week before freeze
<cwillu_at_work> therefore
<cwillu_at_work> <rcn-ee> the most important thing is 'what' kernel and 'what' clockspeed only angstrom's can handle the full 1Ghz, mine limited to 800mhz otherwise it's unstable..
<RobotGuy> We seem to be going round in circles and I am getting quite dizzy.
<cwillu_at_work> :)
<cwillu_at_work> RobotGuy, if you want to use rootstock, and you want to run at 800mhz, then you need to supply rcn's kernel.  You can probably do this without remaking the image, although it's a bit finicky
<cwillu_at_work> If you use rcn's kernel, the network will also Just Work.
<RobotGuy> I keep telling you people that I did not change the clockrate.
<cwillu_at_work> (incidently, I can has preempt_voluntary kernel now rcn-ee?)   :)
<cwillu_at_work> RobotGuy, and we keep telling you that the ubuntu kernel isn't stable at the default clockrate
<cwillu_at_work> there are required patches which weren't available when ubuntu's kernel was frozen for release
<cwillu_at_work> only angstrom's kernel has all the patches (because that's where they get developed for the most part)
<cwillu_at_work> eventually everybody will have them, but the hardware only came out a couple months ago.
<rcn-ee> RobotGuy, if it's running 800Mhz, more then likely you used my "setup_sdcard.sh" script.. a "cat boot.scr | pastebinit" would prove it..
<RobotGuy> Obviously, trying to use Ubuntu was not a good idea for me.  Bummer.  I thought it would be better.
<rcn-ee> it's that boot.scr script that changes it to 800
<cwillu_at_work> RobotGuy, don't be that way.  Every mainline distro will be weird at this point.
<cwillu_at_work> er, major
<cwillu_at_work> You need to substitute one piece, and everything will work fine.
<RobotGuy> What piece?
<cwillu_at_work> rcn-ee, 2.6.36-dl13?
<cwillu_at_work> http://rcn-ee.net/deb/maverick/v2.6.36-dl3/
<cwillu_at_work> RobotGuy, as it stands, you're mixing and matching pieces which assume you're doing it this way anyway
<cwillu_at_work> it's an honest mistake, especially common with new hardware
<cwillu_at_work> but it's not our fault any more than it's your fault.
<RobotGuy> This is not making sense to me. :(
<cwillu_at_work> RobotGuy, can you run the command rcn-ee gave you please?
<RobotGuy> I need to be able to use the full speed of my Beagle-xM. If Ubuntu can't do that, then I can't use Ubuntu right now.
<cwillu_at_work> pastebinit boot.scr
<rcn-ee> RobotGuy, 'full' speed is only one option right now and it's angstrom, and it's on TI's 2.6.32 kernel.. The rest of us will have that hopefully in 2.6.37...
<cwillu_at_work> RobotGuy, so you run a different kernel, which is already packaged at the address I gave you above.
<RobotGuy> Which is it? Ubuntu can or can not run at full speed on a Beagle-xM?
<cwillu_at_work> none of this has anything to do with networking, nor gcc-4.4/4.5
<cwillu_at_work> RobotGuy, ubuntu with rcn's kernel will run at 800mhz right now, and will run at 1ghz in january
<RobotGuy> OK, that answers my question.  I'll try Ubuntu again in January or Feb then.
<RobotGuy> We can't hold up development that long.
<cwillu_at_work> how does this hold up development?
<rcn-ee> i was thinking next week.. ;) but git rebase of dvfs-pm was a huge mess. ;)
<cwillu_at_work> rcn-ee, I was being conservative :p
<RobotGuy> I told you - we need the full speed of the Beagle-xM now.
<cwillu_at_work> how could you possibly know that?
<rcn-ee> yeah stable for everyone else..  january.. ;)
<rcn-ee> cwillu_at_work, does btrfs seem to bog down for you in git tree's?
<RobotGuy> The nature of our project requires top speed.
<cwillu_at_work> rcn-ee, heh, complicated question :p
<cwillu_at_work> RobotGuy, this is probably a good time to mention that ti's hardware isn't intended for prototyping of actual products, or actual deployment
<cwillu_at_work> er, the beagle's
<rcn-ee> git checkout's seem to bog when going from Head to a older branch... i think i really need to enable the new 2.6.37 mount opiton..
<rcn-ee> RobotGuy, optomize more.. ;)
<RobotGuy> I am well aware of that.  We are developing, not producing.
<cwillu_at_work> RobotGuy, if you're developing, then the product speed doesn't matter.  multiply your benchmarks by 20% :p
<RobotGuy> Speed does matter, but I am not here to argue.
<cwillu_at_work> rcn-ee, you mean the git commands themselves?
<rcn-ee> yeah, like a git fetch; git checkout HEAD; git checkout an old branch..
<cwillu_at_work> I haven't noticed anything, but
<cwillu_at_work> might try running a defrag
<cwillu_at_work> which mount options are you using currently?  (or have used in the past, some are sticky)
<cwillu_at_work> (note that defrag operates on specific folders and files;  it's not enough to specify the root)
<rcn-ee> could be, i build a lot of kernels on this machine.. or one of the two enabled but not 'advertised' cores is failing on this fake x4..
<rcn-ee> just 'btrfs defaults' in /etc/fstab...
<cwillu_at_work> nochecksum,nocow might help matters, at least for things like builds and so forth
<cwillu_at_work> you'd have to do a separate btrfs filesystem though, as those currently can't be set separately on subvolumes
<rcn-ee> okay, i'll try that..
<cwillu_at_work> bah, he left
<cwillu_at_work> I was going to mention that pandaboard might be more useful
<rcn-ee> he's been stuck on that issue since like tuesday night...
<cwillu_at_work> yeah, I'm pretty sure he's been told 3 different build approaches that would give him the end result he wants
<cwillu_at_work> and he's consistently refused to follow any one of them :p
<rcn-ee> yeap, it's a receipe for disaster..
<cwillu_at_work> I feel like I was getting overly crotchety, but...
<cwillu_at_work> anyways
<cwillu_at_work> rcn-ee, so, I see you're at home now  :)
<rcn-ee> yeah... 8ish to 5ish.. ;)
<cwillu_at_work> do you know what that means?  :)
<rcn-ee> i can never be found...
<cwillu_at_work> hint:  it involves a kernel :)
<rcn-ee> cwillu_at_work, here they are: http://rcn-ee.homeip.net:81/testing/2.6.36-something/  (forgot what i enabled, but it was that one thing)
<cwillu_at_work> \o/
<cwillu_at_work> thanks
<cwillu_at_work> preempt_voluntary I believe
<rcn-ee> yeah that.. i knew it was 'something'
<cwillu_at_work> rcn-ee, without ck?
<rcn-ee> yeah, without ck...
<enth> Does ubuntu ARM work on StrongARM / PXA27xx processors?
<rcn-ee> enth, not really, that stuff is too old... debian or angstrom is really your only options...
<enth> \: Ok thanks.
<cwillu_at_work> download complete
<rcn-ee> yay i get my bandwidth back. ;)
<cwillu_at_work> I was going to apologize for your untimely responses :)
<rcn-ee> i'm just drinking a beer, waiting for stuff to build.. ;)
<cwillu_at_work> while you wait:  http://www.fanfiction.net/s/4068153/1/
<cwillu_at_work> :p
<cwillu_at_work> booting
<cwillu_at_work> (with the network plugged in, no less!)
<cwillu_at_work> that was quick
<rcn-ee> quick hard lock?
<cwillu_at_work> yep
<cwillu_at_work> and again
<cwillu_at_work> okay, it's not my full preempt sillyness triggering this then
<cwillu_at_work> rcn-ee, incidently, you mentioned that ks8851 was troublesome at 1ghz;  it isn't troublesome in the same way is it?
<rcn-ee> no, it's the omap part, needs a voltage bump to the next level thru smartreflex
<cwillu_at_work> okay
<cwillu_at_work> tempted to get one just to reproduce this :p
<sveinse> I understand that a lot of you is running Ubuntu off a (micro) SD card, right?
<sveinse> Yesterday I purchased a new Class 4 Kingston 8GB micro SD. However, this card is something of the slowest I've ever seen running Ubuntu on
<sveinse> My old 2GB Trancend (which was bundled with a HTC phone) is *much* faster
<sveinse> Have any of you experienced differences and difficulties in respect of memory cards?
<sveinse> I.e. how can I find one with is fast?..
<ogra_ac> take class 10
<sveinse> But the class is related to read/write speeds.
<sveinse> I did a bonnie++ comparison between the two cards. Suprisingly the read/write rates were comparible
<sveinse> However the latency on IO were 4-5 times higher on the newest card.  Example. latency on random create read were 3174 us on the new, while 184 us on the old
<sveinse> So obviously there is some other parameter here which is not covered by the class concept
<ogra_ac> well, i get nearly USB results with class 10 cards here
<sveinse> Yeah, I'll see if I can get my hands on one. Which brand?
<ogra_ac> i had good results with panasonic gold cards
<sveinse> Panasonic. Interesting
<sveinse> I not surprised though. I've had previous experiences that the off-the-radio-shack-shelf cards can be cheap (i.e. poor quality)
<Neko__> hey guys, anyone have any official view or a wiki or something on how to version packages based on git repos?
<Neko__> mainly for kernel packages
<Neko__> git commit ids aren't debian standards compliant so I can't make the debian --revision thing the tag
<ScottK> Neko: Debian package versioning has to be monotonically increasing so using git ids is out.  I usually use the date, i.e. 2010113, instead.
<Neko> but some packages have stuff like +gitblahblah or ~gitsomething or ~something at least
<Neko> I never found anything which tells me what these really mean or what is recommended
<Neko> now I check I can't even find a package with that versioning but I know there are some :D
<ScottK> I'm familiar with it.
<ScottK> In Debian versionin "~" is somewhat magical in that it's less than anything else.
<ScottK> So 1.0~git20101113 is less than 1.0.  You'd use this to indicate some pre-1.0 snapshot.
<ScottK> If you're packaging something that's a bit beyond 1.0, you'd use 1.0+git20101113 since that's higher than 1.0.
<ScottK> Neko: Does that clarify it?
<Neko> oh-ho! I see :)
#ubuntu-arm 2010-11-14
<Neko> kernel question: if we're using make-kpkg to build kernel image, headers, source etc. how do we make linux-libc-dev ?
<fagan> Neko: you should ask on monday everywhere is dead during the weekend
<Neko> I worked it out anyway :)
<Neko> magic hidden targets
<Neko> I should read man pages instead of just --help
<fagan> hehe
<Neko> oop no that target is obselete, and therefore.. we're screwed. anyway it was a bad idea to start. better get to work on a better kernel :D
<GrueMaster> rsalveti: Regarding bug 664642, The kernel that was in proposed was tested and passed.  Or is this for the linaro kernel?
<ubot2> Launchpad bug 664642 in indicator-application (Ubuntu) "indicator-application-service crashed with SIGSEGV in g_object_unref() (dup-of: 637202)" [Undecided,New] https://launchpad.net/bugs/664642
<ubot2> Launchpad bug 637202 in indicator-application (Ubuntu) (and 1 other project) "indicator-application-service crashed on logon (affects: 438) (dups: 94) (heat: 1204)" [High,Confirmed] https://launchpad.net/bugs/637202
<GrueMaster> oops.  bug 663642
<ubot2> Launchpad bug 663642 in linux-linaro (Ubuntu Maverick) (and 3 other projects) "DVI doesn't work at BeagleBoard xM rev A3 (affects: 1) (heat: 18)" [Undecided,Fix released] https://launchpad.net/bugs/663642
<dcordes> Arash18k: so with same kernel, you have the evdev touchscreen rotation working on lucid, but not in maverick. that's correct ?
<Arash18k> yes, now gonna try it with latest kernel from evo tree, copying rootfs atm
<dcordes> Arash18k: be aware it will cause many problems
<Arash18k> evo tree?
<dcordes> yes
<Arash18k> it worked fine for meego
<dcordes> Arash18k: no usb host, no backlight, errornous ts driver
<dcordes> and the configuration is totally wrong
<dcordes> e.g. it will enable android paranoid networking
<Arash18k> hows nexus tree?
<Arash18k> dcordes, no luck with mouse, on maverick
<Arash18k> *touch sry :p
<ScottK> Does anyone know if the most recent gcc-4.5 upload breaking implicit-it=thumb was on purpose or not?
<Arash18k> looks like in maverick my ubuntu know my touch screen as laptop touch pad!!
#ubuntu-arm 2011-11-07
<misham> Does anyone have a .config for BeagleBoard-xM rev C using Linus's kernel?
<misham> I'm working with a camera module that is slated to go into 3.2 kernel, but I'm having trouble getting ethernet to work.
<misham> or could someone tell me which kernel options I need to have enabled to get ethernet working?
<prpplague> janimo: ping
<janimo> prpplague, hello. The panda you gave me works fine :)
<prpplague> janimo: no worries, just wanted to make sure you got home with it ok.
<janimo> prpplague, yes, thanks :)
<janimo> Did you manage to get a look at the broken one?
<prpplague> janimo: please make sure to let your supervisor know that the board has been replaced
<prpplague> janimo: yea, replaced U22 and it is working for testing
<janimo> prpplague, sure
#ubuntu-arm 2011-11-09
<vganesh> hi i am a novice and am trying to boot linux over pb11mpcore through an sdcard. How do i configure the sdcard so that i can set the environment variables in the arm board
<leekic> Can ubuntu 11.10 install on I.MX51 board?
<infinity> leekic: It can almost certainly run on one, but no, we have no installer for them right now.
<infinity> leekic: (Since every new installer image on ARM needs a different boot loader and kernel, we don't produce one for every board...)
<punxos> Hi
<nontrivial> hello
<nontrivial> does anyone know if 11.10 will run on an arm plug server
<nontrivial> such as TonidoPlug
<Neko> hmm that guy disappeared before anyone answered...
<GrueMaster> Not that it matters.  I don't think that system is armv7 compatible.  Seems based on Shivaplug processor.  Can't find better details.
<prpplague> anyone got some handy dandy instructions for using ubuntu 11.10 with dual displays on the pandaboard?
<robclark> prpplague, plug in two monitors, see what happens?
<robclark> prpplague, I guess it "should just work", at least if the two monitors have a similar pixel clock
<prpplague> robclark: yea, only thing i had to do was enable the secondary display
<robclark> (but in reality, I dunno..  I only have one monitor)
<prpplague> robclark: nhg was wanting to know if there was some specific docs for it
<robclark> it should come up mirrored by default
<robclark> open monitors control panel, unclick "mirror" (or whatever it says) to get virtual desktop..
<robclark> ie. it should just work like on PC
<robclark> (or PC without nvidea binary driver, at least)
<prpplague> robclark: interesting, i had to enable it via sysfs first, then it showed up in the monitors panel
<robclark> hmm, one of the displays not getting enabled properly?
<robclark> hdmi?
<prpplague> robclark: dvi
<prpplague> robclark: hdmi comes up ok
<robclark> hmm..  dvi relies on external (to dvi) i2c to detect connection..
<robclark> so it should not care about the dss state, whether it shows up in monitor control panel or not
<robclark> prpplague, anyways, the code (if you care) is in omap_connector.c, in omap_connector_detect()
<prpplague> robclark: interesting, thanks for the info
<robclark> np
<Neko> GrueMaster, any news on the NM hangs on boot and oem-config doesn't uninstall itself bugs?
<GrueMaster> nm hangs?  Not sure I know of that one.  As to oem-config, that is documented in the release notes with a workaround.
<GrueMaster> Essentially, you need to open a console (ctrl-alt-F1), login, and type "sudo oem-config-remove && sudo reboot".
<GrueMaster> ubuntu
<GrueMaster> erp.  wrong window.
<Neko> you told me about this nm hang :( something about NM stalling on boot which may have caused a long, long wait before oem-config ran in the first place
<GrueMaster> I think that was fixed prior to release.
<Neko> okay.. as for the oem-config thing I was hoping that there was a real fix and not just a "workaround in the release notes", even a particular knowledge of what caused the breakage in the first place even if nobody touched it yet
<GrueMaster> We are still debugging it.  I can hit it with the right SD card 99% of the time, others are only hitting it ~%60.  And there are no relevent messages in any logs.  I need to tweak the scripts that launch oem-config to generate their own output logs.
<GrueMaster> Even then, this will not be fixed in Oneiric.  Can't fix images w/o respin, which never happens after release.
<Neko> okay, the release note says "in some corner cases" but the bug doesn't relate what those cases might be
<GrueMaster> The "corner cases" are that I can easily reproduce it, but others can't.  Since I have at least 1 of every board rev released, I have a wider variety to test with.  And I also have a large collection of SD cards.
<GrueMaster> Some combinations reduce the repeatability greatly.  Others cause it to manifest everytime.  I can reproduce it 99% of the time with one SD card on every platform rev.
<Neko> so it's related to... extremely slow disks?
<GrueMaster> Not sure.  The one I have that reproduces more frequently is a Micro Center Class 6 16Gb SD.  My class 10 16G work most of the time, and my class 2 4GB rarely.
<GrueMaster> It appears to be highly timing related.
<GrueMaster> I'll look at debugging it more soon.  I was in Orlando since 10/26 so haven't been able to look at it yet.  And I'm busy with other priority work atm.
<GrueMaster> Best case scenario is that I can root cause the issue or come up with a workaround that can be scripted and applied between resize and oem-conifg steps.  It would be semi-manual though, so a bit of a cludge any way you look at it.
#ubuntu-arm 2011-11-10
<brendand> all of a sudden i'm having problems with my pandaboard. keep getting dropped to a busybox saying it can't find root device
<ogra_> when did that start ? did you change anything in your boot configuration ?
<shadeslayer> lilstevie: any progress on the B70 and B80? :)
<brendand> ogra_ - sorry for the way late reply. i'm using the released desktop image, started around Oneiric release time
<brendand> ogra_ - i'll have to try with a Natty image and see if it's specific to the Oneiric image
<brendand> ogra_ - i just hope my hardware isn't borked
<GrueMaster> brendand: have you looked at the SD card on a different system to see if the root partition is still there and the uuid matches with the one in boot.script?
<brendand> GrueMaster - /dev/mmcblk0p2 shows up fine on my laptop
<GrueMaster> brendand: Make sure the uuid matches.  What does it say when it dumps you to busybox?
<ogra_> check the uuid and compare to the one in boot.script, as GrueMaster said
<lool> ogra_: around?
#ubuntu-arm 2011-11-11
<brendand> has the method of writing the image to the card changed for oneiric (vis-a-vis pandaboard)
<brendand> if i write a natty image using 'zcat <gz file> | sudo dd of=/dev/mmcblk0' then it works fine
<brendand> with an oneiric image i get an error saying it can't find the root partition
<ogra_> lool, oh, seems i missed a ping from you (i was sick the last days) ... do you still look for me ?
<lool> ogra_: Nothing urgent
<ogra_> k
<lool> ogra_: do you have 5 mn for a phone call?
<lool> would save me some typing  :-)
<ogra_> sure, can you use my mobile # ?
<lool> sure
<lool> does it end in 7483?
<ogra_> yep
<lool> it's what I have in my address book, but directory shows it as your landline rather than mobile
<mirabilos> hi, how can I get stuff test-built? (PPA seem to be amd64+i386 only these days)
 * mirabilos trying to fix dietlibc FINALLY
<suihkulokki> mirabilos cool :)
<suihkulokki> mirabilos: there is no virtualization for arm, that's why no arm on PPA's
<mirabilos> ah ok
<mirabilos> does one of you guys have an sbuild or cowbuilder for ubuntu/arm oneiric or precise?
<mirabilos> the last times, doko built it, but he seems EAVAIL
<suihkulokki> I have a chroot :P
<mirabilos> ok, cool
<mirabilos> please build dietlibc (0.33~cvs20111108-2) from debian experimental (unchanged), then install its dietlibc-dev binary package in the chroot and build mksh (40.2-3exp1) from debian experimental, again unchanged
<mirabilos> if that's ok for you
<suihkulokki> ok
<mirabilos> the latter contains the best testsuite for it
<mirabilos> :)
 * mirabilos is mksh author, FWIW
<suihkulokki> would it work on armhf also?
<mirabilos> I hope so, but there'sâ¦ hold a sec
 * mirabilos looks for link
<mirabilos> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633479
<ubot2> Debian bug 633479 in gcc-4.6 "ICE: gcc-4.6: ICE on armel+armhf with mksh, on armhf with oss4-4.2-build2004-1" [Important,Open]
<suihkulokki> oh, ok
<mirabilos> this gcc bug (fixed upstream since 2 months or so) prevents armhf AND armel builds in debian currently
<mirabilos> ah, bot ;)
<mirabilos> (another reason for me to look for dokoâ¦ OTOH he _does_ do a _lot_â¦)
<mirabilos> i haven't yet heard back from the hppa guys, but the alpha guys report success, as do all debian release architectures
<mirabilos> plus, this dietlibc issue should fix the propolice SSP problems on ubuntu
<mirabilos> (tested on precise chroot myself, but x86 onlyâ¦)
<suihkulokki> that bug seems to be fixed upstream, needs backporting
<mirabilos> the gcc one? yes.
<mirabilos> I don't really have access to ARM hardware, except Debian porterboxen (it's frowned upon to build gcc on them, which I can understandâ¦ it can take days, well on m68k it takes 3 daysâ¦)
<mirabilos> (and can't install random software to test it there)
<suihkulokki> mirabilos: ask lindi- for access
<mirabilos> access to what? (he helped with fixing the dietlibc armhf bug, yesterday IIRC, too ;-)
<suihkulokki> ARM hw
<mirabilos> mh ok (when I get time and nobody beats me to it)
<mirabilos> openrheinruhr this weekend
<mirabilos> (what platforms does ubuntu support from precise on, btw? I've just stumbled upon a bug re. powerpc and sparc breakage, dietlibc related)
<suihkulokki> mirabilos: http://kos.to/mksh/
<mirabilos> thanks, that's #633479 alright
<mirabilos> did dietlibc build fine?
<mirabilos> also, you might want to check that your box doesn't have clock issues:
<mirabilos> ] make[1]: Warning: File `/tmp/ccJCeRLb.mk' has modification time 0.089 s in the future
<mirabilos> ] make[1]: warning:  Clock skew detected.  Your build may be incomplete.
<mirabilos> (but that's unrelated to this)
<suihkulokki> mirabilos: yes, it compiled ok
<mirabilos> ok thanks
<mirabilos> did it also run the two tests? (twice './ttt')
<mirabilos> the ttt binary compiled from the tc??????.c file (bug number) is the one that segfaulted before
<suihkulokki> mirabilos: dietlibc compiled fine. just uploaded log to same dir
<mirabilos> ok
<fedon_> hi
<fedon_> what is multimedia extras perspective for ubuntu 11.10?
<fedon_> for panda board
<fedon_> any one knows how to make xv to work?
<mirabilos> wonderful; I just uploaded dietlibc to sid (with ok from zumbi) and put a sync request into the ubuntu-sponsors direction; hopefully that'll fix the situation finally
<mirabilos> (Â± the gcc bug)
<punxos1> Hi
<punxos1> How can I put a global variable into a register ?? In sparc is like "set GlobalVariable, register" in arm ???
<punxos1> ok, is -> ldr register,=Varglobal :)
<dtchen> are there porter boxes accessible to ~ubuntu-dev? I've been using qemu+sbuild but keep getting ICEs that only occur locally.
<punxos1> I the first asm line in a SWI ..How can I get sp from USER ? is banked!
#ubuntu-arm 2011-11-12
<dragunov11> hey, has anyone tried 11.10 core on nokia n900?
#ubuntu-arm 2011-11-13
<oruE-htraD> Hey I had an idea for ubuntu, would it be possible to create a program similar to ps home?
<int_ua> Was the OMAP3 support dropped?
<int_ua> there are no OMAP3 images in the daily cdimages for today
<int_ua> Anybody home?...
<int_ua> So, someone knows something about OMAP3 support in the 12.04?
#ubuntu-arm 2012-11-05
<ogra_> bug 1060171
<ubot2`> Launchpad bug 1060171 in Compiz Core "gtk-window-decorator crashed with SIGSEGV in g_hash_table_lookup_node() from g_hash_table_remove_internal() from event_filter_func() from gdk_event_apply_filters()" [High,Fix committed] https://launchpad.net/bugs/1060171
<bizulk> hi ! Lastly I wanted to work on Bug 1058022. So I updated the installed ubuntu precise but I don't have package linux-
<bizulk> image-3.2.0-33-omap_3.2.0-33.52_armhf.deb available, I just have it until 3.2.0-32 which does not have tidspbridge installed. So what's wrong is there any repository that I should add ?
<ubot2`> Launchpad bug 1058022 in linux (Ubuntu Precise) "no tidspbridge support in kernel." [Undecided,Fix committed] https://launchpad.net/bugs/1058022
<ogra_> lilstevie, do you have any way to get the camera on the transformer to work ? seems the nexus has the same
<mainerror> So, to the Nexus 7 folks. I bought a Nexus 7 just to help you guys but now I'm not quite sure how I can help. :D
<ogra_> well, start with unlocking and installing ubuntu ;)
<mainerror> Oh, well I'm way past those steps of course. ;)
<mainerror> Got a OTG cable too.
<ogra_> great, well, how deep do you want to go ?
<ogra_> easy tasks are simply reporting bugs about missing devices or issues with the system or UI
<mainerror> I'm willing to go as deep as the white rabbit is leading me (that means if there is documentation on certain things).
<ogra_> next harder task would likely be to meake a device or sensor work
<ogra_> https://android.googlesource.com/device/asus/grouper/+/505d795dfcfd473d2a5a2f20177d355bcd254492/init.grouper.rc
<ogra_> this is for example the file that android executes on boot to enable the different devices
<ogra_> so mimicing parts of what that does to get a device working might be a good start
<ogra_> the original android /system partition is in /dev/mmcblk0p3, you can mount it at any time and use bits from there (i.e. firmware files etc)
<mainerror> Alright, that's a good starting point. Cheers!
<ogra_> beyond that there are a ton of workitems in the specs listed on the Nexus7 wikipage ... many of them are less device specific if you prefer working on a broader plan :)
<ogra_> hmm, i really wonder why we have no /dev/video0 on the nexus, the camera should actually support v4l
<ogra_> and there are mi1040 and tegra_camera devices
<ogra_> janimo, we didnt make any config changes in that area vs android, right ?
<ogra_> i see that all necessary v4l options are on in my config
<ogra_> oh
<ogra_> we have v4l but not v4l2 enabled
 * ogra_ tries a kernel build
<ogra_> hmm, no /dev/video0 even with that changed kernel
<janimo> ogra_, I don't think this driver we use has v4l2 support.
<ogra_> well, there is an experimental v4l2 layer for embedded SoC cameras i just enabled
<ogra_> in the hope it would pick up our cam
<ogra_> but it doesnt
<janimo> we had a comment on the webcam bug saying a v4l driver is in the work and could be released soon by nvidia
<ogra_> janimo, i see the android uevent rc script changing permissions for a /dev/video0
<ogra_> so something must init it
<ogra_> https://android.googlesource.com/device/asus/grouper/+/9013d6467fab6c15e6339d389cfebcc7cda828e0%5E/ueventd.grouper.rc
<ogra_> even two /dev/video* devices there
<ogra_> that means something sets up v4l, right ?
<ogra_> seemingly some userspace bit
<janimo> ogra_, could it be for optional external USB webcams?
<janimo> I wonder why the ov2710 is there
<ogra_> thats the usual back camera on that arch
<ogra_> i guess its a generic script for grouper
<janimo> but grouper is only nexus7 so indeed interesting it has video0 nodes
<ogra_> well, grouper is the board
<ogra_> who knows what other tablets are out there that we havent seen yet :)
<ogra_> (with that SoC)
<ogra_> https://android.googlesource.com/device/asus/grouper/+/9013d6467fab6c15e6339d389cfebcc7cda828e0%5E/audio/audio_hw.c
<ogra_> heh, i wonder why the audio init code has support for portarait and landscape modes
<mainerror> mhmm
<lardman> different output to speakers depending on their location?
<ogra_> probably though the device itself only has a mono speaker builtin
<ogra_> and with headpÃ¼hones it shouldnt matter
<ogra_> aha !
 * ogra_ sees a lot of avp_init calls in dmesg now when starting a camera app
<ogra_> that seems to be realted to tegra_mediaserver though
<lilstevie> ogra_, no, the camera is one of those things I have not really looked at cause it is really screwed up
<ogra_> k, thx
<ogra_> well, that /dev/video0 mangling in the android bootscripts gives me some hope
<lilstevie> heh
<ogra_> ERROR: "tegra_camera_mclk_on_off" [drivers/media/video/tegra/mi1040.ko] undefined!
<ogra_> GRRR !
<ogra_> cant build as module
<lilstevie> ogra_, afaik there is some gstreamer stuff involved in the camera in android, at least for the tf
<ogra_> well, it would still use v4l at some point i think
<lardman> not necessarily
<ogra_> but yeah, might be that there is some userspace initialization
<lardman> does the camera appear in sysfs, or is there no driver loaded?
<ogra_> it appears in /dev
<lardman> oh right, I thought the problem was that it didn't appear there
<ogra_> i have a /dev/mi1040
<lardman> ah ok
<ogra_> and a /dev/tegra_camera
<ogra_> which is the generic toplevel i think
<ogra_> oh, and attaching my logitech cam works OOTB
<lilstevie> oh, lardman didn't see you there
<lardman> hey lilstevie, how's things? Exams finished now?
<lilstevie> yeah, had my last one this morning
<ogra_> congrats !
<lardman> :)
<lilstevie> now 6 months holiday until I have to do it all over again for yet another year :/
<lardman> lol
<baggers> Sorry if this is the wrong place for this question but: In the current Nexus7 build is network over usb available. I'm currently using the nexus7 for playing embedded lisp but havent been able to enable netusb. Is there a way to enable it or is it a recompile job?
<ogra_> baggers, not yet, the current kernel only has the android gadget enabled
<ogra_> janimo, ^^^
<ogra_> janimo, there is a composite cdc device that should give us serial and usb network
 * ogra_ installs a kernel with all android bits disabled now
<ogra_> lets see if that still boots
<janimo> ogra_, baggers if you can provide me with the required config options I'll enable it
<ogra_> (trusted_foundations is highly android dependant apparently)
<ogra_> ouch
<ogra_> that doesnt look good
<ogra_> hangs at the bootloader screen
<ogra_> grmbl
<baggers> janimo: wow I must admit I'm a total noob at this depth so I may need things spelling out. I'll explain what I'm going for. I tried to enable network over usb using 'iifconfig usb0 192.168.1.1' I got an error about device not existing and that (with some google'age) led me to a page talking about the netusb module. So I'm not really sure what I'm looking for!
<janimo> baggers, ok nevermind. Probably USB_NET or some such , I do not know the exact name
<baggers> sorry about that, I'm ready to learn but I'm defintely trying to learn by diving in the deep end (or it feels deep to me!)
<baggers> k
<janimo> baggers, no problem :)
<ogra_> janimo, CONFIG_USB_CDC_COMPOSITE
<janimo> ogra_, ok thanks
<ogra_> or  CONFIG_USB_ETH
<janimo> I wish ubuntu had a config file with all arch indep options it enabledin the kernel
<ogra_> first one gets you serial and net, second one net only
<ogra_> janimo, i thought apw said they had something
<ogra_> but gadget support is pretty arm specific
<ogra_> (at least intel machines with otg port are rather rare)
<ojn> I have one right here. :)
<ogra_> heh
<ojn> Motorola Razr i :)
<ogra_> lol
<ogra_> a very common device then :)
<ogra_> sigh, so TF needs android
<ojn> Given that I now have an ARM laptop, an Intel phone somehow seems suitable. :)
<janimo> ogra_, do we need TF at all?
<ogra_> janimo, yes, the bootloader checks for it
<ogra_> it wont fire up the kernel without it in place
<baggers> ojn: what laptop are you using?
<ogra_> just tested here
<ojn> baggers: Samsung Chromebook
<janimo> ogra_, ok. is it a problem that we use some android functionality then?
 * ogra_ ordered one for playing around with it 
<ogra_> janimo, no idea, i dont think it uses much more than that
<ogra_> i migth be wrong though. there might be ifdefs in drivers
<ogra_> so that they function differently in android vs linux
<ogra_> i guess someone should look into maiking TF work without android enabled
<ogra_> so we are on the safe side
<janimo> safe side in what sense? What do we lose by having some android cfg options enabled?
<lilstevie> ogra_, how do you mean "make tf work without android enabled"
<ogra_> lilstevie, have a trusted foundations driver that works n a normal linux kernel
<lilstevie> oh you mean without the android drivers enabled
<ogra_> lilstevie, i fear if the general android option is on, there might be drivers having ifdefs focring different behavior
<lilstevie> that shouldn't be much of a problem, you may have to watch out for some things, I know with the tf201 they use functions from the android drivers for things like the vibrate motor
<ogra_> TF needs general android support enabled
<lilstevie> which drivers out of interest
<ogra_> dunno
<ogra_> network/BT come to mind
<janimo> ogra_, I think the ifdefs are for specific features not something too generic line ANDROID
<lilstevie> cause I have disabled it on my builds, but it really does not make anything work better
<janimo> I think wakelocks is the most important that can affect the behaviour
<lilstevie> yeah
<ogra_> janimo, if they are "#ifdef ANDROID" i would expect android specifics
<janimo> ogra_, true.
<lilstevie> and that is one of the first things I turn off
<lilstevie> wakelocks are pretty horrid to sleep
<ogra_> i.e. i could imagine hardcoded firmware paths etc
<ogra_> or points to android userspace bits
<lilstevie> ogra_, the only one that I know of with hardcoded firmware paths are the wifi drivers
<lilstevie> which is based off defconfig anyway
<ogra_> yeah
<ogra_> well, that was just an example
<lilstevie> the bt requires brcm patchram plus no matter what
<lilstevie> the camera maybe
<ogra_> there are 10000s of lines of code one would have to look at for finding out about it :)
<lilstevie> heh
 * ogra_ doesnt really feel like doing a grep -r on the kernel tree
<janimo> ogra_, git grep is faster :)
<lilstevie> well I honestly haven't seen anything that works better with android* disabled
<lilstevie> also grep -r isn't too bad on the kernel
<lilstevie> the whole aosp tree not so much
<janimo> git grep -w ANDROID|grep "#if" or something
<ogra_> ogra@anubis:~/Desktop/nexus/kerneltree/nexus7$ grep -r "#ifdef ANDROID" * 2>/dev/null|wc -l
<ogra_> 9
<janimo> ogra_, you suspect bluetooth or net may depend on ANDROID code to work well?
<ogra_> i'm likely grepping for the wrong thing
<lilstevie> wifi doesn't depend on android code
<janimo> maybe there ar ifndefs
<ogra_> janimo, well, i know that net definitel has intercepting code paths for the groups stuff
<lilstevie> bluetooth is so hit and miss with kicking up to life I couldn't tell you :p
<ogra_> BT works fine up to the point where data goes over the connection here
<ogra_> i can pair just fine
<ogra_> and tkamppeter claimed at UDS he had a mouse working
<ogra_> (i only tried keyboards yet)
<lilstevie> I could never get keyboards working
<lilstevie> I had my mouse work once, then all of a sudden stop, and never work again
<lilstevie> and I have been able to send a file over bt about half a dozen times, but again hit and miss
<ogra_> ogra@anubis:~/Desktop/nexus/kerneltree/nexus7$ grep -r "ANDROID" * 2>/dev/null|grep ifdef|wc -l
<ogra_> 114
<ogra_> ogra@anubis:~/Desktop/nexus/kerneltree/nexus7$ grep -r "ANDROID" * 2>/dev/null|grep ifndef|wc -l
<ogra_> 47
<ogra_> janimo, ^^^
<ogra_> and security/tf_driver/tf_device.c has "#ifdef CONFIG_ANDROID"
<lilstevie> probably cause of it only really being useful in android
<ogra_> why would it have an ifdef then ?
<lilstevie> no idea
<lilstevie> seen some pretty stupid things though
<ogra_> seems it calso could use zebra or crypto_fips
<ogra_> #ifdef CONFIG_ANDROID
<ogra_> #include <linux/device.h>
<ogra_> #endif
 * ogra_ shakes his head
<ogra_> uh
<lilstevie> ogra_, heh, ASUS/nVidia have done some really silly stuff in places
<ogra_> the gadget support makes my desktop get confused
<ogra_> NM tries to set up the network on both devices now
 * lardman wonders when ARM will release an OpenCL SDK (for the Mali T604)
<victorp> ogra_, quick q - is there a command line way to get the battery level ?
<ogra_> victorp, cat /sys/class/power_supply/battery/capacity
<ogra_> victorp, gets you the percentage
<victorp> ogra_, thanks
<Laney> can I dist-upgrade to raring on the nexus or will the world end?
<ogra_> Laney, you want to pretty heavily pin the PPA stuff
<Laney> could that be copied up to raring in the PPA?
<ogra_> i dont think unity/nux7compiz have all fixes in raring already
<ogra_> and linux-firmware definitely doesnt have the wlan FW yet
<Laney> righto
<ogra_> the PPA stuff shuld go into raring directly
<Laney> unity/nux will go out of date in quantal even soon
<ogra_> yeah, noticed the uploads
<Laney> when the SRU is released, that is
<ogra_> achiang, ^^^
<ogra_> will we do rebuilds for updates/security ?
<ogra_> Laney, note that we disabled both on purpose
<ogra_> with exactly that intent :)
<ogra_> (i.e. to not have to care about updates and security versions)
 * Laney lives on the edge and goes to raring
<ogra_> Laney, btw, i think cjwatson tired that too already
<ogra_> at least he asked about it
<achiang> ogra_: sorry, not seeing the question for me?
<ogra_> but i havent heard back
<ogra_> achiang, Laney pointed out that -updates has a new unity
<Laney> proposed ATM, but will be updates soon
<ogra_> achiang, the question was will anybody update the PPA packages
<achiang> ogra_: specifically which packages?
<ogra_> we said initially we wouldnt support that
<achiang> ogra_: i think we just want all fixes to go into R
<ogra_> achiang, unity and its stack
<achiang> ogra_: i doubt we would update the PPA. there's not too much gain for us to do so
<ogra_> k
<achiang> ... unless there is something i am missing, in which case i am happy to be educated. :)
<ogra_> well, people play with the sw-sources  UI and enable updates/security
<achiang> see "software updates" - https://wiki.ubuntu.com/Nexus7/UsingTheDevice
<ogra_> no biggie since we can point to "we said we wouldnt suzpport that"
<ogra_> achiang, yeaaah ... but that was on Oct. 26 !
<achiang> right. when time comes, we'll just ask jono to blog about it and say, "everyone should dist-upgrade to R now"
<ogra_> (we should take the date out and make clear we also wont start to support it)
<achiang> ... except he'll forget to say for just the nexus7 and everyone on x86 will do it too ;)
<ogra_> it sounds a bit like "we're working on it" with that date in there
<ogra_> haha
<achiang> ogra_: ok
<xnox> hrw: I like the android-tools packaging in debian with all the makefiles =)
 * GrueMaster debates leaving #ubuntu-arm since none of his systems appear to be functional anymore.
<ogra_> GrueMaster, why did you break them ?
<GrueMaster> I updated my servers to 12.04, and that broke a lot of stuff.
<GrueMaster> For example, my 8-port serial card no longer works.  And it took me 2 days after upgrading from Natty to Precise for me to get my mirror raid working again.
<GrueMaster> I just don't have time to put into fixing these issues.
<ogra_> wow, sounds like missing kernel modules
<GrueMaster> And without them, I have no infrastructiure for my pandas to do anything usefull.
<ogra_> yeah, understood, but let ppisati know
<ogra_> i bet it got lost in a merge somewhere
<GrueMaster> He only does arm kernels.  THese aren't arm kernel issues, but x86 kernel.
<ogra_> oh !
<GrueMaster> I feel the quality of Ubuntu is diminishing, and I just don't have the time to track bugs on issues that don't ever get fixed (a vast majority of my bugs have closed due to inactivity).
<GrueMaster> I saw a lot of major issues upgrading one server from 10.04 to 12.04 that had that server down most of the weekend.  The issues were dead simple and could/should have been discovered and fixed prior to 12.04 release.
<GrueMaster> But since Canonical's stance towards QA seems to be to let the community do it, I can find better use of my time/resources.
<mfisch> GrueMaster: the only bugs closed due to inactivity should be ones marked Incomplete
<GrueMaster> mfisch: I have seen a few bugs of mine filed back on Maverick closed as that release is no longer supported.  The bug reports were complete, triaged, and very reproducable.
<GrueMaster> No one bothered to work on them.
<GrueMaster> I have even posted patches for some bugs, but they were never pulled in.
 * mfisch extinguishes GrueMaster's lamp
<mfisch> GrueMaster: I suspect the bug closers were just triagers rather than people who could fix issues, but ignored patches are annoying
<GrueMaster> Check out https://bugs.launchpad.net/~gruemaster and see how many bugs are listed as in-progress, confirmed, triaged.  Look at the dates or bug numbers and tell me I'm wrong.
<achiang> well, the good news is Canonical is taking QA much more seriously now, and i would 100% disagree that the company is assuming the community will just do it. doesn't fix what's past though, but i don't know what the solution there is either
<GrueMaster> So, they are bringing back some level of manual/desktop testing?  Or are they going to continue to script everything and run in VM only?  A lot of the bugs I found were only found through manual testing.  And some of the bugs had scripts to work around them as opposed to marking them for fixing.
<GrueMaster> At any rate, the only reason I have stuck around this channel was to help users.  SInce most of my wiki pages have been either deleted or rewritten beyond being helpful, this has bcome too time consuming.  And I have real work to do.
<hrw> xnox: I have more stuff for it. have to organize a bit
<ogra_> xnox, will i get both, make_ext4fs and ext2simg ?
 * ogra_ just noticed the blueprint status change
<ogra_> would be good to have tehm both for comparison (and after all to have make_ext4fs as a fallback since we already know it works)
<xnox> ogra_: yes, that's what I am hacking together right now.
 * ogra_ hugs xnox 
<xnox> hrw: ` cat makefile | pastebinit ` is good enough =)
 * xnox is working on it.
<ogra_> wow
<ogra_> how complex
<ogra_> pastebinit makefile
<ogra_> ;)
<ogra_> or probably: pastebinit ./makefile
<hrw> xnox: open bug in debian
<xnox> ack.
<xnox> ogra_: my hand compiled binaries don't even segfault =)
<ogra-nx7> heh, cool
<[mbm]> Laney: dist upgrade on the n7 really didn't break as much as I was expecting, unity rendered incorrectly without the libnux changes
<Laney> [mbm]: nice. how incorrectly?
<[mbm]> just got alpha blended garbage where dash would be on the side
<[mbm]> removed most of the n7 specific packages from my install, especially the autologin stuff
<xnox> ogra-nx7: I built them, but didn't test them at all. You can try $ bzr bd lp:~xnox/ubuntu/raring/android-tools/add-ext4-utils
<xnox> to get yourself a package.
<xnox> Will upload tomorrow. As I am EOD now.
<ogra-nx7> xnox, you rock !
<xnox> ogra-nx7: hardly.... it's mostly monkey-patching.
<xnox> but thanks =)
<ogra-nx7> :)
<infinity> Monkeys make the world go 'round.
<ogra-nx7> ++
<mjrosenb> ok, I installed  (GNU/Linux 3.4.0-1487-omap4 armv7l) somewhat recently, and now wish to run the previous kernel (3.2.0-mumble)
<mjrosenb> I alread ran:
<mjrosenb>  apt-get remove linux-image-3.4.0-1487-omap4 linux-image-3.4.0-1486-omap4 linux-image-3.4.0-1485-omap4 linux-image-3.4.0-1484-omap4
<mjrosenb> but I still seem to be running a brand-spanking new kernel
<infinity> mjrosenb: Re-running flash-kernel might fix you up, if the only kernels you have left are 3.2.0-*
<mjrosenb> how is that file even around any more?
<infinity> You're actually booting from kernels on the u-boot partition, not from your root.
<infinity> Which is what flash-kernel moves around and mangles.
<infinity> mangles, too.
<infinity> Very likely a legitimate bug here that removing kernels doesn't re-run flash-kernel, while installing them does.
<infinity> ogra-nx7: ^-- Sound familiar?  I've never really noticed, to be honest, if this is broken. :P
<ogra-nx7> quantal ?
<ogra-nx7> f-k cant downgrade in its 3.0 version
<infinity> "can't" seems a bit strong.  I suspect that's fixable...
<infinity> But ew, if that's the current state.
<ogra-nx7> yeah
<ogra-nx7> there s a bug open somewhere
<mjrosenb> welp, it looks like I am back to running 3.2
<mjrosenb> hopefully it'll be more stable than its successor
<infinity> mjrosenb: 3.4.0 wasn't a shipping kernel anyway... If you're on Q, you should have been up to 3.5.0-something.
<infinity> And if you're on precise, well, installing a current Q kernel should work alright too.
<infinity> (But precise's kernel is generally fine as well)
<mjrosenb> infinity: I bumped it manually because I was trying to get oprofile working
<mjrosenb> since evidently oprofile and pandaboards don't get along too well
<mfisch> ogra-nx7: is there an upstream project for tegra3 drivers in LP?
<ogra-nx7> mfisch, nope, just use the package
<LarsN> afternoon everyone.
<LarsN> how are some of you using your Ubuntu powered Nexus7 devices?
<[mbm]> with bluetooth keyboards and mice
<cwayne> ogra_: ping
<achiang> mfisch: do you know which upstream bug is the one where suspend via power button doesn't work?
<mfisch> achiang: it's linked in the wiki, let me look
<mfisch> its been re-duped now even
<mfisch> AceLan: https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/1041137
<ubot2`> Launchpad bug 1041137 in gnome-session (Ubuntu) "Activating suspend from power button menu does not work" [Undecided,Confirmed]
<mfisch> sorry AceLan
<mfisch> achiang: ^^
<[mbm]> wasn't there a dconf setting to make the power button go directly to suspend?
<[mbm]> oh, gsettings
<mfisch> [mbm]: I think ogra_ knows the magic to do that
<cwayne> mfisch: [mbm]: there is one, let me look for it
<[mbm]> gsettings set org.gnome.settings-daemon.plugins.power button-power 'suspend'
<cwayne> yep, that sounds right
<[mbm]> is it just me or is the elan-touchscreen extremely buggy?
<AlanBell> is there any value in me getting a Nexus 10?
<mfisch> AlanBell: in terms of Ubuntu?
<AlanBell> mfisch: naturally :)
<mfisch> AlanBell: I think it's a different manufacturer and chipset
<mfisch> AlanBell: Nexus10 - Samsung, Nexus7 - Asus
<achiang> AlanBell: nexus10 is samsung exynos
<achiang> AlanBell: nexus7 is tegra3
<mfisch> AlanBell: so you'd need a new kernel
<AlanBell> so, not going to work?
<achiang> AlanBell: very different chipsets, our image 100% won't work on it
<mfisch> AlanBell: nope
<AlanBell> aww, but that screen is yummy :(
<mfisch> seems like a great FAQ question
<achiang> cwayne: ^^ FAQ question :)
<AlanBell> hmm, maybe I will get a N10, give that to family for the kitchen, and nick their N7 and reflash that one
<mfisch> not a bad idea
<cwayne> achiang: it's already there :)
<achiang> thanks!
<k1l_> well, driver support on ARM is like back in the 90s on regular PCs :/
<ogra_> [mbm], ony my way out, but there it is http://people.canonical.com/~ogra/tegra/nexus7/
<cwayne> mfisch: huh, apport-collect added nothing
#ubuntu-arm 2012-11-06
<jrgifford> hi all! My Nexus 7 has been flashing for the past hour.
<jrgifford> not a good sign?
<jrgifford> 16GB model.
<jrgifford> i see i'm not the only one experiencing this - http://askubuntu.com/questions/206984/installation-on-a-nexus-7-gets-stuck-while-flashing-the-root-filesystem
<achiang> jrgifford: yeah, we've seen that occasionally. only advice we have is to try again
<jrgifford> achiang: should i try with the 8GB image?
<achiang> jrgifford: you won't brick the device as long as you can reboot back into fastboot mode
<achiang> jrgifford: i would try 16G one more time, then try 8G
<jrgifford> i'll reopen that question on AU and then drop an answer saying that you need to try again...
<jrgifford> achiang: ok, thanks!
<achiang> jrgifford: good luck
<jrgifford> achiang: tried again, it's "Preparing the root filesystem, please wait, this will take a few minutes..." :D
<achiang> jrgifford: great, now you wait ~15m and it will be all good
<achiang> :)
<jrgifford> achiang: yay! :)
<jrgifford> achiang: it works!
<jrgifford> thanks
<achiang> jrgifford: cool, have fun
<jrgifford> will do. :)
<ogra_> xnox, we'll also need the simg2img (to turn sparse back into normal loop mountable images in cse you want to take a look inside)
<ogra_> xnox, also your clean target removes the fastboot binary (or tries at least)
<ogra_> *the simg2img binary
<xnox> ogra_: ok, will check.
<xnox> ogra_: is there something wrong with remove fastboot binary?
 * xnox thought we compile it.
<ogra-nx7> well, it wont exist in the extras dir
<xnox> ah =)
<xnox> ogra-nx7: ogra_: can't seem to find simg2img
<ogra-nx7> hmm, should be in the same branch in the same dir upstream
<ogra-nx7> (extras)
<xnox> there is "-S don't use sparse output format" in the  ext2simg.c
<ogra-nx7> thats not the same
<xnox> ok.
<ogra-nx7> -S is used to create non sparse images
<ogra-nx7> i.e. only at creation time
<xnox> https://code.google.com/p/usefulshellscript/source/browse/trunk/simg2img.py ?
<ogra-nx7> simg2img actually turns a existing img into a mountable nonsparse one
<xnox> hmm... found an android one as well.
<xnox> https://gitorious.org/0xdroid/system_extras/blobs/9c842adc177c1bcd22c2038d8d237bfb70654dca/ext4_utils/simg2img.c
<ogra-nx7> gimme a few minutes, i  got a branch on my PC upstairs
<xnox> but that's not android official repo?
<ogra-nx7> ah, yeah, that looks good
<ogra-nx7> there must be an android one as well
<xnox> ogra-nx7: so the jelly-bean branch has img2simg and simg2img but not the master branch.
<ogra-nx7> aha
<ogra-nx7> and the existing package uses master ?
<xnox> ogra-nx7: it was moved from extras ext4_utils to core/libsparse....
<xnox> found it, will compile.
<ogra-nx7> yay, hide and seek with code
 * xnox ponders about continue to monkey compile or actually compile libsparse into a separate lib.
<xnox> ogra android_reboot.c ?! =)
<xnox> but that wants linux/reboot.h and I am not sure if I need the android kernel header for that, or just any local one.
<ogra_> ugh
<ogra_> xnox, where is that needed ?
<xnox> ogra_: well, QA might like that... won't they?
<ogra_> fastboot can reboot devices
<ogra_> does android_reboot.c buy us anything extra ?
<xnox> not really.
<ogra_> unless they want to set up autotests with android for comparison reasons i doubt QA will use it
 * ogra_ already feared that was some kind of dep of simg2img
<xnox> setup_fs wants it for some reason.
<xnox> but I'm not sure we need setup_fs.
<ogra_> i dont think so
<xnox> if it pops up we can compile it =)
<ogra_> :)
<ogra_> yeah
<ogra_> janimo, do we have a bug against linux-firmware to include our wlan/BT blobs ?
<xnox> ogra_:  there are now following binaries packaged: ext2simg  ext4fixup  img2simg  make_ext4fs  mkuserimg  simg2img  simg2simg  simg_dump  test_ext4fixup
<ogra_> xnox, awesome, i think thats more than enough :)
<xnox> ogra_: I pushed the branch. I'll try to repack an image and flash it, to see if it works.
 * ogra_ pulls
<ogra_> builds fine here
<victorp> ogra_ hi
<ogra_> hey victorp
<ogra_> nice blogpost !
<victorp> ogra_ thanks
<victorp> I am working in something else at the moment - that is why I asked you about the battery yesterday
<ogra_> i fear firefox simply doesnt use GLES while webkit in chromium does
<victorp> ogra_ could well be
<victorp> am I right that cat /sys/class/backlight/pwm-backlight/brightness
<victorp> will give me the screen brightness level?
<ogra_> i talked to chris about it but it seems the GLES support in FF would only get us WebGL, not faster rendering
<ogra_> should, yes
<victorp> ok.. I think I found a bug
<victorp> ma
<victorp> maybe
<victorp> do you know what the "Dim screen to save power" is suppose to do?
<ogra_> dimming after a defined time
<victorp> ogra_^
<victorp> running on battery?
<ogra_> you can define it in the power settings for battery and AC modes
<ogra_> there is another bug with the slider in there
<ogra_> it allows you to actually actively set the current brightness ... and doesnt catch if you are setting it to 0
<victorp> cant find the power settings you mention..
<ogra_> so you can end up with a black screen ... havent reported that one yet
<victorp> nice
<ogra_> iirc it is called brioghtness or so
<ogra_> ah, brightness and lock
<victorp> yes, that one only gives me a tick box
<ogra_> oh, yeah, seems there were options dropped
<ogra_> there used to be a monitor or display tab in the power settings that allowed finer grained management
<victorp> I run a test overnight and brightness was dimmed from 99 to 70 something
<victorp> almost immediately
<victorp> but I kept printing the file above and every hour it seems that it bounce back to 99
<victorp> and then back down
<victorp> how even it never when lower than 70+ even when the battery was at 10%
<ogra_> yeah,. definitely some bug
<victorp> I think it would make sense to make the dimming a function of the battery level dont you think?
<ogra_> we also dont have a working ambient light sensor yet, that might influence the behavior
<ogra_> that might get annoying if it dims more and more based on the battery level
<victorp> well, assuming that the room is constantly at the same light
<victorp> I doubt you would notice it
<victorp> :)
<ogra_> if you only do that for the nexus you can easily pick the level thats set ... but if yxou want to make that a generic function you end up with funny stuff
<victorp> you should be able to turn it off too
<ogra_> i.e. on my ac100 the battery icon turns red at 20%
<victorp> ah
<victorp> I see
<ogra_> that still is like 3h of worktime
<ogra_> on my x86 lappie 20% means find a wallplug in the next hour
<victorp> ack
<victorp> it seems that battery sensors are not thought for ARM
<ogra_> the prob here is that percentages are used
<victorp> only x86 high consuming beasts
<ogra_> there are finer grained values that could be used
<ogra_> (see what upower -d gives you)
<victorp> well that could be easily tuned if systems are pre-installed. I still think that reducing brightness with battery is not a bad idea... I wonder to whom I should suggest it. raise a bug?
<ogra_> yep
<victorp> oooh
<ogra_> start with filing against gnome-power-manager
<victorp> upower -d is cool
<ogra_> :)
<ogra_> only with janimo's latest kernel though :)
<victorp> seriously , I wish there was a wiki for this sort of tips
<ogra_> the original one we had didnt have all the "energy" values filled
<victorp> btw - I notice that my systems was prompting me to install updates
<ogra_> yeah, there were PPA updates
<victorp> is that part of the newark ppa or should I not install them
<ogra_> check in sw-sources
<victorp> ok, running update now
<ogra_> make sure ypou didnt accidentially enable updates/security/proposed
 * victorp loves to ssh to it
<ogra_> if thats the case, updating is safe
 * ogra_ got pretty good with onboard already
<victorp> btw I just got this... works well with the n7 http://www.amazon.co.uk/PadStand-Black-Portable-integrated-charging/dp/B003QGPAHS/ref=sr_1_1?ie=UTF8&qid=1352203517&sr=8-1
<ogra_> forcing yourself to only use the device this way for a day or two really helps
<ogra_> neat
<victorp> ogra_ I am waiting to get my usb keyboard for that
 * ogra_ has http://www.amazon.de/Twelve-South-Compass-Aluminium-St%C3%A4nder-Apple/dp/B003XQMUVA
<ogra_> and a really cool BT keyboard i still cant use :)
 * victorp does not believe on BT
<victorp> very nice!
<ogra_> well, i like to charge the device while its on the stand
<victorp> I was going to ask about that. I thought achiang said that janimo had a patch to charge whilst in usb OTG mode
<ogra_> yeah, havent tested it yet
<ogra_> i currently run the latest though with some self added test modifications, i probably should try it
<ogra_> hmm, compiling the composite gadget into the kernel wasnt a clever idea it seems
<ogra_> makes both network managers freak out if i plug it into my PC
<ogra_> they both try to automatically establish a usbnet connection
<victorp> sings of modern days.. I dont have a USB to USB cable
 * ogra_ makes a note to make that a module next time
<victorp> I have millions of USB to micro USB
<ogra_> you have the charger cable
<victorp> so I can test it either
<victorp> which goes to micro
<ogra_> which is fine for the usbnetwork stuff :)
<ogra_> if you ten enable port forwarding on your PC you have actual wired network on the nexus ;)
<ogra_> *then
<victorp> ogra_ what I wanted to do is to plug keyboard+mouse+charger to the same USB hub
<ogra_> right, or use a powered hub
<ogra_> there should be male-male cables though
<victorp> indeed
<victorp> I only have one but is hooked to my pc
<ogra_> i know there are female-female ones
<victorp> I suppose I could swap them around
<victorp> lemme play with my hbus
<victorp> hubs
<victorp> naah, is not charging
<victorp> how do I know if I have the right kernel?
<ogra_> janimo, ^^^ should that work already ?
<ogra_> victorp, i think it should show a -7 in uname -r
<ogra_> (my homebrewed one shows 3.1.10-7-nexus7 ... should be the same for the PPA one since they come from the same tree)
<victorp> it's a 6
<victorp> maybe needs a reboot?
<ogra_> yeah, if t was updated it should tell you about it though
<ogra_> i.e. turn the gear icon in the panel red
<victorp> yes, it doesnt
<ogra_> might be because jain uses the linaro packaging
<ogra_> for the kernel package
<victorp> checking that the ppa is in the sources
<ogra_> look in /boot
<ogra_> if there is a vmlinuz-3.1.10-7-nexus7
<victorp> nope
<victorp> ppa is in the sources
<victorp> and update manager says my system is up to date
<victorp> :(
<ogra_> aha
<ogra_> the uploads happened to the private PPA
<victorp> I guess we should get janimo to confirm that 7 has been pushed out
<victorp> ??
<ogra_> it is on the new image but someone needs to copy it over to the public ppa
<victorp> shouldnt they go to the normal ppa
<ogra_> the image is buiult from the private one
<victorp> seems like we should make that part of the process
<ogra_> so uploading there first and then copying is required i think... not sure
<ogra_> nah, we should immediately start uploading to raring instead :)
<victorp> once there is a raring image :)
<victorp> look forward to that
<victorp> in the meantime, If you can make the honours I can test the patch
<janimo> victorp, we need to clarify where to ship firmware before working raring images I guess
<ogra_> janimo, just file a bug and leave that bit to the kernel team
<ogra_> janimo, any objections if i pocket copy the 7.10 kernel to the public PPA ?
<ogra_> i think its on the images already
<janimo> and indeed we should start using the public PPA for image builds while we still do 12.10 based spins
<ogra_> so should be safe to do
<janimo> ogra_, no objections, thanks
 * ogra_ does it then 
<ogra_> along weith the tegra driver fix
<janimo> ogra_, I was waiting for people with OTG cables to see if it works
<victorp> janimo, that is fine. The discussion came because the public ppas had not been update..and we got to raring images :)
<janimo> and whether it causes other USB related regressions
<ogra_> victorp, apt-get update should give you a new tegra driver and a new kernel now
 * ogra_ goes for coffee
<victorp> ogra_,  done - still nothing in /boot
<ogra_> you ran update-manager afterwards ?
<ogra_> apt-get update only updated the lists of available packages
<ogra_> apt-get dist-upgrade is the equivalent of what update-manager does then
 * ogra_ definitely sees the new packages in https://launchpad.net/~ubuntu-nexus7/+archive/ppa
<ogra_> 16.0-0ubuntu3  of the tegra driver and 3.1.10.7.10  of the kernel
<janimo> ogra_, do we need an externally powered USB hub with the nexus?
<janimo> I plugged a keyboard in and nothing happens
<ogra_> just plugging in the kbd should work
<ogra_> directly i mean
<ogra_> i only have used the device with powered hubs yet
<ogra_> when i used a hub
<ogra_> janimo, why iso9660 ?
<janimo> ogra_, ?
<ogra_>  [ Jani Monoses ]
<ogra_>   * [Config] Enable ISO_9660_FS
<ogra_>   * [Config] Various options needed for LXC support.
<ogra_>   * [Config] Enable SND_USB_AUDIO, disable SND_HDA_INTEL
<ogra_> i understand the last two ...
<ogra_> but am wondering why we enable iso9660
<janimo> ogra_, ah. There was a bug about some USB stick not mounting
<janimo> it can be used on non-CD media too
<ogra_> oh,. indeed
<janimo> maybe even our ISO hybrids are like that
<ogra_> yeah, you can just dd them to USB
<ogra_> not that that makes isolinux usable on arm though :)
<janimo> I should have added bug numbers to the changelog, but at that point they were private still
<ogra_> but yeah, i get the point
<victorp> ogra_ running update manager now
<ogra_> yep, it just popped up here as well, offering me the new driver
<ogra_> seems propagation takes a while in the PPA
<ogra_> even though the copying is instantly done
<victorp> ogra_ is it normal that I dont find the update-manager but instead I have a software-updater ?
<ogra_> yeah, i'm just stuck with old naming in my head
<ogra_> the binary is still called update-manager though
<victorp> well the kernel is still 6
<ogra_> eek
<ogra_> janimo, looks like we dont have linux-nexus7 in the image
<ogra_> i only see the linux-image files installed, not the meta
<janimo> ogra_, right, the metapackage is new and did not get the chance to tell vanhoof to update the seed
<ogra_> ah., k
<ogra_> victorp, so for now that means manual updating ... actually for everyone who used the old (and todays) image
<ogra_> it will only start to work once the meta package is preinstalled
<victorp> ol
<victorp> ok
<victorp> so do I need to download the .deb
<victorp> and install them manually?
<ogra_> you can work around it by installing linux-nexus7 i think
<ogra_> manually
<ogra_> that will pull in the metapackage alongside
<ogra_> yeah, that works
<ogra_> janimo, was the wlan firmware file fw_bcmdhd.bin ?
 * ogra_ cant remember and tries to find it
<janimo> ogra-nx7, yes
<ogra_> janimo, bug 1075549
<ubot2`> Launchpad bug 1075549 in linux-firmware (Ubuntu) "please include fw_bcmdhd.bin and bcm4330.hcd in linux-firmware for support of the nexus7" [Undecided,New] https://launchpad.net/bugs/1075549
<victorp> ogra_ doing that now.. can we add it to the wiki pls
<ogra_> lets leave the rest to the kernel team, i'm sure they have a process for checking the legal stuff etc
<ogra_> janimo, might be helpful if someone else than me could set it to confirmed
<janimo> ogra_, ok. I am fine whichever way it is solved :)
<victorp> ogra_ the raring image will have to have the same disclaimer that you get from the installer
 * janimo wonders what broke his chromium that most pages are black backgrounds and not much else
<ogra_> victorp, then we cant do it in the distro
<janimo> victorp, an EULA dialog on first boot or something less intrusive?
<ogra_> first boot wont help
<janimo> ogra_, you're right
<janimo> can't access the net
<ogra_> it will have to happen before you even download anything
<ogra_> and thats something we have a policy against in the distro ... but we ship a ton of other broadcom firmware, i'm sure there is a way
<ogra_> (to include it properly)
<janimo> I'd also want to see if we can have it legally shipped before spending too much time on technical workarounds
<ogra_> lets leave it to the experts dealing with firmwares every day ;)
<ogra_> right. if kernel team says no, we can think about workarounds like stealing it from the /system partition
<victorp> ogra_ -7 now running
<ogra_> but i'm confident we can put it into linux-firmware
<victorp> about to plug the usb hub, hold your breath
<ogra_> victorp, great
<ogra_> janimo, how about a kernel upload to raring ?
<janimo> ogra_, I guess I could.
<ogra_> do it :)
<janimo> If 7.10 is ok for all, I could upload this as a start
<janimo> no USB regressions then?
<ogra_> NEW will probably take a while so we can be sure the binary is there once we start image builds
<janimo> someone tested it last week and said he could not see the kbd
<ogra_> not so important for raring i guess
<victorp> ogra_, does it count as working if OTG is now completly broken?
<ogra_> i need smoe package for the builds
<ogra_> could even be empty ;)
<ogra_> victorp, not really
<victorp> i thought so
<victorp> :)
<janimo> victorp, how did OTG regress?
<victorp> mouse not working
<janimo> probably the same issue I got reported before
<janimo> neither kbd?
<victorp> does not detect anything
<janimo> and they used to work in 6 ?
<victorp> nope
<victorp> or my usb stick
<victorp> yeap
<victorp> all of them but charing
<victorp> charging
<victorp> and it is still not charging
<janimo> ok, seems like a serious issue. I need to rever that charging patch, I think that broke it
<victorp> well I am going to un install this kernel;
<victorp> do we do testing?? problably not achiang :)
<ogra_> janimo, looking in dmesg i see it enmables the HUB
<ogra_> (tegra-otg)
<ogra_> but it doesnt seem to see any devices
<ogra_> so better revert that one :)
<victorp> I am plugging the same hub that with -6
<victorp> with -6 the keyboard, mouse and usb stick where all recognised
<ogra_> i plugged in various things here
<ogra_> nothing is recognized ... but the cable properly loads/unloads tegra-otg when plugging it
<victorp> with -7, not even the mouse plugin is working
<ogra_> yep
<ogra_> same here
<victorp> ogra_, how do I get rid of it
<victorp> uninstalling linux-nexus7 ?
<ogra_> well, that and the linux-image-*-7-* package
 * ogra_ does his first upload to raring 
 * janimo did his 5 min ago
<ogra_> *sniff* starting my release with a binary blob
<ogra_> there we go, the bug is "inprogress" :)
<victorp> ogra_ I removed that package too but still running -7
<ogra_> victorp, oh, flash-kernel cant downgrade kernels (debian removed that feature in the latest version and i didnt get around to write a fix for that yet)
<ogra_> victorp, sudo abootimg -u /dev/mmcblk0p2 -k /boot/vmlinuz-3.1.10-6-nexus7 -r /boot/initrd.img-3.1.10-6-nexus7 && sudo reboot
<victorp> ogra_ soooo
<victorp> do I need to re-flash the image?
<ogra_> that will get you back to -6
 * victorp swearing
<ogra_> well, its just a bit longer than sudo flash-kernel, dont swear
<victorp> too late :)
<ogra_> (thats actually the line f-k would call *if* there wouldnt be a version check before that)
<victorp> flasing also loses anything I set up
<ogra_> ??
<ogra_> what do you talk about ?
<victorp> packages?
<ogra_> you should only write the old kernel to your boot partition with the command i gave you above
<ogra_> <ogra_> victorp, sudo abootimg -u /dev/mmcblk0p2 -k /boot/vmlinuz-3.1.10-6-nexus7 -r /boot/initrd.img-3.1.10-6-nexus7 && sudo reboot
<ogra_> from your running nexus
<ogra_> no need to re-flash the device or anything
<janimo> ogra_, in flash-kernel mmcblk0 is equivalent to mmcblk0p1 in our case?
<victorp> ogra_ I thought that is what you were telling me
<ogra_> nahh+
<ogra_> you never need to install a machine more than once with an ubuntu system :) there is always a way to repaitr it
<ogra_> janimo, no, mmcblk0p1 would
<victorp> let me try that command
<ogra_> victorp, dont get the device name wrong :)
<victorp> the mouse is alive!!!
<ogra_> great
<victorp> ogra_ I copy and paste it
<ogra_> see, dont get desparate :) re-installing is for QA junkies :P
 * victorp cries
 * ogra_ actually has machines around that were installed on warty and upgraded regulary ... they still run without issues
<janimo> ogra_, hmm, flash-kernel would need quite some changes to support alternate partitions
<janimo> ogra_, would specifying the boot part directly without having to scan for it break things? Is it not fixed for various devices?
<ogra_> janimo, well, my original ac100 code was capable .... sadly that wasnt what debian implemented in the end
<janimo> as it is now we cannot easily boot from recovery and have it upgraded there
<ogra_> you need to edit the db
<ogra_> oh, wait, there is that autodetection that debian also trashed
<ogra_> janimo, i would say lets add a check for "Boot-Device:", if thats set we should override the autodetection with it
<ogra_> currently android devices only use Android-Boot-Device and do a pointless autodetection that debian even broke
<ogra_> janimo, but that will always be a hack until f-k actually supports overrides for the DB
<ogra_> whicjh it totally doesnt atm
<ogra_> f-k 3.0 is still in its infancy
<ogra_> infinity, oh, fyi, bug 1056206
<ubot2`> Launchpad bug 1056206 in flash-kernel (Ubuntu) "3.0~rc.4ubuntu23: cannot flash an old (previous Q) kernel" [Wishlist,Confirmed] https://launchpad.net/bugs/1056206
<ogra_> janimo, oh, look, low hanging fruit coming your way in bug 1072657
<ubot2`> Launchpad bug 1072657 in ubuntu-nexus7 "Can't mount a nfs disk" [Undecided,New] https://launchpad.net/bugs/1072657
<janimo> ogra_, I think I added NFS at one point prompted by that bug
<janimo> in 6.9 maybe
<ogra_> ah, its not closed though
<janimo> still, I'd wait with any extra config changes will we sync up with ubuntu. No point in adding them piecemeal
<janimo> ogra_, right, since only today did the new kernel become released
<ogra_> yep
<ogra_> hmm, bug 1075415 is intresting
<ubot2`> Launchpad bug 1075415 in ubuntu-nexus7 "Touch is too sensitive: touch/tap is interpreted as a drag/swipe" [Undecided,New] https://launchpad.net/bugs/1075415
<ogra_> i think in android the touchscreen ships a calibration file
<ogra_> yeah, there it is
<ogra_> https://android.googlesource.com/device/asus/grouper/+/505d795dfcfd473d2a5a2f20177d355bcd254492/elan-touchscreen.idc
<victorp> ogra_,  you might like this one : http://victorpalau.net/2012/11/06/ubuntu-nexus7-7-hours-battery-life-whilst-browsing/
<ogra_> sweet
<ogra_> 7h is great for the fact that we havent touched power mgmt at all
<achiang> ogra_: so reading scrollback... did we upload a broken kernel to our PPA?
<ogra_> achiang, well, not having the meta nobody will get it offered anyway
<ogra_> achiang, so no worries
<ogra_> but yes, seems we did
<achiang> well, i'm a bit worried about what happened to our qa process
<achiang> as in, we didn't have one
<victorp> ogra_ pretty good I reckon
<victorp> imagine if screen brightness was adjusted :)
<ogra_> achiang, well, all i saw was that the new kernel ended up in the new image, i should probably not have done the pocket copying but it felt inconsistent to have it in the new image but not in the PPA
<victorp> achiang, I am not sure the problem was the pocket copy
<ogra_> victorp, right and CPUs get powered down if not needed etc
<ogra_> victorp, well, i published it
<ogra_> so yes, the pocket copy was definitely a part here
<achiang> victorp: we were waiting for test results from staging PPA
<victorp> ogra_ but as you said, it was in the image
<achiang> i know for a fact that janimo asked for testing results
<achiang> i certainly never signed off on a kernel upload
<victorp> achiang, so why was it in the new image?
<ogra_> victorp, right, but i should have waited for a go from achiang nontheless
<janimo> I reverted the charging fix and will upload the kernel in a minute
<achiang> victorp: because the wrong thing happened?
<janimo> but where? staging PPA?
<victorp> stop stop stop
<janimo> anyway, I do not think people get autoupdates
<ogra_> janimo, closed, then pocket copy to the other one
<janimo> this is a new ABI
<victorp> what was wrong was that we released a new image without testing it
<victorp> also
<janimo> ogra_, but why closed? People should be able to test before it being in an image no?
<victorp> that we did not push the same updates from the image to the public ppa
<janimo> so why not in staging?
<ogra_> victorp, sure, but the followup stuff messed it up more
<ogra_> no excuses
<janimo> ogra_, anyway not a big difference
<victorp> ogra_ two wrongs do not make a right
<ogra_> right
<achiang> i don't think we actually released a new image
<victorp> a) we didn't test
<ogra_> victorp, two wrongs make a worse :)
<victorp> b) the image and the public ppas where out of sync
<victorp> c) I dunno, but I felt like putting a c
<ogra_> heh
<victorp> achiang, right so that might have been the confusion
<victorp> anyways... the ppa update did not work
<victorp> so no worries
<ogra_> well, after all, no harm done you would have to manually fish out the package name and install it
<victorp> achiang, and yes, the kernel is very broken
<ogra_> or install the meta
<janimo> I think what happened was we had a staging kernel, and it was decided we make a test image that includes it for easier testing
<janimo> so then image and public ppa became out of sync
<victorp> what a mess... it is all my fault achiang
<ogra_> janimo, that sounds very plausible
<janimo> the fact that we have 3 PPAs does sometimes confuse us all
<janimo> also, did todays image become the default for the installer?( I hope not)
<achiang> no, the installer image needs to be manually updated, which we have not done yet
<achiang> and we will not do so until we QA the image
<janimo> ok, then, less harm done
<janimo> I am glad I deferred having a kernel metapackage, so every ABI bump upgrade must be explicitly requested by the user
<ogra_> achiang, then i'm sorry for messing up the QA process ...
 * ogra_ will wait and ask next time
<janimo> I am less glad I did not myself test each bugfix I uploaded in the kernel
<janimo> ogra_, it's not you. I think it was a combination of us all that got into this situation
<achiang> yeah, we have a QA team. let's use them. :)
<achiang> anyway, we'll get it right next time
<ogra_> janimo, well, i saw discussions about the new image being up and thought it was released
<achiang> just good that we didn't break our hundreds of users out in the wild
<ogra_> hundrets ?
<ogra_> what a pessimist you are *g*
<janimo> ogra hundreds is the subset of the tens of thousands that actually use USB kbd/mouse and would be affected :)
<ogra_> ah, these ... lamers that fear the touchscreen :P
<ogra_> i would really love to know how we make use of the settings in https://android.googlesource.com/device/asus/grouper/+/7fce7d56cb077e869b9509cd2770d92e8cf29dcc/elan-touchscreen.idc
<ogra_> i bet if we could teach the driver to use these the touchscreen situation would get better
<ogra_> janimo, hmm, do we do anything with the touchscreen firmware ?
<ogra_> android seems to forcefully update it with the file on every boot
<janimo> ogra_, the in-kernel fw seems to be newer or just as new as the external blob
<janimo> so I stopped shipping the latter
<ogra_> right, but i wnder if that probably triggers some calibration
<janimo> I saw the way to upload it is to echo into a sys/ file
<ogra_> yeah
<janimo> ogra_, that can be tested with our current images by getting the file and echoing it's path. Not sure who does the calibration
<ogra_> yeah, i dont seem to see any difference in behavior after echoing the file
<janimo> to me our touch issues seem to stem from the fact that we have tiny controls to poke at
<ogra_> i just would like to know how it applies the settings from elan-touchscreen.idc
<ogra_> as bug 1075415 might be solved with touch.pressure.scale = 0.0048 and touch.size.scale = 36
<ubot2`> Launchpad bug 1075415 in ubuntu-nexus7 "Touch is too sensitive: touch/tap is interpreted as a drag/swipe" [Undecided,New] https://launchpad.net/bugs/1075415
<ogra_> it could well be that our touchscreen is set to 1px squares
<ogra_> they seem to not be module options one could pass though
<ogra_> #define MAX_FINGER_SIZE          31
<ogra_> that could be it
<ogra_> there is also IOCTL_ROUGH_CALIBRATE
<dmart> mi all
<dmart> hmmm, wrong window and wrong spelling -- how embarrassing
<ogra_> mi dmart !
<ogra_> :)
<dmart> ogra_: mi yourself :)
<ogra_> heh
<mfisch> achiang: can we close this N7 bug?  https://bugs.launchpad.net/ubuntu-nexus7/+bug/1075416
<ubot2`> Launchpad bug 1075416 in ubuntu-nexus7 "Please install openssh-server out of the box, at least for dev images" [Wishlist,New]
<mfisch> I marked it wishlist, so we could just leave it
<achiang> mfisch: yeah, i think that needs to be close as wontfix
<mfisch> because it deviates from standard desktop
<ogra_> i think even server
<ogra_> it is the first option in tasksel there, but not pre-selected by default
<mfisch> janimo: can give me a brief walkthrough on building a kernel for the N7?
<janimo> mfisch, will copy it to wiki in a minute
<janimo> long overdue :)
<ogra_> it not like it wuld need more than ten lines either :)
<janimo> it needs explanations and context for those who never built a kernel
<ogra_> dont we have a generic "cross build a kernel" page ?
<ogra_> we should really have it, i tend to link people to hrw's blog still
<janimo> mfisch, in the meantime http://paste.ubuntu.com/1337637/
<ogra_> drivers/built-in.o: In function `bq27541_probe':
<ogra_> /home/ogra/Desktop/nexus/kerneltree/nexus7/drivers/power/bq27541_battery.c:726: undefined reference to `get_usb_cable_status'
<ogra_> make[2]: *** [.tmp_vmlinux1] Fehler 1
<ogra_> make[1]: *** [sub-make] Error 2
<ogra_> janimo, ^^^
<ogra_> after the latest git pull
<janimo> ogra_, with no config options changed?
<ogra_> with a git reset
<janimo> that get_usb_cable_status I saw a few times when making some things modular
<ogra_> reset, pull then testbuild makes me get to this
<janimo> ogra_, hmm, I made a clean build before pushing, weird
<ogra_> is there ar "reset harder" option ?
 * ogra_ tries with --hard
<janimo> ogra_, no, git fetch && git reset --hard origin should be enough
<ogra_> lets see
<janimo> ogra_, btw the new kernel is building in the private ppa now, should have the OTG change reverted. Tested with mouse and kbd
<janimo> will be 7.11
<ogra_> yeah, git just told me 7.11 with --hard
<ogra_> didnt fail yet
<janimo> any idea why this page is locked? https://wiki.ubuntu.com/Nexus7/Developers
<janimo> I thought it would be the place to link 'build your kernel' to
<mfisch> janimo: You're not logged in
<mfisch> janimo: Or that's usually what's happened when I see locked pages, or someeone else is editing
<ogra_> bah, failed in the tools as usual
<ogra_> janimo, so all fine
<janimo> mfisch, ah I had to reload it, thanks. Weird that all other pages were editable
<mfisch> this git clone is going to be awhile...
 * mfisch goes to find more bugs while git does it's thing
<mfisch> janimo: are you still working on that kernel build page?
<janimo> mfisch, about to save it
<janimo> mfisch, https://wiki.ubuntu.com/Nexus7/KernelBuild
<janimo> just need to solve some edit conflicts apparently
<mfisch> janimo: yeah sorry
<mfisch> janimo: just revert what I did
<janimo> mfisch, let me know which parts are confusing, and feel free to edit/reword as you see fit from someone who's new to it
<mfisch> I clicked save before I saw the small prnit warning
<janimo> mfisch, no prob
<janimo> I think you cleaned up the code snippets
<mfisch> yeah, doing more of that now
<janimo> which is good, I did not know how that works
<janimo> thanks
<janimo> there may be another cross package missing IIRC, not just gcc needed. If build blows up we'll find out
<mfisch> I added git to the list of stuff you need to install
<janimo> sure
<janimo> we probably want to document the git way only, even if one could simply rebuild from a package source
<mfisch> janimo: fdr clean fails
<mfisch> cd /home/mfisch/tmp/n7kernel/ubuntu-nexus7/debian/build && kernel-wedge gen-control > /home/mfisch/tmp/n7kernel/ubuntu-nexus7/debian/control
<mfisch> /bin/bash: kernel-wedge: command not found
<janimo> ok, a dependency then
<mfisch> installing it now
<janimo> I have been building kernels the past year on the same machine so forgot whether there are extra build-deps
<mfisch> janimo: why parallel=3?
<mfisch> oh I see your note
<janimo> mfisch, maybe that note should be moved in front of the command
<mfisch> working on it
<janimo> as with other comments before commands
<mfisch> what works best?  parallel=num cpus?
<mfisch> num_cpus+50%?
<janimo> num cpus+1 IIRC
<mfisch> ok
<achiang> hm, i always use num_cpus * 1.5
<mfisch> me too
<mfisch> at least I did with android, num cpus + 50%
<achiang> janimo: got a link to some camera stuff in LP - https://bugs.launchpad.net/ubuntu-nexus7/+bug/1068672
<ubot2`> Launchpad bug 1068672 in ubuntu-nexus7 "webcam support" [Medium,Confirmed]
<mfisch> janimo: build worked, thanksd
<mfisch> janimo: actually, where is the kernel config?  I'd like to change some stuff
<janimo> achiang, saw that
<janimo> achiang, still if nvidia is working on a 3.1 port we may want to wait for that
<janimo> mfisch, kernel config is in debian.linaro/config
<janimo> mfisch, I'll add to the wiki page
<achiang> janimo: the way i read the bug, that tree is already 3.1
<janimo> achiang, ok then, I misread 2.6.38 somewhere IIRC
<achiang> janimo: maybe i'm wrong... let me know. :)
<janimo> still the chromeos tree is divergent from the android, in ac100 land they were not easily mergeable
<achiang> ah, i see
<janimo> or cherry-pickable
<janimo> actually now I remember seeing V4L in chromium and asking about it in the tegra channel about 3 weeks ago
<janimo> but that driver seemed not yet ready for some reason
<janimo> but chromium is more linux than android so they may have gotten it to work well enough
<mfisch> janimo: let's also note on the page which steps need to be re-run, specifically does the sed step need to be run on each build?
<janimo> mfisch, the sed step changes a git-tracked file so it persists until one does a git checkout (which syncs the workspace to the repo)
<mfisch> janimo: so it looks like the config option I changed is intertwined with some others, is there a way to manually run make config so I can go through the questions?
<janimo> mfisch, fdr updateconfis
<janimo> updateconfigs
<janimo> mfisch, added a section in the wiki
<mfisch> thanks
<mfisch> janimo: last question, I hope, is the linux-image the only deb I need to copy and install?
<janimo> mfisch, yes, that has the kernel
<janimo> the rest are header files and tools, non-essential for booting
<janimo> mfisch, the more questions, the better the doc becomes, so np :)
<achiang> mfisch: janimo: ogra_: dholbach has graciously taken on the task of reorganizing our wiki, so don't be surprised if you start seeing a bunch of changes happen
<mfisch> ok
<janimo> np
<mfisch> janimo: so there was a bug where the snd_seq module is missing, I added it to the config and it solves the bug
<mfisch> janimo: but, I'm curious why it isn't autoloading, I had to manually load it
<janimo> mfisch, no idea, it may be blacklisted in /etc/modprobe.d somewhere?
<mfisch> hmm, don't see it.
<janimo> mfisch, is this preventing audio in some scenarios?
<mfisch> when I boot this device, I get no modules loaded
<mfisch> janimo: it prevents the usage of some audio tools
<janimo> mfisch, and you installed the deb
<janimo> ?
<janimo> or zImage
<mfisch> janimo: yes, I get the module, just have to manually modprobe it
<mfisch> janimo: deb
<janimo> ok
<janimo> no idea
<mfisch> yeah I'm not sure how it would get autodetected
<nemik> does anyone know if it is possible on the ARM version to install canon printer drivers like the CAPT ones?
<mfisch> janimo: when I run fdr editconfigs it prompts me to edit a file that I'm not certain is the correct one:
<mfisch> Do you want to edit config: armhf/config.flavour.nexus7? [Y/n]
<janimo> mfisch, yes that is the one
<janimo> it prompts for every arch/flavour that package source builds. We happen to only have a single flavour
<janimo> would be nice to have it skipped and not prompt I guess
<mfisch> but I manually edited debian.linaro/config/config.common.ubuntu?
<achiang> mfisch: we need a juju charm to build kernels
<achiang> that would be awesome, actually
<mfisch> achiang: it can take like 5 minutes to provision a machine and then more to do setup, it would be slower than just doing it
<achiang> mfisch: what about the casual kernel builder? i don't mind saying "juju make zImage" and then walking away to do other stuff for a bit
<mfisch> achiang: true
<achiang> especially if i don't keep trees around all the time or have all my build-deps always installed
<mfisch> everyone starts as a casual kernel builder and then it's a downward spiral
 * achiang came back from the dead
<mfisch> janimo: do we have plans to enable a general kernel with all the modules re-enabled?
<janimo> mfisch, yes, the plan is to sync up with the regular ubuntu kernel configs
<NekoXP> anyone got clue on where eglinfo is on quantal?
<janimo> NekoXP, you mean es2_info? This is in mesa-utils-extra
<NekoXP> yeah something like that... :D
<NekoXP> I thought it did llvmpipe rendering if there was no good driver installed. was I wrong or was that an R thing?
<infinity> NekoXP: I vaguely recall there being issues with llvmpipe, where the "issue" was "it sucked".
<NekoXP> I'm getting some odd GL_OES_EGL_image not found things from compiz
<NekoXP> slow but with window decorations would be prefereable to no window decorations at all
<mfisch> janimo: okay, I'm going to defer this audio bug until then, I think we just need some modules
<mfisch> achiang: can you comment on this bug which claims BT loses on/off state after a suspend/resume?  https://bugs.launchpad.net/ubuntu-nexus7/+bug/1073501
<ubot2`> Launchpad bug 1073501 in ubuntu-nexus7 "Bluetooth re-enabled on resume from suspend" [Undecided,Incomplete]
<achiang> mfisch: commented
<mfisch> achiang: thanks
<achiang> np
<janimo> new kernel in  https://launchpad.net/~ubuntu-nexus7/+archive/staging
<janimo> reverts the OTG charging commit which broke USB peripherals
<mfisch> janimo: do you need a new meta package there also?
<janimo> mfisch, don't think so since the current meta is for 7 already
<mfisch> ok
<mfisch> I'll do a quick review of the changelog so we can build a list of stuff to try
<janimo> I think a bump is needed only when ABI (next to last number in version) changes
<mfisch> I think it should be pretty short
<janimo> mfisch the changelog is just Revert OTG charging fix
<janimo> which turned out not to be a fix after all
<mfisch> but the CL between that and what's shipped is what I care about
<mfisch> I assume, for example, you left ISO support
<janimo> right, all that was in 7.10
<janimo> minus the USB breakage
<mfisch> since 7.10 is superseded, whats the quickest way to view it's changelog?
<mfisch> I was just going to pull the source and view the cl
<mfisch> janimo: so it looks like 7.10 is already in the public PPA?
<janimo> mfisch, yes 7.10 is in PPA, 7.11 in staging PPA
<mfisch> I was trying to figure out if we shipped with 6.9 or 6.8
<janimo> quickest way is to look at git I think
<janimo> 6.8 was shipped
<mfisch> so I guess all testing buys us now is piece of mind
<janimo> so ISO, SOUND, NFS are the changes IIRC
<janimo> right
<janimo> I have tested 7.11 FWIW with USB peripherals this time, now that I had a cable
<mfisch> should the NFS change fix this bug?  https://bugs.launchpad.net/ubuntu-nexus7/+bug/1072657
<ubot2`> Launchpad bug 1072657 in ubuntu-nexus7 "Can't mount a nfs disk" [Undecided,New]
<mfisch> it should at least be re-tested
<mfisch> achiang: are we going Fix Released once these hit the public PPA or are we waiting for an image?
<janimo> mfisch, I added NFS modules which were not there before so I hope it fixes that one
<janimo> but I did not test myself
<mfisch> janimo: me either, I dont have the setup, I just told the guy to try again
<mfisch> janimo: I bet your upower fix will fix when the device suspends even after adding power
<janimo> mfisch, I just tested upower --dump today with the 7.11 kernel and it seems to show proper values. Commented on the bug
<janimo> I did not do anything, but also did not test previously and did not saw the erroneous values
<mfisch> janimo: .10 works too, so I marked it as fix released
<mfisch> janimo: change log shows a fix from colin
<achiang> the process should be this:
<achiang> 1) jani builds new kernel and uploads to staging
<achiang> 2) jani sends out mail asking people to test.
<achiang> 3) we test, hopefully each test is associated to a bug
<achiang> 4) once we verify, then we copy to real PPA
<achiang> (or R archive)
<achiang> depending on where we are in the cycle
<janimo> mfisch, ah right, battery stats. Bu tI think the bug was reported against a kernel that had that
<janimo> anyway if it works, we can close it
<mfisch> done
<janimo> achiang, ack
<achiang> so anyway, each change in the changelog *should* be associated with an LP bug
<achiang> janimo: is that how you normally do things?
<achiang> or not really?
<achiang> like ISO_9660: LP: #123456
<ubot2`> Launchpad bug 123456 in xine-lib (Ubuntu) "podcast crashes amarok" [Undecided,Fix released] https://launchpad.net/bugs/123456
<janimo> achiang, well I ommited this so far thinking the bugs were private (while working out of newark)
<janimo> achiang, yes, marking fixed bug is what I usually do
<janimo> when I know about the bug :)
<achiang> heh
<achiang> ok, i think we're on the same page
<achiang> just want to be explicit
<achiang> janimo: thanks
<achiang> mfisch: we should only move to fix-released once it hits the real ppa, not staging
<mfisch> achiang: yes, I'm only testing public ppa fixes ATM
<achiang> mfisch: uh, i'm confused.
<achiang> mfisch: we have 2 public PPAs: staging and ppa
<achiang> the kernel should go into staging first; then once we're satisfied, it goes into 'ppa'
<mfisch> I'm testing "THE" public PPA
<mfisch> the fixes I'm testing were already moved to the public PPA
<mfisch> kernel 7.10
<achiang> mfisch: i think we're talking past each other
<achiang> https://launchpad.net/~ubuntu-nexus7/+archive/staging
<mfisch> agreed
<achiang> https://launchpad.net/~ubuntu-nexus7/+archive/ppa
<achiang> there are two public PPAs
<achiang> not just one
<mfisch> I understand
<mfisch> what shall I call the non-staging public PPA?
<mfisch> because that's what I am testing
<achiang> oh now i see
<mfisch> I don't know a better name for it
<achiang> how did a kernel get into 'ppa' ?
<achiang> release ppa
<achiang> that one is the one janimo uploaded a fix to revert the OTG regression?
<mfisch> no
<mfisch> staging PPA = 7.11 = 7.10 + OTG fix reverted
<mfisch> public, non-staging PPA = 7.10 which is a bunch of fixes + OTG patch
<achiang> ugh
<mfisch> ISO fixes, NFS, battery, etc
<achiang> ok, but no one is getting it because we didn't upload a new metapackage, right?
<mfisch> I saw it with apt-get update
<mfisch> achiang: public, non-staging PPA has a 7.10 meta package
<achiang> oh lovely
<mfisch> so getting 7.11 out quickly would be in our best interests
<janimo> 7.10 in ppa has broken OTG, 7.11 in staging with the only change fixing OTG
<achiang> mfisch: shouldn't you be testing 7.11 then? :)
<mfisch> achiang: will do
<achiang> mfisch: so we can copy it over to the release ppa?
<achiang> janimo: to me, that means you should also upload a new meta package to staging
<achiang> right?
<mfisch> I think staging has 7.10 meta, janimo said it wasn't needed
<janimo> achiang, it is not 100% clear to me, but I thought if the ABI (7) is not changed the meta can stay
<achiang> ok
<achiang> hopefully after today we won't bungle it anymore :)
<mfisch> trying now
<janimo> achiang, do we spin test images based on ppa or stagingppa before making them 'official' 12.10 updates?
<achiang> janimo: i think we only need to respin the image once more, to eliminate the 'random hostname' issue, and after that, no more image spins. kernel updates after that can go into staging, and if they are all good, they can go into universe
<janimo> ok
<achiang> does that make sense or am i smoking crack?
<mfisch> so I added the staging PPA but apt doesn't see 7.11
<mfisch> does that mean we need a newer meta?
<achiang> janimo: ^^
<janimo> achiang, let me check
<janimo> achiang, do you have the meta installed already? linux-nexus7
 * achiang does not
<janimo> it was not part of any image so far as it is new
<janimo> in proper raring images we'll  include it
<janimo> in our spins it was not necessary and we wanted to explicitly say which kernel to include to avoid unintended upgrades
<mfisch> janimo: looking
<mfisch> I dont have the meta installed either
<janimo> mfisch, oh I thought it was all achiang speaking above, whereas he just ^^-d :) That's why I answered him
 * achiang is working on other stuff atm. :)
<janimo> achiang, re image spining, agree with what you said above
<achiang> janimo: alright, so we'll get the .11 kernel QA'ed, spin a new image, and then be happy
<mfisch> janimo: I have linux-nexus7 installed but not linux-meta-nexus7
<janimo> mfisch, confusingly the linux-nexus7 binary package comes from the linux-meta-nexus7 source package
<janimo> so you should be fine
<janimo> whereas linux-nexus7 binary produces linux-image-3.1.10-7-nexus7
<mfisch> ok
<mfisch> so how do I get the 7.11 kernel installed?
<janimo> mfisch, so if you install linux-nexus7 it does not bring in 7.11 automatically?
<janimo> I guess I need to upload a new meta too then
<janimo> I am testing this right now as well
<mfisch> hold one sec
<mfisch> janimo: ii  linux-nexus7                              3.1.10.7.10
<mfisch> janimo: directly trying to apt-get install it doesn't get me 7.10
 * janimo just added the ppa and tests
<mfisch> janimo: added what?
<janimo> I just did add-apt-repository
<janimo> for staging
<janimo> I see it downloads 7.10
<mfisch> yup
<janimo> mfisch, sudo apt-get install linux-image-3.1.10-7-nexus7
<janimo> but not via the metapackage so I need to fix that
<mfisch> linux-image-3.1.10-7-nexus7 is already the newest version
<mfisch> janimo: ^
<janimo> it installed 7.11 here
<mfisch> janimo: okay, it worked now, I had something screwed up in sources
<mfisch> rebooting to try OTG
<mfisch> janimo: USB OTG works
<mfisch> janimo: trying a mouse
<janimo> mfisch, worked here too with both mouse and kbd
<janimo> uploaded the meta
<mfisch> janimo: mouse also works
<janimo> should be copied when it builds to staging
<mfisch> I vote to release it before too many people install .10
<janimo> mfisch, sure
<mfisch> achiang: ^^?
<janimo> but probably not many will install .10 as it is not upgraded to automatically
<janimo> only if they explciitly apt-get install it
<achiang> mfisch: you feel good about your QA?
<mfisch> achiang: for OTG yes, I didn't retest everything
<achiang> mfisch: ok +1 to copy then to release ppa
<achiang> janimo: ^^
<janimo> +1 from me as well
<mfisch> are you going to update the meta so people see it with an upgrade?
<janimo> mfisch, already built in private ppa
<mfisch> thx
<janimo> in a few min it should be published too
<achiang> janimo: you'll take care to copy the packages where they need to go?
#ubuntu-arm 2012-11-07
<mjrosenb> so I boot ubuntu-12.04 on my pandaboard
<mjrosenb> and it gets to X, but I don't seem to have any sort of a window manager running
<mjrosenb> I can right click on the desktop to get a small context menu
<mjrosenb> but no more menus.
<mjrosenb> ok, if I run gnome-terminal from ssh, that seems to work
<mjrosenb> I guess it is just the launcher that is broken/not running.
<[mbm]> what session are you trying to use? if you're running a *dm you can set the session on the login screen
<mjrosenb> the default one.
<mjrosenb> I also set it up to not have a login screen, evidently?
<mjrosenb> what is the default these days, unity?
<[mbm]> lightdm
<mjrosenb> ps says lightdm is in fact running.
<hrw> I see (in backlog) that so far we do not got chromebook users here
<ogra_> hrw, waiting for mine :)
<hrw> ogra_: you still use ac100?
<ogra_> sure
<ogra_> i didnt use it much at UDS but always had it with me
<ogra_> i doubt the chromebook will change that, lets see
<ogra_> janimo, did you upload the kernel to raring yet ?
 * ogra_ doesnt see it in any queue
<janimo> ogra_, not yet
<janimo> I wonder if I should keep both quantal and raring branches in git
<ogra_> well, essentially the difference should just be in the changelog entry
<ogra_> i.e. the distro name
<ogra_> http://www.broadcom.com/products/Wireless-LAN/802.11-Wireless-LAN-Solutions/BCM4330
<ogra_> oh, wow
<ogra_> i didnt know our wlan chip also has an FM radio builtin
<ogra_> i noticed that NM offers WIMAX ....
<[mbm]> hmm never thought of chromebook; figured they would be locked down and only run chromeos
<persia> janimo: Better to keep both branches, in case there is a reason to folk based on SRU vs. development release in the future.
<ogra_> i think they already offer an ubuntu image
<ogra_> persia, there wont be SRUs
<persia> I heard they took extra effort to make it easy to replace the OS in the Chromebook
<ogra_> as soon as we have working raring images we'll mainly care for raring only
<persia> ogra_: Why not?
<persia> ogra_: You will.  Maybe someone else cares.  It's not like an extra git branch is that much overhead.
<ogra_> and will ask people to either upgrade or do a fresh install off an "alpha"
<[mbm]> I remember there was a pc bios for the early chromebooks, just haven't heard anything about the latest
<persia> (and if apw's new system for universe kernel management happens, it would be nice to be prepared to match it)
<ogra_> persia, for only a handfull of chars difference ?
<ogra_> i think it is :)
<ogra_> its really only the distro name in the changelog entry that should differ
<persia> It is?  I find it more work to *delete* a branch than leave it there, if there are no changes for it.
<ogra_> uploads should go simultaneously to both places
<ogra_> until we abandon one of them
 * 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
<ogra_> but currently even an empty package in raring would help me, starting images is blocked on missing a kernel atm
<ogra_> haha
<persia> Why didn't the quantal kernel get copied over when raring opened?
<ogra_> because it doesnt exist in quantal
<persia> Ah.  That's a good reason.  It's so good that I don't care if there's a quantal branch anymore.
<ogra_> we started working on that three weeks before release
<ogra_> and the release team had better stuff to do than reviewing new kernels at that time
<persia> So, in fact, there *shouldn't* be any SRUs: just raring backports.
<ogra_> just PPA uploads in fact
<persia> Why not backports?
<ogra_> well, if someone from the backports team wants to care
<ogra_> the 12.10 image is largely a throw away thing
<ogra_> its heavily hacked in many places and should only serve as a demo
<ogra_> the "real thing" will be the raring image
<persia> 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.
<ogra_> the image has -updates,-security and -backports enabled anyway and we dont encourage people to enable them
<ogra_> in fact it will break your desktop since yesterday
<persia> For a demo, that's probably best.
<persia> I'll stop heckling for now, as the answer to everything will be the same :)
<ogra_> (since there is a new unity that overrides our version in the PPA and no intend to update the PPA package)
<ogra_> 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
<ogra_> janimo, ^^^ that sounds like we could use it legally
<ogra_> to me at least
<janimo> ogra_, pftt, but I wanted to sue Broadcom!
<ogra_> haha
<janimo> ogra_, I will wait till kernel-team/legal whoever gives a verdict :)
<ogra_> yeah, i added a ling to it to the bug
<ogra_> *link
 * janimo installs bash-completion on the nexus7
<ogra_> brave !
<persia> ogra_: I don't read it quite that way.
<ogra_> :(
<persia> 2.3(b) makes me think that it's unsuitable for mirroring
<persia> Check with the mirrors team, but I suspect it needs to be distributed a different way.
<ogra_> sigh
<persia> Because mirrors distribute Ubuntu under the assumption that they accept no liability in doing so.
<ogra_> well, i wonder if thats true for all the closed bits we have
<persia> 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
<persia> I don't propose to do an audit :)
 * persia gets in enough trouble for reading licenses already
<persia> 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.
<ogra_> well, i doubt linux-firmware is anywhere close to DFSG anywaqy
<persia> I do like the wording of 3.3 though: it doesn't actually discriminate against field of endeavour, but not for lack of trying :)
<persia> I did review chunks of linux-firmware at some point in the past, and most of it was only modification-restricted.
<persia> I didn't review all of it, and this was enough years ago that much has probably changed, so you could be right today.
<ogra_> i think it had a real audit at some point
<ogra_> beyond developers
<persia> Mind you, modification-restriction makes it non-DFSG-free, but the rest of the tests pass.
<ogra_> heh
<ogra_> its hard to modify binary blobs anyway
<persia> 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.
<persia> Um, no.  That'S why xxd is shipped by default.
<persia> 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.
<ogra_> yeah, i asked at the bug, lets see what the kernel team thinks
<ogra_> sleep well !
<ogra_> janimo, so rtg asks us to not ship it in linux-firmware at all but in our kernel package
<ogra_> (there was just a discussion on #ubuntu-kernel)
<janimo> ogra_, ok. But that has little to do with legality to distribute right?
<ogra_> right, just with "pfft its a special device, come back if more people use it"
<ogra_> or something along these lines
<ogra_> apparently linux-firmware is mostly generated by looking at the mainline kernel and checking for MODULE_FIRMWARE() calls
<ogra_> if ours does show up there at some point it will be auto-included
<ogra_> (or at least attempted to)
<janimo> ogra_, I thought this broadcom chip combo was also in quite a few x86 machines
<ogra_> i thought so too
<ogra_> and theoretically http://linuxwireless.org/en/users/Drivers/brcm80211 should actually work for us
<ogra_> (the SDIO driver)
<janimo> but anyway, we can include it in the kernel
<janimo> ogra_, is that in 3.1?
<ogra_> practically i didnt get it to work, though that might be totally my fault
<janimo> having a newer kernel would help in many regards I think
<ogra_> janimo, in staging iirc
<ogra_> 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
<ogra_> *htop
<janimo> ogra_, where can you see the alternate/real numbers?
<janimo> 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
<mfisch> janimo: I'll ask our team, I think a few have personal devices
<mfisch> carif: janimo has some questions about the ambient light sensor in Android
<mfisch> janimo: carif is still running Android
<carif> mfisch, janimo, pl walk me through the test you want? Shine some light on tne n7 and see if it changes brightness?
<janimo> 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
<carif> janimo, i have the brightness setting to be automatic and about midway for the slider
<janimo> carif, I can adjust it manually if automatic is not on though
<carif> janimo, very good, so you're asking the question what changes the brightness when automatic is actually set?
<janimo> carif, yes
<janimo> my experiment in covering the sensor or shining a lamp on the tablet do not seem to have an effect
<janimo> or if there is one it is unnoticable
<carif> janimo, i confirm your experiment, i don't know what makes the brightness change however
<janimo> carif, ok thank for the confirmation
<janimo> I'll check on another android device too later
<ogra_> 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
<ogra_> to me everything seems doubled up
<janimo> ogra_, so maybe bugs in battery level reporting and memeory measurements are known to not be very accurate :)
<ogra_> i also see a constant load of 2.xx
<ogra_> but nothing that produces it
<ogra_> and iirc marvin24 once added as fix for to high load reporting to the ac100 tree
<ogra_> (or nvidia did and he merged it)
<janimo> ogra_, never heard of this before. If it happened in ac100 then hopefully we can fix it too
<ogra_> janimo, bug 985661
<ubot2> Launchpad bug 985661 in linux (Ubuntu) "High load average" [Medium,Triaged] https://launchpad.net/bugs/985661
<ogra_> I can confirm that following commit is responsible: "sched: Fix nohz load accounting"
<ogra_> SHA: 3a50863f6706ece7719a68be0ae57957164a0f0c
<ogra_> (comment #35)
<ogra_> though that claims the breakage was originally added in a 3.2 kernel
<janimo> ogra_, I think our 3.1 tree has backports of several commits
<ogra_> http://thread.gmane.org/gmane.linux.kernel/1310462
 * marvin24 can't remember fixing something like this
<ogra_> well, i think it might just have been mentioned in #ac100
<ogra_> or i saw it in a erge in the changelog osr so
<ogra_> xnox, the resultimg images from the tools look good, i havent flashed one yet but what the tools produce seems to definitely be fine
<ogra_> -rw-rw-r-- 1 ogra ogra 1,7M Nov  7 16:13 test2.img
<ogra_> -rw-rw-r-- 1 ogra ogra 6,0G Nov  7 16:12 test.img
<ogra_> test2 is the sparse one (both are empty)
<ogra_> hmm, producing the saem with ext2simg instead of using img2simg gets it even smaller
<ogra_> err, no, bigger
<ogra_> misread
<xnox> ogra_: I'd like to add an autopkgtest for it. Does the test_* utility do anything useful?
<ogra_> no idea
<xnox> ogra_: does it simply need an ext4 image - which can be created on the fly?
<xnox> ack
<ogra_> ogra@anubis:~/Desktop/nexus/builder/tmp$ test_ext4fixup -3 5 rootfs_test.img
<ogra_> error: ext4_parse_sb: superblock magic incorrect
<ogra_> test_ext4fixup: ext4fixup failed!\n
<xnox> hmm...
<ogra_> well, that one was built with img2simg
<ogra_> likely not the right tool for ext4 images if there is edxt2simg ;)
<ogra_> xnox, so, hmm ... it even fails with an image properly created using make_ext4fs
<xnox> interesting so what does test_* thingy suppose to do then? =P
<ogra_> heh, i wonder that too
<ogra_> i like that it so nicely adds a \n :)
<ogra_> in any case the image size isnt acceptable that i get with ext2simg
<dholbach> hey guys
<ogra_> yo !
<janimo> dholbach, welcome to ARM :)
<dholbach> hello ARM hippies :)
<infinity> This channel sure has gotten busier since UDS. :P
<ogra_> heh, yeah
<ogra_> infinity, we lost Grue though
<ogra_> he went away grumpy yesterday
<dholbach> 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'?
<ubot2> Launchpad bug 1049935 in modemmanager (Ubuntu) "Crash on connecting Sierra Wireless mobile hotspot" [Low,Incomplete] https://launchpad.net/bugs/1049935
<ubot2> Launchpad bug 297368 in gnome-phone-manager (Ubuntu) "Sony-Ericsson W910i Not Supported in USB Mode" [Undecided,New] https://launchpad.net/bugs/297368
<dholbach> I was just reviewing the bug filing instructions on https://wiki.ubuntu.com/Nexus7
<ogra_> achiang, ^^^
<janimo> dholbach, I think it should be up to you, you know best practices better and what makes sense globally for ubuntu
<dholbach> is someone regularly triaging https://bugs.launchpad.net/ubuntu/+bugs?field.tag=mobile and adding the ubuntu-nexus7 task?
<janimo> mobile was the initial tag but it may have been misused at times
<ogra_> dholbach, these tags are most likely 4 years old or older from the original ubuntu-mobile team
<dholbach> I don't care too much :)
<dholbach> I was just wondering when I went through the list
<ogra_> we used to use that tag before we got renamed to -arm
<dholbach> luckily enough it's just 2 out of 12 bugs
<ogra_> they should all be invalidated actually
<dholbach> so theoretically we could just leave things as they are and untag the two I mentioned
<ogra_> ++
<dholbach> ok, WFM
<achiang> dholbach: as for triaging, we do triage bugs, but mostly in the ubuntu-nexus7 project.
<achiang> we could start triaging that tag though
<dholbach> 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
<dholbach> just so we don't overlook bugs filed by testers
<ogra_> achiang, well, i thought the idea was to have the tag in raring through apport/ubuntu-bug
<achiang> right
<achiang> ubuntu-bug
<achiang> who is signed up for that WI? :)
<ogra_> so future bugs will definitely carry it
<ogra_> might be me
<ogra_> still wading through WIs this week :)
<ogra_> achiang, though we should probably reconsider the choice of "mobile", we might come across some old LPIA cruft :)
<achiang> ogra_: i don't think i suggested it... ;)
 * achiang twitches re: lpia
<ogra_> someone suggested it in the discussion
<ogra_> cant remember who that was
<brendand> is anyone interested in a way to see the 'top' entry for a specific binary?
<NekoXP> surely you'd get that from "ps aux | grep name"
<NekoXP> or some variant
<brendand> NexoXP - well yeah, exactly. but it's nowhere near that short
<brendand> NekoXP, problem is top only accepts PIDs to filter the list
<brendand> top -p `ps aux | grep $1 | head -n1 | awk '{print $2}'`
<NekoXP> point taken
<janimo> 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
<ogra_> brendand, pgrep ? :)
<janimo> infinity, I just debuild out of the git tree with no orig at all so far
<infinity> 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
<janimo> infinity, thank. I'll check that out
<infinity> janimo: (Only if using a v3 source format, I suspect)
<janimo> infinity, yes just switched linux-nexus7 to 3.0 to see how it works
<janimo> and tought of taking advantage of alternate compressions
<mfisch> janimo: did you look into the "Dim screen to save power" bug also or just the ambient light bug
<janimo> mjust the ambient one as I have a WI to enable the get the light sensor in the kernel working
<mfisch> ok
<ogra_> "	Your Amazon.co.uk order of "Samsung Chromebook Wifi (L..." has been dispatched"
<ogra_> \o/
<NekoXP> wow
<achiang> 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?
<ubot2> Launchpad bug 1065644 in ubuntu-nexus7 "plymouth causes a hard reset of the nexus" [Critical,Confirmed]
<ogra_> achiang, well all i know is that nvidia recommends to remove plymouth completely because it breaks your system
<ogra_> we dont really know which side of the fence is at fault, but i have a WI somewhere to research that
<achiang> ogra_: hm, so known issue for them
<ogra_> right
<ogra_> its prominently in their usage docs on developer.nvidia.com
<ogra_> (for tegra2/3)
<ogra_> achiang, i'll do some debugging and add inof to the bug once i'm through the image build stuff
<ogra_> *info
<achiang> ogra_: np, just going through some of my WIs
<ogra_> right, i did the same today :)
<achiang> ogra_: btw, how do you find your WIs? /me has never really used blueprints before
<ogra_> you can check the blueprints you are involved in on your presonal LP page
<achiang> ok, i've done that
<ogra_> what i personally do though is to just take my personal schedule on summit.u.c
<achiang> but i have to go through the blueprints and then troll for WIs?
<ogra_> and go through the sessions i attended
<achiang> there's no way to automatically see my WIs?
<ogra_> ojnce your WIs are proper and the specs are approved you can use status.ubuntu.com though
<achiang> ah
<ogra_> its just inconvenient during the approval phase
<ogra_> later it gets easy
<achiang> hm, i don't appear here - http://status.ubuntu.com/ubuntu-raring/people.html
<ogra_> your team isnt on there i guess
<xnox> achiang: do you have workitems on blueprints that are "accepted for raring" in the series goal?
<achiang> ah, i was looking at this one -- https://blueprints.launchpad.net/ubuntu/+spec/desktop-r-tablet-desktop-convergence-divergence which does not have it
<ogra_> right, it might needs at least one WI in an approved spec for even generating a report
<achiang> ok
<ogra_> http://status.ubuntu.com/ubuntu-raring/u/ogra.html definitely has something for me already
<achiang> unrelated question: if we're not going to have alphas, when do we expect to start generating dailies? :)
<ogra_> ah, no, it doesnt need to be approved, needs to be "accepted for raring" i think
<ogra_> achiang, asap
<janimo> I see x86 already has dailies so we should too. ogra is probably waiting for my kernel upload :)
<ogra_> achiang, i would like to get going this week but fiurst need a kernel package ... that takes a bit
<xnox> achiang: we have dailies. and we are meant to have a fully working set every two weeks.
<achiang> ogra_: ok, thanks
<janimo> re firmware I still want to know whether we can ship it
<ogra_> janimo, well, for more than that ...
<janimo> I mean we were told by rtg not to put it in linux-firmware
<ogra_> but yeah, kernel is one blocker
<xnox> achiang: so we don't have alphas just many more littlealphas
<janimo> but that does not mean we can put it anywhere for that matter
<xnox> janimo: we are meant to have a bi-weekly testing senergy on a known set.
<ogra_> janimo, well, i think the other fw i found in the generic android wlan tree has a looser licence
<ogra_> we might be able to ship that, someone has to test if it actually works though :)
<achiang> xnox: ogra_: which blueprint talks about installer support in ubiquity?
<ogra_> it claims to be for 4330
<xnox> achiang: huh? ubiquity is the installer....
<ogra_> achiang, https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-arm-ubiquity
<xnox> achiang: or are you after usb-creator?
<achiang> xnox: sorry, me english no good, but ogra_ figured out what i was asking ;)
<ogra_> xnox, i bet he meant nexus :)
<xnox> ack.
<ogra_> achiang, thats for oem-config though
<ogra_> https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-arm-usb-creator-fastboot-support
<ogra_> is the installation/flashing
<achiang> ogra_: ah, ok. i'm just trying to close out as WONTFIX - https://bugs.launchpad.net/ubuntu-nexus7/+bug/1072681
<ubot2> Launchpad bug 1072681 in ubuntu-nexus7 "ubuntu-nexus7-installer should have some logging" [Medium,Confirmed]
<ogra_> heh
<ogra_> achiang, i commented
<ogra_> brendand surely has a point there ... and its easy to add logging to the traball extraction
<achiang> ogra_: no, he was talking about our zenity installer, not tarball-installer
<ogra_> ah
<ogra_> well, usb-creator does logging already i think
<achiang> ogra_: brendand ran into issues with our zenity installer at UDS, but eventually got it working
<ogra_> so does oem-config
<ogra_> but the tarball installer should surely get some
<achiang> ogra_: right, and we won't invest anymore time into the zentiy installer
<achiang> ogra_: sure, file a new bug then. :)
<ogra_> k, just close that one then
<achiang> already done, we spent another 5m talking about it. ;)
<ogra_> i wont file a bug, i'll just implement it with the first upload :)
<ogra_> oh come on ... you manager you
<ogra_> :P
<achiang> :)
<ogra_> does charging the nexus take extremely long for anyone else or is it just me ?
<xnox> ogra_: yes, but it's quicker if you use "official" cable & plug.
<ogra_> probably these 18h it showed me initially were actually correct ... it definitely hangs on the charger since i started my workday
<ogra_> xnox, i do
<ogra_> its at 41%
<xnox> hmm =/
<ogra_> after a fukll workday
<xnox> also I found that the connectors on the nexus are not that good. E.g. the headphones fall-out and the charger disconnects often.
<ogra_> ubuntu@nexus7-roccos:~$ upower -d|grep state
<ogra_>     state:               fully-charged
<ogra_> ubuntu@nexus7-roccos:~$ upower -d|grep percentage
<ogra_>     percentage:          41.4464%
<ogra_> ubuntu@nexus7-roccos:~
<ogra_> OH !
<ogra_> janimo, there is something wrong here
<NekoXP> 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?
 * ogra_ guesses thats ckings work
<janimo> ogra_, mine is not fully charged but either charging or discharging depending on whether the cable is plugged in or not
<janimo> ogra_, but probably a bug indeed
<ogra_> janimo, well, if you keep the cable plugged it should at some point go to 100%
<janimo> sure
<janimo> in a few hours I guess
<ogra_> and not think it is fully charged and report 41% :)
<janimo> 6.0 according to upower
<ogra_> and i'm pretty sure after more than 8h charging it should be at 100% it surely was with the former kernel
<ogra_> i think chraging it to 100% never took me more than 2h actually
<ogra_> so i guess cking has to revisit it :)
<janimo> any reason  I should not use xc compression on the kernel package (besides compressing it being sloow) ?
<janimo> infinity, ^ ?
<ogra_> bootspeed
<ogra_> oh, the package
<janimo> ogra_, the source package
<ogra_> not vmlinuz
 * ogra_ doesnt care
<janimo> ogra_, I am not sure whether build servers can handle it, whether it is all stable etc
<janimo> 60M vs 100M for the sourece tarball
<ogra_> well, someone has to try it anyway :)
<ogra_> i think we have some xz packages already though
<ogra_> and havent seen issues about it on arm
<ogra_> iirc xnox had a list in the xz packages session ;)
 * ogra_ remembers some font package
<ogra_> heh, so my percentage jups back and forth between 41.4464% and 41.4364%
<ogra_> doesnt move beyond that
<achiang> it's trying to converge to 42, of course
<infinity> janimo: We have lots of xz source packages, infrastructure all deals with it fine.
<ogra_> well, if it wouldnt go down to .4364 all the time i would tend to belive that
<infinity> janimo: It may take longer to decompress at build time, but meh.
<janimo> ogra_, it does converge on 42 but due to miscalibration you see the values shifted a bit
<ogra_> 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
<janimo> ogra_, having android dual boot now to see what it says would sure be handy
<janimo> are there sys files that can be read, do they say the same thing?
<ogra_> you wont find uppower in android :
<ogra_> :)
<ogra_>  /sys/devices/platform/tegra-i2c.4/i2c-4/4-0055/power_supply/battery/
<xnox> janimo: with source package - go ahead as much as you want =)
<janimo> xnox, alright :)
<xnox> janimo: ubiquity, libreoffice and emacs all do that ;-)
<janimo> ah, I'm in good company then
<infinity> libreoffice is hardly "good company".
<janimo> my sarcasm key ain't working
<ogra_> janimo, i'm pretty sure it is caused by d017332e756ba9294679c453431bf39507fd176e in our tree
<infinity> I thought that's what AltGr was for.
<infinity> Alternative Grin, or something.
<janimo> mine is remapped to Facebook Like
<ogra_> it wasnt like that in the -6 kernel
<janimo> ogra_, that is cking's patch to fix reporting
<infinity> janimo: Damnit, I nearly have a beverage->laptop incident, thanks.
<janimo> so maybe it had side effects
<ogra_> janimo, right
<infinity> s/have/had/
<janimo> infinity, I must try harder next time
<infinity> janimo: If you want to buy me a new laptop, carry on trying.
<ogra_> janimo, wait until you two are in a hangout together so you can record it
<xnox> ogra_: did you test flashing nexus7 with fs-utils now?
 * xnox is pondering if it's safe to flash my own nexus using those =)
<janimo> infinity, what model doth your heart desire?
<ogra_> xnox, no, and i want to back up my rootfs first ... soo many chganges i dont want to lose already
<infinity> janimo: A T430s to replace my T420s wouldn't hurt my feelings.
<ogra_> i'll keep that bit for tomorrow
<xnox> ogra_: interesting, how do I back it up?
<xnox> with fast boot?
<ogra_> xnox, i think ext2simg is a no go, the image is around 100M bigger than with make_ext4fs
<xnox> *sigh*
<ogra_> 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
<janimo> ogra_, maybe the mkfs part does things differently by not emulating what make_ext4fs does?
<ogra_> janimo, yeah, i think it compresses bits of the filesystem
<ogra_> *filesystem meta data
<janimo> does things that e2fsutils cannot do? That would be strange, but  I know too little about these tools
<ogra_> same here
<xnox> ogra_: was slangasek suggesting some other way of creating sparse images?
<ogra_> but slangasek asked me to look into the possibility to only use ext2simg and stick to our existing sparse img creation we already have
<xnox> at the closing plenery.
<ogra_> dd if=/dev/zero of=test.img bs=1M seek=6144 count=0
<ogra_> mkfs.ext4 test.img
<ogra_> then i loop mount and cp the tarball into it
<ogra_> and then: ext2simg test.img rootfs_test.img
<ogra_> thats largely the way we discussed (and the way debian-cd and friends etc use)
<xnox> ack.
<ogra_> ogra@anubis:~/Desktop/nexus/builder/tmp$ ls -lh rootfs_test.img
<ogra_> -rw-r--r-- 1 ogra ogra 783M Nov  7 18:43 rootfs_test.img
<ogra_> ogra@anubis:~/Desktop/nexus/builder/tmp$ make_ext4fs -l 6G -s rootfs.img mnt/
<ogra_> ....
<ogra_> ogra@anubis:~/Desktop/nexus/builder/tmp$ ls -lh rootfs.img
<ogra_> -rw-r--r-- 1 ogra ogra 646M Nov  7 18:44 rootfs.img
<ogra_> quite a size difference
<ogra_> content is identical
<ogra_> i suspect make_ext4fs does something like compressing the unused inode tables or so which fastboot uncompresses while flashing
<janimo> 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
<ngharo> Does anyone have a minimal nexus7 rootfs image floating around?
<ogra-nx7> janimo, thanks so much !
<ogra-nx7> ngharo, not to my knowledge
<NekoXP> I am having the weirdest experience here
<NekoXP> mkdir qm && mount /dev/sde2 qm && mount /dev/sde1 qm/boot && umount /dev/sde?
<NekoXP> the qm directory disappears
<NekoXP> unity is deleting it because it assumes if I mount it manually that it's the same as being in /media and being removed
<NekoXP> can anyone reproduce that quickly on something safe? I dunno if I found a bug or if I'm being a moron about something
<NekoXP> also this is precise and I can't get a quetzal running to test :D
<r0k5t4r> 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...
<mfisch> achiang & ssweeny: I'm picking this bug up: https://bugs.launchpad.net/ubuntu-nexus7/+bug/1071259
<ubot2> Launchpad bug 1071259 in ubuntu-nexus7 "Setting brightness all the way down actually switches off the display completely" [Medium,Confirmed]
<achiang> mfisch: cool, i'm assuming we're using the normal process of assigning to ourselves, etc.
<janimo> ogra_, see the 2.0 loadaverage happening above too^
<janimo> r0k5t4r, that is seen on the nexus7 as well
<janimo> with 12.10
<mfisch> achiang: yes
<r0k5t4r> janimo: ok, thought I'm the only one as others on the gooseberry forum didn't report this
<janimo> r0k5t4r, what kernel are you using?
<r0k5t4r> janimo: 3.0.36
<janimo> r0k5t4r, what source? Is there a goosberry kernel and you built it using Ubuntu's gcc?
<r0k5t4r> janimo: I downloaded the ubuntu image from someones dropbox account. there was a link on the gooseberry forum
<janimo> ok
<r0k5t4r> 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 :)
<r0k5t4r> janimo: brb
<AlanBell> r0k5t4r: oh?
<AlanBell> I suspect it is a coincidence, I am AlanBell in most places
<r0k5t4r> AlanBell: :) sorry
<AlanBell> thats fine :)
<AlanBell> what is the gooseberry forum?
<AlanBell> 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)
<AlanBell> play/break
<yofel> are there any howto's for making a VM with a nexus 7 environment in it?
<r0k5t4r> 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
<mfisch> yofel: why would you want to?
<mfisch> achiang: ping
<mfisch> yofel: it's just the standard ubuntu desktop on arm, minus thunderbird and open office
<achiang> mfisch: pong
<yofel> mfisch: well, I would prefer to have something where I could build packages in. Other than the actual tablet itself
<mfisch> 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
<mfisch> yofel: give me 5 mins and I can help
<yofel> sure :)
<mfisch> 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
<mfisch> achiang: I can take it to 0, which also implies that the brightness control has no hard stop at say, 1
<achiang> 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
<achiang> if we can't figure that out dynamically, then perhaps we should add a quirk system
<mfisch> 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
<mfisch> yep
<mfisch> yofel: have you used a pbuilder before?
<yofel> yes, I'm a kubuntu packager so I know that part
<yofel> I just have very little ARM experience
<mfisch> yofel: so we're recommending people just setup an armhf pbuilder
<mfisch> yofel: you can install pbuilder-scripts which came from Canonical and it will make life significantly easier
<mfisch> pcreate -a armhf -d quantal <pbuilder name>
<mfisch> and when that's done
<mfisch> ptest <pbuilder name> gives you a shell inside a qemu chroot
<mfisch> ptest -p <pbuiler name> ^^
<mfisch> writing up notes on pbuilder scripts is on the to do list
<yofel> pbuilder image is being created, thanks!
<mfisch> np
<mfisch> yofel: did I talk to you at UDS?
<mfisch> in the bar at the closing
<yofel> impossible, I wasn't there ;)
<mfisch> okay, I met the rest of your Kgang though
<yofel> heh
<achiang> mfisch: where's the pad re: memory debugging? i'll work on writing up the wiki page today
<mfisch> achiang: looking
<mfisch> achiang: http://summit.ubuntu.com/uds-r/meeting/21394/how-do-i-know-my-code-is-not-consuming-too-much-memory/
<achiang> thanks
<mfisch> achiang: does ARM have a sys firmware interface analogous to ACPI?
<achiang> not really
<achiang> there is device tree
<achiang> but i think that is more for topology
<achiang> acpi covers so many bases
<mfisch> what about SMBIOS/DMI?
<achiang> i don't know if device tree allows you to query for capabilities
<achiang> those are both x86 specs
<achiang> the best i've been able to find on ARM is lsusb
<mfisch> just wondered if there was an analog
<achiang> :-/
<mfisch> 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
<achiang> well the way sysfs works, any vendor can create any entry there
<achiang> so that may (or may not) be a standard interface
<achiang> it can be hard to tell
<achiang> where does bl_power live?
<achiang> full path
<mfisch>  /sys/class/backlight/<device>/
<mfisch> it's set to 0 on every device i've tried, I was hoping it would be useful
<mfisch> but I'm doubting it
<achiang> achiang@yew:~$ cat /sys/class/backlight/intel_backlight/bl_power
<achiang> 849009384
<achiang> achiang@yew:~$ cat /sys/class/backlight/acpi_video0/bl_power
<achiang> 0
<mfisch> interesting
<mfisch> I only have the acpi_video0 on my amd64 box, the 2 ARM devices have "pwm-backlight"
<mfisch> achiang: does bl_power change as you change the display brightness?
<achiang> nope
<mfisch> oddly if I set mine to 1, the display turns off
<mfisch> achiang: I found docs: http://www.mjmwired.net/kernel/Documentation/ABI/stable/sysfs-class-backlight
<achiang> ok, so /sys/class/backlight/acpi_video0/brightness echos the current status of my backlight
<mfisch> yep
<mfisch> and you can echo to it
<mfisch> my laptop goes from 0-20, the N7 is 0-255
<mfisch> the other ARM device is 0-7
<mfisch> achiang: squirrel this away in your notes: https://wiki.kubuntu.org/Kernel/Debugging/Backlight
<achiang> interesting but too x86 focused
<achiang> those are all acpi assumptions
<mfisch> yep
<NekoXP> bl_power is the on/off switch for backlight. the value is kind of meaningless
<NekoXP> 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.
<NekoXP> 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.. )
<NekoXP> what are you trying to do? :)
<mfisch> NekoXP: brightness 0 on the Nexus7 turns the display full off
<mfisch> NekoXP: which makes it challenging to get lit back up, unless you don't move your finger
<NekoXP> 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
<NekoXP> brightness 0 could mean anything to different backlight implementations, but what it usually means is the lowest possible PWM frequency
<mfisch> It seems of the devices I've tried that they have set 0 to be "still on" to avoid this
<NekoXP> 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
<NekoXP> 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.
<NekoXP> 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.
<NekoXP> that gives you varying levels of brightness, and the trick is not to have it flicker because of the fading
<NekoXP> 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.
<mfisch> ok
<NekoXP> 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
<mfisch> so that all makes sense
<NekoXP> 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
<mfisch> 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
<NekoXP> you shouldn't do that with just a request for brightness 0, even if it "feels" like it's doing that.
<NekoXP> on the N7 what's the driver called again?
<NekoXP> maybe pwm_bl or something? or tegra_pwm_bl? it's the name of the /sys/class/backlight/<thing>
<mfisch> pwm-backlight is what's in /sys/class/backlight
<NekoXP> okay so probably there is a control in the board support file platform data that supplies the frequencies, periods etc. it needs
<NekoXP> I need a copy of the N7 kernel.. hang on :D
<NekoXP> ah no, here it is
<NekoXP> drivers/video/backlight/pwm_bl.c:51
<NekoXP>         if (brightness == 0) {
<NekoXP>                 pwm_config(pb->pwm, 0, pb->period);
<NekoXP>                 pwm_disable(pb->pwm);
<NekoXP>         } else {
<NekoXP>                 brightness = pb->lth_brightness +
<NekoXP>                         (brightness * (pb->period - pb->lth_brightness) / max);
<NekoXP>                 pwm_config(pb->pwm, brightness, pb->period);
<NekoXP>                 pwm_enable(pb->pwm);
<NekoXP>         }
<NekoXP> ^^ this is so wrong I can't describe, but it does actually disable the pwm
<NekoXP> 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
<mfisch> NekoXP: what's in the board support file?
<NekoXP> period, brightness default, "top" brightness, max brightness value.. that kind of thing
<NekoXP> 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 :)
<NekoXP> there are two options.. one of which depends on kernel version
<NekoXP> 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
<NekoXP> 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
<NekoXP> 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
<NekoXP> 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.
<NekoXP> it's been updated to take it into account but it hacks it above those lines;
<NekoXP>         if (bl->props.power != FB_BLANK_UNBLANK)
<NekoXP>                 brightness = 0;
<NekoXP>         if (bl->props.fb_blank != FB_BLANK_UNBLANK)
<NekoXP>                 brightness = 0;
<NekoXP> this is wrong. it should deal with power off completely differently.
<NekoXP> lth_brightness should be involved here;
<NekoXP> I just saw a patch for DT kernels that adds this; https://lkml.org/lkml/2012/9/26/271
<NekoXP> brightness == 0 should be setting the low threshold brightness
<NekoXP> props.power or props.fb_blank should unconfig the pwm
<NekoXP> not a mishmash of the two
<NekoXP> 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
<NekoXP> 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
<NekoXP> y and set the correct brightness value (otherwise it would come back and it would be "off")
<mfisch> NekoXP: someone just called me, so hold on a sec
<NekoXP> http://pastebin.com/gYdPs0fV
<NekoXP> I didn't compile check it or even test it, but that might be a more favorable behavior
<NekoXP> 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...
<NekoXP> I'd need to fully test the userspace that goes with it to be sure what it tries to do
<NekoXP> but there's your start
<NekoXP> you would have to be sure lth_brightness is set somewhere though :]
<mfisch> NekoXP: I'll catch up in about 30 mins, long phone call then I'm stepping out for a bit
<NekoXP> I might be gone in 30 mins :]
<achiang> i think we should put a quirk in the kernel, not in userspace
 * mfisch catches up
<mfisch> achiang: do you know how to do that process?
<NekoXP> 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)
<NekoXP> the pwm_bl driver is dead to rights wrong in it's behavior so it needs fixing
<mfisch> ok
<mfisch> NekoXP: I'll give it a shot today or tomorrow
<mfisch> NekoXP: thanks
<NekoXP> 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 ;)
<NekoXP> 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
<NekoXP> be warned
<NekoXP> 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%
<mfisch> ok
<NekoXP> hopefully asus gave it a good value to start
<NekoXP> 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.
<NekoXP> I'm sure they're online somewhere.
<NekoXP> anyway I'm off home
<mfisch> ok
<NekoXP> have fun, I'm sure there are people around here who can help at some point
<mfisch> have a nice day
<cwayne> mfisch: ping
<mfisch> cwayne: yo
<cwayne> mfisch: isnt this fixed in our image? https://bugs.launchpad.net/ubuntu-nexus7/+bug/1055949
<ubot2> Launchpad bug 1055949 in unity (Ubuntu) "Unity panel shadow appears as solid black bar on GLES/ARM (Pandaboard, Nexus 7)" [Medium,Confirmed]
<mfisch> cwayne: I was going to ask you about that one
<cwayne> mfisch: afaik its fixed in ours, but not upstreamed yet.  I'm gonna mark it fix committed on our project
<mfisch> cwayne: is it in image?
<mfisch> cwayne: or in the public PPA?
<mfisch> if so mark it released
<cwayne> mfisch: in the image, may be in the ppa as well, let me check
<mfisch> and note when it was fixed "fixed in first release"
<mordicchio_> hello
<mfisch> hi
<mordicchio_> excume me can i ask you a question=
<mordicchio_> ?
<k1l_> mordicchio_: go ahead
<mordicchio_> i m searching a irc client for my raspberry pi
<mordicchio_> can you help me?
<k1l_> mordicchio_: see the topic :) better ask in #raspbian
<persia> With the emergence of our armhf environment, was the downgrading of the armel environment sufficient to run on a Pi?
<slangasek> 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
<persia> What's the rationale for d)?  c) is fixable in the meantime.
<slangasek> persia: the rationale for d) is that we have no rationale for not-d
<persia> So, lack of users?
<slangasek> armel was always intended to go away once armhf was on its feet
<slangasek> the armv5 rebuilt was a speculative repurposing for a contract that never panned out
<slangasek> s/rebuilt/rebuild/
<persia> 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)
<slangasek> right
<slangasek> rather, we want to host the buildds but want them to be armhf buildds ;)
<persia> I say that's effectively the same as saying there's a desire not to host armel buildds :)
<persia> In that case, I suppose I oughtn't push kirkwood kernels and migrate those devices to Ubuntu.
<slangasek> unless you want to stick with 12.10, probably not
 * 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
#ubuntu-arm 2012-11-08
<lilstevie> wow
<lilstevie> persia, haven't seen you around in ages
<persia> lilstevie: I had some administrative issues, now sorted.  Have you been well?
<lilstevie> yeah :)
<lilstevie> persia, I have the tf201 kernel building as a deb now :) finally got my way through setting that up
<persia> 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.
<persia> Err, raring.
 * persia pushes brain faster to catch up
<lilstevie> persia, well it is the same vintage as the n7
<lilstevie> both 3.1.10 nvidia kernels
<lilstevie> :p
 * persia worries more about userspace compatibility than version numbers
<persia> Is that kernel DT friendly enough that we could run one kernel with different DT files for both devices?
<lilstevie> persia, no
<persia> Oh well.  One can dream :)
<lilstevie> however it may be possible to enable both boards
<lilstevie> I don't have an n7 though, so I haven't checked out the machine id
<lilstevie> if it isn't cardhu then they may very well co-exist
<persia> I suspect there's someone else on the channel who might be able to dig up that information :)
<lilstevie> however there still is the issue of the dock keyboard driver
<lilstevie> that thing has infected many parts of the system
<persia> That's not implemented as USB or something else sane?
<lilstevie> Audio, Battery, and Board
<lilstevie> oh, it is i2c
<lilstevie> but they have functions injected all over the place
<persia> Oh, ugh.  That makes it ever so much trickier :(
<lilstevie> the core driver itself is fine, but the offload functions to other drivers
<lilstevie> things like the battery status get offloaded through special calls in the battery driver
<persia> That should really just be another pluggable battery, rather than so closely tied.  I suspect someone was in a hurry.
<lilstevie> 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
<TheMuso> Manufacturers are always in a hurry.
<lilstevie> it is a giant deps tangle
<TheMuso> And the nexus7 machine ID is grouper
<lilstevie> I tried to modularise some of that stuff, but it is just impossible due to how tied up they are
<persia> 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.
<lilstevie> TheMuso, right, silly me :p
<TheMuso> Right.
<lilstevie> persia, as it is this is all hacked over the top of the support for the cardhu development platform
<lilstevie> 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
<lilstevie> 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
<persia> I'm tight on time today, but I can probably look at it tomorrow.
<persia> I know there *will* be changes required, but I haven't seen publication of the new procedure yet.
<lilstevie> persia, oh no hurry
<persia> (so we can use the old one for now)
<lilstevie> the kernel itself is old (and poorly named)
<lilstevie> I need to start again for the new one cause of a different base
<persia> Heh.  Old kernel, old procedure, new kernel, new procedure :)
<lilstevie> that was what I was thinking
<mjrosenb> 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?
<persia> "dash" maybe?
<TheMuso> Thats part of unity. Depends on what version of Unity you are running.
<mjrosenb> TheMuso: how do I find that out?
<TheMuso> 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.
<mjrosenb> TheMuso: well, the issue is that the menu bar and other things are not worknig
<mjrosenb> *working
<mjrosenb> I have a context menu when I right click on the desktop
<mjrosenb> under gnome, i'd say that mean that nautilus was running
<persia> suckless-tools has some useful widgets to query the current set of represented X apps, which may help.
<mjrosenb> but I have no clue who handles that these days
<mjrosenb> it appears as if lightdm is in fact running.
<lilstevie> of course lightdm is running
<lilstevie> mjrosenb, if you kill lightdm it will take everything running in X with it
<persia> (assuming you haven't done any fancy process reparenting beforehand)
<lilstevie> well yeah
<mjrosenb> I just killed lightdm and restarted it, but still just the desktop.
<lilstevie> what is this on?
<mjrosenb> pandaboard
<mjrosenb> running 12.04
<persia> 12.04 does have nautilus providing the desktop
<mjrosenb> indeed, it does.
<mjrosenb> what does it have providing the upper bar with the time + some menus on it?
<mjrosenb> or the meta-key functionality?
<persia> 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)
<TheMuso> unity-panel-service
<TheMuso> Unity-panel-service doesn't actually do any of the rendering however.
<mjrosenb> ps aux | grep unity does not return anything
<mjrosenb> so presumably the backgronud service isn't running
<mjrosenb> unity-2d-panel: error while loading shared libraries: libgbm.so.1: cannot open shared object file: No such file or directory
<mjrosenb> oh.
<mjrosenb> http://pastebin.mozilla.org/1923408
<mjrosenb> interesting.
<mjrosenb> ok, making a symlink fixed the issue
<mjrosenb> but man that feels like a hack
<infinity> mjrosenb: Erm, that looks like a local libgdbm, rather than one from the archive...
<mjrosenb> infinity: it was installed with dpkg
<mjrosenb> is there a way to find out where it is getting the .deb from?
<mjrosenb> iirc, I have the omap overlay installed and nothing else?
<infinity> mjrosenb: 'apt-cache policy libgdbm1' might give you a hint.
<mjrosenb> and I have no clue where that information is stored, since the only things I have in sources.list are the ubuntu repos
<infinity> mjrosenb: Given that libgdbm1 doesn't actually exist in the Ubuntu archive, it's definitely not from us (nor is the thing that was linking to it)
<mjrosenb> this is gbm not gdbm.
<infinity> Oh, I can't read. :P
<mjrosenb> http://pastebin.mozilla.org/1923601
<mjrosenb> looks legit to me.
<mjrosenb> and http://pastebin.mozilla.org/1923602 for unity-2d-panel, which has a dep on libgbm.so.1
<infinity> mjrosenb: Right, that package came from the PPA, though.
<mjrosenb> oh.
<mjrosenb> so it did
 * mjrosenb has no clue what he's looking for.
<infinity> http://paste.ubuntu.com/1341643/ <-- The archive package.
<mjrosenb> perhaps downgrading to 8.0.4-0ubuntu0.2 would fix the problem?
<infinity> Version 8.0.4-0ubuntu0.2 is from Ubuntu.
<mjrosenb> well, I made a symlink, if that ever stops working, I'll downgrade.
<infinity> ndec: The mesa in your PPA for precise is busted.
<dholbach> good morning
<ogra_> janimo, for your ambient sensor, probably taking a look at https://android.googlesource.com/device/asus/grouper/+/7fce7d56cb077e869b9509cd2770d92e8cf29dcc/liblights/lights.c would be helpful :)
<janimo> ogra-nx7, yes I saw that
<ogra_> ah, k
<janimo> but first I wanted to see if it works at all on android, to get some dmesg or logger prints
<janimo> and it does not seem to work at all
<ogra_> i wonder if we should switch to the interactive power governor by default
<ogra_> seeing all these fine tuned bits in the android init scripts it feels like that would save us some power
<janimo> I may need to take a look some android ambient light apps from google play, maybe some extra twiddling that is not in default is required
<ogra_> well, theoretically you shouldnt need any userspace for it apart from some app to adjust it probably
<janimo> ogra_, no idea. Probably someone should try the same power tests (or others) victor did with various governors and then decide based on the numbers
<ogra_> yep
<ogra_> well, i bet victor would just do them, he already has a setup, but we would need to give him a kernel with ondemand disabled or help him to make sure ondemand doesnt get forced
<brendand> ogra_ - what's the correct way to make sure the N7 is up-to-date?
<ogra_> update-manager :)
<ogra_> we push updates to the PPA
<ogra_> just dont enable -security or -updates, they will trash your desktop
<brendand> ogra_ - that's what i was getting at. which ppa?
<ogra_> the ubuntu-nexus7 one, enabled in /etc/apt/sources.list.d ;)
<lilstevie> fwiw kinteractiveup spams dmesg a lot (interactive governor)
<ogra_> well, i guess you can quieten that
<ogra_> victorp, showing EULAs isnt really acceptable for a proper ubuntu image
<ogra_> victorp, i would prefer a proper solution rather
<victorp> ogra_,  what is a proper solution?
<victorp> ogra_ and why is it not acceptable?
<ogra_> victorp, licenses that dont require the user to click anything
<victorp> that is exactly what we do for the business desktop image available to download from Ubuntu.com
<victorp> ogra_, is not a license
<ogra_> if we really want to go down that rathole you need a) EULA support in usb-creator and b) all packages that ship any of the firmware will need it too (you can install an image, but yu could as well also install the single packages)
<victorp> it is just a note letting users know what is the ROM
 * victorp srugs
<ogra_> if the license then needs to be accepted *before* downloading that gets all kinds of complicated
<ogra_> sinbce we have no mechanism for that at all apart from doing something as ugly as the flash downloader package
<ogra_> (which cant work for i.e. network driver frimware)
<victorp> ogra_, I think you are assuming that this is an EULA and that people have to click on it
<victorp> we can't pass the license to the users
<ogra_> victorp, well, its some kind of popup people will have to agree to, no ?
<victorp> if says in the original license
<victorp> ...
<victorp> nope, it is just a notice saying this are the licenses in the rom
<victorp> you are not asked to agree to gplv3 every time you download ubuntu
<ogra_> still, if the license requires us to show it somehow all of the above applies
<victorp> we need to show a notice, yes
<ogra_> if the license doesnt require us to show it, lets just not show it :)
<victorp> does is not what our legal team suggest
<victorp> :)
<ogra_> right, so it needs to be shown by the packages as well as by the installer
<victorp> ogra_ I have a solution!!!
<victorp> we stick to the installer that we have now ;)
<ogra_> victorp, what does that solve
<victorp> ogra_ the packages that contain the firmware
<victorp> ogra_ j/k
<ogra_> you still need EULA popups in all the packages
<victorp> can you define all
<victorp> *all*?
<ogra_> which is massively messy and adds a lot of mainbtenance overhead
<ogra_> every package that ships any of the firmwares
<victorp> right, why dont you put them all in 1 package?
<ogra_> thats ugly but would work
<victorp> or dont put them in a package
<victorp> at all
<ogra_> how would you ship them properly then ?
<victorp> meaning that we could add the to the images, and put the notice in the installer
<ogra_> or apply any updates in case there is newer firmware that fixes issues
<victorp> but if someone wants to use a package per package they can get them from the google site
<victorp> mmm
<ogra_> generally we dont put any non packaged files into images
<victorp> ok - put them in 1 package then
<ogra_> there are exceptions but it would be good to not go with that
<victorp> I think that is ugly from one sense, cleaner from another
<victorp> 1 package + installers with notice?
<ogra_> well, it wont help any other devices with the same HW ... thats the issue
<victorp> WFM
<ogra_> i.e. the bcm4330 is a very common wlan chip
<ogra_> not really ubuntu :)
<ogra_> but yeah, would work for the device
<victorp> ogra_ you cant use those blobs in other devices
<ogra_> sure i can
<victorp> it is against the license of the blobs
<victorp> oh no you cant :)
<ogra_> i can use the bcm4330 blob for every bcm4330 welan card out there that works with the same kernel driver
<victorp> you can, and you can also get a call from the blob owners lawyers :)
<ogra_> wether thats legal by that specific license is another story indeed
<ogra_> talking about technical bnits here
<victorp> well.. now a days you can separate it
<victorp> what I mean is
<ogra_> the proper way to do what we want would be to contact the manufacturers and get proper licenses so ubuntu benefits as a whole
<victorp> do one package called nexus7-blobs-from-other-people
<victorp> that wfm
<victorp> and if is not useful for re-using in other devices
<victorp> even better as the license does not allow you to do that anyway
<victorp> :)
<ogra_> well, if the license says you cant use it on other devicews we cant make it available in the archive
<victorp> ogra_, If you give a list of the manufacturers , I can do that
<ogra_> i can for sure install nexus7-blobs-from-other-people on my ac100
<victorp> ogra_ why?
<ogra_> so i would break it
<victorp> yes
<victorp> but that is not how it works
<ogra_> the list should be at https://developers.google.com/android/nexus/drivers#grouper
<ogra_> this is how ubuntu works
<achiang> we have an ancient version of smem in quantal
<janimo> achiang, in raring I added the latest one
<achiang> janimo: ah great!
<janimo> achiang, we won't do much quantal profiling I guess?
<achiang> no
<achiang> janimo: wonder if it should go into debian though
<janimo> achiang, well 1.2 I got an hour after filing a bug in Debian :) The new bugfix I still have to upstream
<achiang> janimo: awesome, you are a step ahead of me
<achiang> thanks
<janimo> achiang, well I discovered smem while at the memory profiling session, remembering that top & co simply lie
<achiang> https://wiki.ubuntu.com/Nexus7/MeasuringMemoryUsage
<janimo> and added it to etherpad and then went on testing it
<achiang> i think we should write a tutorial
<achiang> or not even that, just usage
<janimo> well I am still in the figuring out phase, i.e don;t know much more than what the package manpage says
<achiang> no worries, not asking you to do it
<achiang> i'm just playing with it too
<janimo> what I want to do though is have a setup where we smemcap locally (this is missing in quantal) which is quick and then analyse on a more powerful machine
<janimo> it may use a setup similar to how the bootchart dailies are to be set up
 * ogra_ thinks that the nexus display even when setting the brightness to 1 is way to bright
<highvoltage> ogra_: I too find it quite amazing that these devices that consume a total of 5W of power can emit 50W worth of light from their panels
<ogra_> yeah, you can easily use the nexus as a torch at night
<ogra_> even with brightness set to 1
<mainerror> heh
<ogra_> oh sigh
 * ogra_ just looked at the plymouth issues
<ogra_> the bootloadert sets console=none ... we override that to console=tty1 in our boot options ...
<ogra_> plymouth sadly picks the first console= option from the cmdline and tries to connect to /dev/none
<ogra_> yay, chromebook
<dmart> ogra_: me too :)
<dmart> ogra_: /win 9
<highvoltage> ogra_: any inside news on when they'll be generally available? I'm burning to order one, just to use as a "nicer" pandaboard :)
<ogra_> highvoltage, i just bought mine at amazon.co.uk
<highvoltage> nice, and they still have!
<cwayne> mfisch: im thinkin mark this as wishlist, right? https://bugs.launchpad.net/ubuntu-nexus7/+bug/1076199
<ubot2> Launchpad bug 1076199 in ubuntu-nexus7 "Feature request for Dual Boot" [Undecided,New]
<ogra_> cwayne, wontfix rather :)
<cwayne> ogra_: lol, im gonna go with opinion / wishlist
<ogra_> if anyone from the community wants to figure it out and write a howto on the wiki thats fine, but we wont work on such a feature for the official images
<cwayne> right
<cwayne> ill comment that and mark opinion
<ogra_> ++
<highvoltage> ogra_: eek, it costs  more than $100 extra to order it from amazon.co.uk, I guess I'll wait until they have stock back in the US afterall then
<mfisch> cwayne: +1
<cwayne> mfisch: also just marked the gnome-shell bug wontfix with a comment explaining why
<mfisch> I can't wait to see the response
<cwayne> im excited
<cwayne> i wrote it as nicely as possible though :)
<cwayne> mfisch: hmm, what about this guy? https://bugs.launchpad.net/ubuntu-nexus7/+bug/1075565  I think that the screen dimming is normal when no clicks are being registered
<ubot2> Launchpad bug 1075565 in ubuntu-nexus7 "Auto dimming on brightness with spikes" [Undecided,New]
<ogra_> cwayne, m,y screen flashes quite a lot if the device is attached to power and in DPMS suspend mode
<ogra_> i assume at the same frequency that victorp sees
<cwayne> ogra_: his wasnt suspended, or plugged into power
<cwayne> my thinking is that he just happens to be logging the brightness after a click, when it is un-dimmed
<ogra_> oh, right, he tested battery time :)
<victorp> cwayne,  the spikes where on battery yes
<victorp> I was a sleep
<cwayne> victorp: right, i think what you're seeing is the normal auto-dim to save power
<victorp> so I didnt see it,but got logged on the test results
<victorp> cwayne,  ugh
<victorp> not normal that is resets every hour
<victorp> http://victorpalau.files.wordpress.com/2012/11/chart_11.png
<victorp> see grey line
<cwayne> victorp: i think it may just be getting that data after a click (when the brightness is brought back up)
<victorp> I dont think so
<victorp> I run it again later with 49
<victorp> sorry
<victorp> 40
<cwayne> 40 minutes between logging?
<victorp> and it did not spike because is below the level of auto dim
<cwayne> oh 40%
<victorp> 40 %
<cwayne> victorp: was 'dim screen to save power' on when you did it at 99?
<victorp> yes
<victorp> and it immediately went down to 99
<victorp> from 99
<victorp> to 76
<ogra_> victorp, btw, i would like to prepare some power mgmt settings for you stealing bits from the android defaults so we can check if they improve the system in any way beyond using ubuntu defaults
<ogra_> (after i got images up)
<victorp> ogra_, cool I can do that
 * ogra_ grumbles about plymouth 
<ogra_> silly software !
<ogra_> intrestingly i cant make the kernel crash anymore by removing all the override files
<ogra_> but i cant get a splash either because plymouth conncts to a non existing /dev/none
<ogra_> :P
<ogra_> i wonder what happens if i create a udev rule to link /dev/none to tty1
<janimo> infinity, can you please remove the nexus7 kernel from raring NEW? I just found it does not build in the PPA. thanks
<janimo> I agains assumed that if it builds in quantal it should in raring
<janimo> which si weird as gcc does not seem to be that different. (4.7.2-2 vs 4.7.2-5)
<ogra_> janimo, python2 vs 3 ?
<ogra_> Makefile:509: The path 'python' is not executable.
<ogra_> from your build log
<janimo> ogra_, it fails while compiling a c file though
<janimo> hmm
<janimo> ogra_, same in the previous build, but that warning is harmless (python)
<janimo> https://launchpadlibrarian.net/122192174/buildlog_ubuntu-quantal-armhf.linux-nexus7_3.1.10-7.11_BUILDING.txt.gz
<ogra_> well, yeah, it should just skip that bit gracefully
<janimo> maybe some extra Werror checks were added
<ogra_> you could just set do_tools = false for now
<cwayne> victorp: hey, how do i install that extension with your changes?  do i just drop that extension dir somewhere?
<victorp> cwayne,  branch into the nexus 7
<victorp> then open chromium
<victorp> go to extensions
<victorp> set it to developer mode
<victorp> that will give you an option to do "unpack extension"
<cwayne> victorp: ah, great, thank you
<victorp> click on that and will let pick a folder
<victorp> cwayne, let me know if that works
<cwayne> victorp: seems to, thanks
<cwayne> victorp: i'll get you some more results overnight tonight as well
<victorp> cwayne, cool
<ogra_> slangasek, another thing ... i played with make_ext2fs vs img2simg and ext2simg ... ext2simg produces about 100M bigger images than make_ext4fs, the latter apparently compresses the unused fs metadata or something along these lines so i think we should rather go with that
<ogra_> (we are constrained wrt image size by the system ram of the device, images need to stay around 680M)
<ogra_> (fastboot has an -S option to actually flash bigger images in chunks, but sadly thats not 100% reliable and sometimes you end up with a corrupted fs)
<achiang> ogra_: xnox: janimo: i'd like to get a sense of the WIs that need to be done before we can start producing dailies. i understand it as 1) kernel+fw bits uploaded into R, 2) cdimage infrastructure working (aka ext2simg, etc.) 3) usb-creator patches. anything else?
<ogra_> achiang, nope, thats largely it
<xnox> achiang: usb-creator should not block "production of dailies"
<ogra_> for *building* i dont even need the firmware
<janimo> achiang, yes. I am working on 1)
<achiang> xnox: well, "installation of dailies" :)
<ogra_> even an empty package would do for that
<ogra_> achiang, fastboot flash foo.img ;)
<xnox> I have packaged the utilities, and now will be flashing my nexus with them..... i hope i will not brick it =)
<achiang> oh, so continue using the nexus7-installer then?
<ogra_> usb-creator is really not important yet :)
<ogra_> well, its four fastboot commands, not really hard to do
<achiang> ok, so let's strike out #3
<janimo> I need to fix the kernel build with raring gcc
<slangasek> ogra_: right, I think it makes sense to stick with make_ext4fs for now in that case.  Would be good at some point to unpick why the fs is different (e.g., how does 'make_ext4fs+simg2img' differ from 'mkfs.ext4') and improve things
<ogra_> right, usb-creator will happen, but yioz can always install by just using fastboot
<achiang> in that case we just need to get cdimage.uc. building images, and we can patch nexus7-isstaller
<slangasek> or maybe it's how does 'make_ext4fs' differ from 'make_ext4fs+simg2img+img2simg'
<ogra_> yxeah
<xnox> slangasek: i'm getting cross-eyes from all the img2img2sigm2igm2sigm+
<ogra_> i also think i'll add the make_ext4fs part to livecd-rootfs/live-build instead of debian-cd
<ogra_> will make everything easier for everyone
 * ogra_ goes afk for a while
<janimo> hrw, do you usually follow gcc versions with the corresponding cross-gcc package or the releases are more or less independent?
<mfisch> janimo: is git clean -xdf going to remove my code and config changes in the kernel?
<achiang> cwayne: re: dual-boot bug, it would be nice to document why it's difficult, which is to say, you'd have to flash into the recovery partition, etc. etc.
<achiang> cwayne: can you track down the details of that and update the bug?
<cwayne> achiang: sure
<achiang> thanks
<achiang> cwayne: re: gnome-shell bug, we can do better. desrt has 2 upstream bugs enabling gnome-shell. can you track those down and link them in our bug report?
<achiang> cwayne: he's already opened the upstream bugs, so all you need to do is link them
<mfisch> cwayne: I've got some cycles while this builds, I'll do the gnome shell one
<infinity> janimo: You probably just want to drop do_tools until you sort it out (as I did for ac100).
<infinity> janimo: Rejecting for now, though.
<mfisch> achiang: re: desrt/gnome-shell: did you mean patches or bugs?  I dont see any upstream bugs that seem to fit
<achiang> mfisch: he filed bugs, that much i know. he *might* have attached patches too, not sure.
<achiang> mfisch: and they might already be closed, unknown to me...
<mfisch> hmm, I'll go search his lp bug list
<achiang> mfisch: i only have this knowledge from a 5 minute hallway conversation with him
<achiang> mfisch: upstream gnome bugs
<mfisch> ah
<cwayne> ogra_: ping
<victorp_> cwayne, have a look at this - https://wiki.ubuntu.com/Nexus7/BrowsingSimulation and please improve if you think anything is missing
<cwayne> victorp_: will do, i've got it running now just for some preliminary info
<victorp_> cool, the main thing is the extension really, rather than the script
<janimo> infinity, thanks. Was the issue the same for ac100? I did not even know about that
<cwayne> victorp_: yep.  did you set it to never turn the screen off when you ran overnight?
<janimo> infinity, I wonder if we could just copy the binaries from PPA to raring until we have a raring package. Would that be bad?
<infinity> janimo: Just upload with do_tools = false. :P
<janimo> infinity, ok I saw the recent ac100 fix in raring
<infinity> janimo: Copying from the PPA for a NEW package would still require the same review, so buys you nothing.
<mfisch> achiang: no joy in finding ryan's upstream bugs
<achiang> mfisch: did you just ask him? :)
<mfisch> achiang: he's not around, we will have to email
<achiang> yep, sorry for asking for the hoop jumping, but i think we should link those bugs
<mfisch> I did find a bunch of other upstreams that I linked
<mfisch> many of which predate our work
<mfisch> like rotation not working
<achiang> yeah, watching the mails come into my inbox now
<infinity> janimo: Once you have something that builds, I'll try to fasttrack reviewing it.  If the source is shockingly similar to ac100, it won't take too much effort.
<mfisch> achiang: the main difficulty on dual-boot is either hacking fastboot or switching to u-boot and then figuring out how to reflash the bootloader?
<achiang> mfisch: i'm fuzzy on the details, it was like, resize the userdata partition, flash over the recovery, then something in picking which userspace to boot
<mfisch> you'd have to manually enter the bootloader
<mfisch> that method is safer than messing with fastboot
<mfisch> cwayne: I forgot about that option ^^
 * cwayne didnt know about that option
<mfisch> so ubuntu would go into recovery
<cwayne> so like, booting into android you would just use the recovery partition?
<mfisch> not sure how userdata would get divided up
<cwayne> ah
<mfisch> cwayne: I've upstream linked the two bugs to the gnome-shell bug, are we re-opening it?
<mfisch> https://bugs.launchpad.net/gnome-session/+bug/1072509
<ubot2> Launchpad bug 1072509 in ubuntu-nexus7 "Gnome Shell/Classic is Unable To Provide Accelerated Experience" [Low,Won't fix]
<cwayne> mfisch: i suppose we can confirm it, but def leave it low
<mfisch> cwayne: done
<achiang> mfisch: cwayne: i don't think it needs to be open, just a pointer to the upstreams are ok
<achiang> imho
<achiang> but do what makes sense. :)
<mfisch> we can leave it open
<cwayne> we'll leave it open for now, and see what happens in those upstreams i suppose
 * cwayne is not seeing the auto-dimming on browsing yet
<mfisch> achiang: if we get the tegra3 bugs into good shape can you poke nvidia?  If so, I'd like to prioritize that effort
<achiang> mfisch: i've been, in the background
<achiang> mfisch: just ping me if you need help on specific bugs
<mfisch> achiang: okay, we'll get them into shape
<mfisch> cwayne: can we do a review of them after you finish up the current issue?
<cwayne> why was this marked as affecting nexus7?  it doesn't seem quite right https://bugs.launchpad.net/ubuntu-nexus7/+bug/974260
<ubot2> Launchpad bug 974260 in gnome-settings-daemon (Ubuntu) "Brightnes of laptop panel is set to minimum when system starts" [Medium,Confirmed]
<cwayne> mfisch: sure
<victorp_> cwayne, yes I did
<mfisch> cwayne: I duped the nexus7 one to that one
<victorp_> cwayne, not many users browse with their screens turn off :)
<mfisch> cwayne: the original: https://bugs.launchpad.net/ubuntu-nexus7/+bug/1075473
<cwayne> mfisch: it isnt minimal brightness though, else it'd be completely black
<ubot2> Launchpad bug 974260 in gnome-settings-daemon (Ubuntu) "duplicate for #1075473 Brightnes of laptop panel is set to minimum when system starts" [Medium,Confirmed]
<cwayne> victorp_: hah, true :)
<mfisch> cwayne: the bug is more that the system doesn't remember where you left the brightness setting after a reboot
<cwayne> mfisch: ah, okay
<cwayne> that makes more sense
<mfisch> cwayne: my laptop, for example, always starts at a blinding 100%
<cwayne> mfisch: right, ok
<cwayne> mfisch: wanna do a quick g+ and go over the tegra3 bugs?
<mfisch> cwayne: IRC, I'm at the library
<cwayne> mfisch: alright: https://bugs.launchpad.net/ubuntu-nexus7/+bugs?field.tag=tegra3
<achiang> fwiw, i expect we're finding normal usability bugs in core ubuntu that have simply been ignored forever
<achiang> good thing is, upstream can no longer hide from us :)
<cwayne> achiang: thats what it seems like to be honest
<cwayne> most if not all of these have an older bug that's been a bit ignored
<achiang> yep
<xnox> ogra_: mfisch: i have recreated the rootfs image using packaged fs-utils, and flashed my nexus7 and it did boot and everything is ok.
<xnox> ogra_: mfisch: I'm planning to upload them into the raring archive now.
<xnox> do I need to backport them back to quantal & precise? or is ppa sufficient for cdimage?
<mfisch> achiang: ^^?  I think raring was the goal
<achiang> xnox: no backport needed at all
<achiang> xnox: Raring or nothing!@
<xnox> ack =)
<xnox> uploading then.
<xnox> I think I will do a ppa and block for general public =)
<xnox> s/block/blog/
<achiang> xnox: curious... what ppa?
<xnox> achiang: a new one, unless there is one already.
<xnox> achiang: do we have one under ~ubuntu-nexus7 ?
<achiang> xnox: sorry, i mean, what would the ppa have?
<achiang> the fs-utils package?
<xnox> achiang: android-tools package patches to produce android-tools-fs-utils which has simg2simg, simg2img, img2simg, make_ext4fs
<xnox> yeah =)
<xnox> and ext2simg I think....
<mfisch> xnox: maybe our Nexus7 public PPA?
<xnox> mfisch: sure. Which one is that?
<achiang> xnox: https://launchpad.net/~ubuntu-nexus7/+archive/ubuntu-nexus7-installer
<mfisch> achiang: not that one
<achiang> ynot?
 * mfisch is thinking
<mfisch> I guess those are image build tools
<achiang> it should indeed be that one
<achiang> right
<mfisch> ok
<achiang> unless i misunderstand
<achiang> which is probably the case
<mfisch> xnox: let me add you to the group
<mfisch> ah, I lack the power
 * mfisch asks for the power
<achiang> xnox: can you apply for the ppa?
<mfisch> https://launchpad.net/~ubuntu-nexus7
<xnox> "Dmitrijs Ledkovs" (xnox) pending approval.
<achiang> xnox: gotcha, you're in
<xnox> thanks =)
<mfisch> xnox: ping me when those are available, I'd like to update my blog post and remove the bianries from people.canonical.com
<xnox> mfisch: ack.
<mfisch> achiang: I have a fix for the brightness issue
 * achiang adds a blurb about team membership to LP
<cwayne> mfisch: which one, the 0 one?
<mfisch> cwayne: ?
<cwayne> mfisch: which brightness issue do you have a fix for
<mfisch> cwayne: ah yes, that one
<mfisch> more testing first
<cwayne> anyone seeing the screen go black even when its not supposed to on the n7?
<[mbm]> nope; worked fine when I tried it
<[mbm]> screensaver? dpms?
<cwayne> [mbm]: hmm, not sure.  its disabled in brightness and lock, but that's all i did
<janimo> infinity, I did a reupload with tools disabled
<[mbm]> mfisch: there was some talk of using kexec for dual booting, although it should also be possible to place the ubuntu kernel on the recovery partition, at the expense of losing android recovery
<ogra-cb> [mbm]: well, there is more to do in the system itself, a kernel update would currently wipe your android kernel
<cwayne> ogra-cb: [mbm]: can we get these issues listed on the dual-boot bug?
<[mbm]> ogra-cb: the flash-kernel scripts would need to be tweaked
<ogra-cb> well, they would be overwritten with the next flash-kernel update
<ogra-cb> flash-kernel would need to learn to accept more than one bootdevice
<[mbm]> there's also the question of where to put the ubuntu root
<ogra-cb> which is a functionality that was just removed on purpose with the rewrite in debian
<cwayne> the bug is here btw: https://bugs.launchpad.net/ubuntu-nexus7/+bug/1076199
<ubot2> Launchpad bug 1076199 in ubuntu-nexus7 "Feature request for Dual Boot" [Wishlist,Opinion]
<[mbm]> thinking that the ubuntu root can just be a subdirectory of userdata, avoiding partitioning problems and free space segmentation
<ogra-cb> the ubuntu root currently is userdata
<ogra-cb> mmmcblk0p9 is /
<[mbm]> right, but you don't want to see android files in /
<ogra-cb> and we need to completely wipe it on install, else we get filesystem corruption over time
<ogra-cb> i.e. fastboot erase
<ogra-cb> (we had that issue)
<[mbm]> thinking of a ubuntu directory on p9
<ogra-cb> well, then you will need to provide a modified image
<[mbm]> combination of mount -o bind and pivot_root can be used in a similar manner to chroot
<ogra-cb> the default image will wipe and use the full partition
<[mbm]> right, the current install clobbers android
<ogra-cb> cant android get along with that ?
<[mbm]> well, android mounts userdata as /data and then makes various directories like /data/data, /data/app, /data/system ..
<ogra-cb> ah, right
<[mbm]> you don't want those directories showing up in ubuntu attached to /
<[mbm]> and it's easily avoided with a few initrd tweaks in ubuntu
<ogra-cb> well, dual boot isnt our focus, our focus is to get the cleanest ubuntu install possible onto teh device in the given situation
<ogra-cb> we wont hack teh initrd nor change teh image design, so if you want dual boot, either get it working with the image as is (happy to accept patches to flash-kernel if they are proper) or roll a modified image
<[mbm]> installation could be a debootstrap from an adb while running android
<[mbm]> some packages to handle the dual boot config changes
<[mbm]> no worse than the existing -nexus7 packages
<ogra-cb> they will go awaty mostly
<ogra-cb> *away
<ogra-cb> hrw: did you actually use teh chromebook with chromeos before installing ubuntu ?
<ogra-cb> feels really weird if your world is restricted to a browser window
<[mbm]> how dors the nexus7 handle partitions? is there a gpt or is it just hardcoded?
<ogra-cb> i think its a gpt hardcoded in the bootloader
<ogra-cb> we dont touch the partitioning
<ogra-cb> hmpf
<ogra-cb> that webchat thingie is unstable
<[mbm]> dual booting would be cleanest with u-boot and a new set of partitions, but that just wastes space
<ogra-cb> ojn: seems clicking inside flash on teh chromebook only works sometimes, is that a known bug ?
<ojn> ogra-cb: under chrome os?
<ojn> It's not something I have noticed myself
<mfisch> NekoXP: so I fixed the issue, but I didn't need your patch, your note about brightness of 13 was spot-on
<mfisch> NekoXP: http://paste.ubuntu.com/1343515/
<ogra-cb> ojn: well, not a single game works for me, in some videos i have play/pause but cant go fullscreen
<ojn> ogra-cb: hm, odd. Let me check here.
<ogra-cb> youtube works though
<ogra-cb> including fullscreen
<ojn> youtube might be html5 and not flash though (in some cases)
<ogra-cb> ah, indeed
<ogra-cb> ojn: try www.myvideo.de (if you can, not sure they block foreign countries) i can play/pause but none of the bottom controls work
<ojn> vimeo works for me, i can switch to full-screen without problems
<ojn> it's slow due to no codec offload with their player though
<ojn> ok one sec
<ogra-cb> (works fine on x86)
<ojn> Sorry! Dieses Video darf in deinem Land nicht angezeigt werden.
<ojn> BUT
<ojn> I can make the commercial go full screen and adjust the volume on it
<ogra-cb> weird
<ojn> what's your chrome os version (from about:chrome)?
<ogra-cb> 23.0.1271.83
<ogra-cb> i see a green checkmark
<ojn> I'm on .84
<ojn> but I'm on dev-channel, not stable or beta
<ogra-cb> and it actually did an upgrade before i could log in
<ojn> I don't think there were any flash fixes between the two anyway
<ogra-cb> very strange
<ojn> yes, that's quite odd
<ojn> I can ask my coworkers when I am back in California next week, if you still see it
<ojn> it's not something silly like a stuck alt/ctrl key or the like?
<mfisch> for youtube you need to go to http://youtube.com/html5 and enable the Html5 beta
<ogra-cb> k, not sure i'll keep using chromeos tthough
<ogra-cb> but i definitely wont wipe it so i can go back for verifying etc
<ojn> mfisch: I think it turns on by default from chromebooks
<ojn> ogra-cb: ok
<ogra-cb> i
<ogra-cb> i'll surely go on using it for a few days though
 * ogra-cb is actually intrested if he can get used to live in a browser only
<ojn> the last bit for me was an irc client, and I got that through irccloud.com now. Browser + terminal window for SSH access is all I really need
<ogra-cb> oh, wait !
 * ogra-cb uses teh touchscreen extension on teh nexus, seems that was copied over to this setup
<ojn> Oh! that'd do it
<ogra-cb> yeah, switching it off makes it work
<ogra-cb> heh
<ojn> phew
<ojn> ok, calling it a day here
<ojn> lots of crap to take care of tomorrow before going back to the us. :)
<ogra-cb> good luck with that
<ogra-cb> and a safe flight
<ojn> tnx
<[mbm]>  touchscreen on the nexus is buggy
<[mbm]> in some ways it'd make more sense to run the touchscreen in relative mode
<[mbm]> treat the entire surface like a laptop touchpad
<yofel> does someone know how to debug a segfault in a armhf pbuilder (qemu)? I'm obviously doing something wrong: http://paste.kde.org/600374
<angs> I have ubuntu-server on my beagleboard-xm. I would like to do remote-debugging. what package do I need to install on my host machine (ubuntu 12.04) to have the toolchains ?
<angs> apt-get install build-essential?
<NekoXP> mfisch, excellent.. 13 is actually just 12.5% rounded up, btw ;)
<hrw> janimo: cross toolchain gets updates ~monthly
<hrw> janimo: raring one next week I hope - have some build problems which I did not had time to check during conferences
<hrw> ogra-cb: I used chromium os before switching to raring
<hrw> ogra-cb: check my G+ to get link to ppa with newer alsa-lib packages to get ucm profiles for chromebook
<hrw> ogra-cb: x11 driver will follow but not sure if it will be tomorrow or next week
<TheMuso> hrw: Please send those ucm profiles my way so I can include them in raring.,
<TheMuso> hrw: Alternatively, where can I find your PPA?
<persia> TheMuso: Looks to be https://launchpad.net/~hrw/+archive/my-own-packages/+files/alsa-lib_1.0.25-4ubuntu2.dsc
<infinity> hrw: Will your updated cross toolchain include an arm64 one too?
<TheMuso> persia: Thanks, will grab those and get them into raring.
<ogra-cb> hrw: did you already try to fish out the flash plugin from the chrome partition ?
<ogra-cb> i suppose it could work for us
<achiang> ogra-cb: ooh, would that enable g+ hangouts?
<ogra-cb> not auew, but hangouts definitely work fine under chromeos
<achiang> hm... maybe they are not using flash anyway
<ogra-cb> s/auew/sure
<ogra-cb> right, i think its a separate plugin
<achiang> i had a flashblocker for a while, and hangouts still worked
<ogra-cb> but chromeos is armhf so all binaries should kind of work
<achiang> something else in the ars technica review convinced me to not get this chromebook yet
<ogra-cb> what was that ?
<achiang> oh maybe it was the screen
<achiang> or the fact that it's *still* thicker than a mac air! :)
<ogra-cb> well, its fine for 720p movies ... surely not as impressive as the nexus screen though
<ogra-cb> and yeah, the clamshell feels a bit cheap
<achiang> the fact that they shipped without getting hdmi working is... lame
<ogra-cb> the kbd is great though
<ogra-cb> it really cant cope with the ac100 frtom a coolness POV but the cpu and ram balance that out a bit :)
<achiang> ac100 still cooler?
<ogra-cb> lighter, slimmer, i like the kbd a bit better and with teh upgraded screen it can easily cope with this one
<ogra-cb> but its a tegra2 and only has 512M
<achiang> once ogra-cb confirms hangouts work in ubuntu... i'll consider it. :)
<ogra-cb> haha
<ogra-cb> hrm, this web irc client is odd, it doesnt auto-scroll
<ogra-cb> but i'll go afk now anyway
#ubuntu-arm 2012-11-09
<cwayne> mfisch: what are your thoughts on this bug?https://bugs.launchpad.net/ubuntu-nexus7/+bug/1076793
<ubot2> Launchpad bug 1076793 in ubuntu-nexus7 "Bad multicore performance" [Undecided,New]
<mfisch> cwayne: unsure really
<mfisch> cwayne: I'm about eod, lets check it out tomorrow
<mfisch> cwayne: I guess we should repro it
<mfisch> I'd like to know how it works on a multicore x86 box too
<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
<infinity> lilstevie: Turn all the Android partitions into one big LVM volume?  I think I suggested that to Oliver a couple of weeks ago. ;)
<lilstevie> infinity, well that too, I started with just UDA
<lilstevie> but lately yeah, the whole damn lot
<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.
<lilstevie> you need nvflash for that
<infinity> Indeed I did, yes.
<lilstevie> and the nexus 7 is ODM secure
<lilstevie> and our nvflash stuff doesn't work with it
<lilstevie> not to mention I don't think canonical could endorse such hackery
 * persia considers mobiln-image-creator and smirks
<lilstevie> lol
<lilstevie> persia, do you have time at the moment?
<lilstevie> also hi
<lilstevie> :p
<persia> Some, not lots.
<lilstevie> heh ok
<lilstevie> repo.lilstevie.geek.nz is where that kernel is if you get some time to have  a look
<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)
<lilstevie> that's ok, you probably wouldn't have reached me
<lilstevie> I didn't get up until 10am and it is only 1pm now
<persia> What did you have to change in casper?
<lilstevie> TheMuso changed something, I think he pushed that for quantal though
<persia> Yeah, but I had more time when you got up than I do now :)
<lilstevie> it was something to do with not looking at any storage on the usb bus for the tf201
<persia> Anyway, unless something comes up, I should be able to look at it in ~6 hours.
<lilstevie> ok cool :)
<lilstevie> anyway with some minor work, the new kernel should support the entire tegra3 transformer range
<mjrosenb> sweet, my chromebook is now running ubuntu!
<mjrosenb> ok, does anyone know how software for ubuntu/arm (e.g. firefox) is built?
<mjrosenb> is it cross-compiled, or just built nativelty?
<TheMuso> mjrosenb: Everything that ships with Ubuntu on Arm is built natively.
<mjrosenb> ow
<mjrosenb> I tried building firefox on a pandaboard last night
<TheMuso> Took a while eh?
<mjrosenb> and the linking phase killed it
<lilstevie> use that shiny new a15
<TheMuso> ...or lots and lots and lots and lots of swap.
 * achiang would be interested in seeing chrubuntu build performance
 * lilstevie too
<achiang> dual a15, 2gb ram... and using usb3 for IO
<mjrosenb> yeah, I think my pandaboard has 1G ram + 512m swap
 * achiang nominates mjrosenb to do some tests. :)
<mjrosenb> I should give it some more swap
<TheMuso> Yep, try a lot more swap.
<lilstevie> building on my quad a9, 1gb ram with slow mmc is a bit more decent but that a15 should kill it
<mjrosenb> achiang: oh, its internal hard disk uses usb3.0?
<TheMuso> No, it usees MMC internally.
<TheMuso> At least afaik.
<achiang> mjrosenb: oh, no. cr-book has an external usb3 port
<achiang> internal mmc
<mjrosenb> yeah, something or other is showing up as an sdcard
<achiang> that's the mmc
<mjrosenb> sadly, / is *quite* small
<hrw> ogra_: ignored flash. hangouts are handled by plugin (not tried extracting)
<achiang> the ubuntu buildds use external USB disks
<mjrosenb> you know if the mmc is user-replacable?
<hrw> TheMuso: that ppa which persia mentioned is with ucm profile.
 * mjrosenb does not have any external usb disks available, but I do have a nice 32g sd card
<mjrosenb> (that I need to find)
<achiang> hrw: i'd be interested if you were able to figure out the hangout plugin. that's my blocker for getting a chromebook. :)
<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
<persia> hrw: How easier to update?
<hrw> achiang: hdmi output works fine
<achiang> hrw: sorry, i don't understand? how is hdmi related to google hangouts?
<lilstevie> hrw, moving the ucm profiles to a separate package would also make tweaking for devices with similar codecs easier
<persia> lilstevie: Why?
<lilstevie> persia, smaller, more portable package?
<persia> lilstevie: more boilerplate documentation bloating deployed images
<lilstevie> hm
<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.
<persia> It's only if one falls into the trap of believing in maintainers and maintainer lock that it could be an issue.
<hrw> 23:55 < achiang> the fact that they shipped without getting hdmi working is... lame
<achiang> hrw: oh, you're processing old scrollback. :)
<hrw> persia: and ucm profiles are ubuntu delta
<hrw> achiang: yes, I do
<persia> hrw: That makes it even simpler: they just drop in local VCS, and get deployed.
<hrw> achiang: its 6:45 here
<achiang> nod
<achiang> 2146 here
<lilstevie> 1646 here :p
<mjrosenb> 47 here
<lilstevie> just 47?
 * persia refutes the concept of timezones, and claims it to be 8:17, based on time since becoming awake.
<hrw> persia: my plan is to get all chromebook related to debian rather then ubuntu
<mjrosenb> well, 0047 if you want to zero pad it
<lilstevie> persia, heh
<persia> hrw: I like that plan.  How does Debian deploy ucm today?
<hrw> and chromebook can fry speakers when wrong switches are enabled in alsa mixer
<hrw> persia: so far not found any
<persia> Frying speakers is good: some hardware actually melts.
<lilstevie> hrw, ouch, that seems like..... a very poor design decision
<persia> hrw: Have you asked #debian-arm@OFTC?
<hrw> persia: conferences does not help too much to make real work
<persia> hrw: I totally understand (hence you not seeing me last week)
<persia> Err, this last week.
<hrw> but today I start few days of vacations in 'still not so cold' Spain
<persia> Heh.  Enjoy the last breath of summer.
<hrw> if 11Â°C counts as summer ;d
<hrw> lilstevie: I have a feeling that chromebook was released in a rush when I use it
<lilstevie> hrw, probably, like everything is these days
<hrw> alsa mixer without restrictions, power usage during suspend-to-ram
<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.
<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.
<hrw> yep
<achiang> persia: hm, i'm not planning on doing anything with chromebooks. :)
<persia> achiang: Yes, but such extra stuff would be on *all* rootfs constructions, which increases the footprint requirements for every install.
<persia> And I thought I remembered you wanting smaller footprints from UDS: my apologies if I'm mistaken.
<achiang> ah, yes. sorry, that is still definitely true
<TheMuso> hrw, persia, I asked the alsa guys fi they wanted to carry the ucm stuff and I was told no.
<TheMuso> And really, it is trivial to carry them.
<persia> TheMuso: Do you think it's better to carry them as a distro-patch, or a separate package?
<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.
 * persia is in favour of the distro-patch model
<TheMuso> Me too, only because they are so easy to carry.
<TheMuso> If they were hell to patch in, I'd be pushing for a separate package, but since they are only text files...
<persia> TheMuso: Have you had any discussions with Debian ALSA folk about them?
<TheMuso> persia: As aboev, I asked if debian wanted to carry, and afaicr they said no.
<TheMuso> above*
<persia> Sorry: I read the above as the ALSA project, rather than Debian.  I understand now.
<TheMuso> But this stuff is really alsa upstream stuff.
<TheMuso> I need to check the archives to see if any previous discussion was held about sed topic.
<persia> I thought UCM was originally done by ALSA upstream folk, but maybe there's still discussions ongoing there.
<TheMuso> Well they don't appear to carry any ucm files from what I've seen in git.
<hrw> persia: UCM was rather ASoC guys stuff
<hrw> Liam G., Mark Brown etc
<persia> hrw: Ah, right.  I get asoc confused with ALSA sometimes.
<hrw> I still remember discussion from Openmoko times about that stuff
<TheMuso> It maybe ASOC but its still part of ALSA.
<TheMuso> Ok this is weird. In /proc/asound/cards on the nexus7, I see an HDA driver loaded for NVIDIA Tegra HDA...
<persia> Hrm?  I would have expected tegra-alc5632
<lilstevie> that isn't totally odd
<lilstevie> same thing on the tf201
<TheMuso> Sure, there is an rt5xxx card, and the one I mentioned above.
<TheMuso> rt5640 to be exact.
<TheMuso> Oh its for HDMI.
<persia> Interesting: are there actually two different audio interfaces in hardware, both connected to the same speakers/
<TheMuso> Which is absolutely crazy, given no HDMI out on the Nexus.
<lilstevie> with the tf201 I get HDA NVIDIA Tegra and tegra-codec
<lilstevie> TheMuso, I think it is actually integrated into the SoC
<persia> Does it not have some sort of dock connector, which maybe carries underdocumented HDMI?
<TheMuso> lilstevie: As above, I suspect the second HDA based one is for HDMI.
<TheMuso> Mini USB only for the nexus7 afaik.
<TheMuso> Or micro USB whatever its called.
<lilstevie> the SoC itself supports HDMI
<persia> Silly hardware manufacturers: save money by not exposing ports, limiting functionality.
<lilstevie> it has 2 outputs
<TheMuso> lilstevie: Yeah afaik you can still have an hda codec as part of the SOC.
<lilstevie> LVDS and HDMI
<lilstevie> I haven't looked at the block diagram but you will probably find the HDA codec is somewhere in that
<lilstevie> I know there is something similar with the Tegra 2
<TheMuso> lsmod shows snd-hda-codec-hdmi loaded on the n7.
<TheMuso> From what I read aon achiang's blog, a new kernel si coming that will disable athat though.
<lilstevie> yeah, on the trimslice it has tegra-trimslice-analog and tegra-trimslice-digital
<persia> A new kernel isn't the right way to do that: it just pushes us further down the path of device-specific kernels.
<lilstevie> I really need a microhdmi cable to test hdmi out with the tf201
<TheMuso> Yeah but I am surprised they used HDA for HDMI... but it does make sense.
<persia> Better would be to have a framework that lets us blacklist modules based on device name.
<lilstevie> persia, yeah, the tf201 kernel needs a crapload of work before that will become an option though
<TheMuso> They already have to do the legwork for their desktop hardware, so why not incldue it in the SoC.
<persia> lilstevie: Lots of them do, but I still think we want SoC-specific kernels in Ubuntu if we can.
<persia> I'd like ISA-specific kernels, or even architecture-specific kernels, but those are significantly harder targets.
<lilstevie> persia, I agree, an SoC specific kernel would take a crapload of stress off me with tf201 stuff
<TheMuso> In other news, GNOME shell appears not to work on the Nexus 7, I get GNOME fallback.
<hrw> microhdmi... I got one yesterday. in a box with some Atom based device
<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.
<lilstevie> but at this stage it just isn't possible, stupid kernel cross contamination crap asus have done
<persia> lilstevie: tf201-not-possible, or tegra-not-possible?
<lilstevie> persia, tegra3 transformer not possible
<lilstevie> persia, the best I can probably do is all the tegra 3 transformers into 1 kernel
<persia> That's a huge step forward though.
<lilstevie> yeah, well thankfully the tf201 tf300t and tf700 are very similar devices
<lilstevie> and asus have left much of the code for the other devices in the latest kernel
<hrw> have a nice day guys. I go for vacations
<lilstevie> I still need to do a bit more research into what is missing
<persia> Good for them.
<lilstevie> hrw, have fun
<lilstevie> persia, likely situation is they build for all 3 devices from the same tree
<persia> lilstevie: They just need to be convinced to only maintain one kernel.  You don't happen to know folk there, do you?
<lilstevie> persia, asus don't like us very much
<lilstevie> and I suspect since July they would be even less likely to open dialogue with me
<TheMuso> /c/c
<persia> lilstevie: Oh well.
<lilstevie> persia, yeah, we kinda really broke their platform :)
<lilstevie> I don't think nvidia would like talking to us either
<lilstevie> persia, not that that matters anyway, I have in the past tried to open communication with them and got ignored
<achiang> TheMuso: we have bugs for gnome-shell
<mjrosenb> major annoyance #1 about the chromebook
<mjrosenb> the power button is evidently right where I expect pageupu to be
<mjrosenb> also, it doesn't have a page up
<persia> Mapping to Search-UpArrow probably makes sense.  That keyboard should have had a function key.
<dholbach> good morning
<mjrosenb> dholbach: morning.
<mjrosenb> hey, is there a TI guy in here?
<mjrosenb> I remember I had an issue with a TI provided library, and someone was pinged
<mjrosenb> but I no longer remember who it was.
<persia> Do you remember which issue?
<mjrosenb> persia: yes, various parts of unity didn't work because libgbm shipped via the omap ppa had the wrong version number.
<persia> Just to confirm, this is likely a mesa issue?
<mjrosenb> yeah.
<persia> Then the person you seek is likely ndec (at least according to my backscroll)
<mjrosenb> persia: ahh, yes.  I remember it was a short name
<mjrosenb> *remembered
<mjrosenb> ndec: ping?
<mjrosenb> also, it took me 17 minutes to build the spidermonkey shell
 * mjrosenb tries on the pandaboard
<ogra_> janimo, did you ping any archive admin about the kernel upload yet ?
<ogra_> still in NEW
<ogra_> heh
 * ogra_ sees an armhf package for fastboot ... so i should be able to flash my nexus from my ac100 or chromebook now
<janimo> ogra_, I told infinity yesterday
<ogra_> k
<janimo> ogra_, would the x86 one not run under qemu?
<ogra_> i dont think we have a qemu i386 on arm
<persia> There used to be one: was it disabled?
<ogra_> iirc i looked at that for last UDS
<ogra_> persia, a system one probably
<persia> user-mode also, at least at DebConf11, but that was a while ago now.
<ogra_> for which you would need to run a full VM ... which in turn would eat all my RAM :)
<persia> Get more RAM then (and if it's all soldered, go complain to your manufacturer)
<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
<ogra_> persia, well, i fixed that ram issue on the ac100
<persia> How?
<ogra_> by buying a chromebook :)
 * persia fails to see how that fixed the ac100
<ogra_> heh
<lilstevie> lol
<xnox> mfisch: android-tools are built and published in the ppa:ubuntu-nexus7/ubuntu-nexus7-installer, you can update your blog post =))))
<victorp> ogra_, I am doing some video test, the nexus7 is really struggling with 720p ogg movie
<ogra_> i havent tried ogg yet, but that might well be, i doubt there is an ogg omx plugin
<ogra_> it works fine with h264 mp4 files, at lest it did at aome point for me
<ogra_> i.e HD movbie trailers
<victorp> ogra_, I will try that
<victorp> ogra_, different question
<ogra_> http://www.dvdloc8.com/list_clip.php
<ogra_> there you should be able to find some h264 HD movie trailersa
<ogra_> livecd-rootfs (2.94) raring; urgency=low
<ogra_>   * add a dependency on android-tools-fsutils for armhf builds
<ogra_>   * add nexus7 live-build configuration
<ogra_>   * add nexus7 post processing with make_ext4fs for teh tarball to roll a
<ogra_>     proper android img file
<ogra_> there we go :)
<ogra_> oh i hate if i typo changelog entries, damned
<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?
<victorp> ogra_, hehe
<victorp> ogra_, I am using big buck bunny
<victorp> much nicer ;)
<victorp> anyway I logged a bug for ogg
<victorp> is there a way to pull in latest decoders that might speed it up?
<ogra_> angs, apt-get install gcc-arm-linux-gnueabihf
<ogra_> angs, trhats the cross compiler
<ogra_> angs, http://marcin.juszkiewicz.com.pl/2012/03/26/ubuntu-12-04-precise-and-cross-compilation-of-arm-kernels/
<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
<hrw> ogra_: iirc at uds there was deiscussion to take all linaro crosscomplation pages and make finally some docs for ubuntu ;)
<ogra_> hrw, yeah, but its not done yet
<angs> ogra_: thank you very much
<victorp> ogra_, I am transform it to mp4 h264 and does not playwell
<victorp> do you use totem?
<ogra_> transform ?
<ogra_> yes, you have to
<victorp> using vlc in my pc
<ogra_> or any othert gstreamer based player
<ogra_> the nvidia codecs are only available for gstreamer
<victorp> totem plays the mp4 well in my laptop but like an old TV in the nexus 7
<victorp> colour all messed up
<ogra_> well, use a proper mp4 not something you manually transcoded
<ogra_> i have the simpsons trailer here from the page above
<ogra_> and that plays fine
<ogra_> some audio lag sometimes but i blame pulse for that
<dholbach> hum, do we advise nexus7 users to upgrade? http://www.mattfischer.com/blog/?p=298
<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
<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
<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
<ogra_> dholbach, well, -updates and -security are disabled by default (on purpose) but fixes that go to the PPA should be updated, yes
<dholbach> ogra_, ah ok
<ogra_> brendand_, yeah, for kernels using DT that could server as a dim like tool
<ogra_> *dmi
<ogra_> brendand_, sadly only very few kernels have DT yet
<brendand_> ogra_, does the n7?
<ogra_> no
<brendand_> ogra_, can it/will it?
<ogra_> if you find someone to port it :)
<ogra_> there are no plans to port the current kernel anywhere on our side beyond adding fixes to make the HW work better
<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
<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
<ogra_> right
<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
<ogra_> i was working on a lshw fix for that before releaase
<ogra_> seems it has the dmi check hardcoded as the very first test
<ogra_> (but there is an option to override that, i was planning to make that a default on arm builds of lshw)
<ogra_> ... but didnt manage to finish that bit yet
<ogra_> memory should really not be pulled from DMI anyway, you want it from /proc/meminfo
<brendand_> ogra_, /proc/meminfo is what the kernel sees, right?
<ogra_> yep
<ogra_> dmi is what the BIOS sees
<ogra_> but arm systems are usually BIOS less
<brendand_> ogra_, exactly. they should match up after allowing for UMA, right?
<ogra_> well, the bios data usually only tells you about the RAM modules used etc
<ogra_> while the values in proc show you the actual currently usable ram
<victorp> cwayne, I saw you raised some bugs on video. Did you get any HD video working?
<cwayne> victorp: i'm trying it again now.  i had gotten 720p working for a bit in copenhagen, but haven't tried since
<cwayne> will keep you updated
<victorp> cwayne, I have 720p ogg working but is very very choppy
<victorp> http://www.bigbuckbunny.org/index.php/download/
<victorp> ^^
<cwayne> victorp: yeah, i saw that, im downloading that file now to test
<victorp> but I tried mp4/h264 and I get lots of image corruption
<ogra_> in my tests before uploading the codecs package it just worked
<ogra_> using commercial 720p and 1080p trailers for testing
<victorp> ogra_, you wont have a link to the actual files?
<ogra_> not direct, i use them from the site i gave you above
<ogra_> http://www.dvdloc8.com/view_clip.php?movieid=12167
<ogra_> the 720p one should definitely be fine
<cwayne> ogra_: i think that's what i used in copenhagen and they seemed to work iirc
<ogra_> yup, same for me
<achiang> victorp: need to mute and unmute your video button in the indicator again ;)
 * cwayne tries again
<victorp> achiang, what?
<victorp> ogra_, downloading now...
 * achiang wonders if victorp knows what a snipe hunt is ...
<victorp> achiang, lol
 * cwayne tries out mfisch's kernel while waiting for sample videos to download
<mfisch> cwayne: great
<ogra_> janimo, CONFIG_USB_GADGET=m and CONFIG_USB_CDC_COMPOSITE=m
<janimo> ogra_, ack
<janimo> will add them in the next kernel upload
<ogra_> ++
<victorp> ogra_, it is not HD though 1280 x 544
<ogra_> victorp, its 720p
<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
<ogra_> victorp, the content is 1280 x 544 instead of 1280x720 because its a cinema (16:10) format though
<ogra_> the black stripes are in the movie as well :) that makes it 720p
<mfisch> cwayne: this new video from Blender is much more fun than Big Buck Bunny: http://www.tearsofsteel.org/
<victorp> ogra_, ha
<victorp> it is not HD is has only 544 horizontal lines
<victorp> 1280 x 544
<victorp> http://en.wikipedia.org/wiki/720p
<cwayne> mfisch: your kernel seems to work!
<mfisch> cwayne: great
<ogra_> victorp, how else would you display a 16:10 movie on a 16:9 display ?
<victorp> ogra_, I am just talking about how hard is making the hardware work
<ogra_> its 544 lines of content and 2x88 lines of black
<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
<ogra_> still 720p ;)
<cwayne> ssweeny: which brightness bug?
<ssweeny> cwayne, https://bugs.launchpad.net/ubuntu-nexus7/+bug/884041
<ubot2> Launchpad bug 884041 in ubuntu-nexus7 "Screen brightness not adjusted when switching from AC to battery" [High,Confirmed]
<mfisch> ssweeny: at the very least we need an upstream bug about the confusing wording
<ssweeny> mfisch, i think the wording is tangential to the bug as filed
<ssweeny> i'm going to file a bug with gnome anyway
<ssweeny> but i'm not sure it needs to be attached to this one
<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"
<victorp> anyway, I am sending it to the nexus7 and see if it plays without green shades
<cwayne> ssweeny: i think it could be attached
<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
<cwayne> and then won't fix'd for nexus7
<cwayne> ogra_: +1 i think we should only use totem for video testing for now
<ssweeny> cwayne, vg
<ssweeny> cwayne, i will trust your expert opinion :)
<cwayne> afaik, vlc brings in a lot of codecs, which is why we don't ship by default i believe
<ogra_> cwayne, right, or any other gstreamer based player (are there any ?!?) :)
<hggdh> I am getting checksum failed when downloading the new image
<ogra_> it can well be that there are still issues with the actual codecs indeed i only did some smoke testing before uploading
<ogra_> hmm, why is vanhoof not in this channel ?
<cwayne> hggdh: what if you clear out that directory (~/Downloads/UbuntuNexus7) and try again?
<victorp> ogra_, is playing extremely choppy
<victorp> cwayne, ^^
<hggdh> cwayne: on it
<cwayne> victorp: which one?  ogra_'s?  damn i need faster internet, mines still downloading
<ogra_> victorp, yeah, i fear your vnc installation might have trashed the setup
<hggdh> cwayne: a look on the dir shows the sha256 file with a date of Oct 26, not today... I wonder
<cwayne> hggdh: hmm, perhaps its not overwriting as it should... i believe vanhoof may have just fixed that
<victorp> cwayne, yes, ogra's
<victorp> ogra_, that is just random
<ogra_> well, it most likely does SW rendering
<ogra_> so once the queue is full it chops frames out
<victorp> and what does vlc have to do with that?
<ogra_> if you let htop run in a terminal window you should actually see one CPU maxed out if thats the case
<ogra_> the whole multimedia stack consists of multiple packages
<ogra_> vlc might have replaced one or the other through a dependency
<victorp> htop not in the image
<victorp> :(
<ogra_> apt-get install it :)
<victorp> I am just complaining that is not in the image ;)
<ogra_> we discussed pulling it into the desktop seed for ubuntu during UDS
<victorp> shouldnt this tools be pre-install on a dev image?
<ogra_> seems everyone is using it anyway and we should have the space
<ogra_> you have top
<ogra_> its just harder to read
<cwayne> fewer pretty  colors :)
<victorp> or we could have a meta packages that install all the debug tools
 * victorp like colors
<victorp> ogra_, cores are not maxed out
<ogra_> cwayne, well, the important part for me is always the total ram usage, nothing shows that as nicely as htop
<cwayne> ogra_: agreed
 * cwayne <3 htop
<ogra_> victorp, well, then it uses the omx libs apparently
<highvoltage> fun fact: htop actually starts up slightly faster than top
<victorp> it is with the ogg 720p
<victorp> for bbb
<hggdh> cwayne: OK. deleting the sha256 file and re-downloading all causes an Oct 26 sh256 file to be recreated -- and failure ensues
<cwayne> hggdh: ruh roh
<cwayne> vanhoof: ^^
<victorp> cwayne, let me know if you get the simpsons running well
<cwayne> victorp: ack.  just finished downloading
<achiang> ssweeny: you get an answer re: brightness? my opinion is that we have an opportunity to do better than upstream
<ssweeny> achiang, i can take a look at implementing something if you like
<cwayne> mine crashes at 9 seconds in victorp... weird
<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
<victorp> mine plays the second time but not the first
<victorp>  :)
<ssweeny> achiang, you make a valid point
<vanhoof> cwayne: hggdh you've gotta be picking up something cached
<vanhoof> have a quick call, ill take a look
<victorp> http://status.ubuntu.com/ubuntu-raring/group/topic-raring-desktop-targets-for-embedded.html
<cwayne> huh, im always getting it hanging at 9 seconds
<cwayne> wtf
<hggdh> vanhoof: I do have a cache for packages (squid-deb-proxy), but I do not see how it would get there
<hggdh> vanhoof: and certainly not for wget
<mfisch> vanhoof: what about the squid proxy?
<Laney> hrm
<cwayne> ogra_: victorp: i've got it running now, its pretty watchable
<cwayne> it stutters on occasion,but not horrible, although there's no sound at the moment
<vanhoof> mfisch: not sure otp will check in a sec
<vanhoof> hggdh: sending you a couple q's
<mfisch> ssweeny: did you look into where the brightness slider gets it's initial value from?
<mfisch> ssweeny: or just the dim part
<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)
<cwayne> ogra_: once i get it running (which is difficult sometimes) the simpsons trailer looks great actually
<ssweeny> mfisch, there's a helper program that talks to sysfs
<mfisch> ssweeny: where is it?
<victorp> cwayne, watcheable with no sound.. :)
<victorp> I have the same
<victorp> but with sound is very choppy
<cwayne> victorp: ah, i havent gotten the sound to work yet cus i hadn't suspended
<victorp> ah
<yofel_> keithzg: packages.ubuntu.com only searches on archive.ubuntu.com I believe. the arm packages are on ports.ubuntu.com
<victorp> let me know, might be just me ;)
<ssweeny> mfisch, source is in gnome-settings daemon, plugins/power/gsd-backlight-helper.c. binary is /usr/lib/gnome-settings-daemon/gsd-backlight-helper
<mfisch> janimo: here's the slider bug, I'm looking at it now: https://bugs.launchpad.net/ubuntu-nexus7/+bug/1077054
<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]
<mfisch> ssweeny: thanks
<ssweeny> mfisch, sure. why do you ask?
<mfisch> ssweeny: that bug above ^^
<ssweeny> mfisch, ah, right
<cwayne> mfisch: confirmed
<brendand> these figures are strange in 'upower --dump':
<brendand>     energy-full:         41.41 Wh
<brendand>     energy-full-design:  18.348 Wh
<Laney> on the nexus, does anyone else see webkit being busted? http://paste.ubuntu.com/1345526/
<Laney> I am on raring, which may or may not be relevant
<xnox> Laney: I like the "soso" bit. =))))
<Laney> yeah it's pretty cute
<achiang> i think webkit is known to be  broken on arm?
<achiang> </rumor>
<ogra> -updates gas a fix
<ogra> has
<victorp> achiang, that should be a bug then
<ogra> victorp, long fixed in quantal-updates
<achiang> so we'll get it as soon as we can move to R :)
<ogra> right
<ogra> ot you fish it out of updates
<ogra> or
<brendand> janimo, https://bugs.launchpad.net/bugs/1077062
<ubot2> Launchpad bug 1077062 in ubuntu-nexus7 "upower says battery is charged when it is not" [Undecided,New]
<Laney> I don't think that is the same as the jit fix
<Laney> but that SRU is still pending in the queue :/
<achiang> ssweeny: wonder if that webkit thing fixes rb-u1
<cwayne> achiang: ah, thatd be cool
<ssweeny> achiang, interesting
<ssweeny> achiang, i should test if the store page is pre-loaded
<victorp> cwayne, so should I re-install the image?
<ssweeny> in banshee it wouldn't load until you clicked on it
<cwayne> victorp: i think so, although now i'm getting pretty similar results as you
<cwayne> but i think it's best to do this on a fresh image anyway :)
<victorp> I think i will wait until the raring daylies are out
<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
<achiang> ssweeny: right, if the new webkit fixes rb-u1, then that's still a bug
<achiang> ssweeny: because we shouldn't be loading webkit until it's needed
<ogra-cb> well, ubiquity usies webkit a lot
<ssweeny> achiang, i'll take another look at it after i'm done playing with gsd
<xnox> ogra-cb: just the slideshow....
<ogra-cb> yeah
<achiang> ok
<ogra-cb> wow, i lkie the chromebook
<ogra-cb> the weird uk layout needs some getting used to
 * ogra-cb is on 12.04 now
<xnox> ogra-cb: do not change to the evil side
 * xnox proudly uses us layout regardless of the keyboard stickers
<ogra-cb> well, then i always have to search for # and stuff
<cwayne> mfisch: wanna mark this fix released?https://bugs.launchpad.net/ubuntu-nexus7/+bug/1072086
<ubot2> Launchpad bug 1072086 in ubuntu-nexus7 "Having random hostnames can result in offensive hostnames" [High,Fix committed]
<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
<ogra-cb> oh WOW
<ogra-cb> even the multitouch stuff and gestures work OOTB
<ogra-cb> four finger tap gets me the dash
<ogra-cb> like on the nexus
<ogra-cb> <3 unity-2d
<mfisch> ssweeny: can you run this on your laptop?  /usr/lib/gnome-settings-daemon/gsd-backlight-helper --get-max-brightness
<ssweeny> mfisch, i get "7"
<mfisch> i'm looking for another device with a large range, like 255
<mfisch> mine is 20
<ogra-cb> ubuntu@nexus7-roccos:~$  /usr/lib/gnome-settings-daemon/gsd-backlight-helper --get-max-brightness
<ogra-cb> 255
<ogra-cb> but
<ogra-cb> ubuntu@nexus7-roccos:~$ cat /sys/class/backlight/pwm-backlight/brightness
<ogra-cb> 40
<mfisch> ogra-cb: thanks!
<mfisch> ogra-cb: can you try to repro a bug for me?
<mfisch> ogra-cb: I cannot repro on laptops they dont have enough steps 0-20 isn't a wide enough range
 * ogra-cb looks at https://launchpad.net/ubuntu/raring/+queue and sighs
<ogra-cb> still no movement for the nexus kernel
<brendand> mfisch, about this bug : https://bugs.launchpad.net/ubuntu-nexus7/+bug/1071259
<ubot2> Launchpad bug 1071259 in ubuntu-nexus7 "Setting brightness all the way down actually switches off the display completely" [Medium,Confirmed]
<brendand> mfisch, i can't confirm it
<mfisch> brendand: I did a fix for it today, but it's not in the wild
<brendand> mfisch, interestingly, if i move the slider back up afterwards then after a few steps the display does blank
<mfisch> brendand: what happens when you slide it all the way left?
<mfisch> brendand: that's another bug: https://bugs.launchpad.net/gnome-control-center/+bug/1077054
<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]
<mfisch> brendand: the slider seems to have confusion in some cases
<brendand> mfisch, you describe it differently though
<brendand> mfisch, what's the command to get and set the brightness level again?
<mfisch> /usr/lib/gnome-settings-daemon/gsd-backlight-helper --help
<mfisch> set it to 0
<mfisch> brendand: I've also noticed that the slider is off by a bit
<brendand> mfisch, ah - then it goes off
<mfisch> brendand: for example, the max should be 255, mine seems to max at 252
<brendand> mfisch, i can only get it down to 7 with the slider
<mfisch> and if you move the slider real fast, it never keeps up
<mfisch> brendand: try moving it very slowly
<mfisch> brendand: are you using a mouse?
<brendand> mfisch, no - i still don't have a working one
<brendand> mfisch, my damn wireless mouse managed to break just after a got home :/
<mfisch> I'm filing one more about the slider
<brendand> mfisch, so 0 and 1 seem to correspond to off
<mfisch> brendand: the issue is that all the laptops I've seen have values from like 0-8 or 0-20
<mfisch> the slider seems to do some odd stuff with 0-255
<mfisch> brendand: that 0=off is being fixed as soon as we have a new kernel
<mfisch> brendand: as it's a rather annoying usability issue
<brendand> man this backlight is powerful
<ogra-cb> way to bright is you ask me
<ogra-cb> *if
<brendand> mfisch, setting via gsd doesn't seem to impact the slider
<mfisch> brendand: yep
<mfisch> the slider is problematic ;)
<mfisch> brendand: can you confirm this for me?
<mfisch> brendand: https://bugs.launchpad.net/ubuntu-nexus7/+bug/1077096
<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]
<mfisch> brendand: also see the new comment I added there, it's my current theory
<brendand> mfisch, hmm. i can't repro it right now
<brendand> mfisch, if i use the arrow keys to ensure it's all the way right then it says 255
<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
<mfisch> brendand: I'm not surprised the arrow keys work
<mfisch> can you add that comment?
<brendand> mfisch, hmm no - i can repro with the arrow keys
<brendand> :)
<mfisch> ah cool
<mfisch> well kinda cool
<brendand> mfisch, i can't get it to zero with the arrow keys either
<mfisch> ssweeny: what did we decide on that other brightness bug?
<mfisch> brendand: odd, I never had an issue with minimum
<brendand> mfisch, check it out. slider at the end '237'
<brendand> mfisch, move it to the left, '252'
<mfisch> ubuntu@nexus7-265143b8:~$ /usr/lib/gnome-settings-daemon/gsd-backlight-helper --get-brightness
<mfisch> 0
<ssweeny> mfisch, achiang oh-so-slyly implied that i should try to implement the AC/battery transition
<mfisch> brendand: yep, that's the bug.  max should be 255
<mfisch> brendand: check out what happens if I use a mouse and drag it as fast as possible to the right
<mfisch> this should be "max"
<mfisch> ubuntu@nexus7-265143b8:~$ /usr/lib/gnome-settings-daemon/gsd-backlight-helper --get-brightness
<mfisch> 45
<brendand> mfisch, ok, but i was moving the slider 'downwards
<mfisch> this slider is all sorts of broke
<brendand> mfisch - new bug: 'brightness slider is generally screwed'
<mfisch> ssweeny: was there a good reason why the feature was removed?
<mfisch> brendand: it certainly was never designed to handle a system with a range of 0-255
<ssweeny> mfisch, i assume it's because it was a useful GNOME feature
<brendand> mfisch, i can reproduce similarly on my laptop though
<mfisch> brendand: what's the max on your laptop?
<brendand> mfisch, 24
<mfisch> thats the highest I've seen from a laptop
<brendand> mfisch, currently it's full right and the value is '19'
<mfisch> please note that if you will, I can't repro here
<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
<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
<ssweeny> achiang, ack
<brendand> mfisch, i confirmed your bug
<brendand> achiang, i think gsd is broke, so it's not a matter of carrying a patch (at least for some of the issues)
<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
<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?
<brendand> mfisch, if you set volume level in pulseaudio command line then there is immediate feedback in the ui. same for bluetooth settings etc
<mfisch> brendand: that would be yet another bug
<mfisch> ngharo: what are you trying to hack?
<brendand> mfisch, which is easily reproducible on any system
<ngharo> mfisch: I'm interested in different DE images and building a Kiosk image
<mfisch> ngharo: see if this helps too: http://www.mattfischer.com/blog/?p=285
<ogra-cb> ngharo, we use live-build, rootstock is dead
<ngharo> ogra-cb: thanks
<mfisch> ngharo: my post will tell you how to proceed after you do your live-build
<ogra-cb> there will be daily images for ubuntu, kubuntu and lubuntu soon
<ngharo> mfisch: awesome thanks
<mfisch> ngharo: you need to set LB_BINARY_IMAGES="tar" in your live-build config
<mfisch> ngharo: input to this process is a rootfs.tar.gz and output is rootfs.img/boot.img
<ngharo> the tarball installer script lives in boot.img it appears; should that also be in the rootfs.tar.gz then?
<NekoXP> yikes does nexus7 really use usb audio?
<ngharo> before building boot.img
<mfisch> ngharo: you'll need all the packages from our PPA in your image
<ngharo> roger that
<mfisch> ngharo: https://launchpad.net/~ubuntu-nexus7/+archive/ppa
<mfisch> ngharo: "tarball-installer" is one of them
<ngharo> :D
<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?
<ngharo> very cool.  Thanks.  It's reassuring to know I'm not completely off the broken path
<mfisch> brendand: lemme check
<mfisch> brendand: yes
<NekoXP> anyway question, where's the nexus7 kernel coming from? I can see builds in the ppa but not where the source lives
<mfisch> NekoXP: in our wiki, let me find you a link
<ogra-cb> on kernel,ubuntu.com
<ngharo> https://wiki.ubuntu.com/Nexus7/Developers
<mfisch> NekoXP: https://wiki.ubuntu.com/Nexus7/Developers
<brendand> mfisch, the slider is completely disconnected
<NekoXP> wicked
<mfisch> brendand: may I suggest a new bug, "was brightness slider written as a practical joke"
<NekoXP> :) I don't think gnome settings has a proper dbus interface for backlight
<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.
<brendand> mfisch, https://bugs.launchpad.net/gnome-control-center/+bug/893851
<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]
<brendand> mfisch, it's marked as fix released :(
<mfisch> lies!
<vanhoof> hggdh: plars: mind giving the sha256sum a hit ( hggdh: no installer changes needed )
<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"
<vanhoof> see if we are in sync now
<vanhoof> looking like it may have been a server side caching issue
<mfisch> brendand: I'll go ask jm-leddy
<vanhoof> but if it is local ISP, then we have a fix as well
<plars> vanhoof: sure
<plars> 55c9802559118ab40e26a2b9d6be105634cbfcecdd54d0b78db34a8b91bcf23c  boot.img
<plars> 5908fcf21c71c0c247848e8b534cacf2a17dd1ca7235ba794567b3b63c0563d5  rootfs.img
<plars> same as it was earlier for me
<brendand> mfisch, well i'm calling it a week. bet you $50 that bug is the source of all these problems
<vanhoof> that's accurate for 16gb
<brendand> ttyal
<plars> so I'm not sure we'd see it unless we change something
<NekoXP> mfisch, you should check if your kernel has inotify/fnotify or something in there
<mfisch> NekoXP: that bug exists on the standard ubuntu kernel
<vanhoof> plars: can also try
<vanhoof> wget --progress=bar:force http://hwe.ubuntu.com/uds-r/nexus7/8GB/ubuntu-nexus7-sha256sum.txt  -O /tmp/ubuntu-nexus7-sha256sum.txt
<NekoXP> oh.. then.. ouch?
<vanhoof> then ls -ltr /tmp
<vanhoof> see if its oct 26th or nov 8th
<vanhoof> if 26th, then add --no-cache
<vanhoof> but a change was made server side
<vanhoof> so it may all be sorted now, just want to be sure
<plars> vanhoof: oh, I got nov 8
<plars> err
<vanhoof> sweet
<plars> vanhoof: no
<plars> vanhoof: oct26
<plars> sorry, typo
<vanhoof> heh
<plars> I was looking at what you said and not the screen
<vanhoof> ok
<vanhoof> run the same (keep the old file)
<vanhoof> and add --no-cache
<plars> vanhoof: so I'm still pulling a cached copy I guess... yes with that I get the nov8 copy
<plars> with --no-cache that is
<vanhoof> ok
<vanhoof> with the updated cache expirary still in question, i'll update the installer too just to be cautious
<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
<yofel_> (qemu bug?)
<mfisch> cwayne: actually I'm just trying to gather info on this bug: https://bugs.launchpad.net/ubuntu-nexus7/+bug/1077062
<ubot2> Launchpad bug 1077062 in ubuntu-nexus7 "upower says battery is charged when it is not" [Undecided,New]
<mfisch> cwayne: his energy-full value is way too high
<ogra-cb> yofel_, yeah, could be, file it
<yofel_> ack
<ogra-cb> mfisch, i noticed that it is accurate after a reboot
<ogra-cb> when it gets into that state
<mfisch> ogra-cb: mine is accurate now
<mfisch> wondering how to make it inaccurate ;)
<ogra-cb> for me it becomes inaccurate if i leave the device on the charger over night
<cwayne> mfisch: added, mine was a bit wrong
<mfisch> cwayne: okay, go ahead and confirm
<mfisch> ogra-cb: thanks
<ogra-cb> its usually wrong when i touch the touchscreen to get it out of dpms
<mfisch> it would be interesting if we could test that in Android too
<cwayne> mfisch: ah, but i dont see the same symptoms
<cwayne> mine doesnt say it's charged
<ogra-cb> well, after the power patch to the kernel you cantreally compare to android anymore
<ogra-cb> well, you can, but the stuff you compare is now different
<ogra-cb> cking should just take another look at his patch
<mfisch> ogra-cb: assign it to him?
<ogra-cb> ++
<ogra-cb> ogra@chromebook:~/linux-ac100-3.0.27$ time dpkg-buildpackage -rfakeroot -b
<ogra-cb> ...
<ogra-cb> real	44m37.117s
<ogra-cb> user	55m16.630s
<ogra-cb> sys	7m33.140s
<ogra-cb> WOW !!!
<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
<ogra-cb> and i'm even building on the MMC, nnot any fast USB disk or so
<cwayne> mfisch: ping
<hggdh> vanhoof: on it (was at lunch). Just a note, I saw it happening with the sha *and* the images (both of them)
<mfisch> cwayne: YO
<cwayne> mfisch: im thinking of marking this incomplete with my last comment,  thoughts? https://bugs.launchpad.net/ubuntu-nexus7/+bug/1075417
<ubot2> Launchpad bug 1075417 in unity (Ubuntu) "Unity panel/launcher/dash don't scale with system DPI/font settings" [Undecided,New]
<ogra-cb> iirc there is an older upstream bug for the same issue
<mfisch> cwayne: there's another bug about login/logout
<ogra-cb> mpt should be able to tell you about it
<mfisch> maybe we should just ask mpt before filing any bugs?
<ogra-cb> for UI stuff that probably makes sense
<cwayne> mfisch: hmm, i suppose so.. should we mark this one a dupe?
<mfisch> cwayne: marking incomplete while waiting for a response is the correct flow
<mfisch> lemme find it
<ogra-cb> yeah
<mfisch> cwayne: https://bugs.launchpad.net/ubuntu-nexus7/+bug/1075470
<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]
<mfisch> seems to be some overlap
<cwayne> hmm yeah
<hggdh> vanhoof: bad sha file
<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/
<[mbm]> it's not just the titlebar buttns that are small, most of the ui is rather small
<ogra-cb> most of it scales properly if you set the font to "gigantic" :)
<ogra-cb> the panel doesnt scale at all
<ogra-cb> it even cuts off the bottom of the letters in the biggest font size
<[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
<ogra-cb> well, there are no actual plans to touch the UI at all for thhis cycle
<ogra-cb> there will be very deep focus on UI stuff in 13.10 on the road to 14.04
<[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
<[mbm]> if you treat the touchscreen in relative mode, same as a laptop, all the usability issues of things being too small goes away
<[mbm]> no ui changes needed
<ogra-cb> well, that implies that we would have any influence on the touchscreen driver ... which is a binary blob
<[mbm]> translating from absolute to relative would be easy enough with a shim
<[mbm]> (I already tried the obvious thing of toggling it with xinput but that isn't supported by the driver)
<ben1066> ogra-cb: haha, touch the ui >_>
<ogra-cb> :)
<ben1066> Still having annoyance with Ubuntu on my desktop...never mind android...multi monitor + nvidia drivers == hell
<ben1066> s/android/nexus 7
 * ogra-cb has an ATI in hs desktop and no issues with a tripe monitor setup
<ben1066> Both monitors are VGA (yeah go me) and one wont even report it's data
<ben1066> At the login screen all is good
<ben1066> login, the second monitors res is 640x480
<ben1066> YAY
<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
<ben1066> i dont get why the login screen is fine
<ben1066> AND THEN it breaks
<ogra-cb> because gnome-settings-daemon manages the resolution after the login
<ben1066> So it's that cocking up
<ogra-cb> likely
<ben1066> ill reboot back into ubuntu in a sec
<ben1066> Now I know why
<ben1066> You have been more helpful than #ubuntu :)
<ogra-cb> well, we're not a support channel, mind you
<ben1066> I know, and I shan't use it as such
<ben1066> Still
<ben1066> In #ubuntu they insisted it was because I was using the NVIDIA binary not the Ubuntu one
<ben1066> despite it partially working...
<ogra-cb> well, thats definitely the root cause
<ogra-cb> nvidia and xrandr are known to not work well together
<mfisch> we have several bugs filed about it ^^
<ogra-cb> and gnome-settings-daemon simply does everthing regarding the resolution settings via xrandr
<mfisch> yep
<ogra-cb> i doubt it makes much difference which of the binary drivers you use though
<ben1066> Is there a proper solution?
<ogra-cb> the ubuntu one is simply better maintained, and gets a bunch of tests before going into the distro
<ogra-cb> yes, make nvidia fix it :)
<ben1066> Other than that, that's hardly an option
<ogra-cb> you asked for proper :)
<vanhoof> hggdh: still about
<ben1066> Apparently the drivers have xrandr now...or is it broken?
<ogra-cb> no idea, no first hand experience with recent nvidia here
<ogra-cb> i know its accused to be broken, they might have fixed it
 * ogra-cb only uses nvidia on arm 
<ben1066> Nvidia is great on windows
<ben1066> On linux, aparently not so much
<ogra-cb> havent touched it in years on x86
<ogra-cb> doesnt it come with a gui configuration tool ?
<ogra-cb> you should be able to set it up there
<ben1066> the nvidia driver does
<ben1066> it sets xorg.conf
<ben1066> Still gets reset on login
<cwayne> ogra-cb: i thought you only used everything on arm :)
<ogra-cb> cwayne, i only work on arm stuff since 4 years ... there was a time before that
<ogra-cb> i.e. LPIA
<ogra-cb> :)
<infinity> *shudder*
<mfisch> could be worse
 * mfisch was working on Intel space heater technology aka Itanium
<infinity> ia64 had a much longer life than lpia.
<infinity> Though, I'll never forgive ia64 for killing parisc.
<mfisch> HP wanted parisc dead though
<infinity> mfisch: I'm unconvinced that's true, rather that they were contractually obliged to let it die.
<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)
<mfisch> infinity: HP co-invented the Itanium chip and handed it to Intel
 * mfisch knows because /me was there during the early itanium days
<mfisch> infinity: unless you mean once they realized the mistake they made ;)
<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.
 * ogra-cb really loved alpha
<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
<vanhoof> ogra-cb: i still have 3 DS10L's that work :D
<vanhoof> ogra-cb: all the rest have died :)
<ogra-cb> sweet !
 * vanhoof loved build server closet cleaning days in the past ;)
<ogra-cb> vanhoof, you werent in CPH ... :(
<vanhoof> ogra-cb: i tried!
<vanhoof> four times
<ogra-cb> i actually had the ac100 displays with me
<vanhoof> ah crap :\
<ogra-cb> well, we just have to convince achiang that we need to do a sprint ;)
<vanhoof> ogra-cb: since we moved saturday, i flew sunday, which was a big mistake trying to leave the east coast w/ the hurricane :\
<ogra-cb> then i can bring them
<ogra-cb> yeah
<mfisch> vanhoof: did you get stuck?
<vanhoof> best I could get there was tuesday night, jetlag + two days, seemed, meh
<vanhoof> ogra-cb: :D
<ogra-cb> right, that would be nonsense
<vanhoof> mfisch: no just cancelled luckily
<vanhoof> mfisch: but sat for many hours here at the airport
<vanhoof> all my original flights went through nyc*
<vanhoof> newark, then jfk, then chicago, then flat out NO
<mfisch> I flew via IAD
 * ogra-cb always tries to enter/exit the US via philly
<mfisch> that airport is an embarassment
<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
<ogra-cb> yay
<vanhoof> yeah if I'd have left saturday or even a few hours earlier sunday i would have made it
<vanhoof> ogra-cb: i hate squid :D
<ogra-cb> heh
<mfisch> why dont we just turn squid off?
<vanhoof> luckily i was able to finally reproduce it
<vanhoof> i thought everyone was crazy :)
<mfisch> I assume the number of downloads has dropped off
<vanhoof> mfisch: cache timeout is 15m now
<vanhoof> and we force --no-cache on downloads client side
<vanhoof> so we should be a'ok
<vanhoof> there are other large relics on the same machine i'd like to have squid for so I dont get yelled at :D
<vanhoof> hggdh++ thanks for help w/ testing today
<hggdh> vanhoof: yw
<mfisch> vanhoof: can we mark https://bugs.launchpad.net/ubuntu-nexus7/+bug/1077007 as fix released?
<ubot2> Launchpad bug 1077007 in ubuntu-nexus7 "Downloaded images failed checksum validation" [Critical,Fix committed]
<vanhoof> yeah I was going to wait to hear back from the reporters
<vanhoof> but im pretty confident its fixed
<hggdh> vanhoof: just confirmed it works. At least so far ;-)
<ngharo> Does anyone have a live-build for n7 directory/config checked in anywhere?
#ubuntu-arm 2012-11-10
<uberushaximus> Has anyone done any work to be able to boot into fastboot from linux? (like adb reboot bootloader)
<uberushaximus> on n7
<cwayne> from a n7 running ubuntu?
<cwayne> you can't yet, youd have to just power off + on while holding volume down
<lilstevie> it shouldn't be too difficult to manually do though
<lilstevie> (reboot into fastboot)
<lilstevie> from memory it is a bootloader message on misc
<uberushaximus> if all you have is ssh and you're locked out of where it is, it's helpful
<[mbm]> uberushaximus: 'adb reboot bootloader' just runs the command 'reboot bootloader' and reboot then passes 'bootloader' as an argument to the kernel reboot function, so really it's all about which kernel was used
<ogra-cb> hrw, lol, did you notice that if you copy the while content of /opt from the cros disk to ubuntu, copy two additional libs and run /opt/google/chrome/chrome, you actually get the chromeos desktop in a window
<ogra-cb> s/while/whole/
<ogra-cb> it seems to require working gles though, its ultra slow
<ogra-cb> but i bet with working 3d accel it will work fine, so you could use the whole browser with all plugins (incl flash and hangouts) under ubuntu
<hrw> ogra-cb: nice
<hrw> ogra-cb: copy /usr/lib/lib{mali,EGL,GLES,GL}* and you may have opengles
<ogra-cb> tried already, isnt enough
<hrw> I was able to run glmark2-es once
<ogra-cb> i need wiorking armsoc for that i think
<hrw> ah
<hrw> have to put it into ppa
 * ogra-cb is on fbdev
<hrw> let me create package
<hrw> I am on armsoc
<hrw> give me 30 minutes :)
<ogra-cb> i didnt upgrade the system from precise yet
<ogra-cb> and tryig to build it myself failed due to missing deps
<ogra-cb> (libdrm-omap or so)
<hrw> apt-getbuild-dep xf86-video-omap or sth like that
<ogra-cb> thats not in precise
<hrw> ok
<hrw> I run raring
<ogra-cb> i know
<ogra-cb> :)
<ogra-cb> wasnt breave enough to upgrade yet
<ogra-cb> the touchpad works flawless for me with evdev btw
<ogra-cb> including all the multitouch stuff
<ogra-cb> i had to adjust accel and snesitivity a bit through the UI tool but after that its not worse than in cros
<hrw> share accel/sens values?
<ogra-cb> oh, weeme it doesnt persist over reboots, heh
<ogra-cb> *seems
<ogra-cb> so it use the defaults since a while
<ogra-cb> nevermind
<hrw> ;D
<hrw> package sent to ppa
<ogra-cb> oh, cool, i just found out that two finger scrolling works
<hrw> both directions
<ogra-cb> just needed to enable it in the gnome gui
<hrw> 1,2,3,4 finger tap too
<hrw> no idea what for 4tap is anyway
<ogra-cb> it defaults to edge scrolling, that doesnt really work right
<ogra-cb> 4 tap brings up the dash in unity
<ogra-cb> so likely emulates the super key in other envs
 * lilstevie is jealous 
<lilstevie> the tf dock trackpad refuses to work properly with anything
<ogra-cb> sad
<lilstevie> even with mtrack
<lilstevie> mtrack works, but gives no scrolling ability at all
<lilstevie> at which point one might as well force single touch mode in the driver
<ogra-cb> rouchpads are dead anyway in the aera of bathroom windows^W^W windows 8
<ogra-cb> touch
<lilstevie> heh
<hrw> ogra-cb: super key is on 'find' key
<ogra-cb> yeah
<ogra-cb> which gets pretty annoying in unity over time
<ogra-cb> i always accidentially hit it
<hrw> remap it?
<ogra-cb> yeah, i will if that goes on
<hrw> I would love to have usable xkb editor
<hrw> lack of pgup/down suxx
<ogra-cb> i actually would like to get unity3d in raring to work though, then i'll likely need it
<ogra-cb> as a comparison system for the nexus
<ogra-cb> ++
<ogra-cb> you could try to remap shift up/down tp pgup pgdn
<ogra-cb> or something like that
<ogra-cb> beond the mapping issues i'm really impressed by the kbd
<hrw> ogra-cb: you have UK or US one?
<ogra-cb> uk
<hrw> I will work on using find up/down for pgup/down
<hrw> shift+up/down are already useful
<ogra-cb> hwwhat ppa did you upload to ?
<ogra-cb> hrw, ^^
<hrw> hrw:my-own-packages
<hrw> or rather: ppa:hrw/my-own-packages
<ogra-cb> k, i dont see anything there
<ogra-cb> alsa-lib is the latest
<hrw> I see
 * ogra-cb finds it funny that the battery meter can act as a load meter 
<ogra-cb> if i scroll a lot in firefox the remaining time drops significantly, as soon as i stop scrolling it bumps up again
<hrw> ;)
<hrw> I know why no ppa
<ogra-cb> you uploaded to raring directly ?
<ogra-cb> :)
<hrw> forgot -sa
<ogra-cb> ah
<hrw> I need to sort out versioning
<hrw> armsoc driver has upstream, fork, different versions etc
<ogra-cb> ah, i see it now
<hrw> I am thinking about using 0.0+gitYYYYMMDDrSHAID version
<hrw> Linaro upstream is at 0.5.1, Chromium fork is 0.0.1 but has code from 0.4* etc
<persia> That's safe as an upstream version
<ogra-cb> yeah, sounds sane
<persia> (only 0.0.0~ or similar breaks stuff)
<ogra-cb> so i wonder if i can make that build on precise
<hrw> ogra-cb: if you get b-d packages then it will work
<ogra-cb> or if i have to upgrade and lose my desktop
<ogra-cb> ywah, that might take some effort
<hrw> I want to replace my patch with patches from xf86-video-omap x11 update but need some time to fix it
<ogra-cb> ah, i just needed to pull libdrm from quantal
<ogra-cb> bah, or not
<ogra-cb> failed
<ogra-cb> omap_dri2.c: In function 'OMAPDRI2ScreenInit':
<ogra-cb> omap_dri2.c:586:4: error: unknown field 'ReuseBufferNotify' specified in initializer
<ogra-cb> :(
<ogra-cb> hrw, did you just dist upgrade from precise to raring or did you properly use update-mamanger ?
<ogra-cb> haha
<ogra-cb> "your graphics may not be fully supported in 12.10, you might end up with a slow desktop ...."
<hrw> apt-get dist-upgrade as usual
<ogra-cb> well, i'm going the proper route now
<Tassadar> Hi, is there somebody involved with the Nexus 7 port of Ubuntu? I'd like to discuss dual-booting ubuntu with android.
<hrw> 
<ogra-cb> Tassadar, no plans to work on it ... see https://wiki.ubuntu.com/Nexus7/FAQ#Do_you_plan_to_support_dual_booting_Ubuntu_and_Android.3F
<Tassadar> No, I mean I did it, and I'd like to ask some details about how to change some things in ubuntu to make it work better
<ogra-cb> it will definitely break with one of the next kernel upgrades
<ogra-cb> (or with the next package that triggers regeneration of the initrd, whatever happens first)
<Tassadar> Yeah, I know, that is why I am here :)
<ogra-cb> it would require massive changes to the design of flash-kernel
<Tassadar> the ramdisk which it flashes must be generated from something, no?
<ogra-cb> update-initramfs from the initramfs-package dooes that
<ogra-cb> any package can trigger such a rebuild and the last step of update-initramfs is to flash the new initrd to the boot partition
<Tassadar> i'd only need to move init -> main_init, add my own init binary, busybox and one symlink to the ramdisk
<ogra-cb> using flash-kernel
<ogra-cb> that wont prevent flash-kernel from flashing over the android kernel;
<Tassadar> that is okay
<ogra-cb> it will trash your android every time it runs in the current setup
<Tassadar> I use different boot.img for both android and ubuntu
<lilstevie> ogra-cb, "Can we remove the Google Logo from the bootloader? There are no firm plans to try this, although it may be possible. Patches welcome!" <-- most likely not, the bootloader is sigchecked on flashing, even while unlocked
<Tassadar> my init then asks you what to boot, and it will either proceed with boot, or flashes new boot.img and restarts
<Tassadar> it is the only solution I could think of, besides kexec, which is pretty hard to make working :/
<ogra-cb> you flash on every boot ?
<lilstevie> kexec would be fine with the hardboot hack
<lilstevie> that is what I do for the tf201
<ogra-cb> that will kill your MMC at some point
<lilstevie> exactly why I didn't go with something like that :p
<Tassadar> lilstevie: that is not much faster than reboot, but I'll look into that
<Tassadar> ogra-cb: no, not every, only when it is needed, eg. android->ubuntu and vice-versa
<ogra-cb> well, indeed, thats what i meant
<lilstevie> Tassadar, it is no faster than a reboot, just a hell of a lot less mmc wear
<Tassadar> the problem is it would require kernel modification
<lilstevie> that it does
<lilstevie> at this stage
<lilstevie> although we have been looking into some changes to solve that
<Tassadar> somebody on XDA had idea if fastboot boot *boot.img* could be used in some way, but I am do not think that bootloader sources are available
<ogra-cb> well we use fastboot for flashing the same way
<ogra-cb> i guess thats possible
<ogra-cb> but you need a second machine
<ogra-cb> and need to boot into fastboot mode
<Tassadar> well, I was thinking that if fastboot just puts the boot image somewhere in ram and then restarts the device, then it could be possible to do the same without fastboot mode, but then again, hard to say without sources, it probably does not even restart the device after fastboot boot :/
<lilstevie> why would it reboot?
<lilstevie> fastboot boot just loads the kernel into ram, then calls the boot method
<Tassadar> no reason, thats just me hoping it would be so easy)
<Tassadar> lilstevie: I have the kexec-hardboot patch opened, and I see KEXEC_HB_PAGE_ADDR define - i suppose this needs changing, where exactly should it be? The value in patch (0x57fff000) doest not remind me of anything
<lilstevie> Tassadar, is that the original, or the one we have for the tf201. I don't have the source right in front of me this second
<Tassadar> it is the one for epic 4g, so the original I suppose. Is the one for tf201 on XDA?
<lilstevie> it is on github
<lilstevie> gimme sec, have the code in front of me now
<lilstevie> right
<lilstevie> HB_PAGE is the page that the decompressor reads to check for the hardboot flag
<lilstevie> it ideally should be part of standard memory that is out of the way of anything that may run over it during the hardboot cycle
<Tassadar> so something near the ram_console should be ideal
<lilstevie> for the TF201 we have it at 0xBEC00000
<lilstevie> which is a little before fbmem
<lilstevie> you really need to check what the memory layout is for your device
<lilstevie> originally we had it at ram_console-SZ_1M but that was inside bootloader fb
<lilstevie> it really depends on memory layout
<lilstevie> you shouldn't need to worry about normal kernel operations, or userspace hitting it, it is one of the last things set before the reboot, and one of the first things checked in the decompressor
<Tassadar> yeah, well, I really feel I need a bit more knowledge to do this - so, decompressor == part of bootloader, which decompresses the kernel (zImage)?
<lilstevie> decompressor == part of the kernel
<lilstevie> specifically the first code to be executed from the kernel
<Tassadar> okay, so the kernel like, decompresses itself?
<lilstevie> yes
<Tassadar> lilstevie: how do I check the memory layout?
<hrw> hm... opengles works only for root
<hrw> 	libGLESv2.so.2 => /usr/lib/arm-linux-gnueabihf/mali-gles/libGLESv2.so.2 (0x76d9f000)
<hrw> ideas?
<tassadar> lilstevie: could you please send me link to that github repo with hardboot kernel for tf201?
<ogra-cb> hrw, yay, unity 3d !
<ogra-cb> hrw, your package needs a udev rule to make /dev/mali0 writable for the user (just hand it to udev-acl)
<ogra-cb> hrw, hmm [   730.601] (EE) AIGLX error: dlopen of /usr/lib/arm-linux-gnueabihf/dri/armsoc_dri.so failed (/usr/lib/arm-linux-gnueabihf/dri/armsoc_dri.so: cannot open shared object file: No such file or directory)
<ogra-cb> hrw, /lib/udev/rules.d/69-mali-gpu.rules
<ogra-cb> hrw, http://paste.ubuntu.com/1348470/
<ogra-cb> hrw, makes GLES work OOTB here for non root users
<ogra-cb> hrw, or better http://paste.ubuntu.com/1348479/
<ogra-cb> (without mentioning tegra :P )
<ogra-cb> hmm, so dpms is really broken with the armsoc driver
<FreezingCold> http://www.chromestory.com/2012/10/how-to-install-ubuntu-on-the-new-arm-chromebook/
<FreezingCold> How can I do that except install it to the SSD?
<FreezingCold> Don't really need or want ChromeOS on it
<FreezingCold> I'll be idling for awhile, just ring me if you know
#ubuntu-arm 2012-11-11
<hrw> ogra-cb_: muchas gracias senior!
<ogra-cb> bug #1039155
<ubot2> Launchpad bug 1039155 in compiz (Ubuntu Quantal) "Unity fails to load on old hardware (blank desktop; only wallpaper). Missing automatic fallback to LLVMpipe when unity_support_test fails" [High,Fix released] https://launchpad.net/bugs/1039155
#ubuntu-arm 2013-11-05
<x-bryan_g-x> HI all, first time user her.
<x-bryan_g-x> here*
<x-bryan_g-x> Does anyone know where I can find a build of Ubuntu 12.10 Desktop for a Nexus 7 (grouper)? I've been searching a lot, but keep coming up with Ubuntu Touch, or Ubuntu 12.10 for TI OMAP4
<infinity> x-bryan_g-x: raring was the only release that had a nexu7 desktop image.
<infinity> x-bryan_g-x: http://cdimage.ubuntu.com/releases/raring/release/
<infinity> x-bryan_g-x: Not that I'd recommend it as anything more than a proof of concept, but there you go.
<x-bryan_g-x> That's what I thought actually, thanks anyway.
<ctronsys> Sup all
<ctronsys> So, I've been drooling over the new tf701t--i loved my old transformer prime--and want to drop some cash
<ctronsys> I also develop for android
<ctronsys> Aide and terminal IDE have been great, but my team uses intellij in such a way that it breaks my builds
<ctronsys> Currently I have a nexus7 with a deb chroot and an ubuntu 13.04 image
<ctronsys> I'd like to set something similar up on the tf, and would like to know the feasibility
<ctronsys> I'm not talking smooth transitions, even the f'ed up touch interface is fine, so not UfA
<ctronsys> Just an arm based Ubuntu I can flash into
<ctronsys> Is there hope, given boot loader unlock&&?
#ubuntu-arm 2013-11-07
<Bronze> hi, noticed that the topic here says that the Pi is ARMv6 and that this channel is for ARMv7 discuission.  What is the difference between those?
<infinity> Bronze: ARMv6 is an older instruction set, Ubuntu only targets 7 and above, so can't run on the Pi.
<Bronze> Thank you.
<Bronze> (and rats... :-)   )
<sp4wnr0ot> ping #ubuntu-arm, Guys someone had test with qemu + raspbian + retropie ? I'm getting this error when I try to run "emulationstation"  returns "* failed to open vchiq instance" , What is it ? Some idea ?
<sp4wnr0ot> ?
<k1l> you are aware, that raspbian is a debian fork and ubuntu doesnt support that old ARM chip on the pi?
<sp4wnr0ot> k1l: heap, I'm just trying test "emulation state" on qemu first
<sp4wnr0ot> yeap*
<sp4wnr0ot> emulationstate*
<sp4wnr0ot> emulationstation* sorry again
<Nothing_Much> Can somebody tell me how to get libhybris to work on the desktop version of (x)Ubuntu 13.10 and Wayland/Weston?
<Nothing_Much> Anyone?
<Nothing_Much> Does anybody here know how to get libhybris enabled on an arm version of Ubuntu?
<Nothing_Much> Hm.
<Nothing_Much> Anybody know how to get libhybris to work on an Ubuntu desktop?
<Nothing_Much> Can I get some help with llibhybris on an Armhf Ubuntu desktop?
<Nothing_Much> Can I get some help with llibhybris on an Armhf Ubuntu desktop?
<infinity> Nothing_Much: I'm not sure that asking 5 times is any better than 4.  You might try asking politely in #ubuntu-touch, where there are some people who actually know hybris.  But only ask once, ideally.
#ubuntu-arm 2013-11-08
<Nothing_Much> infinity: Sorry about that, but any form of response would be nice.
<infinity> It's not always the most active channel.
#ubuntu-arm 2013-11-09
<Nothing_Much> I need some help regarding the official package repositories
<Nothing_Much> My armhf install keeps wanting to redirect to binary-x86/Packages
<Nothing_Much> It shouldn't be doing that
#ubuntu-arm 2014-11-03
<genii> What to do about udev and upstart in a chroot?
 * genii diverts it
<infinity> (vivid-amd64)root@cthulhu:/home/adconrad# cat /usr/sbin/policy-rc.d
<infinity> #!/bin/sh
<infinity> while true; do
<infinity>     case "$1" in
<infinity>       -*) shift ;;
<infinity>       makedev) exit 0;;
<infinity>       x11-common) exit 0;;
<infinity>       *) exit 101;;
<infinity>     esac
<infinity> done
<infinity> genii: ^--- The above snippet makes sure things don't get run in chroots from postinsts.
<infinity> genii: (Well, from invoke-rc.d, which postinsts call)
<genii> Great, thanks!
#ubuntu-arm 2014-11-05
<mach20x> Getting a âfatal IO error 11 x serverâ error message on a fresh Ubuntu install. Ubuntu 14.04 trusty tahr armhf, desktop environment LXDE along with x server installed, on sgh-i897. How may I correct this?
<mach20x> Using chroot via Linux deploy
<mach20x> Anyone here?
#ubuntu-arm 2014-11-07
<mach20x> I am experiencing a problem with my framebuffer, it appears with the desktop GUI for a portion of a second and then disappears leaving only a blinking CPU monitor behind that persists on the display even when I leave the Linux deploy app and traverse the android realm.
<ogra_> not sure what the "linux deploy app" is ... ever heard of it
<ogra_> *never
<ogra_> but you should probably talk to the people providing that thing
<k1l> its a chroot thing
<ogra_> k1l, sure, but definitely not an ubuntu thing
<mach20x> â¦ hmm, I don't know how good and prompt support is for it. I could really use a bit of knowledge on how framebuffer/x server integrates with my machine via chroot.
<k1l> there were some chroot apps which connected with vnc locally to the chroot running linuxes to simulate a desktop linux on the android devices. i tested it once then and it was "rubbish".
<mach20x> I have seen forums, and none express this particular problem
<ogra_> well, on a native ubuntu install you would just use the xorg fbdev driver which would use /dev/fb0 or some such to get graphics on the screen
<ogra_> (unaccelerated)
<mach20x> The vnc server its rubbish/laggy from what I hear from everyone. That is why I elected to the framebuffer for my deployment
<mach20x> dev/fb0 is the driver I'm using and I am seeing feedback, but something its happening which is distorting it this way.
<ogra_> no, /dev/fb0 is the device, not the driver
<mach20x> Is not it's * x2
<ogra_> the driver would attach to the device
<mach20x> Right
<mach20x> I'm sorry the path on the Android device is /dev/graphics/fb0
<mach20x> The path that you are describing is what you would see in Ubuntu
<mach20x> I tried ln -s /dev/graphics/fb0 /dev/fb0 without success
<mach20x> Tried this as well cp -af /dev/graphics/fb0 $chroot_dir/dev/fb0 , perhaps its the reason I'm seeing anything at all, I don't know
<ogra_> well, whatever you do inside the chroot, it will depend on the permissions set by the host system ...
<ogra_> (and copying devices wont work)
<mach20x> Ok, I have root permissions available, what would I have to change on the hosting device?
<ogra_> dunno
<ogra_> but if android restricts access to a group you are not in for example ... you need to have the same group with the same GID insode your chroot
<ogra_> (which gets awfully messy between android and ubuntu if you want all permissions right)
<mach20x> right, I can imagine that.
<mach20x> Though why would it be that I get any signal at all when I try to open Ubuntu, if I'm out their k outside THE GID
<mach20x> If I'm outside the GID *
<ogra_> dunno, check your logs etc, fix whatever it complains about ... and in the end, talk to the people that created this tool
<mach20x> Ok
<ogra_> there is really not much that can be done on the ubuntu side if you have a broken tool that created your setup
<mach20x> I sent an email, so we'll see what comes of it
<mach20x> I know that you are right, but I'm pretty sure I can ssh into the Ubuntu side to interface
<mach20x> I still wouldn't know what would need to be done to effectively iron out this issue when I got there
<mach20x> How to set up the dependencies and all that
<ogra_> well, but is not something we usually do in ubuntu ... we dont bastardize an install on top of some android system ...
<mach20x> The only error I'm seeing is â Stdin: is not a tty â
<mach20x> Do you think this will work if I put it into the custom script option?
<mach20x> Ogra ^^
<mach20x> http://forum.xda-developers.com/showthread.php?t=1328742
<mach20x> Forgot to drop the URL sorry ogra
#ubuntu-arm 2014-11-08
<noob> "-bash: cannot create temp file for here-document: Read-only file system".. how to make read-write file system?
<noob> anyone there/?
#ubuntu-arm 2015-11-03
<bz> in thumb-2, is the final right-most operand supposed to be flexible?
<bz> for the orr mnemonic, that is
<bz> i ask this because i have a pdf titled "ARM and Thumb-2 Instruction Set Quick Reference Card" that shows the syntax of orr to be: orr rd, rn, operand2
<bz> where operand2 allows an optional register shift by a register
<bz> but gnu as doesn't accept this
#ubuntu-arm 2015-11-04
<dTal> Hello chaps. I've added Hugh Greenberg's PPA for xf86-input-cmt, but no packages are available on my ARM Chromebook. I can see that the packages don't seem to be built for ARM, but the peculiar thing is I can't even "apt-get source" them.
<dTal> Never mind!
<ogra_> alai, yo
<ali1234> hi
<alai> ogra_, hi
<ogra_> so the only way to successfully load dtbs on the rpi2 is to load them via config.txt and the binary blob
<ogra_> alai, lol, sorry i meant ali1234
<ali1234> why would that be a thing?
<ogra_> the blob stuff the dtb (and overlays) into 0x100 ... and uboot needs to load it from there
<ali1234> okay so you can't load overlays directly with u-boot
<ali1234> that is because u-boot doesn't understand them
<ogra_> if you do a fatload or tftp load it will not initialize correctly
<ogra_> and uboot will set ATAGs ...
<ali1234> okay, i will test this :)
<ogra_> so your kernel boots but you end up without /proc/device-tree and not all HW features work
<ogra_> for snappy i chainload uboot from the blob ... and let the blob handle all dtb bits ...
<ali1234> yes, obviously we must always chainload from the blob
<ogra_> in uboot i only call "fdt 0x100" to load it
<ogra_> there are some extras you want to actually get the board serial and MAC though
<ogra_> (RaspberryPi2)ubuntu@rpi2:~$ fw_printenv |grep ^loadfdt
<ogra_> loadfdt=fdt addr 0x100; fdt get value args /chosen bootargs
<ogra_> thats what i use in snappy
<ali1234> so what i'm using is pxe
<ogra_> i then add ${args} to the commandline
<ali1234> or rather the u-boot pxe emulation
<ogra_> that way the serial and MAC (which only the blob knows) are handed over
<ogra_> and you can have the codecs working etc
<ali1234> vmlinuz-4.2.0-1014-raspi2 yeah?
<ogra_> right
<ogra_> and /lib/firmware/4.2.0-1014-raspi2 for the dtb files
<ogra_> (and the overlay subdir)
<ali1234> i won't need the overlay because u-boot can't load that...
<ogra_> right, but you want bcm2708-rpi-b-plus.dtb
<ogra_> err
<ali1234> 2-b
<ogra_> bcm2709-rpi-2-b.dtb
<ogra_> right, sorry
<ali1234> yeah, same name as the foundation one
<ali1234> i already have an identical named file on my server
<ogra_> well, you want the one that matches your kernel :)
<ali1234> nah, it doesn't really matter too much
<ogra_> else you make a mess
<ogra_> sure it does
<ali1234> i'm using one built for 3.18 on a 4.1 kernel right now
<ali1234> it works fine
<ogra_> it is directly tied to the enabled devices from the kernel config, else you will only have half the stuff working
<ali1234> yes, but those don't change much
<ali1234> anyway, enough chat
<ogra_> note that this kernel is using the ubuntu config
<ogra_> same as -generic
<ogra_> so you really dont want to use a foundation 3.18 dtb here :)
<ali1234> okay here we go
<ali1234> aw typos
<ali1234> ogra_: it booted, i have /proc/device-tree
<ogra_> and you have system serial and the actual HW MAC in your system ?
<ogra_> (RaspberryPi2)ubuntu@rpi2:~$ cat /proc/cpuinfo |grep ^Serial
<ogra_> Serial		: 000000008b04db1c
<ali1234> http://paste.ubuntu.com/13102443/
<ali1234> no, serial is 0
<ogra_> right
<ali1234> but that is an entirely different thing
<ogra_> so no video codecs for you and your IP will chane on every boot
<ogra_> i'm surprised though ... what uboot version is that ?
<ali1234> HEAD from two days ago
<ogra_> mine is about 8 weeks old and it doesnt work here
<ogra_> aha
<ogra_> so perhaps it has seen some fixes
<ali1234> must have
<ali1234> anyway the serial number thing is not something that is stored on the SD card
<ogra_> in any case i need the serial since people that want to build snappy kodi appliances will want to use the codecs :)
<ali1234> the point of this whole thing was to prove you could boot a pi with nothing except u-boot and config.txt
<ali1234> and the firmware bins
<ogra_> the serial gets added to the devicetree by the blob when it loads it
<ali1234> oh. well that's just stupid...
<ogra_> as gets the MAC
<ogra_> the blob is the only thing that talks to the HW on that level
<ali1234> well i'll pass this on to the LTSP flks as they will no doubt want to use codecs too
<ogra_> i discussed that with alkis quite a bit in the last weeks :)
<ogra_> so he is aware i guess :)
<ogra_> ali1234, so you are sure it isnt using the dtb that the blob has put into 0x100 ?
<ali1234> since two days ago?
<ogra_> i see you are loading to the same address
<ogra_> no, over the past weeks
<ali1234> yes because my config.txt is completely empty except for the line kernel=u-boot.txt
<ogra_> we didnt talk the last two days
<ogra_> your confi.txt has no influence on the dtb
<ogra_> only on the overlays
<ali1234> ogra_: well it was two days ago he asked on raspberry pi and i got it working
<ogra_> the dtb name and path are hardcoded in the blob
<ali1234> hmm good point
<ogra_> do you have the dtb on Sd next to the blob ?
<ali1234> yep
<ogra_> tyr renaming it or removing it and see if it still boots
<ali1234> although surely if it was doing that, it would have a serial number?
<ali1234> also if i overwrote it, how can it use it?
<ali1234> trying now anyway
<ogra_> (though that wont still tell if uboot actually overwrites 0x100 ...)
<ogra_> you will only have the serial if you handed it to the kernel cmdline
<ogra_> bcm2709.boardrev=0xa01041 bcm2709.serial=0x8b04db1c smsc95xx.macaddr=B8:27:EB:04:DB:1C
<ogra_> you need these three on the cmdline
<ogra_> fdt get value args /chosen bootargs
<ogra_> in uboot after you loaded the dtb
<ogra_> then make sure to have ${args} on your cmdline and uboot shoudl expand it
<ali1234> oh, so that could just be hard coded in the pxe config?
<ogra_> well, but it will only be populated in the dtb the blob did put to 0x100
<ogra_> i'm not sure what happens if you overwrite that area with your tftp retrieved dtb
<ali1234> why does it need to be on the command line and the dtb?
<ogra_> the kernel needs it on the cmdline
<ali1234> yeah it booted with the dt renamed
<ali1234> the sd card one that is
<ogra_> cool !
<ogra_> i guess i'll take a look then ...
 * ogra_ needs to update the snappy device tarball anyway for the rpi 
<ali1234> let me add those numbers on my command line
<ogra_> so what i wonder now is if you can use a fake dtb for the blob ... just to get the args populated ...
<ogra_> ... then overwrite it from uboot with a dtb you load
<ogra_> and if that still boots
<ogra_> that way you get the cake and the tea :)
<ali1234> i don't understand
<ali1234> you mean like pass a fake dt in and then extract out the bits the blob added?
<ali1234> why even use a fake one?
<ali1234> just use the real one...
<ogra_> because the blob will try to add to it
<ali1234> it's going to get overwritten anyway
<ogra_> right
<ogra_> but first you want to extract the args from it
<ali1234> yes we want the blob to add to it
<ogra_> to get the HW data the bkob did read
<ali1234> so use a fake one because it will be easier?
<ali1234> because there's less space to search
<ogra_> i doubt the blob will add the stuff if there isnt *some* dtb
<ali1234> okay my pi now has that serial number you pasted here
<ogra_> well, thats mine :P
<ogra_> it comes from the chip
<ogra_> and you need it to obtain the codecs from broadcom .... they get tied to the device via the serial
<ali1234> yeah
<ali1234> so wouldn't the codecs work even if /proc/cpu shows the wrong serial?
<ogra_> to get your serial you need to get it from the blob ... and thats only possible via the in memory dtb ... which is most likely gine once you overwrite it by loading yours
<ali1234> sure sure
<ali1234> but i mean if the codecs relied on /proc/cpu to validate... then there would be lots of piracy
<ogra_> broadcom will give you a codec that only works on a specific serial ... and i would expect they keep track if they have given it out already
<ogra_> i also guess there is more to it than the cpuinfo serial that gets checked against
<ogra_> i.e. if the codec takes action i would expect it to verify the number against the actual SoC
<ali1234> so at this point we need u-boot to be able to manipulate overlays etc
<ali1234> then we can do this properly
<ogra_> right, i havent seen a way to do this
<ogra_> in snappy i fully rely on the blob for all dtb actiions by now
<ali1234> yeah, can't do that when booting from the network
<ogra_> has at least the advantage that all upstream docs still match :)
<ogra_> you can ... but its ugly
<ogra_> you can obtain the dtb via tftp ... fatwrtite it, set a flag and reboot
<ali1234> hah, like the old N900 multiboot method
<ali1234> reflash the kernel every time you switch OS
<ogra_> as i said ... ugly
<ali1234> no thanks :)
<ogra_> (gets even more ugly if you want to clone the overlays subdir every time)
<ali1234> hmm
<ali1234> actually
<ali1234> you now mkknlimg?
<ogra_> for unboot.bin, yeah
<ali1234> well i didn't run the rpi mkknlimg on my u-boot.bin
<ali1234> which means the blob won't think it supports device tree
<ogra_> (RaspberryPi2)ubuntu@rpi2:~$ grep uboot /boot/uboot/config.txt
<ogra_> kernel=uboot.bin
<ali1234> which means it won't set any device tree
<ogra_> ah
<ali1234> if you put a vmlinuz directly into /boot without running mkknlimg on it, not /proc/device-tree
<ogra_> right, cant do that on snappy
<ali1234> can't do what?
<ogra_> so nothing i ever bothered to experiment with
<ogra_> our kernel lives in a subdir thats selected via uboot scriptery
<ali1234> okay that doesn't matter
<ali1234> the thing is that mkknlimg appends a tag to the elf binary you run it on
<ali1234> the blob look sat that tag to determine if device tree is supported
<ogra_> right, which is needed by the blob
<ali1234> so my u-boot does not have that tag
<ogra_> but only for the first thng you load via the kernel= option in confi.txt
<ali1234> yes which is u-boot.bin
<ogra_> right
<ali1234> which means that the blob will not put device tree at 0x100
<ali1234> because it does not think u-boot supports device tree
<ogra_> oh, for you you mean
<ali1234> yes for me
<ogra_> yeah
<ali1234> who else? ;)
<ali1234> anyway so the question then is how did they pass the serial numbers before dt support was added?
<ali1234> using those kernel params you showed?
<ogra_> ATAGs :P
<ali1234> if so we can rip the serial etc from ATAGS
<ogra_> try it
<ali1234> because those are like a million times easier to parse in u-boot
<ogra_> but i fear if they dropped ATAG support from their kernel their last iteration of the blob might have dropped it too
<ogra_> you ahve to check
<ali1234> that would certainly explain why the kernel failed to boot when i loaded no DT
<ali1234> if there were no ATAGs either...
<ogra_> well, for me it also fails if i load an old dtb because oi forgot to replace it
<ali1234> but no it must still support them because i booted a kernel without DT support when going direct from the blob
<ali1234> hmm
<ogra_> well, try to read them then
<ali1234> i will
<ali1234> also did you run mkknlimg on your u-boot?
<ali1234> if you use the blob for dt management then i think you must have...
 * ogra_ wonders what we talked about the last ten minutes :P
<ogra_> yes, i use mkknlimg on my uboot.bin and define it as kernel= in config.txt
<ogra_> so that the user can define overlays and dt options in config.txt ... uboot just passes the dt trhough
<ogra_> (all i need uboot for is the kernel and initrd selection and the auto-fallback functioality of snappy)
<ali1234> would be nice to have a boot menu for different kernel testing... i should set that up properly at some point
<ogra_> yeah, thats trivial with uboot
<ogra_> especially since the rpi one has framebuffer support by default
<ali1234> i only have serial and ssh on my pi
<ali1234> a failsafe initrd would be handy too
<ogra_> reimplementin snappy ? :)
<ali1234> well snappy doesn't work on the model a :P
<ogra_> (we call it recovery there though)
<ali1234> and about that
<ali1234> i did an rdepends on all those snappy packages
<ogra_> yeah, old HW is old HW
<ali1234> it was absolutely huge so i gave up
<ogra_> an rdepends ?
<ogra_> on what now ?
<ali1234> remember we talked about porting snappy to raspbian?
<ogra_> vaguely
<ali1234> well it looks really hard
<ali1234> even with jessie
<ogra_> yeah, its a bit bloated currently
<ogra_> we'll do some cleanup work soon
<ogra_> snappy source is now on github btw
<ogra_> (for the snappy binary)
<ali1234> i calculated all the packages in the snappy core image that aren't in jessie, and then did an rdepends on them and calculated the list of those packages not in jessie
<ali1234> the first list was about 20 packages, the second was about 80 packages
<ogra_> did you talk to alan bell ?
<ali1234> not recently
<ali1234> i know he was trying to set up a compile farm some time ago
<ogra_> he actually wanted to rebuild the archive on his cluster
<ali1234> i funded part of his kickstarter :)
<ogra_> doing the same raspbian did to debian but based on the ubuntu archive
<ogra_> not sure where that went
<ali1234> afaik nowhere
<ogra_> (simply rebuilding everything as armv6)
<ali1234> okay so i just dumped 0x100 and it looks like ATAGs to me
<ogra_> and ? any valuable data in there ?
<ali1234> http://paste.ubuntu.com/13102809/
<ogra_> or just random basics
<ali1234> the serial for one thing
<ogra_> yeah
<ogra_> !
<ogra_> nice one
<ali1234> so the way we did this on N900 was just to not touch the atags set by previous bootloader
<ali1234> but u-boot upstream did not like that very much
<ali1234> but the point being we never actually parsed them
<ali1234> and we can't reuse atags when booting device tree
<ali1234> erm...
<ali1234> u-boot has a command "fdt get"
<ali1234> we can just use that to read from the blob's fdt before overwriting it?
<ali1234> is also has "set"
<ogra_> i think that didnt work last time i tried
<ogra_> (didnt boot anymore)
<ali1234> how does a bootloader pass the command line to the kernel when booting with device tree?
<ali1234> in general i mean...
<ali1234> also, multiple device tree blobs are allowed?
<ali1234> so then pass an empty one to the initial bootloader and then load ours into a different place?
<ali1234> that might just work...
<ali1234> or maybe even none at all
<ali1234> hmm
<ali1234> i need to run mkknlimg on my u-boot
<ogra_> heh
<ali1234> ogra_: mkknlimg refused to operate on my u-boot.bin, any hints?
<ogra_> hmm, not really
<ali1234> * Is this a valid kernel? In pass-through mode.
<ogra_> there is a way to make it ignore that but i dont hav emy notes around
<ali1234> okay i'll check the source
<ali1234> ah you force the flags --dtok and --283x
<ali1234> dunno what the atter does
<ali1234> ah, for open source kernels
<ali1234> ogra_: got u-boot tagged now. with no dt file at all, the broadcom blob always puts atags in 0x100 regardless
#ubuntu-arm 2015-11-05
<ali1234> ogra_: so, u-boot can dump a fdt in memory. this is the diff between the dtb put in memory by broadcom, vs loading the same dtb with u-boot: http://paste.ubuntu.com/13111353/
<ogra_> ali1234, well, pretty much the cmdline .... overlays would show up there too i guess
<ali1234> i didn't load any overlays but yeah they would
<ali1234> but the serial number/mac stuff is in there too
<ali1234> i reckon u-boot is capable of even loading overlays
<ali1234> and even parameters
<ali1234> it would need a really big script though
<ogra_> i dont mind big scripts .... :)
<ogra_> the question is, can uboot pverwrite 0x100 after you already loaded the blob fdt from there
<ali1234> sure, of course
<ali1234> it's just memory
<ogra_> well, i guess it can ... the question is can it re-read from there rather
<ogra_> or does it fall over if you call the fdt command twice
<ali1234> no, absolutely not
<ogra_> perfect
<ali1234> you can load a fdt, extract stuff from it, load a new one and insert stuff into it
<ali1234> you can even have more than one in memory at once if you like
<ogra_> so you can read the cmdline stuff and then overwrite with your own dtb
<ali1234> you just change the active one with fdt <addr>
<ali1234> *fdt addr <addr>
<ali1234> and you can store the values into variables
<ogra_> sure, thats what i do already when loading the initial dtb
#ubuntu-arm 2015-11-06
<Elguapo> hola buenas tardes aqui ayudan todo sobre linux
#ubuntu-arm 2016-11-07
<dael> Hey there. I'm trying to install Ubuntu arm on a BeagleBoard xM using the prebuilt image according to  http://elinux.org/BeagleBoardUbuntu#BeagleBoard_xM
<dael> Starting Ubuntu on the board, there's a blank/black screen showing a blinking underscore and there it's stuck
<dael> Any advice to go further? I plugged in a network-cable, however, I don't know the ubuntu's ip configuration to get a connection
<dael> The same blank screen occurs by switching to another xM board. Angstrom was running fine
<dael> I'll have a look at the logs the next days. Thanks in advance
<WpgmGQjkSLv> https://www.youtube.com/watch?v=3EsJLNGVJ7E & https://wikileaks.org/podesta-emails/emailid/15893, https://wikileaks.org/podesta-emails/emailid/23561, http://www.reuters.com/article/us-usa-election-foundation-idUSKBN12Z2SL & https://wikileaks.org/podesta-emails/emailid/3774 (ctrl+f qatar) - please don't let these be buried
#ubuntu-arm 2016-11-08
<hmw_> hi
<hmw_> I'm running ubunt 16.04 on a terasic DE1_SOC with a 3.12 kernel. i now have a problem upgrading libc6
<hmw_> it is giving me this as error message:
<hmw_> (Database wordt ingelezen ... 51855 bestanden en mappen momenteel geÃ¯nstalleerd.)
<hmw_> Uitpakken van .../libc6_2.24-3ubuntu1_armhf.deb wordt voorbereid...
<hmw_> readlink: invalid option -- 'm'
<hmw_> i tried to do a  apt install -f but still get this error message
<hmw_> hi any one knowledge how to upgrade libc6?
<sur5r> Hi all!
<sur5r> Seems like ports.ubuntu.com got inconsistent, where do I report this?
<k1l> inconsitent like what?
<sur5r> PAckages vs. pool.
<sur5r> xenial/universe/armhf claims to have pool/universe/r/rpm/librpmio3_4.12.0.1+dfsg1-3build3_armhf.deb but that doesn't exist
<sur5r> it does exist in pool/main/ however
<sur5r> but src:rpm is in universe, not in main
<sur5r> ok same goes for src:xmlto
<sur5r> something is very wrong
#ubuntu-arm 2017-11-10
<DarkSpartan> anyone that cam help me?
<DarkSpartan> i need help in permanently installing ubuntu on my android 4.0 device
<DarkSpartan> anyone?
<DarkSpartan> hello?
<DarkSpartan> i need help in installing ubuntu arm
