#ubuntu-arm 2009-05-18
<Martyn_> quick Q
<persia> ...
<Martyn_> Does jaunty have a "home directory on USB" for users of the live filesystem?
<Martyn_> I seem to remember it did have something like that, but I can't remember for the life of me where the config is...
<persia> kinda.
<Martyn_> to allow a persistent home without install...
<persia> The live environment has a persistent mode, which can be enabled by booting with the right kernel command line.
<persia> The distributed images don't enable this by default.
<Martyn_> enlighten me please...
<Martyn_> I can update the fis configuration on the Babbage then, and it would be useful
<persia> I forget the line, and the location of the documentation, but the easiest way to discover it is probably to use usb-creator to create a USB stick from the desktop iso.
<Martyn_> because it's really not possible to have a babbage boot a full install quite yet
<persia> There's an option in the wizard to set the persistence location, and then you can examine the syslinux configuration to determine the command line (or boot it on something)
<persia> Why isn't it possible to have a babbage boot a full install?
<persia> The live image boot process is *more* complex than the installed image boot process.
<Martyn_> because where can I put the persistent storage?
<Martyn_> -heh-
<persia> Well, it depends on what you do.  Most of the traffic I've seen about it seems to involve using USB drives.
<persia> Same for people playing with the SheevaPlug.
<Martyn_> Yeah, I can do a USB drive I guess.
 * Martyn_ will need to go find one .. I used to have a couple
<persia> The issue I suspect you're encountering is the inability of the kernel to reload the partition table form a device with a mounted partition.
<persia> As a result, any excess partitions that may exist on the install media are unavailable as installation targets.
<persia> Which gets confusing if one has a device that has a (small) preferred boot mechanism, and no secondary boot devices.
<persia> (this leads us back to the discussion on bootloaders, which I don't intend to revisit in full just now :) )
#ubuntu-arm 2009-05-19
<blammo_> hola
<blammo_> q tal
<blammo_> alguien probo instalarlo en algun nokia?
<Martyn> meep
<rubenset> hi
<rubenset> ubuntu army!
<rubenset> xD
<Martyn> army?
<Martyn> *raises eyebrow*
<pwnguin> who leaked my secret project?!
<pwnguin> world domination, foiled again!
<Martyn> Okay, I found the best quote /ever/ on XKCD ... "I licked your daughter's nipples."
#ubuntu-arm 2009-05-20
<bizkut> twitter your favourite artists http://spreadsheets.google.com/pub?key=phtgMLGe8aahYaH0pRs7VHg
#ubuntu-arm 2009-05-21
<sn00kie> If I follow the instructions on: https://wiki.ubuntu.com/ARM/RootfsFromScratch and build a root file system, can I use my own kernel?
<sn00kie>  
#ubuntu-arm 2009-05-22
<sn00kie> If I have a kernel pre-compiled, could I use it with the ubuntu file system and assume it will work?
#ubuntu-arm 2009-05-23
<sn00kie> If I have my own kernel, and I take the ubuntu file system and build it from scratch, will my kernel I've built on my own work giving me ubuntu-mobile?
<sn00kie> If I have my own kernel, and I take the ubuntu file system and build it from scratch, will my kernel I've built on my own work giving me ubuntu-mobile?
#ubuntu-arm 2010-05-24
<sid__> hi anybody there
<sid__> i want to know the exact flow of rootstock script
<sid__> and its functioning
<zyga> good morning
<lool> morning
<neure> hi
<neure> how good is 10.04 on beagleboard?
<amitk> neure: it works fairly well on the C4 board
<DanaG> though, rcn-ee's kernels are better than the official Ubuntu one.
<persia> DanaG: Do we know precisely how?  Is this fixable?
<DanaG> https://bugs.launchpad.net/ubuntu/lucid/+source/linux-ti-omap
<persia> amitk: Do we have an SRU in progress?
<amitk> persia: some of those bugs will be fixed as SRUs, yes
<DanaG> I'm also interested in this: https://blueprints.launchpad.net/ubuntu/+spec/foundations-m-uefi-support
<DanaG> though, it'd be nice to get HP to fix the first-gen elitebooks' broken UEFI.
 * persia looks again, having thought all of them were listed as SRU candidates
<persia> DanaG: That ought drop in fairly smoothly.  EFI already (mostly) works.  The main issue with UEFI is the CDs.
<DanaG> My issue, specifically, is that my firmware seems to claim GraphicsOutputProtocol support... but the framebuffer is at 0x0.
<DanaG> also: http://h30499.www3.hp.com/hpeb/?category.id=business-support
<persia> Ah, that's broken firmware then *)
<DanaG> er
<DanaG> fail.... urls are now dead.
<hrw> morning
<DanaG> Next-gen models are supposedly fixed... but that does me no good. =(
<DanaG> It'll be interesting to see uefi + ARM.
<neure> well i'd like to know what does not work
<neure> "fairly well" is rather meaningless
<amitk> OTG is broken ATM, and DanaG has pointed you to the buglist
<neure> bugs at launchpad? hmm let me see
<neure> my computer is really slow right now though :/
<neure> which package has 7za?
<tmzt> p7zip at one point
<ogra> neure, apt-cache search 7za ;)
<neure> thx
<neure> "Everything is Ok"
<neure> lol
<neure> so comforting
<neure> im on my x86 linux now, how do i figure out what device is my memory card reader?
<hrw> dmesg?
<ogra> or if its formatted it should just automount :)
<ogra> (once you plug an SD in)
<hrw> ogra: depends on system config - my ubuntus do not automount
<ogra> mine does
<ogra> definately in karmic and lucid
<ogra> with the builtin mmc reader as well as with an external USB one
<hrw> [161018.255969] sd 8:0:0:0: [sdi] Assuming drive cache: write through
<hrw> [161018.255973]  sdi: sdi1
<hrw> 10:17 hrw@home:~$ mount|grep sdi
<hrw> 10:17 hrw@home:~$
<ogra> wow, file a bug
<ogra> devkit-disks should definately pick it up
<hrw> ogra: for me it is not a bug but proper behaviour
<ogra> it should only not automount if you added a specific udev rule to omit it
<neure> hmm mine is sdb
<ogra> by default all block devices are supposed to be automounted
 * neure ./setup_sdcard.sh --mmc /dev/sdb --uboot beagle --swap_file 100
<hrw> neure: I have hdds as sda/b/c, one card reader as sdd/e/f/g, pendrive as sdh and second card reader as sdi
<neure> i hope i get this Lucid 10.04 Xfce4 to boot on my C2 beagleboard
<ogra> for a C2 make sure to have a proper power supply attached
<ogra> and a powered hub as well
<neure> check, check
<ogra> it has HW issues wrt USB/power
<neure> keyboard and mouse is in the powered hub
<neure> the mini usb thing, also ethernet is there
<neure> i wonder if i need any specific boot arguments
<hrw> no, just boot
<ogra> beyond that i'd recommend the netinstall image and then install xubuntu-desktop (or xfce )
<ogra> https://wiki.ubuntu.com/ARM/Beagle
<neure> would that be somehow better?
<ogra> its tested and supported :)
<neure> ok i'll go that instead then
 * ogra just closed a bunch of bugs as invalid from people that use their own kernels
<hrw> 10 years ago my desktop had 128MB ram and it was enough for gnome1. today with beagleboard/256MB ram it is hard to fit something
<ogra> 640k is enough for everyone !!
<neure> why is the netinstall image half a gig?)
<amitk> hrw: that's called progress
<ogra> neure, the netinstall image isnt half a gig
<hrw> neure: its SD card image
<hrw> neure: lot of empty space inside
<ogra> neure, dont mix up netinstall with netbook :)
<ogra> netinstall is about 10MB
<neure> "Download installation software" Download the ubuntu-10.04-netbook-armel+omap.img image file from ...
<hrw> amitk: add >logger "autogetty: $GETTY_ARGS"< to /etc/init/autogetty.conf and restart. then tell what was in syslog
<neure> that is the first thing on https://wiki.ubuntu.com/ARM/BeagleNetbookInstall
<neure> and that image is half a gig
<ogra> https://wiki.ubuntu.com/ARM/BeagleNetInstall
<ogra> you are looking at the wrong one
<neure> oh
<ogra> the netbook image contains the whole netbook release :)
<ogra> which gets you what the screenshot at https://wiki.ubuntu.com/ARM/Beagle shows
<ogra> (only tested on beagle C4 though, not sure it works on a C2)
<hrw> I got netbook installed on C3
<hrw> not that I would suggest using it
<ogra> does C2 have 256M ?
 * ogra thought that was still 128
<ogra> netbook definately needs 256
<ogra> (and a lot of swap)
<ogra> hrw, yeah, netbook was mainly thought as a base for the upcoming panda/blaze images in maverick ... probably also good to demo whats possible but surely not for daily use
<hrw> Cx have 256MB
<hrw> Ax/Bx were 128MB
<ogra> right, i wasnt sure if there wasnt some overlap
<hrw> there was cpu overlap
<hrw> B7 got newer silicon
<hrw> C4 got even newer one
<ogra> ah
<ogra> cooloney, so i was trying to build touchbook kernels on my blaze over the weekend ... seems there are still some issues, usually make uImage works fine but in make modules i then get bus errors (or the other way round if i build modules first on the second run when using make uImage i get the same)
<amitk> ogra: I thought the only problem with touchbook was the display resolution?
<ogra> i was using make -j2 so it might be a heat problem or it might trigger the same issue we see with git clone, not sure
<ogra> amitk, nope, there are DSS2 patches (that break all other boards) that arent in our tree
<ogra> i finally found a 2.6.32 tree to build that actually has all patches i need, but now my touchbook seems ot have power issues
<ogra> so i didnt get very far yet but seeing a tty on console
<ogra> somehow the battery doesnt charge ... i wonder if the power supply has issues with 220v (even though the printed specs disagree)
<ogra> it shuts down after a minute or two
<hrw> ogra: OE 2.6.32 works on TB iirc
<ogra> hrw, i dont use OE, i want a plain kernel tree
<ogra> so i can diff patches against the ubuntu tree
<XorA> ogra: my 4430 SDP hard locks on occasion, but this is the sort of thing we expect with ES1.0 hardware :-D
<ogra> but anyway the TB patches are to intrusive
<ogra> we would need a standalone kernel for it i guess
<ogra> (which i'm fine to provide from people.u.c once i have one that works though)
<ogra> (as unsupported build indeed :) )
<cooloney> ogra: what's touchbook kernel? i have no idea about that. -:/
<ogra> cooloney, its just a kernel
<ogra> cooloney, the point is thet the blaze kernel misbehaves when i try to build a kernel with it
<ogra> it either overheats or exposes the same issue we see with git
<ogra> its fine after i reboot the blaze
<cooloney> ogra: so what's the difference between blaze kernel and touchbook kernel?
<ogra> cooloney, forget about the touchbook kernel
<ogra> my point is that building soemthing heavyweight on the blaze with -j2 makes it die at some point
<ogra> gcc spills out bus errors after 1-2h of building
<cooloney> ogra: ok, terrible.
<ogra> which are gone after a reboot
<cooloney> bus errors
<ogra> we need to talk to nicolas
<ogra> but its a bank holiday across most of europe today
<cooloney> ogra: right, maybe they did similar test on blaze
<ogra> so it has to wait until tomorrow
<cooloney> ogra: ok, understand
<ogra> just wanted to notify you that there is some issue
<ogra> and a kernel is the heaviest i can build atm ... thats why i took a touchbook kernel
<ogra> (i didnt like to build OO.o :P )
<cooloney> ogra: ok, so if ~test6 works on your hardware,
<cooloney> i am going to ask merge the kernel as a branch in lucid
<ogra> ok
<cooloney> and upload it to PPA
<ogra> i'm still running test5
<ogra> what changed ?
<cooloney> oh, i went throught the email from Sebastein
<ogra> ah
<cooloney> and built-in SysLink driver which will cause linking error before
<cooloney> and rebased to omap4 latest kernel from omapzoom
<cooloney> they updated some wifi MMC things in their kernel
<ogra> ok
<cooloney> so mostly are not big change since ~test5
<cooloney> and ogra, before I upload it to PPA, need i solve the ABI dump and modules list issue in kernel?
<ogra> well, you discuss some SMP related option there
<cooloney> oh, that KGDB,
<ogra> i guess for the first upload you need to disable the abi and module checks
<ogra> amitk will know though
<cooloney> they did not implement a function for KGDB in SMP
<ogra> cooloney, since my building fails with -j2 it might be related
<cooloney> so we have to disable KGDB in our kernel
<ogra> i havent tried without -j2 though
<cooloney> ogra: so -j1 works fine in your blaze?
<cooloney> ok
<amitk> cooloney: for first upload, just ignore the abi and modules list (see wiki)
<ogra> havent tried yet, building a kernel with -j1 will take ages :)
<cooloney> ogra: ok, IC, heh
<cooloney> amitk: thx, i failed to find the wiki about that.
<cooloney> amitk: where is it?
<ogra_> whoops
<amitk> cooloney: see the first few omap uploads in lucid, there is a ignore and modules.ignore file in the  abi dir
<ogra_> -j2 finishes building uImage in 45min ... i think -j1 will take 3h or more :)
<cooloney> amitk: so i just touch those 2 files and upload the kernel source.
<ogra> hmm ?? where does that underscore guy come from
<ogra> weird, i have two xchats running but see only one on the desktop
<amitk> cooloney: each of those files should contain a single line with '1' in it.
<cooloney> amitk: thanks, i understand. so for uploading, the page in our ppa is quite simple.
<cooloney> amitk: 'dput <source.changes>' what does that mean?
<ogra> use the .changes file for uploading with dput
<amitk> cooloney: https://wiki.ubuntu.com/KernelTeam/KernelMaintenance (seearch for ignore)
<amitk> cooloney: you have to build the kernel (debuild) and upload the resulting .changes files to PPA
<ogra> cooloney, you need to generate a debian source package (which generates <packagename-version>_source.changes) and then upload the .changes file (it pulls the other bits of the source package with it)
<cooloney> ah, got it. so how to generate a debian source package for kernel?
<ogra> either using "dpkg-buildpackage -S -sa" or debuaild -S in the source tree
<ogra> *debuild
<ogra> make sure to have your gpg key set up right before doing that, you need to sign the package
<cooloney> ogra: thx, will try soon
<ogra> (debuild/dpkg-buildpackage will automatically ask for your passphrase and do everything for you)
<cooloney> ogra: it is so smart now, much easier in lucid than before
<ogra> building packages ?
<ogra> that has always been like that :)
<ogra> (cant speak for the kernel though, not sure that was different before lucid, but i dont think so)
<cooloney> ogra: need i use root or fackroot?
<ogra> fakeroot is ok, but you shouldnt even need that for building a source package
<ogra> err ... hmm, you might
<ogra> use fakeroot :)
<ogra> never use root for building packages
<hrw> ogra: you should like this: http://hrw.pastebin.com/aR3VSxJS
<ogra> hrw, great !
<ogra> hrw, how about dropping all the if/then ? :)
<ogra> [ -z $BITS ] && BITS=8
<ogra> works the same way and is more readable
<hrw> I like if/then/fi more
<ogra> (makes no difference execution wise)
<hrw> ogra: I prefer programing languages then shell ones so if/then/fi
<ogra> hrw, will you put that into initramfs-tools by default ?
 * ogra votes for it 
<hrw> ogra: asac did put it in some package already
<hrw> ogra: so ask him
<ogra> oh, /bin/autologinroot wont work in initramfs-tools
<ogra> hrm
<ogra> hrw, i want that function in ubuntu proper too
<ogra> but /bin/autologinroot will make that impossible
<hrw> ogra: I think that /etc/default/autogetty can solve that
<ogra> you mean by just checking for a variable ? yeah, that would help
<ogra> asac, where do you plan to put that script ?
<ogra> (it wasnt uploadedd to maverick apparently)
<hrw> ogra: http://hrw.pastebin.com/LtbQBMa0
<hrw> ogra: I think that so far it landed in newcore package
<ogra> right, i'd like to have that function in maverick (and i'd like to use it for 10.07)
<ogra> why do you set line 17 ?
<ogra> if AUTOGETTY_ARGS="-n -l /bin/autologinroot" is in /etc/default/autogetty that should be fine
<hrw> cause I am testing it on system where I do not want to create such one
<ogra> ah
<ogra> well, for having it in maverick it would have to not use autogetty by default
<ogra> so you need the eaxct opposite here :/
<hrw> ogra: or add "START=yes/no" in /etc/default/autogetty
<ogra> right, something like that
<ogra> though that would even require to have the autogetty binary in the main distro
<ogra> i would propose to just source the default file if it exists, put your stuff into the distro and for your project just have a package that creates the file
<ogra> i.e. an autogetty package that ships binary and /etc/default/autogetty
<ogra> that way the distro can have serail gettys automatically without using root access on them by default
<hrw> ok, will discuss with asac
<ogra> cool, thanks :)
<ogra> i guess he's off today as well
<ogra> and i'll go enjoying a bit of my free day too now ... back later
<hrw> national holiday?
<ogra_cmpc> yes whit monday
<hrw> I need to readd US/UK/FR national holidays to calendar
<amitk> ogra_cmpc: curious, .fi has a WhitSunday
<ogra_cmpc> amitk, we have that too
<ogra_cmpc> its both days in .de
<kblin> amitk: what's the point on having sunday off? ;)
<hrw> kblin: if you work in supermarket then it matters
<kblin> hrw: not in .de
<hrw> kblin: but in .pl yes
<kblin> at least in my state supermarkets aren't allowed to open on sundays
<hrw> kblin: basically if you work in businnes which is open 7 days a week then sundayOff matters
<ogra_cmpc> same here
<kblin> which is funny, given how much more religious the polish people are in general
<hrw> in Poland supermarkets can be open on sundays and I even like it.
<hrw> during week I do not have a time to go and make big shopping
<kblin> well, people tried to do that in .de as well, but unions and churches lobbied against it
<kblin> so if you have a gas station with an attached supermarket you can open on sunday, but if you're a normal supermarket you can't
<kblin> obviously god likes gas stations ;)
<ogra_cmpc> heh
 * ogra_cmpc just found out why his touchbook batteries didnt charge
<ogra_cmpc> apparetnly you can only charge it while its running
<hrw> common problem with cheap hardware
<amitk> ogra_cmpc: I'm guessing they have a driver to do charging then?
<ogra_cmpc> apparently
<ogra_cmpc> i wish the NIC would work :(
<XorA> quit complaining, at least you have one to play with :-D
<hrw> ok, lets plug some dongles and report bugs against linux-omap-ti
<lool> linux-ti-omap
<hrw> right - have it open in browser
<hrw> test1: rt2570
<lool> ogra_cmpc: Yes, on N900 the phone actually boots in a special mode when charging the batteires
<ogra_cmpc> well, its supposed to be a rt2879
<ogra_cmpc> err
<ogra_cmpc> 2870
<hrw> ogra: no, I have rt2570 and rt3072 here
<ogra_cmpc> loading the shipped module in OE doesnt get me a device
<hrw> ah
<ogra_cmpc> and plugging the device into an x86 system also only gets me errors in dmesg
<ogra_cmpc> i suspect the HW is dead
<hrw> let me check
<ogra_cmpc> plugging in my zd1211rw NIC makes the system shut down ... i guess i need to charge some more hours
<hrw> ok, got same in desktop. shit... it was working
<hrw> 6â¬ turned to dust
<ogra_cmpc> sadly OE only ships that single one USB wlan NIC driver :(
<hrw> will check under maverick kernel later (on desktop)
<ogra_cmpc> so even if it wouldnt shut down, my zd1211rw wouldnt work :(
<ogra_cmpc> without network its a pretty useless thing ...
 * amitk boots a 2.6.34 maverick kernel on the beagle
 * ogra_cmpc is envious
<hrw> amitk: share
<ogra_cmpc> will surely be in the archive soon
<hrw> cool
<hrw> rt3072 under lucid/desktop suxx
<ogra_cmpc> geez
<neure> erm
<neure> i cant get ARM/BeagleNetInstall to work
 * ogra_cmpc reads the AI FAQ
<neure> fatload mmc 0 0x82000000 boot.scr says 227 bytes read
<neure> source 0x82000000 says Unknown command 'source'
<ogra_cmpc> "My batteries does not seem to charge ..."
<ogra_cmpc> "With a voltmeter, check the voltage of pin 7 of the battery connector"
<ogra_cmpc> oh my
<ogra_cmpc> neure, ouch, your u-boot is to old i guess
<ogra_cmpc> neure, open the boot.scr file in vi on your desktop and type in the lines manually
<ogra_cmpc> ugh
<ogra_cmpc> "Your wifi dongle may not work. Try to plug it into another USB port an wait a minute: the LED should blink. If not, please reinstall your OS"
<amitk> hrw: display is broken, dss2 patch was merged only after 2.6.34, cherry-picking now...
<ogra_cmpc> reinstall your OS, yah
<persia> Oh my.  That:s not a good recommedation.
<ogra_cmpc> persia, the AI FAQ is full of that stuff
<ogra_cmpc> grab your voltmeter ... reinstall your OS
<persia> Right.  Need to get those folk off email and in here and then everything should work
<ogra_cmpc> hahah
<ogra_cmpc> There seems to be something loose in my bottom part
<ogra_cmpc> You might have a loose counterweight: you can easily re-glue it by un-mounting your bottom part
<neure> ogra, could you pastebin that http://ports.ubuntu.com/ubuntu-ports/dists/lucid/main/installer-armel/current/images/omap/netboot/omap/boot.scr somewhere for me?
<neure> i cant seem to see it properly in windows :/
<neure> hmm i think i can read this somehow..
<ogra_cmpc> fatload mmc 0:1 0x80000000 uImage
<ogra_cmpc> fatload mmc 0:1 0x82000000 uInitrd
<ogra_cmpc> setenv bootargs vram=12M omapfb.mode=dvi:1280x720MR-16@60
<ogra_cmpc> bootm 0x80000000 0x82000000
<neurre> :/
<amitk> ogra_cmpc: what do you think about a feature in flash-kernel where it can flash to a different area in flash, so that if the new/test kernel is broken, I can stop uboot autobooting and point it to the alternate (old) address for a working kernel
<ogra_cmpc> amitk, planned for maverick already
 * amitk ^5s ogra_cmpc 
<ogra_cmpc> amitk, since we will provide preinstalled SD images its no prob to keep a uImage.bak in place in the vfat partition
<persia> amitk: Mind you, if you implement it first/faster, that's lovely :)
<neurre> i still cant get keyboard work :/
<ogra_cmpc> we wont use NAND in maverick (since most OMAP4 devicdes we'll suppport dont have NAND)
<persia> Rather, we won't use NAND for any images, or by default.  No reason we can't have support there.
 * amitk better figure out why mmc isn't working in the 2.6.34 kernel then :)
<persia> In fact, that makes it significantly easier to do other stuff later.
<ogra_cmpc> we wont use NAND at all in flash-kernel with the new images
<amitk> neurre: are you connected via your usb-hub to the ehci port of beagle?
<neure> if netinstall fails, what is the next best option
<persia> SD install
<neure> url?
<amitk> neure: what reason for the failure?
<neure> amitk, when i boot the netinstall image on my C2 beagle, usb does not seem to work
<neure> usb works when i boot to Ã¥ngstrÃ¶m
<neure> this is powered usb hub on miniusb
<neure> so im stuck at the language selection screen in the beginnin
<neure> amitk, any suggestions?
<persia> neure: Do you want GTK, Qt, or server?
<amitk> neurre: is your keyboard connected via your usb-hub to the ehci port of beagle?
<neure> persia, i just want X
<neure> amitk, usb-hub
<neure> powered usb hub
<amitk> neure: where is the usb hub connected?
<persia> neure: OK.  For SD install, we have two images that have X, one with GTK and one with Qt.
<amitk> to the ehci port or the smaller otg port?
<neure> amitk, the smaller usb connector on the board
<neure> smaller one
<neure> the normal looking usb port has nothing in it
<amitk> neure: that is broken ATM, see bug list
<neure> amitk, so, what should i do?
<amitk> neure: if you can fix it, I'll take patches. Otherwise, you'll have to wait while we fix that bug.
<neure> persia, which one has less space wasted?)
<neure> can i use preinstalled images?
<persia> neure: They're about the same size: you can look at manifests at http://releases.ubuntu.com/lucid/ or http://cdimage.ubuntu.com/kubuntu-netbook/ports/releases/lucid/release/
<neure> i hate those huge borders in Ã¥ngstrÃ¶m enlightenment
<ogra_cmpc> neure, you should use the netinstall image but using the OTG port wont work, use a powered hub on the big USB port
<neure> persia, i was talking about wasted screen pixels :)
<persia> There are no preinstalled images available.
<neure> ah
<amitk> ogra_cmpc: the B2 boards don't have the ehci port populated, I believe. So he is out of luck
<neure> so if i'd use usb hub on normal usb, it'd work?
<persia> I think the Qt interface scales better, but it requires 2D accelleration to be acceptable.  The GTK interface breaks down at less than 1024x600, but works with no accel
<neure> i have C2
<neure> not B2
<ogra_cmpc> neure, and a proper power supply on the board itself since the C2/3 have HW issuess otherwise
<neure> i have proper power supply
<ogra_cmpc> ok
<ogra_cmpc> then just plug your powered hub into the big USB port and it should just work
<ogra_cmpc> the OTG port is not supported in the lucid kernel as amitk said above
<persia> The port is entirely unsupported, or it fails to work in one or the other mode?
<ogra_cmpc> entirely unsupported with that kernel version
<persia> Ugh.  That's awkward.
<neure> i had to take one usb hub from my computer
<neure> i had two in a chain
<hrw> ok, I will not fight with ogra or amitk but OTG works in lucid 10.04 kernel on C3 BB
<neure> this usb hub is bigger than the beagleboard itself :D
<neure> it's HUGE
<persia> hrw: Maybe different chip revs?
<neure> great, now that i moved usb serial thing to new usb port.. it's now COM6 :D
<hrw> neure: my desktop has 7 serials out-of-box
<amitk> hrw: Are you sure you run the ubuntu kernel? CONFIG_USB_MUSB_OTG is disabled on it...
<neure> hrw, my "desktop" is macbook running windows xp with.. 2 usb ports :D
<neure> now, i did not get that error
<neure> lets see if keyboard will work ..
<neure> yes
<neure> \o/
<hrw> amitk: fun... I could swear that I installed on otg
<XorA> hrw: switch in Angstrom kernel, do install :-D
<neure> netinstall proceeds :)
<amitk> lunch-time
<hrw> XorA: I have ubuntu installed
<hrw> XorA: 0.22uF capacitor hack helps
<hrw> amitk: smacznego
<XorA> hrw: my usb died completely, but I have Lucid on my omap4430
<amitk> hrw: thanks!
<XorA> which is the worlds hugest board
<amitk> XorA: is that the OMAP4 SDP?
<XorA> amitk: yes
<XorA> amitk: took my rootstocked image and used custom kernel
<neure> erm
<neure> it doesnt detect my network :/
<neure> i get a redscreen during netinstall coz my network is not detected :/
<neure> :(
<ogra_cmpc> might be that we are missing some drivers here
<ogra_cmpc> a) file a bug with the exact description of your NIC so we can fix it in maverick, b) use the server image
<neure> its some logilink usb 2.0 to fast ethernet thing i have
<ogra_cmpc> (or the netbook one)
<persia> Will the server image help?  I thought it was the same initramfs as the netinstall image.
<ogra_cmpc> it doesnt neet network :)
<neure> it was in the beagleboard box
<persia> Or do you mean: perform the install without network, get network working, install X.
<neure> ok where do i get server image?
<ogra_cmpc> network works fine once the kernel is installed
<ogra_cmpc> there are issues with the udeb
<ogra_cmpc> neure, same wikipage
<neure> i rebooted..
<ogra_cmpc> neure, note though that you need a usb disk/key to install to
<neure> got one
<persia> Um, the lucid server image seems to have gone missing, unfortunately :(
<ogra_cmpc> netinst is the only one that can diretly install to the SD you booted from
<neure> so what, there is no server image?
<persia> No.  Just odd URL: http://cdimage.ubuntu.com/ports/releases/lucid/release/
<neure> so now what?-|
<neure> thx!
<neure> will try that now
 * persia was expecting http://cdimage.ubuntu.com/ubuntu-server/ports/releases/lucid/release/
<neure> erm
<neure> which image?
<persia> Texas Instruments OMAP server install image
<ogra_cmpc> http://cdimage.ubuntu.com/ports/releases/lucid/release/
<neure> armel+omap
<ogra_cmpc> right
<ogra_cmpc> nothing odd about that url
<neure> so once i have that .img.. what do i do with it?
 * hrw -> lucnh
<ogra_cmpc> dd it to the SD card
<neure> device?
<ogra_cmpc> ?
<neure> dd to /dev/sdb ?
<ogra_cmpc> if sdb is your sd card, yes
<persia> Depends on how your SD is mapped, really.
<neure> and why would i need usb stick?
<ogra_cmpc> to install to
<ogra_cmpc> the img is an installer image
<neure> and thats the destination where it will be running?)
<ogra_cmpc> right
<neure> so i wont need sdcard after?
<neure> it well keep booting from the usb key?
<ogra_cmpc> it will start from NAND and boot the OS from USB, right
<neure> not exactly ideal
<neure> is there any other way?
<ogra_cmpc> only wiht the netinstall, that will boot from NAND and then be able to run the OS from SD
<ogra_cmpc> but you will need a different NIC for it apparetnly
<neure> :/
<neure> would be great to have install from usbkey
<ogra_cmpc> all will get better in maverick with the preinstalled images :)
<ogra_cmpc> they will just run from SD directly
<ogra_cmpc> so your thrid option would be to wait 6 months *g*
<neure> this is AU0025C
<persia> neure: The main blocker to install-from-USB is the lack of support for it on the hardware.
<neure> really?
<persia> neure: if you want to play, and you have NAND, you can try to put the bootloader in NAND, and then have that boot from USB, but it might be tricky.
<ogra_cmpc> well, thats what we currently do post install
<persia> Yeah, the ROM in the processor on that chip can only load the bootloader from MMC or NAND.
<ogra_cmpc> but pre-install you have to rely on the possibilities the HW offers
<persia> ogra_cmpc: I thought it was still bootloader-on-MMC postinstall: glad to hear it's not.
<ogra_cmpc> nah, we have kernel and initrd in NAND
<ogra_cmpc> so we can boot off whatever device we want
<persia> Well, no.
<ogra_cmpc> we could even do bluetooth NFS
<ogra_cmpc> :)
<persia> When you put kernel and initrd in NAND, you mostly boot off NAND.
<ogra_cmpc> but your rootfs can live wherever you want
<persia> The location of root is completely arbitrary, but that's mounted post-boot
<persia> Right.
<ogra_cmpc> right
 * persia is quibbling about nomenclature and semantics, but likes that NAND is used
<ogra_cmpc> well, not anymore after lucid
<neure> where should i file the bug report about the missing driver?
<neure> http://www.itbank.us/Logilink+UA0025C/
<neure> thats the device i have
<ogra_cmpc> neure, launchpad against linux-ti-omap
<ogra_cmpc> mention that its missing in the udeb package
<persia> neure: Best if you can run `ubuntu-bug linux-ti-omap` from the board, with the nonfunctional device attached.
<ogra_cmpc> haha
<ogra_cmpc> without network :P
<persia> Sure.
<persia> the way it works is that it prepares a report, and then, if you don't have X, gives instructions for getting that offline and filing the bug.
<ogra_cmpc> sure
<neure> well
<ogra_cmpc> its easier to do it via the web interface though
<neure> first i would need to INSTALL :)
<persia> So you copy the files containing the report details, and then do something like apport-submit (I forget: instructions for the process are part of the process), which submits the right stuff.
<ogra_cmpc> for a simple omission in the udeb at least
<persia> But less complete :)
<persia> Anyway.
<ogra_cmpc> we only need info about the NIC
<ogra_cmpc> and we most likely have the module in the std kernel package
<ogra_cmpc> its just about making sure it ends up in the udeb
<neure> lsusb in vmware says Bus 001 Device 002: ID 9710:7830 MosChip Semiconductor MCS7830 Ethernet
<neure> is that sufficient?
<ogra_cmpc> yeah
<ogra_cmpc> moschip only has one driver
<neure> url for filing a bug?
<ogra_cmpc> launchpad
<neure> and its not included?
<ogra_cmpc> it isnt in the udeb package which the installer uses
<ogra_cmpc> it is the the actual kernel after installation
<neure> i should first search if it is already registered as a bug?
<neure> https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap/+bug/584920
<ubot2> Launchpad bug 584920 in linux-ti-omap (Ubuntu) "netinstall fails, it has no network driver for moschip (affects: 1)" [Undecided,New]
<neure> there
<ogra_cmpc> ah, great
<neure> since this was in the beagleboard box that we bought, i would expect there are other ppl with the same adapter
<neure> unfortunately it also comes with the
<neure> otg usb hub :/
<ogra_cmpc> in maverick everything will be better
<ogra_cmpc> we only had three weeks to build the lucid image
<neure> well i need this working today :)
<ogra_cmpc> it will work after install
<neure> well i will endup running it from the usb stick :D
<ogra_cmpc> just use the server image and it will be fine after installation
<ogra_cmpc> yeas
<neure> i just had sdcard bought for me
<neure> now i need to tell 'oops i need usb stick too' :D
<neure> but hmm
<neure> i could get even bigger usb stick?)
<ogra_cmpc> you can even use a real USB HDD
<neure> cool
<neure> looks like i can actually get a real usb hdd
<neure> is that possibly more performant than the sdcard?
<rcn-ee> depending on the usb hdd.. Yes. ;)
<kblin> it also won't wear out as fast
<neure> well
<neure> turns out i only got usb stick :/
<neure> well, more portable
<xorAxAx> are there NEON mplayer/ffmpeg packages for ubuntu lucid?
<kblin> so what I use is an sdcard for the system an put all the bigger data on /data
<kblin> which is, depending on the system either a usb stick, a usb hdd or a cifs network mount
<neure> ah, ok
<neure> so i can add that later, yeah
<neure> half way downloading network image
<neure> i mean server image
<neure> how does that dd work anyway?
<neure> my sdcard is 16gig
<neure> i can safely dd anything smaller that that to it?
<ogra_cmpc> yeas
<neure> just dd img -of=/dev/sdb or do i need something more?
<ogra_cmpc> dd if=/path/to/img of=/dev/sdb
<ogra_cmpc> (with sudo)
<neure> this is going to take a while ...
<neure> only 10 minutes :)
<neure> so..
<neure> how do i boot from this image?
<neure> mmcinit - init mmc card
<neure> ** Unable to use mmc 0:1 for fatload **
<neure> got ut
<neure> erm
<neure> the installer seems to hang
<neure> [!] Partition dsiks
<neure> Installation medium on /dev/mmcblk0p1
<neure> i dont seem to be able to get past that dialog
<ogra_cmpc> no, you want to use the usb disk
<neure> as installation medium?
<ogra_cmpc> asw target device
<neure> yeah but i cant get rid of this dialog
<neure> installer gets stuck there
<ogra_cmpc> it doesnt here
<ogra_cmpc> you should just be able to hit enter there
<neure> well i do, nothing happens
<ogra_cmpc> and then get to the partitioner
<ogra_cmpc> thats before the paritioner ?
<ogra_cmpc> (before it asks you to select a device for paritioning?)
<neure> yes
<neure> before
<ogra_cmpc> strange
<ogra_cmpc> and you are sure you have the USB key attached already ?
<neure> yes
<ogra_cmpc> it should really just tell you that mmc isnt a valid media to install to
<ogra_cmpc> thats what happens on mz B3 and C4 at least
<Martyn> morning
<neure> detecting disks...
<Martyn> ogra : do you think the 2.6.35 merge window will last as long as Jun 1?
<neure> starting up the partitioner
<neure> then i get this dialog
<neure> oh
<neure> now it worked
<neure> on second boot
<neure> what should i select?
<neure> guided - use entire disc?
<ogra_cmpc> yeah
<neure> its 16GB kingston usb stick
<neure> Failed to create a file system
<ogra_cmpc> ugh
<ogra_cmpc> Martyn, no idea, ask the kernel team
<Martyn> which image is neure using, on which hardware, out of curiosity?
<neure> The ext4 file system creation in partition #1 of /dev/sda failed.
<amitk> Martyn: doubtful, Linus should release the -rc1 this week IMO
<neure> beagleboard C2
<xorAxAx> ogra_cmpc: can i use the versatile kernel to run the netinstall of the beagle initrd in qemu and then copy the resulting image file to an sd card?
<neure> image is ubuntu-10.04-server-armel+omap.img
<xorAxAx> (because i dont have an usb-ethernet card)
<ogra_cmpc> xorAxAx, well, you wont have a kernel in the target and your NAND wont be set up right
<neure> and when i get that red screen, keyboard no longer works
<Martyn> amit : damnit... i need one more week to get the mach-sstone patch ready
<ogra_cmpc> for creating a rootfs you can for sure use qemu netinstall
<xorAxAx> ogra_cmpc: can i somehow manually execute those steps?
<ogra_cmpc> neure, but your hub is powered, right ?
<amitk> Martyn: you're assuming that the patches will be accepted in the first submission...
<neure> yes
<neure> it is powered
<Martyn> amitk : yes, i know
<ogra_cmpc> xorAxAx, for setting up the nand and kernel ? thats a bit tricky ... but you can look into the source of flash-kernel what it does for the beagle
<ogra_cmpc> xorAxAx, you should be able to use the netbook or the server image (at least thats properly tested on C3 and C4 beagles, looking at neure the C2 seems to have issues)
<ogra_cmpc> both dont need networking
<xorAxAx> ogra_cmpc: but i want to install to the sd card
<xorAxAx> ogra_cmpc: why isnt that possible using the server image?
<ogra_cmpc> because the installer runs from the SD
<ogra_cmpc> its not capable to install to the media it runs from
<neure> silly limitation
<ogra_cmpc> the netinst image copies the 10MB installer to ram after booting and doesnt need the SD afterwards ... the server install has all the packages on the SD
<ogra_cmpc> neure, well, add a gig of ram to your beagle and i can overcome that :P
<ogra_cmpc> if you have a whole package archive on the SD that needs to live somewhere
<neure> couldnt you use usb stick as a temp file system during installation or something like that?
<xorAxAx> ogra_cmpc: can i run the server installer from an usb stick?
<ogra_cmpc> we could copy it to ram as the netinst installer does but that would require at least the amount of ram the SD carries as packages
<neure> and why not usb stick?
<neure> you could install the installer to usb first :)
<ogra_cmpc> xorAxAx, with some tricks you should be able to have the archive on usb, but dont ask me how
<ogra_cmpc> should be described in the debian installer docs somewhere
<ogra_cmpc> neure, because beagle cant boot from USb
<ogra_cmpc> we had that discussion before
<neure> ogra, it doesnt need to boot from there
<ogra_cmpc> for the installer it does
<neure> really?
<ogra_cmpc> the installer is the initrd
<ogra_cmpc> in case of debian-installer images (server and netinst)
<ogra_cmpc> so uImage and initrd need to come from SD
<ogra_cmpc> at least with this HW
<neure> but once loaded they dont need the sdcard
<lool> hrw: I've renamed the wiki page with the arm-m-cross-compilers spec to CrossCompilers instead of CrossCompilation
<lool> hrw: https://wiki.ubuntu.com/Specs/M/ARMCrossCompilers
<lool> hrw: Also, did a large pass on it
<lool> hrw: Could you have a look?
<ogra_cmpc> there are tricks that you can tell d-i to use the archive from a different media
<ogra_cmpc> but as i said above you have to look them up in the d-i docs
<ogra_cmpc> and have to modify the image accordingly
<lool> hrw: If you're happy with the overall text, I'll add work items
<hrw> lool: in few minutes I will look
<lool> hrw: Once thing which we failed discussing is how the runtime libs should be named and packaged, either they could use the dpkg-cross namespace (package name and file locations), or the cross-compiler one; the latter seems safer, but it could confuse dpkg-cross later and means we have two runtime libs (one dpkg-crossed, the other cross-built) which is also confusing
<hrw> or we move to sysroot and keep all crossarch stuff in sysroot only. maybe will require adaptations in dpkg-cross to follow. and I would follow dpkg-cross naming of packages
<hrw> but would be nice to have 'cross/' section maybe for them
<neure> cross?
<neure> "no, we do not cross compile"
<xorAxAx> ogra_cmpc: what if i install to a usb storage device which is a sd-card and then later plug the sd card into the beagle, will it still find the root fs?
<hrw> xorAxAx: UUID is same so it should
<xorAxAx> ok
<lool> hrw: What does moving to a third location gain us?
<lool> Besides the location is only half of the problem, the other namespace issue is with package names, dpkg-cross also converts dependencies
<hrw> lool: location is small problem which can be solved in any way. naming/deps are more important. I think that it depends on how much multiarch ubuntu will be. so far on x86-64 we have ia32-* packages for 32bit compatibility and they are stored in defined places and have own deps. but they are also ugly.
<hrw> lool: dpkg-cross way gives simple visibility which pacakges are cross ones but require all that converting (which can be also done at build time of packages if we will go that way)
<hrw> lool: I mean: how to show that libpng12 is x86-64 (host) or armel (cross)...
<lool> hrw: Multiarch isn't in the picture yet; we know that's what we want in the end, but it's not available right now
<lool> hrw: ia32-libs is horrible
 * ogra_cmpc dances ...
<ogra_cmpc> finally got the touchbook booting
<hrw> and I got auto-serial-console working in a way wanted
<lool> hrw: Are you happy with the wiki page?
<hrw> yes, I am
<neure> now im trying again with a different usb stick
<neure> also fails for another partition :D
<neure> i mean stick
<rsavoye> lool: personally, I prefer sysroot too. nice wiki page
<ogra_cmpc> neure, but it is listed in the partitioner ?
<neure> fuck
<neure> i switched to another usb hub
<neure> now the usb hub i tried on beagle .. is giving me issues on the pc :D
<neure> like, mouse is not working through it :D
<ogra_cmpc> well, the C2 definately has USB power issues
<neure> now it is
<ogra_cmpc> see http://elinux.org/BeagleBoard#EHCI
<lool> hrw: BTW did you manage to build an emdebian style cross-compiler using the Ubuntu sources?
<hrw> yes, I did
<rsavoye> hrw: did you hit the configure problem with libstdc++ and libiberty ?
<hrw> rsavoye: during build of gcc? nope
<rsavoye> no c++ ?
<hrw> g++-4.4-arm-linux-gnueabi_4.4.3-4ubuntu5_amd64.deb
<hrw> I built gcc, g++, gfortran, gobcj, gobcj++
<rsavoye> using the code sourcery patches ?
<hrw> no, ubuntu sources
<hrw> I plan to recreate it from scratch tomorrow anyway
<rsavoye> I'd have to check, mostly I'm just curious as I use FSF sources
<neure> oh dear
<lool> hrw: Do you have some tasks you feel like you can attack already with the cross-toolchains?
<hrw> lool: was thinking about dropping dh_movefiles for start and then looking how binary-cross is made
<hrw> lool: sysroot changes from 4.5 would be nice to have in 4.4 but did not looked at 4.5 yet
<lool> Hmm ok, movefiles was actually assigned to me
<hrw> ok, can skip it
<ogra_cmpc> mumble
<ogra_cmpc> so i got a working kernel but the screen shuts off after some minutes
<armin76> energy saving feature :D
<ogra_cmpc> i wish it would be that easy
<amitk> ogra_cmpc: oops?
<ogra_cmpc> amitk, yes, but unrelated to the framebuffer
<ogra_cmpc> arch/arm/mach-omap2/dpll.c:439 omap3_noncore_dpll_set_rate+0x220/0x264()
<ogra_cmpc> seems it doesnt like that i picked performance as governor at compile time
<ogra_cmpc> but its unrelated to the screen
<ogra_cmpc> (note that is the 2.6.34 touchbook tree i'm trying here)
<amitk> should be unrelated to the governor, but a real bug in the dpll code (that could take down the dss on its way down)
<ogra_cmpc> if i start/restart gdm i see some message about GFX underrun
<ogra_cmpc> saldy that doesnt show up in any log
<ogra_cmpc> aha !
<ogra_cmpc> this time it wrote to dmesg
<ogra_cmpc> [ 3859.026519] omapdss DISPC error: GFX_FIFO_UNDERFLOW, disabling GFX
<ogra_cmpc> hmm, and the screen didnt shut down yet i still see my xterm
<ogra_cmpc> wow and the touchscreen works out of the box
<ogra_cmpc> so apparently issuing xset dpms force on and restarting gdm made it work
 * ogra_cmpc is brave and installs ubuntu-netbook
<ogra_cmpc> i hope the 4G SD card is sufficiant
 * robclark|pb finds 4gb a bit small once you install build-essentials and a handful of builddeps..
<ogra_cmpc> yeah, its only a test setup to get a touchbook image together
<ogra_cmpc> i wont really do work on it
<ogra_cmpc> basically i just want a std ubuntu install to work on the touchbook
<ogra_cmpc> that SD is supposed to be my reference
<persia> ogra_cmpc: How much variance do you see?  Do you expect that we could have a single image that worked on that and on the beagles?
<ogra_cmpc> persia, not until someone uinfies u-boot
<persia> Oh, heh.  same problem as always
<ogra_cmpc> persia, but the pkan is to provide a script or at least a wikipage to replace MLO and u-boot on the maverick preinstall images we,ll provide
<ogra_cmpc> since amitk fights for a unified kernel at least :)
<amitk> ogra_cmpc: having a brain freeze here, what is the program that writes the kernel/initrd to nand on beagle? flash-kernel?
 * persia omits a repitition of the the extended whining about the parlourous state of bootloaders
<persia> amitk: Yes
<ogra_cmpc> amitk, in lucid and later its update-initramfs calling flash-kernel
<ogra_cmpc> before it was the kernel posinst via kernel-img.conf
<amitk> what package?
<ogra_cmpc> kernel-img.conf doesnt come from any package afaik
<ogra_cmpc> its cretaed by the installer
<persia> Indeed, it is.
<ogra_cmpc> the ac tual work is done by flash-kernel though
<amitk> no, I meant flash-kernel. I want to find out the commands and addresses you write the kernel to
<ogra_cmpc> and the flash-kernel-installer.postinst which is used by d-i/ubiquity
<ogra_cmpc> ah
<ogra_cmpc> look at debian/flash-kernel-installer.postinst in the flash-kernel source then
<ogra_cmpc> it sets up the adresses etc
 * amitk is trying to rescue a broken (test) kernel upgrade
<ogra_cmpc> ow
 * ogra_cmpc checks the source
<persia> Isn't flash-kernel-installer.postinst basically just a reimplmentation of flash-kernel for use in a udeb?
<ogra_cmpc> persia, nope
<ogra_cmpc> its doing all the setup for flash-kernel
<ogra_cmpc> amitk, so basically its just writing to the mtdblock device that holds the kernel
<ogra_cmpc> dd if=/dev/zero of=$kmtd bs=$kmtdsize count=1
<ogra_cmpc> cat $tmp.uboot > $kmtd
<ogra_cmpc> $kmtd is the mtdblock device that is labeled as Kernel in /proc/mtd
<ogra_cmpc> and $tmp.uboot is the uImage
<ogra_cmpc> and $mtdsize is the size of the mdtblock device in bytes
<ogra_cmpc> *$kmtdsize
<ogra_cmpc> and that part is definately in flash-kernel not the installer
<amitk> ogra_cmpc: and initramfs?
<ogra_cmpc> same thing
<ogra_cmpc> but its using the "File System" space for the uInitrd
<amitk> ohh, they probably use offset
<ogra_cmpc> using a fixed size of 16777216 bytes
<ogra_cmpc> (for zeroing it)
<amitk> ogra_cmpc: What is "File system" space?
<ogra_cmpc> cat /proc/mtd
<ogra_cmpc> try that
<ogra_cmpc> you should get u-boot, u-boot config, kernel and file system
<ogra_cmpc> the device labeled filesystem is the one we use for initrd
<amitk> ogra_cmpc: I'm at uboot prompt, transferred over a kernel using ymodem. Now hoping to flash that to nand
<ogra_cmpc> oh
<ogra_cmpc> no idea
<ogra_cmpc> i always do it from a running system
<ogra_cmpc> i guess i have to refer you to the beagle wiki
<amitk> could I do it from initramfs? (I don't think so)
<ogra_cmpc> you should be able to
<ogra_cmpc> as soon as the /dev/mtdblock* nodes exost
<ogra_cmpc> exists
<armin76> ssvb: cosmicparrot :D
<hrw> did someone built maverick's gcc-4.4 for armel? ports.ubuntu.com has it but no libstdc++ package
<ogra_cmpc> i think doko uploaded it, yes
<ogra_cmpc> should be named libstdc++6 though
<hrw> yes, but there is -dbg, -pic, -dev but no lib
<hrw> anyway I will rebuild it here
<amitk> ogra_cmpc: the problem is that the test kernel broke mmc :-/
<persia> hrw: Check the build log: maybe something fixable went wrong.
<hrw> k
<ogra_cmpc> amitk, ouch, you could x/yload kernel and initramfs and boot from ram though
<ogra_cmpc> hrw, http://ports.ubuntu.com/pool/main/g/gcc-4.4/libstdc++6-4.4-dev_4.4.4-2ubuntu2_armel.deb
<ogra_cmpc> built may 19
<hrw> facepalm...
<ogra_cmpc> hmm, only -dev though
<ogra_cmpc> and -pic
<hrw> ~curse apt-cross
<ogra_cmpc> there is no non-pic version
<hrw> exactly
<ogra_cmpc> well, as persia said and also ask doko
<hrw> yep
<xorAxAx> anybody knows what i need to pass on the kernel param line to get omapfb run on s-video out?
<ojn> xorAxAx: Check on #beagle or #linux-omap?
<lool> hrw: the runtime libs are built from gcc-4.5 in maverick
<hrw> thx
<lool> https://launchpad.net/ubuntu/+source/gcc-4.5/4.5.0-3ubuntu1 has links to the .debs
<ogra_cmpc> now /me facepalms :P
<lool> hrw: I added work items to https://blueprints.edge.launchpad.net/ubuntu-arm/+spec/arm-m-cross-compilers the dh_movefiles action was originally assigned to me, but I don't mind if you pick it up
<amitk> hrw: ogra: 2.6.34-based omap3 kernel - display and usb works, nand driver broken, but xubuntu works fine. Find it here -> http://people.canonical.com/~amitk/ti/
<hrw> lool: tomorrow I will rebuild toolchain with maverick sources and then start from movefiles
<amitk> it looks "good enough" to start the maverick cycle, IMHO
<hrw> amitk: fetching
<ogra_cmpc> amitk, thats beagle only ? or did you add any other nofty HW support
<ogra_cmpc> *nifty
<amitk> ogra_cmpc: nothing notably new, except for OTG support (I have no HW to test though). Once this is verified on beagles, we can start playing with more features.
<hrw> amitk: during UDS persia was giving otg host cables
<lool> JamieBennett: It seems one can retarget blueprints to a different project
<lool> JamieBennett: I wonder whether it would make sense to move the bps back to /ubuntu
<lool> It would give us all the regular milestones
 * persia suspects this would make it easier to collaborate effectively
 * hrw -> off
<hrw> have a nice rest of day
<JamieBennett> lool: That is possible, I'm not completely convinced its the right option though
<DanaG1> hmm, is a headless box supposed to automount usb drives?
<DanaG1> ah, usbmount just didn't use ntfs.
<persia> JamieBennett: What would it take to convince you?
<DanaG1> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=321694#17
<ubot2> Debian bug 321694 in usbmount "usbmount: use vendor/model in mountpoints" [Wishlist,Open]
<persia> DanaG1: I'm really tempted to mark that Won'tFix, for several reasons.  Firstly, I have several devices with the *same* vendor/modle that I use simultaneously.  Secondly, I have other devices with nice names I want to keep.  Thirdly, I think most users would be confused.
<persia> Please rebut, and I'll delay doing that :)
 * zyga enjoys evening working spree :-)
<lool> JamieBennett: Do you have some time for a call?
<NCommander> ndec: you around?
<lool> NCommander: national holiday today
<NCommander> lool: d'oh :-/
<ogra_cmpc> NCommander, so i dont undrestand what your issues with genext2fs are, it works fine for me on the babbage and rolls a netbook image in ~30min
<NCommander> ogra_cmpc: when I tried it, it ate more and more RAM until it eventually OOMed. If it works for you, then I'll leave the code be :-)
<ogra_cmpc> well, you have a weird way of computing the size, it might get confused because you allocate more than actually needed
<ogra_cmpc> the -b parameter should take exactly the size of the chroot contents
<ogra_cmpc> the tool will allocate enough to add a journal later
<ogra_cmpc> also there is no need to add 10MB spare space, we wont need them
<ogra_cmpc> the partition will be resized before the first boot anyway
<ogra_cmpc> i agreed that genext2fs isnt actually a beauty with its habit to allocate the full image size in ram before writing to it, but we have 30G swap on the builder so no worries
<ogra_cmpc> *agree
 * ogra_cmpc goes back to slurp cool Cidre and watch TV
<persia> So, the reason the magic 10M exists is to contain pool/
<persia> If debian-cd isn't going to insert that later, it's not needed, but...
<NCommander> ogra_cmpc: tune2fs fails if there's no free space
<NCommander> ogra_cmpc: feel free to improve the code, its free software afterall :-)
 * NCommander runs
 * persia lassos the running target
<persia> NCommander: So, where does pool/ end up living with this new order?
<NCommander> persia: what pool?
<persia> The set of stuff that some folk need to be able to connect to the network to get other stuff.
<NCommander> If we need a pool, then we need to expend toe spec
<persia> We need a pool.
<persia> I thought that it was going to prepopulate /var/cache/apt/... somehow, but there are other ways to make it work.
<NCommander> persia: this is a corner case IMHO.
<persia> It's really not.
<NCommander> persia: this image is for demostration purposes only
<NCommander> do we *really* need a pool?
<persia> Three of the last four machines I've installed needed pool/
<NCommander> what did you need from the pool?
<persia> Drivers for network
<persia> Drivers for video
<NCommander> persia: drivers for the network are included on OMAP4 in kernel
<persia> You sure?
<NCommander> video can be downloaded from a PPA
<NCommander> persia: its supposed to work
<persia> So, what kind of network drivers are in the kernel?
<persia> Do they work for my odd network environment?
<persia> What about with my 3G dongle?
<NCommander> persia: we don't have a USB port on blaze
<NCommander> That kinda limits what drivers are needed :-)
<persia> And there's onboard network of some sort?
<persia> And this will remain true for other devices that would use this class of image?
<NCommander> persia: can't speak for hardware I don't have
<ogra_cmpc> persia, why would you want /pool on an installed system ?
<ogra_cmpc> NCommander, tune2fs works for me without leaving a gap in the image
<persia> ogra_cmpc: I don't.  I want to be able to get to the network to install other stuff.
<ogra_cmpc> persia, right, and even if we would ship a pool dir it wouldnt be inside the rootfs
<NCommander> persia: we'll provide drivers for the machines the image is supposed that will make the onboard stuff work
 * persia has had all sorts of devices, the most obscure network requirement was PPP-over-ISDN-on-CF card, which caused no end of annoyance to StevenK when trying not to have pool/ for MID
<NCommander> persia: ...... my eyes just bled from that sentence
<ogra_cmpc> pool is pointless for that kind of image
<persia> I'm against the very concept of designing software to build images that can only be used for a single device.
<NCommander> persia: why can't we pre-install this stuff? (or is it in restricted)
<persia> I've no issues with designing software that ends up being used to generate an image that can only be used for a single device.
<persia> Notice the different.
<ogra_cmpc> but thats what we'll do, feel free to come up with a better concept
<persia> Err, Difference.
<persia> ogra_cmpc: As I suggested last week, we could prepopulate /var/cache/apt/ archives with some stuff.
<ogra_cmpc> indeed
<ogra_cmpc> but with what ? all thats intresting cant be shipped anyway
<NCommander> persia: why don't we just preinstall it now?
<ogra_cmpc> i.e. the 3D drivers
<persia> But we really should include the debs from the ship seed *somewhere*.  This may happen to be the empty set for some specific image, but that's coincidence.
<persia> PPPoE is a good example of software most folks don't need and some cannot live without.
<NCommander> persia: at risk of stupid question, why can't we pre-install it then?
<ogra_cmpc> if you can tell a good reason to have the ship seed for anything i'm happy to prepopulate /var/cache/apt
<persia> NCommander: Because it's useless for most folks.
<NCommander> persia: we ship IPv6 stuff out of the box, that's useless for more folks than PPPoE :-P
<ogra_cmpc> the only reason i see for ship is to have the closed stuff available
 * NCommander agrees with ogra_cmpc 
<persia> ogra_cmpc: Because some use cases for some devices require it.  Like I said, I don't care if you make an image where it's empty, but please make sure the facility is there to use the ship seed to populate *somewhere* on the result image for folks/devices/environments that do require it.
<ogra_cmpc> in which case neither preinstallinf nor perpopulating the cache will work
<persia> It's not about open/closed.  it's about stuff that most folk don't want and others need.
<persia> Is there an open SD slot?
<ogra_cmpc> no
<ogra_cmpc> else we could use an installer
<persia> No USB, no SD.  Anything?
<persia> Any expansion of any sort?
<ogra_cmpc> we will have devices that only come with a single SD slot and nothing else
<persia> No USB?
<persia> No expansion port?
<NCommander> persia: nothing usable out of the box without a custom kernel
<persia> Nothing?
<persia> NCommander: Why not?
<NCommander> persia: you'd have to remove the UART gadget and replace it with something else as far as I can tell
<NCommander> and I'm not even sure if that's possible
<persia> Oh, it has a serial port?
<NCommander> persia: it has a mini-USB port, and a micro-USB port
<NCommander> my Blaze won't boot if I have anything in the micro port
<persia> That's USB.  I can attach all sorts of things to that.
<ogra_cmpc> well, the blaze has eMMC
<persia> And I might need to have my 3G dongle attached to be able to download updated software.
<ogra_cmpc> and could boot from it
<NCommander> persia: mini-USB is OTG, and stuck in Host mode out of the box
<persia> Host mode means I can attach a dongle.
<ogra_cmpc> thats a matter of dip switches
<NCommander> ogra_cmpc: I thought it was panada that had eMMC, not Blaze, or do i have it backwards.
 * NCommander probably has it backwards
<ogra_cmpc> both do
<NCommander> oh
<ogra_cmpc> just have a look :)
<NCommander> ogra_cmpc: ... then why can't we have an installer to the eMMC?
 * persia didn't think panda specs were available yet, and wants a URL
<ogra_cmpc> you have mmcblk0 and 1
<ogra_cmpc> NCommander, because panda and blaze arent the only devices
<persia> So, anyway, regardless of what's in the device, at least someone is going to have an awkward use case.
<persia> And that person is going to need the stuff that usually goes in pool/
<persia> So that stuff belongs somewhere in the image.
<ogra_cmpc> erm, i'm wrong
<ogra_cmpc> panda wont have eMMC
<ogra_cmpc> persia, make a list of poackages that need to be in pool and dont need a pre-download EULA agreement and i'll happily add them to the cache
<persia> Use the content of the ship seed.
<persia> Same as for any other sort of image.
<DanaG1> hmm, how do I get usb hard drives to automount, by-label, on a headless box?
<prpplague> ogra_cmpc: the eMMC is available for expansion, so you could have a secondary mmc card, or use eMMC
<DanaG1> usbmount doesn't work for me... I need persistent labels.
<persia> DanaG1: Watch for udev events, and do something with them :)
<ogra_cmpc> persia, so looking at the lucid netbook ship seed i dont see a single package i would ship
<DanaG1> Unfortunately, udev alone doesn't seem to expose the label.
<DanaG1>  udevadm info --query=all -a -p $(udevadm info -q path -n /dev/sda2)
<persia> DanaG1: Your program would respond to udev, then perform operations on the device to do things like get the label, then mount it.
 * persia looks at the maverick netbook seed
<DanaG1> If I can run gnome-volume-manager (or an equivalent) in xpra, that'd work, too.
<ogra_cmpc> DanaG1, just create a custom rule
<ogra_cmpc> /etc/udev/rules.d/README has info
<DanaG1> I found one here that tries to use an ENV that doesn't exist as an ATTR.
<persia> ogra_cmpc: So, based on http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/netbook.maverick/annotate/head:/ship-live I'd include pptp-linux, sl-modem-daemon, bpalogin, libatm1, setserial, b43-fwcutter, bcmwl-kernel-source,
 * DanaG1 digs up link...
<persia> Extra langpacks are nice, but it's the network stuff that7s critical.
<DanaG1> http://superuser.com/questions/53978/ubuntu-automatically-mount-external-drives-to-media-label-on-boot-without-a-us
<ogra_cmpc> we wont ship any langpacks
<DanaG1> there's a udev rule... but it doesn't work.
<ogra_cmpc> oem-config will install them if network is available
<ogra_cmpc> if not, the image will stay english
<persia> ogra_cmpc: Fine, but the network stuff is critical.
<persia> Lots of folks have broadcomm.  Lots of folks still use modems.  Lots of folks need pptp auth to get out of the local net.
<ogra_cmpc> what does b43-fwcutter gain you without the firmware ?
<persia> I don't know.  I just know that if I do a fresh install on a machine, and install b43-fwcutter and bcmwl-kernel-source I get a working network,.
<ogra_cmpc> you dont
<persia> I do.  I did it on the 11th of May.
<ogra_cmpc> you need trird party frimware files
<persia> I really didn't.
<ogra_cmpc> thats what b43-fwcutter does
<ogra_cmpc> then you only need the source file
<ogra_cmpc> b43-fwcutter extracts windows firmware files
<persia> OK.  Maybe I have a windows driver CD that came with my dongle.
<ogra_cmpc> fine then put the CD in your pandaboard :P
<persia> No problem.  I have USB DVD drives around.
 * persia should really get a new one, as the one that uses PS/2 power is mostly obsolete, and the other one requires *two* USB ports
<ogra_cmpc> my point is that you have used another computer to download your image and ot write the SD, why cant you just copy debs with that computer on the SD ?
<persia> Because there's no space in the filesystem
<ogra_cmpc> ??
<ogra_cmpc> the filesystem is as big as the card
<DanaG1> weird.... ata_id and scsi_id are both returning empty strings!
<persia> I'd have to do the install, and then post-install monkey with the SD card, and then install more stuff, etc.
<ogra_cmpc> right
<persia> ogra_cmpc: Not at the time I dd it.  Only post-install.
<persia> So, that's an unpleasant experience.
<ogra_cmpc> alternatively you have to bastardize livecd-rootfs to install ship inside the image
<persia> Plus it fails the case where I get passed an already burned SD card somewhere from some guy in an overcoat
<ogra_cmpc> pathces accepted if the cdimage team accepts them
<persia> (yes, this happens: I have been on both sides of such an SD exchange)
<persia> OK,  As a rep of the CD image team, do you expect them to be accepted?
<ogra_cmpc> no idea, depends on the code :)
<persia> NCommander: Please present ogra with code to review :)
<ogra_cmpc> pfft
<ogra_cmpc> thats lame
<ogra_cmpc> NCommander has enough work with debian-cd atm
<persia> Well, I guess.  I'm just not expecting to get to it for 3-4 weeks, and that's probably late to jam it in.
<persia> Very true.
<ogra_cmpc> just do it if you have time
<ogra_cmpc> i'm happy to review it
<ogra_cmpc> and to merge it too
<persia> OK, consider my protest registerd.  I'll send a patch when I can.  Otherwise, I'll complain about it for next time.
<ogra_cmpc> next time livecd-rootfs wont exist anymore
<persia> What?  Why not?
<persia> Or is it being reimplemented differently?
<ogra_cmpc> d-cd and l-r are being dropped
<persia> In favour of?
<ogra_cmpc> apparently someone decided to switch everything to luvehelper
<ogra_cmpc> *live
<persia> Everything?
 * persia clearly needs to read more of the specs
<ogra_cmpc> i havent seen a spec
<ogra_cmpc> it was a m+1 decision apparently
<ogra_cmpc> cody told me at the corridor
<ogra_cmpc> at UDS
<persia> I'm reluctant to believe that level of infrastructure migration would happen wholesale without a spec.
<ogra_cmpc> m+1 qill likely have a spec then
<ogra_cmpc> will
<persia> But anyway, I'll send you a patch in July, *OR* I'll make sure there is a pool/ equivalent on produced images in m+1 (regardless of the underlying technologies.)
<ogra_cmpc> pool/ wont happen, cache prepopulation can though
<persia> Oh, of course.
<ogra_cmpc> hmm
<persia> I'm not fussed about the name, so long as users can end up with a working system post-install without needing to mount the storage on *another* device.
<ogra_cmpc> pool/ might if we pick to ship with a huge vfat
<ogra_cmpc> though my plan waws to make that hidden actually
<persia> huge vfat?  Why?
<persia> But yeah, pool/ on vfat is fine, and can be wiped if the user doesn't need it.
<ogra_cmpc> because we boot from that vfat
<persia> If it's just a boot vfat, it ought be small, I think.
<ogra_cmpc> so the boot partition would be bigger but carry pool/
<ogra_cmpc> indeed that makes the plan to make it a hidden partition tricky
<persia> I don't like that.  I'd rather prepopulate the cache.
<ogra_cmpc> ok, fine as well
<persia> I don't think you want to hide the partition.
<persia> For the EFI/GPT case, the FAT partition is unhidden, which people seem to like.
<ogra_cmpc> i want to hide the partition
<ogra_cmpc> else it gets mounted
<DanaG1> persia: you can hack up a ps/2 to usb-power-only cable.
<DanaG1> or rather, the other way around.
<ogra_cmpc> that fat partition is our replacement for the NAND and will be handled similar
<persia> DanaG1: both ways, actually, but I've seen new devices that have an onboard capacitor to handle spinup with only a 5V/500mA draw.
<DanaG1> ah yeah, usb->ps/2->usb.
<persia> ogra_cmpc: Doesn't have to mount.  The FAT partition for EFI/GPT doesn't get mounted.
<DanaG1> Suck power from it, while passing it right back to USB protocol.
<ogra_cmpc> persia, it shows up in nautilus
<persia> ogra_cmpc: Not on a new macbook.
<ogra_cmpc> i dont want people to be able to muck about with it
 * ogra_cmpc didnt know there will be panda based macbooks :P
<DanaG1> http://www.cablesdirect.com/prodimages/USB-PS2F_LR.jpg
<ogra_cmpc> TI will be happy to hear that :D
<DanaG1> I wish my UEFI weren't broken. =(
<persia> ogra_cmpc: The point isn't panda-macbooks.  The point is that we have technology that causes special bootloader partitions not to be mounted by nautilus.
<ogra_cmpc> right
<persia> So we ought use that to do this, rather than fiddling with hidden partitions.
<ogra_cmpc> we also have udev rules that hide such partitions completely
<persia> Right.
<DanaG1> HP_TOOLS is another example.
<persia> Which is the right way to do it, not with the hidden flag in the parition table.
<DanaG1> HP boots in CSM mode, but has their EFI partition for stuff like QuickLook.
<ogra_cmpc> i didnt talk about flags
<persia> Oh, then I've misunderstood you.  Please forget I said anything :)
<ogra_cmpc> but i want it completely hidden so users dont fiddle manually with the contents and instead use the provided tools
<persia> You can't do completely hidden.
<ogra_cmpc> you can through udev
<persia> Closest is with partition table flags (which I'll argue against)
<persia> No, you can't.
<persia> All udev does is not provide a /dev/ link, at best.
<ogra_cmpc> the system wont see it
<DanaG1> Isn't there something like UML that'll let different apps see different file systems?
<persia> DanaG1: Yes.
<DanaG1> sudo scsiadd -p
<DanaG1> scsiadd:scsidump():could not open /proc/scsi/scsi (r): No such file or directory
<DanaG1> argh... for some reason, that udev rule doesn't work.
<persia> ogra_cmpc: You really don't need to go to that extent.  Look up how the EFI/GPT case is handled for Intel Macs.  That7s well-tested code.
<DanaG1> It acts as if ENV{ID_FS_LABEL_ENC} does not exist.
<DanaG1> Intel Macs are weird... they don't use protective MBR.
<persia> Well, kinda.
<DanaG1> I wish Apple would recommend using EFI-installed Windows instead of CSM-installed Windows.
<persia> they leave space for it, but don't pay any attention to it.
<ogra_cmpc> i just plan to add it to /lib/udev/rules.d/80-udisks.rules at the bottom
 * ogra_cmpc needs to go now
<DanaG1> ah, fixed the udev rule.
<DanaG1> had to change SUBSYSTEM=usb to SUBSYSTEM=block
<DanaG1> and rename a file I had mis-named.
 * NCommander is dealing with some really sucky internet in his test builds :-/
#ubuntu-arm 2010-05-25
<xorAxAx> ogra_cmpc: hmm, it seems that i dont get anything on the s-video output even though i am setting the right boot options
<rcn-ee> xorAxAx, which board?
<xorAxAx> BB C5
<xorAxAx> BB C4
<xorAxAx> i currently dont have a dvi connector, nor a serial cable, only s-video :)
<rcn-ee> that's going to make it almost impossible.. (speciall with no serial cable.)  the s-video settings aren't always enabled in every kernel. (nor do i test it)  take a look here, nottice how sakoman setup the tv section: http://www.sakoman.com/cgi-bin/gitweb.cgi?p=linux-omap-2.6.git;a=blobdiff;f=arch/arm/mach-omap2/board-omap3beagle.c;h=915606ed2c8dd82bcd8942a2a0f958de4118e03a;hp=89eca2005d88239bd8ea411e5103c995f52b52e8;hb=9708463105204cb46fa8
<rcn-ee> bd59f309e85f5936d4d6;hpb=76f65e01f23f435497cbd70cb574dd5689cddb58
<rcn-ee> (that failed: http://www.sakoman.com/cgi-bin/gitweb.cgi?p=linux-omap-2.6.git;a=commit;h=9708463105204cb46fa8bd59f309e85f5936d4d6)
<xorAxAx> i dont see how that commit would help me
<rcn-ee> i'm saying if s-video isn't working, there's a good chance the s-video bits aren't setup...
<rcn-ee> looks like they are.. http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=commit;h=0f66624dea24d97fc700e8effad9c4016a22224f  (what's your bootargs)
<xorAxAx> setenv bootargs vram=12M omapdss.def_disp=tv omapfb.mode=tv:pal file=/cdrom/preseed/ubuntu-server.seed  cdrom-detect/try-usb=true
<xorAxAx> rcn-ee: does that make sense?
<rcn-ee> that's valid...  so how are verifying that's actually getting passed to the kernel?
<xorAxAx> i could check the output of uboot
<xorAxAx> (flashed an uboot which talks over usb :))
<rcn-ee> okay, wasn't sure on that...  can you log the kernel boot for me..?
<xorAxAx> i dont get to that step anymore
<xorAxAx> because the kernel doesnt talk usb :-P
<xorAxAx> hmm, uboot doesnt echo the bootargs
<rcn-ee> ah right.. (stick a printenv in your script)
<xorAxAx> videomode=1024x768@60,vxres=1024,vyres=768
<xorAxAx> videospec=omapfb:vram:2M,vram:4M
<xorAxAx> thats in the env :)
<xorAxAx> but thats likely not used
<xorAxAx> mmcargs=setenv bootargs console=${console} video=${videospec},mode:${videomode} root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait
<xorAxAx> nandargs=setenv bootargs console=${console} video=${videospec},mode:${videomode} root=/dev/mtdblock4 rw rootfstype=jffs2
<xorAxAx> ah, hmm. so it prefixed with video=?
<rcn-ee> that's a little weird..  you can call saveenv  to safe your bootargs...
<rcn-ee> ah yeah i remember now.. that's an older u-boot, before they standarized on boot.scr's the video spec stuff is for 2.6.27/28 kernel's..
<xorAxAx> i guess i'll wait for the serial cable to arrive
<rcn-ee> oh you can override, just setenv bootargs ' yada' then saveenv then boot..
<xorAxAx> well, i am booting from sd card
<xorAxAx> and i just booted manually
<xorAxAx> with copying commands into the prompt
<xorAxAx> good night
<persia> What?  Why not?
<persia> Err.  That's an unintentional repeat.
<cooloney> amitk: morning
<amitk> morning cooloney, all
<lag> amitk: Morning
<amitk> morning lag
<hrw> morning
<neure> hi
<neure> any ideas why making filesystem would fail in the installer?
<neure> i tried two different (well both were kingston) usb sticks on two different usb hubs
<neure> on beagleboard
<neure> yesterday :)
<neure> can i preformat on pc?
<neure> can i say 'use this partition, dont try to format it'?
<neure> huh
<neure> preformatting on pc helped a little
<neure> now it got to install the base system
<neure> crap
<neure> de bootstrap warning
<neure> ...bsdutils... was corrupt :/
<hrw> ogra_cmpc: can you show me default-after-install bootcmd from uboot?
<neure> ah
<neure> that _could_ explain
<neure> if my installation image was faulty?
<neure> is it possible to install / create the filesystem on a PC?
<persia> neure: You could use rootstock, but check your checksums: it's unlikely that you downloaded a faulty image.
<neure> persia, is it possible that the dd to sdcard was faulty?
<neure> well.. more like.. is it likely :)
<persia> Yes, that's much more likely (but in that case, you don't need a new filesystem)
<neure> since the install media is the sdcard, it should not be usb power issue
<persia> If you know the size, you can dd from the SD to a file, and then checksum compare the download version to the one read from SD.
<neure> unless the error is detected somehow after file has been copied to usb
<neure> well i have the original filesystem on the pc / vmware still
<neure> so i can use ls to get the size :()
<neure> but iÍ'll perhaps try later
<persia> If it's debootstrap failing, that's prior to actually using anything in the constructed target filesystem.
<neure> ok
<neure> could i use rootstock to install directly to the sdcard on pc?
<neure> that way i could bypass usb
<neure> i have ubuntu 9.04 on my vmware, can i use that to put 10.04 on sdcard for beagle?
<ogra> hrw, you mean the kernel cmdline ?
<ogra> oh, bootcmd
<ogra> cmdline="root=UUID=$uuid ro quiet splash vram=12M omapfb.mode=dvi:1280x720MR-16@60 fixrtc"
<ogra>                 bootcmd="nand read 80000000 280000 400000;nand read 81600000 680000 1000000;bootm 80000000 81600000"
<ogra> hrw, ^^^
<hrw> thx
<hrw> shit - out of luck
<NCommander> morning ogra
<ogra> hey
<ogra> hrw, whats wrong ?
<NCommander> ogra: how was your holiday?
<hrw> ogra: nevermind - my error
<ogra> short, relaxing and good for my touchbook :)
<NCommander> ogra: bah, why do you get the fun toys?
<hrw> booted 2.6.34
<amitk> the touchbook is _not_ fun, after the first 15mins
<amitk> hrw: does it work?
<ogra> NCommander, you mean the SM toys :)
<NCommander> kinky
 * NCommander coughs
<NCommander> ogra: so I smacked livecd-rootfs with a hammer yesterday
<NCommander> It now uses loopmounting, and doesn't make my systems free memory drain like a leaking pipe
<ogra> ouch, poor livecd-rootfs
<ogra> bah
<ogra> dont use loop mounting
<NCommander> ogra: plus now we have ext4
<NCommander> ogra: why not?
<ogra> its ugly
<hrw> amitk: serial works, usb works, 1280x800 on my 20" lcd also works
<amitk> hrw: could you try out OTG
<NCommander> and genext2fs sucked down RAM faster than a hummer sucks down gas
<ogra> NCommander, its works just fine
<ogra> did you try it on a babbage yet ?
<NCommander> ogra: considered I never managed to build anything beside a base image with it, I don't think I'd use the word fine
<NCommander> No, my babbage is upstairs
<ogra> i built about ten netbook images since mid last week with it
<hrw> amitk: otg refuses to see my hub
<ogra> no prob at all, you just need to make sure to have enough swap to pre-allocate the ram space genext2fs copies the files to
<hrw> restarting with hub on otg
<ogra> i have an identical setup to the buildd here and havent seen any probs
<NCommander> ogra: I can appericate the concept of throwing more resources to solve a problem, but I draw the line with a 30GiB swap :-)
<ogra> i use 2G swap iver here
<ogra> *over
<ogra> note that 30G is default on the builder
<ogra> i dont see any of the probs you mention
<NCommander> Well, yes, but that's kinda excessive, no?
<ogra> are you using the genext2fs under arm from the archive ?
<NCommander> under ARM and amd64
<NCommander> It crashes my laptop like few things ever have.
<hrw> amitk: no hub on otg after reboot
<ogra> i'D consider that an amd64 bug
<ogra> i didnt see any issues under x86 nor under armel
<ogra> please stick to the concept
<ogra> if you need to access the image (for whatever reason) dont use loop but fuseext2
<NCommander> I am sticking to the concept. I'm just not building my images in a way that causes my laptop to go TILT and OOM itself to death
<ogra> use your babbage
<ogra> thats what we use in the DC
<ogra> as i said i dont see such issues on x86 or arm
<ogra> i'D file a bug against amd64 :)
<NCommander> ogra: I'll go test it a little later. In other news, where are we with packaging the new x-loader/u-boot
<NCommander> since once we get that out of the way, we can spin our first images for omap4 (granted, without jasper they won't work, but at least we can get all the little bits in place)
<ogra> i'm getting there slowly
<ogra> its a lot of patching involved in x-loader to make it build and i didnt finish that yet
<ogra> beyond that x-loader is going away soon so i'm not sure its actually worth the hassle
<ogra> as i siad before, just build omap3 images
<ogra> we have everything for them in the archive
<NCommander> No, that's what I'm doing
<NCommander> But I'd like to just have something that attempts to boot on omap4 ASAP
<ogra> well, rather dont hold your breath, dont expect anything before A2
 * NCommander blinks
<NCommander> uh, that's July
<NCommander> cutting it a bit close, no?
<ogra> ??
<ogra> thats june
<NCommander> ogra: https://wiki.ubuntu.com/MaverickReleaseSchedule -A2 is the first week of July
<ogra> well, july1
<ogra> anyway, we dont have a kernel in maverick for omap4
<ogra> we cant build anything before thats there
 * NCommander feels like he's missing something, but that may be lack of sleep and/or sanity
<ogra> for maverick we need a 2.6.35 omap4 tree
<ogra> which doesnt exist yet
<ogra> or .34 at least
<sebjan> ogra: Hi! How do you generate a uImage from a .deb? (mkimage? with which arguments?) I'd like to test cooloney's image but the uImage I generate does not boot at all...
<ogra> for omap4 i generate it manually, but with the same options the scripts use ...
 * ogra looks up the command
<ogra> mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n "Ubuntu Kernel" -d  vmlinuz-"${KVER}" uImage
<cooloney> sebjan: it does not boot?
<ogra> sebjan, http://paste.ubuntu.com/439253/ is exactly what i have on my blaze atm
<ogra> the actual in-distro scripts will do something similar
<sebjan> ogra: ok thanks, this is what I had been using for the uImage creation...
<ogra> sebjan, which u-boot/x-loader do you use ? i still use a binary for the pandaboard i got from robclark
<sebjan> ogra : cooloney : with the test6 image, I have a Uncompressing Linux...X-Loader hangs
<ogra> X-loader hangs ?
<ogra> how can it hang when it already loaded the kernel
<sebjan> ogra: I use the same x-loader/u-boot as before (which was working with test3 image for example)
<hrw> amitk: which kernel tree/branch you use for omap3/2.6.34? I want to build compat-wireless against it
<hrw> 802.11n dongle will be faster then usb ethernet ;D
<sebjan> ogra: yes, that's weird :)
<amitk> hrw: maverick git tree, master branch
<hrw> thx
 * ogra goes to find some breakfast ... back soon
<hrw> audio from uds is live
<amitk> err, UDS was in the past, so it can't be live. Unless you're hearing future UDS feeds :-p
<hrw> s/live/online
 * hrw waits for coffee
 * NCommander notes he'd like to know what specs to write UDS-N already so I can save myself some time
<cooloney> sebjan: it still doesn't boot?
<sebjan> cooloney: no, I wonder if it crashes during the uncompressing phase.
<cooloney> sebjan: too bad. i cannot verify it, i don't have hw yet. only ogra can confirm that
<sebjan> cooloney: I probably have a problem with my load addresses, I'll check that
<cooloney> sebjan: ok, no problem.
<NCommander> ogra: stupid question, how much RAM is in your x86 box?
<ogra_cmpc> 4G
<NCommander> ogra_cmpc: hrm, thanks
<ogra_cmpc> using the PAE kernel
<ogra_cmpc> the babbage has 512M and 2G swap
 * ogra_tb waves from the touchbook
<ogra_tb> hmmm, no sound
 * cooloney waves back to ogra_tb from his pc
<ogra_tb> funny, alsamixer has a ton of devices, gnome doesnt
<ndec> ogra: morning. do we need a launchpad project for every package that we put in PPA?
<ogra_tb> ndec, nah
<ndec> ogra: but what if I want that. is that possilble?
<ogra_tb> one PPA per package ?
<ndec> ogra: nope. 1 PPA many packages
<ogra_tb> well, thats what you get
<ogra_tb> god, that touchbook kbd kills me
<ndec> ogra: so I can't get automatic VCS (like for linut-tiomap) if we use 1 PPA with many packages... right?
<ogra_tb> ndec, you can indeed create a project for each package if you like but still upload all of them to the same PPA in the end
<hrw> ogra_tb: gnome wants to be simple - forgot it?
<ndec> ogra: what would the workflow be then. upload new source to project, and then upload to PPA?
<ogra_tb> the VCS you use for a project is independent from the centralized PPA
<ndec> ogra: well but for kernel (linux-tiomap) everytime a new .dsc file is uploaded it creates a new bzr version in the corresponding project. at least this is what I understood...
<ogra_tb> you can for example have a gstreamer-omap project, have a bzr branch under the project but upload the source packages to the central PPA
<ogra_tb> no, it doesnt
<ogra_tb> bzr should be independent from the PPA uploads
 * NCommander feels like stabbing something
<ogra_tb> hrw, well, i dont think its gnome but either alsa or pulse not handing the device through
<hrw> ogra_tb: alsamixer gives you lot of mixer entries so alsa handle it.
<ogra_tb> funny is also that jockey came up on first boot here, offering me a driver for twl4030
<ogra_tb> i sadly dont have enough space on the SD to hold the kernel tree to try out dkms modules
<ogra_tb> hrw, well, aplay doesnt give me any output even though i unmuted everthing
<ndec> ogra: on blaze you have 32Gb of eMMC. you can use fdisk to format. that gives plenty of space
<hrw> ogra_tb: http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/alsa/alsa-state/omap3-touchbook/asound.state
<hrw> ogra_tb: fetch, load, test?
<ogra_tb> ndec, i'm playing with the touchbook and ubuntu-netbook atm]
<ogra_tb> hrw, thanks
<ndec> ogra: oops...
<ogra_tb> :)
<ogra_tb> the kbd is horrid
<hrw> ogra_tb: after 6 years with OE my main source of fixes/configs etc is OE ;D
 * ogra_tb tries firefox for the first time 
<hrw> ogra_tb: you have 256M or 512M TB?
<ogra_tb> 512
<ogra_tb> FF is a bit stuttering but works ok
<ogra_tb> (i havent added swap yet)
<hrw> ogra_tb: can you join #upstart?
<ogra_tb> mumble
<persia> ndec: The automatic bzr commits from uploads comes from something that scans the upload queue for uploads to Ubuntu, and then commits that to special branches.  It's somewhat unrelated to either projects or PPAs.
<ndec> persia: ok. I see. this is only for projects that are beneath launchpad.net/ubuntu/..., right?
<ogra_tb> right
<lool> ndec: You want to talk to james_w about this
<ogra_tb> it will happen for uploads to maverick
<ogra_tb> but vnot for PPA stuff
<lool> ndec: It could be done for PPAs equally well, but currently we only run package imports for the main Ubuntu archive and for Debian packages imported to Launchpad
<ogra_tb> lool, well, ndec doesnt want it for PPAs if i understood correctly
<ndec> persia: so in my case, let me know if i get it right: i will create launchpad project such as launchpad.net/something, it will be linked to TI upstream git trees. when I make a new src package, I will upload to PPA. the PPA will have .dsc and .deb. the LP project will be used to report bug. but I won't be able to view the source code from the LP project...
<persia> ndec: You can set up a vcs-imports job that would pull the git commits into bzr daily.
<ogra_tb> right
<persia> And that makes bzr branch lp:foo work
<persia> Alternately, you could set up an upload scanner and have taht push to bzr, but if you7re working in git, and you're basically packaging upstream, then it makes more sense to me to have bzr track git.
<persia> ndec: Oh, and for the sake of completeness, your statement is entirely correct without any further effort taken.
<ndec> persia: right. i don't want to have a bzr branch that tracks my git trees daily. upstream is done with git. but I would like all my source package to be tracked *somehow*. ideally I would like to commit the content of the source package in either git or bzr. I thought that what was done for linux-tiomap was the perfect solution..
<ndec> persia: so now I can either create an external git tree where I package my upstream git trees (e.g. it would contain debian/ and all packaging patches). or I can use the LP project bzr branch for that...
<persia> ndec: I don't know that much about it, but I believe git-buildpackage was designed to handle that use case.
<persia> I believe the model is to have a packaging branch, and rebase that against the trunk when pushing a package.
<persia> And then the packaging can just be committed to the regular git repos.
<lool> You dont rebase
<lool> you just merge the upstream branch in the packaging one
<persia> Right.
 * persia isn't that familiar with git, and apologies for incorrect terminology
<ndec> persia: i didn't know about git-buildpackage. will check that. however note that my upstream (e.g. other dev teams) who owns the dev git tree don't package with debian. so I will need another tree (git or bzr) to store packaging data
<lool> Well you might have to rebase if your tree is rebased
<lool> especially with kernel trees
<lool> But with other software I packaged in git in the past, upstream didn't rebase and I just merged in the packaging branches
<lool> If you work from tarballs, even more so
<lool> ndec: It's best to use the same VCS for both IMO, allows cherry picks
<persia> Indeed.
<persia> Or rather, makes cherry picks *lots* easier
<lool> ndec: For instance, you can prepare a new package upload cherry picking a single patch
<ndec> lool: i agree, that also means that i don't need to learn bzr then ;-)
<lool> lol
<persia> It's a win all around :)
<lool> It does mean you get little launchpad integration, for instance your source wont be linked to closed bugs and such
<lool> But it's kind of inevitable that you work with git for kernel trees
<ogra> hrw, so lets go to #ubuntu-kernel to talk about serial consoles :)
<ogra> (and their upstart autodetection :) )
<lool> hrw: I'd like to offer review or fixes to your shell script dealing with console= args if you keep it
<lool> I saw some issues with it
<lool> But it might be that it's not part of the final design, so
<ogra> lool, well, we just asked Keybuk for upstream inclusion
<ogra> and he wants some massive chnages first
<ogra> mainly to the kernel
<ogra> he also said that using /etc/default violates upstart policy
<persia> It does.
<lool> Yeah
<persia> Mind you, /etc/default is planned to come back with 0.10, but in an entirely different way (and likely with a different path)
<ogra> lool, whats the timeline for having it in your arm project ?
<ogra> pre maverick ?
<lool> Personally my main problem with it is the approach of having to pass cmdline args for things to work; I'd rather have upstart start a getty on all serial consoles or something like that
<lool> Problem is that there are many possible device names, so the current approach of tty1 - tty8.conf doesn't work
<ogra> lool, right, thats what Keybuk wants
<ogra> he wants to be able to have a "start on" if the device exists
<ogra> without having to parse anything
<persia> I really don't want a getty on all serial.
<lool> ogra: I dont think we're considering changes to our image at this point, but it doesn't matter too much
<ogra> so maverick would be fine then
<persia> I use serial for auxillary displays, on which I never want getty
<ogra> i really want that function in 10.07 but can solve it trhough having my own package
<ogra> though i'd rather not having to duplicate anything
<lool> persia: In most cases, my serial port is an USB adapter to connect to other boards, not to run a getty, so I'm in a similar situation
<lag> amitk: When I do a "git push <remote> HEAD", should I have to do things on the remote to see the changes reflected in the directory tree?
<ogra> lool, well, the poin tis that you really only want a getty if console= was set on cmdline
<ogra> else it doesnt make much sense
<ogra> so the code needs to a) get a kerbel event for the device created and b) still needs to parse the cmdline
<ogra> *kernel
<persia> So, why are we using upstart for this?
<persia> Couldn't we just add a udev script that parsed the command line and optionally launched getty when a serial port was reported?
<ogra> because upstart handles all gettys
<ogra> the code we have is already quite ok, its just not upstreamable
<ogra> because it relies on the fact that the kernel has serial support builtin
<ogra> which is true foe all armel ubuntu kernels but not necessarily for other distros
<amitk> lool: ndec: you can have LP integration for closed bugs with kernel git packages if you commit message contains the BugLink keyword
<persia> ogra: 99% of serial console users in Ubuntu don't run armel.  Please don't make this an arch-specific solution.
<ogra> i will if it doesnt enter maverick in a timely manner
<persia> Why?  Why can't it be an arch-neutral solution?
<ogra> it can if you can guarantee that there is serial support for all ubuntu kernels
<ogra> i know for sure its there for armel
<persia> How much "serial support" do you need?
<ogra> a serial console for booting
<amitk> serial console ++++++++++++++++++++++++++
<persia> But since at least one armel kernel flavour is built from the regular kernel tree, I can't imagine it's a big leap to have it just work.
<persia> The kernel team is trying to collect the set of required configurations for a kernel to be an "Ubuntu kernel".  Just make sure that the necessary CONFIG flags to make that work are on the list.
<persia> And they'll enforce it for all arches (or fail the builds)
<ogra> as i said, if anypone can proof its available in all kernels i have no issue with a autodetect-serial-upstart package or something like that
<ogra> until the kernel is fixed upstream to make it upstreamable in upstart
<ogra> for now my only focus is 10.07 and only armel
<persia> I understand your focus.  I'm just hoping you'd be willing to solve your problems in a way that also solves them for other folks.  Getting that guarantee is just a matter of getting stuff into the required list.  Specify the kernel config you need to the kernel mailing list, and it's very likely to be done.
<persia> And that saves you then having to hunt down each topic branch for the multitude of armel kernels.
<ogra> and i'm not really after pushing a workaround into all arches if there is a proper solution in the pipe
<ogra> its more than the kernel config for a proper solution
<ogra> it will need patches
<persia> We don't get udev events for serial ports?
<hrw> re
<hrw> sorry, was called for emergency
<persia> Well, that makes sense.  What's the proper solution?
<ogra> a kernel event if the console device exists
<ogra> so upstart can use "start on"
<amitk> ogra: that seems to make some sense. No idea how hard it will be to add event support to the console driver(s), though
<persia> Could that cause a race condition with the VC gettys?
<ogra> why ?
<persia> Because they could be consoles, which I wrote before I saw the discussion in -kernel, which makes my question obsolte (and obviouasly underimformed)
<persia> Err, obsolete and obviously underinformed
<ogra> NCommander, persia, i have added work items for both of you to https://blueprints.edge.launchpad.net/ubuntu/+spec/preinstalled-sd-card-images-for-omap
<persia> OK.  I should be able to get mine for Alpha 3, but not likely before.
<persia> (well, rather, sometime after Alpha 2)
<ogra> to late for 10.07 though
<ogra> between A2 and 3 should be ok
<persia> Depends on the freeze date, but likely.
<persia> If you need it sooner, please assign to someone else.
<persia> My (rough) guess would be that I'd be done ~15th July.
<ogra> then i'll do it myself (which i will do anyway but not as deeply as you will i guess)
<ogra> so it will happen in any case
<persia> Shall we plan two passes then?  A quick pass for the obvious "Hey, this is broke" stuff, and a second pass for completeness later?
<ogra> sure
<persia> With first pass for Alpha 2 and second pass for Alpha 3 (ideally both delivered at least a couple weeks early)
<ogra> sounds good
<persia> Great.  That works very well for me.
 * hrw -> lunch break
<ogra> ndec, did NCommander send you an invitation to the mobile team IRC meeting ?
<hrw> lool: s/DH_COMPAT=2 dh_movefiles/dh_install --autodest/g and bumping debian/compat from 5 to 7 solved
<hrw> lool: and that way I got gcc built with dh_isntall instead of dh_movefiles
<lool> hrw: did you debdiff the results?
<lool> hrw: dh_movefiles also renames files, so you need to be careful to mv stuff around before dh_install
<hrw> lool: I crossbuilt maverick gcc-4.4 before and after changes. debdiff said 'no differences'
<ogra> lool, asac, any idea where https://blueprints.edge.launchpad.net/ubuntu-arm/+spec/arm-m-image-builds-without-root went ?
<lool> ogra: to /ubuntu I'm pretty sure
<lool> JamieBennett is mass-moving specs to /ubuntu
<lool> it might also be renamed to mobile- instead of arm- as to allow for separate workitems trackers
<ogra> hrm
<JamieBennett> not renamed yet
<ogra> LP search doesnt find a thing
<lool> hrw: Ah cross-built
<lool> hrw: Please try a normal build (on intel) instead if you can
<lool> hrw: debdiff without and with the changes
<JamieBennett> ogra: just remove -arm ;)
<JamieBennett> the link then works
<lool> hrw: then open a bug against the source package with a debdiff and ask doko for review
<ogra> JamieBennett, merci !!
<JamieBennett> ogra: https://edge.launchpad.net/+search?field.text=arm-m-image-builds-without-root works for me (top hit)
<ogra> well, my top hit went to ubuntu-arm
<ogra> and still does
<hrw> sure
<JamieBennett> ogra: renamed you BP to mobile-* to set its context better. It can now be found at https://blueprints.edge.launchpad.net/ubuntu/+spec/mobile-m-image-builds-without-root!
<ogra> thanks
<lool> hrw: When you're working on a work item, you can set it to INPROGRESS
<lool> hrw: when it's complete (fix released), mark it DONE
<hrw> ok
<lool> hrw: thanks!
<hrw> lool: I miss redmine
<hrw> in my previous job we used redmine for task tracking so it was easy to find who is working on what. now it is more fuzzy I feel
<lool> Hmm, I'm quite at a loss on how to spec rm-m-dpkg-wishlist
<lool> *arm-m-dpkg-wishlist
<zumbi> dpkg wants filters
<zumbi> btw, i am bit confused what decision you made towards sysroot (in cross compilers) is that against multiarch?
<zumbi> IIRC, there was a variable WITH_SYSROOT properly set builds (or almost) sysroot cross compilers
<zumbi> FYI, there was also another variable to provide a canadian cross (have libgcc1 for the target system) called REVERSE_CROSS (or similar)
<zumbi> if you want a pure cross system, keep canadian cross in mind
<lool> zumbi: There is no decision against multiarch
<lool> zumbi: we will use multiarch when it's available
<lool> but that doesn't seem to be the case right now
<lool> hrw: ^ you might be interested in WITH_SYSROOT and REVERSE_CROSS above
<lool> zumbi: sysroot should already be implemented in gcc-4.5
<zumbi> lool: either way is fine for me (at least I have always prefered sysroot way)
<hrw> I noticed reverse_cross/deb_cross stuff already
<hrw> deb_cross is set automatically for cross builds
<zumbi> well, thanks for the work, it is looking great! :)
<hrw> and reverse_cross is not canadian
<zumbi> i hope to have some free time to help out sometime
<hrw> # build != host && host == target : reverse cross (REVERSE_CROSS == yes)
<hrw> # build != host && host != target : canadian (DEB_CROSS == yes)
<hrw> # build == host && host != target : typical cross (DEB_CROSS == yes)
<zumbi> hrw: ok, i was referring to reverse cross then, nowadays, you even need to get a libstdc++ (because lzma dependency on dpkg) for base
<hrw> and for most of situation we want normal build or cross. we can use crossgcc to build reversecross
<zumbi> hrw: i have never tried that crossgcc to build gcc
<hrw> zumbi: I did it a lot with OpenEmbedded
<zumbi> hrw: well, then it should work, but debian is different from OE
<hrw> I know
<zumbi> :)
<hrw> yes ;@
<hrw> hi prpplague
<prpplague> hrw: greetings
<hrw> prpplague: how things?
<prpplague> hrw: not to bad
<prpplague> hrw: staying pretty busy
<hrw> ~curse ubuntu-bug
#ubuntu-arm 2010-05-26
<rai> hi all
<hrw> morning
<zyga> hrw, czesc
<hrw> czeÅÄ zyga
<zyga> hrw, wiesz jaki tag PROGRESS, INPROGRESS, etc trzeba ustawic w work itemach gdy sie nad nimi pracuje?
<zyga> patrzylem na strone pittiego ale tam nikt nie uzywa takich oznaczen
<hrw> moment
<hrw> https://wiki.ubuntu.com/WorkItemsHowto
<amitk> Hi Poland
<zyga> amitk, hi ;)
<hrw> zyga: and do not use any other then listed there
<zyga> hrw, thanks
<zyga> ha, TODO is an alias of INPROGRESS
<zyga> thanks hrw :-)
<hrw> zyga: I got that page from Luic yesterday after using REVIEW tag ;D
 * NCommander waves
<ogra> NCommander, hey
<ogra> NCommander, can you make sure https://blueprints.edge.launchpad.net/ubuntu/+spec/mobile-maverick-arm-improved-subarch-detection and https://blueprints.edge.launchpad.net/ubuntu/+spec/mobile-maverick-softboot-loader have their series goal set to maverick (david needs to approve after you proposed, i could do the proposing  for only one of them)
<ogra> NCommander, oh, and for the subarch one david needs to become the approver
<ogra> else i cant make them show up on http://people.canonical.com/~pitti/workitems/maverick/canonical-mobile.html
<ogra> cooloney, yay, you managed to upload omap4 \o/
<ogra> (though it failed to build)
<hrw> heh... why gcc test suite takes so much time...
<ogra> NCommander, did you see my request above ?
<cooloney> ogra: oh, yeah, too bad. i uploaded it from our server
<ogra> cooloney, see #ubuntu-kernel :)
<NCommander> ogra: no I didn't
<ogra> seems there is an issue with the version detection in the buiold scripts
<NCommander> my internet connection has been *blink* *blink* *blink*
<ogra> <ogra> NCommander, can you make sure https://blueprints.edge.launchpad.net/ubuntu/+spec/mobile-maverick-arm-improved-subarch-detection and https://blueprints.edge.launchpad.net/ubuntu/+spec/mobile-maverick-softboot-loader have their series goal set to maverick (david needs to approve after you proposed, i could do the proposing  for only one of them)
<ogra> <ogra> NCommander, oh, and for the subarch one david needs to become the approver
<ogra> <ogra> else i cant make them show up on http://people.canonical.com/~pitti/workitems/maverick/canonical-mobile.html
<NCommander> ogra: thanks
<NCommander> let me do that
<ogra> great
<NCommander> ogra: and fixed
<ogra> NCommander, great, please hunt down david once he's awake so he sets the right approvals
<NCommander> ogra: will do
<ogra> good :)
 * NCommander is just fixing his network setup so he can boot one of his ARM boxen
<ogra> NCommander, lol
<ogra> you cheated !
<NCommander> ogra: I did?
 * ogra never got the idea to make himself the approver to approve specs and then change them ot the real approver
<hrw> NCommander: that reminded me that I have to remove one 8port ethernet switch and cables of it.
<hrw> it is my FastEthernet switch which was used only for developer boards
<NCommander> ogra: I cna't approve for series goals even as the approval. Just happens my brain did the wrong thing
<NCommander> *approver
<ogra> NCommander, ah, you didnt, you just flipped approver and asignee ! .... do you really expect david to implement the subarch detection ?
<NCommander> I did?
<ogra> *g*
<NCommander> *sighs*
 * NCommander fixes it
 * NCommander also reachs for the coffe cup
<ogra> well, you could leave it
<ogra> would be funny if you approve davids work now :)
<NCommander> ogra: I'm on the fence w.r.t. to going from genext2fs to loopmounting
<ogra> NCommander, please dont
<NCommander> ogra: please dont what?
<ogra> please stick with the specced way
<ogra> did you try it on your babbage now ?
<ogra> with a proper size value
<NCommander> ogra: it works kinda now once I stuck a swapfile on my system
<ogra> right, make sure to have at least 2G of swap
<NCommander> ogra: but I still have consistancy issues with getting tune2fs to work if I don't pad a little spot of the image
<ogra> hmm
<ogra> i dont have that here and i dont see OE or angstrom adding extra space for it
<NCommander> ogra: I still think 10MiB of scratch space is a good thing just so jasper has some room to write stuff before expanding the partition table
<ogra> so i wonder why you need it
<NCommander> maybe I just fail, but I got tune2fs: No space on device when I tried it
<ogra> the partition will not be mounted before it is expanded
<NCommander> oh
<NCommander> hrm
<ogra> so there is no reason to leave any space
<NCommander> ogra: the other issue with genext2fs is we can only use ext3
<hrw> ogra: OE expands ext images
<NCommander> That may not be a big issue, but I think we might want to consider using ext4 images so at least we're consistant w.r.t. normal installs
<ogra> the first thing jasper will do is expand the partition, zero out the UUID and run fsck to create a new one
<ogra> hrw, but OE doesnt add extra space when using genext2fs
<hrw> OE has default size set and if rootfs fits in it then no expanding.
<ogra> before running tunex2fs
<ogra> hrw, exactly
<hrw> ogra: and if rootfs does not fit then ext size is expanded by defined amount
<ogra> indeed
<hrw> ogra: I wrote expansion code
<ogra> in our case we determine the size of rootfs before running genext2fs
<hrw> same as in OE
<ogra> which means the image will have exactly the right size for it to fit
<hrw> OE adds few MB
<ogra> hrw, hmm, where ? i didnt see that in the code
<hrw> moment
<hrw> ogra: 134         ROOTFS_SIZE=`du -ks ${IMAGE_ROOTFS}|awk '{size = ${IMAGE_EXTRA_SPACE} + $1; print (size > ${IMAGE_ROOTFS_SIZE} ? size : ${IMAGE_ROOTFS_SIZE}) }'`  in classes/image.bbclass
<ogra> hrw, what is the value of ${IMAGE_EXTRA_SPACE} ?
<hrw> ogra: 10240 by default
<ogra> ok
<hrw> so extra 10MB
<ogra> http://docs.openembedded.org/usermanual/html/image_types.html doesnt say that
<hrw> OE manual is known to be not up-to-date ;(
<ogra> aha
<ogra> NCommander, so your code is fine then, i followed outdated docs apparently :P
<NCommander> ogra: woo, I've been vidicated!
<ogra> though i still didnt have any issues using tune2fs
 * ogra wonders why
<NCommander> ogra: statistical improbability?
<NCommander> hrw: any reason you don't use loopmounting?
<hrw> NCommander: in OE?
<ogra> NCommander, needs root
<hrw> NCommander: OE refuses to work as root
<ogra> NCommander, you *could* use fuseext2 though
<ogra> but i'm not sure about the permissions you end up with in the image afterwards
<ogra> genext2fs seems a lot safer in that regard
<hrw> NCommander: with OE you run one command and collect packages/images/sdks after some time. all is done as one process tree. running it as root would be insane (think "make install" in glibc/arm on !arm host). and with some build configurations one build can run for few weeks even
<hrw> NCommander: my longest build took 2 weeks on dualcore amd64. but it was for ~30 targets on 6 architectures
<ogra> ours only runs 30-40min for a 1.5G image
<NCommander> hrw: makes sense to me,
<ogra> and we'll create at most two image types
<hrw> ogra: with binary packages...
<ogra> yes
<NCommander> hrw: although we're generating the images on a machine running as root
<NCommander> so ...
<hrw> ogra: OE builds packages
<ogra> oh, indeed, OE builds everything
<hrw> Oe can be told to fetch packages anyway. I had such setups
<ogra> right, that would be similar to our setup
<ogra> NCommander, btw, being able to optionally build an ubuntu-minimal image (probably with openssh-server added) would be a nice to have, would be good if you could take that into account while coding ;)
<ogra> i exepct there are some use cases for having a preinstalled developer image
<NCommander> ogra: we already have a base image type
<ogra> right, but not built in a preinstalled mannaer
<NCommander> ogra: although without a seed, that won't be germinatable and d-cd will explode
<ogra> *manner
<ogra> d-cd ?
<hrw> debian-cd?
<NCommander> ogra: it tries to germinate to populate pool. I'll fix it so it won't do that on pre-installed images
<ogra> the image comes from livecd-rootfs
<NCommander> but I haven't gotten quite that far yet
<ogra> what has germinate to do there ?
<rai> can anybody tell me the exact flow of rootstock script
<rai> why it uses two kernerl
<NCommander> ogra: its just being called currently during image creation, I need to fix that
<NCommander> (on the d-cd side, not in livecd-rootfs of course)
<ogra> rai, debootstrap (into an armel chroot), roll an image out of that, run VM, install the tasks and configure, create a tarball from the image, clean up the build environment
<ogra> rai, it only uses one kernel, the kernel for the VM
<NCommander> ogra: anyway, I think the base images are used for something special w.r.t. to sanity on antimony, we probably want an ubuntu-minimal image thats command line only + openssh + jasper
<ogra> NCommander, exactly
<ogra> and that from livecd-rootfs :)
<ogra> as ext3 image
<rai> ogra but it first download deb from external site and second for virtual machine
<ogra> rai, not by default
<hrw> rai: first it fetch debs for minimal system and then runs that minimal and fetch next sets of packages
<ogra> rai, there is an unsupported --kernel-image option the beagle people use for test kernels in their images
<ogra> you should only use that if you really want to run such test kernels
<ogra> the default run just uses the VM kernel to run the VM
<rai> so it is not necessary to pass any kernel image
<berco> hello! I have a question on the debian packaging, specifically the debian/control file. This file contains a "Sections" field and have problems finding out what value I should chose for my case. Does anyone have familiarity with this topic?
<hrw> berco: debian packaging policy is what you need I think
<berco> hrw: according to this link http://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections I need to chose from the list
<dmart|armel> or install the ubuntu-policy package
<berco> thanks, since I'm a bit new the packaging I'll first look at this ubuntu-policy package
<dmart|armel> It's just a load of docs, but I think the info you're after is in there
<rai> ogra: exactly what debootstrap creates
 * NCommander feels exhausted :-/
<NCommander> ogra: if we want a minimal image that's pre-installed, we need to do it correctly with seeds and such
<ogra_cmpc> NCommander, a new seed ? why not just use the one we have ?
<ogra_cmpc> (we already have minimal and standard)
<rai> ogra_cmpc, what exactly debootstrap does
<berco> dmart|armel: the documentation package contains what I had online in my link above. What I was looking for is what would be the appropriate section from this list: admin, cli-mono, comm, database, devel, debug, doc, editors, electronics, embedded, fonts, games, gnome, graphics, gnu-r, gnustep, hamradio, haskell, httpd, interpreters, java, kde, kernel, libs, libdevel, lisp, localization, mail, math, metapackages, misc, net, news, ocaml, oldlib
<berco> I believe if my packages contain drivers I could chose "embedded" but I'm not sure
<ogra_cmpc> rai, man debootstrap should tell you :)
<rai> ogra_cmpc, i go through but i didnt get exactly please tell me in rootstock script what exactly it does
<dmart|armel> berco: I guess it depends on what your drivers are for
<ogra_cmpc> rai, it bootstraps a basic ubuntu system
<berco> dmart|armel: omap platforms
<rai> it creates basic ubuntu file system for arm
<rai> ????
<ogra_cmpc> debootstrap cretes an unconfigured munumal filesystem
<ogra_cmpc> *minimal
<dmart|armel> berco: I notice that kernel packages tend to be in "admin"
<ogra_cmpc> in the case of rootstock its for arm, yes
<berco> dmart|armel: thx. strange they don't fall into "kernel". It's not all crystal clear to me yet
<ogra_cmpc> berco, i dont think we make any active use of the section filed in ubuntu, probably packages.ubuntu.com does though for the web indicies
 * ogra_cmpc waits for persia to correct him :)
<berco> ogra_cmpc: I see. "Section" is not mandatory but as it was "recommended" I thought I would fill it
<rai> ogra_cmps, in that script  run_vm() function what does exactly
<ogra_cmpc> rai, it runs a VM :)
<rai> ogra_cmps , yes i got it but what does after running VM it displays Configuriang....    Unpacking.....    what is doing exactly????
<ogra_cmpc> it is installing the package task you selected inside the VM
<rai> that means seeds pass to script
<ogra_cmpc> well, to apt, but yes
<rai> ok and qemu-system-arm what it does actully??
<ogra_cmpc> it is the VM
<rai> but what it does
<rai> ????
<cooloney> ogra_cmpc: my second upload was rejected because of The source linux-ti-omap4 - 2.6.33-900.1 is already accepted
<ogra_cmpc> it executes a virtual machine
<cooloney> ogra_cmpc: is that possible to remove my first upload
<cooloney> and i upload my new version?
<NCommander> cooloney: you have to bump the version number.
<ogra_cmpc> cooloney, hmm, ask in #launchpad, i think it requores an admin, not sure
<ogra_cmpc> or that
<NCommander> cooloney: there's a hardcoded sanity check to prevent you from uploading the same version number more than once
<cooloney> NCommander: i don't wanna to bump the ABI, since that's my first upload,
<rai> ogra_cmpc ,  is this VM uses ubuntu basic minimal file system created using previous process og debootstrap
<rai> *og of
<cooloney> although the first upload build failed
<ogra_cmpc> i think there is a button to remove uploads, let me check
<ogra_cmpc> rai, right
<rai> ogra_cmpc , is it right??
<NCommander> ogra_cmpc: cooloney that will not let you upload with the same version :-/
<ogra_cmpc> cooloney, i deleted it but please see https://help.launchpad.net/Packaging/PPA/Deleting
<ogra_cmpc> cooloney, according to that it can take 30min or more
<cooloney> ogra_cmpc: thanks a lot, i will wait to 6:35pm in my TZ
<ogra_cmpc> (up to 7 days)
<ogra_cmpc> if it doesnt work at all, you need to talk to the lp admins in #launchpad
<ogra_cmpc> rai, yes, this is right
<rai> ogra_cmpc ,  ok after can i use that armel.tgz file kernel for beagleboard??
<ogra_cmpc> rai, why not use one of the officil beagle images ?
 * ogra_cmpc points rai to https://wiki.ubuntu.com/ARM/Beagle
<rai> ok but for testing
<rai> ok thanks
<ogra_cmpc> there are also unofficial images (with the test kernels i mentioned above) at http://elinux.org/BeagleBoardUbuntu
<rai> ogra_cmpc , can we get repository or packages required during debootstrap and second stage processing from local machine insted of internet
<ogra_cmpc> yes, if you have an archive mirror or a package proxy
<rai> but how ??
<ogra_cmpc> just point to the mirror
<rai> i dont know the exact way???
<rai> no i did not get exactly wht u say
<hrw> rai: install squid-deb-proxy
<hrw> rai: and then "sudo http_proxy=localhost:8000 rootstock ...."
<hrw> rai: first use will populate cache for next builds
<ogra_cmpc> or use the --mirror arg
 * ogra_cmpc points once again to the manpage
<hrw> ogra_cmpc: squid-deb-proxy is easier to seetup then local mirror
<ogra_cmpc> hrw, well i massively prefer approx, but yes
<rai> ok but wht it does exactly??
<ogra_cmpc> hrw, oh, and localhost will definately not work
<hrw> ogra_cmpc: so 127.127.127.127:8000 :D
<ogra_cmpc> you always need to use the external IP else the VM will point to itself ;)
<hrw> ogra_cmpc: I used vm-builder not rootstack
<ogra_cmpc> rootstock ... --mirror http://192.168.2.87:9999/ubuntu-ports is what i use with my approx instance for example
<hrw> ogra_cmpc: does it works for debs not in your mirror?
<ogra_cmpc> sure
<ogra_cmpc> approx is just a package proxy
<hrw> ok
<ogra_cmpc> it automatically pulls whats missing
<ogra_cmpc> and *only* pulls the packages i have used before
<ogra_cmpc> way way smaller than a local mirror
<rai> ogra_cmpc, what is vm-builder
<ogra_cmpc> a tool to build vm images
<ogra_cmpc> it has no support for arm yet, hrw is just adding it
<hrw> yeah, need to boot laptop and grab latest ver
<ogra_cmpc> hrw, ogra@osiris:~$ du -hcs /var/cache/approx/
<ogra_cmpc> 1,8G	/var/cache/approx/
<ogra_cmpc> that has all pacckages i used from main since jaunty
<ogra_cmpc> compare that to a real mirror for three releases :)
<ogra_cmpc> (and i'm building netbook and desktop for each release at least once)
<hrw> nice
<rai> grw, i trying to install squid-deb-proxy but it gives error E: Couldn't find package squid-deb-proxy
<rai> hrw, i trying to install squid-deb-proxy but it gives error E: Couldn't find package squid-deb-proxy
<hrw> 12:23 hrw@home:~$ apt-cache search squid deb proxy
<hrw> squid-deb-proxy - Squid proxy configuration optimized for deb packages
<ogra_cmpc> its in univers though
<rai> yes i found it..
<rai> but it gives error package not found
<NCommander> ogra_cmpc: http://paste.ubuntu.com/439822/ - progress is being made :-)
<ogra_cmpc> NCommander, sweet !!!
<NCommander> ogra_cmpc: it gets pretty far into d-cd before exploding into a pile of exceptions, but I think I got the hard part done.
<ogra_cmpc> why is it so big though ?
<ogra_cmpc> my armel netbook is only 1.4G
<NCommander> ogra_cmpc: guess its bigger on amd64
<ogra_cmpc> oh, you build amd64
<ogra_cmpc> yeah
<NCommander> Yeah, I'm just doing that so I can spin faster
<ogra_cmpc> OO.o and evolution
<NCommander> yup
<ogra_cmpc> NCommander, btw, you chould make sure the ext3 image is depleted too, your code only deletes the squashfs one
<aaron_liuj> Illegal instruction
<aaron_liuj> wahy
<aaron_liuj> why Illegal instruction
<NCommander> ogra_cmpc: yeah, I saw that and fixed it already ;-)
<ogra_cmpc> NCommander, and make sure the .size file contains the size you actually use
<ogra_cmpc> (not sure the file is actually used but it should have a correct value, so overwrite it if you compute your value)
<aaron_liuj> why Illegal instruction
<aaron_liuj> Illegal instruction
<ogra_cmpc> aaron_liuj, context ?
<NCommander> ogra_cmpc: size is used by livecd-rootfs, I don't think its used by d-cd although I'm not 100%. The diff for d-cd is going to be fugly
<aaron_liuj> no
<ogra_cmpc> i think its used by the web indicies etc
<ogra_cmpc> and might be udes by ubiquity/oem-config, not sure
<ogra_cmpc> *used
<aaron_liuj> i compile a applicaion ,but it used other lib with another compiler
<aaron_liuj> i compile a applicaion ,but it used other lib compiled by another version compiler,when i runs the application ,errors occur Illegal instruction
<ogra_cmpc> so use the correct lib for your compiler or the right compiler for the lib
<ogra_cmpc> what are you building and how do you build it ?
<aaron_liuj> but i have not the  lib source and
<ogra_cmpc> thats tricky then
<aaron_liuj> compiler verion even don't known
<ogra_cmpc> you really need to give more context, what lib, what app, how do you try to build it etc etc
<aaron_liuj> just readelf -a and find the compile different from my used
<ogra_cmpc> well, if it was built using a different toolchain and compiole options its unlikely you can make it work
<aaron_liuj> the app is our company
<aaron_liuj> the app is our company ,but the lib is another company
<aaron_liuj> the app is comer from our  company ,but the lib is come from another company
<NCommander> ogra_cmpc: I'm thinking to simplify d-cd code, it might be better to have the preinstalled image generated to always be livecd.project.preinstalled instead of livecd.project.filesystem unless we have a usecase for wanting multiple filesystems per subarch/target
<ogra_cmpc> please discuss that with cjwatson, i'm not sure we dont rely on the naming scheme somewhere
<ndec> ogra: hi! looks like the problem we used to have on OMAP3 with the boot partition and ROM code not able to find MLO is gone for OMAP4
<ogra_cmpc> else, no objection
<ogra_cmpc> ndec, wohooo !!!
<NCommander> ogra_cmpc: this is completely new code, so if we just add it as .preinstalled instead of .*, it makes life a lot cleaner
<ogra_cmpc> NCommander, sure, just make sure it doesnt break existing code
<ndec> ogra: as such, we could have a single image with all flavors of MLO, uboot, ... on the boot partition, e.g. MLO-board1, MLO-board2 and have a script to switch from 1 board to the other
<NCommander> ogra_cmpc: not sure how, considering I just changing the name in squash_ext2 :-)
<NCommander> but will test heavily regardless
<ogra_cmpc> ndec, yeah, to sad vfat doesnt support symlinks though :)
<hrw> uf.. gcc-4.5 build goes to packaging
<NCommander> ogra_cmpc: for the image name itself, is $(CODENAME)-preinstalled-$(FULLARCH) acceptable, or do we want something like $(CODENAME)-preinstalled_desktop-$(FULLARCH) (I'm kinda afraid to make the if in the d-cd Makefile any bigger though; its already scary)
<NCommander> (or well, preinstalled netbook)
<hrw> NCommander: so maverick-preinstalled-armel?
<ogra> hrw, nope
<ogra> needs to have the flavour
<ogra> and the subarch
<ogra> NCommander, can you shorten preinstalled to preinst or some such
<hrw> maverick-preinstalled-netbook-omap3 etc atleast
 * ogra would love to use oem but that gets to confusing
<ogra> hrw, maverick-netbook-preinst-armel+omap.img.bz2
<ogra> and maverick-netbook-preinst-armel+omap4.img.bz2
<hrw> nice
<ogra> we always have $release-$flav-$arch+$subarch.$type
<NCommander> ogra: ugh, that's going to make that Makefile if statement even worse :-/
<NCommander> Suppose it can't really be helped
<ogra> you just add preinst and compression to the naming scheme
<ogra> so instead of $release-$flav-$arch+$subarch.$type you have $release-$flav-preinst-$arch+$subarch.$type.$comp
<NCommander> ogra: that's not hte problem :-)
<NCommander> the problem is:
<ogra> else we get massive probs with the make-web-indicies scripts
<NCommander>      ifeq ($(PROJECT),ubuntu-server)
<NCommander>  CDBASE = $(CODENAME)-live-$(FULLARCH)
<NCommander>      else
<NCommander> And a hell of a lot mor elines like that
 * NCommander thinks he just needs to rewrite the in a less-than-evil sorta way
<NCommander> s/in/if
<NCommander> ogra: I think we need to do compression in the publish step, not part of the actual image creation
<NCommander> but we can solve that problem as we come to it
 * hrw â lunch
<ogra> NCommander, i'd like to do it as early as possible to save disk space
 * NCommander likes hrw's use of unicode
<ogra> dont forget we're low on space on antimony
<NCommander> ogra: how low?
<ogra> we couldnt publish the omap images until space was freed up for lucid
<NCommander> The current design mimics the way normal live images store their squashfs until cleaned automatically in scratch
<NCommander> I'm guessing that won't work so well by having 2-3 2GiB images sitting around :-/
<ogra> i would have proposed to do the compression in livecd-rootfs ... but the imx51 CPU will take ages to compress 1.5G
<NCommander> ogra: can't compress until after we run the post-boot scripts
<ogra> why ?
<NCommander> We won't have a valid filesystem on the SD card
<ogra> nothing will ever touch the image
<ogra> ??
<NCommander> if we compress on the live image builders, we'll have a compressed ext2 image
<ogra> you use the imx51 scripts to build it, right ?
<NCommander> right
<ogra> well, ext3 but yes
<NCommander> those expect an uncompressed image coming in
<ogra> oh, crap, indeed
<NCommander> It really doesn't buy us much to compress it just to uncompress then recompress it
<NCommander> :-)
<ogra> we compress at the very end when we have both partitions in place
<NCommander> right
<ogra> hmm
<ogra> well, i guess we have to live with that then
<NCommander> But we'll have to dump the folder with the preinstalled images downloaded from the live builder
<NCommander> :-/
<NCommander> So we will probably need upwards of 4GiB to build an image until we delete the incoming files
<NCommander> Ugh
<NCommander> that's going to be freaking tight
<ogra> the cdimage dir has 74G free atm (from 1.6TB)
<ogra> its not different to a DVD after all
<NCommander> That's fine then. Once we compress the image, we can probably get it to the size of a normal image in www/
<ogra> my compressed netbook image was 411MB
<rai> ogra , squid is decreases server load and fast content delivary so how it help in rootstock script
<NCommander> We probably just want to do some early cleanup to prevent space from being a huge issue
<ogra> so with the second partition (and given i didnt install oem-config in the image) we'll likely end up with a 500 to 550MB image
<ogra> NCommander, as soon as we have compressed we should clan up scratch
<ogra> *clean
<rai> hrw, squid is decreases server load and fast content delivary so how it help in rootstock script
<ogra> even though i already hear cjwatson screaming, that seems to be the best
<ogra> rai, you wont have to download over and over again for subsequent builds
<rai> ok.. but if i wnt to use my local repository to build basic minimal rootfs how can i create ??
<NCommander> ogra: http://paste.ubuntu.com/439858/ - I win
<NCommander> (I think)
<ogra> i dont see it finishing any build
<ogra> i pinged cjwatson in -release btw to see if we can wipe scratch/ right after build
<NCommander> ogra: ?, it does
<ogra> where ?
<NCommander> I get the raw (the publishing scripts don't know to publish preinstalled images yet, so I haven't written that code yet)
<ogra> ah
<NCommander> s/so//g
<ogra> well, i only see it attempting an alternate build
<NCommander> ogra: it looks like an alternate build because some of the scripts to refresh APT are in build_all.sh, and I don't want if statements all over the place; they're harmless for what we see now
<NCommander> (the same messages are there on live builds as well)
<ogra> ok
<NCommander> ogra: you don't put MLO/u-boot.bin on omap images right? (you made it so that we require NAND bootloader on first boot, right?)
 * NCommander has a script that makes the VFAT partition correct on the first go
<ogra> NCommander, for lucid ... for maverick we want MLO and u-boot.bin in the vfat
<ogra> as well as for 10.07
<NCommander> ogra: oh good, I was just concerned when I ended up with an empty vfat
<NCommander> :-)
<ogra> that will be the most tricky part btw
<NCommander> ogra: not really, there's a shell script to do it right already
<ogra> MLO dees to live in block 1 of the vfat for omap3
<ogra> *needs
<NCommander> http://www.xora.org.uk/2009/08/14/omap3-sd-booting/
<NCommander> same with Blaze
<ogra> else it will not boot
<NCommander> and that works fine with Blaze
<ogra> for omap4 it doesnt matter where MLO lives
<ogra> you can just copy it in
<NCommander> my Blaze won't boot if MLO wasn't first block
<NCommander> regardless, its a solved problem, we can fix it as we go
<NCommander> just wanted to make sure that an empty vfat was sane
<ogra> NCommander, well, according to ndec above MLO can live where it likes on the vfat
<NCommander> ogra: hrm
 * NCommander shrugs
<ogra> the point is that we want MLO to be replaceable easily
<NCommander> I admit I haven't toyed with MLO a lot after I got my Blaze to boot ;-)
<ogra> since the image will be used on different HW that uses different bootloaders but the same kernel
<NCommander> ogra: ah
<ogra> see the spec :P
<ogra> [ogra] Create documentation and/or scripts to replace the bootloader in the boot partition for using the images with all HW the kernel supports: TODO
<ogra> NCommander, so we're fine to wipe the raw ext3 images after d-cd finished
<ogra> so add some code to clean up scratch/ for that image
<NCommander> ogra: where'd you talk to Colin?
<ogra> #ubuntu-release
<NCommander> ogra: hrm, that fell off my AJOIN :-/
<ogra> NCommander, btw, how do you determine the number of cyls in the vfat script you pointed to ?
<ogra> (in an image i mean)
<hrw> lool: have a minute?
<NCommander> ogra: I'd assumed it was sfdisk options, but this script gave me a VFAT that worked for both omap3 and 4, even if MLO wasn't copied in first
<ogra> NCommander, in an image ?
<ogra> or in SD ?
<lool> hrw: I do
<hrw> cool
<hrw> lool: https://bugs.launchpad.net/ubuntu/+source/gcc-4.4/+bug/585439 - doko gave few suggestions
<lool> hrw: How may I help?
<ubot2> Launchpad bug 585439 in gcc-4.4 (Ubuntu) "migrate to debhelper7 (affects: 1) (heat: 10)" [Undecided,Incomplete]
<hrw> lool: I can generate version without --autodest for gcc-4.4 I think but one thing is differ in how dh_install works and doko base on it
<hrw> lool: dh_install only copies files so after all packaging was done you cant easily check which files were not packaged.
<lool> hrw: So the two remarks in the bug are about --autodest, I didn't know whether it was needed or not myself either
<lool> hrw: if it's not needed, don't add the flag
<lool> hrw: Now concerning the other remarks of checking whether files are all installed, there are two ways to achieve this, one is --list-missing
<hrw> it was first version of patch thats why autodest was used
<lool> (and --fail-missing)
<lool> However I believe this only works if you have a single dh_install call
<lool> The other way to achieve this is by hand
<hrw> do dh_movefiles -> dh_install + rm?
<lool> Basically doing find on debian/tmp (or wherever things are installed) and on the packages dirs to see whether all files are there
<hrw> generate list of installed and packaged and then show diff? that kind of?
<lool> hrw: I would personally find dh_install + rm ugly, but there's an argument for it in terms of needed space (if you move, you use less space than if you copy)
<hrw> space is cheap
<lool> the reason rm is ugly is because if you fail in the binary-indep/binary-arch targets, you need to rerun the make install target
<hrw> and if buildd has a problem with space then let someone connect 1.5TB drive to it
<hrw> lool: will check with comparing installed/packaged list of files
<lool> hrw: You might want to ask about which way doko would prefer it in the bug too
<hrw> thats what I plan now
<lool> hrw: You can ping him on #ubuntu-devel if you have questions
<hrw> will do this too
<NCommander> ogra: on an SD card directly
<ogra> right
<ogra> i suspect for images that will become problematic
<ogra> but i trust you to find a solution ;)
<ogra> NCommander, did you ask davidm already to change your specs ?
<ogra> i still dont see them on the tracker
<NCommander> ogra: looking at the OMAP scripts, you create the FAT partition, but you don't seem to stick an entry in the MBR for it properly, am I missing something?
<ogra> NCommander, the omap scripts are a bare copy of the dove scripts :) in lucid we dont need MBR or anything since we dont ship a bootloader there
<NCommander> ogra: ah, that's why I'm loosing my mind trying to find a non-existant bug :-). I ran the preinstalled image generation through the imx51 generation scripts, and presto, I got two partitions
<NCommander> Number  Start   End     Size    Type     File system  Flags 1      0.51kB  33.6MB  33.6MB  primary                     2      33.6MB  496MB   463MB   primary  ext3         lba
<NCommander> so I think we can call this a working prototype
<NCommander> I need to look at the code and remove some of the crack I added
<NCommander> but I say we're moving along nicely
<NCommander> wb ogra
<ogra> mumble
 * ogra cuses that norwegian guy
<comradekingu> ogra: ooooodin?
<ogra> comradekingu, nope ...
<ogra> peer
<ogra> he resets my connection !
<ogra> (Connection reset by peer).
<comradekingu> :)
<comradekingu> It would be sweet to have odin error messages though
<ogra> heh
<comradekingu> Loki was found in your network configuration, by draupnir, odin shall make amends, meanwhile at your place, no wifi
<ogra> lol
<hrw> bye all
<prpplague> davidm: there a trick to getting ubuntu-arm working with a nfs root?
#ubuntu-arm 2010-05-27
<DanaG> - Linux >= 2.6.20 with I/O accounting support (CONFIG_TASKSTATS, CONFIG_TASK_DELAY_ACCT, CONFIG_TASK_IO_ACCOUNTING): Not found
<hrw> morning
<zyga> hi hrw!
<amitk> morning .pl
<zyga> amitk, hey, how are you
<amitk> good, how is the flooding situation in .pl?
<ogra> amitk, it roughly moved on to germany now
<amitk> ogra: ohh?
<ogra> the oder flows from poland through germany
<ogra> i think the highest levels are done in poland and move down the river now
<hrw> ogra: Poland is big country - flood to my city has not yet arrived
<ogra> oh, wow
<hrw> but Szczecin is prepared for Odra flood
<hrw> we have lot of space for water where no one is allowed to live
<ogra> german news said the hump would arrive at the german boarder last night
<hrw> and bigger problem is not water from south but from returning water from Baltic Sea
<hrw> Szczecin tomorrow/Saturday   iirc
<ogra> yeah
<ogra> oh, right, Szczecin comes after it went through germany
<hrw> zyga: sent
<zyga> hrw, did you get a bounce?
<zyga> hrw, I suspect you did what I did some time ago
<hrw> zyga: I just sent it again though my own smtp
<zyga> hrw, I think you have to send it thru google's own SMTP using "that" domain's account to actually reach your recipients
<zyga> brb
<hrw> zyga: smtp is smtp - as long as email is delivered
<zyga> back
<zyga> hrw, yeah but google seemed to block my other address, anyway the message is away
<zyga> hrw, I wonder what people think
<zyga> hrw, -> (other chan)
<ogra> ndec, https://wiki.ubuntu.com/MaverickReleaseSchedule
<amitk> hmm, http://paste.ubuntu.com/440283/ wonder what is happening at line 595 for nfsroot
<amitk> ogra: ^ any ideas
<ogra_cmpc> amitk, i remember there were mountall issues with nfsroot, not sure they are already solved
<ogra_cmpc> i guess we need to talk to Keybuk
<ogra_cmpc> amitk, https://bugs.edge.launchpad.net/ubuntu/+source/mountall/+bug/537133
<ubot2> Launchpad bug 537133 in portmap (Ubuntu Lucid) (and 3 other projects) "mountall issues with NFS root filesystem (affects: 10) (dups: 2) (heat: 72)" [Medium,Fix released]
<ogra_cmpc> ubot2, liar !!
<ubot2> Factoid 'liar !!' not found
<ogra_cmpc> (its not fix released for mountall, only for portmap)
<amitk> ogra_cmpc: hmmm... not sure if the second issue is similar to min.
<amitk> *mine
<ogra_cmpc> there is also https://bugs.edge.launchpad.net/ubuntu/+source/mountall/+bug/578851
<ubot2> Launchpad bug 578851 in mountall (Ubuntu) "Fail to remount root on nfsroot install (affects: 1) (heat: 6)" [Undecided,New]
<ogra_cmpc> though you dont seem to have /dev/nfs in your fstab
<ogra_cmpc> amitk, erm, do you use an initramfs ?
<ogra_cmpc> doesnt look like it
<amitk> ogra_cmpc: no
<ogra_cmpc> i dont think nfs support is compiled in
<amitk> ogra_cmpc: it is
<ogra_cmpc> hmm
<amitk> and /dev/nfs is in my /etc/fstab for the remote root fs
<ogra_cmpc> did you try with initramfs ?
<ogra_cmpc> i bet it would work
<amitk> ogra_cmpc: no, and to be honest I don't want to. I want to be able to boot-test several different arm boards. Compile kernel and copy to webserver. And the board gets its rootfs over nfs
<amitk> there is not .deb packaging around these kernels, straight mainline + patches
<ogra_cmpc> ootserver=192.168.0.254, rootserver=192.168.0.101, rootpath=
<ogra_cmpc> seems your rootpath doesnt get handed over properly
<ogra_cmpc> line 454
<ogra_cmpc> try with explicitly setting rootpath=/shared/nfs
<ogra_cmpc> and see if IP-config gets it then
<ogra_cmpc> else i'd actually say its an IP-Config bug
<amitk> indeed, good catch
<ogra_cmpc> also is your export in the server side proper ? (try to mount it rw from somewhere else)
<amitk> ogra_cmpc: yeah tried that
<ogra_cmpc> while rootpath isnt set it obviously gets to mountall, so it must have acessed it
<amitk> ogra_cmpc: it should get the rootpath or equivalent from the kernel cmdline
<ogra_cmpc> (though i dont know if mountalal doesnt try to grab rootpath ... if its empty it likely doesnt know what to do)
<ogra_cmpc> *mountall
<ogra_cmpc> well, in initramfs we have a special script that parses nfsroot and actually exports rootserver and rootpath, might be that mountall relies on that
<ogra_cmpc> see /usr/share/initramfs-tools/scripts/nfs
<ogra_cmpc> amitk, heh, do you have devtmpfs support compiled in ?
<amitk> ogra_cmpc: yes, I saw that mount option for /dev and added it in last night :)
<ogra_cmpc> i dont see it listed between 461 and 484
<amitk> doesn't ltsp use nfsroot?
<ogra_cmpc> nope
<ogra_cmpc> nbd
<ogra_cmpc> nfs is dog slow compared to an nbd exported squashfs
<ogra_cmpc> amitk, try editing /lib/init/fstab and remove devtmpfs there (just keep tmpfs)
<ogra_cmpc> i would bet that makes it boot
<ogra_cmpc> though that still leave the question why parse_filesystems doesnt swee it
<ogra_cmpc> *see
<ogra_cmpc> parse_filesystems just loops over /proc/filesystems
<amitk> ogra_cmpc: ok, it gets stuck at the next step now, /dev/shm
<ogra_cmpc> hmm
<ogra_cmpc> tmpfs is clearly found
<ogra_cmpc> though in your log it seems that all tmpfs mounts have issues too
<zumbi> hrw: i still intent to work on DB#577674 if you do not beat me, but not before 1-2 months
<hrw> zumbi: ah... its your bug :)
<zumbi> hrw: sure, feel free to add (if you consider) my comments so doko is aware
<hrw> doko gave mi that bug number
<zumbi> hrw: yes, that is current work
<zumbi> at least to my concern
<zumbi> help is very much welcome :-)
 * hrw â lunch
<ndec> amitk: when i look at ubuntu kernel tree, i can see tags such as Ubuntu-2.6.34-1.1. what does the 1.1 mean? how does it related to mainline tag?
<amitk> ndec: it doesn't relate to the mainline tag. It is Ubuntu's internal abi versioning. So 1.1 means abi version 1, upload 1.
<amitk> 1.2 would be same abi but new upload
<ndec> amitk: ok, thx.
<amitk> ndec: this is to make sure all external modules/packages depending on internal abi are recompiled when a new kernel abi hits the archive
<amitk> e.g. the dkms packages for the binary -nvidia and -ati drivers use this
<ndec> amitk: so how do you decide if there is an abi change?
<amitk> ndec: automated scripts (debian/script/abi-check) are run after a new kernel build. If the hashes for internal functions have changed, the build will fail if we haven't changed the abi version in debian/changelog
<berco> Has anyone used the "edit-patch" from ubuntu-dev-tools package? I'm trying to use it but it complains about "Patch system can not be detected ...." And I use quilt in my case. Any help appreciated.
<ndec> amitk: thx!
<lool> berco: You could set -x it and see where it fails
<lool> berco: It might not be detecting a quilt build-dep or a quilt rules include
<berco> lool: thx. Apparently the script is looking for some file that I'm missing: "debian/patches/series"
<lool> berco: Yes, that's the expected place for your quilt series
<lool> berco: You probably want such a file with the list of patches if you're using
<lool> quilt
<berco> I have quilt installed but I'm now trying to find some doc as to what "series" is supposed to do
<lool> berco: series is a list of filenames
<lool> of patches to apply
<lool> the files should be below debian/patches
<lool> berco: You might want to look at existing packages using quilt?
<lool> berco: e.g. apt-get source gconf2
<berco> lool: thanks. I think I got confused and thought I could use "edit-patch" to create a new patch.
<lool> berco: That's the goal I think
<lool> berco: quilt provides commands to do this as well
<berco> lool: but if I create a new patch "series" potentially doesn't exist for the 1st patch
<berco> so I need to create it empty?
<lool> Yes
<berco> lool: many thanks. "touch debian/patches/series" is enough to start working with "edit-patch" :)
<lool> berco: Cool  :)
<lool> hrw: No need to put your name before work items in brackets because you're the assignee
<lool> hrw: we only do that when someone not the assignee helps with the spec
<hrw> no need but I can - right?
 * ogra always puts his name in front ... 
<ogra> ... to honor the Department Of Redundancy Department
<lool> hrw: it's a bit cluttering, but you can yes
<zyga> lol :-)
<ogra> hrw, there seems to be a kernel that spits out console= into upstart environment at https://edge.launchpad.net/~apw/+archive/green/+packages
<ogra> seems like we'll get that for all meverick kernels soon
<ogra> *maverick
<hrw> cool
<hrw> CONFIG_INIT_PASS_ALL_PARAMS
<ogra> yeah
<hrw> ubuntu addon
<ogra> right
<ogra> yet :)
<amitk> will go upstream if they want it
<hrw> patch is small and quite nice
<ogra> should definately be good enough to base the autotty code on
<hrw> yep
<hrw> waiting for omap3 kernel with it
<ogra> up to amitk or cooloney i guess
<ogra> or mpoirier
<ogra> not sure who is supposed to take the omap3 maverick kernel
<ogra> cooloney is likely busy enough with omap4
<amitk> mpoirier will take care of it
<ogra> ah, right
<ogra> mpoirier, hrw is working on an upstart enhancement to autospawn a getty if console=ttyS... is set
<ogra> so having the patch thats being tested at https://edge.launchpad.net/~apw/+archive/green/+packages would be intresting for us in the omap3 kernel
<apw> ogra, its not like upstart cannot get that information already from /proc/cmdline
<ogra> apw, Keybuk denied that
<hrw> apw: keybuk does not want that way
<ogra> he wants to have the script proper on first shot :)
<hrw> already discussed and it got refused
<apw> i can believe he doesn't want it that way, but till he tests the patch for real its in it court
<apw> i suspect there is some initramfs work to stop that fecking up all the options too
<mpoirier> so, should I try applying the patch on OMAP3 ?
<ogra> mpoirier, as soon as apw approves and Keybuk has tested it
<mpoirier> very well. Lucid, Maverick or both ?
<ogra> (just wanted to let you know why i pinged you actually :) )
<ogra> maverick only
<mpoirier> should we open a bug for it ?
<ogra> lucid doesnt get new features
<hrw> mpoirier: did not omap3 built from same sources in maverick?
<mpoirier> indeed.
<ogra> hrw, well, a bug wont do any harm to track the issue
<ogra> so you actually know when its applied
<ogra> hrw, feel free to subscribe to bug 586386
<ubot2> Launchpad bug 586386 in linux-ti-omap (Ubuntu) "omap3 kernel should hand over all comdline args to the init environment (affects: 1)" [Undecided,New] https://launchpad.net/bugs/586386
<ogra> bah, i typoed :(
<amitk> ogra: let apw know about the bug so that he can auto close it when he applies it to the kernel
<ogra> indeed
<ogra> apw, ^^^
<hrw> added links
<apw> ogra, amitk, ack have the number now
<ogra> thanks ... i would have triaged it properly but dont know what that takes for the kernel team :)
<zyga> have you guys seen meego release?
<ogra> looks like moblin
<hrw> it is moblin
<amitk> is it done in Qt?
<hrw> just rebranded
<hrw> amitk: no, still clutter/gtk
<hrw> or rather MX (which is clutter based UI toolkit)
<zyga> hmm
<zyga> they use qt as the "standard" toolkit though
<hrw> zyga: they announce it atleast
 * hrw had to work in moblin team
<zyga> there is some talk about how to use qtcreator to make meego apps
<zyga> and since meego = nokia + intel
<zyga> qt and atom are the way to go for this project
<zyga> I wonder how it plays out with ARM and ... AMD
<zyga> meego is this nice "not android" software you can put on a product
 * zyga just tried dd'ing meego image on to /dev/sda on his main workstation
<zyga> fortunately I was saved by crappy gvfs
<zyga> the image was on .gvfs
<zyga> and sudo dd didn't find the source file
<zyga> this made me re-read what I wrote
<ogra> that error made me write usb-imagewriter :)
 * ogra once wiped his laptop HDD with a wrong dd
<hrw> I have system on sdb
<hrw> sda1 is 10GB very old debian rootfs so no big loss (newer is on sdb1)
<ogra> well, if you typo your dd command to sdb thats bad then :)
<zyga> ogra, the one that ubuntu has?
<hrw> ogra: current rootfs is on sdb3
<ogra> zyga, ?
<ogra> the one what ?
<zyga> ogra, what is usb-imagewriter
<ogra> its a gui for dd
<ogra> its in universe
<ogra> and scans for mounted disks before offering you devices to write to
<ogra> so you can never write to your actual root disk
 * zyga will try it out
<ogra> file bugs if you find any, i havent used it since quite a while :)
<hrw> lool: the more I look at dh_movefiles removal, the more I do not see a need for it.
<hrw> lool: I can do migration (already migrated some subpackages) but it can be ugly in few places.
<mpoirier> ogra - you around ?
<ogra> mpoirier, yup
<mpoirier> good.
<mpoirier> bug 566645
<ubot2> Launchpad bug 566645 in linux-ti-omap (Ubuntu Lucid) (and 1 other project) "doing a netinstall to SD card results in OTG related oops on first boot (affects: 2) (heat: 14)" [High,Confirmed] https://launchpad.net/bugs/566645
<mpoirier> have you been able to reproduce reliably ?
<ogra> not since OTG was disabled completely anymore :)
<mpoirier> educate me on OTG pls.
<ogra> its the small USB port on the C series beagle
<ogra> it can run in host or gadget mode
<mpoirier> ok.
<mpoirier> what as OTG disabled ?
<ogra> during lucid development we found its broken, amitk didnt manage to find a fix so it was disabled completely
<mpoirier> when was OTG disabled ?
<ogra> after i filed that bug
<ogra> we indeed want it to work in maverick
<mpoirier> is the bug still valid ?
<ogra> dunno, once i have a maverick image to test i will be able to tell you, its not valid for lucid anymore
<mpoirier> vey well.
<ogra> i changed the bug status accordingly
<mpoirier> about maverick.
<mpoirier> I have a lucid powered beagleboard.
<mpoirier> I compile a 2.6.34 kernel and install it on.
<ogra> ok
<mpoirier> have you done it ?
<mpoirier> /dev/mmcblk02 seems to be missing, preventing the rootfs to be mounted.
<mpoirier> and the system stalls in busybox.
<mpoirier> I'd like to know if I'm the only one with the problem.
<ogra> /dev/mmcblk02 or /dev/mmcblk0p2 ?
<mpoirier> the latter yes,
<mpoirier> writing this off the top of my head.
<ogra> i havent put much time into omap3 stuff recently working on the omap4 stuff atm
<mpoirier> ok, I'll investigate
<ogra> but i just compiled a touchbook kernel for my touchbook which works fine
<ogra> based on .34
<ogra> so its likely a config option you miss or something like that
<ogra> since the touchbook boots from mmc
<mpoirier> Well, it's off Leann's integration branch
<mpoirier> which should include all the OMAP3 changes from Lucid.
<lool> hrw: problem is that dh_movefiles is deprecated
<lool> hrw: dh compat 2 is really old and might go away
<hrw> ok, but what does it give except 'dh_movefiles may be dropped one day'?
<lool> hrw: That seems like a good reason to move away from it
<mpoirier> ogra: you already have a panda board don't you ?
<ogra> mpoirier, if we have a binary kernel i'll help testing that on my beagle its hard to tell why yours doesnt find mmcblk0p2
<lool> hrw: but frankly, it's not the highest priority work in the cross-compilers spec
<ogra> mpoirier, not yet, it should arrive on the weekend or monday i think
<ogra> mpoirier, did yours arrive already ?
<mpoirier> ogra: nop, but was supposed to have been shipped.
<hrw> lool: sure, we need to prioritize it
<ogra> great
<mpoirier> ogra: what are you testing OMPAP4 on then ?
<ogra> blaze
<hrw> lool: but this updated my debhelper knowledge
<ogra> looks like a giant mobile phone :)
<lool> hrw: Ok
<lool> hrw: Are you still fighting it
<hrw> lool: I made some notes and can return to it later without problems
<mpoirier> ogra: for mmcblk0p2, all you need is the linux-image*.deb file ?
<lool> hrw: Ok, if you're moving to something else, mark it back TODO
<ogra> mpoirier, did you do a standard ubuntu install on the board (i.e. from one of the installer images)
<hrw> sure lool
<ogra> then you should just be able to dpkg -i the deb
<mpoirier> ogra: I'm in Lucid and do "dpkg --force-depends -i package.deb"
<ogra> why --force-depends ?
<mpoirier> ogra: --force-depens is mandatory.  Otherwise complains about wireless package not present on system
<ogra> then you didnt do an ubuntu install :)
<ogra> the images ship these packages by default
<ogra> so you will additionally need to create an uImage from vmlinuz as well as a uInitrd
<mpoirier> ogra: I followed the instructions found at http://elinux.org/BeagleBoardUbuntu#U-Boot_uImage
<ogra> ow
<mpoirier> ?
<ogra> well, while thats nice to get ubuntu running its not ubuntu :)
<ogra> our setup is different, the installer applies bits these images cant provide (like writing uImage to NAND etc)
<ogra> so if you use such an image you have to do some parts manually to upgrade the kernel
<ogra> if you use an ubuntu kernel package
<ogra> first of all i'd resolve the dependency issue so you dont have to use --force-depends all the time :)
<ogra> after dpkg -i failed run "sudo apt-get -f install"
<ogra> that will install the missing package
<mpoirier> before going any further it is mandatory that I get my board configured the same way as yours.
<ogra> (assuming you have a NIC attached)
<mpoirier> I do.
<ogra> nah, not for kernel testing
<ogra> actually not using NAND for the kernel will make testing easier
<ogra> but you should use a script for the updating of the kernel ...
<ogra> http://paste.ubuntu.com/439253/ thats a setup i use on my blaze
<mpoirier> not using NAND is a boot script thing.
<ogra> that should update the kernel on vaft
<ogra> *vfat
<hrw> mpoirier: cheap omap boards after beagleboard will not have nand afaik
 * armin76 steals NCommander's boards
<ogra> hrw, right, but flash-kernel has no integration for that setup yet, i still need to write it
<ogra> it will be similar to the above paste
<ogra> just less hardcoded :)
<hrw> ah.. no symlinks on vfat..
<hrw> but do we have symlinks in /boot?
<ogra> and using a vfat bootpartition is surely better than having to fiddle with uImage in nand from the u-boot prompt ... if you run test kernels taht break from time to time
<ogra> we do
<hrw> omap has..
<ogra> which is why we will have an extra vfat partition for the uImage
<hrw> my desktop does not
<ogra> right
<hrw> ogra: on bug 2.0 we used one ext3 partition and enabled ext support in uboot
<hrw> worked fine
<hrw> bug 2.0 is omap3 based
<hrw> kernel was loaded from /boot/ on that ext3
<ogra> well, on beagle u-boot ext2 support always crashed for me or took horridly long
<hrw> before we used same config on i.mx31
<hrw> anyway time for me
<mpoirier> ogra: get back to me when you're done with hrw
<ogra> right, if ext support works ext is great
<hrw> have a nice rest of day
<ogra> ciao hrw
<ogra> mpoirier, just chime in that was just chatter :)
<prpplague> ogra: greetings
<prpplague> ogra: hey, is there a trick to using an unbuntu rootfs over NFS?
<ogra> mpoirier, so use something similar to the script i pasted above and put it into kernel-img.conf
<ogra> prpplague, amitk did that today shouldnt require any tricks
<prpplague> ogra: hmm
<ogra> mpoirier, as a postinst_hook
<prpplague> ogra: we tested on panda and blaze, and both hang after mounting the rootfs and starting up the GUI stuff
<ogra> mpoirier, the dpkg -i usually rebuilds the initramfs if you use ubuntu kernel packages so it should just work
<ogra> prpplague, but you can boot it up to a console prompt ?
<mpoirier> ogra: everytime I updated it did rebuild the initrd
<ogra> might be an issue with gnome
<ogra> mpoirier, perfect so the above script should just work for you
<mpoirier> ogra: I need to understand the kernel-img.conf thing.
<ogra> its a file usually created by the installer on arm we dont actually use it anymore
<mpoirier> ogra: I was already doing mkimage to generate a new uImage and uInitrd - classic embedded stuff
<ogra> right, the postinst script of the kernel package looks in kernel-img.conf, if it finds a postinst_hook entry it will execute it after the package was installed
<ogra> we used to use flash-kernel as a postinst_hook in former releases (flash-kernel is the tool used on all arm platforms in debian and ubuntu to care for HW specific cases to activate the new kernel ... i.e. write to NAND if needed or copy to vfat etc)
<ogra> today flash-kernel is automatically called by update-initramfs so kernel-img.conf isnt used anymore
<ogra> as i said above, the changes to flash-kernel to create an uImage on a vfat partition were not written yet so currently you need to apply a script and use kernel-img.conf for your setup
<prpplague> ogra: yea if we use a scaled down image we can get a prompt
<ogra> i'll land these changes soon (before the alpha2 release)
<prpplague> ogra: but if we use the larger images it just hangs
<ogra> prpplague, very likely gnome not getting along with NFS mounted home
<ogra> do you use an initramfs ?
<ogra> (that uses nfsmount and applies nolock in ubuntu, i'm not sure the kernel does that by default if you use the in-kernel way of nfsroot)
<prpplague> we weren't using an initramfs for this testing, i was guessing it probably had some permissions or temp workspace issues
<prpplague> ogra: ahh seems like i read something about that with regards to ubuntu
<ogra> well, if it boots through to a running system its likely X related ... gdm or the homedir in gnome etc
<prpplague> ogra: is there a wiki page or howto doc we could look at?
<ogra> for using initramfs ?
<ogra> or for nfs bugs ? :)
<prpplague> for doing ubuntu over nfs
<ogra> i dont think there is anything arm specifc
<ogra> https://help.ubuntu.com/community/DisklessUbuntuHowto might be the best you can get but thats outdated i think
<prpplague> thanks i think i had that one bookmarked for a look over today
<mpoirier> ogra: I looked at you pasted script and I was doing the exact same thing, except mine wasn't automated.
<mpoirier> ogra: the real problem seems to come from the initial installation
<ogra> that might be
<mpoirier> ogra: where some packages seems to be missing.
<mpoirier> ogra: I don't think it is cause by my "C2" rev.
<ogra> right, that rootfs is created with rootstock that might not get you a 100% ubuntu
<ogra> its shouldnt be
<ogra> *it
<mpoirier> ogra: that being said, where do I find the "approved" way of installing Ubuntu on beableBoard ? Should I use the netinstall ?
<ogra> prpplague, sorry that i cant help much more but since i switched ltsp to nbd images in 2006 i havent touched nfsroot anymore :)
<prpplague> hehe indeed, it was just one of the items that we wanted to test
<prpplague> ahh the good ol' days of LTSP
<ogra> mpoirier, you wont have much fun for kernel development with the approved way
<ogra> mpoirier, since we flash the kernel to NAND by default which gets you into bad situations once you flashed a broken kernel
<ogra> mpoirier, though https://wiki.ubuntu.com/ARM/Beagle has the 2official" images
<prpplague> ogra: haven't i seen you in the #ltsp channel in the past?
<ogra> prpplague, i wrote ltsp5 with scottie, you have for sure :)
<ogra> i stepped down in 2008 though
<prpplague> ogra: ahh right
 * prpplague dropped out of LTSP stuff back around 2001
<ogra> but i'm still a resident there and go to the november meetings in maine :)
<robclark> btw, semi-related to questions about X11/gdm and nfsroot, etc... how actually does recovery mode work?
<robclark> is there some bootarg I can add to tell upstart not to start gdm/x11?
<ogra> single or text on the cmdline
<robclark> ogra: ahh, perfect.. thx
<ogra> single requires an initramfs and gets you to a rootshell, text just switches off gdm
<robclark> ok.. text is probably good for what I am trying to do..
<mpoirier> ogra: the package I'm missing is "wireless-crda"
<ogra> yeah
<mpoirier> any idea why and where I could get it - for ARM that is.
<ogra> just apt-get -f install should install it
<ogra> beyond that http://ports.ubuntu.com/ubuntu-ports/pool/main/w/wireless-crda/ but apt knows which version you want
<mpoirier> fabulous - thanks.
<amitk> prpplague: ogra: I didn
<amitk> oops
<amitk> prpplague: ogra: I didn't use the full desktop, only build-essential and openssh-server for my rootstrap
<xorAxAx> omapfb omapfb: illegal display bpp
<xorAxAx> omapfb omapfb: failed to setup fb_info
<xorAxAx> omapfb omapfb: failed to setup omapfb
<xorAxAx>  omapfb omapfb: failed to setup omapfb
<xorAxAx>  omapfb: probe of omapfb failed with error -22
<xorAxAx> ogra: these are my kernel messages when i try to run the server install on tv
<xorAxAx> gah, i hate how debian/ubuntu slim down the d-i kernel
<xorAxAx> it doesnt detect the second usb hub on beagle
<xorAxAx> (ok, old uboot)
<prpplague> ogra: ping
<asac> ogra: how is your flash-kernel fixes for omap going that would update the uImage etc. on mmc1 if no nand is found?
<ogra> asac, will do them next week, do you need a prototype ?
<ogra> xorAxAx, try to modify the bootargs on boot.scr with a differnt resolution https://wiki.ubuntu.com/ARM/BeagleEditBootscr
<asac> ogra: nah, thats fine. just wanted to know if you already did that in case i feel like doing it tomorrow
<ogra> well, it needs to work with our new image design
<asac> ogra: my understand is that we dont mount boot, but rather just look up the right fat partition and update the uimage etc. there
<ogra> right
<ogra> http://paste.ubuntu.com/439253/ something like that with sane detection code will go into flash-kernle
<xorAxAx> ogra: resolution? i tried pal
<ogra> (note we dont need kernel-imf.conf anymore)
<xorAxAx> ogra: the whole FB setups fails when i try that, doing that later on with sysfs works
<asac> ogra: why that postinst hook? why not just put that code in flash-kernel directly?
<ogra> we do, and flash-kernle is now always called from update-initramfs so we dont need it anymore
<asac> ok thats what i thought then
<ogra> kernel-img.conf is dead in debian for arm
<ogra> it merged their changes to flash-kernel which hooks directly into initramfs-tools now
<asac> let me see if i still have the code i wrote at some point
<ogra> with the new image structure you can hardcode mmcblk0p1 if you want btw
<asac> hmm
<ogra> https://blueprints.edge.launchpad.net/ubuntu/+spec/preinstalled-sd-card-images-for-omap
<ogra> thats what ubuntu will have for arm from 10.07 on
<asac> all arm images?
<ogra> well, we'll only produce omap in the distro
<asac> ah ...kk
<ogra> and the panda restrictions force such an image
<ogra> (no local disk at all now)
<asac> ogra: why cant we install the rootfs on a usb disk?
<ogra> because we would still need the SD to boot
<ogra> and because i hear complaints all the time about the slow install process
<asac> ogra: sure. but you would be able to have a much bigger rootfs
<asac> ogra: (suggestion: jasper)  i started on clown for that
<ogra> so i worked out that setup with cjwatson at UDS
<asac> but folks complained about that approach and said we should use d-i like seeding
<asac> at least cody complained if you remember
<asac> ogra: what i would love to see is a feature that allows you to move a rootfs over to a plugged in usb disk and then boot from that
<ogra> asac, 11.04 ;)
<ogra> jasper/clown whatever can be enhanced
<asac> ogra: hmm. you are a lagger ;)
<asac> jk
<asac> ok heading for lunch
<asac> good night (hope you are gone when i am back)
<ogra> i need to use the same setup in 10.07 and 10.10
<ogra> yeah, team call atm
<ogra> i'll fall asleep afterwards
<xorAxAx> i get segfaults when rebooting :-(
<xorAxAx> ogra: i get wlan0     no wireless extensions.
<xorAxAx> anything weird in the kernel config that breaks wifi?
<xorAxAx> the driver loads without error messages
<mpoirier> As anyone built the Maverick omap3 kernel ?
<mpoirier> ogra: you still on ?
<rcn-ee> mpoirier, my own omap3 kernel is working in maverick, looking for something specific?
<mpoirier> rcn-ee: did you build it yourself ?
<rcn-ee> no... my beagles did from the source i patched. ;)
<mpoirier> your beagles ?
<rcn-ee> Yeah, my beagles.. kernel deb's here, http://rcn-ee.net/deb/maverick/  source is at https://launchpad.net/~beagleboard-kernel (boot testd on all beagles, overo, igepv2, etc)
<xorAxAx> rcn-ee: do you think your kernel would fix my wifi problem?
<rcn-ee> xorAxAx, it depends... if they fixed the wifi upstream and ubuntu hasn't updated there kernel yet. then 'maybe' otherwise it's probally the same...
<rcn-ee> oh.. just scrolled up.. yes.. i have wireless extensions enabled in mine...
<rcn-ee> xorAxAx, the latest (about a week till i move it to stable tree) would be http://rcn-ee.net/deb/lucid/v2.6.34-dl5/
<asac> xorAxAx: what wifi chipset is that?
<asac> ogra: i assume we wouldnt need to create the uimage etc. in /boot at all anymore?
<asac> (looking at your mkimage scrip)
#ubuntu-arm 2010-05-28
<hrw> morning
<zyga> hrw, hi
<neure> hi
<neure> if a bug like https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap/+bug/584920 has been fixed, how can i get a the new, fixed installer image?
<ubot2> Launchpad bug 584920 in linux-ti-omap (Ubuntu) "netinstall fails, it has no network driver for moschip (affects: 1) (heat: 6)" [Medium,Fix committed]
<neure> a.. i mean, the :)
<ogra> neure, you have to wait for a debian-installer respin, that will likely happen for 10.04.1 (end of july)
<ogra> the fix includes all USB NIC modules now, was uploaded this week
<neure> could i somehow would the installer myself?
<neure> like, i should be able to try the fix, right?
<amitk> you need plar's script to install a kernel into a live image
<amitk> s/install/update
<neure> thats almost mumbo jumbo to me .. :)
<neure> ok that makes a bit more sense
<neure> of course would be lovely if someone did that for me .. :)
<neure> but.. where do i get the script and where do i get the new kernel?
<neure> and where do i get suitable live image?
<amitk> http://people.canonical.com/~amitk/update-image-kernel-x86.sh
<amitk> http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-live/current/lucid-netbook-armel+omap.img
<ogra> amitk, that wont help for netinstall though
<ogra> also the live image is http://cdimage.ubuntu.com/ports/releases/lucid/release/ubuntu-10.04-netbook-armel+omap.img
<ogra> (though its not really live, it just fires up an installer under X)
<amitk> ogra: no, it won't help with netinstall
<ogra> neure, the "live" image has the moschip driver included no need to update the kernel there, its just missing in the netinstall
<zyga> asac, hi
<zyga> asac, did plars talk with you about image identity/timestamps?
<neure> so..
<neure> is there some way for me to have installed with the netinstaller?
<ogra> neure, netinstaller works fine ait asix based NICs if you can get such a device it will definately just work
<ogra> s/ait/with/
<neure> asix based?
<amitk> neure: any reason you can't use live image?
<neure> i dont know exactly what live image means in this case
<neure> perhaps i could, i havent tried
<neure> is it something that i could consider as 'preinstalled' ?
<ogra> neure, no, they are all installer images, the "live" image simply installs a netbook system to an USB key
<ogra> preinstalled images will come with the next release
<neure> no
<neure> i can not use live image
<neure> at least the server installer failed to access usb stick on my C2 beagleboard
<neure> i tried two different powered USB hubs and two different USB keys
<ogra> weird
<neure> so i assume all ubuntu installer images have the same issue: they can not access usb discs on this setup
<neure> if you had some ideas, i could investigate further, but im really not a linux expert in any way
<hrw> neure: anything other on usb was visible?
 * ogra doesnt have a C2 so cant tell
<neure> keyboard and ethernet were on the same usb
<neure> same hub
<neure> keyboard worked fine
<neure> ethernet wasnt working as it lacked the drivers
<neure> angstrom works on the otg with powered hub and it can access usb discs and everything works
<neure> so i wish you guys also supported otg :)
<neure> but of course im not sure if this was really usb issue or if for example my installer image was bad
<ogra> otg will come with maverick
<ogra> there are MD5 files on the download page
<neure> i was able to proceed with the installation to usb with a usb stick i had preformatted on pc
<neure> but then it failed complaining some package was corrupt
<neure> i suppose i would need to read the image back from the sdcard and then check md5?
<ogra> if you didnt keep it on your PC
<neure> well im suspecting the image might have been corrupted while it was transferred to sdcard
<neure> image on pc could be ok
<hrw> lool: ok, added note
<hrw> lool: intermediate stages for gcc/eglibc: do we make subpackages for them (gcc-cross-stage1, gcc-cross-stage2) or other?
<hrw> lool: 'build binutils with -sysroot support' is already done in packaging (--with-sysroot=/) since 2.20.51.20100407-0ubuntu1/lucid (08 Apr 2010)
<lool> hrw: I'm not sure I understand the first question
<lool> hrw: In the end, you will have a meta-package called e.g. cross-toolchain which will build-dep on the gcc source and the binutils source, you'll have to call the binutils rules and the gcc rules to achieve building a full set of cross-compiler packages
<hrw> ok, ignore first question now
<hrw> lool: started binutils part
<lool> hrw: You experienced the process of creating them in the emdebian way, right
<lool> hrw: You could see how the various steps created more packages, which you then installed and allowed you to complete the next one
<lool> hrw: Here, the hardest part is getting away without dpkg -i
<lool> hrw: You're going to have to build all packages from a single meta-package build
<hrw> I know
<lool> dpkg -i wontbe allowed
<hrw> basically "dpkg-source -x cross-toolchain-for-arm.dsc; cd cross-toolchain-for-arm; debuild -b -uc -us"
<lool> hrw: In the end, we will upload a cross-toolchain-armel.dsc, and it will give binutils-arm.deb, gcc-arm.deb etc.
<lool> hrw: The hard part is that while you have the full binutils sources and gcc sources and their packaging, you need to call into their packaging to reuse their logic as much as possible (as to give us cross packages which look identical to the non-cross ones)
<lool> hrw: and you may not install them in /usr during the build, since the build runs as non-root
<hrw> yep
<lool> hrw: it is likely that you indeed have to build the intermediate stages, I highly suspect you will have to use --sysroot to achieve building in a subtree
<hrw> will get to it in one moment
<hrw> now working on binutils
<ogra> grmbl
 * ogra starts to hate x-loader
 * amitk gives ogra redboot :)
<ogra> heh, i wish i could use it on omap4 :P
<hrw> redboot... argh
<ogra> i can at least get it to build :P
<ogra> that huge mess fo hard links between git trees is nearly unresolvable to get a natively building package
<XorA> ogra: working on the omap4 x-loader?
<ogra> yeah
<ogra> how did you guess ? :)
<XorA> ogra: someone probably needs to a) pay sakoman to incorporate that work into his or b) merge WTBU trees with his
<XorA> ogra: I had to deal with that mess for Angstrom
<hrw> XorA: and got it working?
<ogra> well, i got the headers from u-boot in my tree now but x-load-arm.h seems to have broken assembler now
<ogra> its just massively messy
<ogra> and the biggest fun is that all i'm doing atm is throw away work because x-loader is going away anyway
<XorA> hrw: for omap3 which is same tree I ended up just mirroring a tarball of the u-boot tree and extracting that next to the x-loader git repo
<ogra> but currently we need it to get the image building for omap4 going
<ogra> XorA, heh, i did a giant patch with the headers ...
<XorA> ogra: I started that way then got real bored, I wasnt being paid for that work :-)
<ogra> but nontheless there are assembler errors in x-load-arm.h
<hrw> ogra: maybe they use gcc 2.95 for building
<ogra> oh, assembling the patch didnt take much ... just a small script with some find loginc to search for dangling symlinks
<ogra> *logic
<XorA> try fixing the arch to armv5
<ogra> hmm
 * ogra tries
<XorA> I vageuly remember armv7a needs and old gcc to actually compile that file
<ogra> nope
<amitk> ogra: what toolchain are you using?
<ogra> lucid atm
 * hrw â lunch
<amitk> ogra: do you know why I wouldn't get a password prompt after the login prompt?
<amitk> i return back to the login prompt on entering the user name (nfs root)
<ogra> amitk, not really, check auth.log (with init=/bin/bash)
<ogra> x-loader-omap4_L24.6-p1git20100520-0ubuntu3_armel.deb
<ogra> yippie
<ogra> phew, what a painful exercise
<lool> Do we need a separate loader?
<lool> I thought it was supposed to be backwards-compatible?
<ogra> lool, we need MLO for each single bpard until the header is added to u-boot
<ogra> and even then it needs to be a binary header per board since they are wired up differently
<ogra> panda and blaze definately are different here, as well as XM and beagle
<ogra> s/beagle/C*/
<ogra> lool, though for omap4 i was told the boundary to block zero in vfat for MLO has fallen, so we can just ship all MLOs that exist and you can boot different boards with the same image through just renaming i.e. MLO-blaze to MLO
<ogra> thats already a big win
<ogra> (or with the binary header you can rename u-boot-blaze.bin to u-boot.bin)
<hrw> re
<lool> is there public doc on the blaze?
<vstehle> lool: I found this: http://svtronics.com/market_omap
 * hrw is building cross-binutils for all arches now using debuild
<lool> vstehle: thanks
<vstehle> lool: No schematics it seems
<lool> vstehle: Oh right, I've actualy seen it
<vstehle> lool: You need some specific info about the blaze?
<lool> Was just curious what it was, but I see now, thanks
<asac> zyga: we started to discuss that
<hrw>  1 file changed, 52 insertions(+), 13 deletions(-)
<hrw> whole changes for binutils
<asac> zyga: depends on what the imjage building concepts are etc.
<lool> hrw: you found lp:ubuntu/binutils I guess?
<hrw> lool: I took latest maverick package but will provide diff against that branch
<zyga> asac, I think that even thought there are several bits of infrastructure involved having timestamp and image type inside the image is very important
<james_w> what are the bootloaders usually used on ARM?
<ogra> james_w, u-boot, redboot, apex are some we used before
<ogra> there sadly are plenty
<hrw> james_w: uboot, redboot, apex, blob and few others
<james_w> ogra: all of them worth having support for in image building tools?
<ogra> james_w, nope
<james_w> ogra: which would you pick to have support for?
<ogra> afaik jcrigby is doing some work to unify on u-boot
<hrw> james_w: u-boot
<ogra> u-boot though i like redboot too, but we dont use it anymore
<james_w> ok, that's what we will start with then
<james_w> thanks ogra, hrw
 * ogra is just rolling u-boot-omap4 packages
<asac> zyga: yes. i fully agree for images, but from what i understood plars wanted a way to have a way to describe what version an install is on
<asac> e.g. even after dist-upgrading other packages
<xorAxAx> asac: ar9170
<xorAxAx> WTF
<xorAxAx> # CONFIG_CFG80211_WEXT is not set
<xorAxAx> bonkers!
<xorAxAx> useless!
<xorAxAx> please fix, quickly, total showstopper
<ogra> xorAxAx, i guess you rather mean amitk
 * amitk looks up
<ogra> amitk, he's right
<amitk> mpoirier: ^^^ could you please look at this as a Lucid SRU?
<mpoirier> amitk: you mean the discussion above ?
<amitk> yes, enabling CONFIG_CFG80211_WEXT
<mpoirier> amitk: Ok, I'll open a pub and fix it.
 * ogra will go and have a beer at mpoirier's pub :)
<amitk> heh
 * amitk notes that it is beer o'clock here
<ogra> here too but i'm out of beer :(
<XorA> keep working until new beer arrives :-)
<hrw> have a nice weekend everybody
<ogra> XorA, hmm
<ogra> XorA, did you ever try your mkcard script with a real SD cardreader ?
<ogra> and on a non english system :)
<XorA> ogra: non english no, but the version in OE should work for that if the patches I got from french speakers were correct
<XorA> ogra: and it certainly works on read SD card readers
<ogra> well, it does explode on mmcblk0p1 :)
<ogra> since you have the p there
<ogra> and "Disk" doesnt show up in german localized fdisk -l output
<ogra> i had to modify it like that for my system http://paste.ubuntu.com/440936/
<XorA> ogra: thats an old version of script, the one in OE is more robust
<ogra> ah
<ogra> i took the one from your blog
<XorA> I thought I had updated all the pages to point to OE git
<ogra> http://www.xora.org.uk/2009/08/14/omap3-sd-booting/
<XorA> http://cgit.openembedded.net/cgit.cgi/openembedded/tree/contrib/angstrom/omap3-mkcard.sh
<ogra> well, it works now, i just needed something quick
<XorA> ogra: top of that post tells you to go to OE git :-)
<ogra> heh, i'm blind
<XorA> :-)
<XorA> that version even runs on the target platform :-)
<ogra> grr, my MLO doesnt work :(
<ogra> NCommander, the driver for the otg port in lucid doesnt work
<NCommander> ogra: ugh
<ogra> use an usb nic
<NCommander> ogra: I don't have one, or an ethernet jack I can plug it into
<NCommander> ogra: why is it broken?
<ogra> because its broken ... no idea the patch didnt work
<NCommander> ogra: ugh, ok. What package is x-loader in? (google is failing me)
<ogra> x-loader-omap
<NCommander> Texas Instruments X-Loader 1.4.3 (Mar 24 2010 - 21:16:42)
<NCommander> W00t
<NCommander> it boots from MMC!
<ogra> phew
 * ogra dputs x-loader-omap4
<ogra> and cllas it a day
<ogra> *calls
<NCommander> ogra: \o/
<NCommander> sebjan: ping?
<xorAxAx>  what does the USR0 blinking mean in my lucid install?
<xorAxAx> ah, heartbeat
<xorAxAx> how to overclock the beagle to 600 mhz without using memory pokes in uboot?
<DanaG> http://www.engadget.com/2010/05/28/lenovo-kills-skylight-os-in-favor-of-android-u1-hybrid-and-skyl/
<DanaG> hmm... does that mean the PRODUCT is dead... or just the OS?
<DanaG> yeah, product is canned.  Dang.
<DanaG> They could've just taken the "skylight" and put ubuntu on it... and called it a full OS (which it is!).
#ubuntu-arm 2010-05-29
<xorAxAx> hmm, i dont have sound. omap3beagle is listed as a soundcard in dmesg, but mplayer et al. cant open the device
<DanaG> ah, probably a permissions issue?
<DanaG> If you're using the thing headlessly, it tends not to want to allow access to the sound card.
<xorAxAx> DanaG: hmm
<DanaG> take a look in /usr/share/polkit-1/
<DanaG> er, lemme check that.
<xorAxAx> DanaG: thanks, that was it
<xorAxAx> i added the user to audio group and now it works
<xorAxAx> i dont use polkit/consolekit
<DanaG> Ah.  Yeah, adding user to audio is the simplest fix.
<DanaG> ARGH, why do ppas not build anything but i386 and amd64?
<DanaG> https://bugs.launchpad.net/ubuntu/+source/udisks/+bug/568926
<ubot2> Launchpad bug 568926 in udisks (Ubuntu) (and 1 other project) "Missing udisks-tcp-bridge binary for remote management (affects: 5) (heat: 26)" [Wishlist,Triaged]
<DanaG> It actually DID work in one build where it was enabled, during lucid development.
<DanaG> Then it broke.
<humphreybc> Hi everyone!
<humphreybc> Even though there were dozens of ARM sessions at UDS, I still don't know what the status is of Ubuntu on ARM. Does it work?
<humphreybc> If I went and bought one of these little crappy ARM netbooks, would it work? http://www.trademe.co.nz/Computers/Laptops/Laptops/Other/auction-293385640.htm
<ogra_cmpc> ubuntu on ARM works since jaunty (9.04)
<humphreybc> I'm having trouble finding a 10.04 UNE ARM download
<humphreybc> I'll probably buy this thing, if it works, http://www.trademe.co.nz/Computers/Laptops/Laptops/Other/auction-293057225.htm
<humphreybc> what do you reckon?
<ogra_cmpc> dont buy it
<humphreybc> why not?
<ogra_cmpc> 128M 400MHz is really nothing you will have fun with
<ogra_cmpc> the arm images that are produced are CPU/board specific
<ogra_cmpc> its unlikely that there exists a pre-made image for that device
<humphreybc> ohh
<ogra_cmpc> so you will need to find kernel source for it and build a kernel yourself
<humphreybc> what about this thing, it's got an atom
<humphreybc> http://www.trademe.co.nz/Computers/Laptops/Laptops/Other/auction-292400909.htm
<ogra_cmpc> atom is intelo, not arm
<humphreybc> ya, i know :)
<ogra_cmpc> and all intel images will work on it
<ogra_cmpc> for arm, if you have a kernel and know which arm implementation the HW uses you can use the rootfs from scratch wikipage from the channel topic to create a rootfilesystem
<humphreybc> that sounds like more trouble than it's worth for me :P
<ogra_cmpc> then get an intel machine
<humphreybc> yeah
<humphreybc> i'm looking at this now, http://www.trademe.co.nz/a.aspx?id=293158559
<humphreybc> it's so pretty. I have basically zero use for one... but... cannot resist...
<ogra_tb> ha
 * ogra_tb found why the touchbook doesnt charge 
<xorAxAx> rcn-ee: could you make your install-me.sh scripts dash-compatible? :) (This message has been postponed.)
<xorAxAx> rcn-ee: can i overclock the beagle to 600 MHz with your lucid kernel? (This message has been postponed.)
<rcn-ee> xorAxAx, just got your message... what part of the install-me.sh was dash complaining about.. (600Mhz is possible by adding mpurate=600 or mpurate=${mpurate} to your boot arg..
<ogra_tb> i think you cant overclock omap3 cpus dynamically
<ogra_tb> err
<ogra_tb> dont think
<rcn-ee> it is with the right pm patches. ;) (smartflex) but it's not in mainline yet.. ;)
<ogra_tb> oh, rcn-ee you can ?
<ogra_tb> ah
<rcn-ee> the basic stuff is there.. not change everything in the core on the fly stuff. ..
<ogra_tb> i always thought you need to fiddle with opp stuff and recompile
 * ogra_tb wonders if he could overclock this touchbook then
<ogra_tb> though the speed is ok, replacing the weird kbd would be more intresting :)
<rcn-ee> for safety, i think there is max limits set by the core id...
 * ogra_tb is correcting more typos while chatting than actually typing text
<rcn-ee> this is a good read on the PM stuff, on what's mainline, what's planned etc, i keep on it myself.... http://elinux.org/OMAP_Power_Management
<rcn-ee> hey ogra, here's a weird situation, when using the oem-config (not sure on it's correct name) with xfce4, after setting the inital user gdm doesn't seem to list the user, have you seen anything like that?
<rcn-ee> xorAxAx, fixed it was the first == 'armv7' check, the next upload install-me.sh's will have the fix
<xorAxAx> are there mplayer binaries with omapfb and NEON around somewhere?
<ogra_tb> rcn-ee, nope, havent seen anything like that
<rcn-ee> the ubuntu repo ones should have atleast the NEON...
<rcn-ee> yeah.. found a couple bugs from a year ago, but nothing recent, still doing some more testing before i file a bug..
#ubuntu-arm 2010-05-30
<xorAxAx> hmm, i dont have any sound with alsa, what could be the reason?
<xorAxAx> i loaded the asound state from an ubuntu bug report and it worked. what a fscking driver with ~50 knobs
<ssk> where should I post question related to kernels built for beagleboard and available on rcn-ee.net?
<xorAxAx> next show stopper!
<xorAxAx> libmad0 does crazy stuff. to reproduce: use xine to play an mp3 file, listen, and puke
<xorAxAx> i took the angstrom libmad0 and now it works
<lool> xorAxAx: Would be nice if you could file a bug with test case with the version of libmad0 you used
<xorAxAx> lool: done
<lool> xorAxAx: Could it be https://bugs.launchpad.net/ubuntu/+source/libmad/+bug/489242 ?
<ubot2> Launchpad bug 489242 in libmad (Ubuntu) "Inline assembler fix needed for libmad in Lucid on armel (affects: 1) (heat: 1)" [Undecided,New]
<lool> xorAxAx: Could you try the patch in that bug?
<xorAxAx> i dont have the device here anymore
#ubuntu-arm 2011-05-23
<ogra_> persia, did you find a working nvflash yet ?
<persia> No, but I'm not sure that's the issue.
<persia> nvflash claims it can't see the USB device.
<persia> Looking at syslog, it seems that when I attach, two USB devices show, and then both disconnect.
 * persia reproduces to get a viewable snippet
<persia> hrm.  Reproduction failed.  I wonder what changed.
<ogra_> well, are you sure the device was actually in flash mode ?
<ogra_> the usb device will only show up if its in that mode
<persia> Right, but it was the immediate disconnect that was the issue.  As long as it stays connected, it ought be OK.
<ogra_> yep
<persia> Ugh.  I tried to backup partition 0, and it failed, and now I get protocol errors.  I guess this will be a bit of fun trial and error.
<ogra_> there is no 0 partition ;)
<ogra_> it starts at 2
<persia> hence needing to power cycle :)
<ogra_> nvfalsh has a get partition table command
<persia> There's no 1 either?
<ogra_> no 1 either
<persia> What's that command?
 * persia doesn't have a manpage :(
<ogra_> dont ask me what they are smoking at toshiba :)
<ogra_> it should have a help command
<persia> nvflash help ?
<ogra_> --help i think
<ogra_> with all the LD_PRELOAD mess
<persia> Indeed it does.
<ogra_> --getpartitiontable
<ogra_> with a textfile as output
<persia> Yep.  So, I don't really like this tool.
<ogra_> nobody does
<persia> 1) It's non-free.  2) It doesn't qualify for multiverse.  3) It's not packaged.  4) It has no manpage, and poorly formatted --help.  5) it has some of the worst subcommand grammar I've ever encountered.
<ogra_> heh, yeah
<ogra_> sadly we need it
<ogra_> i dont know of any alternative yet
<ogra_> i wonder how trimsclice does it
<ogra_> they have largely the same board in their device
<ogra_> and u-boot is missing input support yet
<ogra_> and even then you would have to flash u-boot first
<persia> Lovely.  I seem to get to run nvflash once per powercycle.
<ogra_> you can use the --resume command
<ogra_> replace the --bl flastboot.bin with it
<ogra_> it can only upload the bootloader once
<persia> Aha!  And --resume lets me run another command without getting "usb read error (71): Protocol error" ?
<ogra_> i think so
<ogra_> try it
<persia> Hmm.  Less than ideal.  This power cycle the bootloader failed to install :/
<ogra_> well, luckily you only have to do it once
<persia> --resume seems to work.
<persia> No, I'm super-extra-paranoid: I have to do it ~15 times, plus any that are unsuccessful.
<ogra_> i mean once you flashed successfull you dot have to do it anymore
<ogra_> though i would recommend also flashing a fallback kernel to part 5
<ogra_> in case you mess up anything you can still boot from it
<persia> Why?  Is there some way to select the partition from which one boots?
<ogra_> yes
<ogra_> if you hold down the home key during power up you get into fastboots recovery menu
<persia> If one bricks the device, can one restore with nvflash?
<ogra_> if you press 1 there it boots from part 5
<ogra_> yes
<ogra_> the device is unbrickable
<ogra_> as long as you can restore the partitioning you will always get it back to life
<persia> That's nice.
<ogra_> part 5 is sadly only 5M big
<ogra_> so there is no space for nifty initrds
<persia> On most of my devices there is some flash that, if overwritten, will make the device completely useless.
<ogra_> tegra seems to be similar to omap here ... the rom code will always work
<persia> I suspect that is true for this, except that there is no way to write that flash (who said updating device firmware was a good idea)
<ogra_> and it seems the flash mode lives there
<persia> Oh, nifty.  So it's not like BIOS flash, or the boot NOR on mx5 devices (yes, you can work around the boot NOR with the DIP switches, but they aren't exposed in real devices)
<ogra_> right
<persia> Seems that --resume only works once, and after two operations, I really have to power cycle.  Oh well.
<ogra_> do you do a full backup ?
<persia> That's my plan.  My hardware is different from yours, and my software is very different.
<ogra_> yeah, makes sense
<persia> (unless you have the REGZA control suite by default, etc.)
<ogra_> lol, no
<ogra_> what do you do with that, remote control your TV ?
<persia> That's what I thought :)
<persia> Rather, participate in your entertainment network.
<ogra_> ah, REGZA is more than a TV brand in .jp ?
<persia> At one level you can consider this a remote control for your TV, but you can also do things like switch the audio track from your TV to your stereo to your laptop headphones, control video streaming from your PVR to your TV or your laptop, and switch seamlessly, etc.
<ogra_> ah
<persia> REGZA is Toshiba's home entertainment brand.  They do TVs, PVRs, Speaker systems, Keitais, Tablets, etc.
<ogra_> ah, i didnt know that
<ogra_> i only know trhe term from my TV :)
<persia> I haven't seen a REGZA Stereo, but the protocol should work with Onkyo or Denon hardware.
<persia> Yeah.  The nifty stuff takes a while to export: someone has to figure out how to explain it to foreigners.
<ogra_> heh
<persia> No, seriously.  Here they just stick a couple stickers on it, and the guy in the shop says "It connects to your network", and nobody asks questions.
<persia> Other places people want to know why they should pay more for feature X.
 * persia suspects this has something to do with not having a law against selling electronics more than three years old
<XorA> hey persia
<persia> XorA, Hey.
<XorA> Im amused as I just bought an item that is now 30 years old
<XorA> now I just need to build a circuit to adapt its video output to actually work with something modern so I can see it working :-D
 * persia laughs
<persia> Grr...  Partition 8 consistently fails.
<ogra_> is that the biggest one ?
<ogra_> i think nvflash has a prob with partitions bigger than 4G ... usually thats only the user data partition anyway and empty ...
<persia> Not by a long way.  Biggest is 6774016 sectors.  8 is only 153600
<ogra_> weird
<persia> Yeah, well, it's the oddities that make me do a full backup before I even boot the device.
 * ppisati tried the mmu patch for kexec but still fails..
<persia> ogra_, The partitions I can't read are labeled APP, UDA, and UDB.  Do you know what these codes mean?
<ogra_> APP is android apps i think, did you look whats indside ?
<ogra_> ah, no. you said you didnt boot yet
<ogra_> (though the part table is completely shifted anyway in userspace ... you will never see part 2-6 in android
<ogra_> )
<persia> UDA and UDB would be User Data A and User Data B?
<ogra_> so you have to guess which ones are APP, UDA, UDb
<ogra_> might be
<persia> Ugh.  8 gives a consistent format error, maybe some sort of copy protection.  12 and 14 just time out attempting to copy.
<ogra_> 14 should be mmcblk0p7 in userspace
<ogra_> that falls under the "biggest partition" stuff i mentioned above
<ogra_> no need to back it up
<ogra_> should be empty
<persia> I suspect so: it's 13,230M
<ogra_> yeah
<persia> But the 300M APP partition seems like something I want backed up, and I got just over a GB from the 1235 UDA parittion on one try, although most tries have been lower.
<ogra_> oh, if your device should offer you to upgrade to android 2.2, dont do it if you want to keep the dual boot option
<ogra_> if you should boot it into android before installing
<persia> I don't intend to ever boot Android on it, unless I have to verify a hardware issue for the warranty.
<persia> Connecting to a full speed hub rather than a high speed hub seems to help, although it takes *MUCH* longer.
<ogra_> HUB ?!?
 * ogra_ just connects directly
<persia> You connect directly to the controller?  What sort of device exposes that?  I've never seen one.
<ogra_> i connect a mini usb cable between my x86 laptop and the ac100
<ogra_> without extra hubs attached
<persia> Right.  How many USB ports does your laptop have?
<ogra_> 3
<ogra_> and i usually connect to a full speed port
<persia> Then you probably have 2 hubs in your laptop.  The first providing those three ports and uplink to the second, and the second conneting to internal devices.
<ogra_> right, i thought you referred to an external hub
<persia> I was on high speed, which is something like 30x as fast, but it kept crashing.  Now I'm on full speed, which works better.
<ogra_> k
<persia> ogra_, Aha!  I encountered the 4G issue.  You don't happen to know if there is a 64-bit nvflash floating around somewhere, do you?
<hrw> hmm... sheet.zoho.com is default viewer of xls files under ubuntu?
<persia> hrw, In some environments (like those where openoffice/libreoffice was considered too heavy/slow/broken)
<hrw> arm for example
<persia> From what I understand, natty libreoffice works, but it's kinda slow.  natty koffice is a bit faster, but predates the revival/rebranding.
<hrw> my daughter just sent panda x11 session to logout... power of power key ;:D
<persia> heh
<ZebraDroid_> Hey all, Could someone suggest anything?  I'm running ubuntu on my arm tablet, I've built and installed touchscreen drivers and the cursor now follows my touch.  The only problem is, no click event is launched on touch release/tap.  Is there any way I could configure this? Thanks
<persia> Which tablet?
<ZebraDroid_> Vega
<persia> Try `xinput list` to find the id of your touchscreen
<ZebraDroid_> Yup, I have that
<persia> `xinput list-props <device>` will tell you what it belives it can do.
<persia> `xinput watch-props <device>` will let you see what it is sending.
<ZebraDroid_> ok, thanks
<persia> Depending on how the driver is implemented, you may need to have it send tap events, you may need to trap and process tap events to turn them into button activations, you may need to fiddle with input-utils to make sure the kernel has the right bits for the event driver...
<ZebraDroid_> hmm ok
<ZebraDroid_> It seems that despite moving my pointer, watch-props isn't providing any feedback. (I've tried all of the pointer devices and the touchscreen identifier specified in xorg.conf isn't in the list)
<persia> Right.  I presume you're well past the xev stage, so diving in: does your driver provide a kernel event interface?
<ZebraDroid_> Umm, not too sure.  This is the first time I've had to compile and install drivers manually so I'm kinda feeling my way around still.  Through inspection of the source it seems it provides the click event via a call to xf86EventButtonPressP (or something similar  to that)
<persia> Then it's just an X driver, making xinput the best tool for analysis.
<persia> Check your X log to make sure it's being loaded.
<ZebraDroid_> It seems to attempt to load it, but fails to initialise a touchscreen device and unloads due to EV_SYN missing. I can only assume it loads in some description of state as prior to installation, the cursor would just jump to 0,0 on touch.  Post installation it follows touch
<persia> Hrm.  I'm not sure.  You might ask the team in #ubuntu-x, although they may send you back here if there are architecture-specific confusions.
<persia> (or someone else might know, if you wait a while)
<ogra_> isnt there also #ubuntu-touch ?
<persia> Is there?  I hadn't encountered it before, but yeah, if it exists, it's a better place :)
<persia> Indeed there is!
<ZebraDroid_> Great, I'll ask there - thanks for the help ^^
<ogra_> they focus more on enabling multitouch in existing drivers though
<persia> Well going from 0 to N is multi, right?
<ogra_> so they might not know much about new ones
<ogra_> the prob smells a bit like evdev would just select a mouse driver for the device
<persia> Or any other class of incorrect autodetect.
<ogra_> yep
<persia> ogra_, My notes have a confusion: I'm writing boot-2.6.37-1-ac100-SD.img to partition 6, right?
<ogra_> yes
<persia> OK.  The command was listed once with a 6 and once with a 5, so I just wanted to double check.
<persia> Oh my.  Partition 14 reduced to 0.1% of raw size with gzip :)
<ogra_> heh
<persia> OK.  partition flashed.  Device OFF.  USB disconnect.  SD insert.  Close eyes and cross fingers...
<ogra_> :)
 * ogra_ crosses
<persia> Yeah.  ALSA errors then bootsplash.  Thanks a lot!
<ogra_> awesome !
<ogra_> the rest should be trivial
<persia> Yep.
<persia> Heh.  Jasper.
<ogra_> jasper ?
<ogra_> there shouldnt be any jasper in these images
<persia> This is casper?  What's giving me initial configuration?
<ogra_> oem-config ?
<ogra_> there should be neither casper nor jasper
<persia> Oh.  It's an OEM image.  I suppose that makes sense.
<ogra_> right
<ogra_> its directly derived from the omap3 one
<persia> (although it's a bit annoying now knowing that I have to go through this config process twice)
<ogra_> thats why i said you should set a rootpw or edit /etc/shadow
<ogra_> for the SD boot
<ogra_> this will be automated by an init script for the actual image
<ogra_> so you only need to cp the tarball onto a formatted SD
<persia> Really, we should use the installer.
<persia> But as we discussed before, this requires tracking down why cp is slow.
<ogra_> no
<ogra_> i think the oem team has a udeb that can install tarballs
<persia> Yes.  Really yes.  I'm inflexible on this.  Maintenance overhead.
<ogra_> that might be an option
<ogra_> but i'm really not going through setting d-i to work with universe kernels etc
<persia> It's all part of the same suite that includes live-helper.
<persia> No, but NCommander has a WI to do that for a different spec.
<persia> So you don't have to worry about it.
<ogra_> so it will stay live/oem
<ogra_> NCommander, has no WI to make d-i work with universe bits
<ogra_> there is only one d-i related workitem ... and thats just a partitioning reciepe for partman
<persia> It's on a foundations spec.
<ogra_> universe ?
<persia> Yes.
<ogra_> that would need a complete redesign
<ogra_> d-i needs the kernel in main
<ogra_> and all other bits it uses to create images
<persia> You were *at* the UDS discussion about it.  Now isn't the time to complain.
<ogra_> well, *shrug*
<persia> So, anyway, assuming the component issue is resolved, and the speed issue is resolved, I'll insist on proper installer images.
<ogra_> i wont change the ac100 image, since i find wasting hours of user time for copying or formatting tasks completely pointless
<persia> But that's not soon: make them however you want until then.
<ogra_> and i wont change them in the future either ...
<persia> Please read what I wrote above again?  Your objection is already included.
<ogra_> it adds massive complexity for maintenance as well as for the enduser
<persia> Really it doesn't.  It *streamlines* maintenance and provides a consistent experience for end users.
<ogra_> we have oem-config exactly for this task ... i dont plan on moving away from it
<persia> Mind you, currently it's painfully slow, which needs sorting.
<persia> It's also impossible, which needs sorting.
<ogra_> there is more than slowness
<ogra_> you have to do a d-i rebuild for every kernel version change
<ogra_> that doesnt scale to universe kernels
<ogra_> (it is already annoying enough for the non mainline kernels we have in main ... which was one of the most pressing reasons for preinstalled oem images)
<persia> So, this will be sorted.
<ogra_> not by me, mind you
<persia> No, not by you.
<ogra_> and as mentioned above, you will need a lot to convince me to move away from oem images
<persia> But when everyone else has done their bit, these images will switch to using an installer.
<ogra_> not mine
<D34X> I have a Lanya smart book X6-7A with an SSD and I was wondering if putting ubuntu on it would be any different.  It doesn't have a normal load up like another computer would, it just pops up the SmartBook screen and does the 25 second loading process.  Would I put a live load in a USB and go from there?
<persia> Whether you do this or not at that point can be discussed later.
<persia> D34X, What's the processor?
<ogra_> i find it a massive waste of manopower to even put time into that
<D34X> persia - ARM 926
<ogra_> its fine for server but i dont see even the slightest reason to push us back into stonegae with the desktop images
<persia> D34X, Ubuntu doesn't support that processor.  You might try Debian.
<D34X> Poo....
<persia> ogra_, I feel the opposite.  I have no interest in remaining in an age of hardware-dependent images.  I want generic solutions, that work for arbitrary hardware.  We are getting much closer with the tools to be able to do this, and when we can, I'll have no interest in supporting less generic solutions.
<ogra_> where would a generic image help on the ac100 ?
<persia> well, let's assume we are able to construct a generic tree that supports all Tegra2 devices.
<ogra_> and whom would a generic image help on a specific board that can only run this specific image ?
<ogra_> LOL
<persia> Then we should only maintain that image.
<ogra_> that will never happen
<persia> Why LOL?
<persia> It will.  This is the *point*.
<ogra_> because nvidia doesnt care at all and the board specific implementations collide heavily
<persia> If this was not a goal (and a believeably achievable goal), we wouldn't do doing any of this.
<ogra_> well, you wont see such a kernel for a long long time
<ogra_> it might happen at some point indeed ... like it did for the beagle after what ... 4 years or was it five
<persia> I'll continue to expect it tomorrow, and be disappointed with anyone that feels otherwise, simply because if we don't believe it will happen, we won't help make it happen, and we'll be discouraging the folk that are trying.
<ogra_> the only organization working on that (linaro) has no support at all for tegra
<ogra_> and there is no movement from either side
<persia> That's true today.  I'm not convinced it has always been true nor that it will always be true.
<ogra_> *if* you get such support (which is already unlikely because every odm seems to implement its own bootloader solution) it will happen long after your ac100 collects dust in your basement
<persia> All I ask of you is that if the valid bugs you raise can be sorted, and we can make generic solutions, you help with those, rather than refusing.  If you're right, and it's a long time before we get there, the cost to you of agreeing is nothing.
<ogra_> oh, i surely wont block any progress either way
<ogra_> i just wont change my images :)
<ogra_> even in a generic setup i would go for oem images for desktop
<persia> For all architectures?
<ogra_> at least on devices wheer you have things like hardcoded partition tables etc
<ogra_> its just pointless to count on d-i for two features we dont use/need at all
<persia> I'd rather have a generic installer that could recognise those devices, and skip bothering the user about partitioning, but rather just do the right thing.
<persia> I think you aren't understanding what I'm saying.
<ogra_> thats what an initrd script can do as well
<ogra_> in an easier way for the user
<persia> I don't intend to show the user anything pointless: that's poor interaction.
<ogra_> and with zero maintenance for the developer
<persia> With two pieces of code to maintain, to have bugs, to have security issues, and two places to fix them all, and inconsistency to confuse the support and advocacy teams,etc.
<ogra_> i only care for one place really ...
<persia> So someone else has to care for another?  No opportunity for collaboration?
<ogra_> i wont pull d-i into the installation
<ogra_> d-i has its areas where it makes sense ... in this particular install to totally doesnt and only gets in the way
<persia> You do know that live-helper is a d-i component, so you'll be doing that anyway for all the preinstall images that use livecd-rootfs today, right?
<ogra_> not during install time
<ogra_> only during build time
<ogra_> what i would prefer to see would be a generic oem images initramfs hook
<ogra_> so that you hand over filesystem and target device on the cmdline or some such and a tarball gets unpacked to the target after verifying teh taball md5 sum  ...
<ogra_> without all the crap i need to do for d-i
<persia> Have you looked at live-helper?  It does something very similar to that.
<persia> And it does it from within d-i
<ogra_> no, i havent yet, i will have to before A1 though
<persia> And it can do it without bothering the user with lots of d-i prompting.
<persia> You may want to: I believe it both represents that which you protest against and that which you wish existed, simultaneously.
<ogra_> it bothers me as maintainer with the complexity i add through d-i
<ogra_> i dont want to a) maintain d-i b) have d-i booted at all for these kind of images
<ogra_> having to maintain a ton of d-i components vs a 10 line initramfs shell script is really not wnat i'm after
<persia> Who said anything about "a ton of d-i components"?
<persia> And d-i is just some initramfs scripts.
<persia> So, for instance, if someone wrote partman-ac100, it could simply return, never prompting the user, and adding hints to everything else about how/where to install everything.
<persia> So, for instance, if someone wrote partman-ac100, it could simply return, never prompting the user, and adding hints to everything else about how/where to install everything.
<ogra_> d-i is a huge complex pile of stuff
<ogra_> of which i dont need 99%
<persia> Then don't put those bits in your image.
<persia> It's *designed* to be flexible, modular, etc.
<ogra_> i know
<ogra_> you wont convince me
<persia> I'm not trying to convince you.  I'm trying to inform you that as a result of the change to live-helper, *every* image will become a d-i image.
<ogra_> now that would be really bad
<persia> And I'm trying to tell you that you needn't fear this change, and that it's not that different from what you do now.
<ogra_> and i doubt thats true
<persia> That's what the shift to live-helper means.
<ogra_> you think we will drop casper ?
<persia> No.
<ogra_> see
<persia> I think we'll wrap casper in a filesystem that we deliver with d-i through the live-helper support infrastructure.
<ogra_> heh
<ogra_> after we ported l-h to upstart indeed :)
<ogra_> given that upstart will now run the whole initrd
<ogra_> oh, and indeed all of d-i too
<ogra_> sorry, but i dont see us changing the whole structure on one release
<persia> Writing a single compatibility upstart job is trivial, so there's no blocking porting effort.
<ogra_> we'll see
<persia> Slowly moving more of the early boot stuff to upstart can happen over time.
<ogra_> i expect that in function and form of casper or the live initrd there wont be many changes
<persia> Really, go read about live-helper.  Learn how it works.
<persia> I think you'll be pleased as much as you're annoyed.
 * persia decides thrudhr has a nice ring to it
<ogra_> i wont be pleased for sure :)
<hrw> how to change boot.scr without regenerating it by hand? panda
<Neko> .. use my awesome flash-kernel boot.script->boot.scr demangler :D
<OlivierN> hrw: or like this
<OlivierN> sudo mkimage -A arm -T script -C none -n "Ubuntu boot script" -d boot.script boot.scr
<Neko> guys does anyone have knowledge of a quick way to disable these horrible new scrollbars?
<persia> Don't install overlay-scrollbar?
<Neko> both kinds.. gedit seems to have a kind of floating on the side scrollbar and other apps just have a kind of little orange line
<Neko> I want traditional ones back
<hrw> Neko: for efikas it uses /boot/boot.script
<hrw> Neko: as base of boot.scr
<Neko> I don't think I have a choice not to install overlay-scrollbar
<Neko> hrw, run flash-kernel again it should do it on all boards?
<persia> Why not?  The rdepends list is short.
<hrw> Neko: right..
<Neko> but you want to do it "not by hand", you can't... you have to invoke it somehow with manual labor
<Neko> persia, I just removed the package and I still get orange-line scrollbars
<persia> Hrm.  That's unexpected.  That package is supposed to be where the orange widget lives.
<persia> If you want different defaults, use a different seed.
<Neko> the whole point is I am trying to replace the metapackages so we can basically define a behavior for our not-quite-ubuntu natty build
<Neko> except, if I take these out, the scrollbar thing still happens
<Neko> ahhh here we are
<Neko> you need to remove liboverlay-scrollbar-0.1-0 too
<persia> Then I'm wrong.  I thought it was that.  Maybe grep for "scrollbar" in the natty-changes mbox to see what else got patched.
<persia> Ah, you found it.  Excellent.
<Neko> it's just reaaaaally difficult to hit those little orange lines with a netbook trackpad
<Neko> also since firefox and thunderbird are blacklisted we get different behavior per app which is just not desirable
<Neko> I wonder how this affects unity though
<persia> Try it with one of the tiny little "optical pointers".  It becomes essentially impossible.
<Neko> weurghhh
<Neko> saving a file in gedit defaults to a directory called "chrome"
<Neko> maybe because I am root.. but that's strange
<ZeZu> Is it not possible to remove X / completely from the ARM version ?  Everything I try just prompts it to want to download another desktop setup ...
<persia> ZeZu, It certainly is possible.  I don't have X installed on my beagle.
<persia> You will have to either 1) start from a minimal image (you might be interested in the natty headless developer images), or 2) spend a lot of time making sure you have every reverse dependency removed.
<ZeZu> I figured it would be something along those lines ...  dependency mess ,  do you have the sgx drivers installed on your beagle ?
<ZeZu> I didn't have nearly as many issues w/ beagle as i do w/ panda ...  the pvr kernel drivers refuse to cross compile w/ 2.6.39-rc7
<ogra_> if your .39 kernel is properly packaged they wont ;)
<persia> ZeZu, I don't have the sgx drivers on my beagle (no monitor, no need)
<ogra_> oh, wait you said cross ...
<ZeZu> indeed
<ogra_> i fear there even a properly packaged kernel wont help
<ogra_> i dont think dkms gets along well with cross building
<ogra_> sounds like a good future project for hrw *g*
<ZeZu> yes well i found out the hard way ... actually you have to pass ARCH=arm or else it tries to build bits and pieces for host system ...
<ZeZu> define properly packaged btw,  might help ... i do recall having to package the headers differently when building for beagle, but i don't think it used dkms at that time
<hrw> ogra_: D:
<avinashhm> hi , does any one have a u-boot for omap4 panda board, where we 'saveenv' works ? .. any help pls
<avinashhm> j /#panda
<persia> avinashhm, Does it not work for the u-boot in the Ubuntu images?
<avinashhm> persia, sorry .. wasn't aware of the ubuntu images .. can u point me to .. i ll try
<persia> Most recent images at http://cdimage.ubuntu.com/releases/11.04/release/
<persia> You can choose between a full environment (optimised for netbooks, but suitable for desktops), or a headless image as a base for arbitrary development.
<persia> ogra_, Do you know why there aren't any .torrent files for the omap images?
<avinashhm> persia, thanks man .. i ll pick up these net book image and check out ...
<GrueMaster> avinashhm: When you say "saveenv", are you trying to save the u-boot environment between reboots?  The panda doesn't have any emmc or nand for storing u-boot settings.
<avinashhm> GrueMaster, can't we store to MMC .. just asking , i am not sure ?
<GrueMaster> Not from uboot.  But you can modify the /boot/boot.script in our images and reflash it to the boot partition with flash-kernel.
<GrueMaster> (or modify it manually and reapply the u-boot crc with mkimage).
<persia> heh.  kernel segfault during debootstrap.  Extra points!
<micahg> janimo: poke re chromium> any luck?
<avinashhm> GrueMaster, ok .. i ll try to modify boot.script then .. thanks man
<NCommander> rsalveti: have the PXE boot patches landed in the Linaro u-boot tree?
<rsalveti> NCommander: not that I know, jcrigby should know better
<jcrigby> NCommander, no not yet
<NCommander> jcrigby: any idea when it will land?
<jcrigby> NCommander, I could push them to the linaro-next if that is useful to you
<NCommander> jcrigby: indeed it would be
<jcrigby> or are we talking pushed to archive?
<jcrigby> ok, I'll do that
<NCommander> jcrigby: when it hits the linaro u-boot, it will get piced by the archive next time we update it
<persia> jcrigby, For pushed-to-archive, if you can get a candidate package ready, it's easy to get someone else to help drop it in.
<jcrigby> NCommander, persia ok I'll prepare a 2011.05 release based on current upstream rc and the PXE patches
<NCommander> jcrigby: thanks, that's a huge help
<rsalveti> jcrigby: it'd be good to include the tftp patches, but probably need more work at the ones that enables ehci for omap4
<jcrigby> rsalveti, the patches don't break anything so we can include them for those that want to experiment?
<rsalveti> I know we have ehci support for omap3 already, so I believe we can also make it work with beagle xM
<jcrigby> rsalveti, yes that would be great
<rsalveti> jcrigby: sure, it's not touching anything outside usb, ehci and smsc driver
<rsalveti> guess we can also include them
<persia> Thanks!  That helps us play.
<janimo> micahg, none so far, but I did not spend time on it since the UDS
<micahg> janimo: k, thanks
<dcordes> did anybody try webm in firefox in natty arm ?
#ubuntu-arm 2011-05-24
<XorA> morning
<hrw> (gst-plugin-scanner:1303): GStreamer-WARNING **: Failed to load plugin '/usr/lib/gstreamer-0.10/libgstffmpeg.so': /usr/lib/neon/vfp/libavformat.so.52: symbol __aeabi_d2lz, version LIBAVCODEC_52 not defined in file libavcodec.so.52 with link time reference
<hrw> someone got such?
<hrw> natty on panda
<persia> \o/  How did you generate that?
<hrw> gst123 movie.divx.avi
<hrw> bug 787486
<ubot2> Launchpad bug 787486 in libav "/usr/lib/neon/vfp/libavformat.so.52: symbol __aeabi_d2lz, version LIBAVCODEC_52 not defined in file libavcodec.so.52 with link time reference" [Undecided,New] https://launchpad.net/bugs/787486
<lil_pete> hey guys does anyone know how to get opengl running on a toshiba tegra 2 with ubuntu / xorg?
<ogra_> persia, how is your ac100 adventure going btw ?
<nanomad> I'm having trouble booting an OMAP4 panda board with 11.04
<nanomad> can anyone help me?
<rsalveti> nanomad: sure, post the question and hopefully someone will be able to answer  it :-)
<nanomad> we zcat the headleass image to the sd
<nanomad> and we get no output from the serial console
<nanomad> the validation FS works fine though
<hrw> nanomad: ubuntu does not use serial console too much
<ogra_> well, you should see initial bootloader messages
<nanomad> exactly
<nanomad> but we get nothing
<ogra_> once the kernel is up its all graphical
<nanomad> and no leds blinking
<ogra_> sounds like you messed up the SD somehow
<nanomad> we attach the serial cable first and then then we give power to the board
<nanomad> that's the third time i'm zeroing the SD
<nanomad> any suggestions?
<ogra_> how exactly did you write the image to it ? do you still have the cmdline in your history ?
<nanomad> yes
<ogra_> can you paste it here
<nanomad> zcat ubuntu-11.04-preinstalled-headless-armel+omap.img.gz > /dev/sdd
<ogra_> as root i assume
<nanomad> yes
<ogra_> and sdd is actually the right device ?
<nanomad> we tried also the dd way
<nanomad> of course, the validation FS from  Texas boots fine
<ogra_> are you 100% sure sdd is your SD card ?
<nanomad> yes
<amitk> (ouch)
<ogra_> if you re-plug the card after writing the image, does it get automounted ?
<nanomad> yes
<ogra_> weird
<ogra_> that indicates the filesystems are ok
<ogra_> i wouldnt know why it doesnt find the bootloader
<nanomad> i'm trying with dd again
<GrueMaster> nanomad: Reading the backscroll, it looks like you are using the omap image on a panda?  You need the omap4 image.
<ogra_> GrueMaster, cool ! nice catch !
<sha__> hello
<GrueMaster> <nanomad> zcat ubuntu-11.04-preinstalled-headless-armel+omap.img.gz > /dev/sdd  Should be ubuntu-11.04-preinstalled-headless-armel+omap4.img.gz
<ogra_> GrueMaster, and that *before* coffee ???!?!??!?!!!
<sha__> someone could tell me if is possible to install adobeflash on ubuntu arm?
<GrueMaster> Well, I had my first sip seconds before responding.
<ogra_> sha__, if you find a binary for your architecture
<ogra_> usually the flash binaries are highly optimized for the HW
<ogra_> so an omap flash would have probs to run on tegra for example
<sha__> toshiba ac100-10d :)
<ogra_> yeah, indeed, i thought so :)
<sha__> where i could find that binary?
<ogra_> i think phh had a solution, someone talked about a libflashplayer.so recently
<sha__> ogra_: i have the library for 32bit
<sha__> but i think it doesn work
<ogra_> for 32bit ?
<ogra_> what do you mean by that
<sha__> ogra_: not for ARM but for x86 (downloaded from adobe website)
<nanomad> :(
<ogra_> heh
<nanomad> GrueMaster: thanks, i definitely need more coffee
<ogra_> what do you plan to do with it on arm
<sha__> nothing good :) im looking for an arm version of that lib
<GrueMaster> sha__: Let us know when you find one.  :P
<gildean> sha__: which one?
 * nanomad is interested in flash for omap4
<sha__> gildean: libflashplayer.so
<gildean> http://www.enst.fr/~husson/libflashplayer.so
<gildean> that's the arm version i included in the modified rootfs for the ac100
<nanomad> does it work on our boards?
<sha__> gildean: but i can't see video right?
<sha__> where is the right installation path?
<nanomad> sha__: /usr/lib/mozilla/plugins
<gildean> nanomad: it's originally from the atrix ROM
<sha__> nanomad: firefox doenst recognize the plugin
<gildean> so no idea on which machines it works
<gildean> sha__: i think the path is /usr/lib/firefox/addons/plugins
<gildean> no, it's /usr/lib/firefox-addons/plugins/
<ogra_> you will likely need the full nvidia xserver and GL setup
<gildean> yeah, the overlay is needed
 * ogra_ bets it is linked against them)
<gildean> it surely is
<gildean> so that one only works with the .32 and the l4t overlay
<sha__> the roght folder is /usr/lib/mozilla/plugins/
<sha__> but it doesn't work for me
<sha__> it's doesn't recognized
<ogra_> sha__, do yuo run a .32 kernel and the L4T overlay FS so you have EGL support ?
<gildean> well, afaik atm the only way to have flash at least with the ac100 is to do as i did and have the l4t overlay and all that shit
<sha__> i run .29
<nanomad> Ok, we booted ubuntu correctly but the installer crashes near the end with DSPC timeout waiting for EVSYNC
<GrueMaster> It shouldn't crash.  Try hitting enter.
<GrueMaster> That is a console message only.
<nanomad> yea, we discovered that 3 seconds after i posted
<GrueMaster> Ok.  Happy hacking.  :)
<GrueMaster> We should have that error fixed in an upcoming kernel update.
<nanomad> good
<nanomad> does the GPU work with 11.04 or we are missing the drivers?
<GrueMaster> I thought you wanted to run headless?
<nanomad> yup, while we wait for our brand new hdtv
<GrueMaster> If you want the GPU drivers, you should install the netbook image.  It has an icon in unity to install them from ppa.
<nanomad> thanks
<marvin24_DT> anyone using "claws mail"?
<marvin24_DT> it seems to corrupt attachments on save
<persia> ogra_, It mostly works.  There's still issues with the keymap, some complaints about where I stuck root (not mmkblk0p7), and it crashes at least once in a while.
<marvin24_DT> crashes how?
<persia> marvin24, There seem to be main classes of kernel panic: when I use the wireless too much (e.g. download 1GB of data as several parallel streams), 2) Something random when I leave it alone too long, and 3) Something involving loss of access to MMC, which seems to happen randomly.
<persia> I'll turn these into bugs at some point, but I'm never comfortable reporting bugs on something I can't reproduce, and system setup is a time when I have little patience for reproduction (excepting when I'm trying to sort some specific feature for installers)
<persia> (note that the above is the result of playing with linux-ac100 on a Dynabook AZ, and does not reflect the results anyone might see in environments where the kernel and installation device are more closely aligned)
<marvin24_DT> thanks persia
<marvin24_DT> I cannot say much about 1)
<marvin24_DT> but 2 und 3 looks like some random decision of the device to go to sleep
<marvin24_DT> black screen, no chance to wake up
<marvin24_DT> or mmc sleeping, and not recovering
<persia> Those aren't my symptoms though: I can always restore the screen by pressing the spacebar: I just am greeted with a kernel panic dump screen.
<marvin24_DT> urh
<marvin24_DT> I havn't seen any kernel panic for a long time
<marvin24_DT> maybe you can make a photo for me if it's fatal
<persia> Now that the system is actually installed, it's been running more smoothly, but I'll admit that after spending time getting it installed, I've not been using it as much (although that's in part because I haven't been doing much computing away from my desk).
<persia> But sure, if I get another one, I'll capture the output before restarting the device.  Is there enough information from the screen dump to understand, or does one also need to know how one got to that state?
<marvin24_DT> problem is often that the useful info gets scrolled away
<marvin24_DT> too many tasks
<marvin24_DT> maybe you'll find something in the syslog
<phh> [16:38:18] <ogra_> i think phh had a solution, someone talked about a libflashplayer.so recently <--- motorola atrix
<persia> I don't see anything obvious (although wireless is fairly chatty).
<persia> phh, Does that contain a redistributable blob, or is it just an example of something that works?
<phh> persia: well it's the "full" libflashplayer.so
<phh> I don't know how much it is linked to nvidia stuff
<phh> i'd say it should be mostly independant
<persia> I was asking more about licensing than compatibility.  I would be surprised to see Adobe prepare device-specific flash solutions.
<persia> To put that another way, if it's licensed for redistribution, I'll toss it in multiverse.  If there is a known reliable download site, it should be easy to extend flashplugin-installer to pull from there.  If it's not-for-distribution, that makes it trickier.
<phh> ah.
<phh> i'm quite sure i'm not even allowed to use it.
<persia> Ah.  That was my fear.  Oh well.
<marvin24_DT> if they would like to distibute it, they would have put it on they main site (beta version)
<persia> marvin24, From what I understand, Adobe doesn't especially want to distribute it.  I've seen device vendors stick it behind registration sites before, for download and device recovery.  I keep hoping someone who does that fails to have the registration step.
<marvin24_DT> I wonder if they ever make an arm plugin free for download
<marvin24_DT> maybe platforms are too different (even more than on x86)
<persia> There are a few places that have free arm plugins working for download, and several people have reported that something downloaded for one device works on another (with the same instruction set: e.g. ARMv7a).  The issue is more that the current download locations of which I am aware all require registration, which includes an assertion that one has the device in question, and I'm not going to put anything in flashplugin-installer that encourages
<persia> users to lie.
<marvin24_DT> that's understandable
<marvin24_DT> the whole proprietary stuff is just ... crap
<persia> I believe that free software is a better model, but complaining about stuff that doesn't work doesn't help: the better solution is to make something else work better (who uses Adobe's PDF readers for Linux these days?).
<marvin24_DT> with a little luck, html5 will eat flash
<marvin24_DT> I think even Adobe seems to accept that
<marvin24_DT> the main problem is not proprietary flash, but proprietary video codecs
<NCommander> marvin24_DT: +1
<NCommander> BTW, is there a good set of instructoins ATM on how to best setup natty on an ac100?
<persia> NCommander, I've just completed, and was planning to draft those.
<persia> Here's the precis:
<gildean> NCommander: you can use my guide and just substitute the files with the .37 ones http://ac100.tunk.org/wiki/phh
<NCommander> gildean: how well does it work?
<gildean> what, natty or my guide?
<NCommander> natty
<persia> Ugh.  Now I can't find ogra's prebuilt files :(
<gildean> i haven't tried the latest .37 or the rootfs with it
<NCommander> also, I don't have Android on my AC100 anymore, so no way to update to 2.2
<gildean> NCommander: no need, you just need to flash parts 2 and 4
<persia> You don't need to run 2.2: I never launched Android on my Dynabook
<persia> https://launchpad.net/~ac100/+archive/ppa is a PPA with kernel/settings/etc.
<gildean> and btw. my portal contains links for about everything you need here : http://ac100.tunk.org/
<persia> http://people.canonical.com/~ogra/tegra/2.6.37/ has some binary files.
<persia> You need to get the nvflash utility from somewhere
<NCommander> I take it works reasonable well?
<persia> (nVidia isn't distributing it anymore).
<gildean> th .37 prebuilt is here : http://people.canonical.com/~ogra/tegra/2.6.37/
<gildean> persia: that is also on my portal
<persia> gildean, Cool!
<persia> So what I did was 1) get the rootfs (non-SD), untar that to a freshly-formatted SD, 2) get the boot*SD.img, and nvflash it to partition 6, 3) insert the SD and boot, 4) use that target environment to hack around and build a system based on natty and the PPA.
<NCommander> persia: how well does it work? My ac100 has performacne issues ...
<persia> For the lazy, just untarring ubuntu-natty-netbook-2.6.37-1-ac100-rootfs.tgz onto a formatted partition on the MMC, adjusting /boot/bootimg.cfg, and running flash-kernel ought be the totality of the required hacking around.
<persia> NCommander, it works.  Attempting to type '|' results in '9', and one of my '\' keys doesn't work, but that won't affect you (you are unlikely to have as many keys on your keyboard).
<jhobbs> jpkeybd
<jhobbs> ftw
<persia> jhobbs, This is a software package that intends to work around the kernel bug, or just agreement that more buttons makes a better keyboard?
<jhobbs> agreement =)
<persia> gildean, Looking at http://salaliitto.com/~gildean/ac100/wiki/phh/ , I can't find a download link for nvflash.  Am I blind, or is there another page I need?
<gildean> persia: check the front page of http://ac100.tunk.org it's under downloads
<persia> from scoopr.fi?  Excellent.  Thanks!
<gildean> but the link is also on the guide
<gildean> so yeah, you were a bit blind ;D
<persia> Ah, "... and <a>tools</a> from nvidia ...".  Yes, I'm blind.
#ubuntu-arm 2011-05-25
<sha__> good morning all
<janimo> ogra_, are there daily preinstalled images for oneiric?
<ogra_> janimo, not until the switch to live-build is done
<janimo> ogra_, ok so livecd-rootfs is completely dropped soon?
<sha__> ogra_: do you have never tryed the Totem Youtube plugin under ubuntu/ac100 ?
<ogra_> sha__, no, does it work ?
<ogra_> janimo, yeah, cjwatson is just porting it over
<sha__> nope ogra_  and i'm tryng to understand why... btw i try next days :( i can't now
<ppisati> GrueMaster: about the A2 panda
<GrueMaster> Yes?
<ppisati> GrueMaster: did he have a serial console attached? because from the description, looks like the problem is in the bootloaders
<ppisati> > When you try and boot the green light comes on for about 5 sec then goes
<ppisati> > completely out.
<GrueMaster> Not that I know of.
<ppisati> ok
<ppisati> i'll ask
<hallyn> persia: hi - in your directions yesterday, you said 'connect the netbook via usb and boot'.  do you mean connect it over usb to another laptop?
<persia> Doesn't matter what you connect it to, but yeah, something on which you have the nVidia tools installed
<persia> (for those following at home, I'll repaste the directions)
<hallyn> ah, i need to install those on another laptop :)  gotcha
<hallyn> persia: looks straightforward enough from there - will hopefully get further this afternoon.  (stuff is d/ling right now).  thanks.
<persia> http://paste.ubuntu.com/612813/
<persia> Sure.  By the way, which model do you have?
<hallyn> az/05m ?
<persia> With a Japanese keyboard?
<hallyn> yeah
<hallyn> what fs do you recommend for the sdcard?
<persia> Doesn't matter.  Something that can handle case-sensitivity, symlinks, etc.
<persia> I used ext4.  I've seen people recommend nilfs.  If you're planning to write once, do an install, and wipe, you're not going to hurt your card much more regardless of what you use.
<gildean> ext4 and nilfs are recommended
<gildean> ext4 only if your sd-card can handle it properly
<persia> gildean, Does it matter that much for the pasted procedure?  The filesystem is untarred, booted once, and then tossed.
<gildean> i've used nilfs2 for the last 4-5 months now and can personally recommend it
<gildean> persia: yeah, well not that much
<persia> nilfs is indeed nice for use for flash.
<gildean> but you might want to keep the sd-card with a working system
<persia> hallyn, Of more concern is that you want to consider which filesystem to use for your main data partition.
<gildean> for later use ;)
<persia> I figure it's trivial to recreate given available images, but maybe that's just me :)
<gildean> yeah it is trivial, but if you have spare sd-cards it's not a bad idea to keep one with all the crap ready
<hallyn> persia: the tegra tools won't compile, claim S_ISDIR not defined.  should be trivial to correct, but surprising
 * hallyn has no spare sd cards, took one from camcorder
<persia> hallyn, So, anyway, you'll want to use mmcblk0p12 for your install (13GB).  You have working bluetooth.  You will have to hack around to switch your keyboard to jp106 (/etc/default/keyboard is where I did it), and then your |\ key won't work properly.
<persia> You have no 3G (don't stick a SIM in the slot, it will become lost).  At least on mine (same model), the external USB port doesn't work with my keyboard (although USB works in general).
<hallyn> persia: noted
<hallyn> feh, i was afraid of that, it autogenerates the file that needs S_ISDIR defined :)
<hallyn> poc
<hallyn> persia: step 9 says 'untar the tarball there'.  which tarball?  the one that got expanded onto the sdcard earlier?
<gildean> hallyn: iirc, ogra has made different rootfs's for internal and external install
<hallyn> gildean: so which tarball do you think h e's talking about there?
<hallyn> and btw, which fs *are* you using for your internal root device?
<gildean> the one that has 'SD' on it's name is for the sd and the other one, well you should get the point
<hallyn> ok, so same one that i wrote to the sd.  got it
<hallyn> i wonder if it'll know how to handle xfs
<gildean> i have nilfs2 on my setup, but i use the .32 and have made my own release on it
<hallyn> persia: oh, you say to use /dev/mmcblk012 on az, but i only have through p7 by default
<gildean> or rather, i've made the guide to recommend nilfs, and i've made a modded rootfs from phh's original tarball
<hallyn> gildean: were mods necessary to support nilfs, or you just happen to also be usin gmodified rootfs
<gildean> hallyn: hmm, iirc marvins kernel doesn't support nilfs on default
<hallyn> gildean: good call, it's not in /proc/filesystems
<gildean> if you want to, you can check the guide i mentioned here: http://ac100.tunk.org/wiki/phh
<hallyn> ah but i could modprobe it
<gildean> and here is the rootfs i release on monday: http://kotelett.no/ac100/gildean/
<gildean> hallyn: you should use ext4 i think, at least ogra says it's fast and reliable
<gildean> and marvins kernel should support it by default
<hallyn> ok.  i guess my ext4 woes are usually on fast smp.  n/a
#ubuntu-arm 2011-05-26
<hallyn> persia: oh no, was i not supposed to update?  it's now complaning that plymouth couldn't upgrade, which is preventing me from installing other things in need
 * ppisati tried a dist-upgrade but got stuck in python dependency
<ppisati> but a quick modification to debpython/version.py made it... :)
<ogra_> hallyn, if you use my rootfs it should be fully upgradeable without any probs, most of the others arent
 * ppisati just finished upgrading panda to natty
<ppisati> btw, why do we have a skew between packets on i386/amd64 and arm?
<hrw> ppisati: cause it is hard to find fast arm with lot of ram to make builds at same rate as x86 ones?
<ppisati> hrw: good point :)
<hrw> ppisati: omap4 has 400MB/s memory speed if all goes ok. how much does ddr2/1066 on pc have? or ddr3/1666...
<ppisati> hrw: right, i'll compile my owh package then
<comradekingu1> http://www.envizionsinc.com/features.html
<ogra_> hmpf, more android crap
<hallyn> ogra_: which is you rootfs?
<plm> Hi all
<ogra_> hallyn, http://people.canonical.com/~ogra/tegra/2.6.37/
<hallyn> ogra_: hm, that's what i used actually
<hallyn> ogra_: plymouth refuses to upgrade complaining about a local customization
<hallyn> (I dont' have the netbook on me atm)
<ogra_> hmpf
<ogra_> there is a diversion in place for the initramfs script
<ogra_> thats on purpose,else the initrd gets to big to boot
<hallyn> ogra_: so you can apt-get dist-upgrade fine with that diversion in place right now?
<ogra_> heh, i dont use that image currently
<ogra_> i will have to research that
<ogra_> you should be able to remove the diversion though, then dpkg should stop complaining
<hallyn> ogra_: ok, will do thx
<pmathews> test
 * pmathews is back
<pmathews> with 128MB RAM
<pmathews> [headless]
<armin76> pmathews: omg thats disgusting, get a head!
<jmonty> how can I make ubuntu running on a pandaboard boot into console mode? there's no grub, so what would i change?
<jmonty> sorry, somehow dropped
<jmonty> anybody know how I can have ubuntu boot into a console mode on Pandaboard since there is no grub?
<GrueMaster> jmonty: You could run the headless image.  It is designed to be run through the serial console.
<jmonty> hmm, well, I've already configured this image with everything I need, would rather not have to redo all of that ... but where is the headless image for future reference?
<GrueMaster> http://cdimage.ubuntu.com/releases/11.04/release/
<GrueMaster> I think you can also edit the /boot/boot.script and add "text" to the bootargs.  Once you edit that, rerun "sudo flash-kernel"
<jmonty> cool, I will try that
#ubuntu-arm 2011-05-27
<jmonty> how about setting a static IP address for the ethernet?
<jmonty> it doesn't seem to think usb0 is a network device even though that's what's listed
<persia> jmonty, /etc/network/interfaces is the file you want.  Add a usb0 entry
<persia> The interfaces(5) manpage does a decent job of describing the format
<jmonty> ok, thanks, it wasn't working at first, just ended up being a typo
<jmonty> thought there was something else going on
<jmonty> but thanks all, I got booted up into console and a static IP address set
<GrueMaster> cd ..
<GrueMaster> Gah.  Wrong window.
<ericb2> hello
<ericb2> is this build error known to somebody ?
<ericb2> http://codepaste.net/ec8w2k
<ericb2> more informative : gcc version 4.4.5 (Debian 4.4.5-8)
<ppisati> ericb2: ouch, that's an ICE
<ppisati> ericb2: tree? config? compilation options?
<ericb2> ppisati: building OOo4Kids on (true) Debian. Probably a gcc option, or maybe gcc-4.4 has a bug
<ericb2> ppisati: was perfectly building on qemu
<ericb2> ppisati: in meantime, we installed gcc/g++ -4.5. Maybe this will help
<sijp> Hi, anyone managed to get ubuntu working on BeagleBoard Rev C ?
<sijp> Hi
<sijp> I'm trying to configure an image of ubuntu Natty (kernel 2.6.38.4-x3) on a BeagleBoard Rev C.
<sijp> I've successfully managed to work with Rev B so far, but is apears that this one is giving me
<sijp> dmesg say: ADDRCONF(NETDEVUP) usb0 link is not ready
<ppisati> sijp: AFAIK a fix for beagle rev c just hit the kernel
<ppisati> dunno if it's related
<sijp> you mean a fix in upstream? or in ubuntu?
<ppisati> i saw it in ubuntu (but i guess it came from upstream)
<ppisati> sijp: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/770679
<ubot2> Launchpad bug 770679 in linux "Missing proper support for Beagle XM rev B and C" [Medium,Fix committed]
<sijp> ppisati thanks :)
<sijp> I'll check it ot
<sijp> out*
<ppisati> anyone with an imx51 board
<ppisati> could you test this:
<ppisati> http://people.canonical.com/~ppisati/imx51/linux-image-2.6.31-608-imx51_2.6.31-608.25_armel.deb
<ppisati> kiitos
<GrueMaster> ppisati: What does this imx51 kernel fix?
<ogra_> GrueMaster, the world :P
<ppisati> GrueMaster: sorry, i'm about to send you an email
<ppisati> GrueMaster: with the changelog
<ppisati> GrueMaster: anyway, 15 CVEs
<ppisati> GrueMaster: they just pointed me to the CVE page for imx51
<ppisati> GrueMaster: and it's REALLY lagging behind
<GrueMaster> Ok, security updates.  I can install it and let you know.
<GrueMaster> Why isn't it in proposed?
<GrueMaster> It appears I alread have a 608.25 kernel installed.  Is this built on top of that one?
<GrueMaster> ppisati: ^^^
<ppisati> GrueMaster: i didn't update the changelog
<ppisati> GrueMaster: sorry, wait
<ppisati> GrueMaster: forget about it for a second
<rsalveti> ppisati: did you fix the aboot issues already?
<rsalveti> or still slacking?
<rsalveti> :P
<ppisati> rsalveti: slacking :)
<ppisati> rsalveti: i dind't know there was any aboot issue
<rsalveti> ppisati: GrueMaster knows it all
<ppisati> rsalveti: i read your email from one week ago
<ppisati> rsalveti: and i thought it was done
<rsalveti> I still didn't find time to put my hands on it
<rsalveti> ppisati: it works, but can't reboot it seems
<rsalveti> I got mmc working, but that didn't work for GrueMaster
<ppisati> rsalveti: ah yes, he told me
<ppisati> i mean, the reboot issue
<rsalveti> so the reboot here is the important issue to solve
<rsalveti> mmc is a low priority, at least for builders
<GrueMaster> Actually, mmc & reboot are low priority for the builders, but high for my validation automation.
<GrueMaster> rsalveti: How did you get mmc working?
<rsalveti> GrueMaster: when I was testing I just booted with the normal image, using aboot and loading the rootfs from my sd card and it worked fine
<rsalveti> later you said it didn't work for you, but I still didn't have time to reproduce it again
<GrueMaster> Interesting.
<GrueMaster> I'll muck with it some more and see why it fails here.
<ogra_> GrueMaster, i think reboot has some prio
<GrueMaster> This was with your patch, right?
<GrueMaster> ogra_: reboot is irrelevant, as we can remotely powercycle the boards. for the buildds.
<GrueMaster> But necessary for image testing.
<ogra_> right, but you might want to do it in software too
<ogra_> not sure how the buildd scripts do it
<ogra_> but i would expect them to use sw first
<rsalveti> if reboot is irrelevant we have enough already for the buildds
<rsalveti> or am I missing something?
<ogra_> no
<GrueMaster> We have enough to make serious forward progress on the buildds, but I would like full functionality if possible for image testing.
<hallyn> ogra_: is the linux-image-ac100 one of the standard ubuntu kernels in the archive?
<hallyn> ogra_: there are two config flags i'd like turned on, trying to decide whether to build my own, or whether there is a good centralized place to request that
<hallyn> namely, CONFIG_USER_NS and CONFIG_DEVPTS_MULTIPLE_INSTANCES
<ogra_> hallyn, i would be that central place, i'm just rolling an image update, will enable these options
<hallyn> ogra_: awesome, thanks.  and a regular apt-get update will grab that when it's done compiling?
<ogra_> yes
<hallyn> great
<hallyn> now why does the mouse keep disappearing on thsi thing
<ogra_> i will upload later tonight (i dont upload without testing the package for a while first)
<hallyn> ok, i'll give it a test tomorrow then (assuming build doesn't tke longer than that)
<ogra_> the nvec (nvidia even controller) times out ... its not much documented so talking to it is still flaky
<ogra_> and kbd as well as touchpad are both attached to it
<hallyn> ah, that's why kbd woudln't work for 3 straight boots
<hallyn> cool, long as it's not just me - thanks
<ogra_> to work around it, pull out the battery for at least 30sec
<ogra_> (and the power chord indeed)
<ogra_> with the new kernel it should get better, it still times out but re-initializes at least
<hallyn> ok thanks :)  it's been workign quite well for me as a dumb terminal for the last hour or so actually
<ppisati> GrueMaster: here it is
<ppisati> GrueMaster: http://people.canonical.com/~ppisati/imx51/
<ppisati> please tell me if it boots
<ppisati> i don't have the hw
<ppisati> i'm leaving now
<ppisati> drop me an email if it's ok
<GrueMaster> ok
<ppisati> GrueMaster: cool
<GrueMaster> rebooting now.
 * ppisati wanders off to a concert.. hell yeah! :)
<GrueMaster> Nothing in dmesg, system booted ok.  Ship it!
#ubuntu-arm 2011-05-29
<Lopi> is it possible to get mouse support with qemu-arm?
<dcordes> hi
<ogra_> hallyn, fyi https://lists.launchpad.net/ac100/msg00009.html
<steev> is there something special that needs to be done with a fresh oneiric rootstock filesystem to get it to do things like start the system logger and such? it seems like it's not starting any services here
<hallyn> ogra_: thanks
<ZeZu> libqt4 has to be rebuilt if non-default (non-mesa3d) GLESv2 libs are installed ?
<Lopi> is it possible to get mouse support with qemu-arm?
#ubuntu-arm 2012-05-21
<DrivenMad> Would anyone know how to build a image to flash to an android device?? I want to lean aboutthe boot proccess of the droidx and how i could make a native ubuntu install for it.
<twb> DrivenMad: depends on the device
<twb> DrivenMad: please address the channel unless it's actually a *personal* message (like "you smell like rotten fish")
<DrivenMad> ohh sorry
<twb> No problem.
<DrivenMad> I know from doing diffrent rooting from the original droid, droidx , and an hp tablet. they are diffrent.. something about parts of it still being locked somehow??
<twb> I'm not familiar with droidx, but you probably want to look for references for droix and "omap3"
<twb> *droidx
<twb> Note that rooting is not the same as reflashing; "rooting" typically implies you keep the vendor's kernel and ramdisk, and only change/supplement the userland.
<DrivenMad> ok cool :) i ahve been reading about omap3 and the diffrent versions of arm (arm7) cpus..
<DrivenMad> correct, i do understand that :)
<twb> If you wait patiently, one of the smarter denizens will probably tell you exactly what to do
<DrivenMad> im lost on how i  would even start to flashing something else.  maybe a custom sbf file or something.. i have an extra original droid just screaming for something crazy on it :)
<DrivenMad> awesome thank you for t your thoughts:)
<DrivenMad> I have been watching some of the ubuntu for android videos.. super awesome!!  looks like it will be based for the newer dual cpu devices..
<twb> DrivenMad: you can't have "ubuntu for andriod" is for vendors, not consumers.  You can't have it unless you buy a phone that already has it.
<DrivenMad> i would like to take the droid and make it even jsut a terminal to remote to.. to use the resources on the phone... heck there is anough to run a CS server on one of them.. i just have to get around any latency from wifi, unless i can get somekind of usb to ethernet adapter working on it :)
<DrivenMad> True..
<angeloc> DrivenMad: you can build a rootfs to run inside a chroot, it's the widest used method, you can find plenty of guides on google
<DrivenMad> I figure if it accually comes out, someone will figure out a port of some sort.. i hope :) or I will learn enough to try :)
<angeloc> DrivenMad, you can use my rootstock branch https://code.launchpad.net/~angeloc/project-rootstock/project-rootstock to start with ubuntu-core
<angeloc> DriveMad, intead of building the rootfs from scratch
<DrivenMad> I have run ubuntu on the original droid in a chroot enviroment, i even got backtrack running on the droid and my hp touchpad. The trick i want to figure out is to add better support for the wifi and bluetooth in the base.
<DrivenMad> awesome!!! thank you very much!!
<DrivenMad> Wow fantastic!!!
<angeloc> DrivenMad, i think there is nothing you can do for wireless and bluetooth support into a chroot, a chroot is a restricted world!
<twb> angeloc: chroot is not very restrictive.  in x86-land there are ways around it, dunno if it'd work or be worth the hassle in an android environment
<DrivenMad> hehe true thats what i found out :)  you are basically restrained by the original kernel.. although i have played with some wifi drivers and rebooted.. sometimes it broke it, sometimes it worked.. i acually had the wifi doing monitor mode 2 times, ran kismet very well. then after anotehr reboot broken again.. :(
<DrivenMad> brb food :)
<angeloc> DrivenMad, twb, loading a wireless driver into a chroot seems wired to me ...
<twb> angeloc: meh, if you ask to modprobe something, the kernel will execute the modprobe outside the chroot &c &C
<twb> an indirect modprobe I mean
<angeloc> twb, never tried, but intresting!
<angeloc> twb, of course modprobe should not be in a cherrot env
<twb> Well, chroot is not a security measure
<twb> If you want that you should probably be looking at LXC
<DrivenMad> waht is lxc?
<DrivenMad> ahh tools :)
<twb> LXC is like chroot, but more.
<DrivenMad> hehe i see .. chroot on steroids :)
<twb> As well as changing the root of the VFS, it can also virtualize the process tree, the network stack, etc.
#ubuntu-arm 2012-05-22
<jimerickson> i have found that the work around proposed for bug #971091 works for bug #994368
<ubot2> Launchpad bug 971091 in linux-ti-omap4 "Pandaboard ES freezes with the default CPU scaling governor ondemand" [Medium,Confirmed] https://launchpad.net/bugs/971091
<ubot2> Launchpad bug 994368 in linux-ti-omap4 "linux-ti-omap4 kernel panics on pandaboard ES" [Undecided,Incomplete] https://launchpad.net/bugs/994368
<djszapi> ogra_: is 12.04 ubuntu arm reliable on the pandaboard ?
<ogra_> why would we release an unreliable product ? :)
<djszapi> happened in the past few times...
<ogra_> ??
<ogra_> what makes you think this
<ogra_> all of the ubuntu archive is built on pandas ... running an ubuntu image as the ones we release
<ogra_> if that would be unstable we would surely notice
<ogra_> and all ubuntu devs use the recent images for development as well ....
<djszapi> sorry for that opinion, but that is based on technically broken experiences.
<ogra_> what was broken ?
<LetoTheII> ogra_: seems you've run out of them, so here's one: ><)))'>
<ogra_> lol
<ogra_> now i know why we invented MaaS specifically to please LetoTheII
<ogra_> :)
<LetoTheII> ogra_: must be a typo, its usually called a maÃ.
<djszapi> ogra_: where can I find an ubuntu arm build ? https://wiki.ubuntu.com/ARM
<ogra_> LetoTheII, MaaS ... -> Metal as a Service
<ogra_> ;)
<LetoTheII> ogra_: ah that one ;)
<ogra_> djszapi, https://wiki.ubuntu.com/ARM/OMAP
<djszapi> ogra_: for making sure: this one, right ? 64-bit Mac (AMD64) desktop CD
<LetoTheII> ogra_: https://plus.google.com/u/0/b/116342914382999178679/116342914382999178679/posts/P2FSSisAeo5
<djszapi> hmm, nope...
<ogra_> djszapi, after you soldered the additional registers ontp your panda SoC, yes :P
<ogra_> *onto
<djszapi> perhaps Preinstalled desktop image
<djszapi> ogra_: sorry ??
<ogra_> well, amd64 wont run on 32 bit arm :)
<ogra_> LetoTheII, LOL
<djszapi> Texas Instruments OMAP4 (Hard-Float) preinstalled desktop image -> Perhaps, this is what I need.
<ogra_> right
<ogra_> or the server version, depends how and what you want to install
<djszapi> just a business specific daemon
<djszapi> that is run from an upstart job after the boot.
<djszapi> nothing else, really.
<djszapi> daemon listens to the serial port.
<ogra_> then take the server install
<ogra_> smaller footprint .... unless you actually need a desktop
<ogra_> note though that the server install completely runs on the serial console, you need a serial cable
<djszapi> then it is a big no go
<djszapi> I occasionally need to have an access through the ethernet
<ogra_> during the install ?
<ogra_> why ?
<djszapi> I do not need install at all
<ogra_> ??
<djszapi> I mentioned "preinstalled" stuff above
<ogra_> that still runs the installer
<djszapi> huh ?
<ogra_> how else would you get a proper setup of the system
<ogra_> you need a user, timezone, kbd, language etc configured
<djszapi> obviously default could work
<djszapi> and no, that is not install, but mostly setup
<ogra_> well, however you want to call it, it is set up by the installer
<ogra_> which runs on the serial console
<djszapi> why would be installer on a preinstalled image ? Sounds very scary.
<ogra_> preinstalled just means you have a preinstalled rootfs
<djszapi> setup manager, ok, but installer on a preinstalled stuff makes no sense
<ogra_> it is completely unconfigured without the installer bits being run
<ogra_> well, the app doing the configuration is called debian-installer/ubiquity ...
<djszapi> well I definitely do not wanna have installer on my system
<djszapi> so I need an image which does not /not/ ship that.
<ogra_> its exactly the same as every other ubuntu installer, it just doesnt partition anything nor does copy any packages
<ogra_> you *need* the installer
<djszapi> then it is broken by design (TM)
<ogra_> else you end up with a brokenly configured system
<ogra_> no
<ogra_> that *is* the desigbn
<djszapi> I need a configuration or setup manager, but I do not know why I would need an installer on a preinstalled system
<djszapi> that is a brain damaged idea.
<ogra_> a system needs a certain amount of configuration to run properlay
<ogra_> that configuartion is part of debian-installer in all debian and ubuntu systems
<djszapi> configuration != install
<ogra_> configuration is *part* of the installation
<djszapi> that is a broken design IMO
<djszapi> I can configure my system *anytime* after installing that
<ogra_> and it would be braindead to not use the existing, tested and proven tools for it
<djszapi> without having an installer.
<djszapi> that would be as brain dead as much it is to hard wire into the installer without *clear* separation
<ogra_> how are you sure you configurede it right without reading tons of source code to see you have all the necessary bits enabled in your manual config ?
<ogra_> every bit in the installer chnages and gets adjusted to the new requirements of a new release
<ogra_> so how do you know what to configure and how if you dont look at the source of the tools doing that initial setup
<ogra_> (or by using the tools in an initial setup app that makes use of teh instzaller bits in question)
<ogra_> all preinstalled images always used the installer to do this initial setup ... and there is no sane way around this if you want a properly configured install in the end
<ogra_> the only difference to a normal install is that the unconfigured rootfs is preinstalled instead of being copied in place by the installer
<ogra_> thus the name
<djszapi> I dislike this design, sorry.
<ogra_> well, its the only possible design
<ogra_> eevrything else would be nonsense
<djszapi> no, it is of course not
<ogra_> ?
<djszapi> the configuration manager should be a totally separate project from the installer
<ogra_> why ?
<djszapi> and ofc the "live install stuff" could use that.
<ogra_> it does
<djszapi> so could anything else.
<ogra_> 90% of the installer is the configuration part
<ogra_> 10% are partitioning and copying
<djszapi> so ??
<ogra_> peinstalled images just omit the partitioning and copying ...
<djszapi> say, an application frontend is 10%
<djszapi> and the library is 90%
<ogra_> would you pay a fulltime person to maintain a separate config tool ?
<djszapi> you are essentially saying they should not be decoupled.
<ogra_> just *because* ?
<ogra_> instead of just making use of the existing, proven and well maintained configuration tool that exists since 15 years ?
<ogra_> why would they need to be decoupled ?
<ogra_> you can omit the parts you dont need
<djszapi> ok, you lost me
<ogra_> they dont eat any space and dotn do any harm
<ogra_> anyway, since you dont like the design, you will be pleased to hear that we drop preinstalled images this cycle
<djszapi> not sure what that means...
<ogra_> that there wont be any preinstalled images anymore for Q
<ogra_> you will have to d a full install like on x86/amd64/powerpc
<djszapi> I would need to do the install over serial console anyway
<djszapi> I am just not sure the server edition is good fit
<djszapi> Ubuntu was not meant for server purposes
<djszapi> and is not used widely like other specialized server distributions
<djszapi> so I would trust the quality of the desktop version MUCH more even if I do not need UI
<ogra_> WHAT ?!?
<ogra_> ubuntu is the #1 could server distro in the world
<ogra_> *cloud
<djszapi> I am not sure what to take this comment for...perhaps biasment.
<ogra_> and the difference between the preinstalled server and desktop images is simply the omission of xorg and ubuntu-desktop on server
<djszapi> well, the desktop edition should fit for 4 GB Kingston usb pendrive I guess...
<djszapi> or even for 4 GB Kingston SD card...
<ogra_> right, server will fit into 2G ... and even less if you remove the included repo
<djszapi> http://cdimage.ubuntu.com/releases/12.04/release/ -> this is a mess
<djszapi> very hard to find which usb iso I need in few seconds
<djszapi> I do have 4 GB stuff, so should not be a biggy anyway...
 * ogra_ thinks he has fed the troll enough for today
<djszapi> there is no other way than grabbing the preinstalled images anyway...
<ogra_> you can use a netboot install image
<djszapi> meh
<ogra_> but anyway... i'll go and do some actual work
<djszapi> have fun
<ogra_> more than being ranted at for sure :P
<djszapi> huh ?
<djszapi> I told my sincere opinion about the modularization issue, that is all.
<djszapi> you do not need to think the same.
<djszapi> things like "ubuntu is the #1 could server distro in the world" would not just make me laugh btw =]
<djszapi> Booting the image... Open a terminal on your host system and launch a serial console monitor with the port set for 115200,n,8,1
<djszapi> Screen: screen /dev/ttyUSB0 115200
<djszapi> this does not work for me.
<djszapi> I see no relevant things inside the screen session, really.
<ogra_> works fine here, is your serial device actually ttyUSB0 ?
<ogra_> (check dmesg)
<djszapi> yep
<djszapi> I am getting a root console
<djszapi> http://paste.kde.org/484262/ -> and even this behind minicom...
<djszapi> I can only configure this stuff over gui ? :(
<ogra_> is that the server image ?
<djszapi> no
<ogra_> well, then get a monitor, mouse and kbd, the desktop installer is fully graphical
<djszapi> meh
<djszapi> thing is, I need qt core anyway which depends on X anyway
<ogra_> thats why i told you to get the server image in the beginniong
<ogra_> well, then just use a monitor and input devices
<djszapi> this is a shame ubuntu-arm desktop cannot be configured over serial console.
<ogra_> thats a design decision
<av500> a bad one
<ogra_> well, it makes sure your monitor and input devices work before even bothering to run the installation
<ogra_> and we provide -server for eaxactly that gap
<djszapi> ogra_: makes no sense
<djszapi> qt core depends on X.
<ogra_> djszapi, why do you use ubuntu at all if all you can do is rant ?
<djszapi> and you can run a daemon fired up without using keyboard or mouse
<djszapi> or whatever
<ogra_> go and use angstrom, or linaro, there are fine images for it on the panda
<ogra_> or debian
<LetoTheII> ogra_: but thats not so shiny hf.
<ogra_> debian is :)
<LetoTheII> oh cool, lets go on ranting there then!
<ogra_> they dont have a desktop image that uses mouse and monitor !
<djszapi> ogra_: I do not really understand why your turn my opinion into "ranting".
<djszapi> I cannot say what I honestly think about certain things ?
<djszapi> you*
<ogra_> djszapi, because i have to defned all my work all day since you showed up here
<djszapi> that does not translate here.
<ogra_> its getting tiring to be told that everything me and my team worked on for the last three years is crap, bad design or that i'm telling lies
<av500> defend
<av500> ogra_: and usually its me telling you this! :)(
<ogra_> av500, yeah, but your rants i'm used to, thats different :P
<djszapi> ogra_: do you seriously think we discussed all the things ?
<djszapi> you worked on the last three years ?
<djszapi> no modularization, yes bad design, many people think that including me
<av500> obviously he does not work much...
<djszapi> not having serial port setup opportunity is bad design as well
<av500> how could he, spending all the time on irc
<LetoTheII> *plop* prost.
<djszapi> many people would think t hat way including me.
<av500> having to handle people like you...
<ogra_> djszapi, you have no clue what yuo are ranting about either it seems, debian-installer is fully modular (else we wouldnt be able to only use the configuration bits of it)
<djszapi> *you* told that it is hard wired to the installer
<ogra_> i just said preinstalled uses the installer and omits the bits it doesnt need for maintenance reasons
<LetoTheII> my crystal-spice-ball thinks he wants a fancy tool to automagically create the ubuntu thing he'd like. like some schimaera of narcissus, live-build and some me(n)tal brain interface.
<djszapi> ogra_: yes, it is: I need A, but add A+B because I do not have time to maintain.
<djszapi> even that, it does not make B necessary for me.
<ogra_> LetoTheII, no, he just doesnt listen after asking what image he should take and then rants if the image he cose against good advice doesnt do what he wants
<ogra_> *chose
<djszapi> that is another borked idea
<LetoTheII> ogra_: oh come on, you are not actually telling me that my crystal ball is lying to me?
<djszapi> to not be able to *configure* a preinstall desktop image over serial console.
<djszapi> preinstalled*
<ogra_> djszapi, i told you how
<ogra_> but then you accused me of lying which somehwat killed my enthusiasm of wanting to help you
<djszapi> I think you take my opinion too personal.
<ogra_> well, its my work you are constantly citicizing and there are very good reasons for every single decision you called wrong
<djszapi> yes, *you* like that way.
<ogra_> no
<djszapi> ok, you do not like that way :D
<ogra_> i just implemented what was discussed at lenght at several UDSes with the community, vendors and other devs
<djszapi> so if I think differently I am not part of the community ?
<djszapi> I am sure there are people thinking that in the "community" it is suboptimal this way.
<djszapi> so you perhaps agreed upon with part of the community.
<ogra_> up to you ... UDS is open for everyone to participate in each single session
<djszapi> nobody sponsores my expensive flight tickets, so I cannot, sorry.
<ogra_> ??
<ogra_> there is no neede to attend in person to participate, we have 1000s of users participating remotely
<ogra_> anyway, everything you ranted about will be gone with quantal
<djszapi> if you think my opinion is "ranting", what can I do :D
<av500> rant less
<ogra_> :)
<djszapi> av500: well you apparently agreed upon the "bad one"
<djszapi> with me.
<djszapi> so I do not understand why you changed your mind in a second :)
<djszapi> ogra_: good advice for the future: do not take opinions that hard :)
<dash> howdy. does the oneiric installer image have accounts enabled for console login?
<dash> i would like to interrupt the installer and fiddle with things myself
<ogra_> no, there are no accounts until the installer did its job of creating them
<dash> Guess I'll wait.
<dash> oh well :)
<ogra_> what exacrtly are you trying to do ?
<dash> ogra_: i have an existing ubuntu installation on an external drive
<dash> my boot media got screwed up
<ogra_> ah
<dash> so i booted the installer and now I want to get back to my old install without waiting another hour :)
<ogra_> so your rootfs is on different media ?
<dash> yes
<ogra_> you can take the installer, edit boot.scr on teh first partition and add break=premount to the kernel cmdline
<dash> yeah that would require a machine i could do that from, heh...
<ogra_> then mount your rootfs, chroot into it, adjust /boot/boot.script and run flash-kernel
<dash> we'll see
<dash> ogra_: right
<ogra_> the latter will update the vfat on the SD card
<ogra_> with kernel, initrd and boot.scr from /boot of your rootfs
<djszapi> http://paste.kde.org/484298/ -> is this output normal in minicom while configuring ?
<djszapi> funky that, how many countries are missing in there.
<djszapi> Finland, UK, Hungary, what not...
<jackh> hey, all, is there any ubuntu support A8 CPU, like samsung s5pc110?
<ogra_> jackh, can you be more specific ? ubuntu has images for omap3, omap4, freescale mx5, the toshiba ac100 netbook and a bunch of arm server architectures
<jackh> ogra_: its the samsung A8, s5pc110
<ogra_> not sure, it might be that #linaro has images for that
<ogra_> ubuntu definitely doesnt
<jackh> ogra_: linaro supports some A9 systems
<ogra_> and a8 too
<ogra_> not sure the s5pc110 is among them though
<jackh> ogra_: you sure? i will go to check
<ogra_> yeah, ask in #linaro
<ogra_> i'm sure ubuntu and linaro both support everything thats ARMv7
<ogra_> which inclused cortex-a8 and -a9
<ogra_> *includes
<jackh> ogra_: if i want to build a ubuntu from scratch, how to?
<djszapi> any ideas why I am getting the one fourth size of the fullscreen in minicom for controlling my pandaboard with this ubuntu image ?
<ogra_> jackh, define "built from scratch" you mean assembling your own image from ubuntu binaries from the archive ? or do you mean "build completely from source"
<jackh> ogra_: hmm...i think i need to do the collecting images of binaries first, then i will thinking of builing from source
<ogra_> give up on the latter ...
<ogra_> thats a huge task and you need a lot of infrastructure
<ogra_> ubuntu is a binary distro, its not designed to be rolled from source like i.e. gentoo or angstrom
<djszapi> well, certain parts can be built from source
<djszapi> sometimes, there is not even another solution around, if something is not packaged.
<ogra_> for the image stuff you can start from ubuntu-core, note though that there is nothing configured in this tarball
<ogra_> you should know exaxctly what you are doing if you want to use it
<ogra_> (it is designed essentially as a base for IVI images)
<jackh> ogra_: what's IVI means?
<djszapi> jackh: http://en.wikipedia.org/wiki/In-vehicle_infotainment
<jackh> ogra_: is there a wiki to show me how to build a customized distro?
<ogra_> in vehicle infotainment
<jackh> ogra_: thx!
<ogra_> they usually use very special rootfses that dont have a user etc
<djszapi> jackh: what do you need to customize ?
<jackh> djszapi, ogra_, what comes to me is if i want to get a distro for s5pc110, then 90% of the images are the same with other A8 systems
<av500> yes
<jackh> djszapi: ogra_, the only different is graffics and maybe some other perfics
<djszapi> yes, but cannot you just install the relevant packages and load the relevant modules ?
<ogra_> jackh, well, its usually bootloader and kernel thats different, yes
<djszapi> I mean, why do you need a customized distribution for that ?
<jackh> djszapi: the customized here is just means the graffic and some perfics, not mean the software modules
<djszapi> right.
<djszapi> I would check out the site of the custom periferia vendor.
<jackh> djszapi: could you share me the link?
<djszapi> that is what I also did with my toughbook, and I were able the touchscreen and digitizer drivers in there almost properly.
<djszapi> I do not know what periferia you are interested in, but just type the stuff to google :)
<jackh> djszapi: ok...
<djszapi> (if it is not supported out of the box)
<jackh> djszapi: someone did a 9.0.4 distro for this cpu
<jackh> djszapi: now i want some 11.10 for it
<djszapi> I see.
<djszapi> I would base the customized image on the top of the ubuntu image.
<jackh> djszapi: so which cpu are you working on now?
<djszapi> that is what I also do with my product.
<djszapi> I use pandaboard at the moment.
<djszapi> that is using A9 cortex.
<jackh> djszapi: you lucky, panda is just supported  by linaro
<djszapi> I do not use the linary support.
<jackh> djszapi: why??
<djszapi> I like sticking with vanilla things as much as possible.
<jackh> djszapi: vanilla? seems like some version name?
<djszapi> I mean upstream without modification
<av500> jackh: vanilla as in the most basic ice cream flavor
<jackh> av500: ya, it tastes just wonderful
<jackh> djszapi: so i guess what you do is: first get the upstream ubuntu distro of omap4, then do some driver and udev modification?
<djszapi> jackh: I just install qt core and then my daemon
<djszapi> as for the toughbook, I have had a patch against the wacom driver to get the touch and digitizer work, and then I add my UI application in there.
<jackh> djszapi: got it
<djszapi> and then I make a dd for the sdcard into a custom img
<djszapi> and then I can replicate that to any sdcard, and I have a backup
<jackh> djszapi: seems like some product level stuff
<djszapi> yep
<djszapi> ogra_: do you have any ideas for this packaging issue ? http://paste.kde.org/484334/
<djszapi> trying to package the project on the pandaboard itself.
<djszapi> ogra_: the control file is simply this: http://paste.kde.org/484340/
<ogra_> you miss a comma in your build deps
<djszapi> oh I am blind, thanks :D
<djszapi> ogra_: it hands always here, but not sure why :o
<djszapi> http://paste.kde.org/484352/
<ogra_> find out why that space is missing on the last two lines
<djszapi> what space ?
<ogra_> -O--parallel misses a space
<djszapi> I use the stock debhelper from ubuntu 12.04
<djszapi> it seems to be a bug then in the tool. My rules file is quite simple and do not touch those.
<djszapi> http://paste.kde.org/484364/
 * ogra_ would try dropping the --parallel
<djszapi> I have just tried that
<djszapi> but it is still hanging there
<djszapi> so probably missing space is a no issue
<djszapi> so I was initially getting this: http://paste.kde.org/484376/
<djszapi> perhaps it is because of the timezone
<djszapi> I was not able to select Helsinki during the server configuration.
<djszapi> simply, there was no such an item.
<djszapi> set to Helsinki with /etc/timezone
<djszapi> how can I set this to human readable ? date
<djszapi> ×' ××× 22 19:56:19 AFT 2012
<djszapi> I mean to ascii :)
<highvoltage> that's better :)
<highvoltage> ogra_: seen one of these yet? http://www.geek.com/articles/chips/via-launch-a-49-android-pc-20120522/
<prpplague> wow thats like the 10th post about that in 20 minutes
<prpplague> or this http://olimex.com/dev/imx233-olinuxino-micro.html
<ogra_> highvoltage, oh my, another ARM11
<ogra_> nothing for ubuntu
<highvoltage> ogra_: ah
 * highvoltage gets horribly confused with the arm versions
<highvoltage> I need to read the wikipedia page on arm versions every few weeks to refresh :)
<ogra_> see topic ;)
<ogra_> thats why we have it there
 * prpplague throws old arm boards at ogra_ like ninja throwing stars
 * ogra_ ducks behind a boxed ubuntu 
<prpplague> ogra_: gave up on getting ubuntu running on that toshiba satelite, had to return it
<ogra_> oh
<prpplague> ogra_: gotta find another laptop this weekend though :(
<ogra_> sad
<prpplague> ogra_: yea apparently there is some serious bios issues that make it totally unusable for linux
 * prpplague has to troll the support channels to find a good laptop for ubuntu
<ogra_> https://friendly.ubuntu.com/
<prpplague> ogra_: dandy!
<ogra_> there is also an older laptop project page somewhere on the ubuntu wiki
<prpplague> ogra_: hehe i still have my panda netbook, i ment to give it away ages ago
<prpplague> ogra_: my daughter has been using it
<ogra_> heh
 * ogra_ still works on a stack of ac100 netbooks 
 * prpplague needs to build another
<prpplague> i guess i could build one with the pixel qi display
<ogra_> ++
<av500> ogra_: wasnt friendly being canned?
<av500> prpplague: get a thinkpad
<ogra_> av500, i dont think so, but i'm not sure
<prpplague> av500: i'll have a look at the prices
<ogra_> there were some discussions at UDS but i cant attend all sessions :)
<prpplague> av500: i need something cheap, as it will be dedicated for a specific use
<av500> http://www.phoronix.com/scan.php?page=news_item&px=MTA5OTI
<av500> inb4: yes, moronix :)
 * highvoltage is kind of eyeing the new thinkpad X1
<prpplague> ogra_: well i would suspect the number of visitors is low because people didn't know about it
<prpplague> i certainly didn't
<highvoltage> (it even contains an arm core along with the intel ones: http://www.linuxfordevices.com/c/a/News/Lenovo-ThinkPad-X1-Hybrid/ )
<highvoltage> (and it looks pretty sweet too: http://www.engadget.com/photos/lenovo-thinkpad-x1-carbon/#5020648 )
<ogra_> av500, aha, yeah, seems they look for community people to take over
<av500> community will fix it :)
<ogra_> prpplague, yeah, well, the lead dev did some blogposts when they started but it wasnt really made popular
<ogra_> and she (being teh biggest driver) had to move to another team
<ogra_> i dont think they actively want to tear it down though
 * ogra_ wrote the initial version of checkbox 7 years ago btw ... when i haded it over to someone else we threw away 7 mio datasets it had collected 
<ogra_> we would be far beyond smolt if we had actually had a backend for these huge masses of data we didnt expect
<jimerickson> how does one go about getting the 3.4.0-200.1 kernel for omap4?
#ubuntu-arm 2012-05-23
<djszapi> ogra_: hey, I am having this issue after the ubuntu 12.04 reinstallation on the pandaboard: http://paste.kde.org/484964/ I would like to play an ogg file, that is all.
<ogra_> just use paplay
<djszapi> ogg should work as well...
<djszapi> (it did before the reinstallation)
<ogra_> it works fine here using paplay
<djszapi> uhh, it is nasty PA stuff...
 * abogani waves all
<abogani> Could anyone pinpoint me on RTFM to install Ubuntu on an BeagleBone, please?
<abogani> Thanks in advance!
<ogra_> abogani, we dont have bootloader or kernel support in the official ubuntu images for the bone yet
<ogra_> not sure if someone already has a community port or so, ask in #beagle, probably rcn-ee has rolled an image or some such
<djszapi> ogra_: paplay is a no go anyway since that would require the rewriting of the software
<djszapi> the software executes ogg123, and that is something which should work.
<abogani> ogra_, Thanks!
<djszapi> not to mention, paplay does not work either: Connection failure: Connection refused
<djszapi> pa_context_connect() failed: Connection refused
<ogra_> your pulse daemon isnt running it seems
<djszapi> anyway, I would like to avoid using pulse
<djszapi> I would like to use alsa.
<twb> I wonder if aplay would've worked fine at that point
 * twb is an anti-PA bigot
<ogra_> it should, if all sound related packages are installed
<djszapi> libasound2 is installed.
<ogra_> we only test PA with gstreamer since thats the default setup
<djszapi> I have honestly no clue :-S
<ogra_> are alsa-base and alsa-utils installed ?
<djszapi> yes
<ogra_> and does /proc/asound/cards list the panda ?
<djszapi> those are all installed by running "apt-get install alsa-utils".
<djszapi> yes
<ogra_> well, no idea then
<ogra_> i know it works fine on the desktop images using PA and any gstreamer player
<djszapi> perhaps another bug in 12.04 :(
<ogra_> since thats what we test
 * djszapi is installing mplayer for making sure many stuff are installed.
<ogra_> and to be honest i dont really care about cmdline players, if someone finds a bug i'll happily upload a fix though
<djszapi> well, it is not command line interface issue
<djszapi> I am sure it is exactly the same with ui interface
<ogra_> well, its not a gstreamer player
<djszapi> the error message clearly looks like an operational issue
<djszapi> it is not that the program is executed with wrong parameters, etc.
<djszapi> why would it ?
<ogra_> dunno, but thats what we care about
<djszapi> so you do not care about basic command line utils working ?
<ogra_> send a patch if you find a bug
<djszapi> perhaps there is a reason to use linaro images...
<ogra_> we do test the default desktop in all functions (including ogg and mp3 playback) ... as lomng as that works ...
<ogra_> linaro images are just using a different kernel
<djszapi> not quite
<ogra_> beyond that they are identical and built from the very same archive
<djszapi> they also have patches against user space softwares.
<ogra_> well, feel free to use linaro then
<djszapi> will do
<djszapi> so why is the pulse daemon not running right after the installation ?
<ogra_> dunno, its usually started by the desktop session at login
<djszapi> let me reboot then...
<djszapi> same after reboot: Connection failure: Connection refused
<djszapi> pa_context_connect() failed: Connection refused
<djszapi> perhaps the postinstallation script is broken
<ogra_> well, it works for everyone else
<djszapi> not quite
<ogra_> did you do a normal desktop install ?
<djszapi> it is the same issue for my colleagues as well actually
<djszapi> no, we discussed that that is not so good idea
<djszapi> so I went for the server install obviously.
<ogra_> well, then you are on your own, find the missing pieces, fix them, it works fine on std desktop installs so you are obviously missing bits
<djszapi> actually I remember it did not work with desktop installation either
<djszapi> and that was one reason I went for alsa.
<djszapi> since I had more issues with pulse.
<djszapi> when I previously had the linary desktop images.
<djszapi> (this is why I asked if 12.04 is any usable on pandaboard)
<djszapi> 11.10 worked better so far.
<ogra_> not here, not in the tests
<djszapi> right, so the problem was the pulseaudio is a *separate* package, not installed by the pulse-utils.
<djszapi> ogra_: paplay did not work
<djszapi> even after running the server
<djszapi> empty output, and no sound
<djszapi> http://paste.kde.org/484994/ -> but I hear no sound. Why is that ?
 * djszapi is pondering to install 11.10 back since as feared, the 12.04 is incapable for pandaboard for the time being :(
<ogra_> just use a normal install
<djszapi> that is not an option unfortunately.
<djszapi> ogra_: isn't there a ready made "default" desktop image I can just dd onto an sdcard and use that as the base for my further system ?
<av500> djszapi: I can sell you an sdcard with desktop "installed"
<djszapi> no, thanks. :)
<av500> other OS's even have that as a service: http://www.ebay.com/itm/Raspberry-Pi-Fedora-Operating-System-8GB-SD-Card-Expanded-/300705977609
<ogra_> haha
<ogra_> funny
<djszapi> ogra_: isn't there some metapackages ?
<djszapi> for getting the same out of the server installation as if it had been the desktop ?
<ogra_> sudo apt-get install ubunut-make-sound-work-for-djszapi
<ogra_> ?
<djszapi> ehh
<djszapi> ogra_: we really need this for our project. Please do not joke :p
<djszapi> I would have expected some meta package.
<ogra_> well, the only metapackages we have would install the whole desktop
<djszapi> like we have gnome, kde, etc on archlinux
<djszapi> so no other way than the installer ?
<ogra_> ubuntu-desktop ... though you dont want to install metapackages, usually the meta goes along with a task, you want to install the task
<djszapi> that is physically really not possible unfortunately.
<djszapi> ok ubuntu-desktop, works
<djszapi> is it safe to install that ?
<djszapi> 1 upgraded, 792 newly installed, 0 to remove and 11 not upgraded.
<djszapi> Need to get 212 MB/252 MB of archives.
<djszapi> After this operation, 800 MB of additional disk space will be used.
<ogra_> beyond that, did you follow the ubuntu wiki to debug sound issues (or upstream docs for this)
<djszapi> yes
<djszapi> even discussed with upstream devs
<djszapi> for hours
<djszapi> same with my colleague in here.
<ogra_> did you check your mixer settings etc ?
<ogra_> and all the other general stuff thats descrivbed on the respective debug pages on the wiki
<djszapi> ogra_: yes, we did
<djszapi> yes, we did
<djszapi> so is this safe to execute then ?
<djszapi> apt-get install ubuntu-desktop ?
<ogra_> that will get you the ubuntu default desktop installed
<ogra_> though as i said, use the task instead
<djszapi> what is the task ?
<ogra_> apt-get install ubuntu-desktop ^
<ogra_> err, nob space before the caret
<ogra_> or use tasksel
<djszapi> 1 upgraded, 786 newly installed, 0 to remove and 11 not upgraded.
<djszapi> Need to get 198 MB/237 MB of archives.
<djszapi> After this operation, 734 MB of additional disk space will be used.
<djszapi> fire ?
<djszapi> I pressed "Y".
<djszapi> ogra_: so ogg123 foo.ogg works for you on the pandaboard with Ubuntu 12.04 ?
<ogra_> no idea, i never test anything but gstreamer players
<ogra_> but i would assume so
<djszapi> can you test ?
 * ogra_ has no desktop install around, all my pandas are build machines atm
<djszapi> eh...
<djszapi> well to be positive a bit, omap4-extras seems to be bundled with 12.04
<djszapi> was not the case previously.
<ogra_> omap4-extras doesnt exist in 12.04
<djszapi> yes, exactly.
<ogra_> because there are no contents for it
<ogra_> the pvr driver is in the ubuntu archive, all other bits simply dont exist
<djszapi> sgx and gles drivers
<djszapi> that is what we used omap4-extras for previously.
<ogra_> omap4-extras pulled in a lot more than just sgx/pvr
<djszapi> I know, but that is what we needed.
<djszapi> so how can we achieve those with 12.04 ?
<ogra_> achieve what exactly ?
<djszapi> having proper support for those
<ogra_> those ?
<djszapi> to not lose what we had with omap4-extras previously.
<ogra_> there is no way
<djszapi> yes, what omap4-extras contained...
<djszapi> why is this regression ?
<ogra_> TI didnt release the multimedia codecs for the 12.04 release
<djszapi> is there anything I can read about that sentence ?
<djszapi> some link
<ogra_> nope
<djszapi> what do you mean by ubuntu archive ?
<ogra_> they simply didnt port their stuff to 3.2
<ogra_> with ubuntu archive i mean ports.ubuntu.com/archive.ubuntu.com
<djszapi> ogra_: is this really the right one for panda ? armhf
<ogra_> yes
<ogra_> ports.ubuntu-com is the archive for armhf
<ogra_> s/-/\./
<av500> for playing ogg files it does not matter if TI ported the IVAHD stuff to 12.04
<ogra_> right
<djszapi> obviously.
<ogra_> it just matters that your alsa UCM setup is proper and the mixers are all adjusted right
<djszapi> alsaucm set _verb HiFi
<ogra_> but he said he went through all alsa debugging and latest upstream should have pointed to UCM
<djszapi> sudo alsactl store
<ogra_> yeah, that should give you the proper setup
<djszapi> sine wave: http://paste.kde.org/485102/
<djszapi> alsa is running "fine".
<djszapi> I mean no errors, just one curious line
<djszapi> but the stuff is apparently playing by using ogg123
<djszapi> however, no sound
<djszapi> pactl list clearly shows there is no proper sink stuff
<djszapi> just a dummy stuff
<djszapi> but then again, I do not care about pulse
<djszapi> if alsa works
<djszapi> and vice versa
<ogra_> are you sure you havent plugged into the mic socket ?
<ogra_> :)
<djszapi> totally sure
<djszapi> and I tried both
<ogra_> av500, actually your link makes me wonder, is the R-Pi boot blob freely (and commercially) distributable
<av500> ogra_: I dont know
<av500> and dont care :)
 * ogra_ suspects that SD is highly illegal 
<av500> of course, sine I bet you cannot send the guy a GPL Request
<av500> since*
<ogra_> that too
<av500> would be fun to get the card and than involve ebay and paypal over the GPL :)
<av500> copy it and return :)
<ogra_> i rather suspec the closed boot code to be nondistributable though
<ogra_> haha
 * suihkulokki finds the concept of undistributable boot code silly
<av500> ogra_: I guess even mentioning the pi needs approval from the "Foundation"
<ogra_> yeah
<suihkulokki> it's not like you can use it on any competitors device?
<ogra_> all the R-Pi based phones !
<av500> suihkulokki: its about the patented linked list inside....
<ogra_> :)
 * djszapi suspects that this metapackage installation takes at least 4-5 hours :(
<djszapi> or perhaps it is going to be ready in "just" 2-3 hours.
<ogra_> sounds about right depending on your SD card
<djszapi> Kingston 4 GB
<av500> thats like a lottery ticket
<jimerickson> how does one go about getting the 3.4.0-200.1 kernel for omap4?
 * ogra_ doesnt know wheer that kernel version would come from
<ogra_> quantal has 3.4.0-201.2 currently
<ogra_> (and precise has 3.2.0-1413.17)
<djszapi> ogra_: funky, still "upgrading".
<djszapi> ogra_: guys are saying that in #alsa, it is a kernel regression
<djszapi> guessing*
<djszapi> so I do really wonder how it worked for you, if that is the case.
<dash> howdy. anybody here with an mx53 board that knows how to get it to do 1280x1024 on its vga out? looks lii need to discover
<ogra_> dash, infinity has such a board but i dont think he even has a monitor attached (not sure)
<ogra_> i think there are more mx53 users in #linaro
<dash> alrighty
<djszapi> ogra_: I think you were wrong
<djszapi> there are patches in 3.4 which makes the sound work
<djszapi> http://mailman.alsa-project.org/pipermail/alsa-devel/2012-February/049246.html
<ogra_> djszapi, we dont use 3.4 in ubuntu
<djszapi> exactly
<ogra_> (in 12.04 that is)
<djszapi> that is why it cannot work
<djszapi> on the contrary, the linaro guys might have taken care of this.
<ogra_> and have a very special tree with a lot of extra patches and backports
<djszapi> ogra_: in 12.04 ?
<ogra_> and we definitely have working sound OOTB
<djszapi> not for the pandaboard
<ogra_> since 10.04 yes
<djszapi> see the kernel patch above
 * ogra_ isnt intrested in kernel patches
<djszapi> then trust us
<djszapi> it cannot work
<djszapi> right, the desktop confirms me
<djszapi> still not working
<ogra_> works here after the first reboot after the install has run
<ogra_> every time
<ogra_> and on the Qa machines as well
<ogra_> (and i remember adding the necessary UCM changes before release and verifying them)
<ogra_> probably your board is broken or some such, i know for sure it works
<djszapi> well, I have three boards
<djszapi> all of them are non-working
<djszapi> although with the linary ubuntu stuff they all worked
<djszapi> it is only borked with the stock ubuntu stuff
<ogra_> then use that
<ogra_> the stock ubuntu stuff is using the linaro tree as a base btw
<djszapi> yes...after wasting 1-2 days....
<ogra_> *shrug*
<djszapi> this is EXACTLY why I asked about the quality of 12.04...
<djszapi> it was already borked for gfx stuff...
<ogra_> it works here and in all QA tests
<djszapi> sure...
<ogra_> as well as the graphics
<djszapi> fix your QA tests
<djszapi> to represent more environments.
<ogra_> including unity-3d
<djszapi> show me the QA runs pls
<djszapi> with all the environments to see what that actually is doing
<djszapi> (for the pandaboard, that is)
<ogra_> we test the environments we support
<djszapi> Right, pandaboard Rev A3 is not supported
<djszapi> pretty please: make this clear for others so others do not necessarily need to waste 1-2 days.
<djszapi> because when I asked I was said "Of course, we support, do you think we provide bad quality?"
<ogra_> A1-ES are supported
<djszapi> answer: yes, it is unsupported and has bad quality
<ogra_> andd have been fully tested
<djszapi> with Rev A3
<ogra_> a1-ES i said
<djszapi> no, you did not
<djszapi> you said, of course it works
<ogra_> no, i'm actually wrong, its A2 -ES
<djszapi> would we provide bad quality ?
<ogra_> we dropped A1 aupport in natty iirc
<djszapi> it is nor A1, nor A2
<djszapi> it is A3
<djszapi> and definitely not EES
<djszapi> ES*
<ogra_> yes, which is between A2 and ES
<djszapi> anyway, pretty please: make this clear on the website or some user visible place: 12.04 does not give a crap about Rev A3
<djszapi> so others do not need to suffer from the very same issues.
<mythos> so, if i want mess more around with arm, should i buy a pandaboard es or something else?
<mythos> *want to
<djszapi> mythos: not A3 at least.
<ogra_> mythos, thats surely a good platform to get familiar with arm
<djszapi> try to get them answered for the very question: which models work?
<ogra_> and dont listen to the troll pleass
<ogra_> *please
 * ogra_ thinks this is getting very tiring
<mythos> ogra_, ok... thanks
<djszapi> mythos: please handle advices carefully :)
<djszapi> I have also been said "surely works"
<djszapi> not really after a full day experimenting :(
<jimerickson> ogra just got 3.4.0-201.2 thanks
<ogra_> great :)
<ogra_> jimerickson, does it work ? (i dont think anyone but the uploader even tried it yet)
<mythos> djszapi, actually, if the armhf-port works, it would be fine too
<jimerickson> downloading now will reboot in afew
<mythos> *from debian
<djszapi> mythos: I see. Yeah, I would be very happy too, if a simple sound could be played with an Ubuntu image. I cannot seem to be able to manager that. I fall back to Linaro.
<mythos> djszapi, even if only armel would work, it would be fine ;)
<djszapi> manage*, ehh.
<ogra_> mythos, it should, though i have no clue what kernel they use in debian, its likiely upstream which misses the DSS patches
<djszapi> mythos: yeah, the point is working, I agree. :)
<mythos> ogra_, no problem. i will test that
<ogra_> userspace wise debian armhf is largely the same as ubuntu armhf
<ogra_> (same toolchain, same build options)
<mythos> i don't even need a working x11 driver. xvfb is good enough for my purpose
<ogra_> yeah, that will work fine
<ogra_> though as i said, not sure about the DSS patches
<ogra_> (which you will need even for xfbdev)
<mythos> ogra_, ok, thanks. i will see, when i have the board ^^
<ogra_> :)
<djszapi> mythos: I would also consider linaro images.
<djszapi> they have some custom patches directly for the boards.
<ogra_> nothing the ubuntu kernel doesnt ship
<ogra_> (given the base tree is a merge of linaro and TI trees)
<mythos> djszapi, if i have to patch and compile it myself to use debian/ubuntu, so be it ;)
<ogra_> we have binaries for everything in the archive, no worries :)
<djszapi> mythos: just as an example, audio does not work here, but works fine with linaro
<djszapi> which I consider a basic functionality.
<djszapi> You can patch the ubuntu kernel yourself, but you do the same job as the linaro guys in the end.
<ogra_> audio works fine if you use a proper image and install it following the instructions
<djszapi> (if you do not make any mistakes in the workflow)
<mythos> djszapi, hmm... i have usb-audio-devices here. so i can work around this problem
<djszapi> mythos: why would you, if you have a working option oob ?
<ogra_> djszapi, couls you stop sprading FUD please
<ogra_> linaro doesnt use ubuntu trees or put anything on top of them
<mythos> djszapi, because i only want to test my software on the arm-device. a working audio-out would be nice, but is not necessary for me
<ogra_> and as i said, if you follow the instructions instead of hacking together your own solution with ignoring all good advice various people give you, then yes, sound might not work
<mythos> djszapi, and with pulseaudio, i could use tunneling for audio too. so i don't even need a audiodevice for the armboard
<djszapi> mythos: yep, but they also deal with other things, not just audio.
<jimerickson> ogra while installing Assertion Error: file must be in binary mode. dkms reports bad return for module build. reported bug. do i dare to reboot to the new kernel?
<ogra_> jimerickson, thats likely the PVR driver
<ogra_> assuming you have it installed over there
<jimerickson> ah ok so a reboot is ok? yes i have it installed.
<ogra_> might give you broken X
<ogra_> but consoles should still work ...
<jimerickson> i can handle that much
<djszapi> mythos: for instance my colleague had issues with the hardware acceleration
<djszapi> mythos: he also had to use linary things where those were fixed up.
<mythos> <ogra_> (which you will need even for xfbdev) <-- oh, i overread that. xvfb uses a framebuffer in ram and to access it, you have to use vnc or something similar
<djszapi> 12.04 was broken for that
<djszapi> linaro*, cannot type :)
<mythos> djszapi, hw-accel for videoout?
<mythos> djszapi, i don't need that either
<ogra_> mythos, DSS is driving all the kernel side display stuff including /dev/fb0
<mythos> ogra_, xvfb does not need any fb-device
<djszapi> mythos: I am not saying you need. I am saying linaro works in many areas to fix up shortcomings, hence providing a more robust solution.
<ogra_> mythos, do you mean xvfb vs xfbdev ?
<mythos> ogra_, it only needs ram
<mythos> ogra_, yeah, we speak from something different ;)
<ogra_> yeah, indeed, thats virtual, sorry, i though you talked about xfbdev
<mythos> djszapi, but does linaro have debian-packagement?
<ogra_> right, xvfb doesnt need any graphics ... thats what we use on build machines if a package needs a running x server
<djszapi> mythos: yep
<ogra_> mythos, linaro is ubuntu just not supported
<ogra_> they provide monthly snapshots from the ubuntu archive
<mythos> ogra_, djszapi, ok
<djszapi> mythos: at least for me, that works :)
<mythos> djszapi, ok, i keep that in mind ;)
<GrueMaster> ogra_: Just an fyi, xvfb doesn't support 3D.  Might want to pass it along.
<ogra_> GrueMaster, heh, i took that as a given :)
<mythos> GrueMaster, not even with llvmpipe?
<GrueMaster> Yea, well I heard a nasty rumor that they are killing 2D support.
<GrueMaster> Not sure if llvmpipe works.
<ogra_> well, mesa should work at least
<ogra_> not that it might be fun to use though
<mythos> GrueMaster, they do, they do
<djszapi> mythos: llvmpipe might, but not sure that is a good idea
<ogra_> GrueMaster, right, 2D will be droped
<ogra_> but i thinnk thats post Q stuff
<GrueMaster> (I'm actually doing remote python Gui development on an amd64 system - not arm).
<mythos> djszapi, on an arm? sure that is a rocket
<ogra_> for quantal it will just not see new features
<djszapi> mythos: Llvmpipe even achieves better performance than the
<djszapi> GPU on some low end systems
<djszapi> "although with higher CPU usage and thus power consumption, but you probably already accepted those consequences when you chose a system without OpenGL acceleration)."
<djszapi> this was written to the qt development mailing list after the directx support question
<djszapi> mythos: FTR: http://releases.linaro.org/latest/ubuntu/leb-panda/
<mythos> djszapi, thanks ;)
<mythos> but i don't even have a panda-es at the moment
<mythos> i'm going to buy one today, so...
<jimerickson> ogra it doesn't boot. is there a daily image for omap4 somewhere i can't seem to find one.
<ogra_> jimerickson, not yet, we only stat 12.10 dailies in about two weeks
<ogra_> *start
<infinity> Hrm?
<infinity> Dailies are building now, though they seem to be failing on !ac100.
<ogra_> infinity, we dont ? i havent seen any successfull buiold yet
<jimerickson> ogra ok thank you.
<ogra_> and i thought we wanted to do the preinstalled->live switch before A1 anyway
<infinity> Er, I don't even see logs for ubuntu-omap* ... Did someone break things again? :/
 * infinity looks.
<ogra_> i get mails every day
<ogra_> but empty ones
<ogra_> and i didnt bother to look yet before the live switch
<ogra_> since we will build differently anyway and run into new issues with that
<infinity> True.  Still, having them not building at all right now seems like an issue.
<ogra_> well, lets do the switch and then fix it, i dont really see a reason to waste work on preinstalled if they go away
<infinity> Oddly enough, kubuntu-omap4 is building.
<infinity> I wonder if maybe some machines just fell over when I wasn't looking.
<ogra_> i saw some debootstrap issues in some builds
<infinity> Friggin' shoestring and bubblegum.
<ogra_> "no such script"  for quantal
<ogra_> might be that they need chroot updates
<infinity> The chroots auto-update.
<ogra_> well, its one of the few mails that have content that show this error
<ogra_> i thought they auto-update, but for that particular case it seems they didnt
<infinity> I see no logs for quantal on araceae.buildd at all.
<jimerickson> ogra ok with a hardware reset and a full power cycle i got it to boot to a full desktop. i disabled the pvr driver before the reboot. very pleased!
<ogra_> jimerickson, awesome, thanks for the feedback !
<jimerickson> ogra no problem! we will see you around. i am back to lurking.
<ogra_> :)
<infinity> Odds are that no one set up the livefs chroots on the spare builders.  Meh.
<infinity> I'll look into that later.
<ogra_> infinity, but seriously, dont invest time to fix preinstalled, its not worth it
<ogra_> lets focus on live
<djszapi> are there pre-built images what linaro also provides ?
<ogra_> no
<ogra_> you have to use linaro-media-create or however that tool is called
<djszapi> I do not
<djszapi> they have ready made stuff
<djszapi> only thing needed: dd
<ogra_> lucky you then
<djszapi> see the link above
<infinity> ogra_: Eh?  Fixing the buildds is needed regardless of what we build on them.
<ogra_> infinity, sure
<ogra_> what i mean is that we should switch asap to vfat live
<ogra_> and ignore any preinstalled issues
<ogra_> i assume we will run into enough issues given we didnt use live on arm for years
<infinity> I'm more optimistic.
<ogra_> heh
<infinity> Given that d-i installs work, and live (apart from installing) is pretty arch-agnostic, it should mostly Just Work.
<ogra_> i expect a lot of casper issues (but am prepared to fix them)
<infinity> Except for the speed issue, which we can't fix.
<ogra_> (thats why i made it a WI :) )
<dash> infinity: rumor has it you know stuf about the mx53 board
<dash> infinity: are you familiar with setting vga resolution on it?
<djszapi> ogra_: how can I install the desktop image without hdmi device ?
<djszapi> and without proper cable ?
<ogra_> djszapi, you cant
<djszapi> that is for confirming.
<djszapi> thanks for*
<infinity> dash: It's been a while since I messed with it.  There are some obscure docs at Freescale that detail the kernel command line arguments for display output.
<dash> Yeah
<dash> I did what I thought they said, and got no luck. :)
<dash> setenv bootargs ro console=ttymxc0,115200n8 root=UUID=12460c31-1685-4cb8-a8d5-1cfe1d441b16 video=mxcdi1fb:RGB24,VGA-SXGA vga di1_primary
<dash> i still get 1024x768 same as before =/
<mythos> ok, i orderd one... but 20$ wire-transfer charge is a bit high, imho
<dash> shoulda used bitcoin
<mythos> there was no option for bitcoins
<mythos> ;)
<djszapi> ogra_: finally, I got the sound work even with the server preinstalled stuff
<djszapi> I mean alsa, I do not give anything about pulse really :)
<damian0815> djszapi: did you need to modprobe something by hand?
<djszapi> damian0815: nope
<damian0815> huh
<damian0815> ok
<djszapi> ogra_: ping
#ubuntu-arm 2012-05-24
<develtech> hi everyone
#ubuntu-arm 2012-05-25
<djszapi> ogra_: hey
<djszapi> ogra_: I tried to clone the 12.04 installation after installing my daemon on the pandaboard, but when the replicated sdcard boots up, the system cannot realize the /dev/ttyUSB* ports with usb-serial and modems on those.
<djszapi> What can cause this ? If I use the original sdcard, then there are no such things happening. Is there any idea I could try out for repearing this before I begin the looong replication procedure again ?
<TypoNAM> how are you cloning the SD card?
<djszapi> dd
<djszapi> I am cloning the content obviously, not the physical device. ;)
<TypoNAM> you're just dd the entire card and not just a single partition correct?
<djszapi> the entire sdcard
<djszapi> first onto my usb pendrive, and then back to the other
<TypoNAM> ok, oh and you did make sure to change /etc/fstab to not use a UUID on the root partition mount, right?
<djszapi> that is why it is so long. I have not taken an image onto my hard disk of the laptop yet.
<djszapi> TypoNAM: I am unsure how that is related to the /dev/ttyUSB* problem.
<TypoNAM> hmmmm
<djszapi> what is the name of the kernel package ?
<djszapi> I would try to reinstall the kernel.
<djszapi> since this is a kernel task.
<djszapi> http://lxr.free-electrons.com/source/drivers/usb/serial/pl2303.c?a=arm -> this driver, precisely.
<TypoNAM> so it boots up just fine and you can access the shell without any problems?
<djszapi> yep
<djszapi> I am now behind ssh over the ethernet port
<djszapi> usb ports are not really recognized with usb-serial pl2303 cables at least.
<djszapi> udevadm monitor& shows kernel messages while plugging those in though
<djszapi> just no /dev/ttyUSB* created.
<djszapi> if I use the same environment, but the original sdcard, everything is alright.
<TypoNAM> strange
<djszapi> indeed
<djszapi> so what is the kernel package name ?
<djszapi> Perhaps a simple reinstall of that fixes this very issue
<TypoNAM> checked dmesg?
<djszapi> about ?
<TypoNAM> dmesg | less  and see if there's any errors reported related to driver failures
<djszapi> dmesg checks usually end up seeing something not telling anything to an average user that can be used for repearing.
<TypoNAM> the only things I can think of by cloning an sd card to another sd card and it failing to work is: / failed to mount due to UUID being different in fstab, or you didn't do a complete clone, meaning contents at the end of the sd card failed to copy because the end of the destination was reached
<TypoNAM> when you used dd, did you clone to an image file on your Linux workstation then dd that image on to the sd card, or did you do a literal dd from sd card to the other sd card?
<djszapi> TypoNAM: I do not have two sdcard slots
<djszapi> TypoNAM: as I mentioned above, I used an interim usb pendrive for the transferring.
<TypoNAM> eeek, ok I missed that part then
<TypoNAM> why did you use a pendrive instead of as an image to a hard drive instead?
<djszapi> TypoNAM: why wouldn't I ?
<djszapi> Using hard disk space for 4 GB requires 4 GB free space on the hard disk...
<djszapi> not to mention, way harder to carry that way to my colleagues
<TypoNAM> here's what I do when I clone USB drives and sd/mmc cards: dd if=/dev/SrcDevice of=myClonedDrive.img bs=512K   then writing that image back on to an actual device: if=myClonedDrive.img of=/dev/DestDevice bs=512K
<djszapi> Like I said, that is unacceptable in my case.
<djszapi> because of two very important reasons.
<djszapi> not to mention, usb pendrive should work anyway
<TypoNAM> well because 4GB != 4GB on SD cards that are not exactly the same model, much less across different mediums, in this case an SD card to thumb drive
<djszapi> huh ?
<TypoNAM> case in point, I have two 8GB sandisk SD cards, one is actually 104MByte / 212992 blocks less than the other 8GB cause the one that has less blocks is newer than the other one.
<djszapi> they are totally the same sdcards
<TypoNAM> but your USB drive is not if it isn't more than those SD cards as it could be the one causing the transfer cut off point cause dd reached end of file on destination
<djszapi> it is totally bigger
<djszapi> 8 GB
<djszapi> so + 4 GB ...
<TypoNAM> insert your sd card into your Linux workstation and then do: parted --list /dev/SDcardDevice
<TypoNAM> then remove it and insert your other sd card, and see if they're matching
<djszapi> they do.
<djszapi> I have checked those things after flashings.
<djszapi> and to be honest: if they did not match, there would be way bigger issues than just /dev/ttyUSB0
<djszapi> aye, kernel reinstall helped.
<djszapi> nice :)
<TypoNAM> if I were you I wouldn't be too happy, because if a reinstall fixed it then who knows what else is corrupted on that card, I wouldn't trust it what so ever
<djszapi> wouldn't happy with a fix ? :o
<djszapi> In fact, I am super happy about it.
<orated> Hello! I used ubuntu-11.10-preinstalled-desktop-armel+omap.img image on BeagleBoard B4 and I'm not able to use any usb-storage device.http://pastebin.com/V2sdn3XM http://pastebin.com/tnD1QqDS Both the BB and USB hub are externally powered. Am I missing something?
<orated> ppisati: Hi
<scientes> the arm cross-compiler can't build the kernel for me anymore
<scientes> /usr/bin/ld.gold.real: error: scripts/genksyms/parse.tab.o: incompatible target
<scientes> i tried make clean
<scientes> CONFIG_CROSS_COMPILE="arm-linux-gnueabi-"
<scientes> /usr/bin/ld.bfd.real: scripts/mod/modpost.o: Relocations in generic ELF (EM: 40)
<scientes> i tried checking out back to 3.4 but that didn't do it eithe
<prpplague> ogra_: horrible horrible laptop - http://www.frys.com/product/6515793?site=sr:SEARCH:MAIN_RSLT_PG
<GrueMaster> prpplague: so, other than being preloaded with Windows 7, what else is wrong with it?
<prpplague> GrueMaster: it has a quirky bios called H2O bios, and it HATES linux
<GrueMaster> ouch
<ojn> H2O? Heh
<scientes> definitely not arm....
#ubuntu-arm 2012-05-26
<orated> Hello! I'm running Ubuntu on  Beaglebaord B4 and trying to get usb storage device working. I have both Beagleboard and USB hub externally powered, still I'm not able to get access to usb storage device. http://paste.ubuntu.com/1008505/ Am I missing something?
<scientes> is this a toolchain problem or a linux build system problem: /usr/bin/ld.bfd.real: scripts/genksyms/parse.tab.o: Relocations in generic ELF (EM: 40)
<scientes> my cross-builds of the linux kernel arn't working anymore
#ubuntu-arm 2012-05-27
<int_ua> rsalveti: ping
#ubuntu-arm 2013-05-20
<elwood> hi all
<elwood> I'm reading abou ubuntu and arm, but it's the arm image a full desktop or just a server without X?
<infinity> Which "the ARM image" are you referring to?
<elwood> https://wiki.ubuntu.com/ARM  this one
<elwood> i have an allwinner10 tablet, it's a pengpod, and I'm running debian+lxde on it.
<infinity> We ship an image for Pandas that's a full desktop, and then some proof of concept ubuntu-touch images that are tablet/phone images, and then we ship netboot stuff for a few platforms that you might call "server".
<infinity> elwood: The OMAP, mx53, and ac100 images listed there are desktop images.
<infinity> elwood: But given that you don't want an INSTALLER image anyway, since we can't boot on your hardware, the point's probably moot.
<elwood> infinity: so I have just to try if they are booting for my hw?
<infinity> elwood: None of them will boot on an A10.
<infinity> elwood: I can save you the trouble, if you were hoping for a bootable image, we don't ship one that works for you.
<elwood> infinity: so I have to create an image on my own or there is no possibility at all?
<infinity> elwood: Creating an installer image seems like a bit of a waste of time for just you.  If I were you, since you clearly have a kernel that works (which we don't ship for the A10), and a Debian installation, I'd debootstrap saucy to a subdirectory, chroot in, and play around a bit.
<infinity> elwood: Likely will still be a bit of fail there unless you also have 3D drivers, etc.
<elwood> yes I have a debian wheezy working
<elwood> with mali/opengl support
<infinity> Kay, well.  If you can make that go, you can probably also make Ubunty go.  I'd just scrap the idea of trying to create an "image", and instead just piece together a manual install, but that's just me.
<infinity> Not sure what the state of A10 support in the multiplatform kernel is, but if that's improving, maybe we can enable it for raring.
<infinity> Even then, we'd also need to sort out bootloaders and other messes, which is platform-dependant, not SoC-dependant, so you'd probably still be in manual install land.
<elwood> yes, I mean manual install with create an image, I've expressed wrong. English is not my language :)
<infinity> Sure, well, the easiest manual ways to go would be to either debootstrap something on your Debian system, or download and untar ubuntu-core to a subdirectory on your Debian system, and then play from there.
<infinity> http://cdimage.ubuntu.com/ubuntu-core/releases/13.04/release/
<elwood> so there are packs for arm?
<infinity> Neither one of those is quite "installing", per se, but the next move from there could be to try to jame your kernel and driver into an Ubuntu rootfs and deplace Debian with it, if you wanted.
<elwood> ok so I'll try, thanks for the suggestions
#ubuntu-arm 2013-05-21
<yunfan> hi i have a arm chromebook with ubuntu 1304 installed, now i have set the session to LXDE , but when i restart lightdm it still use the session gnome-session
<yunfan> what's wrong with my step? i just use sudo /usr/lib/lightdm/lightdm-set-defaults --session LXDE
<OurMaNdO|W> how can i find out what packages are available for the arm port of ubuntu 13.04
<yunfan> by adding the ppa source?
<OurMaNdO|W> ppa's dont support arm
<OurMaNdO|W> http://askubuntu.com/questions/181409/what-ppas-support-the-arm-architecture-armel
<yunfan> who said?
<yunfan> i am using it!!!
<yunfan> on my arm chromebook
<OurMaNdO|W> ask ubuntu was wrong!!!
<yunfan> OurMaNdO|W: its not wrong, the answer said `currently`
<yunfan> and notice its date
<OurMaNdO|W> oooo
<OurMaNdO|W> my bad
<OurMaNdO|W> did u have to install the source or was in stock
<yunfan> sorry i dont understand
<OurMaNdO|W> nvrmind i get it
<OurMaNdO|W> thanks for the help
<yunfan> i finally solved my problem :]
<i2c> hey guys
<i2c> i want to enable my i2c
<i2c> in ubuntu os
<i2c> but i can't
<i2c> i just have 2 i2c while i should have 3 or 4
<evilt0ne_> hi
#ubuntu-arm 2013-05-22
<NekoXP> hey guys. anyone know where in gdm or standard gnome desktop session stuff the backgrounds are handled, like when you swap backdrop it does that fade between backdrops?
<OurMaNdO|W> compiz
<OurMaNdO|W> compizconfig settings manager
<OurMaNdO|W> under animations
<OurMaNdO|W> will allow u to change
<NekoXP> this is pre-compiz.. like maverick/oneiric kind of era. I assume gnome-session is handling the background transitions, but it seems unlikely (or maybe it is very likely) that gdm wouldn't share this code (since it does the same thing logged in and for loading the gdm splash)
<OurMaNdO|W> i was using compiz with 10.04
<OurMaNdO|W> which was before maverick and oneiric
<OurMaNdO|W> i also use it on 13.04
<NekoXP> hmm window manager is a good place to look, I guess gdm needs one too and that makes sense.. so it'd be metacity
<OurMaNdO|W> window manager doesnt handle window animations
<OurMaNdO|W> a fade is an animation
<OurMaNdO|W> opengl and compiz handle it
<NekoXP> okay you're just not helping at all.
<NekoXP> I have metacity and gdm. I updated cairo for a good reason, and now my fade-between-backgrounds on gdm and inside gnome using the gnome appearance properties has turned from a fade into a kind of burn-in effect (everything scales to white). I am looking for the thing that handles that fade effect *for the background image* on the root window.
<NekoXP> it would probably be also called from anything that uses the xml backdrop stuff, since every transition does the same, it should be the new backdrop going from full transparency to full opacity over the current background, but it instead does what in Photoshop is the multiply filter, then snaps to the new image. So I assume it's some kind of alpha channel pre-multiplication thing or the values are backwards or.. I can't figure out what is even
<NekoXP> handling rendering the backdrop let alone find code
<NekoXP> there's got to be something that's watching for gconf updates in desktop/gnome/background and then doing the rendering.. if I knew that I'd know what it told to go render it if it didn't do it itself..
<NekoXP> bang. it's gnome-settings-daemon
<NekoXP> which calls libgnomeui...
<mfisch> ogra_: you still around?
#ubuntu-arm 2013-05-24
<RagBal> I just installed Ubuntu core 13.04 rootfs on my BeagleBone Black and booted it, I statically configured eth0 in /etc/network/interfaces but I still have no network connection. Am i forgetting something?
<angeloc> Hi guys, yesterday I announced MKU on Ubuntu devel discuss
<angeloc> this is the email
<angeloc> https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2013-May/014552.html
<angeloc> is is there someone who wants to try it say me what he thinks?
<reisei> hi, all! I'm using ubuntu on the Nexus 7. I'm trying to rotate screen in the landscape orientation, but the touch input rotates wrong. How can I rotate the screen properly?
<reisei> I tried xrotate and xrandr
<reisei> Thank you very much.
<shadeslayer> ogra_: so I was trying out http://cdimage.ubuntu.com/kubuntu-active/daily-preinstalled/current/ on the N7
<shadeslayer> ogra_: and it boots, and ttyACM0 comes up, I can run run screen on it, and it all works, except the OEM thingum doesn't come up
<shadeslayer> and the screen is completely blank, so you can't add a user and therefore I can't login via /dev/ttyACM0 as well
<OurMaNdO|W> anyone know a good wifi adapter for the beaglebone black
#ubuntu-arm 2013-05-25
<FreezingCold> Hey, is it possible to install Ubuntu on a MK808 without an SD card?
<masta> ndec: do you know how to setup the MLO and u-boot for OMAP4 board using raw mode, not the vFAT partition way?
<isaias> Hello. Does Nexus 10 work just as well as Nexus 7 with Ubuntu?
<isaias> :(
<isaias> anyone?
<isaias> Hello. Does Nexus 10 work just as well as Nexus 7 with Ubuntu?
<ogra_> isaias, yes
<ogra_> (assuming you use ubuntu touch)
<doomlord> is this the right channel to ask about ubuntu on android devices... i see the mk908 with a quadcore,  does ubuntu run on this ? that would be rather nice
#ubuntu-arm 2013-05-26
<angs> is armv4l different than armv4?
<infinity> angs: The "l" means little-endian, which all our ARM ports are.
<angs> thank you infinity
<angs> infinity, I would appreciate if you could reply to one more question. uname -a of my device is armv4l, and I compile openssl and I get arm_arch.h:35:5: error: #error "unsupported ARM architecture"
<angs> however, on the 35th line of the library https://github.com/joyent/node/blob/89dcf22/deps/openssl/openssl/crypto/arm_arch.h there is arm_arch__ 4
<angs> do I get error because my arch is armv4l?
#ubuntu-arm 2014-05-20
<arg> Having issues with unity-control-center info on ubuntu 14.04. Settings--> Details not opening. Syscall trace shows me that it is waiting for a read infinitely. Any help with how to proceed further with debugging would be really helpful
#ubuntu-arm 2014-05-21
<rooted> hello ,  is there an ubuntu version for a raspberry pi ?
<hrw> rooted: no
<hrw> rooted: and will not be
<hrw> r/pi has too old cpu
<rooted> hrw , no version because an old cpu ?
<hrw> yes
<rooted> i think there will be new version of raspberry pi , called compute moudule
<rooted> so , some arm version can install same packages as the normal ubuntu ?
<ogra_> we'll see once that thing is available :)
<ogra_> if you want something Pi like that runs ubuntu, get a beaglebone
<hrw> rooted: that module is same crap as r/pi
<rooted> orga_ ive got one actually and a really love it.
<ogra_> or wait for the new Pi and hope someone does the necessary porting
<rooted> and now am going for cubieboard
<ogra_> hrw, i think there is a v7 Pi planned ...
 * ogra_ read about that somewhere 
<hrw> ogra_: let it rest in pieces
<ogra_> Pi-eces
<ogra_> :)
<rooted> lool
<hrw> ;D
<hrw> ok, enough of r/pi talk
<hrw> my weekly limit will end too soon
<ogra_> dev-boards are not really the super hot focus in ubuntu anyway anymore ...
<rooted> so raspberry pi , is a crap because it has an old cpu ? i love that you can find every thing for it , such as camera , speaker's , sensors
<ogra_> its either server/arm64 or phones (with an android container to use the binary blobs)
<lool> rooted: the new module is the same hardware as the current rpi
<rooted> well , i loved the ubuntu edge idea, but its a shame the campaign stoped.
<lool> rooted: just different form factor
<lool> rooted: there wont be an ARMv7 rpi for 6months+ at least
<rooted> hmmm
<ogra_> well, wait another year and the phones will have the specs the edge was aiming for
<lool> rooted: I recommend beaglebone black as an alternative, but it might be hard to get in certain locations
<rooted> i know , it was sad  that the campaign stopped , any chance to restart it again ?
<rooted> lool ive got one , the rev b and C
<rooted> C is on the way actually
<hrw> ogra_: so far only ram and storage size is lacking in market phones
<lool> rooted: it's technically superior to rpi and can run Ubuntu (but is more expensive)
<rooted> lool yeah, $10 extra
<hrw> beaglebone black is 45$ iirc
<lool> sadly BBB is still hard to get in France
<ogra_> hrw, right, and there are already phones with 3G RAM and 64G disk ... so we're getting close
<hrw> rooted: what for you use r/pi?
<rooted> lool , subscribe to notification service at adafruit.
<hrw> if video decoding then consider cubietrack
<hrw> if playing with signals then beaglebone
<rooted> hrw , am working on an educational project, later to be for a comercial usage , for an OCR system
<hrw> rooted: so camera and some storage + cpu speed?
<hrw> rooted: cubietrack + usb camera + sata hdd. dualcore cpu onboard
 * rooted got angry when he started knowing about ubuntu edge campaign and realized its stopped 
<rooted> hrw exactly
<ogra_> hrw, the RPi is the MSOffice of today :) too many people have it so you dont get around it in some sapces ... i.e. educational fiddling
<rooted> hrw , yeah just knew about cubieboard , i was thinking to make a customized case for such idea , with paper dispenser
<hrw> ogra_: good thing is that I can ignore r/pi related talks as I do not have to worry about <armv8 now
<ogra_> rooted, and electrically driven toilet paper roll ?
<rooted> orga_ maybe :p
<lool> rooted: I avoided ordering from the US so far, but maybe I need to revisit this
<rooted> lool , well the best thing was the notification service.
<ndec> hi ogra_ , i came across this old IRC log http://irclogs.ubuntu.com/2012/11/08/%23ubuntu-arm.txt. do you remember the issues you had with using -S with fastboot flash?
<ogra_> corrupt partitions after tranfer
<ogra_> *trans
<ndec> hmm..
<ndec> so you aren't using it, right?
<ndec> even 2 years later?
<ogra_> we dont use much of fastboot at all anymore
<ndec> do you remember if it was on some h/w, or possibly any h/w?
<ogra_> only for the initial bringup to flash kernel and boot partitions ...
<ogra_> err
<ogra_> boot and recovery, sorry
<ogra_> the rest is ubuntu in ubuntu touch
<ogra_> (upgrades run from recovery, not using fastboot at all)
<ndec> the initial bring up is what then?
<Tassadar> nexus 7 (grouper) had this problem, I don't remember anybody really trying it out on anything else
<ogra_> ndec, running ubuntu-device-flash to get the initial install going ... that tool boots into bootloader, flashes boot and recovery, then reboots into recovery and runs the rest of the install from there
<ndec> ok.
<ogra_> but neither boot not recovery need to be sparse
<ndec> yep.
<ogra_> so we dont need -S
#ubuntu-arm 2014-05-22
<rooted> hello
<rooted> am ready to install install ubuntu on beaglebone black , any warnings i should know about ?
<rooted> what is the best arm version for ubuntu suites beaglebone black ?
<ogra_> depends what you want to invest :)
<ogra_> the best one is probably an X-Gene board
<ogra_> (which is supported by default)
<rooted> orga_ i want to install ubuntu on beaglebone black , what version should i download ?
<ogra_> rooted, not sure i think trusty netinst should work ... ppisati might know
<rooted> thanks
<rooted> hello , ive installed ubuntu arm version 13.04 , its in the terminal mode, but how can i set the wireless dongle , password for access point ?
<rooted> :P
<ogra_> rooted, try https://wiki.debian.org/WiFi/HowToUse#WPA-PSK_and_WPA2-PSK
<rooted> orga_ your a life saver did you know that ?
<ogra_> heh
<rooted> its says here after the settings, DHCPDISCOVER on wlan0 255.255.255.255 port 67 interval 10 , dhclient.c error 1996 : failed to send 300 byte long packet over wlan0.. any hint  ?
<rooted> got it , its seems , from the wifi dongle , there is a problem with it , just change it
#ubuntu-arm 2014-05-23
<mistawright> hi guys i have ubuntu on my beaglebone black and need to know how to update the kernel. I have a zImage built and ready for the kernel and have copied the kernels lib/modules/ arleady
<rooted-arm> testing testing , beaglebone black..
<ogra_> failed
 * rooted cries 
<ogra_> :)
<rooted> for that smile i think ill donate to ubuntu-arm team as a support.
<ogra_> good plan :)
<rooted> yeah it is and am serious about it, you guys are making great job.
<rooted> were are you from ?
<ogra_> germany
 * rooted feels afraid.
<ogra_> oh ?
<rooted> j/k
 * ogra_ is pretty tame :) 
<rooted> Lol.
<rooted> any new arm project ?
<ogra_> ubuntu touch
 * ogra_ moved on from boards to real devices (and insane workarounds to get driver support)
<ogra_> and most of the other arm guys in here do real server boards nowadays
<ogra_> like xgene etc
<rooted-arm> thats great to hear, so after 1 year , al devices are going to be similar to ubuntu edge spesifics , the question is what going to be the plan for ubuntu touch after 2 year ?
<rooted-arm> 1 year sorry
<ogra_> heh, let us get there first :) for now we're still poking around to get a 100% phone system working
<ogra_> once thats done and rock solid we'll work on desktop convergence
<rooted-arm> am new in the boards field but i think is cubietruck is the powerful-est ive just knew so far
<ogra_> well, you havent seen xgene then :)
<rooted-arm> ill try to install ubuntu touch on my s5 , will try it
<ogra_> thats 64bit though ... a bit unfair to compare it to a dev board
<rooted-arm> ill search for xgene right away
<ogra_> http://www.apm.com/products/data-center/x-gene-family/x-gene/
<rooted-arm> i think arm team should use indigogo donation , will be the best donaitor
<rooted-arm> so its a full board , or just a chip ?
<ogra_> http://www.pcworld.com/article/2081160/appliedmicro-offers-first-development-kit-with-64bit-arm-server-chip.html
<ogra_> there are full boards
<ogra_> and racks ...
<rooted-arm> nice..
#ubuntu-arm 2014-05-24
<MrBIOS> hey folks
<odroid> Hi all just wanting to know if the arm version of ubuntu which is still on version 13.10 saucy is active now that ubuntu 14.04 is out
<odroid> i am wanting to apply system updates
<rooted> orga_ you there ?
<MrBIOS-DT> hey folks
#ubuntu-arm 2014-05-25
<HiDeHo> hi all i cant seem to find the adobe flash player in package manager. do you know where it may be.
#ubuntu-arm 2015-05-19
<zaniyah> is there somewhere I can find what the sources.list should look like for an ARMv8 system?  I got one pre-installed but the repositories are those of the supplier, and are on their internal network so I can't install anything
<rbasak> deb http://ports.ubuntu.com/ubuntu-ports trusty main universe
<rbasak> Also lines for deb-src and trusty-updates
<rbasak> And trusty-security. All combinations.
<zaniyah> thanks
#ubuntu-arm 2016-05-23
<Aussie_matt> anyone running ubuntu on mk809iv? it's rk3188
#ubuntu-arm 2017-05-26
<setra> I have armbian for H3 and have camera issues, as soon as I load gc2035 and vfe_v4l2 I get camera chip not supported. I had debian  before and it worked
