#ubuntu-arm 2009-10-05
<ali1234> those instructions have been cribbed from here i guess: http://www.aurel32.net/info/debian_arm_qemu.php
<ali1234> debian probably loads the tun module by default
<hamannp> I'll check it out.  I'm kinda self taught, so my networking knowhow is spotty.
<hamannp> Worse, still, I'm long on academics.  It let's me dream up sophisticated ways to get in over my head.
<hamannp> Ciao!  I'm sure I'll see you around this channel.
<lool> ogra: We have a really serious issue
<lool> ogra: our redboot binary doesn't work on b2.5 anymore
<lool> or perhaps it's related to some settings
<lool> ogra: I couldn't boot my b2.5 since a week or so
<lool> ogra: I manually replaced redboot on the SD card with the one from the archive, and it didn't work
<lool> ogra: I manually replaced redboot on the SD with the latest one from FSL and it worked
<lool> ogra: So it seems related to fconfig data
<lool> ogra: I rewrote a live image and it worked
<lool> ogra: I suspect we need to update the fconfig data on redboot upgrades
<lool> I cant reproduce it anymore now since I wiped the SD card with the issue
<ogra> lool, weird, works fine here on fresh installs as well as updates
<ogra> lool, i usually try both before i upload the new redboot
<lool> ogra: I dont know what happened; I'm pretty sure it's fconfig data since I rewrote redboot on the SD
<lool> I guess I should have kept a backup, too bad
<lool> ogra: I fear it's something overflowing a var, or a var missing
<lool> ogra: For intsnace UUID= overflowing bootcmd
<ogra> yeah, i usually replace the redboot binary on the running SD i use first
<ogra> and then redo that SD with a completelky fresh setup using the new redboot
<ogra> if both work i upload
<ogra> i cant imagine UUID overflowing bootcmd
<ogra> i had setups where i had to test FSL setup with ten liners more in the bootcmd script
<ogra> *lines
<ogra> do you know which version the old redboot was you replaced ?
<lool> ogra: Hmm good questions
<lool> It was for B2.5 but how old, no idea
<ogra> i know we had a broken one druing early karmic
<lool> ogra: I dont even know how it broke exactly; I had taken the SD out to do various boot testing
<ogra> weird
<lool> ogra: But the way it broke was spectacular
<lool> random leds would turn on
<ogra> wow
<lool> boards would shut off by itself
<ogra> did you have anything plugged into the NIC ;)
<ogra> the grounding issue can affect the whole system ...
<lool> ogra: No, I unplugged everything when that started t ohappen
<ogra> hmm
<lool> ogra: Well the grounding issue wouldn't explain why one redboot worked and not the other
<lool> ogra: Still I'm a bit scared that FSL's uboot worked and not ours
<ogra> no, indeed
<lool> I used the latest one from their SDK 1.6 pre-release
<ogra> ours works
<ogra> it is just featureless
<ogra> and oem wont use it
<lool> Well ours didn't in my test, then worked when I wrote the whole SD image
<ogra> i had it working here
<lool> ogra: Well as I said, I cant reproduce the issue anymore
<lool> Even with our redboot
<ogra> well, up to the u-boot prompt
<ogra> well, i havent heard about such an issue yet and havent seen it myself ... all we can do is keep an eye on it i guess
<ogra> i'll try to make some time free to test the different karmic versions, i still have them around
<lool> thanks
<lool> kubuntu fails to build due to gtk+ -- ironic and suspicious
<ogra> heh
<ogra> i think it uses some qt-gtk translator thingie
<ogra> not sure how it's called nowadays
<ogra> are you sure its gtk itself ?
<lool> ogra:   libgtk2.0-bin: Depends: libgtk2.0-0 (>= 2.18.1-1ubuntu1) but 2.18.1-1 is to be
<lool> installed
<lool> I'm sure yes
<ogra> evil
<lool> I thought gtk wasn't in kubuntu
<ogra> it shouldnt be, did you notify Riddell or ScottK ?
<ogra> i know they have that gtk theme layer handling tool, but that doesnt require gtk
<lool> ogra: I did not
<flaco> hey all.. I'm planning to buy a beagleboard.... and put ubuntu on them... my question is if gstreamer and python works on this plattform
<lool> flaco: Yes
<lool> We dont provide the kernel part though
<ojn> is anyone (community?) looking at wrapping up the various components already?
<ojn> (openmax/gstreamer integration, that is)
<lool> For beagle?  I dont spend much time on beagle support in ubuntu myself nor do I know of people here who do, but there are some community provided kernels out of ubuntu
<lool> Concerning gst or openmax integration, I didnt see the beagle bits myself yet
<lool> Are these fully open?
<ojn> lool: for omap, not board specific really.
<ojn> lool: everything but the code running on the DSP is. The trick is to pick the right TI project, there seems to be a few stale ones. :)
<ojn> (and the code running on the dsp is, for all intents and purposes, equivalent to firmware anyway)
<flaco> lol, thanks for the answer... so I need to build those packages for use on arm?
<flaco>  lool, thanks for the answer... so I need to build those packages for use on arm?
<lool> flaco: You can use the ubuntu user space
<lool> flaco: http://elinux.org/BeagleBoardUbuntu
<Martyn> lool : I just saw a beagle clone that was well made .. it has ethernet (SMSC1918), USB 2.0 host, usb OTG, DVI + hdmi output (and LCD cable via membrane cable), etc...
<Martyn> it's the first one I've seen that is a good "desktop board" contender
<Martyn> frankly the only thing "missing" is 802.11(b/g/n)
<Martyn> and that's that USB is good at
<Martyn> mmmm .. aptitude install rootstock
<ojn> martyn: url/product name?
<Martyn> ojn : it's being made by students at the University of Texas/Austin
<Martyn> I don't think they have come up with a cute name yet.  I heard it called 'PoodleBoard'
<lool> Martyn: ethernet is nice
<ojn> Ah, so not productized (yet). Seems like there are a few already though. IGEPv2 looks promising
<ojn> gumstix overo with tobi comes close too.
<Martyn> the overo is very nice
<Martyn> (and very out of stock, damnit)
<Martyn> I wanted one
<ojn> Martyn: I think they manufacture them in batches, so placing an order makes it more likely to show up soonish. :)
#ubuntu-arm 2009-10-06
<superdug> why am I so impressed with linux on a processor that can run linux?
<ogra> lool, so about imx-libs and xserver-xorg-video-imx and theior linking .... xserver-xorg-video-imx needs to link against mxcfb.h/ipu.h as well (looking for it on include/linux), do you know if the policy allows it that i would copy both headers during package build into imx-libs so it would ship these two in /usr/include/linux and the xserver wouldnt have to be hacked up for isung linux-headers ?
<ogra> s/isung/using/
<lool> ogra: I think this would create another libdrm and I dont think we want that; it sounds like these headers should be in the kernel tree instead?
<lool> ogra: In which case we'd have to build-dep on linux-headers-imx51 instead of linux-libc-dev because of the mx51 stuff not being upstream
<ogra> lool, yes, it is in the kernel tree atm
<ogra> and imx-libs dep on linux-headers-imx51 and build fine with it
<ogra> the xserver has no configure option to add additional includes though
<ogra> and hasnt /usr/src/linux* in its default include path
<ogra> given that apps that build against imx-libs always need to have the headers from linux-headers it would be more easy to have imx-libs ship them in the default include path instead of having to hack up each app that uses them
<lool> Oh right
<lool> ogra: I disagree that we want imx-libs to ship them
<lool> These headers are in the kernel source and should remain there
<lool> ogra: But we might have to move them to the expected place
<ogra> ok, then i'll need to hack up the xserver autofoo
<lool> Or add -I flags when using imx-libs
<lool> ogra: Well you could also copy them in linux-fsl-imx51
<lool> But you'd have to be really careful in only adding new headers
<ogra> hmm, would linking not work ?
<lool> Perhaps it's best to add an -I flag for now; until the headers make it to linux-libc-dev
<lool> To avoid any clash
<lool> ogra: Well linking or copying, yeah, but the issue is that if the upstream kernel or another vendor or another kernel tree (e.g. lange) wants to provide the same filenames, we're in trouble
<lool> While adding the -I is safe
<ogra> i could make a link from /usr/include/linux/mxcfb.h to /usr/src/linux-headers/*.../mxcfb.h in the libimx-dev package
<ogra> i think currently its highly inlikely that we get the same files anywhere
<ogra> ipu.h and mxcfb.h are pretty exclusively only on the imx51 arch
<lool> I'm not too hot on it
<ogra> well, ok, i'll hack up the xserver for now to look in the linux-headers dir too
<ogra> but that makes two packages that have to stay in sync
<lool> ogra: Actually one thing which strikes me is that the headers are under an ABI path
<ogra> right
<ogra> which is pointless unless the patches get actually updated
<ogra> even if we have an ABI bump they usually stay untouched
<lool> ogra: The core of the issue is that we currently rely on linux-libc-dev/armel to build everything on armel
<lool> While we truly have multiple kernel ABIs
<lool> One per subarch
<ogra> yeah
<ogra> plus vendor patches
<lool> We cant have multiple linux-libc-dev
<lool> I think using the upstream kernel ABI/API is best for us by defalut
<lool> But we could use a more specific ABI/API for packages which need it, like here
<ogra> right, but that wont work for such device specific headers
<lool> Still, this should be offered by the linux-fsl-imx51 packages
<ogra> well, i fear any changes in the packaging of linux-fsl-imx51
<lool> So perhaps we should have a linux-libc-dev-fsl-imx51 which would install in /usr/include/fsl-imx51/* (/linux etc.)
<ogra> especially this late in the cycle and with the experience i made this round
<lool> (I'm speaking long term)
<lool> I dont think that's doable for karmic
<ogra> yes, i understand
<ogra> right
<lool> (But I want to get the logic right as to solve this properly next cycle)
<ogra> yup
<lool> ogra: So either imx51 gets merged upstream in the kernel and we use linux-libc-dev (unlikely before long), or we come up with such a hack
<ogra> well, atm there are in max 5 devices
<lool> ogra: I'd rather use a new binary package for this since the linux-headers packages already have use cases
<ogra> so that package would be fairly empty
<ogra> we only use three of the 5 atm
<lool> ogra: I think it would be a full replacement for libc-dev
<lool> ogra: In theory, the ABI could be difference in some places than the upstream one
<ogra> though sahara was enabled in the config, i will probably switch it back on in imx-libs
<lool> ogra: e.g. they could add some fb ABI calls
<lool> (ioctls)
<ogra> ah
<ogra> yep, i understand
<lool> ogra: Is this approach fine with you for karmic+1?
 * ogra thought of it as addon package
<ogra> yup
<lool> ogra: Ok; now looking at what we can do in karmic
<ogra> bloats the archive with duplkicates though ... but surely the best path to take
<lool> ogra: So I dont think we want to change kernel at this point
<ogra> well, both packages arent even in the archive
<ogra> and unlikely to enter
<ogra> so let me add hacks to the packages for now
<lool> ogra: What we could do is have imx-libs build-dep on linux-headers-fsl-imx51 and copy the latest headers from there into imx-libs
<lool> or use them directly there
<ogra> thats what i asked initially for :)
<ogra> it alreayd build-deps on the headers
<lool> Well I prefer planning the clean fix first, then looking at immediate workarounds
<lool> ogra: Do you that in imx-libs or xorg-imx51 or both?
<ogra> and libimx-dev can easily copy them into /usr
<ogra> i would do it in libimx-dev and make it ship them in /usr/include/linux
<ogra> then have the xserver just b-d on libimx-dev
<lool> Well dont you think we can implement the /usr/include/fsl-imx51 part directly?
<ogra> that would mean to hack up the xserver package to look in there
<lool> Which will be needed for the long term plan anyway
<ogra> ok
<ogra> so i'll do both
<ogra> copy the headers and hack up xserver
<lool> Cool
<ogra> thanks :)
<lool> ogra: Do you want to file the bug for the lucid stuff?
<ogra> can do
<lool> Ok
<lool> ogra: I just had this bug again that I did a reboot on babbage 2.0 and it shutdown instead; do you know if we have a bug for that or shall I file one?
<ogra> we dont
<ogra> and i didnt see such behavior yet
<lool> ogra: So reboot works for you?
<ogra> yep
<ogra> but thats 2.5
<JamieBennett> lool: I had the exact same thing yesterday
<lool> Right
<ogra> you have other weird issues on your 2.0
<lool> JamieBennett: On 2.0 and/or 2.5?
<JamieBennett> 2.0
 * ogra remembers the xterm issue 
<lool> JamieBennett: did you try on 2.5?
<JamieBennett> I don't have the lead yet (going to a specialist shop this morning to get it.
<JamieBennett> )
<lool> b444386
<lool> #444386
<ogra> we should try to make that bug appear on 2.5 too, then it would at least shut off at all :P
<lool> Eh
<lool> I thought the same, that it was really ironic that one shuts off too easily while the other cant
<ogra> yeah :)
<JamieBennett> lool: have you seen video issues with 2.0 on the desktop? I have about 20 pixels missing from the top left hand corner running horizontal.
<ogra> could that be caused by the toolchain issue ?
<lool> ogra: make sure you include karmic+1 or something in the headers bug
<ogra> will do
<lool> ogra: No
<lool> The toolchain issues are only problematic when doing stack unwinding in C++ stuff, so not in the kernel
<ogra> ok
<lool> JamieBennett: I did file a couple of video bugs on b2.0
 * JamieBennett goes to look
<lool> JamieBennett: 2.5 is more stable so nobody bothers with the 2.0 specific bugs
<JamieBennett> ok
<ogra> JamieBennett, does it go away if you definate a video= option on the cmdline
<lool> JamieBennett: https://bugs.launchpad.net/ubuntu/+source/linux-fsl-imx51 and ~ubuntu-armel bugs are good places to check for them
 * ogra thinks he has seen that before 
<lool> https://bugs.launchpad.net/ubuntu/+source/linux-fsl-imx51/+bug/430969
<ubot4> Launchpad bug 430969 in linux-fsl-imx51 "Display unstable when running xterm" [Low,New]
<ogra> JamieBennett, make sure to have the laters redboot-tools (0.7) you can easily edit the cmdline with redboot-cmdline from the running system
<JamieBennett> ogra: haven't tried, just strange that its 1px x 20px top left and nothing else
<lool> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/358956
<ubot4> Launchpad bug 358956 in linux-fsl-imx51 "armel Babbage iMX51 line truncation and addition on VGA output" [Undecided,Incomplete]
<ogra> i think it goes away if the driver gets a video= option
<JamieBennett> ok
<lool> JamieBennett: Can you reopen that last bug if it matches?
<JamieBennett> lool: Will do.
<ogra> JamieBennett, try with video=mxcfb:1024x768-32@60
<JamieBennett> ogra: OK
 * ogra hopes he has that right from the top of his head
<lool> JamieBennett: also, the first bug (xterm makes display unstable) wasn't confirmed by anyone else; it's low prio but your confirmation would be nice
<JamieBennett> lool: I'll look into it now
<ogra> lool, the truncation bug is different though ... its just a small square above thats rendered black directly over the applications menu
<ogra> s/above/at the top/
<lool> JamieBennett: Or perhaps file a new bug, use your judgement
<lool> It was painful to setup this local debmirror, but it feels so snappy when I use it that I really don't regret it!
<lool> I think I'll enjoy deboostrap as well
<JamieBennett> Just caught your Bug #430969 on camera lool :)
<ubot4> Launchpad bug 430969 in linux-fsl-imx51 "Display unstable when running xterm" [Low,New] https://launchpad.net/bugs/430969
<lool> k
<ogra> ogra@babbage2:~/devel/kernel/linux-fsl-imx51-2.6.31$ grep -r "pin config changed" *
<ogra> ogra@babbage2:~/devel/kernel/linux-fsl-imx51-2.6.31$
 * ogra scratches his head
<ogra> i wonder where "iomux_config_mux: Warning: iomux pin config changed" might come from on boot
<ogra> its the very first bootmessage the babbage spits out
<ogra> lool, the regulator errors on bug 438680 look suspiciously like a porting error
<ubot4> Launchpad bug 438680 in linux-fsl-imx51 "please quieten down bootmessages" [Low,Triaged] https://launchpad.net/bugs/438680
<ogra> i wonder if i should open a new bug for it
<ogra> ogra@babbage2:~/devel/kernel/linux-fsl-imx51-2.6.31$ grep -r "with no identifier" drivers/*
<ogra> drivers/regulator/core.c:		printk(KERN_ERR "regulator: get() with no identifier\n");
<ogra> lool, i think bug 439282 should be high instead of medium
<ubot4> Launchpad bug 439282 in linux-fsl-imx51 "does not power down the system properly" [Medium,Confirmed] https://launchpad.net/bugs/439282
<ogra> what do you think ?
<lool> ogra: I dont really care beween the two as long as it's fixed   ;-)
<lool> ogra: I dont think it's a big deal for a developer board
<lool> I find it a pain that sound doesn't work because I can imagine people using that for development
<lool> And ethernet not working with NM is also a pain for a desktop use case, since ethernet is in the soc it hits all boards
<lool> But wiring of the PMU is likely to differ per board (as it does on lange for instance) so I'm not too concerned that we use power when off; even if it's a bug we should try to fix for release
<lool> ogra: Not sure what you want me to do about the regulator stuff?
<ogra> nothing, i want to know if you would consider it better being a separate bug
<ogra> i have no idea what it implies if the code isnt properly integrated with the core kernel regulator code
<ogra> the messages seem to come from that
<lool> Oh I dont know either
<lool> probably best to check with kernle folks
<ogra> yeah
<ogra> waiting for brad or some other ARM person to get up though
<NCommander> ogra, I talked w/ cjwatson. The easiest way to get partman-uboot tested is in an alternative CD environment. Probably best if I spend a few cycles working on this with your assistance (as we want alternates anyway ...)
<NCommander> er
<NCommander> lool,
<ogra> NCommander, but d-i should come up, shouldnt it ?
<NCommander> ogra, it doesn't get as far as partman
<ogra> whats the stopper ?
<lool> NCommander: Well they are mostly working already
<NCommander> lool, they are?
<lool> NCommander: For me alternates worked
<lool> I think I tested netboot
<lool> I got the console fonts bug and then the symlink issue IIRC
<ogra> lool, right, cd detection fails on the normal alternates
<NCommander> Oh, netboot works, but there isn't a way to easily preseed on netboot
<ogra> netinst should work if you have a working NIC
 * NCommander notes that he should probably write a boot.scr for netboot soonish
<lool> NCommander: Oh and I had to do the cdrom-detect/try-usb=y thing
<lool> NCommander: There isnt??  I thought there was a preseed file on the CD and it's just a kernel cmdline parameter
<lool> Oh you mean in the image itself; I'm sure we can add that
<NCommander> lool, ah :-)
<lool> NCommander: files are in initrd, so it's probably trivial to add one and add a cmdline arg
<NCommander> lool, yeah, I was going to make that change once I sit down and hit d-cd with a shovel
<lool> it's debian-installer rather
#ubuntu-arm 2009-10-07
<pwnguin> http://dooble.sourceforge.net/maemo_dooblescratchbox2.PNG
<pwnguin> lol
<pwnguin> windows vmware ubuntu xephyr maemo
<siji> hi mike^,
<siji> I successfully compiled clutter 1.0 with EGL support
<siji> Now am getting excellent performance specially with animations etc
<lool> siji: Cool
<Vink___> Hi, how do I create a ubuntu filesystem for ARM, anything simliar to OpenEmbedded?
<Vink___> anyone?
<ojn> Vink___: https://wiki.ubuntu.com/ARM/RootfsFromScratch
<Vink___> Can I compile the rootfs with customized packages? I want to add/ remove a lot of stuff
<Vink___> ojn: Can I compile the rootfs with customized packages? I want to add/ remove a lot of stuff
<ojn> Vink___: It comes with alot of packages already, and the rest you can install with apt-get just like under regular ubuntu/debian
<ojn> If you feel a need to waste computrons on rebuilding your own software every time, then ubuntu isn't the obvious choice. gentoo or OE might be a better base.
#ubuntu-arm 2009-10-08
<dpb> is the current karmic booting on the beagleboard? I'm getting "init: procps main process (670) terminated with status 255" on boot and it stops there
<beyossi> i am looking for a glib-2.20.0 and gstreamer-0.10 packages to be installed by apt-get into my beagleboard. The list of packages with the package name inside is long and I can't find out which is the package I need. can someone help with that?
<beyossi> well, I took the most wider package, so I am sure it depends on the basic library I need :-) -life are easier when you memory
<lool> beyossi: What do you need?
<lool> beyossi: shared library?  development headers?
<lool> beyossi: apt-cache search libglib should give you a list with short descriptions
<lool> dpb: I run karmic on beagleboard
<lool> dpb: Do you use an initrd?
<lool> dpb: Try with an initrd; would also be nice to see your full boot log on serial console
<beyossi> lool: thanks, i found.
<beyossi> my application compilation looks for asm/hwcap.h
<beyossi> any idea what library to install?, is it libasm-dev?
<beyossi> found. you need linux-libc-dev
#ubuntu-arm 2009-10-09
<dpb> lool: I don't use a initrd. Is there some howto how to do an initrd for an arm rootfs? I used rootstock to build the rootfs.
<dpb> lool: here's the boot log if you're interested: http://koti.kapsi.fi/dpb/beagle.txt
<dpb> lool: what kernel do you use? what is recommended?
<lool> dpb: For beagle, there are debian packages on the web
<lool> dpb: http://www.rcn-ee.com/deb/kernel/beagle/karmic/
<lool> dpb: I run a self built kernel
<lool> dpb: Your kernel cmdline looks good, not sure why you dont get further output
<lool> dpb: I didnt reboot in a while since the new mountall arrived
<lool> dpb: It might be that it's borken without an initrd (that should be supported though); to create one, use update-initramfs -c in the chroot
<lool> perhaps using qemu if you dont have working ARM hardware
<lool> dpb: I'm abroad right now, but could probably help more next week
<dpb> lool: ok, thanks
<dpb> lool: hrmm, I wonder why rcn-ee.com and rcn-ee.net has different kernels... .net has much more newer kernels too, with the same exact path otherwise... ;o
<lool> Eh
<lool> No idea
<lool> not running that site
<lool> I'm using my own kernels
<lool> dpb: Otherwise, the linuxomap tree mostly works
<lool> (tmlind'd)
<lool> (tmlind's)
<ogra> grmbl, cdrdao seems to use $(uname -m) at buildtime
<lool> ogra: fix it!
<lool> ogra: I think Jamie was looking at it already
<lool> ogra: Did you see the conversation on the debian patch already?
<ogra> no, i didnt know there is a debian patch
<lool> ogra: You fail basic grep then  :)
<ogra> i just looked at the FTBFS list and started a testbuild with the armv5tel files copied
<lool> 22:38 < JamieBennett> caused by a missing RULES/ file for armv7l
<lool> 22:38 < JamieBennett> has arm4l
<lool> 22:46 < lool> JamieBennett: debian/patches/10-rules-armel.patch
<ogra> funnily fakeroot debian/rules clean does run ./configure for about 40 times
<lool> 22:48 < lool> JamieBennett: Our armel architecture is v6 and Debian's is v4, the build shouldn't have to know about v4 or v7; it would be nice to foce the build to use the target arch instead of the detected buildd arch
<ogra> there is armv5tel
<lool> Did you read debian/patches/10-rules-armel.patch ?
<ogra> nope
<ogra> ogra@dove:~/devel/cdrdao-1.2.2$ less debian/patches/10-rules-armel.patch
<ogra> debian/patches/10-rules-armel.patch: No such file or directory
<ogra> pfft
<lool> 22:50 < lool> JamieBennett: minimum change: add v7l because that's what our buildds are, good change: make the build use the target arch instead of buildd arch, perfect world change: fix the build to detect what it needs to know about instead of trying to support all arches in the world
<ogra> dpatch ... heh
<lool> I don't know what you're looking at, I see the pathc just fine
<lool> dpkg-source: info: extracting cdrdao in cdrdao-1.2.2
<lool> dpkg-source: info: unpacking cdrdao_1.2.2.orig.tar.gz
<lool> dpkg-source: info: applying cdrdao_1.2.2-18ubuntu2.diff.gz
<lool> vi debian/patches/10-rules-armel.patch
<ogra> its .dpatch :)
<lool> It's not
<lool> cdrdao (1:1.2.2-18ubuntu2) karmic; urgency=low
<lool> ogra: We are not Debian  :-)
<ogra> well, thats what the archive gave me
<ogra> cdrdao (1:1.2.2-17) unstable; urgency=low
<ogra> seems my apt cache isnt up to date
<lool> ogra: My version being newer, I suspect you suck   ;-P
<ogra> pfft
<lool> ogra: You're so yesterday-ish
<ogra> heh
<lool> Was pushed Oct 3
<ogra> yeah, i'm working remotely
<ogra> my laptop has my approx instance for my LAN
<ogra> so the dove board doesnt find the up to date source
<lool> haha
<lool> As I was saying you suck  :)
<lool> I'm running a script to disable/enable my mirror when I'm traveling
<lool> But mirror is on the LAN
<lool> ogra: I should mock you again for your slowness
<ogra> :P
<ogra> he cdrdao code should really be fixed to not use uname though
<ogra> *the
<lool> I agree
<lool> Actually I said it earlier  :)
<ogra> .oO(hungry .... it smells so good and i didnt have dinner)
<lool> That said it's probably easier to fix it like Debian for karmic
<ogra> indeed
<lool> ogra: You had 3 beers
<ogra> liquid bread doesnt count
<lool> ogra: And at least 2 cigarettes
<ogra> more
<ogra> i go a smoker room :)
<lool> OMG
<ogra> *got
<suihkulokki> there is a bunch of other packages that use the same build system and will need same fixes
<suihkulokki> basicly all packages from the same upstream author...
<ogra> who evet invented that should be shot
<ogra> *ever
<ogra> ah, k
<ogra> that explains something
<lool> suihkulokki: (I omitted the part of the logs where I name the upstream and complain about him  ;)
<suihkulokki> he-who-name-whe-shall-not-mention
<ogra> do you fear he shows up at your door ?
<ogra> thats just because of the umlauts, no ?
#ubuntu-arm 2009-10-10
<ogra_n900_> well, at least webchat works
<ogra_n900_> hey JamieBennett
<JamieBennett> ogra_n900: Guess you got it working then ;)
<ogra_n900_> nope, webchat.freenode.net FTW
<JamieBennett> :)
<ogra_n900> yay
<playya_> ogra_n900, you already have a n900?
<ogra_n900> playya, yup, nokia gave them away at the maemo summit
<lool> playya_: You dont?
<lool> davidm has one, ogra has one, I have one
<lool> Everybody has one these days
<lool> I bet jamiebennett has one too
 * armin76 doesn't
<ogra_n900> hehehe
<playya_> lool, no. I#m a poor student
<playya_> i hope ogra will be available in gÃ¶ttingen. i need a photo of the device in my hands ;)
<Meizirkki> omg rootstock finally works!
<Meizirkki> w00f :P
<Meizirkki> roope@ruoska-ng:~/Tyokansio/TBuntu/images$ sudo qemu-system-arm -M versatilepb -kernel ./vmlinuz-2.6.28-versatile -hda TBuntu9.10.img -m 512 -append "root=/dev/sda mem=256M ro"
<Meizirkki> Segmentation fault (core dumped)
<Meizirkki> >_<
<Martyn> stragce it
<Martyn> strace it rather
<Martyn> I've been making karmic rootstocks all day
<Martyn> most work
<Martyn> although I'm not using the stock versatile kernel (I have my own extensions)
<Meizirkki> after cahnging -m 512 to -m 256 it booted, but now shows kernel panic
<armin76> feature :D
<Meizirkki> yes
#ubuntu-arm 2009-10-11
<armin76> eFfeM: afaik yup, but lool may tell you officially :)
<armin76> eFfeM: yup as in armv5 is dead wrt ubuntu
<eFfeM> armin76: understood, ty
<lool> eFfeM: We wont provide official armv5 binaries, but I wish we'd have non-official tools + repos to create such binaries
<eFfeM> lool: thanks for the info, guess this means for now I have to move on if I want something more recent
#ubuntu-arm 2010-10-11
<DanaG> http://www.slashgear.com/pandaboard-offers-ti-cortex-a9-omap4-to-imaginative-devs-04105681/
<DanaG> Spiffy.
<DanaG> So the Pandaboard is really close.
<DanaG> Though, it looks like form-factor may be just different enough to make it incompatible with Beagle expansion boards.
<persia> http://pandaboard.org/ is already taking developer applications...
<DanaG> Is the "retail availability" date still NDA?
<persia> No idea :)
<persia> As a result, I believe the answer is probably "Yes", because otherwise I would expect to have heard something.
<DanaG> That's a good answer.
<hrw> moin
<ndec> ogra: hey!
<ndec> so release is up, finally!
<lag> :D
<lag> Are you please with it ndec?
<armin76> celebreate!
<ndec> lag: well extremely!
<lag> ndec: I'm pleased you're pleased :)
<ndec> lag: it's been a really cool project to work with!
<lag> ndec: So what's next?
<lag> For sure
<ndec> lag: natty ;-)
<lag> I've enjoyed it
<lag> Whoooooooo :)
<ndec> lag: well, next step is to release our public PPA
<lag> For sure
<lag> Are we going to be supporting any more boards?
<ndec> not that I know of
<armin76> zumbi_: celebrate!
<armin76> then you can support another distro :D
<lag> armin76: :-o
<lag> There's only need for one distro :)
<armin76> yeah, and 640k ought to be enough for anyone ;)
<ndec> armin76: ;-)
<lag> :)
* ogra changed the topic of #ubuntu-arm to: Ubuntu ARM Discussion & Development | https://wiki.ubuntu.com/ARM | Want to Submit a Bug? https://bugs.launchpad.net/ubuntu/+filebug | Build a rootfs from scratch: https://wiki.ubuntu.com/ARM/RootfsFromScratch |  wanna cross build ? see http://idlethread.blogspot.com/2010/09/cross-compilation-redux.html | Maverick is out ! http://cdimage.ubuntu.com/ubuntu-netbook/ports/releases/maverick/
<ogra> :)
<persia> Why point at cdimage rather than releases?
<ogra> persia, because thats where our release lives ?
<ogra> show me the url on r.u.c and i'll point to it
<persia> You're right.
<persia> That's a regression.
<persia> We were on releases.ubuntu.com for karmic and lucid
 * ogra doesnt see it as a regression, butu yeah
<persia> Well, it indicates we weren't considered part of the release.  Maybe just a social thing.
 * hrw agrees with persia
<hrw> armel looks like 3rdparty in ubunt
<hrw> u
<persia> Anyway, something to target to be fixed in Natty.
<persia> hrw, It's most certainly nothing like 3rd party.
<hrw> but totally outside of official archive
<persia> No.  Just not blessed with release.
<hrw> persia: but also ports.ubuntu.com for last few years instead of merging to archive.ubuntu.com
 * hrw hugs apt-cacher-ng
<persia> That's mostly blocked by some technical limitations of our mirror software, sadly.
<ogra> hmm, https://wiki.ubuntu.com/MaverickMeerkat/ReleaseManifest agrees with you
<ogra> i dont think there is code in place to put them on releases.u.c :(
<persia> Yep.  Go complain to skaet.
<persia> There is code to move from ports/daily{,-live} but maybe not daily-preinstalled.
<ogra> right
<ogra> though i really wouldnt mind keeping them on cdimage
<ogra> simply because it's super confusing having them in the same page with all the other images
<ogra> (and their install instructions)
<persia> ogra, See, the way to solve that is to make them have the *same* installation instructions :)
<ogra> thats not possible
 * persia grumbles at git for being painfully slow and bloated (why download 1GB of stuff for 80MB of data?)
<persia> Yes it is.  Just requires more work, and more time.
<ogra> then the install isntructions get confusing
<ogra> you just move the problem around
<persia> I believe the only remaining obstacles are 1) getting everyone to accept a common first-stage bootloader (e.g. UEFI), 2) porting grub2, and 3) ensuring there is *some* flash on every board to hold a vendor-installed first-stage bootloader.
<persia> This is much better than we were two years ago.  I predict we'll be done in only 5 or 6 more.
<ogra> you are making weird assumptions about HW manufacturers
<persia> Why?  For x86/powerpc the vendors all meet those requirements already.  It's kinda expected for consumer-level general-purpose devices.
<ogra> there is no flash on any of the publically available boards we support except the beagle C4 which is underpowered for these images
<persia> So?
<persia> That's deficient HW.
<ogra> there is neither grub but a properly usable u-boot
<persia> Right, hence point 2) above.
<ogra> which i disagree with
<persia> why?
<ogra> as well as with the other points
<ogra> we have a properly unified bootloader with u-boot
<ogra> its just missing framebuffer support
<persia> Do you not think it makes sense to have first-stage bootloaders managed by folks to do boards (for board-bring-up), and second-stage bootloaders managed by folks that do OSs (for OS bring up)?
<persia> Everyone else is doing it.
<ogra> i do ... but thats what we have effectively with x-loader and u-boot
<persia> Why be different ?  Multiple code paths are harder to maintain.
<ogra> we dont have to maintain them
<persia> If you like x-loader, fine, but x-loader/grub2 is more cleanly aligned.
<ogra> no, its not
<persia> Plus, I think it's easier to use the existing ARM port of UEFI than to port x-loader to everything else.
<ogra> simply because everyone working with these boards has u-boot experience
<ogra> the only missing bit is framebuffer support so the general enduser could get a menu
<persia> So?  Training is easy.
 * suihkulokki thinks u-boot has way more momentum than uefi
<ogra> ++
<ogra> or grub porting (which hasnt even started)
<ogra> and making the boards more expensive by adding NAND doesnt look like a good solution either
<persia> suihkulokki, Could be: I've seen ports to about the same number of architectures for u-boot and UEFI.  I don't really care which is selected, but would prefer there to be one-true-first-stage-bootloader
<hrw> I think that arm boards should go for one simple setup: vendorbootloader + osbootloader. thats done on x86(-64) and works on arm so far with targets which we support
<hrw> forget about grub/arm
<persia> hrw, Precisely.
<persia> Huh?  Which osbootloader then?  Why not use the same as everyone else?
<hrw> persia: we do have it with omap34 - xloader + uboot
<hrw> u8500/linaro also goes that way: something-from-stericsson + uboot
<hrw> atmel at91 (armv5): at91bootstrap + uboot
<hrw> at9200rm: simple-in-cpu-flash-bootloader + uboot
<persia> bleh!  Standardising on uboot would be fine.  Standardising on it as a *second-stage* bootloader just seems like madness, when it can do first-stage just fine, and it can't do useful device-selection.
<hrw> persia: *if* uboot can be 1st stage then let it be. on *rest* let it be 2nd
<hrw> persia: atmel at91bootstrap fits inside of cpu flash. you cant get uboot there
<persia> uboot needs a fair bit of work from what I've seen to allow user selection of boot devices, etc.
<persia> hrw, That's a HW bug :)
<ogra> u-boot is to big for fitting in the ram you have available at that stage of boot
<ogra> you *need* a smaller first stage
<ogra> indeed it could be derived from the u-boot code
<ogra> (as x-loader already is)
<persia> And has been in several cases.
<persia> So sure, maybe I don't actually care that much about standardisation for hwbootloader.
<ogra> i agree that this should be fixed
<ogra> and i know linaro is working on that at least for omap
<persia> I still want the *same* osbootloader for every architecture, and think having a single shared hwbootloader would lead to economies of scale.
<hrw> persia: so port uboot for basic x86
<ogra> you wont get that without the vendors agreeing
<hrw> persia: most of PC are fine with legacy bios + grub. you cant get grub outside of x86 anyway
<persia> hrw, It's been done for a while.
<hrw> and you cant get PC users with uboot
<persia> Hrm?  grub2/powerpc is reputed to work.
<hrw> o.. did not know
<persia> And u-boot claims to support PPC, ARM, AVR32, x86, M68k, ...
 * hrw moved to coreboot on one machine at home
<hrw> persia: sure. very few x86 chipsets probably
<persia> Oh, I'm sure.  probably mostly VIA ones, for that matter.
<hrw> and they do not boot windows anymore?
<persia> I still maintain there is scope for economies of scale to have one true hwbootloader, and one true osbootloader.
<persia> I wouldn't expect it for the lower-end VIA embedded x86 cores.
<hrw> persia: 5 years and EFI will be x86 desktop standard maybe
<persia> Most of them can't run current Ubuntu (insufficient instruction support)
 * hrw hugs alix.1c with its 2.098s to get init booted from power on
<ogra> persia, oh, btw, i fail to see how that bootloader discussion solves the initial problem of having different methods to write differnt install media
<persia> ogra, Identical OSbootloader means one can use identical procedures cross-arch.
<ogra> i still need to write to different media with different tools
<persia> As a result the means by which I make bootable SD for armel is the *same* as for bootable SD for i386.
<persia> Which means the same instructions, etc.
<ogra> so you run brasero to create an SD card ?
<persia> No.  I use usb-creator.
<persia> (or at least I did last time I tried that for amd64)
<hrw> persia: does any of your pc boots stright from SD?
<ogra> right, on armel you cant even start it :P
<persia> hrw, At least two of them can.  I thikn a third, but haven't tested it.
<ogra> its not installable due to its dep on syslinux
<hrw> persia: and by default you need to press some key during reboot to invoke boot menu and select "this SD please" in it
<persia> ogra, Right.  See, that's a bug in usb-creator: should use grub2: see discussion with superm1 and Bugabundo in -devel whilst you were sleeping.
<ogra> i wasnt sleeping :)
<ogra> and i followed it roughly while my ac100 kernels were building
<persia> hrw, Actually, no, on one of them it tries SD by default (as I discovered when forgetting to remove the SD when trying to reboot, and being confused why it failed)
<persia> ogra, Ah, excellent!  Still, like I said, we're years away.  Even if everyone in the world attempted to start achieving it right now, I don't think it's *possible* to have clean alignment in less than 3 years because of chip layout planning timeframes.
<ogra> yup
<ogra> and given that work on devicetree is already going on in kernel and u-boot i expect that to arrive earlier as a unified arm solution
<hrw> persia: my desktop can boot from sata/pata/usb/cf/sd/sm/ms/xd but for non-sata I need to go to bootmenu, for pata even to bios
<hrw> ogra: 11.10 not earlier
<persia> hrw, That's just a side-effect of your hwbootloader.  If there was the alignment and consensus on a single hwbootloader like I'm advocating, we'd be having a comparable experience.
<hrw> ogra: for Linaro 11.05 DeviceTree will not be ready yet
<ogra> hrw, i dont exepct d-t in less than a year
<ogra> buut thats still quicker than persias estimated 3 years for grub
<persia> 3 years isn't for grub.  It's to fix on-chip ROM codes to not be braindead about what to use to boot hwbootloaders.
<persia> And 3 years is a lower-bound estimate, really.
<persia> (as in, if someone decided to start fixing this today, it would take 3 years for the *first* SoC that wasn't broken to be released)
<persia> Assuming I don't have kernel issues, are there issues expected with do-release-upgrade from jaunty->karmic->lucid->maverick for armel?
<dmart> win go #linaro
<dmart> win go #linaro
<lag> I can feel a new Bootloader coming ... Supports all architectures, all bios', all OS': persia-boot
<persia> lag, That is a frightening concept.  The moreso since I tend to write most stuff in make, which is probably not an ideal language for bootloader development.
<lag> persia: :)
<lag> persia: I can teach you C - it's a small language
<persia> thanks, but I've been taught C a few times: I just haven't used it professionally in something like 15 years, amd my hobby C has all been small patches.
 * ogra sighs ...
<ogra> 3800 mails done, 1400 mails to go
<persia> releases are fun :)
<lag> ogra: Are you back home?
<ogra> lag, yes
<ogra> wading through my mail since two days
<lag> I spoke with ndec this morning - he sounded happy with the release :)
<ogra> on the road i only read what was directly affecting the current work
<ogra> lag, yes, he told me already
<ogra> lag, we still need to solve the sound issue and i need to get the tablet going
<ogra> thats the twoi last bits on my TODO for maverick
<lag> Sounds == userspace (last I heard)
<ogra> oh, and bug 657732 is an intresting one ... i could reproduce it on the tegra
<ubot2> Launchpad bug 657732 in xaos (Ubuntu) "xaos has artefacts on first frame with -threads (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/657732
<lag> sound*
<ogra> lag, not clear yet
<ogra> lag, there seem to be initialization bits missing but its not clear where
<ogra> to me it looks like the driver needs the init after the mixers were set
<ogra> which would be a clear driver issue
<lag> Quite
<ogra> but it could as well be a race in alsa userspace
<ogra> thats why its so hard to pin down
<lag> I believe Mathieu has been liaising with various kernel and TI people to have this issue solved
<ogra> rama from TI (the omap4 ASoC driver dev) was working directly with lrg on the issue but there was no outcome yet
<lag> Well if they can't fix it, then we have an issue
<ogra> they still try i belive
<lag> lrg wrote most of ASoC
<ogra> i know
<lag> He would be 'the one' AFAIC
<ogra> and rama most of the omap4 driver ... and he worked on the HW too
<lag> Then we have the best people 'on it'
<ogra> no
<lag> ?
<ogra> because nobody seems to have deep insight in the ubuntu specifics of alsa
<lag> What if we lent diwic to them?
<ogra> as i understand it alsactl restore is supposed to do the same as alsactl init for example
<ogra> but that either doesnt happen or happens in the wrong order for the device
<ogra> lag, how much does he know about the userspace ?
<lag> He is Ubuntu's Audio guy
<ogra> the prob with alsa is that the line between kernel and userspace is really blurry in ubuntu
<lag> I think that is the case with ALSA generally
<ogra> there are many bits expected by the driver that imho should be in userspace
<ogra> but alsa generally doesnt depend on i.e. pulse to set all mixers :)
<ogra> at least in the rest of the world
<lag> diwic is afk, but I'll hassle him later
<dcordes> hi
<ogra> lag, ok, i'll try to get rama on IRC (dont know his nick, i need to find out if TX gets up)
<lag> Where is lrg?
<lag> TX?
<lrg> lag: UK
<lag> BANG!
<ogra> no idea, i know he uses to live in the UK
<lag> Hello Liam
<lrg> ogra: my panda is very ill
<ogra> heh
<lrg> hey
<ogra> lrg, still ? :(
<ogra> sh*t
<lrg> ogra: hw issue :(
<lrg> so I'm using SDP now
<lrg> Hey Lag
<ogra> should be fine as well
<lag> Where in the UK are you?
<ogra> lrg, any idea about the issue ?
<lrg> lag: just north of Edinburgh
<lag> Just over the bridge?
<lrg> ogra: afaict the USB hub is a bit broken
<lag> :)
<lrg> lag: yes
<ogra> lrg, i meant the sound issue with the SDP4430.conf :)
<lag> That's a nice area
<lrg> ogra: ah, I'm just starting to look now that I have 10.10 running on the SDP, although ubiquity kept crashing for me so I had to do some manual hacks to setup a user account etc
<lag> Do you know Queen's Ferry?
<lag> Do you know Queensferry?
<XorA|gone> lag: that would either North or South, there is no such town named on its own
<ogra> lrg, kept crashing ? how ?
<lrg> lag: Yes, very close :)
<lag> That's a scary little place if you're not a 'local' :)
<XorA> lag: Im going to assume from your IP your in Bristol or South Gloucestershire :-)
<lag> Bristol
<lrg> ogra: it would crash after 30secs in the help pages
<ogra> hrm
<ogra> with the final release ?
<lag> Where are you XorA?
<lrg> no, a few days ago
<ogra> i know it works for TI Nice who have tested it
<ogra> ah
<XorA> lag: Edinburgh, but I used to work in Aztech West many years ago
<lag> @ST?
<XorA> lag: yes
<lag> I have a few friends there
<XorA> 1999-2000
<lag> They didn't work there then :)
<lrg> ogra, lag: going for lunch now - will be back shortly
<ogra> k
<XorA> worked on the disastrous project for ST GFX card
<lag> Sure
<lag> I believe they've had a couple
<lag> ogra: It looks like diwic specialises in userspace :)
<ogra> awesome
<lag> I will speak to the chain and see if we can free him up
<lag> Hi diwic
<lag> Thanks for joining
<diwic> np
<lag> ogra: ping
<ogra> yes, i'm here :)
<lag> diwic: We have some rather taxing issues with regards to audio on the Panda
<lag> We have two kernel audio experts on the case
<lag> But we are lacking in userspace knowledge
<diwic> okay
<lag> Can we set up some kind of brain storming session when lrg is back and rama is available
<lag> ogra: diwic: ?
<lag> Would you be up for that?
<diwic> sure, at what time approx?
<lag> That would depend
<lag> ogra: Where in the world is rama?
<ogra> TX
<lag> So it would be afternoon
<ogra> yeah
<lag> lrg is at lunch currently
<diwic> My work day is up in ~ 3 hours
<ogra> and i need to get him to IRC first :)
<lag> Sure
<lag> If we can't do it today, I'll set a meeting up and we'll do it later in the week (perhaps tomorrow)
<lag> ogra: Do you have his contact details?
<ogra> no
<lag> Okay, we'll hunt those down
<lag> Then speak to lrg
<ogra> right
<lag> diwic: I'll let you know more as soon as I do
<lag> diwic: Thanks for your time
<ogra> he knows them for sure
<lag> We'll get them one way or other
<lag> robclark will probably know them too
<diwic> lag, okay. For today I can't be online when my work day is up, but tuesday or wednesday might work better, if time zones are a problem
<lag> diwic: No problem - we'll work something out
<cjjnjust> hello, when porting linux to arm, I add printascii("bara bara\n"); in start_kernel. It print other string, and then trap into abort. What wrong?
<lag> cjjnjust: When you say it prints another string, what do you mean?
<cjjnjust> i mean it print the other strings. the string is define in other place.
<lag> You mean it prints out other strings successfully?
<lag> It's just yours that it does not?
<cjjnjust> lag, the string is in other function, it seems like address error
<lag> That's probably what it is then
<lag> Check in: arch/arm/kernel/head.S
<cjjnjust> yes, I have check it again and again...
<cjjnjust> once  call a function with args, it will trap into abort mode.
<cjjnjust> but it can run to start_kernel, when printk("%s",linux_banner); it go to  abort mode.
<lag> cjjnjust: Which kernel are you using? And which Arm chip are you trying to use?
<cjjnjust> lag,2.6.35 s3c2410
<lag> The s3c2410 is already supported
<lag> arch/arm/configs/s3c2410_defconfig
<cjjnjust> I know that .
<lag> Then why port it?
<berco> lag: ogra: can you please invite me to your audio brainstorming too?
<lag> berco: Of course
<cjjnjust> I just want to add some driver on it .
<cjjnjust> use the default config can't work.
<lag> You can use it as a base
<lag> Then edit it
<lag> All of the bring-up and debugging (including earlyprintk) code as already been implemented
<lag> All of the addressing setup code too
<cjjnjust> In fact, I just do what you say.
 * ogra_ac dances ...
<ogra_ac> got an ubuntuized kernel for the ac100
<lag> cjjnjust: Failing that, take a look at this: http://stackoverflow.com/questions/1359919/arm-data-abort-error-exception-debugging
<lag> Will enable you to dump the stack and see where it's going wrong
<lag> ogra_ac: Congrats ... booting?
<ogra_ac> lag, sure, its the toshiba source but with ubuntu config
<ogra_ac> (still 2.6.29 indeed)
<ogra_ac> but all the android crap is gone, i have swp and all modules i can imagine
<lag> So long as you're enjoying yourself :)
<ogra_ac> i|ll test later what mavericks udev thinks about it :)
<ogra_ac> s/swp/swap
<lag> I knew what you meant
<ogra_ac> lag, well, i have a netbook on which i can do ubuntu arm development, what more would a human need :)
<cjjnjust> thanks
<ogra_ac> lag, compiling the omap4 kernel package takes just 2h here
<ogra_ac> (on external USB disk)
<lag> cjjnjust: No problem - best of luck
<lag> ogra: Here being?
<ogra_ac> on the ac100
<lag> It only takes me 15mins :)
<ogra_ac> thats a third of what the buildds take
<ogra_ac> and 30min less than on the panda
<ogra_ac> quite impressive imho
<armin76> wow, hows that? tegra and panda should be same speed, no?
<ogra_ac> similar
<armin76> but 30mins is a lot
<rsalveti> ogra_ac: you should be fine with udev: http://paste.ubuntu.com/510877/
<rsalveti> minimum is 2.6.27
<rsalveti> ogra_ac: with usb on omap4 it takes less than 2 hours
<rsalveti> something around 1:50 minutes
<ogra_ac> with the new mem speed ?
<rsalveti> but this I got when testing with 1gb
<robclark> ogra_ac: on panda with usb disk, I built kernel (just running 'make uImage') in ~35 min..
<rsalveti> ogra_ac: I have the timing with new mem speed, just need to boot my board
<ogra_ac> robclark, ubuntu package ...
<robclark> ahh..  I didn't try that
<rsalveti> robclark: so, how is it going with usb disk?
<ogra_ac> robclark, i build zImage for the tegra in about the same time
<robclark> but on MMC card it was ~1hr.. and with USB disk ~35min (for make uImage)
 * rsalveti is setting up all the boards again
<ogra> bug 657281
<ubot2> Launchpad bug 657281 in ubuntu "Kubuntu Maverick on Omap3 & Omap4: screen goes black and never comes back (affects: 1) (heat: 8)" [Undecided,Incomplete] https://launchpad.net/bugs/657281
<diwic> lag, any news on the brainstorming meeting? I'll have to go in an hour.
<lag> No sorry
<lag> lrg: Are you around?
<lag> diwic: I can't see it happening today
<lag> I'll try and sort something out for another day
<lag> XorA: Are you in the same place as lrg?
<diwic> lrg, isn't that Liam? I think he knows ALSA userspace better than I :-)
<XorA> lag: he is the wrong side of the river
<lag> Ah, do you both work from home?
<ogra> diwic, but not the ubuntu specifics about it i guess
<ogra> i think our setup has a lot of specialities
<lrg> lag: I'm here, diwic lets do this tomorrow as I'm seeing some funny things with our mixers that could cause config to fail
<ogra> \o/
<ogra> someone with a clue
<ogra> YAY !
<diwic> lrg, aren't you the one designing the use case manager?
<lrg> I need to get the mixer thing sorted out and then I should have a better idea whats going on with the config
<lrg> diwic: yes, ucm is in perex ucm branch - he's made some changes and I need him to push to master.....
<diwic> lrg, so then you probably know alsa userspace as well as I, but I don't mind participating in a brainstorming, if not lrg's mixer fixes is what we need.
<lag> lrg: Do you have Rama's contact details?
<lag> lrg: Is it worth pulling him in?
<lrg> lag: yes, rsrimushnam@ti.com
<lag> Okay, I'll send out an email
<lrg> lag: Rama is in Dallas so he's probably around atm
<lag> How does 15:00 UTC grab everyone?
<lag> Tomorrow
<lrg> and he does have a working pandaboard
<lag> Or Wednesday
<lrg> lag: most times are fine for me, Rama has more meetings though
<lrg> best find a time suitable for Rama andI'll join
<lag> I'll email him and try to get him on here
<diwic> works for me, but 14:00 UTC would be even better.
<Baybal> is this day a some kind of a holiday in North America?
<lag> diwic: The Arm meeting is at 14:00 UTC
<lag> Baybal: You mean today?
<ogra> Baybal, yes
<ogra> its the day for that guy who got lost trying to find india
<diwic> lag, so 15:00 UTC tomorrow it is then?
<lag> Baybal: It's Columbus day
<lag> diwic: Provided Rama can make it, yes
<lag> lrg: What's your email address?
<lag> berco: Likewise
<lrg> lag: lrg@slimlogic.co.uk
<lag> Shall we have it in here, or in it's own channel?
<lrg> lag: own channel may be best
<lag> No problem
<prpplague> lrg: greetings earthing
<berco> lag: ok for me at 15.00 UTC
<berco> lag: d-bercovitz@ti.com
<armin76> i'm invited too? *g*
<lag> armin76: If you want to be
<armin76> j/k
<lag> prpplague: David, what are you doing tomorrow @ 15:00 UTC?
<diwic> see you in 24 hours then
<ojn> armin76/marvin24: it's using a nonstandard load address. I'll see why nvidia decided to change that this week, but for now, if you change it manually in the sources you can boot it through fastboot
<ojn> Or, you can flash it instead of fastboot as well.
<marvin24> ojn: you mean from 0xe08000 to 0x108000?
<marvin24> last is reported by nvflash
<marvin24> first is TEXT_BASE in config.mk
<ojn> yeah
<lag> ndec: sebjan: Do you want in?
<ogra_ac> ojn, what are you gusy doing about nvrm_daemon ?
<ogra_ac> *guys
 * marvin24 hope it's being killed
<sebjan> lag: yes, please add me. I'll join if I can
<ogra_ac> marvin24, ++
<ogra_ac> but you wont get any power management or sound without it
<marvin24> ogra_ac: not if you have the right documentation
<marvin24> I wish there would be *any* public docu about tegra
<marvin24> but even the supplemental chip docu is hidden
<ogra_ac> yeah
<ogra_ac> evil
<ogra_ac> i wish TI would have a netbook like the ac100 already
<marvin24> TI is not better, search on the TI website for TPS658600A ...
<marvin24> controller on the ac100
<marvin24> only features, no docu (for free)
<ogra_ac> hmm, i thought i saw wiring docs at some vendor
<ogra_ac> platforms like beagle or panda are surely well documented publically
<armin76> ogra_ac: touchbook?
<ogra_ac> armin76, shudder ?
<ogra_ac> armin76, did you ever hold one in your hands ?
<armin76> nope
<ogra_ac> and did you ever hold an ac100 in your hands to compare
<armin76> nope either
<marvin24> armin76: care to make another try with uboot on harmony with the modified loader address?
<armin76> marvin24: i'll try latter today
<marvin24> that would be awesome!
<prpplague> lag: not sure why?
<lag> We're having a Panda Audio Brainstorming session if you want in
<egost_> hi
<egost_> i'm playing with pre build ubuntu  on blaze. could someone tell me the usename and passwd please!
<hrw> ogra_ac: ac100 on photos looks like polished product. touchbook... looks like beagleboard on steroids
<ogra_ac> egost_, i guess yuo need to ask in an internal channel about that image ... but i would suspect something like ubuntu/ubuntu
<ogra_ac> hrw, yeah, and one is wobbly all over and falls on its face if you remove your hands from the kbd, the other weights nothing and has a super stable case
<egost_> i tried ubuntu/ubunto  doesnt work
<egost_> ubuntu/ubuntu  i mean
<rsalveti> vstehle: ^
<ogra_ac> egost_, where did you get that image ? internal server ?
<egost_> http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/current/maverick-preinstalled-netbook-armel+omap4.img.gz
<rsalveti> if not you can install a new one by following https://wiki.ubuntu.com/ARM/OMAPMaverickInstall
<ogra_ac> i would suspect there is a readme file stored nexdt to it
<ogra_ac> egost_, oh, that wont work out of the box
<ogra_ac> egost_, see rsalveti's link
<rsalveti> egost_: by getting a preinstalled image you need to change mlo, u-boot and unitrd
<egost_> i did it
<rsalveti> following the link should give you a working image
<egost_> i use custom uImage and MLO
<egost_> it booted
<rsalveti> that's the problem
<egost_> but i cannot login
<ogra_ac> it didnt exec the uInitrd
<rsalveti> at least if it doesn't work with the default uinitrd and u-boot, it's not going to open you the installer
<rsalveti> then you don't have a user at the system
<ogra_ac> no, you cant loig in if the uInitrd didnt trigger the user setup
<egost_> ok i understand
<rsalveti> egost_: try first by using these files, then after installing it you can change it the way you like it
<egost_> ok i will try it  ths!
<jcrigby> ogra_ac, I have a panda board with serial number 750-2151-002(b) and one red wire.  Can you tell me what version that is?
<ogra> a red wire ?
<ogra> hmm
<GrueMaster> Sounds like an ES2.0
<ogra> could be es2.0
<jcrigby> rework
<ndec> jcrigby: is it green or black?
<jcrigby> ndec, black
<ndec> jcrigby: when did you get it?
<GrueMaster> Black:  ES2.0 8L
<hrw> egost_: take sd card from board, plug to linux desktop, edit /etc/shadow
<rsalveti> 6layers
<GrueMaster> hrw: Not the issue.
<jcrigby> ndec, got it from asac at Prague
<rsalveti> usually the black with red wire is the es2.0 6 layers
<rsalveti> that doesn't boot anymore with our kernel
<ogra> yeah
<ndec> jcrigby: black is 6-layer board
<GrueMaster> Oops, rsalveti is right.
<jcrigby> ok, that is what I thought
<jcrigby> thanks for the verification
<jcrigby> JamieBennett, ^^
<hrw> jcrigby: another device to be bricked to the wall?
<rsalveti> jcrigby: you can still boot it by reverting patch http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-maverick.git;a=commit;h=b5485d193f8a422901fe7e401542950970121860
<jcrigby> hrw, :)
<rsalveti> and using the older x-loader
<ndec> jcrigby: hrw: that can be a decent build machine, though..
<rsalveti> that's how I'm using mine
<ndec> ndec: I think beta image used to work on this board
<ogra> ndec, until next security fix of the kernel indeed
<GrueMaster> RC should work as well.
<JamieBennett> jcrigby: that is sad news :(
<GrueMaster> Beta was ES1.
<ndec> ogra: so you can use it as a decent build if you disable security updates ;-)
<ogra> right, beta only worked on es1
<ogra> ndec, heh, yeah
<rsalveti> rc should be the best one for es2.0 6 layers
 * JamieBennett will be pestering ogra and GrueMaster for some Linaro testing then ;)
 * GrueMaster thinks JamieBennett can buy his own board when they ship.  :P
<hrw> JamieBennett: soon I will be able to do linaro testing on pandaboard too
<hrw> GrueMaster: first they have to sale...
<JamieBennett> GrueMaster, hrw: need it sooner than that
<hrw> JamieBennett: refresh TI contacts?
<rsalveti> JamieBennett: what do you need to test on it?
<JamieBennett> rsalveti: I need to see if our Linaro images work for a start
<ogra> JamieBennett, as long as they use the ubuntu kernel and bootloader :P
<rsalveti> yup
<rsalveti> and x-loader
 * ogra meant to summarize u-boot and x-loader under bootloader :)
<JamieBennett> rsalveti: right they do but that doesn't mean our netbook/ALIP/Plasma Handset/Headless images work, just that they have the right ingredients ;)
<ogra> headless will, for sure
<GrueMaster> heh
<ogra> all the rest depends on what driver support you need i guess
<GrueMaster> JamieBennett: Can't you test your images with qemu?  :P
 * JamieBennett bemoans the lack of hardware
<ogra> lol
<JamieBennett> GrueMaster: heh
<ojn> ogra/marvin24: nvrm is slowly getting replaced, but it's not a small project
<ojn> power management should work fine without it
<ogra> ojn, awesome to hear
<ogra> well, frequency scaling surely doesnt
<hrw> JamieBennett: there always will be lack of hardware
<ojn> core should do. other parts of the chip is harder to deal with, as with all other socs.
<ogra> ah
<ogra> well, i'm kind of stuck with the toshiba kernel
<ojn> yeah, then you're sol
<hrw> ogra: binary or source?
<ogra> hrw, source
<ogra> but 2.6.29
<hrw> eclair one?
<ojn> nvidia legacy sources are _horrible_. wince code ported over to linux, as far as I can tell.
<ogra> yeah, there are a lot of references to windows in the code
<ogra> even to x86
<ogra> hrw, 2.6.29 one
<ogra> there are android patches but i disabled them all
<GrueMaster> Sweet,
<NCommander> ojn: what's nvidia legacy?
<ojn> NCommander: their old port, not the one re-done by us and android.
<ojn> us, them and android, I should say.
<ogra> weho cares about android :P
<NCommander> ojn: you mean tegra or something?
<ojn> ogra: they're doing good work on the base platform support in this case. :-)
<ojn> Ncommander: yeah
<ogra> ojn, indeed :)
<NCommander> ojn: is there a less sucky base port?
<ogra> but i dont want their modules
<ojn> NCommander: yes
<ogra> NCommander, forget about it on the ac100
<ojn> ogra: the linux-tegra- branch in their kernel/tegra.git is android-free
 * NCommander is a cyanogenmod developer, and we've re-ported several HTC device ports
<NCommander> ojn: trivial to re-add
<NCommander> I have a list of the patches somewhere
<ojn> (tne android-tegra- branch is the one with the android pieces)
<NCommander> But its mostly openbinder, the rest is just gravy
<ojn> NCommander: I don't know what you're talking about. I'm _not_ working on android, and I'm not interested in it.
<Baybal> can we port upstream onto it?
<Baybal> good morning
<NCommander> ojn: I was just bringing up that the android stuff isn't really that crufty
<NCommander> Baybal: onto what? AC100?
<Baybal> yes
<ojn> NCommander: yeah, they seem to be active on .35 at the moment
<ogra> Baybal, which upstream ?
<NCommander> Probably. Depends how extensive tegra's mods are, but I don't really feel like playing with Russell King when I'm not a kernel dev
<Baybal> kernel.org
<ogra> Baybal, if nvidia sends their surces upstream, sure
<ojn> Baybal: kernel.org is not quite there for tegra. Stuff is queued up, but what's already merged is just very basic stuff
<ogra> NCommander, tegra isnt so bad
<NCommander> ogra: I haven't poked their tree. If they're using proper git, then that helps a lot
<ogra> NCommander, toshiba adds sauce on top that needs a lot of work
<ojn> *yawn*
<ojn> Ok, have fun guys.
<NCommander> ogra: hrm. If I ever bother to port AC100 to cyanogenmod (which is doubtful, Ubuntu is more interesting), I'll probably work of NVIDIA's tree and then manually add the Android kernel bits
<NCommander> Lot less messy.
<Baybal> but I hope, Tosh didn't remap registers?
<ogra> NCommander, i thought david got an ac100 for you
<NCommander> ogra: I won't get it until UDS.
<NCommander> ogra: and I still have to track a power plug down for it, as davidm didn't bring it
<NCommander> ogra: I haven't looked at the kernel situation yet, but I'd love ot see the kernel in archive if possible ...
<ogra> NCommander, only the wire
<ogra> NCommander, no way
<ogra> NCommander, you only need the cable from the wall to the power brick
<NCommander> ogra: I take it stock tegra kernel doesn't boot?
<ogra> costs $2 or so
<NCommander> ogra: ah, i got like 10 of those at home, and GrueMaster probably has a box full
<ogra> NCommander, no, there are ODM patches
<ogra> i have the source and have a properly ubuntuized kernel running here
<ogra> but o wont forward port it
<NCommander> ogra: ODM?
<NCommander> oh
<NCommander> d'oh
<ojn> ogra: ah, you were able to replace the kernel after all? nice
<ogra> and that still only gives you basic support
<NCommander> (and yuck)
<ogra> ojn, yeah, got the source on friday
<Baybal> is this Toshiba oem_ec a register based interface?
<ogra> huge ugly tarball
<NCommander> ogra: got a link?
<ogra> http://share.grandou.net/ac100/
 * NCommander downloads
<ogra> NCommander, i also have a boot.img and kernel modules for it packaged up
<ogra> ping me once you get yours
<ogra> even though i might have a proper maverick image ready by then
<NCommander> ogra: thanks. I'm going to just look to see how far this tree diverges from cm-kernel tip.
<ojn> ogra: what wifi chipset does it use?
<NCommander> (probably very, but depending on how (in)sane it is, I might be able to convince someone to do a port)
<ogra> ralink 3070
<ogra> or at least something that runs with that driver
<ojn> ok
<ogra> rsalveti, btw, thanks for the udev tip, maverick udev runs fine now
<rsalveti> ogra: cool
<ogra> sadly xorg still needs an xorg.conf and the kbd driver :/
<rsalveti> well, getting better
<rsalveti> :-)
<ogra> but that and disabling pulse should be the only hacks left
<ogra> i wish i knew what nvrm_daemon does to enable the codec
<NCommander> ogra: magic poke? :-)
<hrw> ogra: I think that it will take some time before xorg.conf will finally die. on my desktop I still have one
<ogra> i have proper alsa devices but nothing attached until nvrm:daemon runs
<ogra> hrw, well, i need it for the input devices
<hrw> ogra: I for output ;D
<ogra> the stuff that was supposed to magically work
<ogra> output works out of the box through framebuffer
<ogra> and its not slow
<GrueMaster> same here on my desktop.  Nvidia dual monitor configuration.
<ogra> what bothers me is that we blantly dropped the kbd driver
<hrw> GrueMaster: ati opensource + two monitors here
<ogra> since "all keyboards work through evdev now"
<ogra> which obviously isnt true
<vstehle> rsalveti: Hi! I wanted to warn you: I will rename the sgx-dkms package on the PPA.
<rsalveti> vstehle: ok, thanks :-)
<vstehle> rsalveti: It will be called 'pvr-omap4-kernel-dkms'
<vstehle> rsalveti: (Could not find a longer name ;)
<rsalveti> yeah, better one
<hrw> ogra: you meant "all 8bit keyboards" I think
<ogra> vstehle, i culd make one up if you ran out of chars
<vstehle> ogra: :)
<ogra> hrw, well, i doubt mine has more than 8bit stuff ... but it isnt recognized at all
<ogra> i need to compile the kbd driver package from debian to make it work
<NCommander> ogra: so you need to use the tobisha tree and not the tegra tree to get a working AC100 kernel? :-/
<ogra> and need the xorg.conf for all input devices
<hrw> ogra: I have keyboard which has 9bit keys... works on linux console but not in x11 ;(
<ogra> NCommander, xactly
<ogra> NCommander, the diff between both would be intresting
<NCommander> ogra: I suspect its got to be relatively minimal
<ogra> NCommander, but the toshiba tarball doesnt have git references in it i think
<NCommander> yeah
<NCommander> I'm looking at that now
<ogra> so diff and patch are your tools here
<ogra> heh
 * ogra just tried a minimally modified panda image on the ac100
<ogra> works fine
<GrueMaster> sweet.
<ogra> xorg, xserver-xorg-input-kbd, diverting the pulse binary and unpacking my modules tgz on it
<ogra> even my BT dongle works now
<rsalveti> cool
<NCommander> ogra: looking at nv-tegra.nvidia.com, it looks like everything Tobisha did is in the 2.6.29 branch ...
<marvin24_DT> ogra: do you think it's worth a try to get u-boot running on ac100?
<ogra> marvin24, sure, why not ... i would love to not need a second machine to upgrade the kernel
<ogra> mvflash is really annoying
 * NCommander would agree except we have no user-accessible serial port so it would be a bit tricky
<marvin24_DT> good, I made a small patch based on harmony, but no luck up to now
<NCommander> ^- to dothe port
<marvin24_DT> I don't know how to setup this mux things and there is no docu
<ogra> NCommander, there is an OTG port ... if you can wire it up in u-boot to be serial you are all set
 * rsalveti lunch
<ogra> but even without, having a bootloader that can read from vfat is still better than flashing
<NCommander> ogra: that requires fun low-level code :-/
<NCommander> and a USB stack
<ogra> i'm sure tegra has something like that
<ogra> there is kernel code to steal from
 * NCommander git clone's the tegra kernel
<NCommander> I'm *really* curious on how far Tobisha changed things
<ogra> they added definitely LCD code
<NCommander> right, but that's a driver
<NCommander> As long as arm/arch/* hasn't been heavy modified, it should be pretty straightforwad to get a stock 29 kernel going on the ac100
<ogra> look for the paz00 (or similar) dir
<ogra> that should have the ODM specific bits
<NCommander> ogra: Tobisha forked off NVIDIA release 9.12.10
<ogra> right
<NCommander> now to just generate a diff and to see how extensive they changed things
<hrw> playing with vendor kernels... suxx always
 * NCommander loves git clone --reference
<NCommander> hrw: well, we'll see how high the suckage factor is
<hrw> yes
<marvin24_DT> NCommander: there is a patch at http://attachments.wetpaintserv.us/yl1upugLD3-jVOiRg2dsLQ1360988
<marvin24_DT> against eclair-9.12.12
<hrw> lot of time passed since http://marcin.juszkiewicz.com.pl/2007/06/21/extracting-diffs-from-vendor-kernels/ post... I learn new tricks, more people to ask ;D
<hrw> anyway - time for me
<NCommander> marvin24_DT: http://git.chromium.org/cgi-bin/gitweb.cgi?p=u-boot.git;a=summary
<hrw> have a nice rest of day
<marvin24_DT> NCommander: yeah, I know
<marvin24_DT> lp/~marvin/ac100/u-boot has some patches
<marvin24_DT> problem is, no console ...
<ogra> make it hardcoded look for mmcblk1p1 and fatload boot.scr
<ogra> the you dont need a console
<ogra> *then
<ogra> its a bit of a blind flight, but if it works you can just edit boot.scr
<NCommander> hrw|gone: ugh, this is a nasty pile of hacks
<NCommander> er marvin24_DT & ogra
<ogra> heh, news at ten
<NCommander> its not super bad ...
<NCommander> Bit messy, but servicable
<NCommander> if tegra had a proper master tree, I'd probably look at porting this onto their HEAD ...
<ogra> NCommander, ojn has a good tree i heard
<NCommander> ogra: for Tegra or AC100?
<ogra> for tegra
<NCommander> hrm
<NCommander> I'll have to look at it, but this is actually not bad at all
<NCommander> There's some board specific code that probably needs refactoring, but the vast maority are minor driver tweaks
<marvin24_DT> ogra: I'm a little confused how to setup an u-boot script, I guess you are more familar with that (and u-boot)
<marvin24_DT> ogra: I added you to my launchpad (u-boot+kernel) project in case you are interested
<armin76> marvin24_DT: -TEXT_BASE = 0x00e08000
<armin76> +TEXT_BASE = 0x00108000
<armin76> thats what i should do?
<devilhorns> ogra, have a minute ?
<marvin24_DT> armin76: yep
<marvin24_DT> it at least changes something here (usb went way)
<armin76> oh, damn
<armin76> i did it wrong yesterday
<marvin24_DT> ?
<armin76> i put u-boot instead of u-boot.bin :D
<armin76> it works now
<marvin24_DT> with changed address?
<marvin24_DT> or without?
<armin76> with
<marvin24_DT> great!
<armin76> let me test with the original one
<armin76> nope, doesn't work
<marvin24_DT> ok, thanks for testing!
<armin76> http://dpaste.com/256412/
<armin76> np, thanks for telling me about the load addr :)
<marvin24_DT> thanks should go to ojn
<marvin24_DT> but it seems that it does not find the flash?
<armin76> seems like it
<armin76> marvin24_DT: but you can't kinda flash uboot, can you?
<marvin24_DT> armin76: you could try to flash it as a kernel and see if it boots up
<ojn> yeah
<ojn> that's the easiest way to do it on a current fastboot setup
<ojn> just give it as the kernel argument
<marvin24_DT> ojn: why is the flash not detected?
<marvin24_DT> still TODO?
<armin76> i have tried that, didn't work
<marvin24_DT> maybe again a problem with the init vector
<ojn> marvin24_DT: what flash?
<marvin24_DT> see http://dpaste.com/256412/
<ojn> armin76: ok. I haven't tried recently, so things might have changed
<ojn> marvin24_DT: Ah, emmc. Well, probably because the emmc is not on that controller on your board? which one is that on? harmony?
<ojn> THe MMC that is probed is the one next ot the PCI-e slots there, not the bayonet one. :(
<armin76> bayonet?
<marvin24_DT> probing is done in board/tegra2/common - correct?
<ojn> armin76: the one that klicks in and out. the one ont he other side doesn't.
<armin76> oh
<ogra_ac> wohoo !!
<ogra_ac> 3G works
<ogra_ac> horrible lag but enough for IRC
<ogra_ac> asac, is it normal that i have to configure the connection before inserting the SIM ?
 * ogra_ac found that very confusing
<marvin24_DT> ah, probing is done in tegra_sdmmc
 * marvin24_DT needs a serial console
<hrw|gone> NCommander: that was over 3 years ago post
<hrw|gone> ah..
 * hrw|gone off
<vstehle-home> lool: Hello LoÃ¯c, are you awake? I am desperately looking for an URL about "croco". Would you have this at hand, please?
#ubuntu-arm 2010-10-12
<devilhorns> ogra, around/awake yet ? :)
<persia> He's typically a couple more hours.
<devilhorns> persia, ahh ok, thanks :)
<persia> Find yourself at a loss during the pause-between-cycles?
<devilhorns> persia, not at all :) plenty todo wrt unity-efl
<devilhorns> persia, but, I do need to discuss something with him
<persia> Ah, I can't help with that then.
<devilhorns> hehe yea
<devilhorns> ogra, when you get online, please drop me a PM. Need to discuss a few things with ya, thanks :)
<lag> sebjan: Do you know who Misael Lopez Cruz is?
<sebjan> lag: he is a TIer working on audio (don't know if he still works on audio, but at least he used to)
<lag> sebjan: Does he still work for TI?
<lag> sebjan: I'm wondering if it's worth asking him to the session
<sebjan> lag: I don't know... best to ask Liam or Margarita
<lag> Sure, thanks
<hrw> ehlo #
<ndec> ogra: hi... fyi: just sent you an email...
<lool> vstehle: http://gitorious.org/croco
<suihkulokki> vstehle what do you want to know about it?
<kornel`> hi
<kornel`> does anyone has some experience of encoding video to h264 on arm processor. with ffmpeg or any other solution (which may use dps as well if necessary, etc) ?
<persia> kornel`, What question would you ask if someone replied "Yes" to that?
<kornel`> is it possible to encode  a live stream with an arm (with neon) processor realtime? and if so, what quality?
<hrw> depends on cpu, method used
<kornel`> i would use arm cortex a8
<kornel`> how much does dsp matters?
<persia> I'm not sure our encoders are NEON-enabled
<hrw> kornel`: there is no such cpu as "arm cortex a8"
<persia> kornel`, DSP only matters if there are kernel drivers or encoder-specific drivers for that DSP.
<ogra> ndec, and i answered it :)
<kornel`> ok thanks for answers
<persia> kornel`, Just as summary, it's known possible for some chips, at some resolutions.  It's unlikely we have a wide-enough body of experience to tell you whether any specific combination works.
<kornel`> persia: right i will buy some and triing :) thanks!
<persia> kornel`, Good luck.  My recommendation is to get one from a vendor that has open encoders that are known to meet your application requirements.  The SoC vendors usually are happy to explain just how cool each chip is.
<armin76> persia: yeah, like nvidia saying they don't need neon because their soc is awesome :P
<persia> armin76, might be though: doesn't it support CUDA or something?
<armin76> cuda on arm? weird
<vstehle> lool: Thanks!    suihkulokki: I want to try croco on top of qemu/pbuilder, to speedup armel builds on PC. I would like to use the cross-compiler on the PC transparently instead of the qemu/armel gcc. This is to build Ubuntu packages. I have had no luck so far with xdeb. Google did not return much about croco, that's why I asked.
<hrw> vstehle: distcc will do work
<vstehle> hrw: I thought about that; less setup on PC, but more intrusive on package (need to override the compiler command, I guess).
<hrw> or add one dir to PATH
<persia> armin76, Why?  the code runs on the GPU anyway: CPU architecture ought be irrelevant.
 * hrw -> food
<persia> amitk, I had a chance to play with your kernel sources this weekend, but unpacking the 2.6.28 /proc/config.gz and `make oldconfig` still asked me *lots* of questions, including some about which boards to support.  Do you have any recommendations for the config for a Netwalker?
<lool> vstehle: You can use the hardening-wrapper trick to workaround this limitation
<amitk> persia: start with mx51_defconfig and add compile-in support for the efikamx
<persia> amitk, So I don't care about any of the options that were set on the Netwalker for the old kernel/
<persia> s:/:?:
<amitk> persia: since all the HW doesn't yet work, no we don't care about the netwalker options ATM.
<persia> Heh, fair.  I'll try it with the mx51_defconfig, and see what works or doesn't.  if I have screen, keyboard, WiFi, MTD,  and SD, I'm sufficiently happy.
<amitk> persia: you'll get serial and ethernet now. The linaro kernel might get the mmc/sd patches too. Wifi is WIP.
<persia> Oh.  Since my hardware has no serial or ethernet, that's not very useful.
<armin76> persia: what wifi does it have?
<persia> armin76, I'm not sure precisely: something that uses "ks7010_sdio"
<armin76> yuck
<persia> Why?
<armin76> just curious
<persia> No, why "yuck"?
<armin76> ah, its a renesas chipset
<persia> And this is bad because ... ?
<armin76> oh, because it didn't ring a bell at all
 * persia doesn't usually see "yuck" used to mean "never heard of it" and wanders off, no longer concerned
<armin76> didn't know that renesas did wifi chips :)
<hrw> persia: ks7010_sdio is kernel module?
<persia> hrw, No, kernel module is ks79xx_sdio
<persia> amitk, Actually, before I give up, are there any tests that I could perform using your kernel that you'd find useful, given no ethernet and no serial?
<amitk> persia: probably not, just wait some more to get the rest of the patches in place..
<persia> amitk, OK.  Please let me know if I can help with testing, as I'll be able to make time for it fairly freely between now and the beginning of April.
<armin76> ogra: does the ac100 have a temperature sensor?
<lool> Hmm
<lool> I've been looking whether extras.ubuntu.com is disabled on ARM or not
<lool> it seems not
<lool> does someone confirm that extras.ubuntu.com shows up in sources.list after an Ubuntu install on ARM?
<GrueMaster> It isn't in the preinstalled images sources.list, just the live images.
<GrueMaster> And yes, I see it on dove.
<lool> GrueMaster: Does it work when you apt-get update?
<lool> GrueMaster: I'd expect some APT errors
<GrueMaster> Yes, I get errors.
<lool> GrueMaster: ah, is this reported somewhere already?
<GrueMaster> Apparently, it isn't limited to armel.  It was discussed a few days ago on #u-release.
<lool> I checked this morning, and saw that the keyring was built on armel, seeded on armel, and that the apt-setup/extras setting was off unless preseeded to true, which is the case in all desktop images
<lool> GrueMaster: Ok thanks
<lag> o/
<ogra> lag, isnt it in 1h ?
<lag> UTC != GMT
<ogra> (unless date -u lies to me)
<ogra> oh, you sheduled it for GMT ?
 * ogra thought he read UTC
<lag> Same thing
<ogra> It will be hosted in #ubuntu-arm on freenode @ 15:00 UTC.
<lag> I forget we're in GMT+1
<ogra> ogra@osiris:/var/build/images$ date -u
<ogra> Di 12. Okt 14:01:59 UTC 2010
<ogra> right
<lag> Bloodly British and their stupid saving hrs
<ogra> heh
<ogra> lag, do you have a build with the changes from liam ?
<devilhorns> ogra, you get my email ?
<lag> ogra: Nope
<lag> Bit late to ask now
<ogra> devilhorns, yes, need to talk with davidm
<devilhorns> ogra, ok, no problem :)
<lag> Let's try this again ...
<lag> o/
<mpoirier> o/
<diwic> o/
<berco> o/
<sebjan> o/
<amitk> \o
<lag> We have an intruder
<lag> ;)
<amitk> ;)
<lag> lrg: ?
 * ogra is here
<lrg> lag: here
<lag> Then we shall begin
<lag> Firstly we need to get everyone up to speed
<lag> I'm guessing lrg knows the most about this
<lag> Care to give us a rundown?
<ogra> do we have rama here ?
<lag> Not seen
<rsrimushnam> Here
<lag> rsrimushnam: Welcome
<ogra> perfect :)
<lag> ...
<lag> ogra: Care to start us off?
<ogra> well, we dont really know ehere the issues lie yet, it is clear that sound currently doesnt work at all on the panda (or other omap4 platforms)
<lag> I thought we had sound via ALSA?
<ogra> there are a) the backend routes not properly set by default
<ogra> b) alsa seems to have issues
<ogra> (i discussed with crimsun last night and he pointed me to a bug i noted into our bug)
<ogra> b might be solved by the SRU crimsun plans
<ogra> lag, we do but thats just through a slightly better hack
<lag> I know there as been a tussle with userspace and kernel with regard to who's problem it is - has this been answered yet?
<lrg> ogra: care to expand on (b)
<ogra> though as i understand it, my hack will turn into the default in future alsa (using the init subdir)
<lag> (b) is a libalsa issue is it not
<lag> Do you have the bug number to hand?
<ogra> lrg, i cant expand much more than whats written on the bug, he just told me it would very likely improve things
<ogra> bug 652035
<ubot2> Launchpad bug 652035 in alsa-lib (Ubuntu) "libasound2 not finding usb sound card (affects: 1) (heat: 6)" [Medium,In progress] https://launchpad.net/bugs/652035
<ogra> seems some of the parsing isnt done right
<ogra> there is an upstream fix and an additional fix crimsun added
<ogra> i wish he could be here now, since he does most of the ubuntu alsa maintenance
<lag> It sounds like there are more issues than meets the eye
<ogra> but it sadly collides with his work hours
<lag> Why do these work on other systems and not OMAP4?
<ogra> lag, well, the bug only explains why i have to call alsactl init manually
<ogra> which is anyway not the target we want to achieve
<berco> Is alsa-utils script call at all? It seems this script resets alsa values and has some cases based on platforms
<ogra> berco, yes, it is called properly
<ogra> and as i said above, the future of alsa seems to be to use these init scripts
<berco> but I don't know if it is called before SDP4430.conf is read...
<berco> it could overwrite SDP4430, right?
<ogra> berco, i didnt use SDP4430.conf at all
<ogra> after boot i have the right mixer settings using my way
<diwic> looking at crimsun's patch for 652035 (which I believe I saw upstream as well), it's about not quitting early when finding gaps/holes in the list of subdevices
<ogra> but no sound until i call aslactl init
<ogra> diwic, so that could be the reason why the extra alsactl init is needed then
<ogra> i.e. my scrip should work fine with that fix
<ogra> but thats only half the solution
<berco> ok. so do we want to fix your way first ogra? or is the purpose of the brainstorm to move away from this method and use SDP4430.conf file?
<persia> ogra, Which init script is your script?
<ogra> persia, the one attached to our bug
<ogra> https://bugs.edge.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/637947/comments/24
<ogra> and
<ubot2> Launchpad bug 637947 in linux-ti-omap4 (Ubuntu Maverick) (and 1 other project) "no sound devices on current ES2.0 boards (affects: 2) (dups: 1) (heat: 26)" [High,Confirmed]
<ogra> https://bugs.edge.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/637947/comments/25
<ogra> berco, well, my script has two probs
<ogra> a) these scripts want more info which the driver doesnt expose atm so we cant really differ between different omap4 boards
<ogra> which is indeed bad unless the blaze uses exactly the same setup
<persia> Ah, OK.  I thought it was something different :)
<ogra> and b) more seriously HDMI doesnt get initialized and exposed to pulse
<ogra> imho b) is only solvable through SDP4430.conf
<ogra> but that could be a massively simpler one if it goes hand in hand with my init script
<ogra> since we dont need to set volumes from the .conf
<ogra> for a) we would need to extend the driver to expose more than just the card name
<ogra> if you look at /usr/share/alsa/init/hda you can see how you can set different mixers based on the board
<ogra> but we would need a mixername
<ogra> note that i also havent tried the fix from bug 652035 yet, all this is based on assumptions
<lrg> ogra: I could also add the machine name etc SDP4430/Panda/Blaze into the card name for (a)
<ubot2> Launchpad bug 652035 in alsa-lib (Ubuntu) "libasound2 not finding usb sound card (affects: 1) (heat: 6)" [Medium,In progress] https://launchpad.net/bugs/652035
<persia> Is b) only soluable through SDP4430.conf?  Can't we hint it by providing more inputs to pulse's module-udev-detect?
<ogra> lrg, yeah, that would be good
<abduenas> I have HDMI working from PA
<ogra> persia, its about outputs :)
<diwic> so for exposing HDMI to pulse, first - do we want one output at a time or is the hardware capable of multiple independent streams?
<abduenas> it's justa a matter of creating a PA profile (which I'm working on at this moment)
<persia> ogra, Right, so we expose more data in /sys/ that udev and pulse use to set the outputs.
<persia> abduenas, We're looking at autodetection solutions only.
<ogra> we want either a selectable output in the audio prefs (with a default to analog) or a mirrored output
<ogra> i'd say
<persia> I think the regular pulse output UI is fine.  Let's not fuss with that.
<ogra> abduenas, we cant touch pulse config
<ogra> persia, yes, its fine and i saw hdmi exposed in it
<diwic> persia, there are already mixer profiles for other cards in the default config
<abduenas> PA profile has nothing to do with touching pulse default.pa config
<ogra> thats what i mean by selectable output
<rsrimushnam> ogra: we need to be able to support discrete streams on different outputs -- not just mirrored
 * jayabharath wonders if davidm is back in town... need to send a platform to hrw...
<ogra> rsrimushnam, right, so selectable with default to analog it is
<persia> rsrimushnam, We can do that, but we don't tend to expose the UI for that by default.  Interested folks are usually directed to install pavucontrol
<diwic> persia, upstream ships with files for e g native-instruments-audio8dj.conf and a few others
<persia> diwic, Yep.
<tw_> Hate to bother you people but were would I go to get some help installing ubuntu on the BeagleBoard.  I have tried http://testcases.qa.ubuntu.com/Install/ARM/PreinstalledImage but it won't boot.
<persia> tw_, Are you able to wait ~45 minutes?
<lag> tw_: #beagleboard
<lag> tw_: #beagle
<lag> Even
<tw_> Yes
<tw_> Why?
<persia> tw_, If the folks in #beagle can't help, ask us again then, and we'll help.
<ogra> thats bad
<ogra> dont point him to #beagle
<ogra> they dont use ubuntu usually
 * persia will help tw elsewhere: please continue the sound meeting
<lag> tw_ I'll talk to you via other means - bear with me
<tw_> btw:  I am using one of the new BB_xm boards.
<diwic> anyway, it all comes down to, either we adjust the mixer names (in the driver) so pulseaudio can autodetect the profile, or we take abduenas PA profile when it's ready
<ogra> where would that pa pfrofile go ?
<diwic> /usr/share/pulseaudio/alsa-mixer/profile-sets
<diwic> and an udev rule to go with it
<persia> Let's do the former.  There's a high likelihood that we'll see lots more boards use this SoC, and we need per-board stuff in the driver anyway.
<ogra> hmm
<lrg> diwic: PA autodetection is wrong, we must be more explicit
<ogra> diwic, how do you make sure that doesnt collide with the already existing udev rule ?
<persia> Did anyone ever get module-udev-detect working?  Last I saw, folks were still hardcoding the modules for pulse.
<diwic> lrg, can you elaborate?
<ogra> persia, yes, my init script works without any extras
<ogra> but with the above limitations
<persia> With regular default.pa?
<ogra> yes
<persia> Oh, cool.
<ogra> no changes to pulse at all
<ogra> just the one line change to 00main and the script in place
<lrg> diwic: auto detection depends on PA making guesses about the underlying audio hardware.
<ogra> and the nasty extra alsactl init call
<persia> Ah, so comment 13 wasn't wrong after all.
<berco> ogra: it's one line in 00main + one omap4 file, right?
<ogra> persia, yes, thats what made me develop that script
<ogra> berco, xactly
<ogra> no further changes
<persia> berco and I had thought that was wrong after some experimentation, leading to the SDP4430.conf route
<diwic> lrg, so then we must trace down where PA guesses wrong and evaluate what to do in each particular case
<ogra> if you then call aslactl init at some point after boot sound works fine through analog
<berco> wondering if we don't want to use udev as much as possible to avoid multiple conf files to maintain
<ogra> udev does its job already
<lrg> diwic: the answer is UCM when it's ready, this way PA does not need to do nasty probing on each PCM that it does now.
<ogra> with the init scrip the mixers are all set properly right after boot (and without asound.state file in place)
<persia> diwic, We'd do that in /usr/share/pulseaudio/alsa-mixer/paths/*, right?
<persia> lrg, Do we expect UCM by February?
<ogra> well, as i understood crimsun UCM is whgat these init scripts are
<ogra> or at lest the start of UCM
<lrg> persia: yes,  we are pshing Jaroslav to move it to his master branch ins alsa-lib.git
<diwic> persia, those provide input for the probing as well as being a poor man's UCM, yes
<persia> Let's design a UCM-based solution then, and use that for Natty then.
<lrg> persia: please everyone feel free to mail Jaroslav on UCM progress on alsa-dev. this may speed up progress
<ogra> persia, we need a solution this week
<diwic> lrg, but UCM or not, having uniform control names is still a good thing
<persia> And provide a pulse profile for maverick users.
<ogra> persia, i dont care about natty
<ogra> the SRU needs to be in before friday
<persia> ogra, But you will, so I'll care for you today :)
<ogra> natty is well ... natty
<lrg> diwic: uniform control names can apply to some audio hardware but unfortunately not all :(
 * persia owns some hardware that would have difficulty with uniform control names
<diwic> lrg, so if this particular hardware can't have standard control names, we write a pa profile to compensate?
<diwic> lrg, assuming UCM is not available
<lrg> diwic: yes, agreed
<persia> So, pulseaudio-profile for maverick and UCM for natty?
<ogra> hrm
<persia> We'll still have 652035 though.
<persia> Has anyone tried the proposed SRU on an omap4 board with the alsa init script?
<ogra> not yet
<ogra> will the pulse profile help to initialize the right backend routing ?
<abduenas> nop
 * ogra doesnt belive it scratches more than the surface 
<ogra> right
<persia> The pulse profile will tell pulse the control names to use.
<ogra> so that doesnt help at all
<persia> Are you saying the HDMI out isn't even initialised with the init script?
<ogra> oh, you mean only for adding HDMI ?
<ogra> i understood as a general solution for the problem
<diwic> I think there is some confusion about the "backend routing", what is that really about?
<persia> Right.  Complete maverick solution is 652035 fix + alsa init script + pulse profile
<ogra> diwic, adding the right codec to the control
<persia> Natty solution would be UCM-based and may or may not need a pulse profile depending on whether we can categorise the hardware sensibly in shipping products.
<ogra> persia, ah, now i understand
<hrw> kgilmer: hi here
<ogra> diwic, currently alsa device 0,0 points to a null sink
<ogra> by default
<diwic> ogra, can all subdevices be used in parallel?
<ogra> i dont know
<diwic> or does the hw just support one stream at a time?
<ogra> i'm really no audio guy, only worked into that during last week :)
<ogra> i think it shoudl support more
<diwic> lrg, ^
<persia> HW supports multiple streams
<Guest56473> Hi i just recentÃ±y buy a DevKit8000 and i want to run Ubuntu on it, i have already read the wiki. But when i boot from the SD the boot hang out
<persia> rsrimushnam, Can you confirm that?
<ogra> but one of lrg or rsrimushnam should be able to answer
<rsrimushnam> It can support more than one stream.  But not necessarily all simultaneously.
<persia> rsrimushnam, Do we need to worry about how many it can support at once?
<Guest56473> at kjourlald
<lrg> ogra: UCM will export this multiple stream info to PA too
<abduenas> PA profile can also tell PA about the other hw devices
<rsrimushnam> worry from what respect?
<diwic> abduenas, that was my thought as well
<persia> rsrimushnam, Limit the number of simultaneous streams in the UI or something.
<kgilmer_> hi hrw :)
<rsrimushnam> I guess the way we had visualized this, PA would route audio to the different available sinks on the driver and handle mixing streams to a single sink there.  So from the UI POV, this should be transparent, I would think,
<kgilmer_> hrw, i'm curious how rootstock differs from oe?  does rootstock run entire build on arm via qemu?
<persia> rsrimushnam, That's easlier then.  Thanks.
<hrw> kgilmer_: it just uses packages from feeds  + some mangling
<diwic> so does the driver "probe" the codec and construct devices appropriately? Or are the subdevices hard-coded in the driver?
<persia> The subdevices appear to be constructed by the alsa init script
<berco> Going back to "Complete maverick solution is 652035 fix + alsa init script + pulse profile". rsrimushnam: are you going to provide us the PA profile?
<rsrimushnam> Yes.
<berco> so are we sure "652035 fix + alsa init script + pulse profile" will be enough? no need for a sdp4430.conf file or else?
<rsrimushnam> abduenas is working on it now.
<abduenas> actually the PA guys are willing to include that on PA package, as native-instruments-audio8dj.conf
<diwic> persia, the init script as posted in comment #25 does not add any subdevices?
<kgilmer_> hrw, packages = binary packages?
<persia> berco, I think ogra said that he didn't need SDP4430.conf with the init script.
<diwic> persia, could you point me to that init script?
<berco> abduenas: ok, I see. That's fair
<persia> diwic, Then I'm mistaken.
<ogra> persia, right
<hrw> kgilmer_: yes
<mpoirier> diwic, the scripts simply connect backends to frontends.
<ogra> diwic, its attached to the bug
<berco> persia: I agree. Just wanted to make sure we discard this approach of SDP4430.conf
<kgilmer_> where do the binary packages get generated hrw?
<diwic> ogra, so it is the #25 comment attachment?
<ogra> diwic, right together with the change to 00main
<ogra> (from 24)
<hrw> kgilmer_: ah that your gentoo roots...
<diwic> so then I'll reask my question: does the driver "probe" the codec and construct devices appropriately? Or are the subdevices hard-coded in the driver?
<ogra> they are apparently not since oyu need that script
<mpoirier> nothing is hardcoded in the driver.
<hrw> kgilmer_: in debian (and derived) binary packages are built by builddeamons
<mpoirier> they FE and bE are initialised and left for userspace to connect.
<diwic> mpoirier, who decides that 0,0 is a null sink and 0,7 (?) is HDMI?
<diwic> e g
<kgilmer_> hrw, ah ic.  those biuld daemons are running on target architecture or they are cross compiling?
<berco> ogra: so for the init script, will it be a udev rule?
<hrw> kgilmer_: target - only native builds are done
<ogra> berco, there is a udev rule already
<mpoirier> diwic:the null sink is simply the first on the list.  I beleive moving it down would put another sync as the default
<kgilmer_> interesting hrw
<lrg> diwic: the pcm mappings are done in the machine driver
<lrg> have a look at sdp4430.c
<ogra> berco, you only need to dump the script into /usr/share/alsa/init/
<berco> ogra: oops, sorry. Thought alsactl init was still missing
 * kgilmer_ sees a chicken and egg problem.
<ogra> berco, right
<hrw> kgilmer_: you mean "bootstrap" problem?
<ogra> berco, but thats only to actually init, the mixers are all set right already and properly routed
<kgilmer_> yeah hrw
<ogra> berco, the hope is that the aÃ¶sa-lib fix solves the needed init
<berco> ogra: missed that one :). Now I understand the #652035 need :)
<ogra> :)
<berco> so just waiting for rsrimushnam profile and we can test :)
<berco> rsrimushnam: when do you think you can provide us a profile-set to test?
<berco> sorry, most likely to be abduenas
<rsrimushnam> we have something started already but we are still having issues with it. abduenas can elaborate
<berco> who provides this file
<hrw> kgilmer_: both distros did bootstrap long time ago
<rsrimushnam> fyi:  I need to drop off in 5 minutes...
<berco> rsrimushnam: abduenas: I think we just need to get a rough idea of the timeframe
<abduenas> i'm just missing the udev rule in /lib/udev/rules.d/90-pulseaudio.rules to be able to read omap3.conf
<abduenas> but i'm udev nubee
<ogra> abduenas, ugh, a udev rule for pulse ?
<diwic> So the problem is then: that PA should switch subdevice on the fly (i e when user switches from "Headset" to "HDMI")  in a way it currently can't do?
<abduenas> sorry meant to say omap4.conf (or wahtever)
<berco> abduenas: don't hesitate to come to this channel and ask for help. If we can we will help
<persia> diwic, Why does it need to be different than what we do for headset/HDMI for anything else?
<lrg> lag: are you taking a note of any actions here btw ?
<lag> I wasn't no
<persia> (irclogs.ubuntu.com can help if it's not being done in realtime)
<ogra> abduenas, are you sure that is used at all when pulse runs on a per user base ?
<berco> ogra: this udev rule already exists.
<lrg> persia: I'm forgetful ;)
<ogra> (which is the default in ubuntu)
<lag> I don't think we have a meeting bot in here
<diwic> persia, current PA structure is either switch between different cards, or switch "connector" (which it does by setting volume controls, not by switching subdevice)
<ogra> berco, right, but i think only if pulse runs as a system daemon it is used
<berco> ogra: I see.
<persia> lag, We don't.  I don't want to have enough meetings here to add one, but I'm willing to be convinced.
<ogra> berco, i'm not sure though
<ogra> berco, abduenas, that should be heavily tested
<persia> diwic, Aha.  OK.  I guess I've not actually used PA with my harder-to-define cards.
<abduenas> i'm able to use it on per-user basis
<lag> persia: No, it's okay :)
<ogra> abduenas, thanks that helps :)
<lag> I we'll have to have a wash-up when the meeting has finished
<lag> Who's doing what etc
<ogra> so who is fixing the driver side ?
<persia> lag, It's also worth separating into two discussions moving forward: maverick hacks and natty solution.
<lrg> ogra: what part of the driver ?
<ogra> to expose the board name
<lrg> the name ?
<lrg> ah, ok - me :)
<ogra> :)
<berco> cool :)
<ogra> like in the hda init file
<ogra> i'm happy to add my init file to alsa-libs in an SRU
<ogra> and the one line change to 00main
<diwic> persia, the question is if that can be worked around in the pa profile, and it might be if the subdevices are stable
<abduenas> i'm working on the PA profile for SDP4430/OMAP4
<ogra> abduenas, will you test on all available omap4 hw ?
<ogra> (panda, blaze tablet)
<persia> diwic, For the small number of devices to be fixed for maverick, I think we can find a way to fake that.  We'll need a richer interface for natty.
<abduenas> i have a blaze but no panda... although i can borrow one ... i think
<Neko> hey guys what's the procedure for cross compiling a package
<persia> Neko, We try to avoid it at all costs.
<ogra> (though i guess we can be a bit ignorant about tablet since it uses a different kernel anyway)
<armin76> haha
<persia> Neko, That said, there's a cross-toolchain package in the archives
<Neko> yes but consider I have a nice fast box here to cross compile xserver or so....
<Neko> I have the toolchain
<berco> abduenas: if you have something to be ready for test, let me know. I can run the test on my panda to help
<Neko> but if I dpkg-build it's gonna use native right?
<persia> Right.
<abduenas> berco: roger that
<ogra> lag, so was that enough as a summary for your notes ?
<persia> And lots of packages are packaged in a way that means they can't be cross-compiled.
<berco> abduenas: also good to be able to reproduce
<ogra> (who -> what)
<Neko> I guess the answer is, then, don't bother..
<persia> That's what we devided, yeah.
<ogra> Neko, so i found the issue to your gdm vs oem-config bug
<hrw> Neko: "xdeb -a armel --apt-source packagename"
<lag> ogra: Sure
<ogra> great :)
<persia> Neko, hrw is the local cross-compilation expert if you really want to dig: just be warned it's not as trivial as just expecting dpkg-cross to actually work.
<lag> Unless there's anything else anyone wants to add?
 * ogra is fine as long as sound works on friday :)
<hrw> Neko: it may fail (probably will). next step is adding "--only-explicit" to xdeb call. this also may fail
<Neko> ogra, amazing what is the problem?
<Neko> I didn't get a bug update
<Neko> hrw, thx maybe I will look into it.. for now though, native, since this seems like it may fail
<ogra> Neko, because the bug is invalid ... its the way rootstock rolls the tarball
<hrw> Neko: last step is "dpkg-buildpackage -b -aarmel" as xdeb steps should give you build deps
<diwic> abduenas, you're also welcome to contact me if you need someone to discuss PA profiles with
<Neko> ogra, argh?
<abduenas> diwic: thnx!
 * berco thinks it "sounds" better than an hour ago :)
<hrw> Neko: debian and derived are not cross compilation ready
<Neko> so maybe update the bug as invalid with a comment that rootstock rolls the tarball badly? :)
<Neko> hrw, I know, nothing is.. :(
<ogra> Neko, if you just use tar, uid's and gid's will be taken from /etc/passwd and group of the host system
<persia> Neko, Just build faster boxes :)
<ogra> Neko, rootstock needs to use --numeric-owner to make sure owners of the files dont change
<Neko> hmm has this been patched already?
<ogra> Neko, thast something you will only hit of you build newer releases on older boxes
<ogra> not yet, i need to discuss with rsalveti once he is back
<Neko> yeah I was building maverick on lucid...
<Neko> but also building lucid on lucid broke like that
<ogra> (public holiday at his place today)
<lag> In case there is any doubt
<lag> [END MEETING]
<lag> Thank you everyone
<lag> I'll be in touch
<diwic> thanks, bye
<Neko> basically because on x86 and armel the user ids not necessarily the same...
<ogra> Neko, well, as long as there is a diff between host and VM
<ogra> right
<ogra> not even between two x86 boxes thats guaranteed
<hrw> Neko: OpenEmbedded allows to cross compile big amount of stuff in automated way
<ogra> the system users are created by the packages
<mpoirier> sguiriec: were you able to bet me docs for the complete audio path we talked about ?
<ogra> so it only depends on the order
<ogra> (in which the packages are installed)
<Neko> hrw yes and opensuse build service manages too.. the big trick is use qemu
<Neko> but installing a full system then qemu then build is overkill
<ogra> opensuse does some very nasty things though
<Neko> yep I know
<ogra> injecting x86 libs and binaries
<sguiriec> mpoirier:I have prepare a picture. Need to make minor correction
<Neko> I got my "I contribute" t-shirt for reporting tons of bugs :]
<mpoirier> sguiriec: cool.
<Neko> okay.. so...
<Neko> ogra, if I hack my rootstock to have this --numeric-owner stuff it will magically start to work better?
<persia> sbuild can run over qemu as well: the results were not as exciting as initially thought...
<sguiriec> mpoirier: sorry a little bit busy on other stuff. Will try to push it today
<hrw> Neko: OE does cross only - qemu is used only for generation of glibc l10n packages (and can be disabled)
<hrw> Neko: but thats #ubuntu not #oe
<mpoirier> sguiriec: that's ok, I've been elsewhere too.
<ogra> Neko, it should, i haent tested it yet but hit the exact same issue as you with a tarred up rootfs that i repacked on different boxes
<ogra> Neko, so finding all tar calls in rootstock and adding --numeric-owner should solve it
<Neko> hrw, I have some experience with OE, but I quit using it about 18 months ago
<persia> Neko, Did you never have success with livecd-rootfs and debian-cd?
<sguiriec> mporier: I will give you the link as soon as I have done the update.
<Neko> persia, I never got to try it
<Neko> I am stuck doing kernel stuff
<Neko> but since mav got released....
<Neko> I am building rootstocks
 * ogra would also recommend livecd-rootfs over rootstock if you want to release images
<Neko> I need a rootstock first before I can do that though
<ogra> rootstock is great for home use
<Neko> chicken-egg really
<persia> Ah, OK.  I'll hope you have a chance to switch before natty, as rootstock isn't tested well, and mostly meant for hacking about rather than working systems.
<ogra> but nothing for doing official releases
<Neko> these rootstocks right now are for *me* only
<Neko> we have released on a board already but.. it was a hateful solution
<persia> For now, stick with what you have.  When you have a few hours, come back, and we'll help you switch.
<hrw> have a nice rest of day
<Neko> maybe in 6 weeks? :D
<ogra> Neko, will you be at UDS ?
<persia> Neko, 6 weeks sounds about perfect, sure.
<Neko> no but Konstantinos will be
<Neko> (markos, armhf debian)
<ogra> we could sit down one evening and fix :)
<Neko> unfortunately UDS happens during the school year so it's impossible for me to take time out to do it
<berco> ogra: do we also need to add the user to audio&pulse groups?
<Neko> yay, ogra, made a little fix for rootstock, worked :D
<Neko> so that numeric-owner thing is exactly it
<Neko> (oem-config still nukes on exit though, I gotta work out how to fix that, but we have a new uboot series coming out.. which will make flash-kernel work better...)
<Neko> btw is the flash-kernel package owner in here
<kgilmer_> ogra, where can i get more info on livecd-rootfs?
<kgilmer_> the default google search isn't very enlightening.
<TAsn> Hey guys, I can't find the SmartQ v7 in https://wiki.ubuntu.com/ARM/DeviceSupport but I remember reading somewhere (sorry, lost the link) that it does in fact work. Is this true? So, is there support? If so, in the form of a repository hosted somewhere? or do I have to compile everything on my own? Thanks.
<ogra> berco, no
<ogra> berco, console-kit cares for that since lucid
<playya_> what are the minimum disk requirements for an arm ubuntu with a tiny window manager (matchbox, unity) ?
<Neko> for the whole unity desktop?
<playya__> i have to recreate my lvm partitions and maybe i can get enough space for an ubuntu
<playya__> but not high priority
<playya_> is ogra's build-arm-rootfs still usable for maverick?
<ogra_ac> playya_, better use qemu-debootstrap --arch armel
<playya_> ok
<ogra_ac> oh, wait, build-arm-rootfs ?
<playya_> yes
<ogra_ac> no, use rootstock
<playya_> i think the resulting image might be to big and the pre's kernel is quite old (2.6.24)
<playya_> maybe i should wait for the pre plus
<ogra_ac> doko, new ac100 image up if you want
<ogra_ac> (with the battery spam patched out of the kernel now)
<Neko__> battery spam? :)
#ubuntu-arm 2010-10-13
<Neko__> ogra, does anyone know why mono doesn't install on armel (especially in qemu?)
<persia> It's a qemu bug.
<persia> directhex got Mono working cleanly on the EfikaMX for maverick.
<persia> (even moonlight)
<persia> If you're using rootstock, don't install Mono until you've booted on the real hardware.
<persia> (unless someone made rootstock work unemulated for native builds, in which case it ought be no issue)
<persia> kmargar, Hey.
<Neko__> persia, I just saw there were tons of bugs in Mono for mx51 (but not dove!) for some reason, and ogra was involved
<Neko__> testing at least
<Neko__> directhex is one of the guys we sent boards to?
<Neko__> the mono guy?
<Neko__> did he have to fix anything or was it just working out of the box at release?
<persia> Indeed.  mono on the i.MX51x was exceedingly painful for a while, but is now sorted.
<Neko__> okay great
<Neko__> so what's the qemu bug :D
<persia> He had to fix something.  There was a blog post.
<Neko__> it would be great if that was fixed
<persia> Well, qemu doesn't support some huge chunk of stuff (you'll see lots of unsupported syscall and unsupported ioctls pass in stdout).
<Neko__> once I finish this next rootstock I am done with it and will start messing with livecd-rootfs
<persia> And something in that unsupported stuff is enough to wedge Mono.
<persia> The impression I have is that nobody wants to fix it, instead switching from qemu-versatile to qemu-omap to collect a separate set of issues, but one that can easily be compared against hardware.
<persia> Whether using qemu-omap is enough to install Mono is not clear to me: there may be more involved.
<Neko__> I saw his post about moonlight and firefox ABIs today
<Neko__> nothing about Mono proper though
<persia> He got Mono working back in Jaunty, but only for some things.  It's a steady progress to test all the corner cases.
<Neko__> I'm impressed that Moonlight is working..
<persia> Moonlight is rather demanding on the CLI, and exercises it fairly well.
<Neko__> I don't understand about this codec pack though
<Neko__> anyway brb Patch Tuesday
<persia> For those lurking, the above is another demonstration why it's handy to run Ubuntu :)
<doko_> ogra: the hint for tar --numeric-owner is missing in your README
<persia> doko_, Please file a bug :)
<lag> Morning
<lag> ogra: Are you around yet?
<hrw> moin
<vstehle> ogra, ogra_ac: Hi, how are you? I am "fighting" with the "install extras" icon right now; we think that universe & multiverse have not been enabled in the preinstalled image, which make installing our "extras" a bit difficult...
<ndec> ogra: lag: hey! questions for the PPA: I see that the builders are idle, however our builds don't get started. is that expected?
<persia> vstehle, Take a look at your /etc/apt/sources.list to verify universe and multiverse are enabled.
<lag> ndec: This isn't something I deal with - perhaps ogra or persia can help?
<persia> Best to ask the launchpad folk (in #launchpad).  My guess would be that it had something to do with natty opening, but there's a high chance I'm wrong.
<persia> ndec, I'm happy to lead the discussion, if you'd prefer, but please also join to provide any support information :)
<ndec> persia: ok
<persia> ndec, Just to confirm, which PPA?
<ndec> persia: well, our private OMAP ppa
<ndec> persia: and I got a 'waiting 11 hours' for an arch all package using an i386 builder...
<vstehle> persia: Well, /etc/apt/sources.list _is_ the problem :) We have those of the preinstalled image. And they don't include multiverse and universe "out of the box".
<persia> vstehle, Aha!  I suspect it's one of the preinstalled vs. performing the install things.  Please file a bug against jasper-initramfs, and we'll sort it.
<vstehle> persia: Hum. Can you "fix" the images on the website? I thought they were released and "frozen" now.
<vstehle> persia: I thought our only options were fixes in the PPA packages, and documentation.
<persia> No, but we can 1) fix jasper to not do this next time images are produced, and 2) brainstorm about ways to work around it.
<persia> There's also bugfix uploads: won't affect the images, but can affect user experience once the user updates.
<vstehle> persia: Ok, I'll file a bug on LP for (1). I am very interested in (2) right now :)
<persia> We'll use the one bug for both.
<persia> Just with two tasks.
<persia> ogra, Did you implement the special software channel as a separate package, or as part of jasper?
<vstehle> persia: Bug #659754
<ubot2> Launchpad bug 659754 in jasper-initramfs (Ubuntu) "Universe & multiverse are not enabled on OMAP4 preinstalled image (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/659754
<persia> Great.  Now to wait for the confirmation of the implementaiton, and we can get started on fixing it :)
<vstehle> persia: I tell you: I am not really worried about the fix for future distributions. What worries me is that users will d/l the OMAP4 preinstalled image, click on the icon and get an error message.
<vstehle> persia: We are thinking about documenting an extra step like "enable multiverse/universe manually" on a website somewhere. Or even more nasty: do some hacks in the ubuntu-omap4-extras package (break the deps on other real packages, perform hacks in postinst scripts). What do you think?
<persia> There's an API to enable universe/multiverse, so we oughtn't have to go to the extreme of a nasty hack.
<persia> Just a matter of determining where/how to drop it in place.
<persia> But I really don't think it's wise not to worry about the fix for future releases: firstly, the SRU process requires "fixed in current development" as a prequisite for an SRU.  Secondly, if we don't fix it in both places, we'll just end up in this state again in six months.
<persia> That said, I very strongly suspect we can get a solution ready for testing within the next 24 hours, and probably within the next 6-8.
<vstehle> persia: Would your solution require an extra user step? Or are you thinking of doing stuff in preinst?
<persia> I was thinking a postinst: just have to think about where.
<persia> But, ideally, the user experience would be nothing other than a regular update.
<persia> For the future, the planned jasper rewrite *should* cover it, and we can do a quick python-apt hack to force-enable for the short-term.
<persia> Ideally, ogra implemented the omap4-special software channel in a separate package, so we can just update that package: this has the lowest chance of affecting others.
<persia> But I'm not precisely certain how that was implemented, which is the main deciding factor for not fixing it now.
<ogra> persia, it is just implemented through a .desktop file containing an aptulr
<ogra> *url
<persia> ogra, No package then?  Darn.
<ogra> nope
<persia> Any suggestions on where we can stick a postinst fragment to enable universe/multiverse?
<ogra> the postinst of the meta needs to be easily able to just rebmove it
<ogra> a package would have gotten in our way
<persia> Aha.  I'll call that excessively layered hackery, but I understand why it was done that way.
<persia> So, what do we have that would only hit preinstalled folk and can enable universe?
<ogra> a package would either have to be seeded or be a dep of jasper
<ogra> in the seed way it would always come back
<ogra> and with jasper it would have been removed with oem-config
<persia> Let's not discuss that implementation now: we can do that in the jasper-rewrite discussion.
<ogra> thanks to the live seed
<persia> Let's talk about how we can SRU a fix.
<ogra> well, first of all livecd-rootfs needs a fix
<persia> Because a pre-jasper-rewrite natty fix is a trivial python-apt call.
<persia> No.
<ogra> it apparently misbehaves
<persia> The model is that the live environment has universe disabled, and it's enabled during install.
<persia> The rationale is to save space for the universe Packages file in the live environment.
<ogra> it writes the sources.list and obviously doesnt write the same default one that ubiquity sets up by default
<persia> And livecd-rootfs does this.
<persia> Right.  Jasper should take care of that.
<persia> (and it's trivial).
<ogra> jasper isnt SRUable
<persia> But the hard question is what to do for maverick.  What can we update that is only going to affect jasper-installs.
<persia> I know/.
<persia> The only reason to add the hack to jasper is to justify the SRU of something else.
<ogra> and we have no package that would just do it
<persia> We have nothing that is only on preinstalled images?
<ogra> nothing apart from jasper
<persia> That makes this tricky :)
<ogra> right
<persia> Do we have any programmatic way we can distinguish a preinstall from an install?
<ogra> not from an oem install, no
<ogra> well, you can check if jasper is installed, but only until oem-config was removed
<ogra> you can also check if the ppa enablement files exist
<persia> Do we do an apt-get upgrade before that happens?
<ogra> no
<ogra> update-manager is supposed to care for upgrades
<persia> Ah, right.  The PPA enablement files are probably a good test.
<persia> Let me rephrase then: do we invoke a python-apt cache update prior to oem-config?
 * persia really doesn't care *how* the apt-cache is updated, but whether it is updated
<ogra> the prob here is that either oem-confir doesnt run apt-setup at all or that livecd-rootfs doesnt enable what it should
<ogra> i'm still tending to blame the latter
<persia> livecd-rootfs is supposed to leave universe and multiverse disabled.
<ogra> why ? thats nonsense
<persia> This is by design for all live environments building from main.
<persia> It saves several megabytes from the CDs.
<ogra> since we enable it by default and give no opportunity to override that
<ogra> ??
<ogra> why would it
<persia> Packages.gz
<ogra> sources.list is setup at a point where that doesnt matter
<ogra> hmm, k
<persia> Yes, but you need an accurate apt-cache to be able to run things like the codec installer from within the live environment...
<ogra> i wouldnt think Packages.gz is that big
<persia> Anyway, it7s not a livecd-rootfs bug.
<ogra> it is
<ogra> for future images we should just enable whats needed in the preinstalled path
<ogra> that wont touch the livefs
<persia> 5MB on my mirror for maverick.
<ogra> nah
<ogra> it gets compressed again
<ogra> wont be 5MB
<persia> Yes, for packages.bz2  Packages.gz is seven and a half.
<persia> Yes it will.
<ogra> well, if you say so
<persia> Maybe 4.5, because squashfs is lzma, but anyway...
 * ogra wont debate that since we'll be adding several 100 anyway in natty
<ogra> no squashfs involved for preinstalled
<persia> Oh, then 7.5 because that's gz.
<persia> Anyway, doesn't matter.  Let's get back to the point.
<ogra> right, whats your suggestion ?
<persia> So, it's trivial to enable universe/multiverse in current jasper by calling into python-apt.
<persia> And we'll use apt-setup to do it with rewritten jasper.
<persia> So natty is sorted.
<ogra> jasper is not SRUable
<ogra> what about maverick
<persia> Yes.
<ogra> i know what to do about natty
 * persia is getting there, and requests a bit of patience for a summary
<ogra> and i wont do it in jasper there since that enfoces a network connection at oem-config time
<persia> No, it doesn't.
<persia> The idea is to use the same sequence of stuff used for normal installs.
<ogra> how do you get the package cachje without network if not at image buildtime ?
<persia> You fail to get it if there's no network, and you set it up to be a request for it in software-sources, so that next time update-manager does a regularly scheduled run, it pulls them.
<persia> And update-manager automatically doesn't do that if there's no network, so you end up doing it the first time the user *has* a network, which is the right time.
<persia> Anyway, can we get back to maverick?  We've agreed natty is easy.
<ogra> k
<persia> So, we can detect that we're in a preinstall because of the PPA enablement files.  And we can detect that universe/multiverse are not enabled, and use python-apt to request enablement.
<persia> What we need is some package to which we can attach the script that does that.
<persia> And that has to *not* be jasper, but something that we can usefully SRU.
<persia> And I don't care about delayed-enablement, because the user has a network connection to download the SRU anyway.
<ogra> k
<ogra> is there a way to enforce u-m directly after login ?
<ogra> without much hackery indeed
<persia> It's already set to run the first time there is both a logged in admin user and a network.
<persia> So we get that for free.
 * ogra has never seen that
<ogra> and by rules of mpt it should only run after 7 days for the first time
<persia> Try doing a networkless install about three months after release sometime, and you'll see it.
<ogra> but i might be wrong
<persia> You can test with a networkless install of lucid today, if you like.
<ogra> it changed between lucid and maverick
<ogra> mvo told me it has to wait 7 days now
<ogra> no matter what
<persia> It runs 7 days after the last run.  ubiquity tries to do an update at install time.  If ubiquity fails to do an update, the last run timestamp is the image creation date, which is more than 7 days ago.
<persia> Unless the implementation changed massively, we ought still get free updates.
<ogra> not my experience and not what i was told for maverick, but if you say so
<ogra> so where would we put it ? we dont have any special packages installed
<persia> Maverick might be different.  Dunno.  We'll check if we find a victim.
<persia> Yeah, the where to put it is the tricky bit.
<persia> Don't we have a kernel SRU pending that's specific to certain hardware?  Could we add it to that?
<persia> (noting that anywhere we put it will annoy the SRU team, so there's no better/worse place)
<ogra> ubuntu-netbook-efl-default-settings ... ?
<ogra> thats quite freely hackable
<ogra> for us at least
<ogra> it will only be installed on arm by default (there is a switch in the netbook seed)
<persia> I think the default-settings package is probably better.  Same argument with the SRU team, but won't block the kernel if it gets sticky.
<ogra> you will never get it on anything but arm
<persia> That's not true.
<ogra> (nothing depends on it on other arches)
<persia> But you won't get it *by default*, and we can guard it with the appropriate preinstall check.
<ogra> only if you explicitly install it by hand you will get it
<ogra> ubuntu-netbook doesnt pull it in, nor does any other dep
<persia> Right.  We have to also consider that case, but I think we're safe if we check for the PPA enablement files in the postinst.
<ogra> yes
<ogra> well, that wont solve omap3
<ogra> i'd say we do an arch check
<persia> Why?
<ogra> check arch, check sources.list, if universe is missing and arch matches, enable universe
<ogra> because omap3 doesnt have a ppa
<persia> If someone decides, for reasons we'll never understand, to use livecd-rootfs to create an i386 preinstall and has this issue, we ought sort it for them as well.
<ogra> that would mean he has to change seeds too
<persia> Unless you want to SRU jasper.
<ogra> an x86 preinstall would still not pull in -efl
<ogra> and jasper on x86 would do nothing wrt ppa
<persia> Oh right, and at that point, it becomes a case of "the bug was reported, and you should have backported the fix from natty".
<ogra> it does an arch check
<persia> OK.  I hate arch checks on general principles, but I think it's probably the least bad option at this point.
<persia> And it's only the omap3 and omap4 images that are broken.
<ogra> it wouldnt do much at all in fact, just enable oem-config and the default session (the latter would be a bug on x86)
<persia> Why would it be a bug on x86?
<ogra> because the efl session cant exist there
<persia> Why not?
<ogra> not from livecd-rootfs
<ogra> because the seed doesnt pull it in, on x86 it defaults to unity
<persia> Different definition of "can't".  Right.  I agree.
<persia> Do you want to summarise the above in the bug, or shall I?
<ogra> it would require massive seed hackery that would make the netbook CD size explode
<ogra> would you ?
<persia> No, but we don't care, because it's large enough to be derivative at that point.
<persia> I'm happy to: let's just recap quick to make sure we agree.
<ogra> tell that to didrocks :P
<persia> 1) Long-term fix is jasper-rewrite
<ogra> he forced -efl off the x86 installs because of size
<persia> 2) short-term natty fix is python-apt hack in jasper
<persia> 3) maverick fix is -default-settings postinst hack with arch guard.
<persia> Look right to you?
<ogra> (which got us in the awkward situation of unity sessioons coming back all the time, since he hardcodes a switch of the session towards unity in his -settings postinst)
<persia> Right, netbook-efl for x86 is only interesting if one drops unity.
<ogra> looks good to me
 * persia updates the bug
 * ogra just did an update on x86 and glares at the (felt) 2mx2m sized button in update-manager "restart now"
<ogra> geez, thats huge !
<ogra> i wonder how that looks on a small screen, it must have 60px padding around the text
<persia> ogra, Could you quickly accept jasper/natty and -default-settings/maverick tasks and reject the other two for bug #659754 ?
<ubot2> Launchpad bug 659754 in ubuntu-netbook-efl-default-settings (Ubuntu) (and 1 other project) "Universe & multiverse are not enabled on OMAP4 preinstalled image (affects: 1) (heat: 10)" [Undecided,New] https://launchpad.net/bugs/659754
<ogra> oh, why are you not allowed to ?
 * persia isn't core-dev
<persia> I'm still writing up the issue, etc.
<mopdenacker> Hi! I'm trying to make a few changes to the uInitrd of pre-installed images, to support installation on the Blaze's eMMC storage. However, the kernel says "failed to execute /init" when my modified uInitrd is used. Here are the steps I took:
<mopdenacker> dd if=../uInitrd of=initrd.lzma bs=1 skip=64
<mopdenacker> mkdir initrd
<mopdenacker> cd initrd
<mopdenacker> lzcat ../initrd.lzma | cpio -id
<mopdenacker> <make changes: just adding "set -x" in some scripts>
<mopdenacker> find . -print -depth | cpio --quiet --dereference -o -H newc | lzma -c > ../initrdnew.lzma
<ogra> persia, hrm, doesnt work
<mopdenacker> cd ..
<mopdenacker> mkimage -A arm -O linux -T ramdisk -C none -a 0 -e 0 -n initramfs -d ./initrdnew.lzma ./uInitrdnew
<mopdenacker> Do you see anything wrong?
<persia> ogra, Ugh.  Maybe accept everything, and we can set somethings to Invalid?
<persia> !paste | mopdenacker
<ubot2> mopdenacker: For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
<ogra> persia, sounds better
<ogra> mopdenacker, thats not the right way, chroot into the filesystem and run update-initramfs (and make sure /proc is mounted ... and unmounted before you leave the chroot)
<mopdenacker> ubot2: ok, I thought this was short enough, but I got it wrong. Will do it in the future...
<ubot2> mopdenacker: Error: I am only a bot, please don't think I'm intelligent :)
<lag> ogra: persia: Explain to me what the default.pa file does for _us_
<lag> ! mopdenacker | lol
<ubot2> Factoid 'mopdenacker' not found
<persia> lag, Ask me again in 10 minutes.
<lag> I just want a short explanation for my write-up
<ogra> lag, imho it gets constantly in our way :P
<ogra> (but dont put that in your summary )
<lag> ogra: That's not helpful
<lag> Why do we need it?
<lag> ogra: You contradicted yourself
<lag> 1. HDMI doesnt get initialized and exposed to pulse
<lag> 2. its fine and i saw hdmi exposed in it
<ogra> lag, when hacking default.pa
<ogra> you pulled that out of context :)
<ogra> we cant hack default.pa because it breaks all other arches
<persia> ogra, Note that Kubuntu is also affected.  Do you know if the PPA enablement stuff works there?
<ogra> persia, no idea
<mopdenacker> ogra: I kind of disagree. It never hurts to understand the lowlevel formats. Would you still go through elaborate scripts (which could go wrong in multiple ways) to make a quick change to an initramfs if it was just a plain compressed tar archive?
<lag> ogra: But I thought that was the solution until UCM comes along
<ogra> mopdenacker, yes, always
<ogra> lag, what ? editing default.pa ? no, thats no solution to anything
<ogra> lag,  as i undrestood we'll get a pulse profile that will fix that
<lag> What's the difference between default.pa and the Pulse profile?
<ogra> they live in different places and the profile can be card specific
<persia> ogra, Please *accept* the maverick task.
<lag> Ah, that clears a lot up
<lag> I thought they were the same thing
<lag> What's the Pulse profile called? And where does it live?
<vstehle> persia: I am not sure I understand all the outcomes of your discussion with ogra; what will the end-user see after all? D/l preinstalled image, receive "magical" update due to "older than 7 days", then click icon and everything ok?
<lag> /usr/share/pulseaudio/alsa-mixer/profile-sets?
<ogra> persia, invalidated the jasper bug for maverick and accepted both tasks
<lag> Oh, that's what the default.conf is?
<persia> vstehle, That's the idea.  If nothing else, the apt cache update to get the PPA stuff ought get the universe stuff as well.
<mopdenacker> ogra: I'm still not sure I will go this way. But thanks for your answers anyway :-)
<lag> !help
<ubot2> Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-)
<ogra> mopdenacker, at *least* make sure you pack the initrd the exact same way update-initramfs uses
<lag> !commands
<ubot2> The linux terminal or command-line interface is very powerful. Open a terminal via Applications -> Accessories -> Terminal (Gnome), K-menu -> System -> Konsole (KDE), or Menu -> Accessories -> LXTerminal (LXDE). Guide: https://help.ubuntu.com/community/UsingTheTerminal
<vstehle> persia: But how could you change the apt-cache update in the preinstalled image?
<lag> !stupid-bot
<ubot2> Factoid 'stupid-bot' not found
<lag> !factoids
<ubot2> Hi! I'm #ubuntu-arm's favorite infobot, you can search my brain yourself at http://ubottu.com/factoids.cgi | Usage info: http://ubottu.com/devel/wiki/Plugins | Bot channels and general info: https://wiki.ubuntu.com/IRC/Bots
<ogra> vstehle, with the update to the -sessings package
<persia> vstehle, We don't: when the user updates the apt-cache, the update will show: when they install the update, it will then cause universe to be enabled for the *next* apt-cache update.
<ogra> vstehle, on first boot, forst thing the user sees will be update-manager
<vstehle> ogra: I don't see that.
<ogra> with installing the update, universe and multivers get magically enabled
<ogra> vstehle, thats hardcoded
<vstehle> ogra: I am testing the preinstalled image on a Panda right now. I never saw the update manager.
<persia> Might have to wait until the 17th to see it.
<persia> That 7 days thing.
<ogra> right
<lag> LOl
<lag> !sound
<ubot2> If you're having problems with sound, click the Volume applet, then Sound Preferences, and check your Volume, Hardware, Input, and Output settings.  If that fails, see https://help.ubuntu.com/community/Sound - https://help.ubuntu.com/community/SoundTroubleshooting - http://alsa.opensrc.org/DmixPlugin - For playing audio files,  see !players and !mp3.
<ogra> u-m checks for timestamps
<persia> Right.
<lag> There's our answers
<ogra> you will see it earlier
<ogra> the final image for omap4 was built on the 7th
<ogra> tomorrow or thursday it shoudl start to show up
<persia> But if the apt-cache gets updated for any reason (and there are several things that do this), u-m will notify the user of the updates without waiting.
<ogra> right
<vstehle> Ok, suppose I am now 7 days later. I install, I am prompted to do the updates, I accept, this adds universe+multivers. Then I click the icon, hopefully this does update the sources _again_ and it works. right?
<lag> !botsnack
<ubot2> Yum! Err, I mean, APT!
<lag> :)
<ogra> it does run apt-get update
<ogra> it has to, since it enabled a new source
<persia> vstehle, That's the idea.
<vstehle> Ok, I get it. Thanks!
<persia> ogra, No it doesn't: it will only update the apt-cache if the network is on (although the chances of this are astronomically high during SRU application)
<ogra> well, it will update the cache once you enable universe
<ogra> and it will do that again once you enable the ppa
<persia> lag, So, the big things we get out of our specialised default.pa are 1) automatic configuration restoration, 2) automatic detection of devices, 3) bluetooth support, 4) legacy overrides to work around the idea that pulse and alsa and oss somehow compete,
<lag> I thought we weren't touching *.pa?
<lag> I thought we were using *.conf
<ogra> we dont touch default.pa beyond whats there already
<persia> 5) cleaner audio load/unload for suspend/resume, 6) integration with console-kit so we don't have to fuss with the audio group and other stuff, 7) positionally meaningful events for cooler integration with libcanberra
<ogra> all arch specific changes we do now have to happen elsewhere
<persia> Right.  We don't touch default.pa for the special sdp4430 stuff, but that's what the Ubuntu default.pa is configured to "give us"
<lag> k
<persia> ogra, Are you preparing fixes for this, or do you want patches to review?
<ogra> do you have patches ? i'm currently trying to get crimsuns fixes to work
<ogra> we need to get rid of the alsactl init
<persia> You go work on sound: that's HW dependent, so I can't do it.
<ogra> ok
<persia> I'll prepare some patches.  Worst case, they'll be ready when you wake tomorrow.
<ogra> but first ... coffee
<ogra> ok
<ogra> this week is key
<persia> I'm not going to do the final natty jasper fix now: that needs to be part of the rewrite.
<ogra> yep
<persia> This week is not an issue.
<ogra> well, i wouldnt actually call it a rewrite :)
<persia> Just "tonight" is uncertain.
<ogra> the main issue is splitting out most of jasper into packages
<ogra> the things it does are mostly ok, just not the way
<persia> You can continue not to call it a rewrite as long as you like.  I have a huge desire to rearchitect it to such a degree that I expect to retain 0 lines of code.
<ogra> thats impossible
<ogra> the resizing bit wont be doable anywhere else
<ogra> the setup script i agree .... but even that will still need one line (teh enablement of oem-config cant be done anywheer else)
<persia> Oh, I might reuse some of the resizing code, actually, but likely nothing else.  Enabling oem-config will happen there, but in an entirely different way.
<ogra> you need the rootfs mounted to enable oem-config
<ogra> cant happen in jasper_growroot
<persia> I know.
<berco> hello
<persia> Doesn't mean I won't try to do it as d-i controllers anyway.
<persia> Hey berco
<berco> when an upstart script is installed from a deb package, does it require a posinst script?
<berco> I get lintian warning script-in-etc-init.d-not-registered-via-update-rc.d
<berco> but i'm confused as the upstart script goes into /etc/init and not /etc/init.d
<persia> upstart scripts don't belong in /etc/init.d/ : they belong in /etc/init
<berco> so lintian is complaining for nothing?
<persia> Are you using dh_installinit?
<berco> not specifically
<persia> Are you using debian/package.upstart?
<berco> persia: yes
<berco> but in the rules file, I see "dh $@"
<persia> That's fine.
<persia> Do you have a manual postinst script for the package?
<berco> persia: no
<ndec> persia: berco: isn't that better to use cdbs in this case? less chance to get errors, no?
<ogra> dh should do the right thing
<persia> ndec, No.  Actually, just means one has to know lots more make and slightly less perl to track down the same errors.
<berco> ndec: that's what I usually use but not my initial package. I can change it though if needed
<persia> But the extra perl for dh(1) is kinda trivial when compared with the perl one needs for dh_* anyway.
<berco> persia: ogra: so is this fine to ignore this lintian warning?
<persia> berco, Could you paste the output of dpkg --contents foo.deb ("No" is an acceptable answer, but then I want the package name)
<ndec> ok. wasn't sure if dh_installinit would be called with just dh $@
<ogra> ndec, yes, it is if the file is properly named
<persia> dh $@ should call all of them.
<ogra> it looks for .init or .upstart
<persia> If there's something missing from the sequence, well want it added.
<ogra> and puts them in the right places
<persia> ogra, Or .default
<ogra> .default doesnt go into an init dir
<persia> No, but dh_installinit is responsible for installing it anyway.
<persia> Puts it in /etc/default/package
<persia> Anyway, berco, about those contents?
<lag> bug 652035
<ubot2> Launchpad bug 652035 in alsa-lib (Ubuntu) "libasound2 not finding usb sound card (affects: 1) (heat: 6)" [Medium,In progress] https://launchpad.net/bugs/652035
<rsalveti> morning
<berco> ogra: persia: any issue with launchpad? Impossible to upload or fetch from TI 3PA
<ogra> works fine for me
<berco> argh
<berco> maybe network issue on our side then :(
<berco> ndec: does it work for you? try apt-get source tisyslink for e.g
<ndec> berco: it's downloading.
<ndec> berco: what's the exact problem? any log?
<berco> ndec: Err https://private-ppa.launchpad.net/tiomap-dev/private-release/ubuntu/ maverick/main tisyslink 0.24.9.2-0ubuntu7 (tar)
<berco>   gnutls_handshake() failed: A TLS packet with unexpected length was received.
<berco> Failed to fetch https://berco:xxx@private-ppa.launchpad.net/tiomap-dev/private-release/ubuntu/pool/main/t/tisyslink/tisyslink_0.24.9.2.orig.tar.gz  gnutls_handshake() failed: A TLS packet with unexpected length was received.
<berco> E: Failed to fetch some archives.
<berco> ndec: was working a few min ago
 * berco should have pastebin this log
<lool> berco: Looks like a network issue
<ndec> lool: but I am sitting less than 3 meters away from berco and it works for me ;-)
<rsalveti> ndec: do you need proxy in your network?
<rsalveti> maybe it's missing something
<lool> ndec: At so it's a PBCAK
<lool> ;-)
 * berco damned. corkscrew killed and everything goes back to normal
<mpoirier> GrueMaster: good morning
<GrueMaster> mpoirier: good morning.
<mpoirier> GrueMaster: a couple of weeks ago you gave me a command that plays sound, alternating from one speaker to another.
<mpoirier> I noted it somewhere but to save my life, can't find it anymore.
<GrueMaster> speaker-test -c 2 -t wav
<mpoirier> yes, thanks.
<GrueMaster> This will play directly through the hardware.
<GrueMaster> No pulse.
<mpoirier> I'm getting *nothing*...
<GrueMaster> On which platform?
<mpoirier> I'm panda, I'm testing the new patches sent by Irg
<ogra> mpoirier, they are not complete
<ogra> and you also need to make sure to have no state file
<mpoirier> state file ? please expand.
<GrueMaster> /var/lib/alsa/asound.state I believe.
<mpoirier> hold on, checking.
<ogra> right, you need to disable its creation
<ogra> else you wil always get the same state
<mpoirier> indeed I have such file.
<mpoirier> how to I prevent its creation ?
<mpoirier> Irg: good morning - I have your patches live on my card.
<ogra> for the init file you need to call alsactl init manually after boot
<lrg> mpoirier: morning
<mpoirier> ogra: i did.
<mpoirier> Irg: is there something you'd like me to check ?
<mpoirier> Irg: I have all 4 patches, the new 00main and omap4.
<lrg> mpoirier: ok, have you ran alsactl init ?
<mpoirier> Irg: I also manually ran alsactl init
<mpoirier> yes.
<lrg> ok, does audio work at this point
<lrg> ?
<mpoirier> I tried "speaker-test -c 2 -t wav" without results.
<mpoirier> I get clear silence.
<lrg> ok, what does cat /proc/asound/cards show ?
<mpoirier> that's the first thing I checked and it seems right to me.  Hold on.
<mpoirier> mpoirier@panda:~$ cat /proc/asound/cards
<mpoirier>  0 [Panda          ]: OMAP4 - Panda
<mpoirier>                       TI OMAP4 Board
<mpoirier> mpoirier@panda:~$
<lrg> ok, cool :)
<mpoirier> yes, at least that works.
<mpoirier> any sound control you're interested in ?
<ogra> that lookd fine
<ogra> *looks
<lrg> what about aplay -Dplughw:0,0 -f dat /dev/urandom
<mpoirier> Irg: yes, success.
<lrg> ok, the ABE uses some non standard formats
<mpoirier> please expand.
<lrg> everything has to go via alsaplugins atm
<lrg> well it uses S32_LE instead of S16_LE for PCM format
<mpoirier> Irg: educate me: what makes you say that ?
 * rsalveti lunch
<lrg> mpoirier: it's all in the TRM
<mpoirier> Irg: ok, I'll check it out.
<lrg> the plugin converts wav S16_LE to ABE S32_LE
<lrg> for playback
<lrg> and vice versa for capture
<mpoirier> Irg: should I understand my test results aren't a surprise to you ?
<ogra> lrg, i dont think your omap4 file can work
<ogra> lrg, as i understand, the init files need to use dB values, you use absolute numbers everywhere
<lrg> ogra: iirc, thay can use both since some drivers do not export dB info
<ogra> well, when i tested, absolute values didnt work
<ogra> but i'm happy to be proven wrong :)
<lrg> ogra: ok, I'll ping Abraham as he craeted the file
<ogra> did he test it ?
<lrg> I did, on SDPand it worked for me
<ogra> ok
<ogra> then it shoudl work on panda too
<lrg> I'm pretty sure I removed the old state file too - but it was quite late at night though
<ogra> you also need to disable its recreation
<ogra> it comes back with every boot and is executed immediately on device init by a udev rule
<ogra> move /etc/init/alsa-mixer-save.conf to /etc/init/alsa-mixer-save.conf.old
<lrg> ogra: ok thanks, I'll check this after some food
<lrg> abduenas: morning Abraham
<abduenas> hi
<lrg> abduenas: ogra has some questions about the config file
<ogra> abduenas, hey, i didnt get the init file to work when i used absolute numbers and had to use dB instead
<lrg> abduenas: I have to go, will be back in 30m
<abduenas> hmm really? it work for me with those numbers
<ogra> back last week when i created the first version of it which is attached to the bug
<ogra> liam said it works for him too
<ogra> so it was probably a temporary glitch on my side
<ogra> just wanted to know if you are sure one can use absolute numbers too
<abduenas> yes i used to manually set to zero then alsactl init and then check the status on alsamixer it was resotred properley
<ogra> oki
<ogra> thanks
 * ogra takes a break too and will then test the alsa-lib fix
<abduenas> no prob... i can try your dB also if you want
<ogra> i havent tested the new file yet
<ogra> so dont worry
<abduenas> oki
<berco>  pushed my source package 30min ago and since then launchpad says it will start in 1min... is it blocked in some ways?
<berco> abduenas: haven't tested yet your file. still busy w/ today release
<abduenas> berco: no prob
<oOSkar> Hi
<oOSkar> I need little help on Ubuntu on my Beagleboard
<oOSkar> I don't have any username-password after using https://wiki.ubuntu.com/ARM/OMAPMaverickInstall
<oOSkar> system boots perfectly but i'm blocked at login
<GrueMaster> oOSkar: Which image did you use?
<oOSkar> I used ubuntu-netbook-10.10-preinstalled-netbook-armel+omap.img.gz
<GrueMaster> Did it run the firstboot scripts that resize the root partition?  It should have been on the display.
<oOSkar> i did not see any firstboot script
<oOSkar> display was : orange (beagleboard boot) then black (linux booting on serial) and finally ubuntu purple login
<oOSkar> i've rewritten the SD card to try again but still no script running
<GrueMaster> Reboot but this time hold down the user button while the board resets.  This will load the boot loader from the sd card.
<GrueMaster> You should not see an orange background while this boots.
<oOSkar> trying
<oOSkar> no change
<GrueMaster> Is this a beagle C4?
<oOSkar> yep
<GrueMaster> Note that this image will be at the edge of what can run on that board.  256M memory is very limiting.
<GrueMaster> There are special directions for C4 on the wiki, below the BeagleXM & Panda instructions.
<GrueMaster> You need to have a serial console open to run a uboot script.
<oOSkar> i have the serial console
<oOSkar> i don't see any instruction for C4 on the wiki
<ogra_ac> it falls under "older beageboards"
<GrueMaster> Look for the "older beagleboards" section.
<oOSkar> (note that this step is only necessary if you have a NAND and the system does not default to reading boot.scr)
<oOSkar> hum, i may have read it too fast
<oOSkar> as the system was booting i tought it would have been unnecessary
<ogra_ac> the image wont be much fun on an old C4
<oOSkar> it's not that old
<ogra_ac> it will swap a lot and be reather slow
<oOSkar> but i agree that boot is quite slow
<ogra_ac> the images are built for HW with 512M
<oOSkar> i've used debian on it previously but wanted to try some more hardware
<ogra_ac> it will run indeed but dont expect speed
<oOSkar> but i can remove a lot of the stuff from that ubuntu version manually
<ogra_ac> sure
<ogra_ac> if you are patient enough to finish the install :)
<oOSkar> script is running now, thx :)
<ogra_ac> its all graphical
<oOSkar> "setting up swap" oO
<ogra_ac> yeah, that will take a while
<oOSkar> i don't want swap on a 4Go microSD card :/
<ogra_ac> you do
<ogra_ac> else the installer wont run
<oOSkar> that's quite a strenge choice
<ogra_ac> choice?
<oOSkar> *stange
<oOSkar> you mean that the installer would need more than 256Mo of RAM ?
<ogra_ac> the image is built for beagle XM or panda boards
<GrueMaster> X and gnome use a lot.
<ogra_ac> right
<ogra_ac> well, actually they dont once everything is up
<ogra_ac> htop on my ac100 here shows only 162M used
<ogra_ac> and i have firefox and xchat open
<oOSkar> did i read "ac100" ?
<ogra_ac> yes
<oOSkar> i was thinking about buying one
<oOSkar> but still hesitating vs tablets
<ogra_ac> what would you do with a tablet ?
 * ogra_ac really doubts their usability if yuo actually want to type etc ....
<oOSkar> surfing, email, programming, sys admin over ssh
<ogra_ac> programming ?
<ogra_ac> on a virtual kbd ?
<oOSkar> with usb keyboard they might be quite usable no ?
<ogra_ac> yeah, that might work if you like to carry around a stand to put the tablet on
<oOSkar> what do you think about the ac100 ?
<oOSkar> everything working on ubuntu ?
<ogra_ac> but before i carry a USB kbd plus a tablet plus a stand i rather use an ac100 :)
<ogra_ac> no, not everything
<ogra_ac> but getting there
<ogra_ac> the only kernel they provide is 2.6.29 so much stuff isnt as gooc supported as it could be
<ogra_ac> and things like powermanagement are completely done by a proprietrary tool
<ogra_ac> same goes for sound
<ogra_ac> its nvidia after all
<oOSkar> ok
<oOSkar> that's sad
<ogra_ac> well, its good enough for working
<GrueMaster> oOSkar: If you want to customize the beagle image, you could use rootstock or you could try installing from the net with the untested netboot install image from http://ports.ubuntu.com/dists/maverick/main/installer-armel/20100211ubuntu29/images/omap/netboot/omap/
<oOSkar> thx GrueMaster ;)
<oOSkar> i finally see the config graphic screen
<GrueMaster> cool
<oOSkar> you would have guessed it, it's quite very very slow
<ogra_ac> GrueMaster, btw, there is a shorter url for netboot now :)
<ogra_ac> http://cdimage.ubuntu.com/netboot/maverick/
<GrueMaster> ogra_ac: That lists links to what I just pasted.
<oOSkar> thx for these links, look quite interesting :)
<ogra_ac> right
<oOSkar> do you know where i can change the bootargs environment variable ? is it on the SD card or using the bios from the beagleboard ?
<GrueMaster> It is in the boot.scr on the first partition.  You can change it by editing the /boot/boot.script on the rootfs and running sudo flash-kernel.
<GrueMaster> THis is the easiest method.
<oOSkar> ok thx
<oOSkar> @ogra_ac : do you still have good autonomy without power management ? is there only sound missing ?
<ogra_ac> well, under android the ac100 has about 7h, on ubuntu its 4-5 depending on what i do
<oOSkar> ok
<oOSkar> and how is the android ? still usable for a hacker ?
<ogra_ac> havent tried how long it lasts with wifi off and 3g on yet
<ogra_ac> android is completely unusable imho
<ogra_ac> its a great phone OS but should stay there
<ogra_ac> might be usable on tablets but surely not for netbooks
<oOSkar> ok
<ogra_ac> try an ac100 at a dealer and you will understand :)
<oOSkar> if i find one ^^
<oOSkar> i've seen the videos and it looked strange, but wasn't sure
<oOSkar> thanx for all your advices ;)
<oOSkar> see ya !
<GrueMaster> ogra_ac: http://www.engadget.com/2010/10/13/specs-released-for-advent-vega-the-249-android-tegra-tablet/
<ogra_ac> looks like an ac100 without kbd :P
<berco> ogra_ac: what's wrong with the build machines?
<berco> I'm waiting for more than 2 hours...
<ogra_ac> berco, ask #soyuz or #launchpad
<berco> ogra_ac: thx
<ogra> lrg, lag, berco ... (and who else is involved in panda sound) i tested the alsa-lib fix and updated bug 637947 ... please someone provide a kernel package with the other changes so i can test the other init file
<ubot2> Launchpad bug 637947 in linux-ti-omap4 (Ubuntu Maverick) (and 1 other project) "no sound devices on current ES2.0 boards (affects: 2) (dups: 1) (heat: 26)" [High,Confirmed] https://launchpad.net/bugs/637947
 * ogra vanishes into his evening again
<rsalveti> GrueMaster: can you check the x-loader build date from the released image?
<GrueMaster> Sure in a few minutes.  (currently hobbled with bad knee).
<rsalveti> ouch, np
<rsalveti> ogra_ac: at http://cdimage.ubuntu.com/ubuntu-netbook/ports/releases/10.10/release/, preinstalled USB image
<rsalveti> it should be sd image, I believe
<ogra_ac> rsalveti, yeah
<ogra_ac> we need to fix that for natty
<ogra_ac> .img files are by default set to USB image in the scripts
<rsalveti> ogra_ac: oh, ok
<rsalveti> ogra_ac: and when are we getting natty images?
<ogra_ac> i want an SD card icon too :)
<ogra_ac> not sure
<rsalveti> yup :-)
<ogra_ac> they wont be usable anywy before alpha 1
<rsalveti> true, but just to know
<ogra_ac> so dont worry about image now
<ogra_ac> we'll start building them after UDS
<ogra_ac> as soon as there is an archive :)
<ogra_ac> toolchain and basic packages usually take a week to ten days
<rsalveti> cool
<ogra_ac> the sound seems to sort itself now too
<ogra_ac> seems we have all bits
<rsalveti> nice, still need to read the backlog and emails about it
<ogra_ac> we had a very fruitful meeting yesterday thanks to lag :)
<ogra_ac> he got all involved parties together
<rsalveti> nice
<ogra_ac> and even more imprtant, the issue with alsactl init was actually a alsa-lib bug
<ogra_ac> fix is already pending for SRU
<rsalveti> oh, so it was really a bug :-)
<ogra_ac> yeah
<ogra_ac> Bug #652035
<ubot2> Launchpad bug 652035 in alsa-lib (Ubuntu) "libasound2 not finding usb sound card (affects: 1) (heat: 6)" [Medium,In progress] https://launchpad.net/bugs/652035
<GrueMaster> rsalveti: Texas Instruments X-Loader 1.41 (Oct  6 2010 - 17:27:48)
<GrueMaster> I don't think that is the right one.
<lag> I'll post my email onto the LP bug so people not involved can read
<lag> Give me a moment
<ogra_ac> lag, no hurry
<ogra_ac> would be good to get lrg's patches too there
<lag> ;)
<lag> There's nothing stopping you ;)
<ogra_ac> yeah, there is alwas tomorrow ... i wont go upstaris again today, testing the alsa-lib stuff was enough at that time
<rsalveti> GrueMaster: cool, thanks
<rsalveti> GrueMaster: that should be the one
<GrueMaster> I'm redownloading from the above link for comparison.
<rsalveti> for some reason I flashed the wrong image
<lag> rsalveti: bug 637947
<ubot2> Launchpad bug 637947 in linux-ti-omap4 (Ubuntu Maverick) (and 1 other project) "no sound devices on current ES2.0 boards (affects: 2) (dups: 1) (heat: 26)" [High,Confirmed] https://launchpad.net/bugs/637947
<GrueMaster> Ah
<rsalveti> GrueMaster: for some reason when I got the rc instead of the release when using zsync
<rsalveti> probably lack of coffee
<GrueMaster> Oops.
<rsalveti> so I was surprised when I saw x-loader from september hehe
<rsalveti> ooops
<ogra_ac> yeah, we need to make sure the coffee is compiled in in the future so you dont need it additionally
<lag> Kaffine?
<ogra_ac> sounds like it would depend on QT
<rsalveti> argh...
<rsalveti> qt doesn't taste good
<ogra_ac> heh
<mpoirier> ogra_ac: I just read your email.
<mpoirier> ogra_ac: you need a kernel with the 4 patches suplied by Irg ?
<ogra_ac> mpoirier, yeah, tomorrow though
<ogra_ac> wont test today anymore
<ogra_ac> but his patch names the card based on the board
<mpoirier> ogra_ac: yes,
<ogra_ac> to test the switching init file we need the name
<mpoirier> ogra_ac: cat /proc/asound/cards does yield panda
<lag> mpoirier: I'm assuming you mean lrg? :)
<mpoirier> lag: Irg yes
<lag> No lrg
<ogra_ac> like a small L
<ogra_ac> :)
<lag> :)
<mpoirier> ogra_ac: are you looking for a .deb ?
 * GrueMaster hobbles back out to the couch where laptop & ice pack awaits.
<ogra_ac> mpoirier, right
<mpoirier> you'lll have a link in you inbox tomorrow.
<mpoirier> I'll get to it by the end of my day.
<ogra_ac> sweet !
<ogra_ac> thanks a lot
<sguiriec> mpoirier:if you want to have more data about OMAP4 ABE paths you can look at the next link  (http://www.omapzoom.org/wiki/File:Omap_abe.jpg http://www.omapzoom.org/wiki/File:ASoC_OMAP4.jpg). first one is mainly Audio Back End path. The second one is mapping the kernel audio controls on the graph.
<sguiriec> mpoirier: I hope it will be the missing part for your understanding
<mpoirier> sguiriec: this is very cool thanks - at first glance there is a fair a mount of things that are new to me.
<sguiriec> mpoirier: OMAP4 audio is very different from OMAP1/2/3. ABE and McPDM introduce new functionalities.
<mpoirier> ya - someone else (can't remember who) in TI told me the same.
<sguiriec> mpoirier: May be berco
<mpoirier> probably yes.
<mpoirier> he was the first person to enlight me in this matter
<lag> mpoirier: I didn't think you were working on this anymore?
<sguiriec> mpoirier: I am still working and helping on the driver
<mpoirier> lag: I was waiting for that info - now I can move forward.
<mpoirier> lag: it has a lot of the missing peices we were talking about.
<lag> I was under the impression that all the outstanding tasks have been already issued
<lag> What needs to be done that I am unaware of?
<lag> mpoirier: ?
<mpoirier> lag: yep
<lag> --^
<mpoirier> lag: sorry - I had not seen your post.
<mpoirier> lag: everything has been covered.
<mpoirier> I peeled the sdp4430.c and twl6040.c a couple of weeks ago.
<mpoirier> but there was something missing,
<mpoirier> those two files we setting forth the BE and FE but again, the path between them was incomplete.
<mpoirier> I was specifically interested to know how berco came up with the setting of the alsamixer.sh file
<mpoirier> that file was bridgin ABE, BE and FE together.
<mpoirier> I was missing part of the puzzle.
<sguiriec> mpoirier: Nomally should be more clear for you now.
<mpoirier> sguiriec just painted the missing part.
<mpoirier> lag: there was a grand scheme I couldn't see - and you could not have deduce the information from the TRM or the schematics.
<mpoirier> drove me nuts.
<lag> Okay
<lag> So it was more a quest for information
<mpoirier> yes, 'cause we are bound to do this again...
<mpoirier> whenever another omap4 board gets spun off.
<lag> I don't believe that to be the case
<mpoirier> the more we know, the better we can point out problems and work with TI.
<lag> Well ...
<lag> Maybe
<lag> So, are you happy that all the tasks have been addressed for Panda -> Maverick?
<mpoirier> I have nothing more to requets
<lag> Okay
<lag> Try not to spend any more time on it, testing not withstanding
<lag> If you believe we have missed something, let me know and I will endeavour to address it asap
#ubuntu-arm 2010-10-14
<hrw> morninge
<vstehle> ogra: Hi Oliver, you came back after all :)
<vstehle> ogra: I find something puzzling regarding the PPA.
<persia> I wouldn't trust much communication until there's been no netsplit traffic for a while: sometimes stuff gets lots in the backscroll.
<vstehle> persia: May I please ask _you_ about this PPA thing, then?
<persia> I generally recommend asking questions generally of the channel.  I'm unsure that this is the best channel for a PPA question, but I'll try.  Otherwise, you can ask in #launchpad.
<vstehle> persia: Ok; I move there.
<ogra> so the sound stuff doesnt work at all anymore :/
<lag> What have you done?
<ogra> lag, trying mathieus kernel, putting all new files in place
<lag> Hmm
<ogra> all muted
<ogra> urgh
<lag> ?
<ogra> a) i tried remotely .... my screen is all blue if i switch the monitor on
<lag> Nice
<ogra> not sure what he did to that kernel package
<ogra> b) calling alsactl init makes it work
<lag> I'm just looking now
<lag> Is that correct?
<ogra> no
 * ogra reverts everything, it worked yesterday with distro kernel and my file without alsactl init
<lag> What does cat /proc/asound/cards produce?
<hrw> ogra: panda sound still has problems?
<lag> What was the link to the kernel he gave you?
<ogra> http://people.canonical.com/~mpoirier/linux-image-2.6.35-903-omap4_2.6.35-903.13+release3_armel.deb
<ogra> lag, before i had http://people.canonical.com/~roc/kernel/audio/linux-image-2.6.35-903-omap4_2.6.35-903.13+audio1_armel.deb installed
<ogra> just reinstalling that one
<lag> That's Bryans kernel
<ogra> right
<ogra> and that one worked after the alsa-lib change
<ogra> i dont get why i would get that bright blue screen
<ogra> the patches dont touch anything related
<lag> I'm trying to find the server which he built on
<lag> But to no avail as yet
<ogra> sound/soc/omap/sdp4430.c , include/sound/soc.h and sound/soc/soc-core.c
<ogra> nothing should have any influence on my display
<lag> I can't find any of his builds
<ogra> fun
 * ogra reboots into old kernel with old init files
<ogra> yup, login sound here
 * ogra checks the screen
<ogra> and netbook ui
<lag> I can't find any up-to-date build?
<ogra> weird
<ogra> well, we need cooloneys kernel plus the bits from lrg
<ogra> i just need the names
<ogra> and i know cooloney built on one of your servers
<lag> How different is cooloney's tree to the mainline?
<lag> What if I applied lrg's patches to the current tree?
<ogra> you would be missing a ton of audio fixes
<ogra> afaik
<lag> Ah
<ogra> oh, no, wait, i think they were applied
<ogra> please check the tree
<lag> Yep
<ogra> not sure there was an upload with thgem though
<lag> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-maverick.git;a=shortlog;h=refs/heads/ti-omap4
<lag> Is that all the patches?
<lag> Or are there more?
<ogra> its like 70 patches and i cant find the merge request on the kernel ML
<ogra> RAAAAAHHHH !!!!
 * ogra freaks out about being CCed on all the kernel mails
<ogra> I HATE THAT !
<lag> We've had this discussion
<ogra> thanks to that they dont match the ML sort filter and end up in places i cant find them
<lag> Not everyone reads the mailing list
<ogra> thats so annoying
<ogra> i do
<lag> Good for you :)
<ogra> and i am sure that other people filter on ML headers too
<lag> Perhaps you shouldn't
<lag> ;)
<lag> I have working filters
<lag> ;)
<lag> Anyway ...
<lag> That current tree looks like it has loads of new audio patches
<ogra> lag, based on ML headers (like you should for LP mail ?)
<ogra> [Maverick] [ti-omap4] SRU: audio driver fixings
<lag> I'd say ~90 patches
<ogra> applied and pushed by tim on the 6th
<lag> In the ML/
<lag> ?
<ogra> yes
<lag> Yes, they are applied
<ogra> good
<ogra> so only the naming patches from lrg are missing there
<ogra> could you roll me a kernel deb ?
<lag> Of course
<ogra> merci :)
 * ogra meanwhile goes to find some breakfast
<ogra> we'll need GrueMaster (once he gets up) to confirm the switching works, he has a blaze
<lag> There are only 4 patches right?
<persia> ogra, jasper-initramfs/scripts/local-bottom/jasper_setup runs in initramfs, right?
<ogra_ac> yes
<persia> So, I think we can't enable universe via the python API there.  Is there a script that runs in userspace, or do you think unsafe sed is better?
<ogra_ac> you cant run apt-get update from there at all
<ogra_ac> no networking in initrd
<ogra_ac> so your apt-cache will be completely out of sync
<persia> Oh, I don't care about apt-get update.
<persia> That's fine.
<ogra_ac> i do
<persia> Everything will be able to tell the apt-cache is out of date because of timestamps.
<ogra_ac> if a user calls apt-get install i dont want him to be greeted with an out of sync cache error
<ogra_ac> thats about the first impression not about technical issues
 * persia digs into oem-config code
<ogra_ac> i think apt-setup is only called from oem-config in case you also run tasksel
<ogra_ac> which we dont want in our setup
<ogra_ac> i'm not sure they are separate
<lag> ogra_ac: I also have Blue screen!
<ogra> even with the new kernel ?
<ogra> wow
<lag> The latest kernel
<lag> We're screwed
<ogra> i dont get how the soc changes can affect hdmi
<lag> I don't think it was the SoC changes
<ogra> especially since its only a few lines adding names
<lag> Let me roll there kernel without lrgs patches
<ogra> well, the kernel on the release image works
<lag> Which was compiled when?
<ogra> and i think the 90 sound patches are in there
<ogra> and cooloneys test kernel works for me too
<ogra> without any issues
<ogra> there was one patch afterwards ...
<ogra> one sec, let me find it
<ogra> [Maverick] [ti-omap4] [SRU] UBUNTU: [Config] enable passing all kernel command line to init
<lag> 7 days ago	Mythri P K	OMAP4:DSS:HDMI:Fix for default boot on HDMI with ES2.0
<ogra> Thu,  7 Oct 2010
<ogra> lag, oh, wait
<ogra> which image do you use ?
<ogra> x-loader changed along with that patch
<lag> Ah
<lag> I'm using the daily build
<ogra> you need to use the new image
<lag> But with my own x-loader
<lag> Whould the daily build work?
<ogra> right, x-loader and the Mythri P K HDMI patch had to be applied at the same time
<ogra> the daily from 7th should
<lag> Okay, re-DDing
<ogra> (it should be the release image, we didnt re-roll)
<lag> ogra: Okay, my blue screen has disappeared momentarily
<lag> ogra: Why did you get a blue screen?
<lag> ogra: Were you using the old x-loader too/
<ogra> lag, yeah
<ogra> i still use the same image, upgraded since RC and we dont upgrade x-loader (as you wouldnt upgarde a PC BIOS)
<ogra> ok, updated x-loader
<ogra> let me try with mathieus kernel again
<lag> If it doesn't work, I have a working one here
<ogra> k
<ogra> i suspect it will work now
<ogra> *twiddle*
<lag> Which board do you have?
<lag> 8 layer?
<ogra> 2.1
<lag> I am sooooo behind on boards :(
<ogra> and 8 layer 2.0 and a special 2.1 with DVI wiring added
<ogra> 2.0 8 layer is fine
<lag> I only have a 6 layer
<ogra> oh, yeah, we need to upgrade you
<lag> No kidding
<lag> Why have I been left behind
<ogra> ask rsalveti, i thinnk he has a patched u-boot and kernel package
<ogra> because we got limited amounts of HW
<lag> I should always have the most up to date board!
<lag> And who has priority?
<ogra> and i think mathieu got the new one because he didnt have one at all
<lag> Surely the kernel is important to you?
<lag> Mathieu is normally OMAP3
<ogra> cooloney has the 2.1 and the 2.1+DVI
<ogra> you should get his 8 layer
<hrw> ogra: how old are 2.1 boards?
<ogra> about a week
 * hrw wonder which ver will land in my hands
<ogra> we only got fout of them directly handed out
<ogra> hrw, pray its not a 6 layer
<ogra> lag, we'll get more borads within the next few weeks
<hrw> ogra: I was told that it will es2.0 8layer minimum
<ogra> enough for everyone i hope
<lag> I want 2.2
<ogra> lag, well, then get a soldering iron :P
<ogra> and a list from TI what will be on 2.2
<hrw> good thing is that I will be able to run anything not exactly ubuntu on it D:
<lag> For future h/w releases I really should have the latest boards
<ogra> they wont go to production for a while :)
<lag> It was a jk
<ogra> 2.1 is what goes out
<ogra> and i hope we wont see any HW upgrade for a while now
<lag> But as the OMAP4 kernel team representative I should be on the priority list
<ogra> lag, well, cooloney is *the* OMAP4 representative i was told
<hrw> fight, fight!
<ogra> we can swap that indeed
<lag> Who told you that?
<ogra> that was decided at UDS iirc
<lag> Before I joined :)
<ogra> right
<lag> Well there's a new daddy in town ;)
<ogra> yeah
<jkridner|work> rsalveti: let me know if my response about the P8 BeagleBoard-xM memory was at all confusing.  you should swap out MLO and see if your problem goes away..
<ogra> lets shuffle responsibilities at UDS
<lag> By all means
<ogra> hmm, i think i trashed my panda image :/
<ogra> ah, no
<ogra> now it boots
<cooloney> lag and ogra, are you guys talking about my panda toy? -:)
<ogra> cooloney, hehe, we do
<lag> Yep yep
<cooloney> yeah, I got 2 panda boards now. actually one is 2.1+DVI
<ogra> oh, you dont have the 2.0 anymore ?
<cooloney> and one is 2.0
<cooloney> yeah, the 8 layers 2.0
<ogra> i thought you got a normal 2.1 too
<ogra> no sound here :/
<cooloney> ogra: oh, i returned that to chris, as 2.1+DVI is enough
<ogra> sigh
<cooloney> but i have to keep 2.0, since we need to support 2.0, right?
<ogra> so with the old kernel it all worked
<ogra> with the new kernel i have to call aslactl init *again*
 * ogra doesnt get that
<ogra> and i cant esaily downgrade, hrm
<cooloney> ogra: just before we left, i got 3 boards ->  2.0, 2.1 and 2.1+dvi
<ogra> yeah
<cooloney> ogra: after sent your guys to airport, we were back to hotel
<cooloney> chris called GrueMaster
<ogra> ah
<cooloney> chris showed up and i returned the normal 2.1 to him
<cooloney> so i just have 2 boards. one old 2.0 and a 2.1+dvi
<ogra> yup
<cooloney> so lag, do you wanna i give you my board? i think you got 2.0 board
<cooloney> ogra: how come sound doesn't work?
<cooloney> ogra: doesn't work with new kernel?
<ogra> cooloney, it never worked ?
<ogra> only partially
<ogra> we're trying to fix the last bits since beginning of the week
<cooloney> oh, i mean even using your alsactl trick, it doesn't work?
<ogra> sure it does
<cooloney> ogra: ok, got it.
<ogra> but the alsactl call is wrong
<cooloney> ogra: so any idea about our plan?
<ogra> yes, look at the bug
<ogra> lag, documented everything
<cooloney> ok, let me check
<cooloney> ogra and lag, thanks
<ogra> GRRR
<ogra> no sound at all
<ogra> not even after alsactl init now
<ogra> HA
<ogra> putting my omap4 file back works
<ogra> so one step at a time now
<ogra> keeping everything as is and upgrading to mpoiriers kernel
<lag> :)
<lag> cooloney: I don't want your board
<ogra> (and adjusting the name in 00main indeed)
<lag> cooloney: I'll wait for the next batch
<cooloney> lag: oh, panda 2.2? heh
<lag> cooloney: No, just the new batch of 2.1's
<cooloney> ogra: did liam provide the patch to export platform name from kernel to userspace
<ogra> lag, confriming, with the new kernel it doesnt work at all
<cooloney> lag: yeah, indeed.
<cooloney> ogra: which kernel?
<ogra> cooloney, yes, thats what i'm testing here
<lag> ogra: Well that's not good!
<cooloney> ogra: ok, where is the patch from liam
<ogra> no
<lag> I don't know which kernel he rolled
<lag> Do you want to try mine?
<ogra> yes
<lag> In case it's any different
<lag> Okay, wait one
<ogra> i know which kernel he rolled ...  2.6.35-903-omap4 #13+release3
<ogra> :P
<ogra> its release3 :)
<ogra> (i dont know what release3 is supposed to mean though)
<lag> ogra: Uploading
<lag> My point exactly
<lag> I don't think it has any of the audio patches in
<lag> Doh!
<lag> The one he rolled was *.13*
<lag> Mine is *.15*
<lag> That would explain it
 * lag is uploading 
<lag> Well, my kernel is :)
<lag> ogra: I'll let you know when it's finished uploading: http://people.canonical.com/~ljones/lp637947-maverick/
<ogra> oki
<ogra> the alsa-lib fix is uploaded btw
<ogra> we'll need some testers to confirm it works and can go to -updates (its in -proposed now)
<cooloney> ogra: i can try that on my board
<ogra> cooloney, use the 00main and omap4 files from the bug
<persia> ogra, Have you prepared the candidate alsa-utils bit yet (the new conf file and 00main changes)?
<ogra> persia, not until i know they work
<persia> Ah, so you're waiting for the alsa-lib bit to be verified?  Makes sense.
<cooloney> ogra: oh, if you didn't changed those 2 files since Dallas trip, I've already installed them on my board
<ogra> persia, to test the switching i need the new kernel, but the one i got didnt include cooloney's 90 audio patches
<ogra> cooloney, great, with the new alsa-lib it should work without alsactl init
<cooloney> ogra: i think lag's kernel contains those audio patches
<persia> Oh, I somehow missed that the alsa-utils bit depended on the kernel bit.  Sorry for the poorly-timed poke.
<ogra> cooloney, right, thats what i'm waiting for
<cooloney> ogra: ok, so i just need to update my alsa-lib on board?
<ogra> persia, well, my alsa-libs bit doesnt but that works only for panda
<ogra> what we need is the switching piece based on boardname
<ogra> and thats what we try to test atm
<ogra> cooloney, from maverick-proposed, yes
<cooloney> ogra: ok, cool. let me upgrade
<ogra> cooloney, bug 652035 is the one waiting for test results
<ubot2> Launchpad bug 652035 in alsa-lib (Ubuntu Maverick) (and 1 other project) "libasound2 not finding usb sound card (affects: 2) (heat: 18)" [High,Fix committed] https://launchpad.net/bugs/652035
<persia> ogra, Right.  I just was chatting with crimsun earlier, and added the task to the other bug (637...) based on what he was saying.
<ogra> right
<ogra> i'll prepare my stuff today as soon as i can prove it works on the panda at least
<ogra> we'll need GrueMaster for the blaze test
<persia> Right.
<ogra> btw, i suspect the fix also fixes dove
<ogra> we should ask NCommander to try
<lag> ogra: Done
<ogra> lag, you guys dont need to upload the headers every time :)
<ogra> i wont compile anything against the test packages :)
<lag> It's automatic
<ogra> ah
<lag> scp linux-* <server>
<ogra> i thought you do that with scp
<ogra> right, just use scp linux-image*
<lag> What does it matter?
<ogra> saves time and bandwith
<lag> 100%  573KB 573.3KB/s   00:00
<persia> 573KB?  Are you sure that's the file you wanted?
<ogra> well, at least it took no time :P
<ogra> everyone cross your fingers :)
 * ogra reboots
<ogra> lag, hmm
<ogra> lag, are you sure you applied the patches ?
<ogra> my card is still named SDP4430 with your kernel
<lag> 2 secs
<ogra> should be Panda
<ogra> ogra@panda:~$ cat /proc/asound/cards
<ogra>  0 [SDP4430        ]: SDP4430 - SDP4430
<ogra>                       TI OMAP4 SDP4430 Board
<ogra> yeah, no name change
<ogra> behind the colon it should be: OMAP4 - Panda
<lag> http://kernel.ubuntu.com/git?p=lag/ubuntu-maverick.git;a=commit;h=39f15b5e3ac8c486bcc8bcf4376b7d2e8122517b
<lag> They're applied
<lag> Maybe something went wrong with the build
<lag> Let me try again
<ogra> err
<ogra> whats these abe changes ?
<lag> ref: lrg's email 12/10/10 @ 11:45
<ogra> ah, k
<ogra> he does weird testing though
<ogra> pretty hackish :P
<ogra> but ok, i'll trust him
<ogra> he should know what the mixer values should be
<ogra> though i dont get why the name change doesnt work now
<lag> As I said, it's probably a build error
<lag> I am re-compiling
<ogra> ok
<lag> Shouldn't be too long
<ogra> k
<ogra> i'll go play with my ac100
<ogra> :)
<ogra> rsalveti, hey
<lag> ogra: The latest kernel is up by the way
<lag> (and has been for a while)
<ogra> pulling, thanks
<ogra> ok, rebooting, lets see
<ogra> (or hear rather)
<ogra> the names changed
<ogra> but it doesnt work :(
<ogra> lag, could i get a build with *only* the name changes ?
<lag> You mean without all the other audio patches?
<lag> Or without his other 2 patches?
<ogra> right
<ogra> without any patches to the abe files
<ogra> i have to call alsactl init manually again with your kernel
<ogra> then it works
<ogra> and i cant imagine that to be caused by the name changes
<ogra> sound/soc/omap/abe/abe_dat.c , sound/soc/omap/abe/abe_def.h and sound/soc/omap/omap-abe-dsp.c dropped please
<ogra> (the changes, not the files indeed :) )
<ogra> oh, shriek !
 * ogra just found a spares alsactl init in one of the alsa files
<ogra> *sparse
<lag> Does that mean you don't want me to re-compile yet?
<ogra> yes, wait a sec
<ogra> i have to test the old kernel again
<ogra> GAH
<ogra> lag, leave it i think i'll haver to additionally apply a hack to alsa-utils
<ogra> seems the alsa-lib fix only fixed it partitally
<lag> Okay
<lag> Let me know if you need me
<ogra> will do
<ogra> but i think kernel wise we're fine now
<rsalveti> ogra: hey
 * rsalveti reading backlog
<ogra> rsalveti, not about the backlog :)
<ogra> rsalveti, about the "oem-config doesnt start in my rootstock images OMG the world ends !!!" issue :)
<rsalveti> haha
<ogra> rsalveti, i ran into a similar issue with ac100 users ...
<ogra> we need to use --numeric-owner in tar
<rsalveti> sure, saw that while reading backlog
<rsalveti> I have an exclusive todo list just for rootstock :-)
<ogra> else it will replace the UIDs and GIDs with the ones from /etc/passwd and group from the host machine
<rsalveti> but I can push at least this fix for now
<ogra> ah, you already saw it, k
<rsalveti> ogra: so, ac100 users are using rootstock?
<ogra> no, but a tarred up rootfs
<ogra> and i suddenly got users with exactly the same issues
<ogra> using --numeric-owner on packing and unpacking fixed it
<rsalveti> hm, ok
<rsalveti> yeah
<rsalveti> ogra: so, how is the audio thing going now?
<ogra> bad, we still need the init, but at least it gets respected in the right place now
<ogra> i'm preparing patches now
<mpoirier> ogra: reading the above exchange, should I undertand the patched kernel that was produced for you didn't work ?
<ogra> mpoirier, you based on the wrong version and were missing about 90 audio patches apparently
<ogra> it didnt work for me for other reasons based on my own stupidity though
<mpoirier> ogra: I used the latest maverick kernel
<ogra> lag said you used 13 while 15 is current
<mpoirier> ogra: yes indeed that where the current code is but I pulled all the audio patches.
<ogra> ah
<mpoirier> ah
<mpoirier> the kernel I produced for you has all the latest audio patches.
<rsalveti> mpoirier: ogra: at least 2.6.35-903.13 is a quite old one
<rsalveti> mpoirier: why did you pulled?
<mpoirier> it's about a couple of weeks old.
<rsalveti> you should just use based on what's in the repo
<mpoirier> simply 'cause I had it on my machine already and it was quick to recompile.
<rsalveti> you should really follows our kernel tree, in a way it's easy to identify the kernel we're using
<rsalveti> to avoid problems like these
<rsalveti> we don't know what else you have on your kernel, so it's not that great to test it
<mpoirier> I agree the in this case, it was impossible for you to know I pulled the audio patches.
<ogra> lag, so feel free to prepare an upload, i'll prepare an alsa-utils patch now
<rsalveti> and this kernel probably misses b5485d193f8a422901fe7e401542950970121860, in a way that breaks the display
<ogra> rsalveti, no it has it ... i missed the new x-loader though
<ogra> which left me with a bright blue screen
<lag> ogra: What is it you want?
<ogra> lag, an upload of what i just tested
<lag> All the audio patches plus the _two_ name change patches?
<ogra> well, whatever you just gave me works :)
<lag> Sorry, save me reading though the backlog
<lag> Awesome!
<lag> Okay, I'll get it pushed
<lag> Well done :)
<ogra> lag, so that should be uploaded, i'll roll the alsa-utils change now
<lag> Will Maverick work out-of-the-box now?
<ogra> yes
<lag> :D
<persia> No.
<persia> Maverick will work just-after-update
<persia> (minor, but important distinction, as support folk have to remember to ask "Have you installed all the updates")
<rsalveti> ogra: but you were using the newer x-loader already
<rsalveti> I believe, if you're using the released image as base
<ogra> rsalveti, i used the RC
<rsalveti> heheh, that's a problem :-)
<rsalveti> lag: and what are the needed changes at the kernel?
<rsalveti> jkridner|work1: cool, will test with this x-loader and see if it works better
<rsalveti> thanks for the info
<lag> Driver name export and some maximum volume amendments
<rsalveti> hm, cool, not so many changed lines I believe
<rsalveti> ogra: I just don't understand yet why you still need to call alsactl init
<persia> rsalveti, Because the SRU for that bug isn't in -updates yet.
<rsalveti> persia: oliver said he tested with the fix from this bug, and still didn't work
<persia> It needs three pieces.  the kernel bits lag just did, the alsactl stuff crimsun uploaded earlier, and the alsa-utils stuff ogra was preparing.
<persia> leading to ogra's 14:12 comment about everything working.
<rsalveti> persia: the alsa-utils stuff *is the* alsactl init
<rsalveti> that's the one I don't yet understand why we need it
<rsalveti> http://launchpadlibrarian.net/57601862/alsa-utils.patch
<persia> rsalveti, No, alsa-lib is alsactl.  alsa-utils is /usr/share/alsa/init/
<persia> Where's that from?  That's not the patch to 00main I was expecting.
<rsalveti> persia: read the bug
<persia> Which one?
<rsalveti> ogra posted the latest changes at the end
<rsalveti> bug 637947
<ubot2> Launchpad bug 637947 in linux-ti-omap4 (Ubuntu Maverick) (and 3 other projects) "no sound devices on current ES2.0 boards (affects: 2) (dups: 1) (heat: 26)" [High,Triaged] https://launchpad.net/bugs/637947
<persia> That's not a complete patch.  Alsa-utils needs the bits from comment #36 and comment #37 as well.
<persia> (although, really comment #36 should be a patch rather than a blob)
<ogra> uploaded
<rsalveti> persia: yeah, but I still don't get why we need this alsactl init stuff
<persia> Same as comment #24
<ogra> http://bazaar.launchpad.net/~ubuntu-core-dev/alsa-utils/ubuntu.new/revision/70
<persia> The comment #40 thing?
<ogra> rsalveti, me neither, thats stuff to figure out in natty
<persia> Why didn't the 652035 patch work?
<ogra> persia, it does
<rsalveti> persia: yeah, the link I sent you
<ogra> alsactl init at that place did never work before
<persia> So, why do you need 637947/comment 40?
<ogra> persia, no idea
<ogra> but its still needed
<persia> Ah, right.  That's broken for complicated reasons we don't understand.  I can live with that for now.
<ogra> right
<ogra> we just need the fix in -updates on monday
<ogra> thats a requirement
<ogra> lag, ^^^ same goes for the kernel btw
<persia> The final solution is close enough to comment #13 that I'm very much happy with everyone for doing it that way :)
<ogra> right
<ogra> natty will make everything better
<ogra> the scary bit will likely become the tablet ;)
<persia> In a completely different way, because of UCM (or parts thereof).
<ogra> nobody knows what the soundcard is called on that
<persia> heh.
<ogra> but thats my personal headdache
<ogra> since i'm the only one having a tablet to test (and no poroper kernel yet)
<rsalveti> ogra: were you able to touch it since last week?
<ogra> rsalveti, nope
<ogra> and to be honest i'm not in a hurry
<rsalveti> yeah, understand
<rsalveti> if you read the kernel diff you'll be scared :-)
<ogra> i'll need to roll a kernel package for it from the tarball i have
<ogra> but first need to make up a proper ubuntuized config
<ogra> their kernel doesnt even have lzma enabled so ubuntu initrd doesnt work
<rsalveti> ogra: I can try to create a deb file for you if you want
<rsalveti> based on our kernel
<rsalveti> and applying just the diff
<ogra> and i dont want to have to repack the initrd every time i try something
<rsalveti> let me see if I still have the tarball
<ogra> well, if that boots and you feel like doing that work :)
<ogra> i can push it to chinstrap worst case
<ogra> i habe the SD somewhere in the unpacked part of my luggage
<rsalveti> yeah, I have it: tablet_kernel.tgz
<ogra> yep, thats the one
 * ogra relocates
<GrueMaster> ogra: I can't test blaze yet.  I only have an ES1.
<rsalveti> yeah, true :-(
<ogra_ac> oh, i thought you could take the CPU board with you
<rsalveti> but I believe vstehle can :-)
<lag> Sent to kernel team ML
<ogra_ac> with an urgecy tag i hope
<ogra_ac> *urgency
<rsalveti> lag: did you create the SRU?
<lag> A do what now?
<ogra_ac> rsalveti, lets wait until everything is in the queue
<lag> Wiki please?
<ogra_ac> lag, subscribe the SRU team to the bug
<ogra_ac> lag, https://wiki.ubuntu.com/StableReleaseUpdates
<ogra_ac> lag, after the upload to -proposed we need to subscribe ubuntu-sru ... they will let it into -proposed
<ogra_ac> then it needs at least two positive comments on the bug from testers to make it to -updates
<GrueMaster> Is this the audio fix for panda?
<ogra_ac> GrueMaster, righht
<GrueMaster> nice.
<vstehle> ogra_ac, rsalveti, GrueMaster, I have no blaze at hand but I can ask around me if you want. What is it that you want to test?
<rsalveti> vstehle: audio, but needs changes all around
<ogra_ac> nothing right now buit if the packages for Bug #637947 are in maverick-proposed we need a test on blaze
<ubot2> Launchpad bug 637947 in linux-ti-omap4 (Ubuntu Maverick) (and 3 other projects) "no sound devices on current ES2.0 boards (affects: 2) (dups: 1) (heat: 26)" [High,Triaged] https://launchpad.net/bugs/637947
<lag> lrg: Are you about?
<rsalveti> seems the sound should be ok at panda and blaze with these changes
<lag> I need your sob on the patches I just submitted
<vstehle> rsalveti, is everything in packages, or are there even patches around? If it boils down to apt-get/test I can grab someone at his desk :)
<rsalveti> vstehle: at the moment there are only patches, but you'll be able to test it soon :-)
<rsalveti> once the packages are in maverick-proposed we can ping you back
<ogra_ac> vstehle, hopefully we have packages in maverick-proposed by tomorrow
<lag> ogra: I need a favour
<ogra_ac> lag, tell me
<lag> ogra: I need a King Cobra picking up from Holland :D
<ogra_ac> np. when ?
<lag> Really?
<lag> :)
<lag> You jest
<ogra_ac> i use my care to rarely anyway :)
<ogra_ac> s/care/car
<lag> I'm assuming you do know what a King Cobra is?
<ogra_ac> a snake ?
<lag> Yep
<ogra_ac> safely boxed ?
<lag> It would be, but I have no way of collecting it from you then
<lag> :(
<lag> I think you are even further away
<GrueMaster> Erm, why?
<ogra_ac> probably
<ogra_ac> well, i cnt leave my girlfriend with a snake during UDS
<ogra_ac> *cant
<ogra_ac> i surely have no prob picking up a box and delivering it somewhere
<GrueMaster> Oh, why not.  She has one the rest of the time when you aren't traveling.  :P
 * GrueMaster ducks for cover.
 * ogra_ac slaps GrueMaster behind his chair
<lag> :)
<lag> That's very kind of you, but I fear it is too much to ask
<GrueMaster> lag: Why do you want a king cobra?  Not enough challenges in the kernel team?
<marvin24_DT> ojn: does the tegra kernel on git.chromium.org depends on nvidia binary-only userspace stuff for sound/graphics?
<ojn> yes
<marvin24_DT> means, nvrm_daemon required?
<marvin24_DT> I'm asking because we have this beautiful ac100 laptop
<marvin24_DT> but we cannot get something usefull out of it with this nvidia stuff
<ojn> marvin24_DT: the binary pieces still have a bit of nvrm dependencies, yes. For graphics most of them have been removed but there's still some in there.
<marvin24_DT> ojn: thanks for the answer!
<ogra_ac> ojn, sound would be more intresting
<ojn> ogra_ac: I haven't looked at sound yet, so no input there yet unfortunately.
<ogra_ac> ah, tell me if you have ... on the ac100 i get sound devices but no mixers for example ... it also appreas like it defaults to a null codec unless nvrm_daemon runs
#ubuntu-arm 2010-10-15
<lag> GrueMaster: I think they're amazing
<lag> GrueMaster: I already have quite a few Cobras, but Kings are awesome
<hrw> hello
<asmcos> "apt-build world" can compile all arm source code package ?
<asmcos> Can I re-compile  all soft package ?
<persia> You can certainly recompile everything.
<persia> I'm unsure if that syntax is correct for apt-build.
<persia> I'm not sure why you'd want to recompile everything though.
<asmcos> maybe i want to use a newcompiler ?
<asmcos> persia
<asmcos> do you compile ubuntu 10.10 for arm ?
<asmcos> do you have any document about compile ubuntu for arm ?
<hrw> asmcos: you have lot of arm cpu power to waste?
<hrw> hi njpatel
<asmcos> æ²¡æ
<asmcos> ä½ æ¯linux forumçhrw?
<njpatel> hrw, hey dude
<asmcos> hrw:no
<hrw> asmcos: recompilation of whole ubuntu on arm hardware will take ~month if not more...
<asmcos> for arm,
<asmcos> now on arm
<asmcos> not on arm
<asmcos> use cross compiler
<hrw> asmcos: cross compilation of ubuntu packages is not working for lot of packages
<asmcos> is nothing,i need part packages
<asmcos> I need know the compilation methods
<asmcos> how many do ubuntu 10.10 have packages?
<asmcos> apt-build support cross-compile ?
<hrw> asmcos: you need to get used to xdeb
<asmcos> hrw:thank you
<persia> cross-compilation *can't* work for lots of the packages.
<persia> And the number of packages that will fail to cross-compile only increases as people implement more built-time test suites (which we consider best practice)
<asmcos> oh
<persia> Note that everything there now is native-compiled.
<asmcos> compile ubuntu on arm ?
<persia> From what I understand, nobody has ever done large-scale extensive testing to ensure it is safe to mix native- and cross- compiled code.
<persia> Yep.
<vstehle> Hi ogra, I saw you released images for the AC100 (http://ac100.gudinna.com/); nice!
<ogra> yep
<ogra> well
<ogra> kind of "images" :)
<persia> And a personal release, really :)
<ogra> its just a hacked up rootfs :)
<ogra> yeah, spare time fun
<vstehle> The kernel is at http://gitorious.org/ac100; how comes you don't have a branch in maverick kernel already ? :)
<persia> maverick is frozen.
<vstehle> persia: Oh, right, I forgot.
<persia> For natty, needs someone to maintain it.
<vstehle> On another topic, I found an interesting "side effect" of the netbook edition; bug #661003
<ubot2> Launchpad bug 661003 in software-center (Ubuntu) "Debconf dialogs are hidden (affects: 1) (heat: 10)" [Undecided,New] https://launchpad.net/bugs/661003
<vstehle> Not very "user friendly" :)
<persia> vstehle, What priority did you set the debconf prompts?
<vstehle> persia: No idea; I'll check.
<ogra> right, they neew to be high or critical to be shown iirc
<ogra> vstehle, the kernel is 2.6.29 ... we wont pull that into the distro :)
<persia> I hope not!
<ogra> nor will there ever be "real" images unless someone pays or the community steps up to get them (but in a more proper way than "untar that to your SD")
<persia> Mostly just needs one or two folk.  A kernel maintainer and someone to do image verification.
<persia> Mind you, getting hosting on cdimage is a bit more opaque and complicated, but in theory.
<ogra> well, first of all it would need a way to wrtie the kernel updates to the device somewhere :)
<persia> One can't do that even after booting a proper kernel?
<berco> hi there
<ogra> nope
<berco> trying to test #637947 SRU
<ogra> you cant access the boot bits on the emmc
<ogra> berco, a bit premature :)
<hrw> ogra: use kexecboot
<ogra> berco, the kernel was just accepted a few minuted ago ... and alsa-utils wasnt yet
<berco> ogra: I just received the notification, thought I could test :)
<ogra> give it time to build ;)
<hrw> ogra: you put kexecboot kernel in flash, it boots, search on sd/flash for distro kernel and kexecs it
<berco> so that's normal I get maverick-proposed not found
<ogra> hrw, if kexec works, yeah
<hrw> ogra: Zaurus guys do that for quite long time
<berco> in sources.list?
<ogra> hrw, we had a spec for that to replace u-boot about three releases ago
<ogra> berco, yes, you need to enable it deliberately, -proposed is for update testing
<ogra> berco, packages go to proposed first, only if they recieved enough testing they go to -updates
<persia> It's been 90% done for a couple releases as well, just nobody ever really wanted it enough to finish it.
<ogra> its kind of a staging archive
<ogra> ugh
<berco> ogra: but does it exist yet? I get 404 not found on it
<persia> Probably not built yet.
<ogra> so i was testing the sound fix for the last half hour ... suddenly hearing nothing anymore since i started today
<persia> And you discovered that your headphones were unplugged?
<ogra> .... and i just noticed my headset is plugged into my laptop
<ogra> yeah
<berco> lol
<ogra> having team calls at night is NOT helpful !
<persia> Heh.  +1 for the "is it plugged in" method of troubleshooting :)
<ogra> ok, works all fine
 * ogra calms down again
<berco> ogra: persia: thanks, that's good news
<ogra> now that really woke me up at least
<ogra> berco, we're still missing one part
<berco> ogra: what do you need?
<ogra> the pulseaudio profile file isnt there yet
<ogra> so currently HDMI isnt exposed in the UI
<berco> has abduenas sent you anything?
<ogra> not yet
<vstehle> persia, I checked the debian/preinst of the concerned package, and all the 'db_input' I see there have a "critical" priority. Also, the window is presented, only it appears in the background, so I don't think this is related to the prio after all.
 * ogra checks the longish mail thread again ... i probably missed it
<berco> ogra: how can I take your changes to test on my side?
<berco> I have abduenas file, I could probably share this with you too
<persia> vstehle, Indeed, it's not.  I think it's related to maxiumus or whatever replaced it.
<ogra> berco, you would need to compile alsa-utils and the kernel from the source package ... better just wait
<persia> ogra, You understand these WM oddities better than I: any ideas?
<hrw> ogra: switch to using BT headsets for calls
<ogra> persia, might be a timestamp issue
<vstehle> ogra, persia, you know, the message actually _is_ presented. Its window is just "below" the software center, I think...
<ogra> persia, i havent done much with WMs for the last 1.5 years but i think metacity introduced a timestamp thing, would probably be a question for mvo if sw-center has "always on top" set or some such
<ogra> that might override the timestamp
<ogra> vstehle, in any case file a bug against sw-center
<persia> ogra, timestamp? for wnck-placement stuff?  (and I haven't done anything with WMs in >15 years, so you're closer)
<ogra> (mvo might reassign it to debconf-gkt or so)
<ogra> *gtk
<persia> 661003 is definitely the right bug.
<persia> But yeah, probably needs mvo.
<ogra> ah, alsready there
<vstehle> ogra, yes
<ogra> bug 661003
<ubot2> Launchpad bug 661003 in software-center (Ubuntu) "Debconf dialogs are hidden (affects: 1) (heat: 10)" [Undecided,New] https://launchpad.net/bugs/661003
<ogra> heh, you're to fast vstehle :)
<vstehle> ogra, the only problem with this is that it is "user unfriendly" :)
<persia> vstehle, That's a bug :)
<ogra> yes, agreed
<ogra> hmpf
<berco> ogra: persia: just updated #637947 with proposed profile
<ogra> my alsa-utils fix can need some improvement
<berco> can you test if HDMI works?
<ogra> damned
<ogra> no biggie, but alsactl init is only actually needed if no state file exists (it does no harm if its run when it exists but is a useless extra call)
<persia> So it's only needed the first time?
<ogra> yes
<ogra> i'll update the fix with a check for the state file i think
<ogra> i mean i could as well leave it in ... the mixer volumes are properly restored etc
<ogra> but its not "clean"
<ogra> berco, your pulseaudio.rules wont work
<berco> what's wrong with this file? I just uploaded the file from our audio team
<ogra> berco, it will only work on blaze ;)
<berco> ogra: agree.
<berco> is that possible to "or" in the ATTRS{id} field of the rules file? I guess the conf file can apply to both blaze and panda boards
<devilhorns> ogra, !! (just felt like shouting your name) :P
<ogra> devilhorns, !!!
<devilhorns> hehehe
<ogra> berco, either that or switch inside the conf and use something else in rules
<ogra> i'll have to inspect that
<ogra> berco, once the basics are in i'll look at pulse (unless someone beats me to it)
<rsalveti> morning
<asmcos> hi all
<persia> hey asmcos
<persia> Were you able to get maverick running on your 3530?
<asmcos> hi persia
<asmcos> i should try
<asmcos> i want to compile source code
<persia> OK.  Any code in particular?
<asmcos> i see
<asmcos> i need a example
<persia> The "hello" package is the classic example.
<asmcos> yeah
<persia> So, apt-get source hello should get you the source.
<persia> But I still think you want to install 10.10 on your 3530 before you proceed.
<asmcos> debuild -nc -us
<persia> You could.  I'd probably do `debuild -b -us -uc`
<asmcos> ok
<asmcos> i hope do a command to compile some packages ,not a package
<asmcos> so i use apt-build world
<persia> What do you expect `apt-build world` to do?
<ogra_ac> cleanup my house !
<ogra_ac> and do the dishes indeed :)
<rsalveti> vstehle: ogra_ac: https://edge.launchpad.net/~tiomap-dev/+archive/release
<rsalveti> awesome!
<rsalveti> let me try with the ti icon
<ogra_ac> rsalveti, well, enable universe/multiverse first
<rsalveti> true
 * ogra_ac will upload the fix for that fater the call
<ogra_ac> argh
<ogra_ac> no ndec, damned
<ogra_ac> his -config package will completely break audio
<ogra_ac> it collides with the fix thats in the archive nw
<ogra_ac> *now
<gmdq> hello, after writing the image (ARM/OMAPMaverickInstall wiki) EXT4-fs (sdc2): bad geometry
<gmdq> how extract it manually
<vstehle> rsalveti, you will need to enable universe/multiverse
<ogra_ac> vstehle, are yu near ndec ? we're all waiting for the chair ...
<vstehle> ogra_ac, I'll got get him :)
<rsalveti> vstehle: just did that, will now try with the icon
<ogra_ac> vstehle, thanks :)
<lag> sebjan_: Is there a meeting today?
<ogra_ac> lag, patience is golden
 * lag just hung up
<vstehle> He's back
<ogra_ac> good
<lag> Do you mean "patience is a virtue"
<persia> yes
<persia> Unapproved packages in maverick-proposed: https://launchpad.net/ubuntu/maverick/+queue?queue_state=1
<rsalveti> vstehle: ogra: interesting: Total size: 80.9GB to download, 80.9GB when installed
<rsalveti> hehe
<rsalveti> using ubuntu-omap4-extras
<persia> Some blueprints links: https://blueprints.launchpad.net/~davidm/+specs?searchtext=%27-n-%27 is about as close as I can figure out how to find the ones davidm is looking at.
<persia> https://blueprints.launchpad.net/sprints/uds-n is the set that shall be discussed at UDS.
<davidm> http://blogs.arm.com/software-enablement/going-maverick-ubuntu-10-10-for-arm/
<rsalveti> ndec: these are the x-loader changes we made for panda: http://gitorious.org/~rsalveti/pandaboard/rsalveti-x-loader/commits/omap4_panda_es2.1
<rsalveti> would be nice to check this performance difference we have on blaze
<ndec> rsalveti: thanks. we will look into this. vstehle, see ^^^
<ndec> rsalveti: where is the branch for the MLO for blaze?
<rsalveti> ndec: I'm using the same one for panda and blaze
<rsalveti> just build it for sdp4430
<ndec> rsalveti: ok.
<ndec> rsalveti: looks like we don't have this one for blaze: http://gitorious.org/~rsalveti/pandaboard/rsalveti-x-loader/commit/71d0d1faf3c40a2c394c73869fc6030ca56b3d12
<rsalveti> ndec: yup
<rsalveti> because no one was complaining of sync lost with it
<rsalveti> but let me check what clocks are being used for blaze...
<rsalveti> ndec: we don't need this patch for blaze because it was already with these values
<rsalveti> from sebjan_ commit it seems it was changed at panda because of the 6 layers board
<ndec> rsalveti: right
<gmdq> how extract preinstalled img with netbook ubuntu to directory ?
<ogra_ac> you mean to SD card ?
<ogra_ac> or do you want to extract the content ?
<gmdq> extract content
<ogra_ac> well, easiest is surely to extract to SD and then just grab stuff from the second partition
<gmdq> with sh -c 'zcat . ...' - EXT4-fs (sdc2): bad geometry
<ogra_ac> alternatively you can gunzip and loop mount
<GrueMaster> Actually, it is easier to mount the partition.
<ogra_ac> ext4 fs ?
<gmdq> yep
<ogra_ac> the image doesnt contain any ext4
<ogra_ac> only vfat and ext3 filesystems
<gmdq> hm, i use ext4 driver for ext2 and ext3
<ogra_ac> how exactly did your command look like ?
<GrueMaster> gmdq: First run "gunzip < <image.gz> > <image>"
<GrueMaster> To uncompress it.
<ogra_ac> did you extract to a filesystem instead of a disk ?
<gmdq> i know
<GrueMaster> Then type "file <image>" to determine partition start block.
<gmdq> one second
<GrueMaster> To mount it, type "mount <image> <mount point> -o loop,offset=$((512*<start block>))"
<rsalveti> GrueMaster: that should be in the wiki page
<GrueMaster> example:  sudo mount maverick-preinstalled-netbook-armel+omap.img mnt/ -o loop,offset=$((512*63))
<GrueMaster> I think it is, just can't remember *which* wiki page.
<rsalveti> hehe
 * rsalveti out for lunch
<gmdq> GrueMaster: thx
<GrueMaster> The above example is for the boot partition.
<cpearson> GrueMaster: I tried booting from the the image and I get a CRC error on the Kernel.
<GrueMaster> Compare md5sums with the md5sums file in the release directory.  If they match, write /dev/zero to your sd card & reflash the image.
 * GrueMaster out for an hour.  Driving to Portland.
<oli44> hello!
<ndec> ogra: GrueMaster: do you know where the cdimage.ubuntu.com server is located? is it UK or US?
<ogra_ac> UK
<ogra_ac> london ...
<ogra_ac> want the address ?
<armin76> yes
<armin76> :D
<ndec> ogra: thanks! no need for the address!
<ogra_ac> :)
<ndec> ogra: the 'ports' are mirrored on ubuntu standard mirros. I am talking about cdimage mirror, not archive. any reason?
<ogra_ac> nothing is mirrored
<ogra_ac> neither cdimage.u.c nor ports.u.c
<ogra_ac> (probably worth putting up an UDS spec about that ;) )
<ndec> ogra: how about https://launchpad.net/ubuntu/+cdmirrors
<ogra_ac> just space issues, i think the reason is to not put off mirror admins by wasting their space for rather rarely used images
<ndec> ogra: oh this is r.u.c, right?
<ogra_ac> yep
<armin76> ogra_ac: what bogomips do you have on the ac100?
<ogra_ac> 2x ~2000
<armin76> k, 1998 && 1992 on the harmony board
<armin76> wonder why they're different
<ogra_ac> how are they different ?
<ogra_ac> oh, you mean between the cpus ?
<armin76> yep
<ogra_ac> same here
<ogra_ac> no idea though, probably one has the gpu directly attached
<persia> Um, there are some cdimage mirrors, but most of them aren't very complete.
<oli44> hello, channel!
<oli44> this is my first time here, gving a try to an omap board named igep
<ogra_ac> your mileage may vary with the igep2
<ogra_ac> there are still some patches missing to make the images properly work on them
<oli44> ok
<rsalveti> ogra_ac: latest update should have most of the fixes
<ogra_ac> ah, k
<oli44> actually , i purchased it with a working ubuntu 9.04 SD
<ogra_ac> then i'm not up to date, rsalveti is your man ;)
<rsalveti> hm, actually some of them are not yet released, just at the repo
<rsalveti> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-maverick.git;a=summary
<oli44> i'd like to upgrade to the LTS: if i add a line such as deb http://ports.ubuntu.com/ubuntu-ports lucid main multiverse universe then i dist-upgrade, that sould do the trick?
<ogra_ac> no, use do-release-upgrade
<ogra_ac> http://www.ubuntu.com/desktop/get-ubuntu/upgrade
<oli44> yeah, already tried it but without adding the lucid line
<oli44> back in a few minutes
<oli44> hopefully for cheers
<oli44> hmm, says no new release found
<sunnydrake> hi can anyone post links on rootfs (preferably busybox) images?
<sunnydrake> and pxa270 arm images?
<sunnydrake> kernel
<ogra_ac> we only have preinstalled omap3/4 and live dove images
<ogra_ac> for other rootfses see the channel topic
<sunnydrake> thnx one more question kernelimage will output something without rootfs?
<sunnydrake> not on serial..via display
<ogra_ac> kernel is up to you, we dont have a kernel for that HW
<sunnydrake> i compiled kernel for arm but dunno if it works.. currently it jsut blank via haret boot
<cpearson> I just ran the updater for the first time on a clean image today for the Pandaboard build... All of the updates show as being 704MB, when downloading it says 2MB to download
<rsalveti> cpearson: yeah, that's weird, as I said in the morning, when getting packages from ppa it showed me 80.9GB to download
<rsalveti> hehe
<rsalveti> probably a bug somewhere
<cpearson> someone is dividing by close to zero eh?
<rsalveti> hehe, probably something like that
<rsalveti> also, when installing ubuntu-omap4-extras the license is set as unknown
<rsalveti> it should be proprietary or oss/proprietary, something like that
<oli44> hello
<oli44> just failed a release upgrade, machine is stuck
<oli44> libc-bin broke libc6 package
<oli44> now everythin segfaults
<oli44> even cat or cd
<rsalveti> ouch
<oli44> not cd
<oli44> bug ls
<oli44> is it recoverable?
<rsalveti> oli44: which release did you use as base when upgrading?
<GrueMaster> And what platform?
<oli44> jaunty on omap (igep, beagle board like)
<rsalveti> ok, seems at least sgx, wifi and bt are working fine from ppa
<ndec> rsalveti: this is cool!
<ndec> rsalveti: http://trailers.apple.com/ to test video from firefox, using GST plugins
<rsalveti> cool, will check gst
<GrueMaster> mpoirier: Did you want to submit a track on alsa soc for UDS?
<rsalveti> ndec: should it work with 720p and 1080p?
<ndec> rsalveti: yes
<rsalveti> nice
<ndec> rsalveti: for such resolution you need to have a full hd monitor, if you use a standard monitor, you need to play full screen, we currently have a bug when downscaling too much
<mpoirier> GrueMaster: to explain how the thing work in the kernel ?
<GrueMaster> More of what can be done in the kernel drivers to improve userspace interaction.
<GrueMaster> Have you gotten any detailed info on UCM?
<mpoirier> My quest was related to how the ABE, PDM and FE worked together - I did not looked into UCM specifically
<mpoirier> I got my information on the former.
<mpoirier> I'm still thinking about the "to improve userspace interaction"...
<rsalveti> ndec: yeah, saw that bug while at ti
<mpoirier> GrueMaster: I don't see how that interaction could be improve - the current implementation is the ultimate in terms of flexibilty.
<mpoirier> GrueMaster: unless you have ideas.
<rsalveti> ndec: awesome, trailers.apple.com works nicely :-)
<ndec> rsalveti: eheh... and the cool thing is the CPU load ;-)
<rsalveti> yeah, around 15%
<mpoirier> GrueMaster: I think we could fix our other omap3 boards using the same solution that was implemented to fix panda.  After all, the all export a distinct string in /proc/asound/cards.
#ubuntu-arm 2010-10-16
<Dingo_aus> G'day all - trying to install Maverick on a SD card for BeagleBoard and the instructions on https://wiki.ubuntu.com/ARM/OMAPMaverickInstall result in me getting a "bash /dev/sdc permision denied" error
<Dingo_aus> anyone know how to fix this?
<Dingo_aus> My relevant terminal session is:
<Dingo_aus> sudo sh -c './ubuntu-netbook-10.10-preinstalled-netbook-armel+omap.img.gz' > /dev/sdc
<Dingo_aus> bash: /dev/sdc: Permission denied
<persia> You get the error at trying to write the SD card?
<Dingo_aus> yes
<persia> Oh, right.  the redirect needs to be inside the quotation marks.
<Dingo_aus> oh...
<persia> Because you need the elevated permissions for > not for zcat.
<Dingo_aus> Thanks - yeah I usually use DD or other commands, not really familiar with this one - cheers
<persia> zcat ./ubuntu-netbook-10.10-preinstalled-netbook-armel+omap.img.gz | sudo tee /dev/sdc > /dev/null` might do almost the same thing, but I'm not sure I trust tee that much.
<persia> Oh, for dd, just unzip the image, and then `sudo dd if=${img} of=${SD} bs=1M` or something
<Dingo_aus> Thanks so much - my SD card is be written to as we type
<daurnimator> anyone here got a beagleboard xm?
<persia> daurnimator, There's a few folk who reported they had them, and the omap3 images were reported to work on them.  It may be that you'll get a better response to a specific question.
<dhiry2k> hi all while running apt-get install in chroot environment getting message as Unsupported ioctl: cmd=0xc020660b
<ogra_ac> yes, you can ignore that
<dhiry2k> ogra, but why this comes?
<dhiry2k> any issue in my chroot environment?
<ogra_ac> because qemu-static hasnt implemented this ioctl
<ogra_ac> no
<ogra_ac> every binary you run in your chroot is wrapped in qemu
<ogra_ac> its a qemu issue
<dhiry2k> ogra, oho then i can add bug for qemu
<ogra_ac> check before ... i think there might be one already
<dhiry2k> ogra_ac, compiling and creating .deb for armel in chroot is feeling quite slower process
<dhiry2k> ogra_ac, is there any way to do cross compile for arm in x86
<ogra_ac> its faster than in a VM but yes, still slow
<ogra_ac> dhiry2k, yes if you run maverick (10.10) hrw|gone can give you info
<dhiry2k> ogra_ac, what is normally preferred way to creating deb for armel
<ogra_ac> (he maintains the cross tools)
<ogra_ac> native compilation is the preferred way
<dhiry2k> ogra_ac, native means compiling in armel os itself
<dhiry2k> ?
<ogra_ac> yes
<ogra_ac> thats how we build the whole distro
<dhiry2k> ogra_ac, i have created filesystem using rootstock for 10.10
<dhiry2k> but each time rootstock takes packages from repo
<dhiry2k> i need to divert rootstock  to local directory where i kept almost all packages
<dhiry2k> and remaining it should take from repository
<dhiry2k> can it possible?
<rcn-ee> can't you copy and install them after you've created the image?
<dhiry2k> rcn-ee, first i created image with gnome not want to try with xfce then main basic packages already i have need not necessary to redownload
<dhiry2k> just downoad xfce4
<dhiry2k> i want to create different images of different display manager
<dhiry2k> but base packages for all are same
<rcn-ee> use a cache: like apt-cacher-ng ?
<dhiry2k> rcn-ee, can you elaborate it ..how to use this for rootstock
<ogra_ac> approx ftw
<rcn-ee> dhiry2k, with ubuntu/debian there's lots of *.deb cache/proxy tools to save bandwidth, the one i use is "apt-cacher-ng"
<rcn-ee> with rootstock i point to it with: "--mirror http://192.168.0.10:3142/ports.ubuntu.com/ubuntu-ports"
<rcn-ee> just remember, your final image will have "192.168.0.10" in the /etc/apt/source.list so if you give it to someone else, remembet to edit that..
<dhiry2k> but i am feeling if i give gdm or xfce,lxde either of this then rootstock takes many packages which i dont need
<dhiry2k> so always needed to to remove packages manually
<dhiry2k> after creating filesystem
<rcn-ee> last i tried lxde it brought in a lot of extra stuff, 'xfce' by itself is still pretty minimal...
<ogra_ac> just use ubuntu-minimal then
<ogra_ac> save that ... and then add on top of a copy
<dhiry2k> ogra_ac, ubuntu_minimal has any desktop environment or need to add manually
<rcn-ee> for xfce, i use this to get a prety minimal desktop: "--seed xfce4,gdm,xubuntu-gdm-theme,xubuntu-artwork,xserver-xorg-video-omap3"
<ogra_ac> minimal is minimal console system
<dhiry2k> rcn-ee, lxde looks good diaplay manager
<dhiry2k> but i have seen my board gets heated after some time of running display manager
<rcn-ee> yeah i used it by default with jaunty on my beagle..
<rcn-ee> heated: wait till the pm changes in 2.6.37...
<dhiry2k> rcn-ee, have faced issue of heating
<dhiry2k> have you  faced issue of heating
<rcn-ee> yes... even in mainline, only the cpu idle bits are their, the core other wise runs at what ever clock speed you give it..
<rcn-ee> looking at what's going in 2.6.37 it'll get a lot better...
<dhiry2k> how to improve performance on beagle for display manager and running different application at same time
<ogra_ac> upgrade the HW to a pandaboard ;)
<dhiry2k> ogra_ac, you mean pandaboard has more ram and better CPU?
<rcn-ee> just on the beagle? make sure your running it as fast as it can.. bx/cx = 600, c4 = 720, xm (800, 1Ghz with 2.6.37).. lots of swap.. really fast usb-harddrives as rootfs..
<ogra_ac> dual core 1GHz and 1GB ram, yes
<dhiry2k> rcn-ee, i not created swap
<dhiry2k> how to swap ?
<rcn-ee> that'll kill the desktop experience..
<dhiry2k> how to add swap
<rcn-ee> since you've allready partition, used the swap file option: https://help.ubuntu.com/community/SwapFaq
<ogra_ac> yeah, you should use swap files in any case
<ogra_ac> dont use swap partitions on SD
<rcn-ee> but sometimes you just have to. ;)
<dhiry2k> ogra_ac, rcn-ee thanks it worked
<Neko> ogra, oem-config still doesn't work because gdm starts instead as usual
<Neko> the permissions are fine now I fixed rootstock but gdm is still in the way
<ogra_ac> well, doesnt happen for anyone else
<ogra_ac> must ne necause you touch the rootfs
<Neko> could it be 100% down to lack of initramfs?
<ogra_ac> no
<Neko> 10%?
<ogra_ac> heh
<ogra_ac> no
<Neko> okay so ruling that out what on earth makes it so that gdm starts and then ubiquity-dm just complains and complains in the background that it cannot start X?
<ogra_ac> likely still permissions for dbus
<Neko> but they're fine
<Neko> that gdm starts at all means the tar fix in rootstock worked
<Neko> (otherwise /var/lib/gdm is owned by hplip on  my system :)
<Neko> could it be that rootstock simply fails to set up dbus properly when doing the chroot and this is the problem not so much the correct permissions but lack of actually setting permissions
<ogra_ac> might be
<ogra_ac> no idea, really, i just know it works for others that dont touch the filesystem
<Neko> rootstock-201010121152.log:WARNING:root:Failed to setup dbus (ignoring)
<Neko> for instance :)
<Neko> we don't touch it either
<Neko> I extracted a rootstock directly to an SD card
<Neko> I even tried leaving the image there, mounting it, and rsyncing to sd card
<ogra_ac> Failed to setup dbus is expected in a chroot
<ogra_ac> thats what its supposed to do
<Neko> qemu should fix it?
<Neko> or firstboot?
<ogra_ac> dbus sets up itself on first start, right
<ogra_ac> see its init script
<Neko> so frustrating
<Neko> anyway I really popped in here to ask since I noticed.. linux-headers-linaro-imx51??
<ogra_ac> wrong channel ;)
 * ogra_ac points to #linaro
<Neko> yeah I guessed as much :D
<ogra_ac> its plain upstream afaik
<zumbi_> i am trying to run unity, but I get a message on required driver missing.. any ideas?
<ogra_ac> get a driver ?
<zumbi_> ogra_ac: what driver?
<zumbi_> unity-driver?
<ogra_ac> one that supports 3D
<ogra_ac> unity makes heavy use of GL
<zumbi_> uhm.. that might be tricky as i am on a imx51 netbook
<zumbi_> not sure if that is supported
<ogra_ac> ask Neko :)
<ogra_ac> but its unlikely that even if you have a driver it will work
<ogra_ac> on ARM GL usually means GLES
<ogra_ac> which is only a subset of GL and parts of unity are still not supporting it fully
<zumbi_> I believe GLES is supported by omaps
<zumbi_> oh! so, unity not for ARM?
<zumbi_> linrao might need to fiix that :)
<ogra_ac> not yet
<ogra_ac> there is work going on for it
<ogra_ac> in linaro
<ogra_ac> and the canonical DX team
<ogra_ac> and in TI
<ogra_ac> but its not there yet
<zumbi_> not FSL?
<ogra_ac> i saw unity running for a few mins on a pandaboard
<ogra_ac> but it still locks up often
<ogra_ac> zumbi_, no idea ubuntu-arm doesnt do anything with FSL anymore
<ogra_ac> they dropped out
<zumbi_> uhm.. bad for them
<Neko> we will be supporting it soooooon
<ogra_ac> Neko, lol
<zumbi_> Neko: what will we be supporting soon?
<Neko> there are some things we want to fix first and building other packages takes precedence
<ogra_ac> so you plan to rewirite clutter alone ?
<Neko> we did ship GL libs one time but.. they are buggy :D
<ogra_ac> ah, GL
<Neko> not clutter, just shipping GLES
<ogra_ac> i thought unity
<zumbi_> ogra_ac: out of curiosity, is unity related to Erlang programming language?
<ogra_ac> might be
<zumbi_> i saw some erlang dependencies, but i was not sure if it is related
<ogra_ac> i think something is using erlang in the default install nowadays, might be ubuntu-one though
<Neko> I thought ubuntu-one used python
<zumbi_> Erlang is quite impressive
#ubuntu-arm 2010-10-17
<pdc> I downloaded ubuntu-netbook-10.10-preinstalled-netbook-armel+omap.img.gz, zcatted it to a microSD, and attempted to boot it on my BeagleBoard-xM.  It booted to the point where it said "Uncompressing Linux... done, booting the kernel." and then nothing else happened.  The DVI monitor did not get a signal.  Any suggestions?
<persia> pdc, On which output did you get the Uncompressing... message?
<persia> Anyway, the point of the question was that the base image attempts to uncompress and occupy the entirety of the MMC storage on first boot: As microSD tends to be slow (at least mine are *very* slow), I wonder if this isn't just taking much longer than expected.
<persia> I've not tried, but I understand some folks have tried to get serial console working, so I can imagine some messages going to serial console, and then the uncompress message failing to go to DVI for some reason.
<persia> (but I'm just speculating, and hoping someone who actually has an XM can comment on their experience)
<lool> sakoman: Ah found these u-bbot env file patches for u-boot again, they were simply in my PPA!  sending them to you now
<ogra_ac> lool, hmm, could it be that your libnnss-ldap patch was never applied in debian and soemone moreged it into ubuntu without the gnueabi fix ?
<ogra_ac> (looks serious enough to justify an sru to me)
<lool> ogra_ac: Do you intend to merge this older x-loader changes of mine in natty?
<lool> ogra_ac: libnss-ldap > indeed, it seems this was dropped by Chuck for some reason
<lool> ogra_ac: Actually, I still see the patch in debian/patches/60_fix-glibc-test-for-armel-gnueabi.patch
<lool> but not applied anymore
<ogra_ac> lool, yeah, after UDS i'll care for x-loader unless rsalveti does it earlier
<ogra_ac> and indeed the plan is to get your changes back in
<lool> ogra_ac: I've pushed a fixed libnss-ldap; do you have a way to test it?
<ogra_ac> lool, not really, i have an LTSP arm spec though so i will be able during implementing that
 * ogra_ac doesnt currently have any LDAP server around
<voipster3> hi all
<voipster3> anyone tried installing on a beagleboard c3?
<voipster3> it boots but it doesn't seem to show any screen at all
#ubuntu-arm 2011-10-10
<dash> hi! i find myself compiling a kernel for ubuntu for the first time in 5 years :)
<dash> is make-kpkg still the thing people use when building custom kernel debs?
<hoshi411> ive noticed android/ubuntu dual boot tablets on youtube but has anyone gotten around having to go through an external pc to change which system you want to boot?
<hoshi411> like using u-boot or CWM?
<hoshi411> always having to externally change some zip file everytime I want to `change the system I boot is not a very nice option
<dash> that would be nice.
<twb`> hoshi411: you have a TF101; its default bootloader will switch to a "rescue" mode if you hold down voldown and power while booting; this rescue mode is simply a different kernel
<dash> hoshi411: yeah it's like having to stop at a gas station every time you want your car to change gears
<twb`> hoshi411: thus, you can replace the rescue mode of android with a normal ubuntu/debian kernel
<hoshi411> twb: I see that is an interesting trick... but then how do you designate which kernel you want the rescue mode to boot?
<hoshi411> is there really no way to communicate with the bootloader, like on windows bios , grub , yaboot etc?
<twb`> hoshi411: the ASUS bootloader is hard-coded to bootstrap specific partitions for normal and rescue mode, so you pick by writing the kernel and ramdisk into the appropriate partition
<twb`> hoshi411: on the TF101 there is no way to communicate with the default bootloader except for that voldn thing, and u-boot currently has no support for the keyboard doc OR the volup/dn buttons, so you cannot provide any input at boot with u-boot.
<hoshi411> O_o but if you can root an android device then you can install any soft you want on it
<twb`> hoshi411: however if you have a dock, you can put the u-boot scripts or environment onto a SD card or USB (but not micro SD), and u-boot will do whatever the script says.  So to change how booting will happen, you can put that SD card into a working box, and reconfigure it.
<twb`> hoshi411: uh, only within android
<dash> hoshi411: yeahbut someone's gotta write it :)
<twb`> hoshi411: rooting android won't allow you to e.g. replace its kernel
<twb`> And you probably can't easily replace e.g. the shitty android UI with normal X.
<hoshi411> twb: but rooting android would allow me to run a terminal right
<twb`> hoshi411: I wouldn't know, I do not support or use android.  Talk to the android people about that.
<hoshi411> the ideal way to do a dual boot would be to be able to select the kernel , not at startup but before shutdown
<hoshi411> if I could somehow in android select which kernel I want to boot from
<hoshi411> and then boot into it ... then from that distro also to go and select the android kernel again
<hoshi411> etc....
<hoshi411> before shutdown
<hoshi411> that seems ideal to me
<twb`> That's how Macs used to work; it's a fucking pain because if the main system breaks, you're hosed
<twb`> IMO it's better to have it boot the right thing, and if it screws up you insert a rescue SD card
<twb`> s/main system breaks/current system breaks/
<dash> so... any of y'all build a custom kernel .deb lately? :)
<twb`> dash: yes.
<dash> twb`: what do you use? when I were a lad, make-kpkg was the thing
<twb`> It's built into upstream now
<hoshi411> can't you just mount the boot partition and alter the boot scripts on the asus device?
<dash> in particular I want a kernel with NFS server support
<twb`> Just do "make deb-pkg"
<dash> and i'm not seeing one in oneiric for mx53
<dash> twb`: aha.
<twb`> hoshi411: the asus bootloader has boot partitions that are in a hokey android format; you can't mount them
<twb`> hoshi411: you'd have to rebuild them from source components and then reflash them onto the device
<dash> was thinking about installing ubuntu on my tf101
<dash> sounds like i should wait
<twb`> dash: you can have 2.6.36 now
<twb`> dash: but it can't drive the wifi or bt or much else, so it's pretty useless
<hoshi411> a hokey android format? not ext or ntfs etc?
<dash> hoshi411: correct.
<twb`> hoshi411: correct.
<twb`> hoshi411: specifically abootimg format
<hoshi411> abootimg ... hmm
<hoshi411> twb: wouldn't this allow you to read the files on that partition https://launchpad.net/ubuntu/+source/abootimg
<twb`> hoshi411: I doubt it.
<twb`> Hm, actually it looks like you're right, you could pull apart the bits from that, edit them, reassemble them, then reflash it back on
<twb`> But you'll still need the reflash step, which either means nvflash on an external device or (maybe) flashing it from within a working device, and the default partition table doesn't expose that partition to the OS.
<hoshi411> twb: and depending on the script that is used to select the kernel on bootup... you might be able to reflash it in a way where you wont have to reflash every time you want to change kernels
<twb`> hoshi411: in magical fairy land, sure.  I wouldn't hold your breath waiting for it in the real world.
<hoshi411> I use yaboot on ppc but have never tinkered with grup on my pc ... but as far as yaboot goes , it is just a script that allows me to select the kernel at bootup... and I can change the script to allow for any kernel I want or as many as I want....
<hoshi411> grup > grub
<hoshi411> arg... I really wanna get inside that boot partition
<twb`> Look, the short version is: bootloading on ARM is fucked up.
<twb`> Do not expect it to be as nice as PPC or x86
<hoshi411> twb: yea but I cant give up
<hoshi411> I need gimp on my transformer
<hoshi411> otherwise it's almost a paperweight to me
<hoshi411> and I need the ability to boot back into android whenever I want
<hoshi411> without haveing to wait to get home just to connect it to my pc and change some zip kernel whatever
<hoshi411> twb: but thanks for updating me on the state of things on the transformer right now
<hoshi411> Im gonna try and see if I can get into the boot partition somehow
<hoshi411> im trying to get ubuntu chroot on my asus transformer
<hoshi411> do I need windows to do this?
<hoshi411> or can't I do it from ubuntu
<hoshi411> my windows partition is acting up and ... it would be nice to be able to do this from the ubutu side
<hoshi411> I think I have to root my device right?
<twb`> No.
<hoshi411> really. there is an easier way?
<twb`> hoshi411: if you want to *boot* Ubuntu, you need to follow the notes I showed you in #debian-arm.  If you just want a chroot, you need to root android, and that is off-topic for this channel.
<twb`> Rooting android is probably substantially easier, but I don't know.
<hoshi411> yea I just wanna chroot, cause I really don't wann ahave to connect it to a pc every time I wanna switch back and forth
<hoshi411> ive been at this all day
<hoshi411> and I give up
<hoshi411> chroot will give me an easy switch back and forth
<hoshi411> would be great if there were gimp on android
<twb`> hoshi411: android is off-topic for this channel.  I won't help you with that.  Go find the android channel and ask them instead.
<hoshi411> chroot may be off topic but there is a version of ubuntu that runs on chrooted android that I have seen.... that would be on topic right?
<twb`> hoshi411: I suppose so, *once* you have it working
<hoshi411> ive seen it on the galaxy tab
<twb`> The vast majority of "get it to chroot" issues will be on the android side
<hoshi411> aright
<hoshi411> ill go there
<soren> twb`: Are you suggesting you've gotten Ubuntu to boot on an ASUS Transformer? Or know of someone who has?
<twb`> soren: lilstevie has a working .36 boot, which I have reproduced
<soren> *drool*
<twb`> soren: he also allegedly has .38 CrOS, but I can't reproduce that because u-boot isn't working for me
<hoshi411> soren: it seems that he has done it but .... still no one has figured out how to switch between android and ubuntu without hooking the tablet up to a pc
<soren> Those things look awesome, but I'm not looking for an *extra* gadget to carry around. Someething that could replace my laptop... maybe.
<twb`> soren: http://cyber.com.au/~twb/doc/tf101.html contains about half my notes so far
<twb`> Yeah, I bought it to replace me Eee PC 1005P, because 1) quadruple the battery life; and 2) ARM is a "fun" challenge.
<lilstevie> you can dual boot
<lilstevie> at the cost of recovery
<lilstevie> but you can still switch without needing to hook it up to the pc
<twb`> lilstevie: dunno if you saw the scrollback, but hoshi411 doesn't seem to be interested in that
<hoshi411> lolstevie: how do you switch without having to hook it up to a pc?
<lilstevie> by having one OS kernel in the recovery slot
<twb`> 14:17 <twb`> hoshi411: the ASUS bootloader is hard-coded to bootstrap specific partitions for normal and rescue mode, so you pick by writing the kernel and ramdisk into the appropriate partition
<hoshi411> lolstevie: are you sure about that
<twb`> 14:17 <twb`> hoshi411: on the TF101 there is no way to communicate with the default bootloader except for that voldn thing, and u-boot currently has no support for the keyboard doc OR the volup/dn buttons, so you cannot provide any input at boot with u-boot.
<lilstevie> my kit sets it up like that, so yes I am sure
<lilstevie> and I have over 2000 people using my kit at the moment
<soren> twb`: Yeah, the crazy long battery life + being able to separate keyboard from the rest makes it excellent for traveling.
<twb`> soren: what would be *really* nice is if the keyboard could talk bt to the tablet while they were apart :-(
<hoshi411> lolstevie: can you give me a link to "your kit "
<soren> twb`: Yes. Yes, it would.
<twb`> soren: if you just want a netbook, the Toshiba AC100 is apparently quite similar
<lilstevie> lilstevie.geek.nz/ports/linux-flash-kit.tar.gz
<hoshi411> twb: lilstevie says he's got it dual booting back and forth without hooking it up to a pc. are you believing this?
<twb`> hoshi411: yes
<lilstevie> it is at the cost of recovery mode
<soren> twb`: How big is the transformer? Specifically the keyboard.
<hoshi411> >:| but you keep saying it is impossible
<twb`> soren: I dunno; it's about a quarter-inch wider  than my 1005P
<lilstevie> so you only need to use the pc, at the time you want to update or need CWM
<twb`> soren: go down to your local hifi store and look at once
<twb`> s/once/one/
<soren> twb`: So slightly larger than a netbook, but still some way to go up to a laptop sized one.
<twb`> soren: it's 10"
<lilstevie> battery life pwns a netbook
<soren> twb`: I'm almost 100% sure noone around here stocks stuff like that.
<twb`> soren: obviously, smaller than a 12" or 16" laptop or so
<twb`> soren: where are you again?  Uppsala or something?
<soren> twb`: Aalborg, Denmark.
<twb`> Hum
<lilstevie> denmark most certainly does
<soren> I'm sure I can order it, I just doubt they stock it and/or have it on display.
<soren> There are lots of smallish hifi stores who all carry mostly the same mainstream stuff.
<hoshi411> lilstevie: im running honeycomb 3.1 on my asus transformer but will your kit force me to downgrade or anything like that?
<jondo> morning
<lilstevie> hoshi411: it will force you to run what ever rom you want
<hoshi411> lilstevie: do you have any recommendations of roms based on honeycomb 3.1 or 3.2?
<twb`> lilstevie: I'm planning to email muromec describing my u-boot problems, what I've tried, what the symptoms are, etc, and CC you.  Is that cool with you?
<lilstevie> hoshi411: prime
<hoshi411> hmm ok
<lilstevie> twb`: sure, want me to upload a binary for you to test?
<lilstevie> don't bother writing it just run it in ram
<lilstevie> to make sure it works
<twb`> lilstevie: also if you can work out how to get me a copy of u-boot.bin that works for you, I can verify that I'm at least uploading it to my device correctly
<twb`> lilstevie: right, understood (re just ram)
<twb`> Hell, you can just email it to me, since it's only 200kB or so
<lilstevie> kk
<lilstevie> I was just going to upload it :p
<twb`> Whatever's easiest for you
<lilstevie> twb`: well I am going to extract it from my device and decrypt it for you
<twb`> Ace
<twb`> I'm going home in a minute, so if it's gonna take you a while just email it me or so, since I won't have time to mess with my tf before the weekend or so anyway
<twb`> no rush
<lilstevie> shoot me an email and I will shoot it back a bit later
<twb`> lilstevie: later, dude
<hrw> wii infinity
<infinity> infinity [~adconrad@66.79.167.154]
<infinity>  ircname  : Adam Conrad
<infinity>  channels : #ubuntu-desktop #ubuntu-installer #linaro-armhf #ubuntu-release
<infinity>             #ubuntu-arm #ubuntu-devel
<infinity>  server   : wolfe.freenode.net [Manchester, England]
<infinity>           : is connecting from *@66.79.167.154 66.79.167.154
<infinity>  idle     : 0 days 0 hours 4 mins 37 secs [signon: Sat Oct  8 23:46:12 2011]
<infinity> End of WHOIS
<infinity> Hope that helps. :P
<lilstevie> lolwit
<lilstevie> lwut
<lilstevie> fail
<infinity> lilstevie: That was my response to hrw's wii. :P
<lilstevie> lol
<hrw> ;D
<jondo> Hi! My BeagleBoard-xM gives me "hub 1-0:1.0: unable to enumerate USB device on port 2". Does that sound familiar to anyone?
<jondo> See my dmesg at http://paste.ubuntu.com/705313/
<davidm> ogra_, you about?
<ogra_> davidm, indeed
<davidm> did you see my pm to you?
<ogra_> on freenode ? nope
<davidm> Interesting
<ogra_> ah, seeing it now
<ogra_> i was testing suspend oin the ac100, seems you opened it while i just fell over
<ogra_> yup, will take care
<infinity> ogra_: Reinstalled my ac100 and ran through a bunch of tests here, seems good.
<ogra_> yay
<ogra_> did you try suspend ?
 * ogra_ also isnt sure zram was actually a good idea, tell me if you see hangs after some time
<xranby> ogra_: did you see my rants about echo 30000 > /proc/sys/vm/min_free_kbytes
<xranby> ogra_: my experience are that there are some bug in the kernel that makes the kmalloc unable to operate when memory are low    even in situations when swap are available
<brandini> ogra_: so I got my openbsd userland cross compiled, then built my kernel fromthat, learned about the fun required to create a proper bootable partition on the SD card, installed uboot, MLO etc to there and pointed it at my bsd kernel only to find out mboot doesn't like my bsd kernel format
<ogra_> xranby, what you see is  a "normal" message from wlan USB, we should be shipping a sysctl.d file like we do on omap
<ogra_> it doesnt do any harm even though it looks like an oops
<lilstevie> ogra_: how are you working out suspend on the AC100
<ogra_> lilstevie, ask in #ac100, i'm just a consumer of their work ;)
<lilstevie> haha
<lilstevie> ok
<ogra_> but i think they reverse engineered the nvec commands needed for the device
<lilstevie> ah
<lilstevie> nvec isn't used here
<ogra_> right, thats why i mention it ;)
<lilstevie> :p
<xranby> ogra_: if you feel unsure about zram then do not iclude it for the release
<ogra_> xranby, a bit late now :P
<xranby> haha ok
<lilstevie> ogra_: however have been testing out the graphics acceleration with CrOS kernel
<xranby> ogra_: are there anything we can do before release?
<ogra_> i could try but i would have to be sure about it adding instability
<ogra_> ripping it out if it isnt at fault at all would be really bad
 * ogra_ would like to see some test results from people seeing hangs ... so we can see if its zram or not
<lilstevie> having some show stopping bugs though
<ogra_> i suspect that OOM doesnt work properly if zram is used
<xranby> ogra_: on my machine i can workaround these hangs by raising the /proc/sys/vm/min_free_kbytes
<xranby> ogra_: i do see userspace hangs without touching that knob
<ogra_> xranby, and also by disabling zram at all ?
<xranby> ogra_: i see hand by using swap on usb as well
<xranby> so imho the bug are not zram related
<xranby> mroe a generic kernel have trouble to operate when memory are low issue
<ogra_> well, i'd like to know if they go away if you dont use zram, just to prove that
<ogra_> (or if they dont go away i should say)
<xranby> ogra_: (14.49.57) juliank: xranby_ac: The bug is not related to swapping, so stop pretending that it is. Lower the value and you'll see those crashes without swap as well
<ogra_> hmm, k
<xranby> ogra_: juliank: claim that he starts to see crashes mroe frequently if the threshold gets lowered
<xranby> imho the system should run stable even if the threshold are insanely low
<xranby> else its a kernel bug
<ogra_> well, i use 8192 as a default here
<ogra_> (for the famous wlan bug)
<xranby> ok. i think the kernel defaults to around 2600
<xranby>  2698, the ubuntu's calculated default for ac100
<xranby> the reason why using zram makes things worse are because the kernel itself uses more slub's when zram are activated
<xranby> imho
<ogra_> infinity, hmm, if we actually do a respin i wonder if we should add an: echo "vm.min_free_kbytes=30000" >/root/etc/sysctl.d/99-ac100 to the installer
<infinity> ogra_: Erk.  Why?
<infinity> ogra_: My ac100 seems happy enough.
<ogra_> infinity, to fix xranby's hangs after some hours
<ogra_> mine too ... but more than one person seems to have issues regarding that
<xranby> infinity: the hang happens when trying to run two memory hogs firefox and thunderbid at the same time
<ogra_> hmm, i probably dont see it because i would never do that :)
<ogra_> i dont think it will do harm for the working ones and it seems to fix it for the non working ones
<ogra_> (and it cant be an SRU since we have no package for such stuff (i guess i should intorduce an ac100-hacks package in P for such a purpose))
<jondo> Hi ogra. Is there anything I can further do now for helping with launchpad bug 871650? Any more logs needed?
<ubot2> Launchpad bug 871650 in linux ""unable to enumerate USB device" with BeagleBoard-xM" [High,Confirmed] https://launchpad.net/bugs/871650
<jondo> It probably doesn't make sense to try the current daily instead of last Thursday's?
<xranby> ogra_: do OOM killer still go around and slay your chrome?
<ogra_> jondo, well, i would recommend to talk to jcrigby about it once he is up
<ogra_> xranby, sure, if i use more ram thean i have it doe that
<ogra_> *does
<ogra_> same goes for firefox but with half the tabvs chromium can handle
<xranby> ogra_: ok not really a bug then
<xranby> but it would be nice if the user got informed that its about to happen
<jondo> Ok. Which timezone is he in?
<jondo> That certainly is https://launchpad.net/~jcrigby?
<ogra_> jondo, right, you also should test with the latest kernel, somehow the kernel team bugbot thinks there is a newer one than you tested
<xranby> infinity: hi i got a report from a user who obviously have namaged to install oneiric on his ac100 and then crippled it by pressing the bug shiny install release button from unity  http://paste.ubuntu.com/705353/
<infinity> xranby: That must be from an old image.
<infinity> xranby: We now correctly clean up, so he'd never get a change to press said button.
<infinity> (As in, it won't exist)
<infinity> s/change/chance/
<xranby> infinity: good.. i told him to go to http://iso.qa.ubuntu.com/ and retest usin ghte image provided there
<infinity> xranby: That should do.  Except that he'll need the bootimg that matches, and iso.qa doesn't link both files.
<xranby> oh my...
<infinity> xranby: http://cdimage.ubuntu.com/daily-preinstalled/current/ is a bit less hassle in that regard.
<infinity> xranby: Code limitation, iso.qa can't list more than one file for an image. :P
<infinity> xranby: Not a big deal for testers, we know what we're doing there.
<infinity> xranby: The actual cdimage release bits have the right info.
<ogra_> well, iso.qa seems to also point to the omap4 wikipage for installation instructions
<ogra_> https://wiki.ubuntu.com/ARM/TEGRA/AC100 might be the best place to point to
<infinity> ogra_: Not sure that it matters deeply.  I doubt that many people will be testing ac100 for us.
<infinity> And we really (REALLY) shouldn't be pointing users to iso.qa as a source for images.
<infinity> cdimage.ubuntu.com is the right place.
<ogra_> well, i point them to iso.qa beliveing that everything is in order there
<ogra_> which it apparently isnt :)
<ogra_> the wikipage has the proper instaructions and links to both files you need
<xranby> ogra_: infinity: i was a bit surprised since this user claims he have followed the instuctions from the wiki
<ogra_> xranby, i only updated the links from beta to the current daily when i was sure the images build properly
<xranby> i sent him a mail to double check that he are using both the latest .tar.gz and bootimg
<ogra_> so beta was linked from there for a few days longer
<ogra_> janimo, how do the mx5 images look ?
 * ogra_ needs to signoff on them fo rthe release team
<hrw> heh... http://marcin.juszkiewicz.com.pl/2006/03/18/openzaurus-354-released/ was nice time - good that I do not have to work on releases anymore
<janimo> ogra_, will ping you back once I test todays. The last ones looked better
<ogra_> k, thanks
<xranby> janimo: when i test the daily mx5 image, i find banshee in the sound menu
<ogra_> yes, thats a bug :(
<ogra_> likely on all images
<ogra_> seems there are dependencies that keep banshee in, juts dropping it from the seeds didnt help
<ogra_> you should have rhythmbox too though
<ndec> ogra_: there is still no RC image? is that correct?
<ogra_> ndec, there wont be an official RC image ... the dailies are RCs
<ndec> ok!
<xranby> ogra_: during oem-setup i only see banshee  no rythmbox  will check if rythmbox are present when i login into deskto
<ogra_> it should be ... but you will likely need to search for it in the dash
<ogra_> as long as banshee is installed it claims all the mediaplayer links and launchers
<ndec> talking about banshee... i just dist-upgraded my system, banshee is still there and rythmbox was not installed.
<ogra_> do you have ubuntu-desktop installed ?
<ogra_> that it doesnt get removed on pre-release images is normal
<ndec> no...
<ndec> now i am wondering why...
<ogra_> we exdpect users of alphas and betas to be able to deal with that
<ndec> i have dist-upgraded since alpha2 or something like that.
<ogra_> but RB should get installed in any case
<ndec> ;-)
<janimo> xranby, I still find the daily mx5 install very slow
<janimo> you said you saw an imporvement
<janimo> almost 10 minutes to the second bootup, and no output about resizing partitions in the first one
<pmatulis> hi everybody, where can i find information on the work done re this blueprint:
<pmatulis> https://blueprints.launchpad.net/ubuntu/+spec/server-o-arm-sysadmin-tools
<ogra_> pmatulis, NCommander leads the server stuff in ubuntu-arm
<ogra_> pmatulis, though i would start talking to the approver or drafter first
<ogra_> looks like cmagina did all the work on it
<xranby> janimo: yes the daily install are still slow
<xranby> janimo: the daily linaro oneiric image are quick in comparision
<xranby> for mx5
<janimo> xranby, which one was fast then? IIRC you said that a few days ago
<ogra_> there finally are linaro oneiric images ?
<janimo> ah, the linaro one. Sure that always was faster
<ogra_> heh, yeah
<janimo> for mx5
<ogra_> they just hardcode the autologin and dont have to run jasper
<ogra_> that makes the first step lots faster
<pmatulis> ogra_: alrighty
<janimo> ogra_, I think in this case it is somehing else. kernel/FS/SDcard setting maybe? Although we use the same kernel imagaes
<ogra_> well, you said you dont see jasper output
<janimo> as our mx5 is much slower than our omap one so it is not just jasper
<ogra_> so there likely also is a jasper bug
<janimo> ogra_, indeed, I did not see any output for over 5 min, board seemed dea
<janimo> d
<xranby> ogra_: janimo: the last linaro oneiric image i testsed was sudo linaro-media-create --rootfs ext4 --mmc /dev/sdc --binary linaro-o-ubuntu-desktop-tar-20111006-1.tar.gz --hwpack hwpack_linaro-lt-mx5_20110929-0_armel_supported.tar.gz --dev mx53loco
<xranby> but it had some issues like metacity crashed
<xranby> apart from that gui was snappy
<xranby> janimo: http://snapshots.linaro.org/oneiric/linaro-o-ubuntu-desktop/
<janimo> xranby, no images yet for today's directory there
<xranby> correct
<xranby> the last image are from 08
<xranby> and hw pack http://snapshots.linaro.org/oneiric/imx51-oneiric/20111008/0/images/hwpack/
<xranby> janimo: my Ubuntu oneiric daily mx5 image did after half an eon complete the oemsetup and i am now viewing the desktop
<janimo> xranby, that's the speed I see too
<xranby> the last part of the oem-setup i was only observing the background image and title bar for about 30min
<janimo> but I get ubiquity restarted at the end
<janimo> I got these with omap images too this cycle
<ogra_> as long as it doesnt happen with todays anymore thats fine :)
<janimo> ogra_, it is with today's unfortunatley
<janimo> I am not sure I ever saw an omap image get past instal lw/o this ubiquity restart either
<janimo> so seeing it on the mx5 is not surprising me
<janimo> need to check if there's a crash log, most times there was not even one
<ogra_> so you are saying you now see that bug that nobody else but GrueMaster could reproduce for weeks =
<ogra_> ?
<ogra_> darn, well, at least you can reproduce it too now :/
<ogra_> even though thats to late for release :(
<brandini> after a week of hacking I finally found the source for MLO
<ogra_> brandini, you could have asked ;)
<brandini> I know, I was too focused on other things
<brandini> I seriously think I was made to be an embedded hacker, I lvoe this stuff!
<ogra_> like spending a week on finding it yourself you mean ? :)
<brandini> I was hacking the pandaboard port for openbsd, cross compiling, etc so I just copied the exising uboot and MLO from linux
<ogra_> ah
<brandini> ogra_: it took a special form of art to make a bootable windows partition :)
<ogra_> heh
<brandini> needs an even number of sectors to overcome some "bug" in mkfs.vfat and even after knowing that it took me a dozen tries to get it right
<janimo> ogra_, I mean I always( almost always) see this, but there are not crash logs o
<janimo> some of the earlier ones had _Crash files
<janimo> those too were seen by gruemaster but fiex d in the meantime
<ogra_> janimo, well, why didnt you speak up when we discussed that, it seemed GrueMaster was the only one seeing it
 * ogra_ didnt have a single non-explainable restart of ubiquity during this cycle
<ogra_> anyway, we should find out why its failing, make sure to file a bug
<brandini> wonder if the eagleboard aims to be a "production" style board
<ogra_> as production style as the panda i guess
<ogra_> i.e. not for commercial use
<brandini> gotcha
 * brandini creates a cluster of arm servers on commodity hardware
<janimo> ogra_, hmm beause I thought everyone sees it and it is part of the current status honestly
<ogra_> nah, it isnt, sadly
<janimo> the only thing that is suspicions - is /var/og/faillog which is 20K of zeros
<janimo> but no oem-config.log nor crash nor installer log have suspicious content
<ogra_> syslog is the intresting one, the rest is usually quite empty anyway
<janimo> also jockey has backtraces but that too must be common for all arms as it looks and fails to find broadcom-wl fglx etc
<ogra_> i havent seen any jockey issues, though apport should be disabled on todays images
<ogra_> so you might not notice crashes in the bg
<janimo> well, they are python backtraces but it carries on so I think they are harmless
<ogra_> well, add them to the bug
<janimo> also faillog is for login attempts, unlikely to be relevant here
<ogra_> usually python backtraces are rather serious in ubiquity
<janimo> ogra_, this is in jockey. ubiquity logs are clean
<ogra_> ah
<janimo> ogra_, after the installer finished should it prompt for reboot or reboots automatically?
<ogra_> it should drop you to lightdm
<janimo> I never get to that step I only see the newly started ubiquity
<ogra_> it doesnt reboot at all
<janimo> hmm, never seen being dropped to lightdm. So it logs out then automatically?
<ogra_> after it removed itself it restarts the display manager ... since ubiquity-dm is gone you land in lightdm
<rOxx> iÂ´m using beagleboard xm with ubuntu 11.04 and kernel 3.0. i have problems with flooding messages in the syslog and kern.log file. the messages look like this: rpm_suspend flags 0x0, rpm_resume flags 0x4, rpm_resume flags 0x5, rpm_resume returns 1. can someone help me with this messages?
<janimo> ogra_, ubiquity-dm is also not removed on this image
<ogra_> janimo, yes, else you wouldnt see the issue ;)
<janimo> :)
<ogra_> janimo,
<ogra_> Oct 10 13:07:30 localhost ubiquity[1108]: log-output -t ubiquity laptop-detect
<ogra_> Oct 10 13:07:38 localhost dbus[404]: [system] Activating service name='org.debian.apt' (using servicehelper)
<ogra_> Oct 10 13:08:03 localhost dbus[404]: [system] Failed to activate service 'org.debian.apt': timed out
<ogra_> that looks suspicious
<ogra_> you have a unch of other AptDaemon messages in there
<ogra_> and there is:
<ogra_> Oct 10 16:20:46 localhost ubiquity: debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by another process: Resource temporarily unavailable
<janimo> that may be from when it already restarted and I tried removing oem-config
<janimo> I am doing a new install now
<ogra_> though that might still be locked from the crashed ubiquity run before
<janimo> right
<janimo> it seemed so
<ogra_> aptdaemon is the bit thats does the uninstall though
<ogra_> there is also one:
<ogra_> Oct 10 16:16:49 localhost ubiquity: dpkg-trigger: error: must be called from a maintainer script (or with a --by-package option)
<ogra_> though not sure that means anything
<janimo> tbh the installer logs are usually very chatty so it is not easy to find the logs for the really harmful event
<janimo> xranby, did you experience boot problems with USB devices inserted? I need to not have  anything plugged in or it won't boot - leds turn off
<janimo> may be a hw issue of my board though
<GrueMaster> Morning all.  Nice to know I am not the only one seeing oem-config respawn.
<xranby> janimo: no. i have usbhub + keyboard + mouse inserted on the mx5 when i tested the ubuntu oneiric mx5 image
<janimo> xranby, ok, my hw may have issues then
<janimo> which may be the root of the other errors too
<janimo> I wonder if my setup has issues, since I see such things on omap
<xranby> http://www.theinquirer.net/inquirer/news/2115929/ubuntu-1110-support-arm-chips-fight-red-hat
<GrueMaster> janimo: As long as you don't use your AC100 PS on your panda/beagle/mx5, you shouldn't have too many problems.  :P
<janimo> GrueMaster, you never forget do you?
<janimo> luckily the mx5 has (hmm does it??) unique jack
<GrueMaster> Well, you know the old addage, "Elephants never forget", right?
<GrueMaster> The mx5 uses the same jack btw.
<janimo> GrueMaster, but this one comes from a different wall socket not from under the table, so I cannot easily mix them up
<janimo> still a weird situation. Maybe both my hub and my external USB drive are just too much for that supply
<GrueMaster> It isn't the wall part that matters.  :P
<GrueMaster> Is your hub and external drive self-powered?
<GrueMaster> Or do they draw from the mx5?
<janimo> both draw from mx5
<janimo> I may need to check another hub which has its own supply
<GrueMaster> Yea, that would be bad.
 * GrueMaster wanders over to the coffee pot to fullfill his daily quota.
<jcrigby> jondo, bug #871650 reminds me of onw GrueMaster reported a while ago and I don't thing we ever resolved.  Looking for old bug...
<ubot2> Launchpad bug 871650 in linux ""unable to enumerate USB device" with BeagleBoard-xM" [High,Confirmed] https://launchpad.net/bugs/871650
<GrueMaster> jcrigby: The bug you are looking for is 838200
<ogra_> bug 838200
<ubot2> Launchpad bug 838200 in u-boot-linaro "No network support on Beagle XM" [High,New] https://launchpad.net/bugs/838200
<GrueMaster> sigh.  bug 838200
<ogra_> hehe, i was faster !
<jcrigby> GrueMaster, ogra_ you are both faster than me! I was still looking
<ogra_> i just reformatted GrueMaster's thought :) i'm not actually that fast
<ogra_> or better: LP isnt ... :P
<GrueMaster> But I don't think they are the same, as jondo (and others over the weekend) have been reporting no USB at all.  My system has everything enabled, but to get networking to work, I have to unplug the network cable for a fe seconds then plug it in.
<jcrigby> GrueMaster, yes you are right the old bug has usb working but not network
<GrueMaster> They could be related to the same code.
<GrueMaster> As they are different rev boards.
<GrueMaster> And rev C has some different power scenarios for USB.
<ogra_> well, it smells like u-boot or MLO to me ... but i might be totally wrong and its the kernel
<GrueMaster> (I have rev B).
<GrueMaster> I have found that if I use the Natty MLO/U-boot, I get consisten networking.  With Oneiric, spotty at best.
<jcrigby> ogra_, could be however I believe latest linaro images work fine but maybe not on xm rev c
<GrueMaster> jcrigby: linaro boot systems use a master boot partition.  Does it ever get updated with the latest u-boot?
<jcrigby> GrueMaster, you mean the test systems?
<GrueMaster> yes.
<jcrigby> not sure how often they get updated but you are right it is not with every build because if they did they could get bricked with a bad u-boot build and then a human would have to go replace the sd cards to fix them
<rsalveti> this bug is so annoying
<GrueMaster> Hence the flaw in the design I mentioned a while ago.
<rsalveti> do we have any newer xM than C?
<rsalveti> in theory both kernel and u-boot are handling it correctly
<GrueMaster> I don't think there is one.  Not according to beagleboard.org at least.
<rsalveti> GrueMaster: yours is even more interesting, just eth0 not working
<rsalveti> what doesn't make any sense to me
<GrueMaster> It is only the link detection circuit that isn't working.
<GrueMaster> The port enumerates fine.
<jcrigby> possibly nothing to do with this but I found that when switching to the u-boot based MLO on panda the external USB/ethernet phy stopped working until I did the right thing in u-boot
<rsalveti> that's the interesting thing, it's all the same chip
<jcrigby> the right thing being setup its clock before powering it on
<rsalveti> jcrigby: yeah, but I believe this was basically because u-boot wasn't in sync with x-loader
<jcrigby> yes, exactly
<GrueMaster> rsalveti: It may be the same chip, but I think the code paths are different.
<GrueMaster> Otherwise I would be able to get networking working in u-boot, right?
<jcrigby> rsalveti, what I am thinking is that this external phy seems to be touchy about its init sequence
<rsalveti> jcrigby: could be
<jcrigby> rsalveti, was the the xm that switched the polarity of the reset and the switched back?
<rsalveti> GrueMaster: yup, but don't know if it's currently working the same way as panda
<rsalveti> jcrigby: iirc, yes
<rsalveti> that was the rev C thing
<GrueMaster> rsalveti: It isn't.  At least not on my end.
<rsalveti> jcrigby: I remember we had a bug for rev C support at u-boot a while ago
<rsalveti> let me check
<brandini> ok, now for some fun
<brandini> mount an nfs share with all my DVD's on it and play them!
<brandini> should I be using gdm or something else?
<GrueMaster> Go brandini, go!
<brandini> Yay!
<rsalveti> jcrigby: bug 770679
<ubot2> Launchpad bug 770679 in linux "Missing proper support for Beagle XM rev B and C" [Medium,Fix released] https://launchpad.net/bugs/770679
<GrueMaster> rsalveti: iirc, when we launched Natty, you made a special u-boot & kernel that only updated the board ID table for Rev C.
<rsalveti> GrueMaster: yup, this was the bug that fixed the support at the kernel side
<brandini> heh, wonder if that's why uboot didn't boot my bsd kernel
<rsalveti> jcrigby: http://patchwork.ozlabs.org/patch/92334/ need to check the default path when an unkown rev is identified
<brandini> wait, does ubuntu arm support nfs?
<GrueMaster> brandini: Yes.  I have it running here on my system I used for builds.
<brandini> ahh ok
<GrueMaster> And I have tested nfs-root as well.
<GrueMaster> NFS-Root is much faster than SD.
<brandini> knowmercy@localhost:~$ sudo mount -t nfs 10.15.32.103:/storepool /media
<brandini> mount: wrong fs type, bad option, bad superblock on 10.15.32.103:/storepool,
<brandini> :(
<rsalveti> jcrigby: in theory the kernel for both oneiric and linaro are right
<rsalveti> beagle_config.usb_pwr_level = GPIOF_OUT_INIT_HIGH; for xM only
<GrueMaster> brandini: For grins, try rebooting.
<brandini> GrueMaster: the panda?
<rsalveti> ops, for A/B only, not C
<GrueMaster> brandini: yes.
<brandini> ok
<brandini> GrueMaster: what display manager works best?
<GrueMaster> I have seen an issue where networking gets confued.
<GrueMaster> Display manager?  We ship with lightdm.
<GrueMaster> *confused
<brandini> GrueMaster: do I need mount.nfs?
<GrueMaster> No, mount should just work.
<brandini> seems I do
<brandini> nfs common?
<brandini> aha!
<brandini> that worked
<jcrigby> rsalveti, ok.  One other thing perhaps again no relevant.  I noticed when merging ubuntu sauce that the upstreamed beagle changes were a little different than the ubuntu sauce from you and robert
<brandini> now to get a display manager runnin on server
<brandini> GrueMaster: should I be using mplayer to play these movies?
<brandini> or are there better things?
<rsalveti> jcrigby: hm, u-boot also seems fine
<rsalveti> default is basically rev C
<janimo> ogra_, ah one reason I probably  newver saw the lightm greeter is that when installing I always set autologin on
<jcrigby> rsalveti, yes just noticed that also
<GrueMaster> brandini: I really don't know.  iirc, you want to use something that uses the g-streamer hardware accelerated drivers.
<GrueMaster> janimo: Um, yea.  That would do it.
<janimo> now I am trying an install without autologin
<janimo> let's see if anything is different
 * janimo wonders what the heck is the netsurf web browser and why is it prominently featured in the StarApps section of the installer slideshow
<GrueMaster> brandini: Figured it out.  sudo apt-get -y install nfs-common.  Then you can mount nfs drives.
<rsalveti> jcrigby: but I didn't see any specific changes at u-boot for rev c
<rsalveti> so it seems the kernel or MLO is responsible for setting it up correctly atm
<jcrigby> Do we have any rev C beagles in Linaro?
<rsalveti> jcrigby: not sure, need to check the hw spreadsheet
<jcrigby> I will
<jcrigby> rsalveti, good news mattwaddel has a rev C
<rsalveti> jcrigby: oh, even better
<jcrigby> I am going to swap my B for his C and then I can try some stuff
<janimo> GrueMaster, although once the board is booted up, said peripherals work without external power supply
<janimo> so I still think there's something the kernel could do better
<GrueMaster> possibly., but you could also be very close to hitting the limits of USB.
<brandini> GrueMaster: yeah, I did the nfs common and that did the trick!
<GrueMaster> brandini: Cool.
<brandini> so g-streamer eh?
<brandini> and gdm
<GrueMaster> brandini: What is your end goal?
<brandini> to have X running so I can play movies outputting them on my TV :)
<GrueMaster> You might try mythtv or one of those types of front-ends.
<brandini> :)
<brandini> but my point right now is that I don't have X running since I'm running 11.10 server
<GrueMaster> Ah.
<GrueMaster> I haven't tested anything to that level this cycle.  I would suggest experimenting.  Of course, it helps to have the accelereated bits, which should be in the ppa already, if not very soon.
<infinity> janimo: Grr.  I'm trying to artificially reproduce your oem-config-remove-gtk-not-starting bug, and my Panda is failing to misbehave.
<GrueMaster> What mechanism does it use to launch oem-config-remove-gtk?  If it is sending out a dbus call then exiting, X is probably dying before oem-config-gtak-remove has a chance to start.
<GrueMaster> Not sure why dbus is being used to launch apps anyways.
<GrueMaster> Just feels wrong.
<ogra_> dbus is used internally by aptdaemon
<ogra_> not to call aptdaemon from ubiquity
<ogra_> and launching bits through dbus enables privilege control through polkit
<ogra_> so it has security advantages
<janimo> infinity, this is on mx5 though
<infinity> janimo: Yeah, I know.
<infinity> janimo: Maybe if I boot nosmp to make my machine even slower. :P
<Neko> why would oem-config-gtk-remove rely on X in the first place?
<Neko> if oem-config needs to uninstall a component of itself it had better do it while ubiquity isn't running, right? don't they share things?
<stephen__> hi, any news on 1080p packages for pandaboard running oneric. Did this ever get done for Naty?
<stephen__> ?
<brandini> crickets
<rsalveti> stephen__: nops, was never done for natty
<rsalveti> we're all waiting ti to publish the newer packages
<BlInK311> GrueMaster
<BlInK311> u on?
<GrueMaster> sup?
<BlInK311> the other day you told me to put 'discard' into /etc/fstab.    before the first boot?
<GrueMaster> Yea, forget that.  Doesn't work well with SD.
<BlInK311> do you know another way to get past the start up config?
<GrueMaster> After the first run through, hit <ctrl><alt><F1>, log in as the user you created, and type "sudo oem-config-remove", then reboot.
<BlInK311> ok, ill give that a try
<twb`> IME -o discard doesn't work at all on SD, and the kernel simply reports "discard not supported, disabling" the first time it tries to GC blocks
<twb`> So AFAICT it's harmless to turn on
<GrueMaster> twb`: I actually saw a performance hit with it enabled, but it also allowed me to get through oem-config.  Not sure what is going on yet.
<twb`> Hu
<twb`> What kernel
<GrueMaster> 3.0.0-1205.10
<twb`> What *I* would be doing is adding force-unsafe-io to dpkg.cfg, fwiw
<broo> while not quite an ubuntu question, I was wondering if anyone had experienced issues using FlexNVM in eeprom mode on the Cortex-M4 (freescale k60 family), I keep seeing resets when trying to initialize the partitions
#ubuntu-arm 2011-10-11
<ppisati> anyone with a beagle xm rev.c willing to do a test, please contact me
<ogra_> xranby, thanks for taking over
 * ogra_ hugs xranby 
<xranby> youre welcome
<ndec> ogra_: what do you think of bug 872178
<ubot2> Launchpad bug 872178 in jasper-initramfs "ROOTDEV export not working" [Undecided,New] https://launchpad.net/bugs/872178
<ogra_> ndec, hmm, it is used in all other installs
<ogra_> do you avoid _growroot with some hack or so ?
<ndec> ogra_: i asked XavB to join, as he is the one that knows this stuff..
<ndec> XavB: (2:54:37 PM) ogra_: do you avoid _growroot with some hack or so ?
<ogra_> XavB, it works on all other installs, so there must be something special in the way you use jasper
<XavB> ogra_: not sure if other are using mmcblk1
<XavB> ogra_: as soon as you ar eusing mmcblk0, no issue, because a default value is set.
<ogra_> hmm, i thought we added a way to override that...
<ogra_> let me take a look at the code, one sec
<XavB> if you add trace to jasper_setup, you will see that the export form ROOTDEV is not seen into jasper_setup
<ogra_> did you try setting root= on the cmdline ?
<XavB> ogra_: in fact I reviewed the code and it seems OK, the only problem is the export from _growroot that is not visible into _setup
<XavB> ogra_: yes I have root=/dev/mmcblk1p2
<ogra_> well, export exports to the full environment, you should see it unless its actually unset
<ogra_> hmm, that should actually pick up the right bits then
<XavB> The _growroot part is working fine, ROOTDEV is computed correctly, the resize of mmcblk1p2 is OK
<XavB> but then the UUID is computed on mmcblk0p2 and after the reboot we are using FS on eMMC not SD
<ogra_> well, i dont see why the export wouldnt work, it is the same shell
<XavB> ogra_: adding traces demonstrate that the export don't work, I promise...
<ogra_> infinity, any idea why an export from one initrd script to another wouldnt work ? even though they should be inside the same environment
<janimo> ogra_, so mx5 install actually works if I do not tick automatic login
<janimo> just takes very very long
<janimo> the packages are removed, adn you get into lightdm
<janimo> but only 15 minutes after the ubiquity GUI disappears
<janimo> ogra_, re the ROOTDEV bug, I saw jasper setup script (?) set rootdev explicitly in case it is not set in growroot
<janimo> which seemed one of the weird places in the code as growroot has exports
<janimo> but they may be run from different shell sessions so the exports do not carry over
<brandini> janimo: how do you install lightdm
<janimo> brandini, it is on the image by default
<brandini> how did you enable it?
<brandini> start lightdm?
<ndec> brandini: it's supposed to be enabled by default.
<ndec> what's the problem?
<ogra_> janimo, thats just a fallback, growroot should actually have exported the right thing
<brandini> I don't have any X running on my machine
<janimo> ogra_, well the fact there is a fallback shows the export does not always work
<brandini> I plug in my TV to the hdmi out and all I see is the login prompt
<ndec> brandini: is it intentional?
<janimo> so we should either see why it does not work, or just set it anew in setup
<brandini> ndec: I'm running 11.10 server so I dunno
<janimo> of course not for O :)
<ndec> brandini: what do you call login prompt with no X?
<ndec> ah... on the console
<brandini> yup
<ogra_> janimo, i just added it to make sure we succeed in any case even if the user adds soemthing weirtd to root=
<ndec> i didn't use the server image. is ubuntu-desktop package available?
 * brandini looks
<brandini> ndec: you're right :)
<brandini> 565MB
<ogra_> well, better use the task than the metapackage
<ogra_> apt-get install ubuntu-desktp^
<ogra_> *desktop
<brandini> :)
<ogra_> (note the caret, its important)
<brandini> too late?
<infinity> ogra_: export exports to children, it can't export "up" to the parent.
<ogra_> argh !
<ogra_> damned
<ogra_> i thought it exports on the same level
<ogra_> not sure what made me think that
<infinity> ogra_: If it was exported by the parent, then children can change it.  But children can't export to the parent.
<ogra_> right
<ogra_> so i need a tmpfile or some such
<ogra_> to put the value in and make the second script read it
<infinity> ogra_: What are you mangling?
<ogra_> how ugly
<ogra_> Bug 872178
<ubot2> Launchpad bug 872178 in jasper-initramfs "ROOTDEV export not working" [Undecided,New] https://launchpad.net/bugs/872178
<ogra_> infinity, ^^^
<ogra_> TI has probs with a blaze install
<infinity> Don't we use more or less the same detection routine twice?
<ogra_> no
<ogra_> only once
<infinity> Or is it just hardcoded in _setup?
<ogra_> it is hardcoded to a fallback of mmcblk0
<infinity> Ahh.
<ogra_> if the export doesnt get through
<ogra_> which doesnt harm us on any installs atm
<ogra_> since all our images use mmcblk0 ... the blaze cant
<infinity> Well, you could do this two ways.  You could find it in growroot and write a tempfile, or you could break the detection out into a utility that you install to /bin
<ogra_> well, i could also add it to initramfs-tools, the value i set in a child should persist for the other child then, no ?
<ogra_> though it feels very wrong to add jasper vars there
<infinity> If you export ROOTDEV= in init, then it would persist.
<infinity> But that seems silly.
<ogra_> no, i mean if i set ROOTDEV to a value in growroot, that should get handed over to _setup
<ogra_> if the var is owned by init
<infinity> Yeah.
<infinity> That's what I meant.
<ogra_> k
<infinity> See the list of exports in init.
<ogra_> well, not the solution for now though
<ogra_> (and actually a bit to late for a solution in general i think)
<ndec> ogra_: why exactly do we have to hardcode mmbblk0 in initramfs?
<infinity> Yeah, I'm not sure this is something we should care about for release.
<ogra_> ndec, its a fallback value
<infinity> ndec: We don't have to, and shouldn't, it's a bug IMO.  But not an RC one, given that the images all work as designed on their respective targets.
<ndec> sure.
<ogra_> it gets only used if the first script doesnt hand the info to the second (which sadly seems to be a default)
<infinity> But yes, the ROOTDEV stuff is all broken/wrong, IMO.
<ndec> what do we do in the non fallback solution?
<ogra_> hack jasper :(
<ogra_> xranby, was it you who filed that gconf bug where gconf looks in the wrong path ?
 * ogra_ needs the bug #
<ThersiT> I've got a usb to serial adapter I'm trying to use to get to an Arcturus module. For the life of me I can't get minicom to connect to my module. However if I run WinXP in a virtualbox I can get Putty to connect. Have any of seen this before?
<GrueMaster> Why use minicom?  Use screen, much easier.  screen /dev/ttyUSB0 115200
<ThersiT> Screen won't work either. The adapter is being recognized. Here is my dmesg output. [ 5880.414017] usb 5-1: generic converter now attached to ttyUSB0
<GrueMaster> ok.  What does screen output when launched?
<ThersiT> Screen gives me nothing but a flashing cursor. I'm in the dialout group too.
<ThersiT> Used the same cmd you just posted.
<GrueMaster> What speed settings do you use in Putty?  Any other comm settings?
<ThersiT> 115200 8N1 no flow control.
<ThersiT> I've been all over the web, I'm really at a lost here.
<GrueMaster> Very interesting.  I am using the same settings on 8 different USB serial cables here with no problem.
<GrueMaster> Try sudo screen /dev/ttyUSB0 115200.  Also, try unplugging the usb cable from your host and re-plugging it in and checking dmesg to verify it is ttyUSB0.
<ThersiT> Ahh, sudo gives me an error in screen "ioctl failed"
<ThersiT> "Interrupted system call"
<ThersiT> Is that any help?
<GrueMaster> Very interesting.
<GrueMaster> Anything in dmesg?
<ThersiT> Negative.
<ThersiT> Also I've tried this in 10.04, 11.04, and Backtrack 5.
<GrueMaster> This is very odd.  My desktop is 10.04, and I have a dedicated serial console (serial-killer) running 11.04, neither have had these issues.
<GrueMaster> Make sure your usb device isn't being taken over by the VM.
<ThersiT> Yea, It's really kicking my butt. VM has'nt been open since a reboot.
<ThersiT> I modprobed the adapter myself after boot.
<GrueMaster> So dmesg does show the ttyUSB device?
<ThersiT> Yup. ttyUSB0
<GrueMaster> What does "sudo lsof ./dev/ttyUSB0" show?  May be modem-manager getting in the way.
<ThersiT> It's 660. Owned by root:dialout. Letme look.
<ogra_> nromally ubuntu users are in the dialout group by default
<GrueMaster> I don't think it is a permissions issue.  I think some other app is taking control of the device in the background.
<ThersiT> sudo lsof /dev/ttyUSB0
<ThersiT> lsof: WARNING: can't stat() fuse.gvfs-fuse-daemon file system /home/wstraus/.gvfs
<ThersiT>       Output information may be incomplete.
<GrueMaster> lsof should show who/what has the device open
<GrueMaster> Ignore the gvfs stuff.
<ThersiT> How do you quit screen?
<GrueMaster> <ctrl>-a k
<ThersiT> I had a bunch of screen's open, they were listed in lsof and I killed the pids.
<ThersiT> But after killing all of those nothing gets listed from lsof
<GrueMaster> ok, that is a good thing.  Now try launching screen again.
<ThersiT> sudo?
<obarthelemy> Hi... sorry, dumb question... what are the user+root accounts and pwd for oneiric-core-armel ?
<GrueMaster> You may have to do something on your test system as well to get any output (like reset).
<GrueMaster> obarthelemy: There is no passwd.  You should be able to use it as a chroot environment w/o problem.
<ogra_> obarthelemy, -core is for building your own images, its just enough OS to run apt, nothing more, no user or configuration
<ThersiT> Just rebooted the module with screen running, got nothing.
<ThersiT> I should see it booting then a login prompt.
<ThersiT> let me try sudo screen.
<ThersiT> Nothing using sudo either.
<obarthelemy> I know core is very bare, that' what i want... I'm stuck at the login prompt though, root/blank don't work, blank/blank neither, tried temppwd which was the correct pwd for the minimal-omap rootfs, no luck either
<ogra_> right, as i said, no users, no passwd, no config
<ogra_> you would have to create a rootpw before booting the rootfs
<obarthelemy> ok, ill dot hat then, thanks
<ThersiT> Do you guys know a good adapter that works well with linux? I can go buy a new one.
<gildean> i remember reading about the same problem somewhere
<GrueMaster> ThersiT: All of mine are TrendNet USB Serial.
<GrueMaster> Essentially anything with a pl2303 converter chip should work well.
<GrueMaster> What does dmesg say your USB cable has for a converter?
<gildean> hmm, here it was, don't know if this is any help: http://www.trimslice.com/forum/viewtopic.php?f=52&t=335
 * ogra_ never checked, i'm just buying them as i lose them
<ogra_> and never had one that didnt work
<ThersiT> GrueMaster: cool I'll go looking. dmesg says "usbserial_generic 5-1:1.0: generic converter detected" but it's a TIUSB3410
<ThersiT> gildean: I'm looking at that now.
<ThersiT> Thanks guys. I'm just gonna try a new one.
<GrueMaster> ThersiT: Make sure you do a little research before you just buy one.  You should be able to google the specs easily enough.
<ThersiT> Yea, I'm gonna try to find one with that PL2303 chipset.
<prpplague> or has an ftdi chipset
<prpplague> both are reasonably stable
 * GrueMaster has had excellent luck with the TrendNet brand, and a few others that have the pl2303 in them.
<GrueMaster> One of my cables is actually a 4 serial port hydra cable.  1 USB<>4 Serial heads.  Other than enumerating, it works very well.
<GrueMaster> But I doubt a lot of people are using multiple usb-serial adapters on a single system to control 8+ arm systems.
<ThersiT> I read in that forum gildean showed me to short pins 2 and 3 to make a loop back and that failed. I think this adapter in just not linux friendly.
<GrueMaster> Highly possible.  I also found a bunch of issue reports when I googled for TIUSB3410 Linux.
<GrueMaster> To be fair, there "may" be a module that just isn't being loaded for some reason.
<GrueMaster> But I doubt that is the issue.
<ThersiT> I did have to add a udev rule to load usbserial.
<GrueMaster> ThersiT: Check lsmod to see if ti-usb-3410* is loaded.
<ThersiT> Tried lsusb | grep ti and got nothing relevant.
<GrueMaster> Then try "sudo modprobe ti_usb_3410_5052".
<ThersiT> tried it, no change. what is the 5052?
<ThersiT> lsmod says ti_usb is using ttyUSB0 tho.
<GrueMaster> Ok, different kernel, different module.
<ThersiT> I'm on Ubuntu Desktop 10.04 2.6.32-34-generic
<GrueMaster> Interesting, I'm on the same kernel.
<GrueMaster> Well, -pae.
<ThersiT> Yup, been messing with it for a few days. Installed that WinXP vbox last night and hated every minute of it. heh
<ThersiT> On a side note I'm new to these modules. Is uClinux the way to go?
<GrueMaster> No idea.  Never worked with that.
<ogra_> does uClinux still exist ?
<ogra_> i thought that died long ago
<ThersiT> Oh, that would suck. This Arcturus module was bought about 2 years ago and uClinux is what came on it.
<ThersiT> What do you guys use?
<ogra_> well, you are in #ubuntu-arm
<ogra_> so make a guess ;)
<ThersiT> Ah heh heh, yup I should have thought of that.
<martyn> How can I get a PPA compiled on the ARM farm?
<martyn> ( Specifically : http://nginx.org/packages/ubuntu/dists/lucid/nginx/ )
<martyn> compiled in Oneieric
<GrueMaster> martyn: Not sure, but I believe heavy bribing with beer may be involved.  :P
<GrueMaster> Seriously, I wouldn't know.
<GrueMaster> I can pull it locally and see if it builds on one of my pandas if that is what you are looking for.
<GrueMaster> martyn: We already have nginx in the pool (universe).  I'm sure it will get resync'd and rebuilt after next week.
<martyn> GrueMaster: That would be helpful
<martyn> GrueMaster: My buildd is down, having been "borrowed" for a corporate demo
<martyn> cool
<martyn> So it's migrated from PPA to universe?
<GrueMaster> Yes, but it is at 1.05-1.  Building 1.08 for you now.  Shouldn't take too long.
<GrueMaster> btw:  Are you coming to UDS-Orlando?
#ubuntu-arm 2011-10-12
<brendand> anyone else got a problem with the oneiric final image on panda, where the horizontal alignment is way off?
<brendand> well, it's more like it's horizontally squashed
<infinity> Not here...
<infinity> Though I haven't tested today's spin (about to), I don't see how it would be different from yesterday's.
<ogra_> infinity, hmm, frambuffer changes ?
<ogra_> *frame
<ogra_> (no idea how they could influence us, but werent there some in the initrd ?)
<brendand> infinity - also once i get to lightdm it seems to kill the display
<brendand> i just got the image this morning
<infinity> I'm testing right now.
<brendand> could just be my stupid monitor. i've had issues with it in the past
<infinity> Well, sure, if you keep calling it stupid, I can see how that would cause issues in your relationship.
<infinity> Try being less of a jerk to your monitor? :)
<ndec> panda and monitors have always had difficult relationship as well..
<ogra_> yeah, i suggested for the first release already that TI should just ship the pandas with a monitor
<ogra_> but they never listen to me :(
<brendand> perhaps it's having its revenge
<xranby> ogra_: i tried to install the omap extras package onmy panda today.. and .. poof no xorg
<ogra_> xranby, hmm
<xranby> so the good news are that something are available in the ppa now
<ogra_> right, i guess we need to talk to rsalveti about that
<ogra_> the sgx packages come from linaro ... they have been tested there, probably some incompatibility with our kernel or so
<xranby> i will download the latest oneiric panda image and retry
<xranby> the image i used are some days old
<ndec> ogra_: the sgx don't come from linaro...
<ndec> but from TI
<infinity> Indeed, it's all ndec's fault.
<ndec> xranby: how exactly did you install the omap extra?
<xranby> ndec: clicked on the nice shiny button
<xranby> in the unity launcher
<ndec> only that?
<xranby> it opened the software center
<xranby> and then i clicked on install
<xranby> and it said it was done
<ndec> that should not install anything since our meta package is empty.
<infinity> ^
<xranby> it did install something on my board :P
<ndec> so if that install nothing, that can't break anything ;-)
<xranby> ok i will retest using the latest unadulterated oneiric image
<ndec> i guess it installed ubuntu-omap4-extras, right?
<infinity> It should just install an empty package.
<infinity> ndec: Yeah.
<ndec> xranby: check the version of the package, it should be 1.1~1
<infinity> He may have done this with an older image that still referenced the natty ppa.
<infinity> Before I fixed that. :P
<ndec> xranby: can you share the output of apt-cache policy
<ndec> infinity: that's what i guesed ;-)
<ndec> guessed
<xranby> ndec: just a second
<xranby> ndec: http://paste.ubuntu.com/706596/
<ogra_> yep, all natty
<xranby> ogra_: false alarm then, im fetching a new image
<ogra_> heh
<brandini> morning
<jeremiah_> So I've got an Ubuntu root file system for my OMAP 3 beagleboard
<jeremiah_> But it won't boot on a new disk because in the boot.scr there is a UID that appears incorrect
<jeremiah_> Is there a way to fix that?
<ndec> jeremiah_: update your boot.scr?
<jeremiah_> ndec: I tried to do that by hand but it doesn't seem to have any effect
<jeremiah_> Is there a way that is used by others?
<ndec> jeremiah_: what do you mean by hand?
<ndec> the boot.scr is generated with mkimage.
<jeremiah_> I edited the boot.scr in emacs
<ndec> e.g. mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n "Ubuntu" -d ./boot.cmd ./boot.scr
<ndec> from http://elinux.org/BeagleBoardUbuntu#Beagle_Bx.2FCx_.26_xM
<jeremiah_> Thanks ndec! I'll go read that URL
<ndec> if you use a UUID you will need to use an initramfs, where the init will read the UUID and find the actual device to mount
<ndec> so if you know the actual root device, you can use it in root= instead of UUID.
<jeremiah_> ndec: I thought the device I needed to specify was something like /dev/mmblk0
<jeremiah_> but that doesn't seem to work. :(
<ndec> /dev/mmcblk0p2 likely
<brandini> I was reading through the docs last night and it almost seemed like I could format my usb thumb drive like I did the sd card and make it boot of teh usb drive
<jeremiah_> Ah, of cou!
<jeremiah_> rse
<ndec> brandini: you cannot 'boot' from the usb drive, but you can boot from SD (mlo, uboot, uimage) and have the root fs on USB driver
<brandini> ndec: the docs say first is usb, then mmc
<ndec> brandini: ok... well you can boot from USB yes, but that's using a special protocol with the OMAP rom code. it's for OTG, not HOST. it's used for example for when you connect your phone to flash it...
<brandini> ahhhh ok
<brandini> so even if I put MLO and uboot on a thumb drive it won't boot properly from that?
<ndec> brandini: no. it won't
<ndec> you can do this http://omappedia.org/wiki/Ubuntu_on_OMAP_FAQ#I_want_to_install_Ubuntu_on_external_USB_hard_disk_instead_of_sluggish_SD_card
<ndec> to put root fs on USB driver
<ndec> drive
<brandini> interesting
<brandini> leave it to me to actually read the docs and get more confused :)
<ndec> brandini: reading the docs is great , no confusion!
<brandini> I didn't understand that there was a difference between the first boot device and the second
<brandini> in how it tried to initiate the boot sequence
<brandini> I thought no matter what the device was it would look for MLO, then uboot
<ndec> brandini: the difference in 1st vs 2nd boot is not in mlo/uboot, that part never changes.
<ndec> on 1st boot the initramfs will enlarge the partition and launch the installer. it will generate /etc/flash-kernel.conf
<ndec> on further boots, the initramfs will directly mount the root fs
<brandini> http://pandaboard.org/sites/default/files/board_reference/A1/Panda_Board_Spec_DOC-21010_REV0_6.pdf
<brandini> so on page 21 where it talks about SYSBOOT
<brandini> that's where I was reading that
<brandini> the default is 000101 which says USB, MMC1
<ndec> brandini: and as i told you USB here does not mean what you were hoping. if you look at the OMAP4 TRM docs, there is a chapter on 'booting'
<brandini> ok
<brandini> I'm not saying I don't believe, just showing you how I got confused
<ndec> sure. i know this doc.
<brandini> I pulled down rev X of that last night... 5500 pages or something :)
<ndec> and it's just the public version ;-)
<brandini> lol
<brandini> right
<brandini> and there is a pretty extensive errata doc too
<brandini> ndec: so I found the assembly source for booting the beagle on openbsd, it doesn't seem similar enough to actually boot the panda
<ndec> i guess so
<brandini> you guess so?
<ndec> omap3 vs omap4? a8 vs a9 smp...
<brandini> yeah
<brandini> that's why I'm trying to read this TRM
<brandini> wonder if looking at the ubuntu version is a good start
<rOxx> hello, someone here who can help me with industrial i/o driver ?
<brandini> ndec: I found some interesting stuff after reading 27.4.5.3 in the public doc :)
<ndec> what's 27.4.5.3 exactly?
<brandini> it explains what you were trying to tell me earlier about the booting of usb
<ndec> ah!
<brandini> s/trying to tell/telling/g
<ndec> i am hoping i wasn't too far from the reality ;-)
<brandini> you weren't at all
<brandini> this is fun, I wonder how far I can go with this
<GrueMaster> brandini: On the omap4 usbboot, we are using that (or soon will be) in our panda build cluster.  I already use it in my test setup.  Really usefull for booting and clobbering SD image hands free.
<ndec> brandini: usbboot is indeed using the actual USB boot mechanism. (this refers to our discussion earlier)
<brandini> :)
<brandini> I want a panda build cluster!
<diwic> <mkbosmans> is it always valid to cast a uint8 pointer to a uint32 pointer, even if the pointer is not 4-byte aligned?
<diwic> anybody knows if the answer is "yes" on arm as well?
<R_Nev> the kernel will trap and handle the unaligned accesses
<R_Nev> by default, most likely, but it's going to be slow and i think it's possible to disable the fixup so that the app crashes instead
<R_Nev> unaligned neon accesses may infinite loop instead
<j4r00tn> hey guys where can I find a list of jaunty armel packages
<rcn-ee> j4r00tn, they got removed when jaunty went eof.. for x86 there's an old repo, but i don't there's one of those for ports..
<rcn-ee> j4r00tn, are you using an armv5 device?
#ubuntu-arm 2011-10-13
<brandini> https://twitter.com/#!/packetslave/status/124270413927809024
<j4r00tn> im using a tegra
<phh> why do you want jaunty oO
<j4r00tn> hacked my atrix and if I update I can't use webtop
<j4r00tn> I already acquired all the old repos but I just want the exact packages to that I wont waste space on my phone.
<j4r00tn> I only did a 6gb partition for linux
<phh> only .32 on atrix ?
<phh> anyway you can still use a recent ubuntu
<phh> just need to put the L4T in a chroot
<GrueMaster> We have an image this cycle for the Tegra2 based Toshiba AC100.  Runs quite well.
<j4r00tn> where can I get the image?
<GrueMaster> You can also use the ubuntu-core image as a base.
<GrueMaster> They are currently on cdimage.ubuntu.com
<GrueMaster> Should be posted tomorrow on ubuntu.com official site.
<phh> "this cycle" ?
<GrueMaster> 11.10 release.
<phh> ah ok
<phh> that assumes a .38 kernel
<phh> can't work for j4r00tn
<j4r00tn> where can I get the image??
<GrueMaster> Well, the core image doesn't assume any kernel.  Just Armv7 support.
<phh> it assumes fbdev
<phh> i'm not even sure j4r00tn has that
<GrueMaster> j4r00tn: The images are on http://cdimage.ubuntu.com.  For Ubuntu Desktop, go to daily-preinstalled.
<twb> Does canonical plan to make arm a first-class arch?
<j4r00tn> prowsing now
<phh> as far as i can tell it already is
<twb> Hum
<twb> Then why are the repos on ports.ubuntu.com or whatever it is
<j4r00tn> i think the tegra image should work
<GrueMaster> Well, we are trying.  As soon as more devices are out there that make sense, we probably will.  Right now, most of the consumer available systems are either closed tablets or development platforms.
<phh> j4r00tn: if you're on .32, it won't
<twb> GrueMaster: fair enough, just curious
<j4r00tn> is there an application that converts normal packages to be compatible with armel
<phh> j4r00tn: nonsense
<twb> I guess I'm used to "first-class" as meaning "release critical bugs in this arch, will prevent a release" -- which doesn't make sense in ubuntu land, due to time-based releases
<GrueMaster> j4r00tn: define "normal"?  All of our packages (with a few exceptions) are built for all arches.
<j4r00tn> packages that are not armel compatible
<twb> GrueMaster: *all* arches?  Even m68k? ;-)
<j4r00tn> i tried a few but they dont seem to run
<GrueMaster> twb: I just finished testing the release candidate images for the third time this week.
<GrueMaster> twb: All Ubuntu supported arches.
<twb> Don't mind me, I'm just rambling
<GrueMaster> j4r00tn: If you are running a jaunty environment with only armv5 support, you will run into problems.
<GrueMaster> Even though the processor can handle the armv7 code, without the kernel support, you're hosed.
<GrueMaster> Kind of like trying to run x86_64 code on a system running an i386 kernel.
<j4r00tn> so what's the best way to avoid having this issue? should i update the kernel? I'm having second thoughts coz the webtop environment might stop working again
<phh> well i doubt you're the first guy trying to ask an atrix
<phh> ask them.
<GrueMaster> On the Atrix?  I'm not too familiar with that system.
<j4r00tn> it's the mobile phone by motorola with a tegra 2 processor and 1gb ram it runs android on one side and a locked down version of ubuntu when plugged in a dock
<GrueMaster> I know what it is, I just have no hands-on experience with them.
<j4r00tn> sorry my bad...
<GrueMaster> I had heard they were running a form of Ubuntu, but never experienced it.  Also, nVidia was supposed to update their Linux4Tegra to something more recent (L4T is currently Jaunty based).  I have a dev board that I got that came with a Lucid based environment, but it is very specific to this board.
<GrueMaster> And the AC100 is another beast entirely.
<twb> linux4tegra as in the GPU driver or as in their big blob that is old and crap, apart from happening to contain the GPU driver? :P
<phh> twb: old blob
<GrueMaster> The sad part about Arm SOC systems is that once the bits leave the SOC, all similarities end, even on systems utilizing the same SOC.
<twb> Bugger that for a game of soldiers
<j4r00tn> yup it's jaunty that why I sourced the old jaunty repo to do updates and stuff
<j4r00tn> so will it be pointless if I update to another version other than jaunty?
<GrueMaster> What did the atrix come with?  iirc, it was based on Maverick.
<j4r00tn> it has nothing in it when I got it i had to install lxterminal and the other apps manually... the only thing it had is nautilus and firefox
<j4r00tn> i think it came with tomoyo
<twb> tomoyo's an LSM
<j4r00tn> then it's probably jaunty
<j4r00tn> yup it's jaunty (9.04)
<brandini> dennis ritchie is dead :(
<obarthelemy> hi. I'm running natty on an arm-based hercules cafe. works globally fine, except at boot I get a blinking curosr at the top left corner, and hav to do ctrl-alt-F1 to get a tty. It would be great if I could also know where to change my keyboard map at bott time instead of manually each time
<twb> obarthelemy: in lucid, at least, that's a known problem with plymouth on GUI-less installs
<twb> obarthelemy: to configure your keyboard, dpkg-reconfigure console-setup and/or edit /etc/default/keyboard
<obarthelemy> ok thanks i'll try that for the keyboard.. and for the tty, no solution then ? I tried to hack a inittab, but either I got it worng or it's no longer used
<twb> Well, I think I work around it by disabling plymouth by brute force
<twb> in lucid, you can't simply uninstall plymouth due to some silly apt dependencies
<twb> I don't run non-LTS releases, so I don't know how much of that's applicable to you
<obarthelemy> ok, thanks anyway :-)
<jondo> Hi ppisati, anything else I can do for bug 871650? Or just wait for jcrigby's tests
<ubot2> Launchpad bug 871650 in linux ""unable to enumerate USB device" with BeagleBoard-xM" [High,Confirmed] https://launchpad.net/bugs/871650
<ndec> ogra_: infinity: with gdm we could add 'text' in the bootargs and it would not start the gdm service, hence would not start UI. how can this be done with lightdm?
<ogra_> shoudl be the same
<ogra_> else its a bug
<ndec> ok... so it's a bug ;-)
<sebjan> confirmed. lightdm.conf does not scan the cmdline args. Adding what gdm.conf used to do here seems to be working for lightdm as well.
<ndec> ogra_: it sounds more a feature than a bug...
<ogra_> not really
<infinity> I'm not sure that was ever a widely-advertised feature, but it's still a minor regression I suppose.  File a bug on lightdm.
<sebjan> ok, I'll do that
<ndec> sebjan: i did
<ndec> bug 873334
<ubot2> Launchpad bug 873334 in lightdm "missing support for 'text' command" [Undecided,New] https://launchpad.net/bugs/873334
<sebjan> ok
* ogra_ changed the topic of #ubuntu-arm to: Ubuntu ARM Discussion & Development | https://wiki.ubuntu.com/ARM | Submit a Bug? https://bugs.launchpad.net/ubuntu/+filebug | Get oneiric while it's hot ! http://cdimage.ubuntu.com/releases/11.10/release/ | Logs at http://irclogs.ubuntu.com/
<ogra_> :D
<ogra_> everyone welcome our new baby ! its an Ocelot !!!
<ndec> congrats ;-)
<ogra_> thanks, its your work too :)
<brandini> w00t!!
 * brandini apt-get upgrades
<brandini> http://ppa.launchpad.net/tiomap-dev/release/ubuntu/  w00t!
<brandini> good work guys!
<ndec> brandini: PPA isn't fully ready stil...
<brandini> big surprised right :)
<Neko> it's release day isn't it?!
<GrueMaster> Yep.  Happy release day.
<MrCurious> yay!
<MrCurious> Guess i know what i will be doing tonight
<MrCurious> (discovering if omap4 addons is ready for 11.10)
<gildean> i also upgraded one trim-slice to oneiric
<gildean> seems to work ok
<gildean> some minor things, but thats mostly due to the rootfs i updated
<gildean> also nvidia beta-drivers seem to work on oneiric for trim-slice
<gildean> sorry, alpha, not beta
<jevin> anyone know of a fast mirror in the US that isnt hammered right now?
<jevin> apt mirror, that is
<jevin> nvm
<jevin> i forgot kernel.org was back up :)
<jevin> its "fast enough"
<GrueMaster> I was going to say mine, but it is internal only.
<jevin> neeer neeer :-P
<jevin> i should petition my uni to mirror ubuntu
<jevin> they (cerias) already mirrors releases
<brandini> does ubuntu maintain its own kernel source tree?
#ubuntu-arm 2011-10-14
<GrueMaster> brandini: Yes. Multiple trees.  http://kernel.ubuntu.com
<brandini> phew, why couldn't I find that
<brandini> GrueMaster: I'm still looking for the assembly code you guys wrote to initialized the panda :)
<GrueMaster> I believe TI keeps it in the mach-omap2 stuff under arch/arm.  Not sure.
<GrueMaster> Or plat-omap.
<brandini> they release source for that?
<GrueMaster> If you clone the ubuntu/ubuntu-oneiric.git tree, there should be a branch in it for ti-omap4 (iirc).
<brandini> thank you :)
<GrueMaster> It is a separate branch though, not the main trunk.
<GrueMaster> Looks like ubuntu-3.0.0-1205.10 (according to git web).
<twb> lilstevie: ping
<twb> lilstevie: nag re send me known-good u-boot.bin
<twb> lilstevie: poke poke
<CodeWar> whats a good hardware to test ubuntu-arm on ? preferrably a SMP one
<CodeWar> Tegra part of the supported list?
<twb> CodeWar: efikamx should be good, they seem to actually be contributing to debian
<twb> tegra is more like "if the moon is waxing and you're standing on one leg, it works OK...ish"
<infinity> We don't have installers for efika systems right now (and they're not SMP).
<infinity> If you want SMP, a Toshiba AC100 netbook  or a TI PandaBoard are your best bets.
<twb> infinity: oh, sorry
<twb> AC100s are about the same as TF101s, aren't they?  i.e. sucky?
<infinity> Mine works great.
<twb> OK
<infinity> Outperforms the Panda by no small margin, if it had a US keyboard layout, I'd actually use it as my primary netbook.
<infinity> But the Uk keyboard makes me want to kick puppies. :P
<twb> stupid enter key?
<infinity> Stupid everything.  Keyboard layouts are a religious thing. :)
<CodeWar> AC101 dual core A9 .. decent enough let me look it up
<twb> Well you can remap it if it's just the caps
<infinity> CodeWar: It's a Tegra2.
<infinity> twb: Yeah, remapping it fails a bit because you end up with a teeny-tiny \| key, due to the enter key eating most of its neighbours.
<twb> yeah OK
<infinity> Om now now.
<infinity> nom nom too.
<twb> That's one of my biggest hates on keyboards, that big enter key
<CodeWar> Asus Transformer 2 .. is that expected to work :-)
<twb> I mean half the time I type ^M anyway
<CodeWar> would be best
<infinity> CodeWar: There have been some people fiddling with the TF2.  It has no official support, but I know you can make it work with enough effort.
<twb> CodeWar: I have a TF101 (Eee Pad Transformer 32G); currently it only works with crappy old 2.6.36
<infinity> CodeWar: Panda or AC100 work out of the box, which is appealing if you just want to get to hacking.
<twb> When lilstevie comes back from the pub or his girlfriend's or whatever and helps me, I might make some more progress :P
<CodeWar> thanks guys .. still trying to wrap my head around these various models ..
<diwic> infinity, I was a little surprised when I read the release notes, AC100 and IMX.53 (I think?) was listed, but not the Pandaboard.
<infinity> (And most devices that ship with Android can just be abused to boot Ubuntu with an Android kernel, but the user experience there will vary, depending)
<twb> That's cheating
<twb> it doesn't count
<infinity> diwic: AC100 and i.MX53 were listed as new, omap3 and omap4 were already supported.
<diwic> infinity, ok, that explains it, thanks
<soren> You know what would be awesome? If someone sold a complete get-started-on-hacking-Ubuntu-on-ARM kits at UDS. Pandaboard, power supply, SD card with Ubuntu pre-installed, USB-serial dongle, whatever else one might need.
<twb> sheevaplug used to ship with ubuntu pre-installed
<infinity> soren: To be fair, that's more or less what you get if you order a Freescale i.MX53.  They ship with an SD with Ubuntu.  Though, I need to find someone at Freescale to talk to about refreshing their image to use a saner kernel.
<twb> But IMO the goal should be a pure blend
<infinity> It would be nice if TI did the same thing with the Panda package, though.
<infinity> Not that it's rocket science to download an image and make it go, but the user experince is fairly shiny when it "just works" without having to read.
<soren> infinity: Looking at the i.MX53 now. Glancing at the specs, it looks somewhat less beefy.
<infinity> soren: Well, it's a single-core A8, which is less cool than a Panda or AC100, but for people doing a lot of building, the on-baord SATA more than makes up for it.
<soren> infinity: Oh, shiny. I didn't notice that.
<infinity> soren: Building most things on A8/A9 systems is almost entirely I/O bound, not CPU.
<twb> infinity: what, you don't use iSCSI pointing at the SAN for everything ? ;-)
<soren> infinity: Ok. Well, let me rephrase then..
<soren> You know what would be awesome? If someone sold a complete get-started-on-hacking-Ubuntu-on-ARM kits at UDS. Freescale i.MX53, power supply, SD card with Ubuntu pre-installed, USB-serial dongle, whatever else one might need.
<infinity> twb: It doesn't matter how cool my networking tech is, you can't get past the part where Pandas have a 100bit ethernet adapter hanging off a USB 2.0 bus. :P
<soren> 100bit? Holy crap.
<infinity> Mbit.
<infinity> Typing is hard.
<soren> Oh. Those.
<infinity> It feels like 100bit.
<twb> that's the uart :P
<infinity> (To be clear, I have no issues with the Panda's architecture, it's a dev board meant to be a giant cell phone, and it works great for what it's meant to do... It's just a lousy desktop or build server due to USB being your limiting factor for any storage)
<soren> At least for me, having to buy unknown hardware and bits and pieces just to even get started has put me off for a looong time. Now I've actually bought a pandaboard, but still haven't gotten it to work.
<infinity> soren: Flash oneiric image to SD, insert, boot.
<soren> Done that.
<infinity> soren: It's pretty straightforward these days.
<soren> Doesn't work. It just lights up very briefly, then turns off.
<soren> No clue why.
<infinity> That sounds unpleasant.
<infinity> The turning off bit.
<infinity> They don't do that.
<soren> I RMA'ed the board (not just for this reason), but the new one does the same.
<infinity> Oh, actually, it might do that if it fails to find anything interesting on the SD, I don't recall.
<soren> What the heck. I'll give it another go.
<infinity> Wiggle the card, rewrite it moar bettar, use a different one?
<soren> Where' the current "Idiot's guide to Ubuntu on Pandaboard"?
<soren> I've tried two different card.
<infinity> https://wiki.ubuntu.com/ARM/OMAP
<soren> Same micro-SD-regular-SD converter, though.
<infinity> Oh, I've had serious issues with micro->regular->Panda, though I'd always assumed it was just my own cards and adapters being shit.
<infinity> (Which it probably is)
<soren> Maybe I should see if I could find a regular SD card somewhere.
<soren> ...or just try a different adapter.
<infinity> But yeah.  SD/MMC is about the worst choice for installatoin media ever, but we have no options.
<soren> HAdn't thought of that.
<twb> infinity: ferrite core
<infinity> If I recall, the Panda will just appear to "do notihng" if you light it up and it sees nothing of interest in the SD slot.
<soren> infinity: Well, if no SD card is in, it stays on.
<soren> When my SD card is in, it shuts off.
<infinity> Well, nothing of interest, after looking.
<infinity> It's a bit fiddly in those first few miliseconds. :P
<infinity> After that, it's great!
<soren> I guess it could be the power supply.
<soren> It says it goes up to 2.5A.
<twb> Or dirty power that is pissing it off because it's a switching-mode PSU and thus sensitive to problems in the wave
<twb> We went through three soekris net5501 PSUs here before we gave up
<soren> infinity: The for the PAndaboard I want to use the OMAP4 image, right?
<infinity> soren: Yup.
 * soren downloads
<soren> Oops, accidentally grabbed the natty image. Will that work ok?
<infinity> It will, but why start out-of-date?
<infinity> Especially if you're using SD.  Upgrading is SLOW. :P
<soren> I just want to see that damn thing work.
<soren> Also, the oneiric image seems to be more than 3 times bigger. Writing out the natty image takes long enough.
<soren> Holy crap! It stayed on!
<infinity> Magic.
 * soren headdesks
<soren> It's been that adapter all along, then!
<soren> And the one I'm using now is identical. *sigh*
<ogra_> lool, poke
<ogra_> hmm
<ogra_> infinity, do you happen to know where the new flash-kernel lives in debian atm ? did it migrate to unstable or is it still in experimental ?
<ogra_> (i would like to file a sync request ahead of time so we have it immediately after opening)
<infinity> ogra_: Not sure.  I'd assume either experimental, in some VCS somewhere, or on lool's hard drive.
<ogra_> i suspect we will run into a pile of issues
<ogra_> so the sooner we get it the better
<infinity> ogra_: I'm not positive that lool thinks it's ready for prime-time, but I haven't talked to him about it for a couple of months.
<ogra_> i know its ready for the arches we support but might handle things different than we do for these
<infinity> ogra_: Given that this is an LTS coming up, I'm not sure I'm inclined to switch.
<ogra_> i know its not ready for "old" arches
<infinity> ogra_: Dealing with the bugs we know seems saner.
<ogra_> which we dont care about
<ogra_> and i know its used by default in armhf in debian
<ogra_> but thats not in any official repo
<infinity> Almost.
<infinity> But is it?  They don't have installation media.
<ogra_> infinity, well, you had a spec to actually use its database for HW stuff iirc
<ogra_> and i would like to get rid of the crap ahead of the LTS
<ogra_> else we need to carry the hackish version for 5 years
<infinity> http://ports.debian.net/debian/pool-armhf/main/f/flash-kernel/
<soren> What does "hf" stand for, btw?
<ogra_> right, i dont think we can sync from there
<diwic> hard float
<ogra_> soren, hard float
<soren> Ah.
<diwic> ogra_, does the official oneiric image for AC100 have working sound?
<infinity> ogra_: Eh.  I don't mind carrying it for 5 years.  Once it's set up, it works.  It's not like it's a maintenance burden.
<ogra_> diwic, btw, doi you remember who waas chiming in when we talked about 5.1 recievers ? i owe him a beer :)
<infinity> diwic: It does if you use headphones.
<ogra_> diwic, only with a kernel update thats not in an SRU yet and with some alsamixer adjustments
<ogra_> and it breaks after resume from suspend
<ogra_> but all these issues should be fixable and will make it into SRUs
<infinity> ogra_: The problem with that spec is that it assumes some debian-cd violence and other things.  Which I'm happy to do, but I feel like it would be a waste of timein a cycle where we should be focussing on stabilising existing software, not introducing new stuff.
<diwic> ogra_, sorry, don't remember the 5.1 receiver stuff?
<ogra_> infinity, well, for me thats not so much introducing new stuff but getting rid of the horrid hacks
<infinity> ogra_: I really do want to implement that spec and get the new hw DB idea working right, but this just feels like the wrong time.  I dunno.  We'll argue about it in Orlando. ;)
<ogra_> diwic, yeah, its started with me asking you about spectrum analyzer software
<diwic> right
<ogra_> he chimed in and recommended me to rather get a denon ...
<ogra_> after 3 weeks of bitter ear pain with the new yamaha i returned it on monday ... now i have a denon, no more earpain, waaaay better sound :)
 * soren pats his Denon receiver in his desk
<ogra_> and i got it reaaaaly cheap because they felt pity for giving me something that produces ear pain :)
<ogra_> (like a 500â¬ discount *g*)
<soren> Wow.
<ogra_> soren, for the SACD player i bought i got a 1000â¬ discout because the box was missing ....500 isnt that much ;)
<soren> If you can get a â¬1000 it must have been rather pricey to begin with.
<lilstevie> ogra_: is there anything major different between the AC100 image and the omap builds?
<soren> I think mine cost â¬1000 total.
<soren> 11 years ago.
<ogra_> lilstevie, look at ac100-tarball-installer source, that has all the specialities ... beyond that indeed it has its own kernel and bootloader setup
<lilstevie> ok :)
<ogra_> soren, yeah, my old system costed me 600, including cup sized speakers etc ... i thought its time for an upgrade and invested 5000
<lilstevie> ogra_: was mainly wondering for basing my transformer stuff from one of them
<ogra_> lilstevie, feel free, but you might need some adjustments
<lilstevie> well I do have a different bootloader setup
<ogra_> right, and a different kernel
<lilstevie> yeah
<lool> ogra_, infinity: New f-k is in experimental and in git
<lool> there are more changes to be done, but I guess it's already better than what we have
<ogra_> lool, do you think its suitable for an LTS ?
<ogra_> yeah, thats what i think too
<lool> it doesn't support SD card right now
<ogra_> and i dont want to sit on what we have for 5 years
<ogra_> argh, seriously ?
<lool> well, it doesn't have any OMAP mechanism; you could point it at /boot though
<lool> I don't think much OMAP support made it to Debian
<ogra_> does it have omap4 ?
<ogra_> shouldnt be to hard to derive from there
<lool> that included lack of OMAP4
<ogra_> bah, k
<brandini> morning all
<brandini> is com0 at 0x49020000 on the panda?
<FunkyPenguin> aloha, does ubuntu build from a single source or do you have a separate one for arm vs x86?
<FunkyPenguin> wondering if i look for a package in packages.ubuntu.com does that cover arm?
<ogra_> most of the time, yes
<ogra_> all packages use the same source, packages.u.c wont tell you if the binary exists though
<ogra_> http://qa.ubuntuwire.org/ftbfs/ has a list of all failed builds
<FunkyPenguin> ogra_: great, thanks
<ogra_> you can also look on launchpad.net/ubuntu/
<soren> What's the rationale behind that /var/lib/preinstalled-pool thing in Oneiric?
<soren> What's worse is that the very first package I installed from there has a checksum mismatch :(
<ogra_> that shouldnt happen, infinity ^^^
<soren> The python-setuptools package I have in there is all NULLs.
<ogra_> its what we ship as pool on the x86 server isos and should support installs without network
 * soren checks the image
<ogra_> right, compare your md5
<soren> Image checksum matches.
<ogra_> hmpf
<infinity> Yeah, but does it match once you've written it to SD?
<soren> That's what I'm about to find out.
<soren> WEll... Sort of.
<infinity> I can write an image out in a sec and have a look.
<infinity> Where "in a sec" is "sometime this afternoon".
<soren> I'll mount the image on my laptop and see if the problem exists there, too. Otherwise, it probably got screwed up when I wrote it to the SD.
<soren> Nope, it's fine if I mount it on my laptop.
<soren> Weird.
<soren> No idea where it got scrwed up, then.
<ogra_> hmm, porobably a kernel issue then... mmc driver or filesystem driver issue
<soren> Most of the files in there seem fine.
<ogra_> on your laptop...
<soren> Just 9 of them have this problem.
<soren> No no, on the SD card.
<ogra_> if inserted in your laptop or in the panda ?
<soren> Panda
<ogra_> ah
<ogra_> hmm
<ogra_> bad SD ?
<ogra_> i.e. some borked blocks that shouldnt have been written to ?
<soren> No idea. It's brandh new. Just unwrapped it a couple of hours ago.
<soren> dmesg is silent.
<soren> (on this subject, I mean)
<soren> Plenty of other stuff in dmesg.
<ogra_> hmm
<infinity> I could rant about SD/MMC quality again, but I seem to do that often enough.
<infinity> While I think it's cool that we provide an SD grow-root installation method (and, indeeed, that's the simplest way for people to test their hardware and get started), I still think the goal should be to encourage people to get their system on reliable external storage ASAP.
<infinity> And just use the SD for uBoot.
<ogra_> or support boards with nand booting only :P
<ogra_> we just need to convince vendors to put more money in :)
<infinity> ogra_: I don't mind treating the SD slot as a hardwires flash/firmware area.  At the end of the day, the behaviour is the same.
<infinity> ogra_: And that's what we do when we netboot, for instance.
<infinity> It's also how my i.MX53 and Panda both run when they're at home.
<infinity> s/hardwires/hardwired/
<ogra_> infinity, right, thats also what we did on babbage ... though there we had the prob that we had to install to the livefs media while running from it
<xranby> wow... i got opengl-es to work on my pandaboard using oneiric  and using the default package sources..  i simply installed every omap4 package and then it turned ON
<xranby> i was expecting to get the packages from the ti ppa.. but they where already in main
<infinity> *raise brow*
<xranby> infinity: want a screenshot?
<infinity> There's no way that's hardware accelerated if it involves nothing from TI.
<xranby> infinity: http://openjdk.gudinna.com/lwjgl-es/pandaboard-LWJGL.png
<xranby> running at 130fps
<infinity> xranby: 130fps sounds like software rendering to me.
<xranby> infinity: libEGL comes from the SGX omap 4 package
<xranby> infinity: this are usning java -> opengl-es bindings
<ogra_> infinity, es2gears in SW rendering on the ac100 gets me 20-30 frames
<ogra_> i think its about 180 if accelerated
<infinity> xranby: I can't find this package you're referring to.
<xranby> infinity: let me try generate a list of installed packages
<infinity> xranby: dpkg -S /path/to/file
<xranby> are the some way to list the packages that got installed  today?
<twb> Would that be the "benchmark" that has a --i-acknowledge-this-is-not-a-benchmark option?
<xranby> infinity: http://paste.ubuntu.com/707964/    perhaps i got them from the ppa after all
<ogra_> twb, i think that was dropped again at some piunt :)
<ogra_> *point
<infinity> xranby: "apt-cache policy packagename" will tell you where it comes from.
<infinity> xranby: But yes, those aren't in the archive.
<ogra_> well, we definitely dont ahve ubuntu-omap4-extra in any official archive
<ogra_> and you have the sw-center added ppa .list
<xranby> infinity: ok i can now confirm that they did come from the ppa
<xranby> thanks ti
<ogra_> :)
<ogra_> send flowers to ndec and his team :)
<xranby> ndec: cheers!
<ogra_> (or probably better bottles of old wine)
<twb> ogra_: well that's bloody stupid
<xranby> ndec: i have lwjgl java bindings working on the pandabord using your latest oneiric drivers..
<xranby> nice
<ndec> yes, gfx libs have been in PPA for a while now. video decoders are coming soon...
<xranby> ndec: ok meanwhile i have filed a bug against the LWJGL upstream to add support for all your drivers extensions http://lwjgl.org/forum/index.php/topic,4237.0.html
<xranby> ndec: when i install teh libEGL and friens  all .so ends with .so.1   are this intentional?
<xranby> the opengl-es userspace applications are looking for the  libEGL.so symlinks  and fails to find the library
 * ndec thought we had fixed that.
<ndec> xranby: yes, this is true the .so is only in the -dev package (e.g. libegl1-sgx-omap4-dev)
<ndec> to me it's more a bug in the applications, ... but we've seen that in the past, and since we cannot change all applications, we need to update our package.
<ndec> for now, you just need to install the -dev
<xranby> ok thank you for checking
<infinity> There's a longstanding history of bainry GL apps looking for .so instead of the actual library. :/
<infinity> But we don't ship .so in any library package, for sanity reasons.
<infinity> binary*
<xranby> hmm i wonder why.. the brainy GL apps simply try to link againt EGL
<xranby> 'to get into this state
<xranby> -lEGL are passed tot he linker
<xranby> and it makes the linker pick to use the .so
<infinity> xranby: Err, wait.
<infinity> xranby: You need the -dev (and the .so) to link...
<infinity> But it should then link to .so.1
<xranby> usually you can have EGL mesa installed to build it
<xranby> so the app links against the mesa EGL -dev package
<xranby> libegl1-mesa-dev - free implementation of the EGL API -- development files
<infinity> I'm still not sure what your bug is here...
<infinity> You need dev packages installed to compile.
<infinity> But not to run.
<infinity> If "ldd mybinary" shows that you've linked to an unversioned .so, that's certainly a bug (ie: if you need it at runtime).
<ndec> we used to have wrong SONAME in our libs, but this is fixed. objdump -p /usr/lib/libEGL.so | grep SONAME will tell you libEGL.so.1 (and it used to be the .so). the soname is what the app will link against.
<ndec> perhaps the mesa-dev package has wrong soname?
<infinity> ndec: Almost certainly not. :P
<infinity> (If it did, nothing on my system would work)
<ndec> xranby: is your app dynamically linked against the .so, or do you have a dlopen to the .so . i think firefox does (did?) that
<xranby> let me check
<xranby> ldd at points to /usr/lib/libEGL.so   i guess that makes it dynamically link
 * xranby are rebooting his board... for some reason the usb mouse/keyboard refused to enumerate
<brandini> morning dudes
<_Thomas> Does anyone here work with the ubuntu release for the Linaro Origen-board?
<_Thomas> (I'm wondering if anyone knows the status of getting HW opengl on that board)
<ogra_> _Thomas, as i said in the other channel, ubuntu-arm doesnt support the origen board
<_Thomas> ok
<stephen__> pandaboard: linaro image vs ti-omap ppa
<stephen__> which is better?
<brandini> so when I have the load address in uboot, is that looking for KERNEL_BASE_PHYS=0x80300000?
#ubuntu-arm 2011-10-15
<Xase> Yay for ARM
<twb> ubot2: seen lilstevie
<ubot2> I have no seen command
<twb> Bah.
<lilstevie> twb: I haven't forgotten about you
<twb> Yay!
<Xase> Bah.
<CodeWar> looking for a good ARM development system .. doesn't have to be a tablet
<CodeWar> so far found trimslice .. probably try Asus TF101 .. let me know if there are other suggestions
<lilstevie> CodeWar: TrimSlice and the TF101 are pretty cool
<lilstevie> TrimSlice is probably slightly better though
<CodeWar> lilstevie, does it run Ubuntu properly .. not sure how to purchase one their site doesn't mention
<lilstevie> define properly :p
<lilstevie> it runs well if thats what you mean
<lilstevie> there are ofc still a few bugs
<lilstevie> and to purchase look at the resellers list
<Xase> Trimslice looks fun
<Xase> Meh I was trying to run ubuntu 11.10 from SD slot on my nook color... at least 11.04 hanged the power on of the device until the SD card was removed... this 11.10 doesn't even seem to get ead.
<Xase> read*
<gildean> oneiric works with trim-slice
<gildean> i just upgraded one yesterday
<gildean> and i'm thinking about building an installer for it
<gildean> or at least upgrade the natty version compulab distributes
<Xase> I wonder if Trimslice offers volume discounts...
<Xase> Those would make a sweet setup for an internet cafe.
<Xase> Man if I wasn't afraid of damaging my nook color physically, I'd rip it apart.
<gildean> i'm sure you could come up to an agreement
<Xase> I think it would make a pretty bada$$ ubuntu tablet.
<gildean> they sold the pro model as dev-kit for half the price
<Xase> There
<Xase> There's no notion as to whether or not it is reading this damn sd card.
<Xase> Feh...
<Xase> Two hours DDing that img for nil.
<Xase> Oooh
<Xase> Found something interesting while holding my n key :D
<Xase> a custom uboot menu
<Xase> Ah fiddlesticks... it lets me boot from sd, but hangs like the old Natty install
<Xase> Maybe the kernel is acting up?
<gildean> yeah, sounds like it doesn't like some of the nooks hardware or something like that
<gildean> hmm, try to suppress the quiet option in the boot and you might see what's wrong
<Xase> I would but it's a very rudimentary boot menu interface to uboot, that doesn't give any options other than selecting emmc/sdcard and uimage/wuimage
<Xase> I don't get access to anything of the oneiric's image it seems.
<Xase> I'm trying to figure out how to mount the second partition of this sdcard... with vold
<Xase> What is the fs type of the second partition made by DDing the arm preinstalled image?
<Xase> ext2?
<Xase> o.o
<Xase> ROFL!!!
<Xase> There's a typo in /etc/vold.fstab on the Encore (Nook Color)
<Xase> ## Vold 2.0 Barns and Nobel Encore
<Guest956> hi all, oneric on beagleboard-xm howto? Mine loops on booting kernel?
<Bodman456_> Hi all
<Martyn> morning
<Bodman456_> I have a question
 * Martyn is spending his morning installing oneiric onto a reference ARM platform server
<Martyn> ever fun
<Bodman456_> with the current state of Ubuntu ARM, will any of the Natty release kernels work upon the Qualcomm Snapdragon APQ8060 ARMv7 processor?
<Martyn> it's arm v7, so it should
<Martyn> although the APQ kernel isn't natively supported that I know of
<Bodman456_> Hmm
<Martyn> so you will have to -re-compile a release kernel with the support you need
<Martyn> not a hard thing to do
<Bodman456_> Ah, thanks
<Martyn> the problem is the usual one.  ARM isn't a unified platform
<Bodman456_> Yeah
<Martyn> it's even worse than that, really.  You need to enable -board- support
<Bodman456_> We've got Qualcomm with Snapdragon, TI with OMAP, and nVidia with Tegra/2
<Bodman456_> all with their own  unique features, with different calls
<Bodman456_> I'll take a look at compiling the kernel later and loading it onto my TouchPad to see if it boots.
<Martyn> ahhh :)
 * Martyn points to his TouchPad :)
<Martyn> It will definitely boot
<Martyn> there's already some work on the wiki to tell you what's what
<Martyn> bootloader installation was the un-fun part
<Bodman456_> Oh, didn't even notice that
<Bodman456_> XD
<Bodman456_> at least we have moboot to make this a lot easier
<Martyn> I got u-boot working, but it's a bear to install
<Bodman456_> nice
<Martyn> Well, nice-er
<Martyn> but moboot does the job
<Martyn> ubuntuchroot is the most popular method, of course
<Bodman456_> yeah
<Bodman456_> I'd prefer the option of a native boot though
<Bodman456_> woops
<Bodman456_> accidentally closed my wIRC card
<robclark> hmm, does unity-greeter depend on GL stuff?
 * robclark is wondering why unity-greeter doesn't work but gtk-greeter does..
<robclark> (although also possible something got b0rked in the natty->oneirick upgrade)
<GrueMaster> robclark: I would suspect the upgrade.  I had the same issue going from Oneiric Alpha2 up (weekly dist-upgrades when the pool was settled).
<GrueMaster> Although I have not done a Natty>Oneiric upgrade yet.
<brandini> GrueMaster: I've made progress on my openbsd port to the panda
<brandini> I'm really excited :)
<GrueMaster> Have fun with that.
<brandini> I am!
<GrueMaster> Personally, I am not much interested in freeBSD.  Now, getting Ubuntu on my Nook Color, that sounds like a fun challenge.
<brandini> freebsd is not the same as openbsd
<GrueMaster> Just hope I have time for side projects this cycle.
<brandini> it does sound fun!
<GrueMaster> Last cycle I used my NC for actually reading.  How odd.  :P
<brandini> :)
<GrueMaster> At any rate, it is Saturday after release.  Fragfest at a friends house all day.  Time to go kill kittens (on screen).
<brandini> Yay!
<CodeWar> how can I check what apps are available on ARM Ubuntu 11.04/11.10 repositories
<CodeWar> particularly I m interested in the port of Java
<rlrosa> hi
<rlrosa> i installed
<rlrosa> gcc-arm-linux-gnueabi
<rlrosa> g++-arm-linux-gnueabi
<rlrosa> on ubuntu 11.04
<rlrosa> i can cross compile successfully with gcc-arm.. , but g++ fails to link libc:
<rlrosa> /usr/lib/gcc/arm-linux-gnueabi/4.5.2/../../../../arm-linux-gnueabi/bin/ld: warning: libc.so, needed by /usr/lib/gcc/arm-linux-gnueabi/4.5.2/libgcc_s.so.1, not found (try using -rpath or -rpath-link)
<rlrosa> any tips?
#ubuntu-arm 2011-10-16
<twb> apt-file might tell you where that ld lives
<Bodman456> Hi all
<Bodman456> I downloaded the preinstalled OMAP4 image, and when I extract it, instead of getting a .img file, I get a .raw
<Bodman456> Any ideas?
<phh> that's the same thing .. both are meant to be dded
<Xase> Does anyone here think that using an Android kernel, instead of the one already in Oneiric, for a device would yield more favorable results in booting it natively on an android-installed device (Referring to Nook Color, Codenamed: Encore) ?
<Xase> It's more or less a modified BeagleBoard, though I'm not too familiar with the  Beagle Board to know which revision it's most like...
<lilstevie> Xase: well running the android kernel will have its caveats
<Xase> Of course, but I mean to at least get it running.
<Xase> I can't quite grasp the difference between uImage and the vmlinuz kernel though...
<Xase> They're not the same thing... but are?
<Xase> Because in the source I want to use the kernel from (CyanogenMod 7.1 as it has bluetooth setup properly where as BN's pure nook source doesn't), it only contains one file: kernel" in the same directory as MLO
<lilstevie> uImage is a vmlinuz packed for u-boot
<Xase> Which is roughly the same size as uImage
<Xase> Now I know MLO has something more or less to do with uboot... I've done a lot of reading and still cant properly grasp all this :p but hey learning is best done through trial and error.
<Xase> So since uboot requires a uImage, I can probably assume that uboot is reading this "kernel" file somehow as uImage?
<Xase> Because I know uboot can look for alternative kernels...
<Xase> And obviously android wouldn't require vmlinuz, the way it handles things I assume, so I'd also need to take the CM source and rebuild a vmlinuz target from the same make conf that was used to construct the uImage... am I hitting any nails on the head yet?
<Xase> And then when all is said and done... inject both into the Oneiric preinstalled image?
<Xase> In their respective partitions of course :D
<Xase> Speaking of ubuntu... I need to make this computer dual boot again =( I forgot to redo it.
<Xase> =/
<stlsaint> sup folks
#ubuntu-arm 2012-10-08
<infinity> ogra_: Reviewed and accepted.
<infinity> ogra_: A bit shocked that those drivers don't both ship in the same tarball (or even just as the same driver), but whatever.  nvidia never ceases to confuse.
<lilstevie> infinity, heh that is nvidia for you, I'm not even quite sure what the difference between the T2 and T3 pack is yet
<marvin24> lilstevie: the avp firmware is different, but that's also a different tarball ...
<lilstevie> marvin24, yeah I know the avp firmware is, but that is cause the avp is different in general from what we have seen
<lilstevie> marvin24, but the acceleration xorg driver and libs that you guys package up for the ac100 work just fine on the tf201
<marvin24> lilstevie: the original tar gz (for up to abi 12) contains a lot more
<marvin24> e.g. kernel, bootloader, ...
<marvin24> abi13 driver was released as a single tegra_drv.so (which is identical for tegra2/3)
<lilstevie> marvin24, oh yeah, bootloader and stuff could easily go in the same tarball though
<lilstevie> given size is not big
<marvin24> maybe customers may get confused if they see more than one kernel ;-)
<lilstevie> maybe
<lilstevie> although that would be a little troubling :p
<wookey> infinity: my build is failing with ../sysdeps/unix/sysv/linux/init-first.c:102:1: sorry, unimplemented: function profiling
<wookey> and indeed it is unimplemented. Where do I turn it off for the arm64 build?
<wookey> (eglibc)
<wookey> aha debian/sysdeps/arm64.mk looks plausible. --disable-profile
<doko> ogra_, is the openscenegraph ftbfs on arm the gl/gles problem?
<ogra_> dunno, i didnt even know it ftbfs
<doko> asking because a whole lot of things b-d on it
<ogra_> (/me is on a special forces project until UDS ... so i didnt follow the ftbfs list)
<janimo> marvin24, what's the prospect of ac100 being all mainlined, any ETA?
<janimo> any blockers still?
 * janimo hopes it's there by 13.04 :)
<marvin24> janimo: it is (all) mainlined for over a year now
<marvin24> unfortunately, tegra2 support isn't ...
<marvin24> I would also prefer to move to mainline for 13.04
<marvin24> we already lost supend with 3.1, so it shouldn't matter if we lose some more stuff ;-)
<janimo> marvin24, well I mean ac100 support as in working out of the box :)
<janimo> and your insight on where the tegra2 upstreaming stands
 * ogra_ doesnt think there is anything gfoing on wrt upstreaming the tegra2/3 bits
<ogra_> especially in the light that they are mostly developed for android which uses snapshot kernels
<ogra_> as long as android moves with that practice i doubt we'll see changes here
<marvin24> janimo: it works out of the box if you add the drm driver
<marvin24> ogra_: wrong, e.g. today lp2 support was added for tegra3
<ogra_> ah, nice
<marvin24> I think tegra2 has it already
<janimo> what's lp2
<ogra_> well, they still build their binary drivers against a special kernel tag usually
<marvin24> but I haven't looked lately
<ogra_> and i doubt that will change in the short term
<ogra_> marvin24, janimo's dream is to use mainline for ac100 (and other tegras) in 13.04
<marvin24> ogra_: tegra drm will likely come to staging in 3.8
<ogra_> when is 3.8 due ?
<marvin24> and "they" already made some changes to mainline to get their propietary driver working
<janimo> 6 mo probably
<ogra_> early 20013 ?
<ogra_> oops
<marvin24> no, we are not that slow
<ogra_> didnt mean to exaggerate that much :)
<marvin24> ;-)
<marvin24> so we will endup in a situation where both drivers are supported
<marvin24> the open one likely without any 3d or video accel
<ogra_> thats fine
<ogra_> and thats how i use the closed one atm :)
<marvin24> I hope I didn't look too deep into the glass
<ogra_> on my ac100 at least
<lilstevie> yeah, O cam
<lilstevie> er
<lilstevie> I can't say I use the 3D and video accel on my prime either
<ogra_> well, and what for :)
<ogra_> there isnt really much thats built for GLES
<lilstevie> ogra_, yeah, and I really don't watch videos on my prime anyway
<ppisati> ogra_: by any chance, did you try Q on your beagle?
<ogra_> nope
<ppisati> ok
<ppisati> anyway, problem found and fix too
<ppisati> i'll send a pull req tonight
<ppisati> (after gym)
<ogra_> ppisati, you rock !
<ogra_> will test with the fix then
<sakoman_> was the CONFIG_HIMEM issue on Pandaboard ever resolved?
<sakoman_> (i.e. random crashes when trying to do a kernel build if CONFIG_HIMEM was set)
<ogra_> ogra@panda:~$ grep HIGHMEM /boot/config-3.5.0-211-omap4
<ogra_> # CONFIG_DEBUG_HIGHMEM is not set
<ogra_> CONFIG_HIGHMEM=y
<ogra_> we have it enabled since a while, so yes
<ogra_> at least in 12.04 and 12.10 it should be fine
<sakoman_> do you recall what the issue root cause was?
<ogra_> no, but there was a bug
<sakoman_> I'm working on another OMAP4 based system and it too has random crashes if HIMEM is enabled :-(
<sakoman_> running 3.6
<ogra_> bug 633227
<ubot2> Launchpad bug 633227 in linux-ti-omap4 "instabilities with highmem activated" [High,Fix released] https://launchpad.net/bugs/633227
<ogra_> we use 3.5 in 12.10, seems pretty solid
<ogra_> but we dont use mainline. mind you
<sakoman_> hmmm . . . not really clear from that bug exactly what fixed the problem :-(
<GrueMaster> What ever became of devicetree for arm?  I'm reading articles covering the 3.7 kernel, and they don't even seem the same.
<rsalveti> sakoman_: I don't think we got to the point of finding exactly what was the patch that fixed the issue
<rsalveti> I believe that at some point it just worked as expected
<tinti> Hi, can someone give me a hint about how to debug linux kernel boot without JTAG? I was thinking in use early_printk and try to use usb debug
<wookey> tinti: DEBUG_LL is useful in early linux boot
<tinti> wookey: thanks :)
<wookey> maybe that's what's called early_printk these days
<wookey> it writes direct to serial port
<wookey> or probably USB these days, as no-one has serial ports anymore
#ubuntu-arm 2012-10-09
<tinti> wookey: in fact it is for raspberry pi :)
<tinti> wookey: I think it is at least reasonable to implement it over gpio too
#ubuntu-arm 2012-10-10
<TheMuso> p/c
<janimo> ogra_, around?
<ogra_> janimo, now, yep
<marvin24> ogra_: I just received message from nvidia that the gstreamer modules are lgpl (sources come later)
<ogra_> awesome !
<marvin24> the nvgstplayer/recorder are not lgpl, but the "LICENSE" applies
<marvin24> which means, AFAIU, they can be redistributed by linux distros
<marvin24> but not by anything else
<marvin24> this is the "License For Customer Use of NVIDIA Software"
<ogra_> yeah, thats the std thing for all driver packages
<ogra_> same as x86
<janimo> marvin24, do you know if the ac100 android drivers for the webcam worked out of the box with V4L on Linux?
<janimo> from what I see android webcam drivers are not necessarily V4L compatible as they rely on userspace services to provide a unified camera API
<ogra_> janimo, yes, they did
<ogra_> janimo, the advantage of having an uvcvideo compatible cam :)
<janimo> good to know :)
<marvin24> yeah, the nvidia interface is totally crap
<ogra_> yup, luckily we didnt need to use it on the ac100
<marvin24> on the other hand, I guess using usb for nearly everything eats a lot of power
<marvin24> there must be a reason for i2c, spi, iio, and all the other strange busses
<ogra_> yeah
#ubuntu-arm 2012-10-11
<ericbutters> hi. i got: init: mounted-proc main process (1268) terminated with status 1
<ericbutters> with 11.10 12.04.1 and 12.10 (beta2)
<ogra_> as i said in -devel, thats likely missing kernel options upstart needs
<ogra_> compare your kernel config to an ubuntu one
<ericbutters> orga_ sry, but where to find ubuntu .config?
<ogra_> i told you in the other channel
<ericbutters> ok i see. thx
<adam_tl> hi, where do find the ".config" for "freescale imx5x" board? there is an 12.04 image, but did not find at http://kernel.ubuntu.com/~kernel-ppa/configs/ ?
<adam_tl> i tried to build an image for imx53 board but it always fails to boot, it want to mount root fails.. after a minute it tells me that imx-sdma firmware not found
<ericbutters> i need that one two :)
<ogra_> adam_tl, download the respective kernel package and unpack it
<ogra_> it is usually put into /boot/config-$(uname -r)
<adam_tl> ah ok
<wookey> doko: I solved my stage2 build problem by adding MULTIARCH_DIRNAME = $(call if_multiarch,aarch64-linux-gnu) to src/gcc/config/aarch64/t-aarch64-linux
<wookey> But libgcc_s.so is ending up installed in /tmp/usr/<triplet>/lib instead of /tmp/usr/lib/<triplet>, so the files is not found when assembling the libgcc1-arm64-cross package at the end
<wookey> oddly libiberty.a ends up in the right place...
<wookey> I wonder if that is a clue to where the wrong path is hiding. (it's awfully complicated inside all this gcc build fooery!)
<doko> wookey, ahh, ok. will add the MA macro
<doko> wookey, just libiberty.a, or anything else?
<wookey> doko: I just mailed you the updated patch
<doko> wookey, is this installed from some gcc-4.7 packaging files, or by some cross rules files?
<wookey> I'm not sure. I've been peering through the log trying to work out where it all comes from
<wookey> make[5]: Entering directory `/home/wookey/linaro/armv8/toolchain/quantalnew/arm64-cross-toolchain-base-1.89/gcc/build/aarch64-linux-gnu/libgcc'
<wookey> /bin/bash ../../../src/libgcc/../mkinstalldirs /home/wookey/linaro/armv8/toolchain/quantalnew/arm64-cross-toolchain-base-1.89/gcc/debian/tmp/usr/aarch64-linux-gnu/lib; /usr/bin/install -c -m 644 ./libgcc_s.so.1 /home/wookey/linaro/armv8/toolchain/quantalnew/arm64-cross-toolchain-base-1.89/gcc/debian/tmp/usr/aarch64-linux-gnu/lib/libgcc_s.so.1; rm -f /home/wookey/linaro/armv8/toolchain/quantalnew/arm64-cross-toolchain-base-1.89/gcc/debian/tmp/usr/
<ericbutters> ogra_: i see in the config (ac100) that it enabled initrd --> i read that with initrd no mountall error comes up.. i do not have an initrd..
<wookey> so that installs it to the wrong path
<adam_tl> i wanted to rebuild the ubunutu arm kernel linux-linaro-lt-mx5 and got gcc compilation error, how come when they compiled it?
<ogra_> ericbutters, even when booting an ubuntu kernel with noinitrd there is no such error, thats unrealted to initrd
<adam_tl> gcc error, "DA9052_BUCK_PERI_VOLT_UPPER" was not declared;)
<ogra_> better ask that in #linaro :)
<ogra_> they maintain that kernel
<ericbutters> ogra_ you mean i need to set noinitrd in kernel command line?
<ogra_> no
<ogra_> i mean thats unrelated to your error
<ericbutters> okay
<sauerbraten> GrueMaster?
<GrueMaster> sauerbraten?
<sauerbraten> I have to do that boot.scr-remove-serial-console thing again
<GrueMaster> Ok.  Easy enough.
<sauerbraten> I'm using the preinstalled server image, it has debian-installer/framebuffer=false in it. keep that or delete that?
<GrueMaster> Start with "dd bs=72 skip=1 if=boot.scr of=boot.script.
<GrueMaster> Delete it.
<sauerbraten> ok. I'll install wpa tools via chroot and then try it.
<sauerbraten> does anyone know specifics on how good sound support is with the server image?
<GrueMaster> Unsure.  Should be ok.
<GrueMaster> Just no Pulse.
<GrueMaster> But everyhting should work through alsa.
<sauerbraten> no pulse is fine. I want to use it to play music remotely. my room layout doesn't allow to connect the stereo to my notebook, and I'm too greedy to buy one of those fancy usb-bluetooth soundcards
<GrueMaster> heh
<GrueMaster> I used to have something like this setup a while ago (natty iirc).  Can't remember what all I used, but the tools are there if you have the time to make it work.
<ericbutters> what is the login passwd for root on serial console on ubuntu-core 12.10 beta 2?
<GrueMaster> There is none.  It should boot into oem-config and prompt you for info, similar to the desktop.
<ericbutters> i added a getty myself. and i see login prompt on console
<GrueMaster> So log in as the user you created.
<ericbutters> looking into etc/sahdow i see that there should be a passwd
<GrueMaster> Ubuntu doesn't have a root password by default.  It relies on sudo.
<GrueMaster> No, it has a locked invalid passowrd (!).
<GrueMaster> Of course, you can use sudo to edit this and change the password, but it isn't recommended.
<ericbutters> first i need to login
<GrueMaster> Did you run through the oem-config first?  It should have prompted you for user info.
<GrueMaster> What image are you running?
<ericbutters> no. i downloaded from here: http://cdimage.ubuntu.com/ubuntu-core/releases/12.04/release/ and added etc/init/ttySAC1 and added ttySAC1 to etc/securetty.. pls see here: http://pastebin.com/raw.php?i=Rmu0fWQQ
<ericbutters> btw, oit is 12.10 beta 2 (armv7hfp)
<GrueMaster> what platform?  Never heard of ttySAC1
<ericbutters> S5PV210 (samsung) UART1
<GrueMaster> Wait, ubuntu-core?  That isn't an "image".  It is a chroot environment.
<GrueMaster> It is designed to be a minimal base for creating a chroot or rolling your own image.  It doesn't have everything needed for a boot image.
<ericbutters> okay. i see. it try the preinstalled image for ac100
<GrueMaster> See http://wiki.ubuntu.com/Core
<ericbutters> Ubuntu Core delivers a functional user-space environment ..
<ericbutters> with full support for installation of additional software from the Ubuntu repositories, through the use of the apt-get command.
<ericbutters> ?
<GrueMaster> yes.
<GrueMaster> "Ubuntu Core is a minimal rootfs for use in the creation of custom images for specific needs."
<ericbutters> i thought i can use that. it is exacly what i want :) a simple console image to install what i need
<GrueMaster> Well, it isn't quite a console image.  But it is very close.
<ericbutters> and i get a login.. but i can not
<GrueMaster> YOu should be able to edit /etc/shadow and remove the ! from the root password section.  That will give you a blank password.
<ericbutters> so there are only images for specific boards? no general image for armv7?
<GrueMaster> Right.  If you want an image for your system, one solution would be to take a server image and replace the boot partition with your bootloader, kernel, and initrd.
<GrueMaster> Also, I think Linaro may have images for that system.
<ogra_> bug #875222
<GrueMaster> Looks like bugbot is mia.
<GrueMaster> bug 875222
<GrueMaster> yep
<micahg> ubot2: wake up
<ubot2> Factoid 'wake up' not found
<ogra_> heh
<ogra_> i made up that number
<ogra_> to poke it ...
<ogra_> bug 959596
<ubot2> Launchpad bug 959596 in nvidia-graphics-drivers-tegra "Low graphics boot" [Undecided,New] https://launchpad.net/bugs/959596
<ogra_> seems if the number exists it works
<wookey> too clever by half
<ogra_> bug 1029343
<ubot2> Launchpad bug 1029343 in nvidia-graphics-drivers-tegra "X server crash" [Undecided,Confirmed] https://launchpad.net/bugs/1029343
<GrueMaster> ogra_: Do you remember how to get audio working on omap4 server image?  It has been a while for me.
<ogra_> install all bits and run alsaucm set verb Hifi_
<ogra_> or some such
<ogra_> i have never used sound on server :)
<GrueMaster> That's what I thought.  But alsamixer is failing to find a mixer.  Suggesting a driver not configured.
<GrueMaster> Hmmm.  Everyhing in /sys is as it should be.  But no mixer.
<GrueMaster> nvrmind.  Seems to be agroup thing.
#ubuntu-arm 2012-10-12
<ppisati> ogra_: check your mbox
<ogra_> damn, i dont have one
 * ogra_ uses maildir :P
<ppisati> :)
 * XorA opens the gates to the religious mailbox format war
<ppisati> jsalisbury tested Q/omap4 beta and he said the installer doe4sn't show up immediately, he needs to switch tty and back to get the screen
<ppisati> ogra_: ^
<ogra_> hmpf
<ogra_> yeah, i see the mail
<ogra_> i would suspect plymouth
<ppisati> actually since we switched to a live installer we are already running unity dyring the install, right? so the pvr driver, right?
<ppisati> *during
<ogra_> we arent runing unity (ubiquity uses metacity and a simple gtk panel) but yeah. the pvr driver
<ogra_> do we have a bug open for this ?
<ppisati> no, because he just discovered it
<ppisati> i can try daily image and fill a bug if you are too busy
<ogra_> i heard something similar before and was alredy pondering to shipÃ¼ an xorg.conf that forces fbdev during the installation
<ppisati> shall i fill it against... plymouth? pvr?
<ppisati> i'll try this one: http://cdimage.ubuntu.com/daily-live/current/quantal-desktop-armhf+omap4.img
<ogra_> pvr i guess
<ppisati> ogra_: i've a blue screen
<ppisati> ogra_: not smurf, really electric blue :)
<ppisati> and indeed switching fixes it
 * ppisati wonders if we have the same problem after the installation...
<ppisati> ok, ubiquity exploded in my face so i couldn't finish the installation
<LetoThe2nd> oO( *kaboom* )
<xnox> ppisati: did you connect an external usb hard drive or the usb stick as installation target?
<xnox> ppisati: which instructions did you use?
<ppisati> xnox: installing on the sd card actually
<xnox> ppisati: that won't work with 12.10 ;-)
<ppisati> xnox: it did in the past iirc
<xnox> ppisati: unless you pre-partitioned it.
<xnox> ogra_: we need to update installation instructions on the wiki.
<xnox> ogra_: as all the desktop install instructions talk about preinstalled tarballs, instead of live installer =/
<ogra_> xnox, on my list :)
<xnox> ogra_: on your list, yet it's me who gets the bugs assigned =)))))
<ogra_> i'll try to get to it today
<ppisati> lp 1065902
<ubot2> Launchpad bug 1065902 in pvr-omap4 "black/blue screen before installer, tty switches fixes it" [Undecided,New] https://launchpad.net/bugs/1065902
<ppisati> i'm doing a complete installation just to see if everything is ok after
<ppisati> "an unrecoverable error... blablabla.. now a dekstop session will start so you can fix it"
<ppisati> black screen again
<ppisati> tty switch and there it is my desktop session
<ppisati> rsalveti: i'm assigning the pvr part of 1065902 to you
<ppisati> ogra_: you wanna take the plymouth part?
<ogra_> infinity, hrm, the tegra driver ftbfs in dh_slibdeps now ... would you let the package in if i just completely override that step ?
<ogra_> its not like it ever has done anything useful anyway
<ogra_> (apart from moaning about the plugin libs)
<infinity> ogra_: Or, you could tell it where to look for its libraries...
<ogra_> well, it doesnt fail in a local precise build
<ogra_> override_dh_shlibdeps:
<ogra_>         dh_shlibdeps -l${PWD}/debian/nvidia-tegra/usr/lib/nvidia-tegra
<ogra_> something like that ?
<infinity> Indeed.
<infinity> Should shut up all the warnings, and the two errors.
<infinity> Or three, or however many there were.
 * ogra_ tries
<infinity> No need for the ${PWD}/ bit, though, you should always be relative to the package build dir.
<infinity> -ldebian/foo/bar is enough.
<ogra_> well, still warnings about the missing SONAMEs
<ogra_> in the plugin libs
<infinity> Hold on, let me look at this for a sec.
<infinity> Gah, why is that in universe?
<infinity> ogra_: Will your world explode if I move it where it belongs?
<ogra_> not at all
<ogra_> dunno why it landed there
<ogra_> it used to be in restricted
<infinity> It's in universe in precise too, so I guess someone just messed up way back when. :/
<infinity> Oh well, moving it in Q.
<infinity> To multiverse, not restricted.
<ogra_> k
<ogra_> i wonder if dh_shlibdeps got more strict in quantal
<ogra_> i cant reproduce the error at all in precise
 * infinity downloads some build-deps.
<infinity> dpkg-shlibdeps may have gotten stricter, I wouldn't consider that a bad thing.
<ogra_> i didnt say its bad :)
<infinity> Right, -l/usr/lib/nvidia-tegra does the trick (no need for the leading debian/pkg at all)
<ogra_> ah, k
 * ogra_ adds that then 
<infinity> And the mess of warning about the missing SONAMEs seems like a nice reminder that it's broken. :P
 * infinity tests with the override in debian/rules
<infinity> Yup, perfect.
<ogra_> k
<infinity> As "useless" as it may seem, it's nice that it'll yell at you if you don't have the right build-deps (and thus don't get the right dependencies), so taking it out feels wrong.
<infinity> And this DTRT.
<ogra_> yeah
<ogra_> and there is hope they fix it eventually :)
<ogra_> meh, i should teach my finger memory to not always use -sa for dpkg-buildpackage
<infinity> I always forget it when I need it.
<infinity> Which is rarely.
<ogra_> well, you need it for all native packages
<ogra_> we used to have a lot of them when i started :)
<infinity> ogra_: Eh?  No native package needs -sa
<infinity> ogra_: You only need -sa on a new upstream version of a NON-native package (ie: with an orig) that dpkg doesn't auto-detect as a new upstream (so version doesn't have -0 or -1 on the end).
<infinity> ogra_: So, commonly in Ubuntu when doing merges from, say, 1.2.3-4ubuntu1 to 1.2.4-2ubuntu1 instead of 1.2.4-0ubuntu1
<ogra_> yeah, i thought it was also used to attach the native tarball ... seems i was wrong :P
<ogra_> but that would be nonsense thinking about it :P
<xranby> infinity: ogra_:  i would consider it a bug dch -i to not detect and use a  0ubuntu1 name when appropriate
<ogra_> well, it never detects if i work on a native package
<infinity> xranby: Hrm?  This isn't about dch.
<ogra_> but always attaches -XubuntuX
<infinity> xranby: I was talking about merging and intentionally versioning in a way that won't be -0 or -1 (which is common when merging to, say, Debian's 1.2.3-4)
<xranby> infinity: ok i get it
<infinity> ogra_: Really?  I thought dch was smart enough these days to version natively.
<ogra_> doesnt for me
<infinity> ogra_: If not, THAT is a bug for sure.
<xranby> infinity: dch -i always increast the unmber, it never resets the number when the major version differs
<ogra_> well, i might have some old dotfile somewhere with weird settings tr so
<ogra_> *or
<infinity> It sure works for me.
<infinity> I just did a dch -i on apt (0.9.7.5) and got (0.9.7.5ubuntu1)
<infinity> Which is right.
<infinity> xranby: I'm a bit confused as to what you're on about. ;)
<infinity> xranby: Up until just now, we were talking about dpkg-genchanges -sa, which has nothing to do with dch's versioning.
<xranby> we are surely talking about different things,, yesterday i did a dch -i on avian_0.6+20121011   and got 0.6+20121011-0ubuntu2      instead of 0.6+20121011-0ubuntu1  http://bazaar.launchpad.net/~xranby/ubuntu/quantal/avian/avian_0.6+20121011/revision/4#debian/changelog
<xranby> when switching from 0.6+20120911 to 0.6+20121011
<infinity> That was driver error.
<infinity> You did a uupdate or something first, then a dch -i
<infinity> The first thing got the version right, then dch -i did what you asked (increased the version number).
<xranby> no update
<infinity> Then how did you update from 0.6+20120911 to 0.6+20121011?
<infinity> dch doesn't autodetect upstream versions.
<xranby> infinity: i got the new name 0.6+20121011  when i did a bzr branch avian.dev avian_0.6+20121011
<xranby> and dch -i picked up that
<xranby> based on the branch nam
<xranby> e
<infinity> Still sounds like something, somewhere, filled in a skeleton changelog entry first, and dch -i then increased it.
<infinity> (I just did this to myself yesterday..)
<xranby> hmm i have to double check next time i update
<xranby> you might be right it might be one of those things you do without reflecting about it
<xranby> I do
<xranby> not to something completly different: When usability fail: The "mouse wiggler" a "new invention" used at a Swedish hospital to prevent inactivity auto-logout http://www.flickr.com/photos/henrikahlen/sets/72157631580658085/
<xranby> now
<infinity> ogra_: So, after all that pointless prattle, do I get a new upload? ;)
<ogra_> err, yeah
<ogra_> just noticed i missed to s/precise/quantal/ in my build
<ogra_> lets do it without -sa this time :)
<ogra_> bug 1065902
<ubot2> Launchpad bug 1065902 in linux-ti-omap4 "black/blue screen before installer, tty switch fixes it" [Medium,New] https://launchpad.net/bugs/1065902
<nOStahl> hi guys
<nOStahl> whats going on with the ubuntu on android thing?
<nOStahl> the page has not changed on ubuntu.com for a long time since I first seen it
<GrueMaster> Given that unity-2D is dead, probably not much.  Not sure how well Unity runs on an Android system.
<nOStahl> the site says it boots up full ubuntu
<GrueMaster> Well, iirc it is more like an ubuntu chroot running on an android system.  That way, the two can communicate with each other.
<nOStahl> ah ya that makes some sense
<nOStahl> i'd love to have one device that I take with me and dock it in a workstation or in some form of lapop device
<prpplague> GrueMaster: any idea who is in charge of u-boot/SPL for pandaboard at canonical right now? we have some memory change patches in the pipe for the next revision of the OMAP4 based pandaboard
<ogra_> prpplague, jcrigby
<prpplague> ogra_: ok thanks
<ogra_> (unless that changed and i missed it)
<GrueMaster> prpplague: I'm no longer at Canonical.
 * prpplague makes a note
<prpplague> GrueMaster: yea i keep forgetting
<prpplague> GrueMaster: i don't know who is where these days in relationship to canonical/linaro/ubuntu
<GrueMaster> It seems to be changing a bit lately.
<ogra_> we're all ubuntu :)
<ogra_> only few are linaor or canonical :(
<ogra_> err
<ogra_> :)
<prpplague> jcrigby: ping
<prpplague> jcrigby: need to start getting a plan together to handle questions / upgrades for u-boot
<st3fan> i got Ubuntu 12.04 running on a Pandaboard \o/
<st3fan> do i need special drivers now? or is it all included?
<st3fan> also, is there a correct way to upgrade to 12.10?
<ndec> prpplague: for uboot/spl patches please talk with sebjan too.
<ndec> and send them upstream too ;-)
<prpplague> ndec: yea, already working on the upstream, i am more concerned about people trying to use older ubuntu releases for pandaboard and it not working
<ndec> for older release... it will be a problem since the bootloader is in the released image.
<ndec> and new images aren't created after they are released...
<ndec> so, if old uboot reallly doesn't boot on new board, 12.04 image will not boot.
<ndec> and 12.10 either.
<ndec> well, 12.10 there is a slight window to get that done before the release, though...
<prpplague> ndec: yea, there was some update procedure that was documented for the pandaboard-es to update the bootloader , so i figured there would be something we could document
<prpplague> ndec: yea totally different mem config, it won;t boot without the change
<ndec> yep, we did that a couple of times indeed.
<ndec> it's basically -> prepare SD, and copy the magic MLO on SD.
<ndec> prpplague: what's this change about? and why?
<prpplague> ndec: the memory that is currently used on the pandaboard and pandaboard-es is EOL'd as of the end of this month
<prpplague> ndec: we have enough stock to last till mid feb
<ndec> bummer.
<prpplague> ndec: the only available configuration as a replacement is a totally different die/bank configuration
<ndec> you can detect the config at runtime, right?
<ndec> so that same MLO works on new and old, right?
<prpplague> ndec: yes we can detect if it is a new board or old board, however the MLO(SPL) needs to be updated with the new EMIF/LISA configurations
<prpplague> ndec: i thought you were gone for something called "weekend", hehe
<GrueMaster> That sounds like a simple patch to a lookup table, and maybe some init code.  Should be fairly straight-forward.  YOu could always file a bug against MLO and file a patch with it.
<ndec> prpplague: i should be gone indeed...
<prpplague> GrueMaster: yea code wise it is trivial
<prpplague> GrueMaster: my concern is the coming support issue, "i just got my pandaboard and it doesn't boot ubuntu 12.04"
<GrueMaster> Since 12.04 is LTS, this fix should be able to be backported.  Not sure what the release schedule is for 12.04.2, but it will have to wait until then to show up in an image.
<ndec> GrueMaster: that said, images weren't rebuilt for 12.04.01 for panda...
 * ndec really starts weekend now ;-)
<GrueMaster> They weren't?  sigh.  Slackers.
<xnox> GrueMaster: ndec: the images were build, they failed testing hence could not be released.
<xnox> no sign-off, no point release image.
<xnox> image, per-image.
<xnox> but boy 12.10 is so much better on Pandaboards =)
<st3fan> xnox: how do i test 12.10 now? (i see no images)
<xnox> st3fan: they are on cdimage
<xnox> st3fan: http://cdimage.ubuntu.com/daily-live/current/
<xnox> note you need USB storage to finish the install.
<GrueMaster> Failed testing?
<st3fan> xnox: ah yes i think i did try that .. i was unable to install it on SD card and was not sure how to fix that
<st3fan> i'm currently using the preinstalled 12.04, which works great
<xnox> it's slow on the IO though.
<xnox> no more preinstalled images.
<st3fan> yeah i notice that
<xnox> hence you install from sd card onto usb stick or usb HDD
<xnox> with quantal onwards.
<xnox> you can "do preinstall"
<st3fan> aha
<st3fan> i was thinking of buying a small SSD and USB/SATA adapter
<xnox> basically after creating sd card, create a new partition at the end.
 * xnox uses 32 GB tiny pen drive ;-)
<st3fan> is that faster than SD?
<xnox> yeah.
<GrueMaster> Hmm.  Doesn't look like 12.04.1 was even generated, according to http://iso.qa.ubuntu.com
 * xnox has fast usb stick though ;-)
<st3fan> how does a pandaboard boot from usb though? it needs help from a bootloader on SD right?
<GrueMaster> st3fan: Bootloader stays on SD.
<xnox> st3fan: so the sd card you used for the install .... becomes boot floppy as panda only boots from there.
<st3fan> this sounds good :)
<xnox> so you need both to install & both to continue running panda.
<GrueMaster> Well, you could also drop a bootloader through the mini-usb from a host.
<GrueMaster> It actually looks there first, SD second.
<st3fan> do i need to configure the bootloader manually or will that happen as part of the installation?
<GrueMaster> It will (should) just work.
<st3fan> these are great hints. i'm going to try this after dinner with 12.10b2
<GrueMaster> If not, file a bug.  If it doesn't install proeprly, it shouldn't be shipped.
<st3fan> or daily?
<xnox> st3fan: don't try b2, use daily. The current daily is frozen and is the testing candidate for quantal final.
<st3fan> yay
<xnox> st3fan: plus you will help testing quantal final =)
<st3fan> ok
<st3fan> i will bbl
<infinity> xnox: You're misinformed.  12.04.1 ARM images weren't built at all, as we only build point-release images for LTS products, and only the netboot images are LTS for ARM.
<infinity> xnox: Not that it would matter, the 12.04 images would work just fine, and one could apt-get upgrade.
<xnox> infinity: ok. sorry.
<infinity> xnox: Oh, I read more backscroll, I see.  So, the 12.04 images will stop working at some point. :P  But we can still build new d-i (and will), so that's the direction to point people in.
<xnox> thanks.
<infinity> xnox: And d-i is the direction I point people in anyway, since it's the only way to install directly to USB in precise.
<xnox> i point people to quantal =)
<infinity> Some people (like, I dunno, our buildds) have a legitimate use-case for wanting an LTS. :)
<xnox> infinity: for whatever reason people are expecting a much higher volume of SRUs for precise.....
<infinity> I don't mind the attempt to perfect LTSes, personally.
<infinity> Maybe because I run them. :P
<GrueMaster> infinity: I think the reason this came up was due to the expected change to the pandaboard memory, wich will need a new MLO.  If the images aren't respun, then they will fail.  Easy enough to download an updated MLO and drop it in place.
<infinity> GrueMaster: Yeah, I caught that and commented on it.
<infinity> GrueMaster: We still won't respin the preinstalled images, but debian-installer will get bumped for new netboot love.
<infinity> (And, as you say, it's not rocket science to do surgery by hand on the preinstalled ones, if someone really prefers those)
<GrueMaster> I'm...not going to comment.
<infinity> GrueMaster: (If the whole new MLO thing happens, I could probably be talked into building a Panda/preinstalled image for 12.04.2 if someone communityish wanted to QA it)
<infinity> GrueMaster: You could totally get them to send you a new-new-new Panda just for this, and expand your dusty collection. :)
<GrueMaster> When is 12.04.2?
<GrueMaster> And considering I had to personally buy the last 4 pandas I got, I doubt I will be motivated to do this.
<GrueMaster> (note, I could have expensed them, but then I would have 0 dusty pandas and absolutely no reason to be here).
#ubuntu-arm 2012-10-13
<st3fan> xnox: when i go through the setup too quick (..., time zone, account setup) the installer window disappears ... i see some disk activity but i have no idea if it is actually finishing the install
<st3fan> it barely started copying files when the window closed, so it can't be done i'm sure
<st3fan> unfortunately i can't seem to switch to a text based console to check what is happening
 * st3fan will try again and this time will not fill in his account info until the installer is done
<xnox> st3fan: is that with panda image. what timestamp? we are respinning it due to crashing like that....
<st3fan> grabbed it from http://cdimage.ubuntu.com/daily-live/current/ an hour ago
<st3fan> quantal-desktop-armhf+omap4.img       12-Oct-2012 14:39
<st3fan> should i grab an earlier one?
<xnox> you should want the http://cdimage.ubuntu.com/daily-live/20121012.3/quantal-desktop-armhf+omap4.img
<st3fan> downloading
<xnox> current is a symlink =) currently points to 20121012.3
<xnox> st3fan: you can use zsync.
<xnox> if you have the old one around use: $ zsync http://cdimage.ubuntu.com/daily-live/20121012.3/quantal-desktop-armhf+omap4.img.zsync
<st3fan> cool i'll do that next time
<xnox> and it will download the delta =) which should be very small
<xnox> st3fan: if it still fails. please report bug from the panda (if you can) with `ubuntu-bug ubiquity`
<st3fan> ok
<xnox> st3fan: and add a "install result" to http://iso.qa.ubuntu.com/qatracker/milestones/240/builds/25703/testcases
<xnox> the entire disk test case ;-)
<st3fan> the internets are fast today, the download took 4 minutes
<st3fan> dd'ing a diff would be better :)
<st3fan> ok booting
<st3fan> ah yes now i get a little window with a progress bar 'copying files'
<st3fan> xnox: success!
<st3fan> ubuntu 12.10 keeps crashing on the pandaboard :-(
<st3fan> it just hangs, how do i find out what actually happens?
<st3fan> i wonder if this is the network controller .. i think i read something about that in the release notes?
<infinity> st3fan: Are you sure it's hung?  Are you watching on a serial console?
<st3fan> infinity: i don't get much on the serial console .. should i congigure that as a boot parameter to get it going?
#ubuntu-arm 2013-10-07
<joe18> how do i install ubuntu on my nexus 7? the files the installer depends on are no longer where the wiki says they are
<davmor2> joe18: Ubuntu touch for the n7 or the full desktop?
<joe18> full desktop
<davmor2> joe18: it's not worked on now as far as I know ogra_ might be able to help you more
<joe18> wasnt unity supposed to be the one interface for all the devices? what happened to that? why are there 2 interfaces for only one android tablet
<davmor2> joe18: unity8 is the converged code which is the same code doing the same thing with different perspectives based on screen size.  Unity8 is Ubuntu Touch
<joe18> ooohhhhh
<davmor2> joe18: in which case the install you want is https://wiki.ubuntu.com/Touch/Install
<joe18> can i make ubuntu touch not so phone friendly?
<joe18> like ubnutu-(notsomuch)-touch?
<infinity> Other than the lack of GSM radios, there's not much difference between a tablet and phone, really...
<infinity> Have iOS and Android not proven this quite well already?
<davmor2> joe18: How do you mean.  There is no real need to have something more like the desktop version as it just takes up space on the screen that you need.  Is there something specific you need it to  do that it can't?
<joe18> i want ubuntu desktop on my nexus 7. call me crazy. i dont really like the ubuntu touch interface
<joe18> is ubuntu touch still based on cm10?
<ogra_> define "based on"
<joe18> chroot, kernel, no x11 ?
<ogra_> it uses the cm10 kernel, and an ~40M big lxc container where we run a few android daemons to initialize the HW (like the proprietary modem driver and daemon etc)... the reas is a plain straight ubuntu
<ogra_> *rest
<ogra_> and indeed, since the new unity is designed for Mir, no X
<joe18> how much of a plain straight ubuntu? if i wanted too could i apt-get install kubuntu?
<ogra_> it wouldnt run, but indeed you can apt-get install it (after making the OS writable)
<ogra_> (no X ...)
<joe18> can i install X?
<joe18> why isnt OS writable?
<ogra_> because you dont need that on a phone ... apps dont get installed in the OS but in a user specific space (using click packages injstead of debs)
<joe18> does not mobile unity work?
<ogra_> additionally ubuntu touch uses image based updates, that requires that certain parts of the fs do not change
<ogra_> (else you wouldnbt be able to provide image diffs OTA and people would have to download a full image every time)
<joe18> so no kubuntu also means no X11 apps?
<joe18> does?
<joe18> *
<ogra_> right
<Rjs> I've been toying in my mind with the idea of using the ubuntu-nexus7 kernel with e.g. standard debian userland to provide a fully-free code base - it seems that it could be feasible (if you don't need gps or 3d acceleration, which require closed-source binaries, and ignore the non-freeness of the boot loader)
<Rjs> but I haven't had any time to try it out... (especially since I heard that there were difficulties bootstrapping a new filesystem etc. using the bootloader, and there might be complex userland changes that the ubuntu desktop had which I don't know about)
<ogra_> not many ...
<ogra_> ubuntu-defaults-nexus7 should have all modifications
<Rjs> I remember from my testing that the fbdev X11 display driver seemed to work ok (if 3D acceleration isn't needed - I think it was quite a bit faster than the openmoko gta02, for example), and I later heard about someone starting to write a driver called "opentegra", which could be even better (I don't know if anything came of it, haven't looked)
<ogra_> it should be sufficient if you dont need any GLES stuff
<kulve> opentegra might need newer kernel
<ogra_> you might lose the most of one CPU core to it worst case
<ogra_> fbdev should work on all kernels that have a framebuffer device
<ogra_> the only issue is that if you want *any* kind of usable video playback you will need the binary driver and the codecs
<ogra_> if you can live without that fbdev is just fine
<Rjs> ok, so it doesn't sound too difficult after all... (I was actually surprised that so many of the sensors etc. in the nexus7 worked without closed-source software; I think GPS and of course 3d acceleration were the primary exceptions)
<Rjs> maybe the easiest way to install it would be to make a filesystem image (sans kernel) using qemu-arm, configuring it to use fbdev etc. (and to manage without a keyboard), and then try to use the adb stuff from the bootloader to get the kernel and this filesystem image or its contents onto the nexus7 (that's what I think I'd try first, if I had the time...)
<ogra_> why manage without a keyboard ?
<ogra_> if you use the right kernel config you will have a console and should be ablet to attach a keyboard via OTG cable
<Rjs> hmm yes, good idea, that would probably be much easier than trying to do everything with just the touchscreen
<kulve> Rjs: as said, it shouldn't be a problem to get X.Org running with open source only. But it would be slow and crippled. So why would you like to do it? :)
<Rjs> kulve: simply because I don't like to use non-free software :) (and I'm used to using an openmoko gta02, which is much slower but still ok for me - the main problem I have with it is the physically small display)
<Rjs> (and from a more pragmatic point of view, I'm not sure if the stuck-button bug was ever fixed in the non-free world - I didn't really follow it closely, but I think I read that the proprietary driver provided by nvidia required an X.org that was too old to have the bugfix, so at least some backporting would be required)
<kulve> luckily on tegra nvidia provides drivers for multiple X.Org versions, up to 14
<kulve> which I think is used in Saucy
<kulve> I meant the video ABI versions..
<Rjs> ok, good to know (I haven't really followed the proprietary drivers at all)
<kulve> I've been playing with them a bit nexus 7 and Ouya
<c10ud> hi.. this is embarassing but: I need to install hamachi in my NATTY (11.04) armel box and I just found out that mirrors are gone..is there any backup mirror somewhere?
<c10ud> (I need it for damn lsb deps)
<c10ud> wow, maybe found it (!) http://160.26.2.181/
<rbasak> c10ud: http://askubuntu.com/a/91821/7808
<c10ud> rbasak, thanks but that doesn't seem to include the "ports" pool
<c10ud> no wait it does
<c10ud> thanks then! :D
<rbasak> Good point I didn't think of that.
<rbasak> If it does then you're in luck :)
<c10ud> I tried searching for specific armel packages and google didn't bring this up, now I'll try it but I see a Contents-armel file so I think it should work!
 * c10ud trying
<rbasak> http://old-releases.ubuntu.com/ubuntu/dists/natty/main/binary-armel/Release exists
<rbasak> So the line "deb http://old-releases.ubuntu.com/ubuntu natty" should just work I guess. No ubuntu-ports any more then.
<c10ud> this imx53 is slow, probably the SDcard is quite fucked up.. (and it's running armel instead of armhf anyway..) but it definitely seems to be working :)
<c10ud> thanks again rbasak
#ubuntu-arm 2013-10-09
<Vialas> how are you all?
<Vialas> wondering if i can have some support re Raspberry Pi and Cloud 9 IDE
<Vialas> hello Dr_Who
<Vialas> hello, can someone help me out with Cloud 9 IDE
<Vialas> anyone help me?
<rbasak> !anyone | Vialas
<ubot2`> Vialas: A high percentage of the first questions asked in this channel start with "Does anyone/anybody..." Why not ask your next question (the real one) and find out? See also !details, !gq, and !poll.
<rbasak> Vialas: note that the Raspberry Pi isn't supported by Ubuntu, since it's ARMv6 and Ubuntu is built for ARMv7.
<ogra_> this is why we have this informative thing called /topic in this channel ;)
#ubuntu-arm 2013-10-10
<elyezer> I'm using ubuntu on beaglebone black and I have downloaded images from http://www.armhf.com/. I'd like to know if there is some tutorial on how to customise rootfs. I'd like to add some scripts and change default network configuration.
<elyezer> Sorry if it is not the correct channel to ask
<ogra_> shouldnt be different to any other ubuntu
<ogra_> suerspace is all the same on all arches ... what works on ubuntu desktop or server will also work on the bone installation
<ogra_> *userspace
<ogra_> (read, the normal ubuntu documentation will apply, just look on the ubuntu wiki, there are many howtos)
<MiksterX> Hi guys - anyone knows how to create support for TUN? It seems no module is loaded I think...
#ubuntu-arm 2013-10-11
<B13B> anyone here with experience on ubuntu-arm and the nexus 7?
<davmor2> B13B: ask your question and people who might know the answer can respond
<B13B> I'm doing $ fastboot oem unlock from terminal, but it keeps getting stuck on  < waiting for device >
<B13B> my nexus 7 is in fastboot mode, with usb debugging on
<B13B> is there a step I missed?
<infinity> B13B: Does "fastboot devices" list your device?
<ogra_> you might need sudo
<ogra_> (depending if anything ships udev rules for the device or not)
<B13B> ogra_: Sudo worked nicely, thanks!
#ubuntu-arm 2014-10-07
<hvn2> Hi, using a BeagleBoard Rev C4. connected to DVI, I installed this image elinux.org/BeagleBoardUbuntu#Trusty_14.04 but after power on, the screen stays black. What could be wrong ?
<cptylor> hey guys, I'm kinda lost with this pandaboard rev b3... I've seen a lot of people with problems in the late 2013, should the pre-build version be working just fine now?
<cptylor> using the serial output, I see "SDRAM: identified size not same as expected size"
#ubuntu-arm 2014-10-09
<DistroFeud> can i install ubuntu on my android device?
<DistroFeud> cause its got old android and im afraid of security gaps
 * genii makes more coffee
#ubuntu-arm 2014-10-10
<RoyK> hm... how can I resize a filesystem that's mounted?
#ubuntu-arm 2015-10-05
<cadenr> HELOO?!!!!!!!!!!!!!!!!!!!!???????????!!!!!!!!!!!!!!
#ubuntu-arm 2015-10-09
<timothy> hi, is there any semi-official way to have flash on ubuntu arm?
<rpirea> hi
<rpirea> i have been installed ubuntu core 15.04 on my jetson tk1 and idk my password
<rpirea> what password is set by default?
<timothy> ubuntu / ubuntu?
<rpirea> not works
#ubuntu-arm 2015-10-10
<asusc201> Hey, everybody. Looking for a bit of help with chrubuntu/ubuntu on an asusc201 rockchip ARM processor.
<asusc201> I'm having difficulty finding out whether I can install ubuntu on my c201 chromebook.
<asusc201> To clarify, I don't want to use crouton, I want to dual-boot chromeos and ubuntu
<asusc201> ...anybody out there?
<asusc201> !info
 * asusc201 slaps ubuntulog around a bit with a large fishbot
 * asusc201 slaps AceLan around a bit with a large fishbot
#ubuntu-arm 2016-10-12
<Mylon> Is Rasbperry pi ARM or am I in the wrong channel?
<Mylon> The ubuntu pi build isn't working for me.
<lilstevie> Mylon which raspberry pi do you have? the original raspberry pi will not work with Ubuntu because it is ARMv6 and Ubuntu is built for ARMv7
<Mylon> I have the pi3.
<Mylon> I'm using the build linked via raspberrypi's website.
<Mylon> https://developer.ubuntu.com/en/snappy/start/raspberry-pi-2/
<Mylon> I got it to boot using the raspbian image, but I had to SSH in because hdmi didn't work with the default config.txt
<Mylon> Using snappy, no display, no IP address.
<Mylon> Is the network card disabled until the first boot?
<lpotter> the hdmi out is known issue. I thought that had been changed
<Mylon> When I try to boot using ubuntu the Pi flashes 4 long, then 4 short times as an error code.
<Mylon> If I guess the number of dashes is all that matter, that means "sdram not recognized"?
<Mylon> I can't seem to figure out how to get it to work so maybe I'll just use the Raspbian.
#ubuntu-arm 2016-10-15
<Wobbo> Hey all, i am wondering, is there a MATE 16.10?
#ubuntu-arm 2016-10-16
<Wobbo> Hey all, i need help installing Chromium in 16.04. All the help pages to get Chromium working in 15.04.
#ubuntu-arm 2017-10-11
<b_kludged> has anybody loaded ubuntu on beagleboard c4
