#ubuntu-arm 2009-05-28
<tonyyarusso> Is there a touch-friendly ARM image ready for installation on devices such as the Nokia N810 yet, or is it still just a developmental concept?
<Martyn> Morning
<persia> Good day.
#ubuntu-arm 2009-05-30
<garren> morning
<garren> Im still quite new to this.. debootstrap basically creates a ubuntu image in a file location?
#ubuntu-arm 2010-05-31
<snadge> is there an faq about what things you can buy that will run ubuntu arm?
<snadge> https://wiki.ubuntu.com/ARM/DeviceSupport
<DanaG> Beagleboard is nice... but wait for the xM.
<snadge> yeah i've been looking at that
<snadge> also heard a few things about the HP Airlife 100
<snadge> sure thats an android device but whatever
<snadge> im sure if it were to actually get sold somewhere other than spain
<snadge> people might run ubuntu on it ;)
<snadge> the xm is a nokia phone?
<tmzt> airlife is snapdragon based isn't it?
<tmzt> http://h20000.www2.hp.com/bc/docs/support/SupportManual/c02104127/c02104127.pdf
<tmzt> http://www.h-online.com/news/item/MWC-2010-Android-everywhere-931988.html
<DanaG> airlife has weird touchpad buttons.
<tmzt> required by android I think
<DanaG> http://beagleboard.org/hardware-xM
<DanaG> I hope they still register as 1, 2, 3.
<tmzt> extra?
<tmzt> extra cortex
<tmzt> could that hub by a switch (vlan enabled)?
<tmzt> oh it's a usb hub
<DanaG> SMSC LAN9514.
<DanaG> USB hub + ethernet in one chip.
<kblin> I wonder what that means for ethernet to usb hdd performance
<DanaG> well, if it's ntfs-3g, it's Le Suck, any way you slice it.
<DanaG> NTFS-3G is Le Suck even on eSATA.
<kblin> why would I use NTFS on a linux box?
<kblin> I mean, a filesystem with full windows ACL support would be nice for running a samba file server, but I don't think the ntfs-3g code can do that, even if ntfs supports that
<tmzt> ftp://ftp.hp.com/pub/open_source/Handheld/AirLife100/kernel.tar.gz
<snadge> i want to get an arm netbook or tablet.. im kind of waiting for google to make it a reality
<zyga> good morning everyone
<hrw> morning
<tmzt> snadge: chrome os?
<tmzt> what's the difference between that and meego+chrome or ubuntu lite+chrome?
<snadge> i wouldn't say theres much difference apart from chromeos has a chance of succeeding.. the others probably dont
<snadge> by succeed i mean, gain a meaningful percentage of the market share
<snadge> beyond 3 hobbyist geeks
<snadge> most of the arm stuff so far is aimed at tinkerers who dont care if stuff is broken
<snadge> excluding the new apple products which are closed and completely useless from the perspective of most people in here
<tmzt> snadge: I'm wondering, I think having the OS featues of Chrome is a big win, but being able to alt-tab to a traditional desktop has it's benifits
<hrw> asac: http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/u-boot/u-boot-git/beagleboard contains patches for bbxm u-boot
<neure> hi
<neure> which network things were supported by the installer?
<hrw> ho neure
<neure> something that i can turn usb to ethernet?
<neure> the adapter that i have is not supported :/
<ogra> hrw, is there anything thats not in sarkomans branch ? (i'm currently working on updating the u-boot packages)
<hrw> ogra: no idea - I know that this patchset is maintained by Koen Kooi and used on bbxm
<ogra> hrm
<ogra> i know that the XM patches entered the sarkoman branch short before lucid released
<ogra> i wonder which are better/newer
<hrw> Xm rev A was added today
<neure> hrw, do you - or anyone - know if the apple usb to ethernet adapter is supported by the installer?
<rcn-ee_lpt> and they work on my xm board... those zippy (expansion board) patches are nice too.. ;)
<hrw> neure: I use dm9601 cheap adapters
<ogra> hrw, hmm, i really perfer to keep building the package from one upstream branch
<hrw>  but I did not used
<hrw> neure: but I did not used them during installation
<neure> i want to try ubuntu but i cant until i get adapter that works during installation
<hrw> I used netbook install
<neure> you installed to usb? well for me, installing to usb doesnt work :/
<hrw> I did
<hrw> you have C2/C3?
<neure> C2
<neure> i tried with two different powered usb hubs and two different usb sticks
<hrw> my C3 works better after 0.22uF capacitor hack
<amitk> GCC begins move to C++http://lwn.net/Articles/390016/rss
<ogra> asac, i'll update u-boot-omap3 from http://www.sakoman.com/cgi-bin/gitweb.cgi?p=u-boot.git;a=shortlog;h=refs/heads/omap3-v2010.3 FYI
<xorAxAx> neure: i have problems with usb hubs as well
<mpoirier> amitk ?
#ubuntu-arm 2010-06-01
<ssk> how to add new drivers like ppp? i see that there are no modules for ppp connection using beagleboard.
<hrw> morning
 * cwillu yawns
<DanaG> ureadahead invoked oom-killer: gfp_mask=0xd0, order=0, oom_adj=0
<DanaG> nice.
<ogra> what HW is that ?
<DanaG> beagleboard.
<ogra> board, disk type, ram etc
<ogra> on SD card or USB key ?
<ogra> and do you have swap ?
<DanaG> Booted from 2GB SD card (that's 90% full), no swap.
<ogra> graphical env or only cmdline ?
<DanaG> oh, and: on host: hub 8-0:1.0: unable to enumerate USB device on port 1     usb 8-1: new full speed USB device using uhci_hcd and address 9      usb 8-1: device descriptor read/64, error -110
<DanaG> Commmand line, with some extra stuff (such as deluge).
<DanaG> Xorg is installed, but no display or login manager.
<ogra> hmm, i havent seen a beagle hitting OOM in a cmdline env yet
<ogra> is that a rev B ?
<ogra> (128M)
<DanaG> Nope, C4.
<ogra> hmm, thats indeed very weird
<DanaG> where's that ureadahead pack file?
<ogra> man ureadahead tells you
<DanaG> ah, I thought it was /var/lib/ureadahead/pack
<DanaG> File doesn't exist.
<ogra> though ureadahead should gracefully exit on Sd cards anyway
<ogra> with code 5 iirc
<DanaG> argh, tried to load g_audio, and got screenfuls of panic.
<ogra> g_audio ? isnt that OTG stuff ?
<DanaG> yeah.
<ogra> OTG is broken in the kernel still
<DanaG> I hope we'll get musb built-in but all the modules... modular.
<ogra> https://bugs.launchpad.net/bugs/566645
<ubot2> Launchpad bug 566645 in linux-ti-omap (Ubuntu Maverick) (and 2 other projects) "OTG configuration is broken on omap kernel (affects: 2) (heat: 14)" [High,Confirmed]
<DanaG> So then I can choose to use g_audio instead of g_ether, or such.
<DanaG> It also rather oddly hangs lsusb on the host.
<ogra> basically we dont have musb atm
<DanaG> I wonder why it doesn't work as a module.
<ogra> i think it didnt work compiled in either
<ogra> amitk would know, he ported the patch back then
<amitk> no porting involved, it was the state of musb in 2.6.33
<ogra> cooloney, can you make sure that our omap4 kernel has the same config for udebs as the omap3 one ? i think the files under debian.ti-omap/d-i/modules/ rule that, probably you can just copy them over
<cooloney> ogra: the d-i files in omap4 was copied from omap3 debian.ti-omap/d-i/modules/
<cooloney> ogra: they are the same, i never change that.
<ogra> they recently changed :)
<ogra> i just checked the nic-usb-modules package yesterday and its missing the same modules the omap3 one did
<ogra> mathieu added a fix afaik it was accepted to the tree already
<amitk> ... and that is why we are moving to a unified debian tree. That will be sync'ed across all branches, all releases.
<cooloney> ogra: oh yeah, i noticed that. will check it later. maybe just apply mathieu's patch
<ogra> that should be fine
<DanaG> also weird: cnetworkmanager --syscon doesn't list the wireless connection I stuck in /etc/NetworkManager/system-connections/
<DanaG> And it also ignores my "Wired Network" connection by that name, and instead creates an "Auto eth0".
<DanaG> I've never managed to get headless NetworkManager to work well.
<Laibsch> Hi everyone
<XorA> hey Laibsch
<Laibsch> XorA!
<XorA> Laibsch: joining the ubuntu party?
<Laibsch> I'm a bit surprised to find you here
<Laibsch> I think I probably was here earlier than you ;-)
<Laibsch> But probably not as active
<Laibsch> I always you'd never budge from being a staunch Debian user and Ubuntu-loather
<Laibsch> Good to see you here
 * XorA is paid to be here :-D
<Laibsch> are you?
 * XorA is a fedora user
<Laibsch> more power to you
<Laibsch> they should only hire people that at least have a Ubuntu tattoo to show their commitment
<Laibsch> anything less makes no sense ;-)
<XorA> hehe
<XorA> that might be why at UDS they kept trying to get me intot the "dark" room :-D
<Laibsch> probably
 * XorA is on contract with TI which is working on ubuntu stuff
<Laibsch> I see
<lool> XorA: Are you based in Nice?
<XorA> lool: Scotland :-D
<lool> Didn't know TI had a Scotland office
 * XorA has been in Nice
<XorA> lool: they dont, I contract
<lool> XorA: Well too bad we failed meeting at UDS then, I dont think I had the chance to chat with you, or if I did I failed I associated name and face
 * XorA is actually based in Dallas office
<neure> anyone used http://elinux.org/BeagleBoardUbuntu#NetInstall_Method ?
<neure> i get a kernel panic on boot :/
<lool> Oh you're based in Dallas, then I might see who you are
<XorA> lool: I was hanging with the TI dudes mostly, you would have found me in Xorg and ALSA talks
<Laibsch> lool: XorA is also one of the OE crowd
<amitk> XorA: not everyone is perfect, I hope you don't miss the bus to salvation ;-p
<amitk> (just kidding)
<Laibsch> hurry, doors are closing ;-)
 * Laibsch hears that all the time
<neure> http://www.pastie.org/986954
<neure> any suggestions?
<Laibsch> actually it's "please don't hurry or rush, doors are closing" ;)
<XorA> amitk: hehe, Im too old for distro wars
<hrw> amitk: better not start - he will try to move you from ubuntu to angstrom
<amitk> hrw: I've used OE before for the Zaurus 5500
<Laibsch> doesn't the Z predate OE?
 * XorA still has a 5500
 * Laibsch too
 * amitk too
<XorA> where is the ubuntu port?
<Laibsch> not more than one meter away ;-)
<Laibsch> XorA: working on it ;-)
<Laibsch> but probably impossible
<hrw> Laibsch: no, OE was made as replacement for OpenZaurus build system
<Laibsch> hrw: yes, I know
<neure> amitk, did you have some preinstalled image of ubuntu somewhere?
 * hrw does not have 5500 - donated to 2.6 hacker
<ogra_cmpc> there is a jaunty port for the zaurus somewhere
<XorA> Laibsch: if I knew how to rebuild full ubuntu easilly it would be real easy to do an armv4 port
<Laibsch> hrw: therefore the Z was there before OE
<DanaG> yeah, and it failed miserably last time I tried one.
<XorA> Laibsch: I just need a build farm
<DanaG> Kernel didn't have ucb1x00_ts enabled, or such.
<hrw> Laibsch: ah yes...
<amitk> neure: preinstall image? Not for Lucid. We will have preinstalled images for Maverick though.
<neure> :/
<neure> anything that i could try?
<ogra_cmpc> neure, that netinst image uses a kernel from rcn-ee, wait for him to be around
<ogra_cmpc> oh i lied, its hardy that was ported to the zaurus
<ogra_cmpc> http://www.omegamoon.com/blog/index.php?entry=entry081030-074514
<amitk> neure: did you try with a different usb-ethernet adapter?
<ogra_cmpc> use an asix or pegasus based one
<neure> amitk, no, i dont think i have one
<neure> i could perhaps get the apple one
<neure> is it known to work?
<ogra_cmpc> also did you file a bug aboout your partitioning error ?
<neure> no, i didnt
<ogra_cmpc> its very likely that you will hit it again even with a netinstall
<neure> maybe
<neure> if i do i can try to file a report
<neure> but its just 'doesnt work'
<ogra_cmpc> well, thats not a proper erro description we accept here :)
<neure> hmm
<neure> i have bootargs=vram=12M omapfb.mode=dvi:800x600-16@60 console=ttyS2,115200n8 root=/dev/mmcblk0p2 rw rootwait
<neure> i wonder what i should have in order to use this rcn-ee thing
<ogra_cmpc> no idea
<ogra_cmpc> rootwait is definately wrong for the official images
<neure> what does it mean?
<ogra_cmpc> but you might need it in rcn"s
<hrw> makes kernel wait for rootfs device to appear
<ogra_cmpc> it means to wait for the rootfs device until it shows up
<ogra_cmpc> since ubuntu always uses an initramfs in the official images thats not needed
<ogra_cmpc> we also boot in ro mode by default
<ogra_cmpc> because mountall remounts rw after fsck
<neure> hmm
<lool> mattman wrote me that he managed to boot to a console using our ti-omap kernel + qemu-maemo!   :-)
<Laibsch> XorA: lool shared with me a couple of blueprints discussed at UDS: https://blueprints.launchpad.net/sprints/uds-m?searchtext=arm-
<Laibsch> https://blueprints.launchpad.net/ubuntu/+spec/arm-m-cross-compilers looks like something you and I may be interested in
<neure> if i have this 16GB mmc card inserted, i get this: http://www.pastie.org/986970
<neure> is something wrong?
<XorA> lool: have you been to Nice BTW?
<neure> if i dont have it in there, i get http://www.pastie.org/986971
<lool> XorA: I came to visit, yes
<Laibsch> XorA: Ubuntu on ARM is still very young and evolving, so I have a hard time (and not enough of it)to keep up with the status
<lool> For a couple of days only
<lool> I wouldn't mind going back  :-)
<lool> it's an easy ride
<XorA> lool: same meeting as persia jumped out of hotel?
<lool> haha yes
<XorA> lool: you met me then
<lool> I was his translator in the hospital  :-)
<lool> XorA: I missed the morning meeting, but I think I saw you Monday afternoon
<lool> XorA: I am the guy who talked about cross-compilation
<XorA> lool: I was all in black wearing New Rocks
<XorA> lool: from weds onwards I had my nails painted
<ogra> Laibsch, i wouldnt call 1.5 years "young" :)
<Laibsch> I would ;-)
<lool> XorA: I only stayed until Tuesday evening I'm afraid
<lool> I missed the fingernails
<ogra> lool, he had them painted at UDS too
<neure> could it be that there is an issue with the sdcard?
<neure> could that be causing issues for server installer?
 * XorA should get his hair hot pink to make it wasier to spot :-D
<hrw> I remember how someone asked me 'why XorA paints his fingernails' ;d
<ogra> neure, your paste shows that you dont have a second partition
<neure> ogra, that is correct
<hrw> libnih - for all those with NIH problem?
<ogra> hrw, yeah *g*
<XorA> hrw: your answer?
<neure> ogra, that is sdcard with ubuntu installer on it,  created by script by rcn-ee..
<ogra> neure, then how do you expect it to boot from mmcblk0p2 ?
<hrw> XorA: because he can
<neure> well he doesnt tell what i should have as bootargs :(
<XorA> hrw: nice catch :-D
<hrw> XorA: I do not care how people look as long as they are fine with it
<neure> i tried to change it to p1 but that didnt help
<XorA> hrw: this is why I like working in linux, in the windows world I would always be the freak
 * XorA isnt good with suits
<ogra> neure, for netinstall you dont set root=
<ogra> it needs to load the initrd as rootfs
<neure> ogra, http://www.pastie.org/986979  -- without root
<ogra> how did you load the initrd ?
<neure> i dont know...
<amitk> :)
<neure> http://www.pastie.org/986986
<neure> like this
<neure> bootcmd=mmc init;fatload mmc 0 80300000 uImage;bootm 80300000
<neure> thats my bootcmd i wonder if thats ok?
<ogra> thats definately not right
<neure> great
<ogra> wait for rcn-ee
<neure> what should it be?)
<ogra> i guess he has a boot.scr file somewhere
<ogra> i have no clue about the unofficial images
<neure> lunch
<cwillu_at_work> neure, what's the problem?
<ogra> asac, x-loader and u-boot with XM support are in maverick now
<lool> ogra: Cool
 * ogra ponders about the x-loader-omap4 versioning
<ogra> lool, i have x-loader-omap4-L24.6-p1git20100520 what would you do with the L ?
<ogra> (its TI versioning for the omap4 branches, u-boot has that too)
<ogra> i'm inclined to just ignore th elintian warning, but we'll get probs if we ever have a unified x-loader package (not that i expect that to happen)
<lool> ogra: the L?
<ogra> -L24.6-p1git20100520
<ogra> is the version
<ogra> L24.6-p1 is what TI calls the release
<lool> It shouldn't be a problem for pdkg
<lool> dpkg
<lool> You can have as many dashes as you like
<ogra> well, usually x-loader is 1.1.4 or some such
<lool> It would be good to understand how they relate
<lool> Is it a 1.1.4 + patches?
<ogra> if we get a unified u-boot or x-loader package we'll struggle with the versions
<lool> ogra: I understand x-loader is a TI only project, so eventually everything will go upstream, right?
<ogra> i think its based on 1.1.4 but TI always uses L (for linux) 2.6 (kernel main version) -p* published version
<ogra> x-loader will even vanish soon and just become a binary header to u-boot.bimn
<ogra> *bin
<ogra> but still, the u-boot-omap4 version has the same issue
<ogra> i'd actually like to use their versioning, but once jcrigby is done and we have a unified numeric version it will force an epoch
<lool> ogra: If you're taking full tarballs from them, make sure the origin is reflected in the source package name and use their versions
<ogra> at least for conflict/replacing the binary versions
<lool> Well we could use different binary package names and provide an upgrade path
<ogra> i expect jcrigby's work to result in a u-boot source but u-boot-omap3 and omap4 binary packages
<ogra> hmm
<ogra> indeed, that would work
<ogra> ok, i'll keep the original TI versioning
<ogra> lool, thanks
<ogra> (effectively it doesnt matter anyway, i dont think anyone will actually use the binaires directly, they are for the image build system)
<asac> ogra: flash-kernel on omap is kinda destructive
<ogra> asac, yes, that'll change for maverick
<asac> why dont you use the defaults that are in the uboot source?
<asac> that looks really generic and good enough
<ogra> asac, because upstream u-boot has no concept for an initrd
<ogra> and we cant use boot.scr if we use NAND
<ogra> maverick will change that completely
<hrw> re
<asac> ogra: hmm. we cant use boot.scr if we use nand? why is that?
<ogra> because boot.scr only works from vfat
<asac> the default that is in uboot seems to do the right thing .. checks if sdcard is there
<ogra> right
<asac> otherwise uses nandboot
<ogra> but has no concept of initrd at all
<ogra> anyway, lucid is done
<asac> well. thats simple to add imo
<ogra> maverick will change the whole concept
<asac> ogra: right. problem is that once you install lucid you cant install anything else anymore ...
<ogra> since we ship our own u-boot now
<ogra> you can update the setup
<ogra> i'll take care for that
<asac> ah you didnt ship your own uboot
<asac> kk
<ogra> if you have a better concept, feel free to do an SRU
<asac> my image has that
<asac> thats the problem then
<asac> all fine
<ogra> oki
<ogra> time was to short in lucid to change the whole image build system
<ogra> which is why i relied on NAND
<ogra> asac, btw, any final word on the naming discussion?
<ogra> :)
<ogra> i'll start with the tool this afternoon
<ogra> (after the mobile meeting)
<asac> ogra: remind me about what naming discussion that is ;)
<ogra> asac, casper :)
<ogra> see the spec whiteboard
<asac> heh
<asac> ogra: EDONTCARE ;)
<ogra> ok
<asac> let me see whats going on on whiteboard
 * asac didnt intent do raise a long discussion
<ogra> btw, i didnt bother to rename the specs since th eteam will likely be renamed soon
<ogra> and i didnt want to do the renaming twice
<asac> ogra: well. but it was tough to find
<asac> ogra: can you paste the url again ;)
<asac> i wont be able to find it
<ogra> yeah, agreed
<ogra> https://blueprints.edge.launchpad.net/ubuntu/+spec/preinstalled-sd-card-images-for-omap
<ogra> hrm, no NCommander
<ogra> he had a task to care for libnih before the meeting
<ogra> oh, now upstart failed completely ... no wonder i dont find libnih on the ftbfs list :P
<ogra> hmm, funny, i dont see any recent upload
<Laibsch> How does one start to build Ubuntu for ARM from scratch?
<Laibsch> I thought about starting from Jaunty and then recompiling packages
<Laibsch> But Jaunty requires armv5t
 * ogra wonders why you would recompile
<Laibsch> I was wondering how to inflict a lot of pain on myself and base it off armv4
<hrw> Laibsch: you have armv4t?
<ogra> aww
<hrw> Laibsch: armv4? strongarm?
<Laibsch> XorA seemed to be interested in it
<Laibsch> this is as much about getting binaries as it is about learning the steps
<ogra> iirc there was a spec about rebuilding the whole distro for other arm versions
<lool> Laibsch: The way mojo did it and which is proven to work is to rebuild the archive multiple times against itself
<ogra> not sure where it went though
<hrw> Laibsch: grab as fast arm buildd as possible, install ubuntu and do rebuilds for armv4/eabi? nightmare task
<Laibsch> lool: take Jaunty and rebuild the toolchain packages, then reiterate?
<Laibsch> I see
<lool> Laibsch: Take whatever Ubuntu version, change the toolchain, rebuild the modified archive against itself, rebuild again and again
<Laibsch> Maybe sticking with armv5t is a better idea then (probably plenty of pain as is ;-))
<lool> I'd recommend taking the latest version of Ubuntu
<lool> (for rebuilds)
<Laibsch> OK
<ogra> or get some more recent HW :)
<ogra> money seems the easiest solution for your prob
<Laibsch> Where is the armv7 vs. armv5t vs. armv4 switch?
<Laibsch> ogra: you don't seem to understand my prob
<ogra> jaunty v5, karmic v6, lucid v7
<Laibsch> I don't have a particular prob
<ogra> the switch is done in the compiler defaults iirc
<Laibsch> ogra: See my comment 19:18:49
<Laibsch> ogra: thanks
<Laibsch> XorA: ^^^
<Laibsch> lool: Is there a way to find out if the numbers of compile iterations have been sufficient or not?
<Laibsch> debdiff $deb1 $deb2?
<Laibsch> or something like that?
<neure> back
<neure> cwillu_at_work, i am having hard time installing ubuntu on my beagleboard C2
<cwillu_at_work> can you be more specific? :)
<cwillu_at_work> are you using rootstock?
<neure> no... 1) installer doesnt recognize my moschip network usb to etherner adapter
<ogra> 'doesnt work'
<ogra> :P
<neure> 2) server installer fails to format usb stick
<cwillu_at_work> you should use rootstock :D
<neure> i guess so then
<neure> im trying to figure out how to boot http://elinux.org/BeagleBoardUbuntu
<neure> but i dont know what boot environment variables it needs
<cwillu_at_work> which, the kernel, or u-boot?
<neure> any
<cwillu_at_work> c2 will have a pretty old u-boot, but it should still boot fine
<neure> should i upgrade?
<cwillu_at_work> neure, have you done ./setup_sdcard.sh --mmc /dev/sdX --uboot beagle?
<neure> cwillu_at_work,  yes
<cwillu_at_work> and you booted with the user button held down?
<neure> yes
<cwillu_at_work> you have a serial line hooked up?
<neure> yes
<neure> i can see kernel booting
<neure> but then it fails to figure out where is root
<cwillu_at_work> what's the kernel panic?
<ogra> cwillu_at_work, iirc his u-boot doesnt load boot.scr
<ogra> by default
<cwillu_at_work> neure, boot up, and pull up the u-boot prompt over serial
<neure> if i have some root= in boot args, it fails to mount that
<cwillu_at_work> neure, tell me what the bootargs are set to
<neure> bootargs=vram=12M omapfb.mode=dvi:800x600-16@60 console=ttyS2,115200n8
<cwillu_at_work> neure, and the card mounts fine on a desktop, and you properly unmounted it?
<neure> bootcmd=mmc init;fatload mmc 0 80300000 uImage;bootm 80300000
<neure> yes
<neure> the card has only one partition
<neure> boot fails it says it cant find init
<cwillu_at_work> neure, you'll need "rootwait root=/..." in bootargs
<neure> root= what?
<cwillu_at_work> root=/dev/mmcblk0p1
<ndec> ogra: hi
<neure> iirc i tried it
<ogra> ndec, hey
<neure> let me try again
<cwillu_at_work> or mmcblk0p2 if it's a second partition
<cwillu_at_work> neure, you had rootwait as well?
<neure> yes
<neure> let me try and get you the message
<ndec> ogra: if I want to get automatic login on the console by default, what's the easiest way?
<ogra> ndec, i think asac has a script for that
<ndec> ogra: I don't need root login, so any user is okay
<ogra> though thats rootlogin by default
<ndec> ogra: that's okay too...
<ogra> asac, ?? ^^^
<cwillu_at_work> ndec, /etc/init/tty1.conf sets up the login prompt on tty1
<neure> cwillu_at_work, i get [   24.414520] Kernel panic - not syncing: No init found.  Try passing init= option to kernel.
<cwillu_at_work> o_O
<cwillu_at_work> neure, try init=/bin/bash
<cwillu_at_work> oh, wait
<cwillu_at_work> one sec
<cwillu_at_work> neure, your rootstock failed probably
<cwillu_at_work> neure, which qemu packages did you isntall?
<ndec> cwillu_at_work: but i want autologin. i have automatic tests that reboot the board and run afterwards, so I need to make sure that I can autologin
<neure> i didnt
<neure> cwillu_at_work,  i used http://elinux.org/BeagleBoardUbuntu
<cwillu_at_work> ndec, that's nice.
<ndec> cwillu_at_work: what is nice?
<cwillu_at_work> ndec, it's almost like I was giving you exact hint you need, and you missed it ;)
<cwillu_at_work> neure, install qemu-kvm-extras-static, and rerun rootstock and remake the card
<neure> cwillu_at_work,  i was trying "NetInstall Method" on that page
<neure> i havent run rootstock at all
<neure> how much rootstock needs diskspace?
<neure> i dont have much on my vmware  :/
<cwillu_at_work> neure, it needs about as much room as the final image size
<asac> ndec: we have a package for that ...
<neure> so 1 GB should be enough?
<cwillu_at_work> re: net install, I presume you got to the part where it said "If boot fails... upgrade x-loader and u-boot ... and clean u-boot environment vars"?
<neure> E: Couldn't find package qemu-kvm-extras-static
<cwillu_at_work> and ignored it, given that you asked if you should update u-boot?
<ndec> asac: which package?
<neure> im running ubuntu 9 something in my vmware
<asac> ndec: see msg
<asac> ndec: you want autologin serial console?
<asac> as root?
<asac> or autologin virtual terminal?
<ndec> asac: root or not, don't care.
<asac> the package isnt published yet (reason see msg)
<cwillu_at_work> asac, come on, it's a one line change to /etc/init/tty1.conf :p
<asac> ndec: serial or virtual terminal?
<asac> cwillu_at_work: yes, its a one line change, or some magic ;)
<asac> we opted in to magic
<cwillu_at_work> ugh
<cwillu_at_work> bad asac, BAD.
<asac> as you cannot change .conf files
<asac> in a package
<cwillu_at_work> _why_ does it need to be a package?
<ndec> asac: serial
<asac> ndec: do you need a package or can i just give you the files?
<ogra> cwillu_at_work, because this is ubuntu :)
<cwillu_at_work> ogra, "if dkms is madness, _this_ is sparta"
<ndec> asac: whatever is simpler for you... honestly I just need the 1-line change ;-)
<ogra> cwillu_at_work, why would dkms be madness ? we use it all over the distro
<cwillu_at_work> ogra, it was an excuse to use a good quote :p
<ogra> heh
<cwillu_at_work> asac, agra, repeat after me:  "apt is not a global control panel"
<neure> cwillu_at_work,  will rootstock make installer image or what?
<asac> ndec: cool. then just take that change for now ;)
<asac> ndec: and wait for the magic to pop up on a tree ;)
<cwillu_at_work> neure, rootstock makes the final installed image, you just need to dump it onto a card and boot
<neure> :/
<ndec> asac: but I don't have the 1-line for now...
<neure> i have 16GB sdcard
<neure> so i would need 16GB free in my vmware
<neure> which i dont have :/
<cwillu_at_work> hardly
<neure> hardly?
<cwillu_at_work> you only need the tarball, which will be 600mb or so
<cwillu_at_work> then you just write it out to the sd card like it was any other hard drive
<cwillu_at_work> mk_mmc and company does exactly that
<neure> ok so it might work even with ~2GB free to make 16GB image?
<cwillu_at_work> neure, exactly, because you're not actually making a 16GB image
<neure> well it starts by "I: Creating temporary Image" so i was worried.. :P
<cwillu_at_work> it just needs to be big enough to actually complete the install, the final size of the card doesn't matter
<neure> i'll give it a try
 * cwillu_at_work cringes at the thought of running rootstock (which uses a vm internally) under vmware
<cwillu_at_work> neure, hmm
<cwillu_at_work> you know, you could actually use one of the prebuilt images on the same page I bet
<neure> cwillu_at_work, is there such?
<cwillu_at_work> neure, brief tangent:  when reading technical documentation other than reference material (which that link isn't), it's usually a good idea to read the whole thing once through before actually attempting to follow the instructions
<cwillu_at_work> the instructions to use a prebuilt image is the first thing after the table of contents :p
<neure> the demo image in the beginning is 2G
<neure> my sdcard is 16
<cwillu_at_work> doesn't matter
<neure> and i need the space
<cwillu_at_work> your reading comprehension leaves something to be desired :)
<cwillu_at_work> first, the rebuilt images are tarballs, which are like zip archives
<neure> ah
<neure> so --imagesize 2G has very little no no meaning at all?
<cwillu_at_work> pretty much
<neure> ok i will try
<neure> or well
<cwillu_at_work> it's used for the internal virtual machine during install, and rootstock can (and does by default I think?) give a raw image of that size (the end result of the virtual machine)
<cwillu_at_work> but a tarball is generally more useful for a few reasons
<ogra> --imagesize 2G is important for building
<ogra> has nothing to do with the target SD
<neure> ok
<neure> 5 min to download the image :)
<neure> cwillu_at_work, how about bootargs for the demo image?
<cwillu_at_work> neure, the args I gave you before should work
<cwillu_at_work> root=/dev/mmcblk0p1, etc
<cwillu_at_work> neure, there should be a boot.scr that setup_sdcard.sh makes
<neure> got the image now..
<neure> we'll find out soon
<neure> running setup script...
<neure> how much diskspace is in use by the prebuilt demo image?
<neure> it's taking a quite a long time to populate rootfs...
<cwillu_at_work> neure, not sure;  less than 2gb
<neure> df is reporting 474404 as Used currently
<cwillu_at_work> df -h is nice
<neure> hmm
<neure> the script finished now
<neure> now booting
<neure> [   24.510650] Kernel panic - not syncing: No init found.  Try passing init= option to kernel.
<neure> so.. the same error, basically
<cwillu_at_work> neure, if you mount that sd card, is there a ./sbin/init?
<neure> yes
<cwillu_at_work> what partitions are there?
<cwillu_at_work> ls /dev/sd*
<cwillu_at_work> and cross reference to whichever you mounted
<neure> /dev/sda  /dev/sda1  /dev/sda2  /dev/sda5  /dev/sdb  /dev/sdb1  /dev/sdb2  /dev/sdc  /dev/sdd  /dev/sde
<neure> /dev/sdb2 on /media/sdcard2 type ext3 (rw)
<neure> /dev/sdb1 on /media/sdcard1 type vfat (rw,flush)
<cwillu_at_work> what was your root= line?
<cwillu_at_work> /dev/mmcblk0p2?
<neure> bootargs=vram=12M omapfb.mode=dvi:800x600-16@60 console=ttyS2,115200n8 rootwait root=/dev/mmcblk0p1
<neure> i see
<neure> let me try p2
<cwillu_at_work> :)
<neure> well
<neure> i got login now
<neure> :)
<cwillu_at_work> \o/
<markos_> hi, I've managed to build ~3k packages (karmic for now) using -mfloat-abi=hard and codesourcery 2010q1 gcc 4.4.1. So far I've had minor problems, but I've hit a wall with mono and java (gcj/openjdk), anyone willing to help/point to the right directions?
<neure> cwillu_at_work, thanks !
<neure> cwillu_at_work,  one more q..
<neure> how do i add x?
<neure> some minimal
<neure> some simple, compact wm if possible
<cwillu_at_work> neure, play around on your vm with a ubuntu-server image or some such;  basically you can apt-get install <foo> to make any install you could possibly want
<neure> this is the minimal demo image
<neure> hmm
<neure> but.. i would like to get some hint about how to proceed getting X :)
<cwillu_at_work> binutils build-essential cups git-corelinux-firmware network-manager openssh-server picocom python-dev python-nose python-pip python-setuptools python-virtualenv samba system-config-printer-udev uboot-envtools uboot-mkimage ubuntu-minimal ubuntu-standard vim winbind wireless-tools xdotool xfwm4 xorg xsplash libcap2-bin
<cwillu_at_work> are the package I throw in
<cwillu_at_work> a lot of them aren't going to be relevant for you though
<cwillu_at_work> you could also do something like "ubuntu-desktop" or "lubuntu-desktop" to get a fairly full desktop (full ubuntu, and a light ubuntu respectively)
<ogra> or ubuntu-netbook :)
<ogra> its specifically tailored for armel
<neure> erm
<neure> my network doesnt seem to work
<neure> how do i check that?
<ogra> ifconfig
<cwillu_at_work> #ubuntu :p
<neure> well
<ogra> or on a lower level: cat /proc/net/dev
<neure> i dont see anything other than lo
<neure> which is bad
<neure> i suppose
<neure> there is no eth
<cwillu_at_work> dhclient eth0 says device not found?
<ogra> in proc ?
<cwillu_at_work> (a device that's down won't show up in ifconfig unless you specifically name it)
<neure> ogra, proc has line for eth0
<ogra> then bring it up
<ogra> and run dhclient for it
<cwillu_at_work> dhclient eth0 will suffice (it'll bring it up automatically)
<neure> ok
<cwillu_at_work> this is typical stuff for a bare operating system
<neure> i had to run "dhclient eth0" before my eth0 started running
<ogra> dpkg-deb: Building Package Â»u-boot-omap4Â« in Â»../u-boot-omap4_L24.6-p1git20100520-0ubuntu1_armel.debÂ«.
<ogra> \o/
<ogra> finally
<neure> cwillu_at_work, eh
<neure> i suppose my clock is not right
<neure> installing some packages i get lots of tar complaining time stamps being in future
<ogra> run ntpdate
<cwillu_at_work> ntpdate-debian :p
<neure> i'll wait for the packages to install first
<neure> i hope things are not broken by running with bad clock?
<cwillu_at_work> neure, i.e., almost nothing you're going through at the moment is specific to ubuntu or beagle
<cwillu_at_work> it's just general "bringing up a unix system"
<neure> i know.. :)
<ogra> if you set up your network properly it will automatically sync the clock on network bringup during boot
<cwillu_at_work> neure, should be fine, although you'll have bogus dates on files, etc
<neure> ogra yes, i want it that way, but i was bitten by the fact that it is not like that by default on the minimal image i started from :)
<ogra> you have to configure /etc/network/interfaces
<ogra> or use network manager
<ogra> that will always autosync the clock on network bringup
<neure> first i want x working :)
<neure> even before that i want openssh-server working
<ogra> sudo ntpdate ntp.ubuntu.com
<ogra> before installinf stuff
<neure> well im already installing stuff
<neure> i hope things will still work
<ogra> they will, its just annoyingly niosy
<ogra> *noisy
<neure> yeah
<neure> update-alternatives: using /usr/bin/smbstatus.samba3 to provide /usr/bin/smbstatus (smbstatus) in auto mode.
<neure> smbd start/running, process 1327
<neure> start: Job failed to start
<neure> whats that?
<ogra> looks like samba
<neure> yeah is it supposed to fail like that?)
<ogra> no idea
<ogra> i never use samba
<neure> how do i allow lame passwords?
<neure> sorry moved to #ubuntu :)
<neure> how do i remove the 'password has expired'?
<neure> ha
<neure> got ssh working :)
<ogra> lool, asac, is there any interest in keeping the uboot-imx package in the archive ?
<ogra> i'm inclined to file a removal bug
<lool> ogra: Does it work?
<ogra> lool, well, very roughly ... its darn slow and a mess merged of two patchsets
<lool> If it works and is not a huge maintenance burden, it might make sense to keep it?
<ogra> effectively it was merged of two non working patch tarballs to make it somewhat work
<neure> now getting ubuntu-netbook
<ogra> today there shoudl be a new codebase in the freescale git that works better but i'm not really after maintaining it and doing a new release
<hrw> re
<ogra> beyond that it doesnt fit into the naming scheme anymore
<ogra> (i use u-boot instead of uboot everywhere since thats what we get from all the upstream branches)
<neure> oh no
<neure> "ubuntu@beagleboard:~$ [ 2773.007507] hub 1-0:1.0: port 2 disabled by hub (EMI?), re-enabling..."
<neure> what is that?
<neure> my ssh connection to shell that was installing ubuntu-netbook was reset :/
<neure> but looks like it is still running
<neure> serial still works
<neure> but looks like my eth0 died :/
<neure> i had no issues with Ã¥ngstrÃ¶m
<neure> usb worked reliably
<neure> :/
<neure> ogra i assume my installation issues were caused by usb issues
<asac> ogra: isnt there a new git snapshot now available with all the fixes?
<ogra> asac, no idea, but their git tree was supposed to have the fixes ... i didnt check
<ogra> and i dont have interest in maintaining it (as in updates to the package)
<ogra> so if nobody takes it over or says he needs it in the distro, i'D rather remove it
<amitk> ogra: I used the imx uboot on my babbage board, it worked upto a point and then the board died. No idea if was caused by uboot. I need to use JTAG to try get it working again.
<zyga> ogra: how can I make my nebook image look nice with 24bpp color on a beagle board?
<hrw> zyga: use other omapfb.mode
<ogra> what hrw said
<hrw> zyga: 1280x800-24@60
<zyga> ogra, hrw: is it possible to change this without rebooting?
<hrw> zyga: fbset --depth 24?
<zyga> m
 * ogra dounbts that works but would be happy to be proven wrong
<zyga> checking
<zyga> mmm
<zyga> it 'worked'
<zyga> interesting image
<zyga> well
<zyga> it's not what I wanted
<zyga> ogra: any hints?
<ogra> define "interesting image"
<ogra> :)
<zyga> ogra: sending at ogra@canonical.com
<zyga> sent
<ogra> wow
<zyga> ogra: resetting to 16 makes it even more wrong
<zyga> the bottom 30% is black
<ogra> what did you set on cmdline ?
<zyga> sudo fbset -depth 24
<zyga> oh
<zyga> on cmdline
<zyga> mm
<ogra> i'm pretty sure dynamic switching wont work with omapfb
<ogra> you likely need to reboot and set it on the kernel cmdline
<zyga> omapfb.mode=dvi:1280x720MR-16@60
<ogra> try 32 ther
<zyga> just did
<ogra> -32@
<zyga> (fbmode
<zyga> nice ;-)
<ogra> better ?
<zyga> ogra: yeah, much more readable, check your email
<zyga> note the blackness in the bottom parts
<zyga> rebooting bb
<ogra> hmm
<zyga> ogra: I set it to
<zyga> 'root=UUID=2e97cacf-bddd-45b7-a81a-c252dd42943f ro quiet splash vram=12M omapfb.mode=dvi:1280x720MR-32@60 fixrtc'
<zyga> checking now
<ogra> you might also want 1280x800
<zyga> GODNESS!
<zyga> it looks awsome
<ogra> i picked 720MR-16 for people that use TV sets
<zyga> much much better than that 16bit crap
<ogra> since usually monitors can to 720 even with a bit streching
<zyga> ogra: why 16? tvs cannot handle true color?
<ogra> zyga, eats more ram though
<ogra> no, just a ram decision
<hrw> on 16:10 lcds 1280x800. on 16:9 - 1280x720
<zyga> ogra: makes you want to look at the screen though ;-)
<zyga> ok
<ogra> though we allocate 12M ...
<ogra> might not really be an issue with that
<ogra> hrw, right, but many TVs cant do 1280x800
<ogra> while monitors usually are able to do 1280x720
<hrw> yep
<ogra> even 16:10 ones
<hrw> my TV anyway is not able to do MR ones
<ogra> though the 16bit are surely debatable
<hrw> 1280x720 works
<zyga> ogra, what does omapfb.debug=y do?
<ogra> spill debug messages to dmesg afaik
<mpoirier> ogra: do I remember you telling me you have a panda board ?
<ogra_> mpoirier, still waiting for it
<mpoirier_> Ok - I got mine yesterday.
<ogra_> cool
<ogra_> dont boot it yet
<mpoirier_> oops.
<mpoirier_> why ?
<ogra_> we need a special kernel patch to work around an issue that will fry the HW
<mpoirier_> ok.
<ogra_> at least i was told so
<ogra_> did you boot it with our kernel ?
<mpoirier_> No.
<ogra_> i guess if there is something shipped with it that should be fine
<mpoirier_> there is nothing apparent that came with it.
<mpoirier_> no SD card.
<mpoirier_> I'm just trying to see u-boot on the console.
<ogra_> i just uploaded x-loader-omap4 and u-boot-omap4
<mpoirier_> I should probably do the same - where from ?
<ogra_> https://edge.launchpad.net/ubuntu/maverick/+source/x-loader-omap4/L24.6-p1git20100520-0ubuntu2 and https://edge.launchpad.net/ubuntu/maverick/+source/u-boot-omap4/L24.6-p1git20100520-0ubuntu1
<ogra_> not published yet you will have to wait a bit
<mpoirier_> what do you mean by not published yet ?
<ogra_> the binary packages arent published yet
<mpoirier_> ha.
<ogra_> the source just finished building
<mpoirier_> I have to build them myself then.
<ogra_> or just wait a bit
<mpoirier_> very well, I can do that.
<ogra_> the debs should show up within the next hour
<mpoirier_> you're still getting patches from TI ?
<ogra_> for the bootloaders ? nope
<ogra_> they should be fine now
<ogra_> at least they are on blaze
<ogra_> i'D love to know if MLO and u-boot.bin from these packages work on panda
<mpoirier_> Well, that was my next question - I bet they won't.
<mpoirier_> too HW specific at that point.
<ogra_> shouldnt be
<ogra_> but we'll see
<ogra_> x-loader might, u-boot definately shouldnt
<mpoirier_> definitely shouldn't work or shouldn't have problems ?
<ogra_> shouldnt have probs
<mpoirier_> humm...
<ogra_> MLO (x-loader) might since the wiring of the boards is different
<mpoirier_> yes, exactly.
<mpoirier_> mapping layout, ports...
<ogra_> but after x-loader u-boot should just work
<mpoirier_> depending on how they did their things...
<ogra_> well, its all omap4
<ogra_> my blaze currently boots with that u-boot
<ogra_> so other omap4 should too
<mpoirier_> if uboot is doing some board specific hw initialization we could see problems.
<ogra_> if not we need to get that fixed by TI
<mpoirier_> yes.
<mpoirier_> I'm skeptic here 'cause I never used an xloader.
<ogra_> well, the omap4 u-boot is supposed to work across all omap4 boards we currently have
<mpoirier_> Always did all board specific init in u-boot.
<ogra_> x-loader inits the HW before loading u-boot
<ogra_> so the differences should be covered in x-loader
<mpoirier_> in that case yes.
<mpoirier_> Otherwize TI needs to fix.
<ogra_> right
<armin76> ogra_: you working with TI now?
<mpoirier_> as in talking to them ?
<mpoirier_> no.
<ogra_> well, try out the binaries once the packages show up (or build the packages yourself if you cant wait)
<mpoirier_> ya... I'll have to get another SD card.
<mpoirier_> Don't want to mix OMAP4 and OMAP4.
<mpoirier_> by the way...
<ogra_> 3 and 4 you mean :)
<mpoirier_> yes - brain bug.
<mpoirier_> by the way.
<mpoirier_> is omap4 code compatible with omap3
<mpoirier_> >
<mpoirier_> ?
<mpoirier_> binary i mean.
<ogra_> usespace wise ? yes
<ogra_> *user
<mpoirier_> I'm talking about machine instructions.
<ogra_> its definately backwards compatible
<mpoirier_> yes, that is what I imagined.
<mpoirier_> Then we'll have to see about my board.
<mpoirier_> before talking to you I simply used the SD in my beableboad in the panda...
<mpoirier_> I don't see anything on hte console but that might just be my serial connection.
<mpoirier_> We'll see...
<ogra_> the userspace binaries work
<ogra_> TI is using lucid on their boards already
<mpoirier_> yes, they should - I'm more worried about the kernel thing you told me about.
<mpoirier_> my beagleboard kernel might have booted.
<mpoirier_> it would be very surprizing but still possible.
<ogra_> no
<ogra_> its not omap4
<mpoirier_> I just hope not - if the binaries are code compatible the processor will have fetched instructions.
<mpoirier_> most likely not gone very far.
<ogra_> it wont boot an omap3 kernel (it cant)
<ogra_> and your MLO wont init the board anyway
<mpoirier_> good.
<mpoirier_> on another topic...
<mpoirier_> have you built maverick for ARM recently ?
<mpoirier_> kernel that is.
<ogra_> not yet
<ogra_> i'm actually waiting for the kernel team on that
<mpoirier_> Yes, Bryan is working on it.
<ogra_> <- uses binaries ...
<mpoirier_> I'll join him shortly.
<ogra_> i very very rarely build kernels :)
<mpoirier_> ok all good - no more questions.
<mpoirier_> thanks.
<ogra_> though since i have a touchbook i actually do that again :)
<ogra_> since it has non upstreamed patches it needs to work
<armin76> hrm...
<armin76> ndec: i want a blaze :D
<ogra> http://paste.ubuntu.com/442850/
<ogra> WOHOOO !!!!
<dmart> lool: with regard to bug 489242, where can I find the patches you mention?
<ubot2> Launchpad bug 489242 in libmad (Ubuntu) "Inline assembler fix needed for libmad in Lucid on armel (affects: 1) (heat: 1)" [Undecided,New] https://launchpad.net/bugs/489242
<dmart> I don't see a distinct libmad for maverick yet
<ndec> armin76: no problem. give me you mail addres ;-)
<ogra> lol
<armin76> ndec: yey, armin76@gentoo.org :)
<ndec> armin76: you should send me a check first .. ;-)
<armin76> ndec: ogra pays
<ogra> and its hard to attach blazes to mails :)
<ndec> ogra: that's why I said mail address and not email address ;-)
<ogra> yeah
<armin76> oh, sorry, i'm used to it, i'll email it to you if you give me your email :D
<hrw> ;D
<hrw> ok, time for me
<ogra> armin76, checks are also hard to attach to emails ;)
<armin76> ogra: dunno, thats your choice *g*
<ogra> mine ?
<armin76> yup, you pay
<cwillu_at_work> mmm, avahi isn't in ubuntu-standard anymore
<ogra> jayabharath, pingaling
<dmart> lool: ping
<ogra> http://paste.ubuntu.com/442866/
<ogra> NCommand1r, ^^^
<ogra> feel free to play with it
<ogra> (for image building)
<NCommand1r> ogra: oooh, win, although I don't have my OMAP4 with me at the moment :-/
<lool> dmart: pong
<lool> dmart: The patches are in the libmad source package
<dmart> lool: are you comparing against the current Debian package?
<lool> dmart: the libmad version is the same in lucid and maverick
<dmart> ok
<lool> dmart: I'm just looking at the patches in the Ubuntu package
<lool> dmart: Comparing the patch in the open bug and the patches in the source package
<lool> dmart: There was a complaint that libmad produces garbled output with Ubuntu's binaries
<dmart> yeah, I saw that one
<dmart> Which patches are you comparing?
<lool> dmart: Which is why I looked at the patches on the ARM bugzilla and in Launchpad, I wanted to send them upstream too, but I got confused by the three different patches and wanted someone who worked on them to sort it out
<dmart> debian/patches/* versus http://linux.onarm.com/bugzilla/attachment.cgi?id=11 ?
<lool> Yes something like that, or actually I think the one you attached to the Launchpad bug and the ones in the Ubuntu package
<dmart> I can't see any patch attached to launchpad
<dmart> ...but it looks like the one on Bugzilla may be different, is that what you mean?
<lool> dmart: Yes
<lool> dmart: You probably just linked to the bugzilla patch in Launchpad or so
<dmart> I think that's probably it.
<lool> dmart: So there were slight differences in the ifdefs and implementation of the arm assembly
<dmart> I'll have to take a look at that and get back to you.
<lool> dmart: Thanks
<armin76> dmart: did you guys saw that gcc fails to build with --enable-checking?
<dmart> armin76: Can you check with doko?
<armin76> will do when he's around
<dmart> I havent tried/observed this myself.  Is this Ubuntu gcc or trunk?
<dmart> lool: It looks like Kevin Welton's patch on linux.onarm.com is an implementation of the same thing.
<dmart>  * it's a bit neater than mine for MAD_F_MLN
<dmart>  * he's added some Thumb compatibility in imdct_l_arm.S, but it's an out-of-line assembler file and so will still be built for ARM by default
<dmart>   * (we could change that if desired)
<dmart>  * he lacks the add pc -> adr change in imdct_l_arm.S, which would probably cause problems if the code was really being built for thumb
<dmart> I guess I'll need to merge the patches together and make sure the merged patch hits linux.onarm.com as well as Ubuntu
<cwillu_at_work> is there a more correct way to generate the xauth file for a user than to xauth extract - $DISPLAY | xauth -f ~user/.Xauthority merge -; chown user ~user/.Xauthority?
<cwillu_at_work> ... in xsession.d
<lool> davidm: There are small differences like ifdef thumb versus ifdef thumb2
<lool> err sorry davidm
<lool> ah dmart left
<davidm> lool, NP
 * armin76 waits for ndec's mail :D
<DanaG> http://www.engadget.com/2010/05/31/sharp-netwalker-pc-t1-unboxed-now-available/#commentshttp://www.engadget.com/2010/05/31/sharp-netwalker-pc-t1-unboxed-now-available/#comment
<DanaG> er
<DanaG> stupid finch... screen didn't update, so I pasted twice.
<NCommander> an Ubuntu tablet?
 * NCommander has doubts about that being a great user experience since nothing is touch optimized expect the UNE launcher
<DanaG> Interesting... some people from TI are on campus here right now.
<DanaG> Some sort of meeting going on.
<zyga> ogra: booting with 32bit color makes the console blue
<ogra_cmpc> heh
<gbillings> does anybody know how to compile + install elf-arm-gcc in lucid lynx?
#ubuntu-arm 2010-06-02
<DanaG> [ 3840.406250] INFO: task apt-check:7226 blocked for more than 120 seconds.
<DanaG> [ 3840.419738] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
<DanaG> How do you suppress login scripts?
<DanaG> The stupid thing is hanging at login... and then timing out at 60 seconds.
<DanaG> I enter my username, and it waits like 50 seconds before showing me the password prompt
<DanaG> What is this stupid apt-check, anyway?  When I log in, I want to log in... not have it block forever on some update check.
<DanaG> argh, had to reboot the thing.
<DanaG> argh.
<DanaG> hmm, I do still get that OOM on ureadahead.
<DanaG> Maybe it's because I haverc.local start pulseaudio and deluged.
<DanaG> no, wait, /var/lib/ureadahead/pack doesn't exist.
<DanaG> hmm, it also oom kills mount.ntfs.
<DanaG> I guess I have too much stuff running.
<DanaG> hmm, now I'm pondering which would be more useful: one of the beagle XM boards, or one of those not-available-yet Marvell thingies?
<DanaG> And will Marvell's stuff do compiz?  that's my definition of useful 3D. =Ã¾
<DanaG> https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/466886
<ubot2> Launchpad bug 466886 in network-manager (Ubuntu) ""No network connection" when IPv6 is enabled in Network Manager (affects: 12) (heat: 60)" [Undecided,New]
<DanaG> er, not arm-specific.
<DanaG> hmm, is rcn-ee around?
<neure> hi
<neure> after installing ubuntu-netbook.. in keyboard doesnt work
<neure> nor mouse
<neure> i can go to text console
<neure> wait
<neure> keyboard works
<neure> mouse doesnt
<neure> weird
<neure> i had to switch it to other usb port on the hub
<neure> now it works
<neure> erm
<neure> cpufreq-info says there is no driver :(
<wv> Hello, I have ubuntu 10.04 installed on a IMX51
<wv>  but want gnome to use a resolution of 1536x384
<wv> for some reason it always jumps back to 1536x768
<wv> Somebody knows how I can change this?
<neure> i dont even know what imx51 is but on beagleboard that i have the resolution is set in the bootloader bootargs
<wv> freescale's cortex based processor
<neure> ok
<neure> does it have some sort of boot loader?
<wv> yes, redboot
<neure> ok, i dont  know that one either
<neure> but it is likely that you may need to provide resolution at boot time
<wv> well, case is, I can change the resolution at runtime
<wv> via fbset
<wv> so my output resolution is already 1536x384
<neure> but..?
<wv> but the resolution gdm is using, is 1536x768
<wv> so on my screen, I see only the upper part of my desktop environment
<neure> i see
<neure> no idea
<wv> damn
<hrw> morning
<neure> hrw, know about cpufreq-utils?
<neure> they worked on Ã¥ngstrÃ¶m but complain about missing driver on ubuntu
<amitk> neure: cpufrequtils is not needed, we use ondemand governor by default and it is compiled in
<amitk> cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
<neure> amitk, is there way to control to cpu frequency?
<amitk> neure: switch the governor to a different one if you like
<neure> amitk, cpu0 has on crash_notes
<neure> only
<neure> nothing else
<neure> this is rcn_ee:s image
<neure> maybe that could be missing some stuff
<neure> ?
<amitk> then _please_ ask him
<neure> =)
<neure> this was the only thing i was able to get running :/
<neure> official doesnt support otg yet ehci is broken so what can i do
<amitk> understood
<neure> but yes, i will hang around here and wait
<amitk> have you filed any bugs regarding ehci breakage?
<neure> what should i report? "it is known that certain hardware is broken and ehci wont work"
<amitk> you're using an older board?
<neure> should i request that installer gives you a dialog "sorry, your hardware is known to be faulty, please wait until we support otg"
<neure> C2
<neure> not very old but ppl keep telling me it has usb issues
<amitk> *shrug* can't help you then until OTG is fixed
<neure> right
<amitk> yes, it does
<neure> what is the current status with otg?
<neure> considering it is working in Ã¥ngstrÃ¶m and rcn-ee version, it should not be tough to get it to official
<hrw> gcc-4.5 takes 3.5h on my x86-64...
<neure> hrw, doing what?
<neure> to build it?
<neure> amitk, do you think it would be worth reporting a bug that installer should warn about known-to-be-broken hardware configurations?
<amitk> neure: it can't hurt, talk to ogra (god of installers)
<neure> ogra ping :)
<markos_> could anyone help with this? (mono build on armel -mfloat-abi=hard), build phase succeeds, binary-arch fails:  http://paste.debian.net/75788/
<markos_> package version mono-2.4.4~svn151842
<markos_> same result with karmic version
<hrw> neure: build package
<neure> right :)
<zyga> ogra: hi, did you get my message yesterday, the one about console colormap being broken on BB with 32bit fb
<ogra> zyga, yes, i guess thats worth a bug
 * ogra reads backlog
<zyga> ogra, against linux package in lucid?
<ogra> in lucid its linux-ti-omap iirc
<ogra> in maverick its linux
 * zyga wonders which release 'that' thing is based on (rolls eyes)
<zyga> k, I think it's lucid
<ogra> zyga, ask amitk i think its .33 with backports from .34
<ogra> so its possible that the issues still show up in maverick (since the DSS patch might be the same)
<amitk> zyga: in lucid, it is a 2.6.33 kernel
<zyga> k
<markos_> guys, also, are there any thoughts of providing native version of rootstock (ie one that doesnt' require an x86 box +qemu) to build the image?
<zyga> I'll finish this install, take a photo and file a bug
<ogra> neure, well, for lucid i wont change the installer and i'd rather fix the issues than popping up warnings :)
<XorA|gone> markos_: isnt that called debootstrap :-)
<ogra> markos_, look up debootstrap on the wiki :)
<ogra> and read about chroot
<markos_> or would you accept a patch?
 * ogra always accepts patches if they dont break existing functionallity and are sanely coded ;)
<ogra> amitk, do you know if the maverick kernel is supposed to support XM ?
<markos_> uhm, that's not only what rootstock does, it also sets up various system stuff
<markos_> ogra: at least that's the impression I get by reading its code ( I know about debootstrap, was a DD for 9 years :P)
<ogra> markos_, indeed it does, though thats not really much ... loopback networking, fstab, system groups, default user, sudo from the top of my head
<amitk> ogra: not yet, I haven't gotten around to looking at that yet (doing specs and all)
<markos_> yeah, my idea was to prepare a native rootstock script (rootstock-native?) that works on just debootstrap + the extra stuff and send it over
<ogra> amitk, k, x-loader and u-boot fully support it now (the omap3 packages i uploaded yesterday)
<ogra> markos_, feel free, i'll happily add it
<markos_> ogra: basically, i've rebuilt basic ubuntu-desktop karmic, using hardfp -instead of softfp- float-abi and would like to provide a couple of images as proof of concept -to see if the performance difference is worth the effort -imho it is, but i'd like to have numbers to base this
<ogra> markos_, though to avoud code duplication it would be clever to make rootstock use that script in the VM, i.e. just split out the installer part
<markos_> ogra: good idea
<zyga> ogra: I sent you an image that shows the colors and something I'm not familiar with - it looks like a kernel oops (it has a backtrace) but it's not an oops ;-)
<zyga> ogra, should I file a bug against that as well?
<ogra> yes
<ogra> and if you have a spare SD it would be cool to compare against maverick
<ogra> (upgraded lucid, we dont have installer images yet)
<markos_> ogra: in fact these days i'll set up a tiny arm-based compile-farm (8-9 nodes) to support this initiative, these will be Genesi EfikaMX boards (iMX515 based)
<ogra> nice !
<lool> markos_: wow you rebuilt ubuntu-desktop using hardfp?
<lool> markos_: So you used gcc 4.5?
<markos_> ~3k packages so far
<lool> markos_: So you bootstrapped stuff by hand to build in the correct order?
<markos_> no, codesourcery 2010q1-202 (gcc 4.4.1 +patches)
<lool> or are you rebuilding multiple times
<markos_> es
<markos_> yes
<markos_> I bootstrapped some stuff initially
<markos_> then I rebuild pretty much everything -incl the basic stuff like gcc, eglibc, etc
<lool> markos_: Do you have notes from your setup, and from the issues you faced?
<neure> ogra, would it then be fix to refuse to use known-to-be-broken hardware?
<markos_> it sure took a LOOONG time
<ogra> neure, no, the fix would be to fix the breakage :) maverick is still young
<markos_> lool: well, the biggest problem were the cyclic dependencies in the packages themselves
<lool> markos_: https://blueprints.launchpad.net/ubuntu/+spec/arm-m-automated-bootstrap
<markos_> lool: I stopped taking notes when the dependency cycle included too many packages :D
<lool> markos_: I'm interested in even partial notes if you don't mind sharing them
<markos_> lool: I still remember most of it
<markos_> right now I'm stuck in gcj and mono
<ogra> zyga, hmm, that page allocation failure looks like livecd related, i think plars saw something similar already but it didnt do any harm to the actual install process
<zyga> ogra: ok, I'll file a bug about that anyway
<ogra> not sure he filed a bug about it though
<ogra> yeah
<markos_> lool: unfortunately, it's a long way from becoming trully automated
<lool> markos_: Yes, I think we need to start somewhere
<lool> markos_: I'd like to provide a prototype resolving a particular cycle or a small set of cycles, and then proposing the concept to Debian/Ubuntu at large
<markos_> lool: mind you, I started from a hardfp gentoo basic image
<lool> aha
<lool> markos_: So how did you keep the Debian and Gentoo bits isolated?
<markos_> separate chroots
<markos_> right now the basic system runs on softfp, and I had 2 chroots one gentoo-hardfp, and another with karmic
<markos_> I built a couple of vital packages inside gentoo, like eglibc, bash, gcc, etc
<lool> markos_: Please correct me: your process was something like: create a gentoo hardfp chroot, build build-essential packages by hand in it using CS compiler, setup a buildd using a compiler wrapper which calls into codesourcery instead of build-essential, build everything you can and resolve loops by hand
<markos_> and dpkg -i --root=<karmic-hardfp-root> the packages
<markos_> after a while, I could chroot in the karmic-hardfp dir and start building packages there
<markos_> lool: actually I packaged codesourcery compiler using ubuntu's package and modifying it a bit, so right now I have gcc-4.4 codesourcery replacement packages
<markos_> but yes, the loops were resolved by hand
<lool> That's really cool because that's exactly how we envisioned people doing rebuilds to do it
<lool> (replacing the gcc sources contents)
<markos_> lool: I saved you the job :)
<lool> well I'd rather say you proved our imagination right   ;-)
<markos_> the only remaining thing right now is to provide the images somewhere
<lool> markos_: So who do you do that for, will you share the resulting packages publicly?  :-)
<markos_> Genesi
<markos_> of course
<lool> You work for Genesi?
<markos_> yes, doing that and NEON stuff as well
<lool> markos_: Tell me about the NEON stuff!  :-)
<lool> markos_: I'm also curious on whether you had the chance to compare speed of hardfp versus softfp
<markos_> lool: well, I only started doing that, some proof of concept NEON work went into the Eigen math library (it was easier for me as I had already done the altivec port some years ago)
<lool> Too bad you actually had to use a Gentoo chroot too, the plan on our side was to cross-compile build-essential, but it's not easy because you have to bootstrap them
<markos_> lool: now, I'm working on the neon libfreevec port and some 2D driver optimizations for the imx515 X driver
<DanaG> Stupid Adobe:
<DanaG>  openscreenproject.org tells me to download Flash plugin....
<markos_> lool: yes, I didn't want that either, but I had no choice really
<DanaG> on ARM.
<lool> markos_: it certainly saved your time
<DanaG> I wish somebody would make an ARM with an open GPU.
<DanaG> Or at least, one with a GLX driver with texture_from_pixmap.
<lool> markos_: Did you have to patch any sources for hardfp?
<DanaG> Even nvidia is leagues above powervr in that rate.  Though, I'm not sure how Tegra is.
<hrw> DanaG: ha! you did not told about gl in first line ;d
<lool> markos_: We'd love helping you to merge the patches into Ubuntu proper
<markos_> lool: actually I tried bootstraping it myself, but it was taking me too much time, and then someone (ssvb) published the gentoo tarball
<markos_> lool: very few
<markos_> i have them all here
<lool> markos_: isn't it a problem that it uses the same gnu triplet?
<markos_> well, apart from gcc which was a totally different package
<markos_> well
<markos_> they're totally incompatible
<lool> markos_: It would be lovely if you could upload them somewhere, or open bugs or whatever
<markos_> softfp/hardfp I mean
<markos_> or rather
<markos_> the binaries run
<lool> markos_: I can host them if you don't have a web hosting location ready
<markos_> but produce TOTALLY wrong results
<lool> well you seem to have a debian account so you probably have a place already
<markos_> I did, I 'm not a DD anymore
<markos_> since 2008 :(
<lool> Yeah, it says account locked
<markos_> but space is no problem, net connection might be
<wv> hello, I get a FBDEV(0): mode "1536x384_60" not found
<lool> markos_: There is a lighter process to get an account reenabled BTW
<zyga> ogra: https://bugs.edge.launchpad.net/ubuntu/+source/linux-ti-omap/+bug/588638
<ubot2> Launchpad bug 588638 in linux-ti-omap (Ubuntu) "console colormap is wrong when using 32bit framebuffer (affects: 1)" [Undecided,New]
<wv> although it's added to /etc/fb.modes
<zumbi> lool: markos_ is coming to dc10 :)
<wv> first thing it states before is: "checking modes against framebuffer device"
<lool> markos_: I find it a bit scary that the binaries will be run
<markos_> zumbi: that's not certain yet :)
<zumbi> markos_: did not you registered?
<lool> markos_: Anyway, I think we need a new debian architecture name for such a port
<markos_> lool: yes, this is why it must be a separate tree
<lool> ack
<ogra> zyga, we used to subscribe ubuntu-armel and tag arm bugs with the armel tag in the past ....
<markos_> zumbi: will do, I want to discuss with Genesi first
<zumbi> lool: armfp?
<markos_> zumbi: armelfp probably
<lool> zumbi: I was thinking armhf rather
<ogra> lool, do you know if there is a new practise ? ^^^
<zyga> ogra, and now? should I do the same?
<ogra> else i would like us to go on with that behavior
<lool> markos_: "arm" was little endian as well, it would be shorter
<ogra> zyga, i dont know if the policies changed with the new team
<markos_> lool: I think it's worth the effort basically
<ogra> zyga, thats why i asked lool  :)
<zumbi> markos_: if you really want to attend dc10 is important you register soon as reconfirmation period has started and it is over by june 10th
<markos_> anyway, I have a DSL 24/1 here, it can work to get the stuff fast to a server
<ogra> zyga, essentially its makes searching for arm bugs easier
<lool> ogra: we didn't change policies, but I dont think everybody is aware of these best practices
<ogra> lool, ok, we should spread them then
<markos_> zumbi: I have 8 days left then :D
<lool> ogra: it's something the mobile team did, but wasn't really communicated at large
<ogra> lool, right
<lool> markos_: I ceratinly agree it's worth the effort
<zyga> lool, ogra, so adding tags and subscribing teams is best practice currently, correct?
<zumbi> markos_: but I need to provide you with accomodation which you are already late (since April 15th)
<lool> markos_: So do you think we should actually use a different GNU triplet?
<ogra> if we didnt change them we should communicate it, if your team changed it the mobile team should know :)
<ogra> zyga, yes
<lool> currently I think it's still arm-linux-gnueabi for hard-float
<ogra> zyga, ubuntu-armel and the armel tag
<zyga> thanks
<lool> zumbi: yes, tag it armel and sub ~ubuntu-armel
<markos_> lool: indeed, well, i'm not sure about that
<hrw> lool: but armelhf shows cleanly that this is armel based just in case someone will wonder is it eabi still
<ogra> zyga, only subscribe ubuntu-areml (dont assign)
<lool> zumbi: Tag it armel if it's specific to armel, subscribe the team if that sounds like an interesting bug for the armel porters
<zyga> right
<markos_> it's not exactly a subarch either, i'm not sure how to categorize it
<lool> markos_: The same *spec* covers the two subcases, but the *abi* is actually different, so I think we should get that fixed to use a different triplet, but I suspect it's a rather painful process for everybody
 * lool notes to bring that up with CS
<lool> hrw: armeb doesn't tell you anything about EABI though
<markos_> it is rather painful yeah :)
<lool> markos_: So your goal is to build all of Ubuntu main + universe, or just main or...?
<lool> markos_: How do you define your project as successful?
<hrw> lool: armeb for me is "arm BE" so for debian based it mean oabi to me
<markos_> lool: well, for now, main will suffice, soon -the extra nodes will arrive these days, so I'll have the cpu power to maintain this at least now
<lool> hrw: You can have BE and EABI
<lool> hrw: in fact, "If a bigendian arm EABI port will be created, it will be called "armeb", and it will replace the previous oldabi-based "armeb" port effort. "
<hrw> lool: I know
<markos_> lool: as for success, well I expect quite a measurable performance improvement esp in 3D or fp-intensive apps
<hrw> good to know
<markos_> lool: hardfp supposedly saves 20 cycles per function call, so esp in 3d or any other app that calls too many small functions with fp arguments, it *should* make a difference
<lool> markos_: in fact it's 20 cycles per load / store of a single vfp register IIRC
<lool> So it could be much more
<markos_> hm, yes, you're right :)
<lool> (or perhaps it's all vfp registers, in which case I'm confused)
<markos_> lool: right now the only setback to providing the images, is mono -and to a lesser extent java. gnome-applets (part of ubuntu-desktop) depends eventually from mono which breaks here
<markos_> apart from that, I could provide ubuntu-minimal and ubuntu-standard right now even
<markos_> but I don't have an ubuntu x86 box (yet) :)
<lool> markos_: mono doesn't build with hard-float, or it's broken at runtime?
<markos_> but, I could make my local mirror public and one of you could run rootstock :)
<markos_> the build breaks, in particular, binary-arch phase: http://paste.debian.net/75788/
<lool> markos_: That would be interesting; I'm mostly interested in benchmarks on the same hardware + source package version between softfp and hardfp; I'd like to prioritize this new port over our other devs
<lool> make[2]: *** [build/deps/basic-profile-check.exe] Error 1
<lool> I dont see that error
<lool> markos_: And we could start integrating the patches ASAP too
<markos_> lool: they're not that many
<lool> markos_: Still!  :-0
<markos_> lool: the most important change is the compiler
<markos_> it would either have to be gcc-4.5 -which I haven't tested- or codesourcery
<lool> Ack
<markos_> the current 4.4 in ubuntu doesnt' support hardfp, at least it didn't a couple of months ago
<markos_> dunno if it changed
<lool> markos_: We plan integrating the CS patches at least on ARM on top of 4.4 https://blueprints.launchpad.net/ubuntu/+spec/arm-m-tool-chain-selection
<markos_> i did it the other way
<lool> markos_: the other way?
<markos_> took the cs source and used a few ubuntu patches on top -incl. graphite- you might find it nice that Eigen showed an extra 0.03 GFLOPS performance 0.89 -> 0.92
<neure> what would be nice code editor that runs fine on beagleboard?
<neure> for X..
<markos_> lool: btw, the difference in a8 vfp vs NEON is huge, this is from a basic Eigen benchmark:
<markos_> $ ./bench_gemm.gcc4.4.1cs
<markos_> eigen cpu 3.84s 0.0699051 GFLOPS (19.27s)
<markos_> eigen real 3.8469s 0.0697796 GFLOPS (19.2648s)
<lool> markos_: but that requires custom NEON code in eigen?
<zyga> neure, vim
<lool> it's not like we can just turn on a toolchain flag which will use NEON, well only partially
<neure> sorry im allergic to editors with unix roots :D
<markos_> $ ./bench_gemm.gcc4.4.1cs+genesi.neon
<markos_> eigen cpu         2.35s         0.913823 GFLOPS         (11.82s)
<markos_> eigen real        2.35064s      0.913574 GFLOPS         (11.8205s)
<neure> scite should be fine..
<markos_> lool: yes, that was my first NEON project :)
<neure> does gcc directly support neon?
<neure> or does it need some manual coding?
<hrw> neure: vim was written under AmigaOS :D
<markos_> well... it does do some basic fpu stuff using neon
<markos_> but to get top performance and vectorization, you have to do special coding
<markos_> A9 has a much better fpu, it's almost as fast as neon
 * markos_ has remote access to a prototype quad-core A9 :)
<hrw> markos_: i.mx61/63?
<hrw> I do not remember which of those is dual and which quad
 * gsnedders wonders if we have any A9 hardware hereâ¦
<wv> Question, I have a Freescale IMX51 board (arm cortex A8) with custom ubuntu. The framebuffer always starts in 1024x768, but I want it to be 1536x384. Where can I change this?
<neure> hrw, really?
<hrw> neure: yes. first it was Vi IMitation
<hrw> neure: "Vim is a text editor released by Bram Moolenaar in 1991 for the Amiga computer. "
<neure> "The original vi program was written by Bill Joy in 1976 for an early BSD Unix release"
<tmzt> markos_: if you're worried about fpu (I read mmu earlier) why not just use neon?
<neure> granted i have no idea how much vim shares with vi
<hrw> neure: yes, vi is old timer
<markos_> hrw: i think it's a samsung
<neure> i was born 1976 :)
<tmzt> wv: you might have to do that in the kernel source
<hrw> neure: so did I
<markos_> tmzt: I am, when I can at least
<XorA> sorry
<zyga> wv, I think you can do that in the boot loader, just change the kernel command line
<XorA> doh wrong window, so lucky that wasnt another random statement :-)
<wv> bootloader is redboot, and I don't see any resolution specified in the kernel command line
<hrw> wv: run 'fconfig' command
<hrw> ah.. no entry...
<wv> exec -c "noinitrd console=ttymxc0,115200 console=tty1 root=/dev/mmcblk0p1 rw rootwait wvga"
<markos_> hrw: ARMv7 Processor [410fc091] revision 1 (ARMv7), cr=10c53c7f
<amitk> wv: AFAIK, the display driver has EDID detection on the imx51
<wv> Possibly, but I don't want to use EDID detection
<wv> screen is an own made custom fpga screensplitter
<hrw> wv: tried "fbset --xres 1536 --yres 384"?
<wv> hrw, well, that works after boot, I can output this resolution via fbset
<wv> not via this command, but with timings and stuff
<wv> but I want it to be correct directly at boottime
<amitk> wv: then I guess you'll have to look deeper into the driver for it's default settings
<wv> cause second problem is that the x-server gets started at 1536x768 in stead of 384
<wv> so I only see the upper half of the screen...
<zumbi> win 23
<zumbi> err
<lool> lose 77
<wv> So it's not like I can put a default startup resolution somewhere without modifying some sourcE?
<hrw> dpends on x.org driver
<amitk> wv: again, look at the modinfo for the driver to see if it takes some parameters (I don't have my babbage board handy atm)
<neure> /usr/bin/ld: cannot find -lEGL
<neure> where do i get pvr oes and egl stuff?
<wv> amitk, can you give me the specific command? I tried modinfo fbdev, but get a ERROR: modinfo: could not open.......;
<amitk> wv: I guess the display driver is not even a module, it is compiled in. And from a quick look it doesn't seem to take any parameters
<amitk> wv: so you'd have to hack the driver
<zumbi> lool: nobody loses :) (I was changing windows :-P)
<zumbi> lool: btw, would you know some TI or freescale people wanting to pay money to sponsor debconf food?
 * zumbi is fundraising
<hrw> zumbi: alt-d is not working as /window 23?
<zumbi> hrw: not here alt-d=Ã¤
<zumbi> when fundraising, I get more hardware than money for food -- would you like some? :)
<hrw> zumbi: ah.. I use RAlt for national chars
 * XorA uses ralt for compose
<lool> zumbi: It's a bit of a stretch for me to share Canonical customer contact details in the interest of letting you contact them to raise money
<lool> zumbi: But I can see various ways in which this could work: a) contacting them during Debconf itself (the ones who come) to sponsor the next debconf b) prepare some information for ARM silicon manufacturers on why debian is great for ARM development and why sponsoring debconf is critical c) let networking happen (I might mention the debconf sponsoring option to the ones I know well, but that's my own personal decision as a DD :-)
<lool> zumbi: The other option is that you eat some hardware instead
<hrw> ;D
<zumbi> tasty :-)
<zumbi> thanks :)
<hrw> or grab hw to debconf and sell^Wexchange it for food
<XorA> sponsored "Will it Digest"
<lool> hrw: Reselling hardware which you were offered for development might not be a terribly good move to keep your hardware sponsors happy though
<zumbi> lool: as DD if you want to fundraise a little more for food, you can access open budget at http://wiki.debconf.org/wiki/DebConf10/Budget
<zumbi> lool: that can be a great idea (hardware reselling booth)
<lool> zumbi: Ok, it's good to know the budget bits are there, what might help sponsors make their move is a targetted marketing of why debconf is great for their company/products/communities
<lool> zumbi: if you do have a reselling agreement with your partner, that would be good, but otherwise it's quite an ugly business to resell gifts IMHO
<lool> I wouldn't be tempted to make further gifts in the future if I saw them being exchanged for money or food
<lool> Housing + Food shows how an expensive city like NY hits the debconf budget badly    :-/
<zumbi> lool: yes, i already wrote a letter (http://whiteboard.debian.net/sponsors.wb) and thanks for suggestions, I should agree reselling before hand. Exchange hardware for food. :-)
<zumbi> lool: btw, will you be there?
<lool> zumbi: the list of benefits is not geared towards ARM at all
<lool> zumbi: Yes, I'm coming
<lool> zumbi: Do you have a list of current sponsors as to not bug the same companies multiple times?
<zumbi> lool: yes, but it is kept private
<lool> zumbi: Could you mail it to me?
<zumbi> lool: i think so
<zumbi> one sec
<lool> I wouldn't share it obviously
<zyga> plars, gomockingbird.com
<lool> zyga: Amazing
<zyga> lool, just found it on planet.gnome
<zyga> I'm redoing my mockups in that, pen and paper sucks
<zyga> (and another objective-c -> javascript recompiler app, cool)
<zyga> I'm doing ubuntu one sync on my BB
<markos_> zumbi: eating hardware... gives a new meaning to "Intel Inside" stickers, lol :)
<hrw> markos_: ;DD
<zumbi> markos_: well, not Intel, but ARM
<zumbi> "Eat the ARM" could be a posible marketing sponsor :)
<zumbi> sponsor or phrase or ... i dunno the best word here
<tmzt> wv: did you get it through the bootloader?
<tmzt> it's possible the bootloader just configures video for itself, not the kernel
<tmzt> you probably have to patch the board file or devicetree (if it's used)
<tmzt> I don't know this hardware though so I can't be sure
<markos_> "this guy ate his ARM", won't sound very nice though...
<neure> guys
<neure> is there some lighter X environment than ubuntu-netbook?
<neure> it seems to be pretty sluggish
<ogra> do you have swap ?
<ogra> its not that sluggish on a C4 with 512M of swap here
<ogra> but indeed there are other desktop envs, try lubuntu-desktop or a plain xfce (not xubuntu-desktop, thats nearly as heavy as ubuntu)
<neure> how do i see if i have swap?)
<ogra> free
<neure> no swap!
<ogra> htop is also helpful to see the real ram usage
<neure> damn
<ogra> (not installed by default)
<neure> i have 16 GB sdcard, use% 16..
<neure> can i add now somehow?
<neure> i can take the sdcard to pc if necessary
<ogra> use your desktop pc and gparted
<ogra> you should be able to shrink the partition
<neure> is gparted x11 program?
<neure> my vmware only has shell, no X11
<ogra> gparted is X11
<neure> :/
<ogra> it uses parted and ext2resize in the backend though
<ogra> but they are rather complex to use
<neure> i need to do apt-get install xfce-4 on my vmware first :D
<neure> or something like that
<SQlvpapir> you can ssh -X into the box without it having a full X+desktop installed
<neure> mm., true
<neure> i should install some local X server
<neure> probably cygwin?
<ogra> just openssh-server and gparted
<SQlvpapir> seems like a major workaround. if you can take your desktop down and boot from a usb stick/cd that would be much easier
<ogra> then you can do "ssh user@vm -X gparted"
<neure> well i first need to install the X server ;)
<ogra> you dont need an xserver with openssh
<ogra> gparted will pull in what it needs to run
<ogra> should only be X libs
<ogra> oh, wait, your host is windows ...
 * ogra now gets the prob
<neure> :)
<ogra> just stop using windows ;)
<neure> not my choice
<ogra> it helps in so many areas :)
<neure> running windows, qemu, vmware, windows, qemu in vmware, beagleboard and now adding remote X.. this can get confusing..
<neure> double windows :D
<amitk> *shudder*
<hrw> amigaos -> macos -> windows 3.11 -> zx spectrum
<neure> -> ?
<hrw> neure: your list of vm reminded me old amiga times
<neure> heh
<neure> i had c64 instead of spectrum
<neure> and i never really used mac
<neure> and skipped 3.11
<hrw> neure: amigaos as host with mac emulator which was running x86 emul which got zx spectrum
 * hrw -> lunch
<neure> ah right
<neure> :)
<neure> you can run that amigaos on winuae.. :)
<neure> or some other uae
<neure> damn
<neure> how the hell do i switch from ubuntu-netbook to some other desktop
<neure> ?
<ogra> at the login manager select your session
<neure> there is no such thing
<neure> login manager?
<neure> where do i select session?
<neure> oh wait
<neure> found it
<neure> :D
<neure> silly me
<ogra> fi you log out of netbook you get to the login manager
<ogra> :)
<neure> i didnt see any session options because i had not chosen user
<neure> i was expecting to be able to choose session already before having to select user
<neure> mm
<neure> lxde <3
<ogra> oh, sweet !
<ogra> the maverick kernel seems to boot on the XM
<neure> sounds good
<neure> i wonder when xm is available..
<ogra> since last week i think
<neure> it can be ordered now?
<neure> or you mean it has already been shipped?
<neure> how do i add swap with gparted?
<neure> hmm i think i got it
<hrw> re
<asac> ogra: can you document how to set back to uboot env defaults?
<asac> whats the way? is that just erasing the mtd2?
<ogra> re-flash u-boot
<ogra> not sure erasing gets you the defaults back, i never tried
<asac> ogra: what do you mean by "reflash uboot"
<asac> uboot still has the defaults, its just that it ignores them when there is something different in the uboot env
<ogra> re-flash u-boot bin from the u-boot prompt
<ogra> right, try to erase the env then
<asac> does that write the default env to uboot env?
<asac> i am not sure. i just thought that erasing might do the trick too
<asac> i will let lool try that
<ogra> lol
<ogra> coward !
<ogra> just dd /dev/zero to mtdblock2 :)
<ogra> and reboot
<ogra> worst case you have to setenv/saveenv the stuff manually afterwards
<lool> geez
<lool> you guys are dangerous!
<asac> me?
<lool> plural!
<asac> i feel pretty harmless here
<asac> heh
<asac> ok
<lool> asac: You're discussing with ogra!
<lool> jk  ;)
<asac> right. i might get infected with more risk ;)
<asac> ogra: so in panda world uboot would always use the built in default i guess? how will you work around the problem with partitions on the image production? thought there were problems with cylinders etc.
<ogra> *grin*
<ogra> asac, using sfdisk
<asac> ogra: sfdisk fixes that problem in which way?
<ogra> ask NCommander :) he said he has working debian-cd code, i havent seen it yet
<asac> feels odd
<ogra> parted cant be forced into CHS mode
<asac> i mean in best case we can hard code coms cylinder/sector etc. values, but are those true for all sdcards?
<ogra> sfdisk can do that fine
<asac> what does CHS mode involve?
<ogra> putting fixed values in for these
<ogra> i dont think it actually matters on mounting at all
<ogra> it just matters for MLO
<ogra> asac, basically we're re-using the imx51 scripts but use an ext3 partition for the second part. and vfat for the first one
<asac> ogra: right, but why would it not be a problem for MLO if the values are wrong
<ogra> why would they be wrong ?
<ogra> we know the disk size so we can make up proper values here
<asac> ogra: are CHS values all the same for all sdcards of all sizes etc.?
<ogra> s/disk/image/
<ogra> no
<asac> so doesnt depend on the hardware?
<ogra> they are bound to the card size
<asac> but if you produce an image, you dont know what card size the user will choose, do you?
<ogra> no
<ogra> well, it works is all i can say
<ogra> but you wont get anywhere with parted
<asac> right
<ogra> so sfdisk or fdisk
<ogra> or patch parted :)
<asac> why sfdisk rather than fdisk? i sfdisk as commonly available?
<ogra> yes
<ogra> and better scriptable
<ogra> actually sfdisk is designed for scripting
<ogra> while you need to direct fake input to fdisk if you want to script it
<asac> ogra: have oyu tried if it also helps for our imx51 uboot mess?
<ogra> nope
<ogra> i didnt touch imx51 since months
<ogra> and we dont build images for it anymore
<ogra> since lucid release
<asac> right.  just thought you evalled this switch to sfdisk ;)
<ogra> i played with it for omap
<asac> i see
<ogra> but thats a while ago
<ogra> before lucid released
<ogra> lets wait with what NCommander comes up ...
<ogra> i should get some code this week for review, i can give you the snippets for your livehelper scripts
<asac> that would be fantastic
<ogra> effectively we're holding back because of alpha1
<asac> can we have a config file with the partition layout?
<ogra> we dont want to disturb the milestone with code commits atm
<asac> rather than a loose command script?
<ogra> i think its written like the other debian-cd scripts so you will likely have vars at the top
<asac> ogra: are a1 images for omap going to happen?
<ogra> you can indeed put these vars into a config file you source
<ogra> asac, nope
<asac> ;)
<asac> ogra: what is outdated?
<ogra> livecd-rootfs is ready but i'm scared to merge it in the middle of a milestone freeze
<asac> right
<ogra> debian-cd misses the publishing code according to NCommander
<ogra> i have him access to a branch so he can work on it but i havent seen code yet
<asac> wow ftbfs growed again ;)
<ogra> according to him the images are built and bootable
<ogra> yeah, QT
<asac> hmm
<ogra> ftbfs is second prio atm
<asac> ogra: the qt fix should be changing the typedef for long to long rather than int
<ogra> we're working towards having daily builds
<asac> and drop all ncommander patches and rebuild the full qt stack
<asac> ogra: daily builds? we already have daily builds, dont we?
<ogra> well, i was told there is another timout issue too
<ogra> we dont have any arm images atm
<asac> ogra: in anycase, the typedef migration hsould be done asap
<ogra> feel free to do it or wait until the images build :)
<asac> ogra: err. we had daily images last cycle (unless they failed)
<ogra> right
<ogra> but we're changing the build system completely
<asac> so why are you working on getting daily images?
<ogra> because we are not able to build them right yet
<ogra> building the old ones wastest space on cdimage and requires manual clanup work someone has to do later
<ogra> so we dont build the old ones and the code for the new ones is still in the works
<asac> ogra: so what does this "make daily builds happen" involve?
<ogra> antimony/cdimage is short on diskspace
<asac> why dont you work with us on using the same infrastructure?
<ogra> because you dont work in the distro infarstructure
<ogra> and 60% of our work is done
<asac> so you are saying you just ensure that there is more disk space left?
<ogra> the ext3 image buiold code is ready and working, just not merged to the livefs builder yet
<ogra> no
<asac> i mean if you move your stuff to a separate host, you could also embrace our system as a "distro" infrastructure part
<ogra> oh, yes, on antimony
<ogra> then we would have to maintain a separate machine
<ogra> we want to have our  distro builds in the distro infrastructure
<ogra> there is no way around it
<ogra> since there are plenty of people maintining that it would be a massive waste (and not doable for our team) to have to maintain a complete additional machine and infrastructure
<ogra> also we dont want to duplicate code
<asac> ogra: right thats why i suggested to share the infrastructure for live-helper
<ogra> debian-cd and livecd-rootfs are there and well maintained
<asac> but i see that you guys are not yet ready mentally for looking for different stuff ;)
<markos_> ogra: rootstock/qemu gave me a fatal error: "qemu: fatal: cp15 insn ee1d6f70"
<asac> so move ahead ;)
<ogra> not with the current time schedule
<markos_> while building a ubuntu-minimal image with hardfp debs
<ogra> asac, dont forget we only have a about 6 weeks until release
<asac> ogra: sure. just saying you shouldnt invest too much work there. if you put real man cycles into it now, we should rather go and share our efforts
<markos_> that's on lucid x86_64 on a VM
<asac> ogra: what i dont get is that we had more images last cycle, and now the diskspace is not enough to have dailies for a single image?
<ogra> markos_, probably the VM kernel
<ogra> asac, preinstalled images require a lot more space
<XorA> scripts/kconfig/kxgettext.c: In function âmessage__addâ:
<XorA> scripts/kconfig/kxgettext.c:148: internal compiler error: Segmentation fault
<ogra> the raw image is 1.4G and we can only compress it at the end of the build process
<XorA> arse
<markos_> ogra: ok, i'll just fix the antive build anyway
<asac> ogra: oh true. you could lzma them though
<XorA> ogra: built a kernel natively on omap4?
<ogra> asac, we'll bzip them but still they are raw first
<asac> but squashfs is also raw first, isnt it?
<asac> nevermind.
<ogra> yeah, squash lives on the livefs builder
<ogra> and comes over in compressed format
<ogra> we could compress on the livefs builder but that takes hours on a imx51 CPU
<ogra> so we have to live with uncompressed and then compress on antimony
<ogra> the resulting image is only 4-500M though :)
<ogra> XorA, yes, several times
<XorA> ogra: seen anything like my error above?
<ogra> XorA, what kernel do you run on the machine ?
<XorA> ogra: L24.6
<ogra> and what HW is that ? a zoom ?
<ogra> i have seen random segfaults, yes
<ogra> err s/&zoom/blaze/
<XorA> ogra: this is a 4430 SDP
<ogra> XorA, usually it survives uImage creation but fails some time during modules creation
<XorA> its not random happens every time
<ogra> or if i build modules first it survives the modules but happens on uImage creation
<ogra> i also had builds that survived completely
<ogra> but there are known kernel issues on omap4
<ogra> oen is definately exposed if you use git clone with a recent git version
<ogra> try that :)
<ogra> (but be prepared for reboot)
<ogra> i know its known at TI
<lool> markos_: this seems bad
<lool> markos_: If you like, you could try the qemu-maemo/meego packages, they have a handful more ARM patches
<lool> markos_: https://launchpad.net/~lool/+archive/ports-dev/+packages
<ogra> lool, do you plan to bring them to the archive at some point ?
<markos_> lool: well, only for x86 rootstock, I'm working on a native rootstock right now
<lool> ogra: No, I'd rather avoid adding a fork to the archive; some of the patches were submitted upstream now though
<ogra> ah, great
<ogra> though the question is which upstream then :)
<ogra> i.e. will they show up in the kvm port
<lool> Ultimately they will, but yeah, it will take longer
<asac> ogra: so compressing to squash is considerably faster than compressing to gzip/bzip/lzma?
<asac> or you also want to improve image build time?
<ogra> on arm HW, yes
<ogra> no, but i want to have a reasonable build time
<asac> cant we just ship the image .squashfs compressed then ;)?
<ogra> rolling the ext2 takes about 40min
<asac> j.k.
<ogra> no
<ogra> did you read the spec ?
<ogra> we're growing the existing partition to the size of the SD on first boot
<XorA> ogra: yeah I noticed the git clone failure.
<ogra> cant do that with a readonly squashfs ...
<ogra> and it would force a union mount
<markos_> lool: better, a few errors, but i think i'll make it work
<markos_> ogra: it gives me chroot: cannot run command debootstrap/debootstrap: no such file or directory
<ogra> markos_, you installed the lucid package ?
<markos_> yes, but trying to build karmic image
<ogra> that shouldnt matter
<ogra> did it pull in qemu-kvm-extras-static ?
<ogra> seems your binfmt handler for armel chroots doesnt work
<markos_> that's a pristine lucid install :P
<ogra> dpkg -l|grep  qemu-kvm-extras-static
<ogra> is it installed ?
<markos_> yes, 0.12.3+noroms-0ubuntu9
<ogra> try: sudo service binfmt-support restart
<ogra> and then try again
<ogra> worst case try a reboot
<markos_> ok, here is the problem:
<cwillu_at_work> does plymouth work under dss?
<markos_> with default qemu-arm-static I have the fatal error in qemu I mentioned before
<ogra> cwillu_at_work, on my C4 it does
<cwillu_at_work> k, so I just don't know how to work it then :)
<markos_> ogra: with qemu-maemo, there is no static version, so I think it may possibly break when trying to run it inside a chroot -missing libs?
<ogra> cwillu_at_work, you have quiet and splash on your cmdline ?
<cwillu_at_work> ogra, I'm actually trying to bring it up by hand from a serial console
<ogra> markos_, no, the binfmt handler uses the qemu-arm-static binary
<ogra> markos_, so even if you use qemu-maemo that will only affect VMs
<cwillu_at_work> markos_, which fatal error?
<markos_> ok, i'll have to copy paste this to some pastebin, moment
<ogra> ok
<ogra> cwillu_at_work,  fatal error: "qemu: fatal: cp15 insn ee1d6f70"
<cwillu_at_work> partway through the install?
<ogra> cwillu_at_work, though he recompiled the world with hardfp
<cwillu_at_work> ah, okay
<ogra> the vm kernel is surely not compiled like that
<ogra> so that might cause this issue ... or something in qemu itself
<markos_> http://paste.debian.net/75826/
<cwillu_at_work> :/
<cwillu_at_work> plymouthd seems to ignore it's --tty arg;  it looks like it's trying to open the serial terminal for splash even though I'm passing --tty=/dev/tty1
<ogra> markos_, yeah, thats in the VM if i'm not totally wrong
<markos_> ogra: but the kernel doesn't use fpu at all, it should be totally agnostic whether I use softfp or hardfp or whatever
<ogra> markos_, what you can try (but will slow down rootstock) is to remove the static package
<markos_> i don't mind :)
 * ogra isnt sure he made qemu-arm-static a recommends
<ogra> gah, i didnt
<markos_> retrying without it
<ogra> so you might have to re-rooll the package without that dep
<ogra> rootstock will then use the VM for everything
<ogra> so should use qemu-maemo all over the place
<markos_> seems to do exactly that
<ogra> phew, at least that code works :)
<markos_> "Switching to VM for 2nd stage processing"
<markos_> Installing core packages...
<markos_> fingers crossed :)
<ogra> :)
 * ogra just got icecream ...
<ogra> -> afk for a bit
<cwillu_at_work> ogra, heh;  apparently using having a serial console available on boot breaks it
<ogra_cmpc> oh, indeed, i forgot about that
<ogra_cmpc> i even filed thwe bug in LP for it
<cwillu_at_work> you know offhand if it breaks if the serial console is display only?
<cwillu_at_work> (i.e., the first of two console= args)
<ogra_cmpc> iirc it breaks with any console= setting
<cwillu_at_work> I just had it work with console=tty1
<ogra_cmpc> hmm, then this part was fixed
<cwillu_at_work> order doesn't matter on two devices
<cwillu_at_work> just doesn't work
<cwillu_at_work> k
<lool> hrw: BTW I updated the cross-compilers spec to include doko's feedback, check the diff for the detailed changes, but the highlights are: fortan expected as well (to match upstream default set of languages), cross-toolchain rules should allow using embedded sources, should not go above dh 5 for now
<markos_> lool: speaking of compilers, how do you bootstrap java (gcj/openjdk)?
<ogra_cmpc> we have a tool for that ... it's called doko ;)
<markos_> haha
<lool> markos_: Good Q, I don't know
<hrw> lool: I checked them when you added
<markos_> lool: only java and mono are left from the big/important/lots of dependencies packages so far
<markos_> reg. mono, I suspect the CS compiler braking the build somewhere, but I'm looking at it for days
<lool> apw: Heya, did you see my ubuntu-maverick-meta patch, complementing the ubuntu-maverick linux-tools armel support?
<lool> markos_: Ok good to know
 * ogra saw it on the ML
<cwillu_at_work> lucid's x still grabs the screen eh?
<cwillu_at_work> ... from plymouth, on omap
<cwillu_at_work> did we drop xorg's omapfb?
<ogra> nope
<cwillu_at_work> rename it?
<cwillu_at_work> merge it with something else?
<cwillu_at_work> :D
<ogra> it has the same name debian gave the package
<ogra> https://edge.launchpad.net/ubuntu/+source/xf86-video-omapfb
<ogra> xserver-xorg-video-omap3 or xserver-xorg-video-omapfb
<ogra> make your pick (NEON or not)
<cwillu_at_work> sorry, distracted
<cwillu_at_work> and less distracted now
<cwillu_at_work> I don't see xserve-xorg-video-omap* anymore
<cwillu_at_work> nothing that starts with o
<ogra> cwillu_at_work, where do you look ?  we only build it for armel
<cwillu_at_work> ogra, on a beagle
<cwillu_at_work> I do see a bunch of xserver-corg-video-{1.0,1.9,2,4,5,6} though
<ogra> its in universe, is that enabled ?
<cwillu_at_work> yep
<ogra> lucid ?
<cwillu_at_work> yep
<ogra> weird
<ogra> i use it here
<cwillu_at_work> I used it in karmic
 * cwillu_at_work apt-get updates unnecessarily
<ogra> as you can see on the LP page above it exists :)
<cwillu_at_work> liar
<ogra> heh
<cwillu_at_work> and as long as I have your attention, novtswitch or similar doesn't seem to work;  is that just me?
<cwillu_at_work> trying to get that smooth splash experience working :)
<cwillu_at_work> geez
<ogra> hmm, not sure if novtswitch is recognized by plymouth
<cwillu_at_work> no, by xorg
<ogra> it might switch forcefully
<ogra> (before xorg comes up)
<cwillu_at_work> xorg switches forcefully, regardless of the switch
<cwillu_at_work> I'm running plymouth, and I want plymouth to stay on the screen until an app is loaded in xorg
<ogra> might be that the new xorg doesnt anymore
<cwillu_at_work> but xorg switches vt's (which I can deal with) and clears the screen (which I can't)
<ogra> man xorg doesnt have it
<cwillu_at_work> Xorg --help does
<ogra> best ask in #ubuntu-x
<ogra> they might know if thats just a missed leftovert in the documentation
<ogra> everything relies on KMS nowadays so it might actually be that the option is gone
<cwillu_at_work> ahhhh, and dss isn't a kms driver
<cwillu_at_work> how does plymouth-x11 work?
<ogra> no idea :)
<ogra> i know TI works on adding KMS support for the future
<jussi> right, Im going to ask this one final time, because I know you all hate it when I ask, but what arch is the imx51?
<ogra> jussi, ARM :)
<jussi> ogra: so arm and not armel, right ?? :D
<ogra> jussi, cortex-a8 ARMv7
<sebjan> I generated a kernel source package (debuild). Now I'd like to generate the kernel image and headers packages from it, in native build (ARM). What command shall I run / where to find this info?
<ogra> armel just means arm with little endian
<ogra> all arm HW we support or ever supported is little endian
<Martyn> After reading much of what was posted on the GCC list, I'm confused as to why GCC wants to adopt C++ into GCC (vs g++) ... When it comes down to it, what's the reason for the upcoming proposed change?
<cwillu_at_work> Martyn, aren't they just talking about allowing the use of c++ in the implementation of gcc?
<Martyn> I think so .. but I really haven't understood why.
<rsavoye> it's cause for some things C++ works better. ie, look at the new Gold linker
<sebjan> amitk: ping
<amitk> sebjan: pong
<sebjan> amitk: I generated a kernel source package (debuild).
<sebjan> amitk: Now I'd like to generate the kernel image and headers packages from it, in native build (ARM).
<sebjan> amitk: I have seen some guidelines on https://wiki.ubuntu.com/KernelTeam/KernelMaintenanceStarter for doing so on qemu
<amitk> sebjan: yes, using sbuild
<sebjan> amitk: but had issues (probably with proxy settings...), and would anyway like to do on natively on my ARM board
<cwillu_at_work> Martyn, that means it's not vs g++ at all
<cwillu_at_work> ie, they're not talking about compiling c++ via gcc
<amitk> sebjan: build the kernel on the board? ok. What is the problem?
<sebjan> amitk: build the image and headers packages from my source package on the board
<sebjan> amitk: what would be the sbuild command line then?
<amitk> sebjan: the debuild line should work, you don't need an sbuild then
<sebjan> amitk: I am also able to generate kernel image and header .deb using debian/rules, but I suppose this is not the best way to do it to emulate what would happend after uploading my source package on a ppa, right?
<amitk> sebjan: ohh, I see, the wiki page only uses debuild to make a source package, not to compile the kernel
<sebjan> amitk: yes, right :)
<ogra> debuild -b
<amitk> sebjan: debuild -b
<ogra> instead of -S
<amitk> aah, ogra beats me to the punchline as always :-p
<ogra> :)
<sebjan> ok, so debuild -b will generate the image and headers packages? (all the packages specified in my debian folder I guess)
<ogra> all binary packages
<amitk> sebjan: it will do what happens on a buildd
<amitk> sebjan: so prepare to wait a few hours
<sebjan> amitk: ok, I'll try this tonight then :)
<sebjan> amitk: ogra: thanks!
<amitk> sebjan: give the command with 'time' in front of it. Would be interesting to see how long it takes on your new boards :)
<sebjan> amitk: yep, I'll do that :)
<ogra> what kind of board is that ? omap4 ?
<dmart> Does anyone know a way to snapshot a load of data from /proc?
<ogra> if so there was a trick to make it use -j2
 * ogra cant remember it though
<dmart> tar and cpio fail, because proc files read as zero-sized when you stat them
<ogra> amitk, do you rememebr the switch to make debuild use multiple cores ?
<amitk> ogra: debuild -j2 ?
<ogra> heh, yeah, i guess thats it
<ogra> -j2 makes a significant difference on omap4
<amitk> dmart: find /proc -maxdepth 1 -type f | xargs cat | less
<jcrigby> ndec:ogra sent me to you.  I saw some omap4/cortexa9 patches from aneesh@ti.com on the u-boot mailing list last week
<amitk> dmart: this gets your the output, you could add some echos to add the filename above it?
<dmart> amitk: that could work... I'll play around with it.  Thanks
<cwillu_at_work> hmm
<cwillu_at_work> seems like a trivial change to re-enable novtswitch
<markos_> ogra: is there any way to enable/force unauthenticated repos in rootstock?
<markos_> I get "E: There are problems and -y was used without --force-yes"
<markos_> nm, it was a different error
<markos_> apparently it failed reading my non-english /etc/default/console-setup
<markos_> anyway restarting
#ubuntu-arm 2010-06-03
<cwillu_at_work> I hate vts
<cwillu_at_work> I also hate Xorg, non-kms drivers, and the lack of a good way of making xsplash act like plymouth
 * DanaG wishes there were an Ubuntu phone.
<XorA> ogra: L24.7 kernel improves the native compile issue on omap4
<ogra_cmpc> XorA, aha, cooloney can you rebase our package ? ^^^
<ogra_cmpc> XorA, does git work with it now ?
<cooloney> ogra_cmpc: ok, let me look, thanks for head up
<XorA> ogra_cmpc: that still fails :-(
<XorA> fatal: git fetch_pack: expected ACK/NAK, got ''
<ogra_cmpc> bah
<XorA> 24.7 isnt at final release yet I beleive
<cooloney> XorA: yeah, got a new branch L24.7 with a new tag:  L24.7-pre-release
<XorA> got as far as fs/partitions/msdos.o before kernel build dies now
<markos_> ogra: ok, finally I got the first hardfp image (ubuntu-minimal), I had to modify rootstock (named the script to rootstock-native) to make it work without qemu. I still have a couple of probs, mainly I have to preset some debconf values in console-setup otherwise I can't output everything to the logfile -I could use tee, but I'd like the process to be totally automated
<markos_> now building ubuntu-standard
<markos_> I'll upload them soon
<lool> markos_: Cool
<ogra> markos_, great
<ogra> once you are done, gimme a bzr branch to merge :)
<markos_> ogra: I'll file rootstock-native as a bug report to LP
<ogra> or that
<markos_> I don't use bzr :)
<markos_> I'm more of a hg/svn person :)
<markos_> (tbh, I've never used bzr, so I'm indifferent)
<lool> the photos from http://www.netbooknews.de/16929/arm-freescale-ibm-samsung-st-ericsson-und-ti-schliessen-linux-buendnis/ are decent, but did someone find a video or the slides from the launch presentation?
<lool> ECHAN
<lool> BTW, Ubuntu is used as part of Linaro which was launched today at Computex; it's an important ARM effort for us
<zumbi> great! is linaro a meego competing project?
<zumbi> xilinx is missing on the partner list :) (I think it would be good to have them)
<markos_> ogra: #589104
<amitk> zumbi: no, not competing
<ogra> thanks
<amitk> zumbi: linaro will contribute directly to upstream and distros like meego can use that work
<markos_> bbl
<amitk> zumbi: http://www.flickr.com/photos/22046787@N03/4664911239/
 * zumbi gets excited
<lool> http://www.linaro.org/arm-freescale-ibm-samsung-st-ericsson-and-texas-instruments-form-new-company-to-speed-the-rollout-of-linux-based-devices/ is the announcement
<zumbi> hehe, maybe linaro wants to sponsor debconf.. :-)
 * zumbi hides
<fewfw> qemu: uncaught target signal 11 (Segmentation fault) - core dumped
<fewfw> Segmentation fault
<lool> zumbi: not for profit == we have no money   ;-)
* ogra changed the topic of #ubuntu-arm to: Ubuntu ARM Discussion & Development | https://wiki.ubuntu.com/ARM | Want to Submit a Bug? https://bugs.launchpad.net/ubuntu/+filebug | Debian ARMel TODO: http://wiki.debian.org/ArmEabiTodo | Build a rootfs from scratch: https://wiki.ubuntu.com/ARM/RootfsFromScratch | got package build issues in lucid ? see https://wiki.ubuntu.com/ARM/Thumb2 | no, we do not cross compile | linaro.org anno
<ogra> bah
* ogra changed the topic of #ubuntu-arm to: Ubuntu ARM Discussion & Development | https://wiki.ubuntu.com/ARM | Want to Submit a Bug? https://bugs.launchpad.net/ubuntu/+filebug | Debian ARMel TODO: http://wiki.debian.org/ArmEabiTodo | Build a rootfs from scratch: https://wiki.ubuntu.com/ARM/RootfsFromScratch | got package build issues in lucid ? see https://wiki.ubuntu.com/ARM/Thumb2 | linaro.org anno
<ogra> why the heck
<amitk> too long
<ogra> its not
* ogra changed the topic of #ubuntu-arm to: Ubuntu ARM Discussion & Development | https://wiki.ubuntu.com/ARM | Want to Submit a Bug? https://bugs.launchpad.net/ubuntu/+filebug | Debian ARMel TODO: http://wiki.debian.org/ArmEabiTodo | Build a rootfs from scratch: https://wiki.ubuntu.com/ARM/RootfsFromScratch | package build issues ? see https://wiki.ubuntu.com/ARM/Thumb2 | linaro.org announced, visit #linaro
<ogra> there we go, sorry for the noise
<dev__> ogra is Linaro will be the same as Ubuntu-arm ??
<dev__> ogra: Is Linaro will be the same as Ubuntu-arm ?? I had check page https://launchpad.net/linaro/ which mention "Also known as:   ubuntu-arm"
 * zumbi `buildcross` in the new queue targetting experimental suite.
<ogra> dev__, no, ubuntu-arm is ubuntu
<dev__> ok
<ogra> there will still be the ubuntu-arm channel and an ubuntu-arm team that specifically works on ubuntu stuff and builds ubuntu images
<dev__> Can you point any link which will give me clear idea about relation of Ubuntu-ARM and linaro community ?
<amitk> dev__: read the faq on linaro.org. It should answer your questions
<amitk> http://www.linaro.org/faqs
<amitk> ogra: perhaps the faq link should be in topic
<ogra> i wonder if i could drop the debian eabi stuff
<ogra> lool, ^^^ any objections ?
<ogra> i think we're far beyond that
<rcn-ee> do it.. ;)
<dev__> amitk, thx for link.
* ogra changed the topic of #ubuntu-arm to: Ubuntu ARM Discussion & Development | https://wiki.ubuntu.com/ARM | Want to Submit a Bug? https://bugs.launchpad.net/ubuntu/+filebug | Build a rootfs from scratch: https://wiki.ubuntu.com/ARM/RootfsFromScratch | package build issues ? see https://wiki.ubuntu.com/ARM/Thumb2 | www.linaro.org announced, visit #linaro ! also see http://www.linaro.org/faqs/ for questions
<ogra> dev__, i belive the "Also known as:   ubuntu-arm" isnt there anymore
<ogra> hmm, no, it isnt
<ogra> could someone fix that ?
<dev__> It is there https://launchpad.net/linaro/
<ogra> yeah
<ogra> i missed the light grey on white :)
<ogra> i agree its very confusing
<dev__> FAQs are very good.
<fewfw> qemu: uncaught target signal 11 (Segmentation fault) - core dumped
<fewfw> Segmentation fault
<lool> ogra: in the topic?
<lool> ogra: http://wiki.debian.org/ArmEabiTodo > sure
<ogra> lool, nope, under "Also known as:"
<lool> ogra: where is that?
<ogra> lool, https://edge.launchpad.net/linaro
<lool> Also known as ubuntu-arn?
<lool> ubuntu-arm?
<lool> is that an issue?
<ogra> well, it caused confusion already
<lool> It's the name we've been using the last couple of months and some URLs might point to it
<ogra> i know
<lool> I think we can sort out the confusion here
<ogra> hmm
<ogra> lool, even after mobile was renamed ?
<ogra> that smells like a big chaos
<fewfw> qemu: uncaught target signal 11 (Segmentation fault) - core dumped
<ogra> fewfw, re posting the error message over and over wont get you any answers
<ogra> fewfw, how about you give some more info :)
<jcrigby> ndec: around?
<jcrigby> ndec: ogra sent me to you.  Hoping you can put me intouch with Aneesh at ti.  He posted some initial omap4 patches to u-boot mailing list a week or so ago.
<jcrigby> I would like to help if possible.
<cwillu_at_work> oh, sweet, that was easy
<ndec> jcrigby: hi
<jcrigby> ndec:sorry to start a conversation and then leave but I need to drive my kids to school, be back in 20 minutes or so
<ndec> jcrigby: no problem. i am in a meeting anyways.
<cwillu_at_work> omapfb works fine with -nr, just needs a pScrn->canDoBGNoneRoot  = 1; in the driver
<ogra_cmpc> cwillu_at_work, what for do you use that ?
<cwillu_at_work> ogra_cmpc, plymouth?
<ogra_cmpc> emulating KMS behavior ?
<cwillu_at_work> plymouth uses that even with kms
<ogra_cmpc> ah
<cwillu_at_work> it seems that kms basically allows a driver to act somewhat like omap's frame buffer already works
<ogra_cmpc> cool
<ogra_cmpc> KMS support for omapbf was discussed at UDS btw
<cwillu_at_work> so the only thing needed to get a slick transition to gdm is that one line in the omapfb driver
<cwillu_at_work> well, and a nice x11 renderer for plymouth if you want to hide your initialization too, but ya
<ogra_cmpc> could it do any harm to other functionallity ?
<cwillu_at_work> no, it's only used as an arg to xorg
<ogra_cmpc> ah, good
<ogra_cmpc> lets add it then :)
<cwillu_at_work> it's checked when blanking the root window, and that's it
<cwillu_at_work> I threw it in to the end of the pScrtn-><foo> = <bar> block in omapfb-driver.c:232
<cwillu_at_work> and the check where it's used is xorg-server-1.7.6/hw/xfree86/common/xf86Init.c:305:  if (bgNoneRoot && pScrn->canDoBGNoneRoot) {
<cwillu_at_work> (bgNoneRoot is the -nr option)
<ogra_cmpc> ah
<cwillu_at_work> ogra, is displaying a boot splash on multiple console's (specifically, multiple console= entries) actually a desired usecase?
<ogra> cwillu_at_work, not really, but having it not break if console=ttyS* is set is one
<cwillu_at_work> define "not break"
<ogra> well, it shouldnt affect tty0 if i define console=
<cwillu_at_work> I'm going to do that thing where I make it do what I need it to do, and then describe what I did :p
<ogra> well, it would be cool if you would produce an upstreamable fix :)
<cwillu_at_work> one of these days I should figure out ppa's
<ogra> wont help you for arm
<ogra> we dont provide arm ppas yet
<cwillu_at_work> ogra, remind me, what was the actual bug with plymouth and console= again?
<cwillu_at_work> just made a big loop, having gotten the behaviour I wanted, then backing out changes until it broke again.
<ogra> cwillu_at_work, https://bugs.launchpad.net/bugs/516825
<ubot2> Launchpad bug 516825 in plymouth (Ubuntu) "plymouth doesnt show any splash as soon as a console= commandline option is used on boot (affects: 2) (heat: 12)" [Medium,Fix released]
<cwillu_at_work> The funny thing is that I backed out _all_ of my changes to the package, and it works :)
<ogra> heh
<ogra> yeah, plymouth is a myth
<cwillu_at_work> so, console=tty1 should definitely not work?
<ogra> well, the bug is fix released
<ogra> https://bugs.freedesktop.org/show_bug.cgi?id=22239 is the upstream bug for it
<ubot2> Freedesktop bug 22239 in plymouth general "improve console= handling" [Normal,New]
<ogra> - Make VT mandatory for renderer plugins, so we fallback gracefully to text when the console is not a VT.
<ogra> thats the changelog entry for the fix in the package
<ogra> seems slangasek fixed that one
<cwillu_at_work> okay, that makes some sense
<cwillu_at_work> it's broken in the two console case
<ogra> or, no, it was Keybuk
<ogra> yes
<cwillu_at_work> I can set console=tty0 or I can set console=ttyS2,115200n8
<ogra> but tty1 shoudl work
<cwillu_at_work> but setting both breaks it
<ogra> right
<ogra> so the upstream bug is still there
<cwillu_at_work> on the other hand, if you have a bootsplash, it doesn't matter so much that you don't have boot output on tty1
<tmzt> was linear to tiled framebuffer issue researched following uds?
<garyhbaker> Unable to do a NetInstall on a Beagleboard.  Can't find archive.  Is something down.
<garyhbaker> During the install process, after it gets to the part where it asks to choose an archive, the only choice is UK.  Ran fine yesterday.  Are there other archives and if so what are their URLs?
<lool> garyhbaker: there's only one archive for armel, which is ports.ubuntu.com/ubuntu-ports
<gsnedders> Anyone tried to install Lucid on any MX51 device that isn't the Babbage?
<amitk> gsnedders: we've only had access to Babbage
<amitk> but I suspect a different device would need a different kernel
<gsnedders> Yeah, that's what I'm thinking
#ubuntu-arm 2010-06-04
<hrw> morning
<cooloney> hrw: morning
<cooloney> sebjan: hi, morning
<cooloney> amitk: morning
<sebjan> cooloney: morning
<cooloney> sebjan: i saw your email. yes, try that 'exclude' d-i patch will solve your issue
<amitk> morning cooloney, all
<sebjan> cooloney: yes, I'll do that thanks!
<cooloney> sebjan: normally, how long will it take for building package in your omap4 hardware?
<sebjan> cooloney: :) that's a good question. It ran for 5 hours tonight until it stopped on this error.
<sebjan> cooloney: I have all my files on NFS, and my NFS settings may not be optimal either.
<cooloney> sebjan: ok, good, understand. hehe, i guess it is using -j2 defaultly, right
<sebjan> cooloney: I specified -j4, and the cores seemed quite loaded when I checked
<DanaG> ooh, dual-core?
<cooloney> DanaG: yeah, it is omap4
<amitk> sebjan: 5 hrs?! so not too much better than our existing situation.
<cooloney> dual-core a9
<amitk> sebjan: We're at 7hr per arm flavour ATM
<cooloney> amitk: right, i don't see any improvment
 * amitk wonders if we should to some study about how I/O bound this is
<cooloney> amitk: maybe NFS is the bottleneck
<amitk> NFS?
<DanaG> hmm, I'm curious what omap4 hardware.
<DanaG> my gripe with the ARM stuff is that the 3D stuff is often blobby (and not nvidia okay blob, but PowerVR doesn't-even-build blob)
<cooloney> amitk: hehe, sebjan is using NFS with omap4 hardware as rootfs, so i guess it is building via NFS
<hrw> DanaG: powervr for omap3?
<amitk> cooloney: ok, that could be reason if the source are on NFS
<ogra> amitk, i'm building a native kernel faster (no package though)
<ogra> and on SD
<DanaG> yeah, beagleboard.  The TI PowerVR Makefile tries to make clean on a hardcoded target dir that doesn't exist.
<ogra> create it :)
<amitk> ogra: want to try a 'debuild -b' of the lucid package on your shiny board? :)
<ogra> amitk, will do that on the weekend, currently i need the board with constant reboots (testing jasper)
<hrw> ogra: how is panda compared to normal bb?
<DanaG> hmm, I wish there were an Ubuntu phone.
<sebjan> yes, I access the sources over NFS. I will give a try on SD card.
<ogra> hrw, compared to normal bb ... hmm normal bb is on my desk, panda is in shipment ... if that suits you as comparison :)
<DanaG> Panda?  Is that a code name?
<hrw> ah ok
<ogra> should arrive today/tomorrow though
<ogra> i had some customs issues
<hrw> ogra: ah, right - you told that before
<hrw> hi zyga
<hrw> DanaG: run ubuntu on n900?
<zyga> hrw, hi, how are you
<DanaG> ah, surprised I didn't think of that.
<DanaG> Oh yeah, and my criteria for "Useful 3D" is Compiz.
<hrw> zyga: fine thx. forgot that we have long weekend in Poland and wanted to visit one place... kissed door handle ;(
<DanaG> Or at least accelerated metacity compositing would be good.
<hrw> DanaG: n900 uses omap3 so powervr glx libs
<ogra> compiz uses full GL afaik, you wont make it work properly on GLES i guess
<zyga> hrw, I need to visit some government place next week, I figured trying to go there today would be a waste of time
<hrw> ~curse gcc4.5 configure
<hrw> zyga: it was 10-15 minutes walk with daughter
<ogra> ah, poland had a bank holiday too yesterday ?
<DanaG> Bummer... that old "XGL" would be exactly what we'd need.
<DanaG> Implement that on GL ES...
<ogra> germany only had it for half the country (mainly the catholic parts)
<hrw> ogra: yes
<hrw> ogra: in theory Poland is catholic country
<zyga> hrw, what's wrong with configure :-)
<hrw> zyga:     ${CC} ${CFLAGS} ${LDFLAGS} -rdynamic conftest.c -o conftest > /dev/null 2>&1
<hrw> zyga: ${CC} == gcc in that case
<zyga> mmm
<zyga> so what's wrong with this line?
<hrw> zyga: but --target=arm-linux-gnueabi
<hrw> zyga: it should use arm-linux-gnueabi-gcc
<zyga> oh
<hrw> but I have to check one thing more
<ogra> hrw, apt-get source x-loader-omap4 and look at debian/rules
<zyga> cross vs native all over agian
<ogra> i think there is a solution in it
<hrw> ogra: you want me to have nightmares?
<hrw> ogra: I think that it uses proper cc and inproper objdump
<hrw> one coffee later I will solve
<ogra> right, look at the rules there, it solves that
<hrw> gracias my friend
<ogra> u-boot-omap4 has the same snippet
<hrw> so tomorrow is BBXM premiere?
<DanaG> I'm still wondering where all of Marvell's stuff is.  Not out yet.
<hrw> ogra: maverick/arm only source?
<ogra> yep
<markos_> is omap4 cortex-a8 or cortex-a9, I'm confused
<hrw> my adm64 fetched
<ogra> well source is arch agnostic
<hrw> markos_: a9
<markos_> hrw: cool, it will have a fast fpu
<hrw> markos_: it has already
<markos_> hrw: I mean because it's based on a9 :)
<hrw> ok
<hrw> markos_: I hope that storage i/o will not kill omap4
<hrw> markos_: as it is SD or USB only as options for storage
<markos_> yes, that sucks
<markos_> well, one can connect a fast disk on usb2 but that negates the advantage of its small size
<hrw> now I am running bb/c3 with rootfs on usb stick, 40GB 2.5" pata drive on usb as storage
<DanaG> yeah, marvell's stuff has SATA.... but the currently-available ones won't run lucid.
<hrw> markos_: small size of BB is disadvantage when you use it as devboard
<hrw> 17.8MB/s from pata drive is not that bad (hdparm -Tt)
<markos_> my efikamx here has flash on ata and it's quite fast, much faster than the sd
<markos_> yes, sth like that, SD gets 10MB/s max
<hrw> time to check OE gcc patches
<zyga> hrw, I did some benchmarks on netbook
<zyga> hrw, my BB pulls solid 20MiB/s from 2.5" SATA HDD
<markos_> zyga: via usb2 you mean?
<zyga> markos_, yes
<zyga> _and_ it was two USB hubs away from BB
<markos_> well, that's not surprising, usb2 can get up to 400Mbps
<hrw> zyga: I have 3.5" sata hdd in usb2/sata case. does 110MB/s over sata and is able to max sheevaplug usb connector with 40-50MB/s. did not tried it with beagleboard
<markos_> zyga: I get ~25MB/s here, on an old 40GB in a pata ->usb case
<markos_> but that's not very important, the thing is that BB's internal storage is slow, and fast SD cards aren't avaialble yet
 * gsnedders wonders how fast he gets over NFS
<lool> zyga: That's still relatively far from what a common intel system with SATA can do (75 MiB/s or so I'd expect)
<lool> It's decent, but it's one of the bottlenecks
<lool> CPU speed is one as well on beagle, but with GHz SMP it should be better
<zyga> lool, if you attach SATA SDD the speed can go even higher
<markos_> lool: the bottleneck is usb2 not the disk, no matter how fast the disk is, usb2 will max at ~40MB/s
<lool> markos_: Yes, I know
<lool> markos_: that's why I mentin SATA
<markos_> lool: it's not a fair comparison :)
<zyga> mmm
<hrw> heh.. oom on 8gb ram..
<lool> The only ARMv7 SoC with native SATA that I've seen is dove
 * zyga notices nitl netbook got cheaper 
<lool> markos_: it exists, but it's hard to find
<markos_> lool: imx53 is supposed to have sata as ell
<zyga> does anyone know what how they roll their software?
<lool> markos_: Isn't it fake SATA on USB as on imx51?
<lool> or SATA over PATA or something equally poor
 * ogra_cmpc thought imx53 only has PATA
<markos_> good question, i don't know
<lool> markos_: babbage had a SATA connector, but the soc has no native SATA; it was USB behind it IIRC
<ogra_cmpc> in the SoC, not sure how its exposed to the outside, might be a SATA socket
<lool> So same limitation
<markos_> http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MX535&nodeId=0162468rH31143ZrDR988D
<ogra_cmpc> well, SATA over PATA might imnprove it
<markos_> doesn't say if it's over USB though
<ogra_cmpc> babbage (imx51) is definately USb
<ogra_cmpc> 53 has a PATA bus but i dont think a SATA one
<lool> markos_: I checked the PDF brief, and it mentions PATA *and* SATA connectivity
<markos_> PATA is not even mentioned in iMX515 page
<lool> http://cache.freescale.com/files/32bit/doc/fact_sheet/IMX535ANNCMNTFS.pdf
<markos_> so I guess iMX53 does include PATA/SATA on the chip
<lool> markos_: Do you have an idea of timeline to availability of imx53?
<lool> http://cache.freescale.com/files/32bit/doc/fact_sheet/IMX515FS.pdf
<lool> imx51 mentions PATA
<lool> (well it mentions ATA)
<lool> the text below the diagram mentions P-ATA
<markos_> no sorry, but I understand samples will be available to Genesi before the end of summer
<amitk> Rob mentioned late this year for something that we could buy
<sebjan> All: j'ai mis a dispo un pre-kernel L24.7 sur le serveur dans www/releases/L24.7/pre-release (sans les modules, mais c'est pas genant pour booter et faire des builds)
<sebjan> oops... sorry :)
<lool> 24.7?  wow
<lool> tell me it aint linux 2.4.x!
<sebjan> lool: :)
<XorA> lool: 24.7 is internal TI version number
<XorA> its actually 2.6.33 + TI stuff
<zyga> asac, ping
<zyga> asac, I need to be able to display package build failures, is there an interface to harvest that data?
<asac> zyga: you mean in ppas?
<zyga> asac, mmm I mean our 'derived archive' concept
<asac> fta: ^^ ... i know you recently did that with our daily builds, do you have input?
<zyga> let's say you setup a linaro spinoff
<zyga> asac, with your own 'archive'
<zyga> and dashboard to see how it works
<zyga> so this dashboard needs to know _all
<zyga> _all_ packages you have in the archive
<zyga> including daily package changes (new uploads/rebuilds) and build failures
<asac> zyga: i think the problem is that there are no derived archives yet so we cant tell for sure what will happen. however, i know that there is an api for ppas and i would assume you can do the same for a real archive
<asac> zyga: you could also talk to the ubuntuwire folks ... and see how they maintain:
<zyga> asac, can you give me any pointers to PPA APIs?
<asac> http://qa.ubuntuwire.com/ftbfs/
<asac> zyga: i havent used it, but fta has ... i think he will reply when he is available
<asac> zyga: otherwise you can ask on #launchpad
<asac> let me see if i can find who is maintaining ubuntuwire
<asac> ogra_cmpc: do you know?
<zyga> http://qa.ubuntuwire.org/
<zyga> wow
<zyga> coooooool
<ogra> asac, stgraber
<ogra> though he is not responsible for the ftbfs page
<asac> zyga: yep. so talk to stgraber ... he is your friend for sure
<ogra> ask in #ubuntu-motu
<asac> zyga: you can find him in -motu or -testing
<ogra> zyga, http://qa.ubuntuwire.org/ftbfs/source/
<asac> ogra: i asked in -motu ... didnt get anything back yet
<ogra> there is the code
<tmzt> zyga: I would hope such spinoffs aren't needed, sadly things like arm11 support will only come that way
<asac> zyga: go to #ubuntu-motu ... and ping geser
<asac> i prepared him that you will ask him a few questions ;)
<ogra> asac, so did you make a decision about LinuxTag ?
<zyga> asac, ogra: I know stgraber, I traveled with him to the UDS :-)
 * zyga switches networks
<ogra> zyga, ah, nice
<asac> ogra: dates?
<ogra> 8th to 12th (next week) i'll go there from thu to sat
<ogra> the beagle community will be there, surely worth to meet them
<hrw> I am considering going there but need to check program more
<ogra> beer in the evenings
<ogra> and likely good weather
<ogra> isnt that enough as a good program ?
<hrw> ogra: sure, but need to convince slangasek too
<ogra> heh
<ogra> bribe him with beer :)
<slangasek> pretty sure the company can buy you beer for a lot cheaper than they can get you a hotel room, if that's all you're after ;)
<ogra> lol
<hrw> ;d
<hrw> slangasek: I need to convince myself too - my car probably be ready to get it from service next week. and this can higher priority for me then going to LT
<zyga> ogra: tell me, is there any serial number inside an ARM CPU?
<zyga> ogra: please tell me there is
<hrw> zyga: depends on SoC
<hrw> zyga: but only some offers such function
<ogra> zyga, what do you want to achieve ?
<ogra> ogra@babbage2:~$ cat /proc/cpuinfo |grep Serial
<ogra> Serial		: 0000000000000000
<zyga> ogra: well basically, device identification
<ogra> zyga, look at flash-kernel
<zyga> ogra: uboot shows some serial number
<amitk> zyga: not really, is the answer
<ogra> could be more fine grained but its already pretty good
<zyga> mmm
<zyga> okay
<zyga> another question
<amitk> it isn't foolproof
<zyga> fw_setenv/fw_printenv
<zyga> can I put UUID inside and assume it will be more-less portable?
<zyga> that I can fw_setenv my_env=UUID on all devices (somehow)
<ogra> well, you usually never touch the root= cmdline option after install
<ogra> again look at flash-kernel
<zyga> ogra: I'm looking for something outside the FS, if you reinstall the filesystem UUID is gone
<ogra> this time the flash-kernel-installer.postinst script, thats what d-i and ubiquity execute during installation
<hrw> zyga: so you want to be able to identify HW?
<zyga> yes, exactly
<zyga> I'm looking for a foolproof way to provision devices
<ogra> flash-kernel --supported :)
<asac> JamieBen1ett: what happened to arm-m-liquid spec? did that get dropped when moving it from ubuntu-arm to ubuntu?
<asac> or who was leading that moving effort?
<ogra> asac, rbelem
<ogra> oh, he was leading the spec :) surely not the moving
<hrw> zyga: how you identify x86 boxes?
<ogra> hrw, you dont need to
<asac> ogra: yeah. seems it got renamed back to mobile-m
<ogra> thats why flash-kernel exists :)
<asac> i will rename it back as we are embracing it
<ogra> yeah
<ogra> we dont have it on the trachker even
<ogra> *tracker
<lool> asac: https://blueprints.launchpad.net/ubuntu/+spec/mobile-m-liquid
<lool> asac: Was renamed to mobile-
<asac> yes, i take it back as i am approver and dont want to make naming complicated
<ogra> ++
<ogra> we also dont have manpower to care for it in mobile
<asac> dropped a note why that name was choosen (technical burndown purpose etc)
<asac> so hopefully they dont feel offended by being arm-m ;)
<zyga> hrw, I don't identify x86 boxes
<ndec> ogra: asac: hi. quick question on packages... I need to write a xxx.install file in my package to split into multiple bin packages. in ubuntu gstreamer, the xxx.install file has debian/tmp/usr/lib... when I build my pacakge I don't have debian/tmp subfolder, but debian/xxx instead. and my package fails to build. where does this tmp come from?
<ogra_cmpc> ndec, omit debian/tmp and it will work
<ndec> ogra_cmpc: i tried this as well, but without the leading '/' and it did not work
<asac> ndec: yeah. omit that debian/tmp
<ogra_cmpc> hmm, it should work
<ogra_cmpc> ndec, can you paste a line from your current .install file
<asac> debian/tmp is automatically used by debhelper if you have multiple binary packages in control
<ogra_cmpc> right
<asac> if you have just one it usually installs all in the target package
<asac> now i wonder how to filter stuff out ;)
<asac> hopefully there is magic that still allows .install ;)
<ogra_cmpc> by dirs in .install or specifying the actual single files
 * asac hasnt done a single binary package for a long time it seems
<ndec> asac: ok, i see... i do want more packages, but I only added 1 in control for now.. I was planning to add the 2nd one later ;-)
<ogra_cmpc> that shouldnt make a difference
<asac> ndec: yeah. just add a second. but even then the debian/tmp isnt needed anymore
<asac> if you have a modern compat level
<asac> e.g. put 7 in debian/compat
 * ogra_cmpc does single binary files all the time
<ogra_cmpc> s/files/packages
<asac> yeah. ogra is always going for the simple stuff ;)
<ogra_cmpc> hehe
<ndec> asac: is the leading '/' needed if I omit /debian/tmp?
<ogra_cmpc> no
<asac> doesnt matter iirc
<asac> both should work
<ndec> ogra_cmpc: well, in fact I need a package for -dev for header files
<ogra_cmpc> if you add usr/lib/ it will install everything below debian/tmp/usr/lib in your package
<ogra_cmpc> then you need to add some more fine grained magic and also have different .install files
<asac>  you usually put usr/lib/*.so.* in the lib .install ... and usr/lib/*.so and usr/include in the -dev
<ogra_cmpc> (matching the entries in debian/control)
<asac> assuming you use autotools with -version-info to versoin the lib properly
<ndec> asac: ogra_cmpc: thanks. I have added the -dev, and started a rebuild.
<ogra_cmpc> good luck :)
<sebjan> amitk: I'd like to generate kernel source and binary packages, but with a name like 2.6.33-900.1~ti+release0. What files do I need to edit for that? (debian/changelog is re-gerenated by the debuild command)
<amitk> sebjan: you need to do a debian/rules clean, 'git clean -df' to get a clean tree, edit debian.ti-omap4/changelog to change your version number, This time debuild -b should DTRT
<amitk> sebjan: you can run 'debian/rules clean' before the build to make sure your debian/changelog reflects your changes correctly
<sebjan> amitk: ok, thanks, it seems fine!
<ogra> robclark, hey, whats the branch you built the u-boot from which i got from you with the blaze ? seems the omap_dev branch doesnt work on the panda
<ogra> (omap4_dev)
<robclark> ogra: there are some panda patches..  I'm not sure they are all integrated back in u-boot tree..
<ogra> oh, you applied them manually to your build ?
<robclark> and I guess the x-load/u-boot on the blaze is a bit older, so for sure won't have the panda patches
<robclark> yeah..   I can mail you the patches I have
<ogra> well, the two binaries you gave me work fine
<robclark> really?
<ogra> but from the stuff i packaged in ubuntu only MLO works
<robclark> oh.. yeah, that is right..
<ogra> u-boot exits with: ** Can't read from device 1 **
<robclark> the MLO/u-boot I had on that card was actually the panda version..
<ogra> it starts though, but there seems to be an issue with mmc
<robclark> ok..  if you want to build something that actually works on panda, I think I should send you the patches
<ogra> http://paste.ubuntu.com/444610/ is what i get with the packaged binaries
<ogra> works on blaze
<robclark> which you could apply on top of dev.omapzoom.org tree..
<ogra> ok
<zumbi> hrw: ayt?
<zumbi> hrw: ayt?
<zumbi> hrw: where can i have a look to the patch merging binary-cross target into binary for binutils? is that affecting debian or is it only ubuntu thing?
<hrw> zumbi: it is integrated in next ubuntu binutils package release
<hrw> zumbi: moment and I will give you bug link
<hrw> zumbi: https://bugs.launchpad.net/bugs/587851
<zumbi> hrw: please update README.cross file and if you care, please fill a bug report on `buildcross` the tool for getting cross tools built (now, in debian/experimental)
<ubot2> Launchpad bug 587851 in binutils (Ubuntu) "merge cross build into "binary" target (affects: 1) (heat: 8)" [Undecided,Fix released]
<hrw> zumbi: ok
<zumbi> hrw: thanks nad thanks for the merge :)
<hrw> zumbi: will have to check that buildcross tool
<hrw> zumbi: I got gcc-4.5 crossbuilt today
<hrw> zumbi: http://paste.ubuntu.com/444614/ was needed on my system to get gcc 4.5 cross built.
<zumbi> interesting, i have not tried 4.5
<zumbi> hrw: make sure cross-fixes and cross-include patches are up to date
<hrw> maverick base libs has from 4.5
<hrw> zumbi: cross-fixes got update - sh part needed dropping
<hrw> zumbi: merged it latest gcc-4.5 ubuntu package so I think that doko will merge it back to debian
<zumbi> hrw: sure, thanks, you are doing great! Let me know if you want to hack on buildcross code too, for getting cross tools built
<hrw> at least I will look at it
<zumbi> http://www.emdebian.org/repos/current/host/trunk/buildcross/trunk/
<zumbi> or http://www.emdebian.org/svn/browser/current/host/trunk/buildcross/trunk
<hrw> looks interesting
<zumbi> hrw: it could be used for daily builds to see if toolchains are fine
<zumbi> and it needs more love. I have great plans for it, but -ENOTIME
<hrw> common problem
<hrw> bb in few
<hrw> btw - Stylish extension to firefox roxx - whiteboard in blueprints is now 2x wider D:
<hrw> zumbi: buildcross lacks deps on embedian-tools, dpkg-cross dep needs to be versioned
<hrw> zumbi: grep-dctrl is also checked for being installed
<hrw> zumbi: and it needs to run as a root ;(
<zumbi> hrw: why does it need emdebian-tools (which has also been deprecated)
<zumbi> dpkg-cross and grep-dctrl, agreed
<hrw> zumbi: it checked for those
<zumbi> hrw: and it needs root to install packages, i have not tested, but i was planning to start using fakechroot stuff
<zumbi> you can not build gcc, without installing binutils :-/
<zumbi> any idea how to work that arround? (besides looking fakechroot)
<hrw> I plan to depend on *-source packages and call them one by one + temporary install dirs
<zumbi> btw - i am updating my launchpad info, to work better with you
<hrw> so you would do "apt-get source cross-toolchain; cd cross-toolchain*;echo armel >debian/target;dpkg-buildpackage"
<hrw> and this will build linux-libc-dev, binutils, gcc, eglibc
<zumbi> hrw, and how do you plan to get cross libraries?
<zumbi> are you going to bootstrap glibc headers?
<hrw> yes
<hrw> zumbi: buildcross suggestions: s/-v/-V/ and make -v == --verbose (display logs on screen)
<zumbi> hrw: lool had some code in his ppa and i have splitted that into packages into git repo, http://emdebian.org/git/
<hrw> zumbi: and for now small check at start "am I root" check
<hrw> thx
<zumbi> look under packages/..
<zumbi> those are not perfect, but a start
<hrw> zumbi: any readmes for them?
<zumbi> readmes? what do you mean? what for?
<zumbi> those just build in a standard debian way
<hrw> sorry, looked at wrong page
<zumbi> hrw: hint, if you need some buildcross ubuntu changes, $ debcheckout buildcross, make-a-patch :-)
<zumbi> you would need a deb-src line for debian experimental archive
<hrw> zumbi: need to make ubuntu vm for it first
<hrw> zumbi: already fetched sources from p.d.o/buildcross
<zumbi> vm as virtual machine?
<hrw> yes
<zumbi> we usually work on chroots, done by debootstrap (or newer multistrap)
<hrw> I do not like to run root-automats on my normal systems
<zumbi> do you know debootstrap?
<hrw> I know
<zumbi> ok, sorry :)
<hrw> np
<zumbi> hrw: actually you do not need root, but sudo on apt-cross and dpkg
<zumbi> hrw: it is not good idea to build packages being root
<zumbi> hrw: do you think just a warning would be fine?
<hrw> yep
<zumbi> hrw: `buildcross-0.0.2` released. Uhmmm, I forgot to thank you (will do on next release)
<hrw> no problem
<hrw> zumbi: you use some scm for it?
<zumbi> svn
<hrw> ah. sorry, you gave me link
<zumbi> yes, also if you have devscripts package you could use debcheckout
<zumbi> but you need to add deb-src line for debian/experimental
<hrw> ok
<hrw> zumbi: scm allows me to look at patches etc
<hrw> git-svn uber alles
<zumbi> yet another git fanboy :)
<hrw> zumbi: I like to be able to make commits without going to server
<zumbi> then use debcommit
<zumbi> oh! nevermind
<zumbi> yes, i also like git, but sometimes it is over abused
<hrw> btw - "gcc-4.4" instead of "4.4" maybe?
<zumbi> uhm.. i am not sure about that one, as we do not use package names, like `libs`
<hrw> but you have 'binutils' not '2.20.51'
<zumbi> well, I'll have a look
<hrw> I have a patch
<zumbi> oh! great, then tell me how to fetch it :)
<hrw> moment
<hrw> zumbi: http://paste.ubuntu.com/444686/
<zumbi> hrw: Committed revision 7278
<hrw> http://paste.ubuntu.com/444700/ adds help for --verbose
<cwillu_at_work> rcn-ee, not sure if this is a kernel problem or not yet, but I'm getting unexpected oom failures in 2.6.34-l0
<zumbi> hrw: thanks, that is already done
<zumbi> hrw: i was thinking on how to better implement verbose
<cwillu_at_work> http://paste.pocoo.org/show/221945/
<zumbi> hrw: either by a new logging funcion or by embedding commands in a variable. I think I'll go for the first one (more clean)
<cwillu_at_work> http://paste.pocoo.org/show/221947/ rather
<cwillu_at_work> [84303.868164] Normal free:102232kB min:2036kB low:2544kB high:3052kB active_anon:9788kB inactive_anon:30968kB active_file:0kB inactive_file:72kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:260096kB mlocked:0kB dirty:0kB writeback:0kB mapped:156kB shmem:840kB slab_reclaimable:2328kB slab_unreclaimable:87676kB kernel_stack:1336kB pagetables:964kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
<hrw> ok, need to go now
<cwillu_at_work> seems like I should have lots and lots of free memory (that's the pre-killing numbers)
<hrw> have a nice weekend everyone
<zumbi> hrw: good weekend!
<cwillu_at_work> rcn-ee, also, would it be possible to get an alternate version with that new defragmentation code enabled?  I'd like to see if that improves things on a long-running beagle
<cwillu_at_work> I'll get you the appropriate config items if you could do that
<zumbi> hrw|gone: just have released 0.0.3
<cwillu_at_work> !info libpixman
<ubot2> cwillu_at_work: Package libpixman does not exist in lucid
<cwillu_at_work> !info libpixman-1
<ubot2> cwillu_at_work: Package libpixman-1 does not exist in lucid
<cwillu_at_work> !info libpixman-1-0
<ubot2> cwillu_at_work: libpixman-1-0 (source: pixman): pixel-manipulation library for X and cairo. In component main, is optional. Version 0.16.4-1ubuntu2 (lucid), package size 230 kB, installed size 508 kB
<cwillu_at_work> !info libpixman-1-0 maverick
<ubot2> cwillu_at_work: 'maverick' is not a valid distribution: hardy, jaunty, karmic, lucid
<in-game> Hello all
<cwillu_at_work> eat the newcomer
<in-game> lol
<in-game> yeah got a netwalker
<in-game> wondering how to clock my arm cpu
<tmzt> netwalker?
<in-game> yeah sharp netwalker
<in-game> running ubuntu 9.10
<tmzt> that's the new zaurus cxxx?
<in-game> runnng xfce instead of default gnome
<tmzt> with snapdragon?
<in-game> yups somewhat yeah
<in-game> bit bigger thouigh
<in-game> some like the UMID
<in-game> hmm
<in-game> let nme check
<in-game> Freescale i.MX515 800 mhz
<tmzt> ah, that's the older one then
<in-game> yep
<in-game> ios there a tool to clock it?
<tmzt> what do you mean?
<in-game> well to let it ruin on say 900 mhz
<in-game> like the zaurus overclock tool
<in-game> and any idea if the arm ubuntu gets the upgrade to the 10.x ?
<in-game> meaning: now it is 9.10
<tmzt> in-game: that cpu/soc is one of the ones getting supported I think
#ubuntu-arm 2010-06-05
<_Kamondelious_> **tumbleweed**
<cwillu> _Kamondelious_, it's saturday, what did you expect?
<cwillu> everybody is actually playing with their arm-based devices today
<rcn-ee_lpt> cwillu, saw your irc message, did you have any luck finding that oom defrag config option?
<cwillu> sec
<cwillu> not specifically for oom
<rcn-ee_lpt> no rush. ;)
<cwillu> it's a case of "Carey saw a random thing added in the latest kernel, and must have it" :p
<cwillu> memory compaction
<rcn-ee_lpt> well... if linus does do a rc2 today, it could be avaiable in the next rc2 build.. ;)
<cwillu> CONFIG_COMPACTION
<cwillu> relies on CONFIG_MIGRATION I believe, although I guess that'd get set automatically
<cwillu> also, did you see my note about 2.6.34-l0?
<cwillu> I respun my image against 2.6.34-l1 before I left work yesterday, logging in right now to see if it's suffering the same fate
<cwillu> and it appears that it might
<rcn-ee_lpt> the oom-killer thing? http://paste.pocoo.org/show/221947/
<cwillu> yep
<cwillu> I'm seeing a very slow response over ssh, about a minute to get a login prompt, and 15 seconds or so to verify a password
<cwillu> I've got a serial terminal hooked to it, which seems a bit more responsive
<rcn-ee_lpt> very strange, i haven't hit that yet... how much are you loading your systems?
<cwillu> sec, pulling up top over the serial link
<cwillu> it's just firefox with a backend server, streaming data to the page
<cwillu> what I see is basically a swapstorm (noting that I don't have any swap configured on the system)
<rcn-ee_lpt> so then it shouldn't be too much..
<cwillu> there shouldn't be any io load to speak of
<cwillu> okay, it's definitely an issue under l1 as well
<rcn-ee_lpt> okay, that's the one difference i do have swap setup on my test ones..
<cwillu> top just came up finally, I'm seeing the same sort of symptoms
<cwillu> also, it doesn't show up for the first hour or so
<cwillu> I've got high wait% showing in top, with btrfs-endio-0 and kswapd0 showing
<rcn-ee_lpt> and looking at irc, it shows there is memory left, but it's going nutz..
<cwillu> sorry, looking at irc?
<cwillu> looking at yours you mean?
<rcn-ee_lpt> sorry irc log from yesterday.. ;)   i'll setup a quick btrfs and no swap rig, and let it run for an hour to see what happens..
<cwillu> 6.85 load average :)
<cwillu> oh, here's something
<cwillu> Cpu(s): 10.1%us, 22.3%sy,  0.0%ni,  0.0%id, 67.3%wa,  0.0%hi,  0.3%si,  0.0%st
<rcn-ee_lpt> that's way more..
<cwillu> top - 15:17:25 up 21:08,  2 users,  load average: 6.95, 6.19, 5.06
<cwillu> Mem:    237068k total,   168120k used,    68948k free,       28k buffers
<cwillu> Swap:        0k total,        0k used,        0k free,    22116k cached
<cwillu> _lots_ of free memory
<rcn-ee_lpt> yet it's stuck waiting for something..
#ubuntu-arm 2010-06-06
<saeed> Hi Canonicals, any idea what is the linaro about? will that project maintain a kernel of its own?
<DanaG> My big gripe with ARM stuff: no open graphics.
<DanaG> If AMD would make an ARM + Radeon thing, that would be pure win.
<cwillu> a royalty free distribution with sgx would probably make sgx defacto redistributable
<jufer> where i can get the rootstock source lists ?
<jufer> where i can get the rootstock source lists ?
#ubuntu-arm 2011-05-30
<jthomas_> Hello all
<jthomas_> I am facing some problems when compiling instrumented arm assembly on ubuntu-arm
<jthomas_> I am trying to add some instrumentation code that does a simple printf
<jthomas_> but for some reason, I am getting a segmentation fault
<jthomas_> the interesting fact is that
<jthomas_> since printf requires the arguments to be put into r0
<jthomas_> for whichever basic block that does not modify r0, the instrumentation works
<jthomas_> but when I instrument any basic block that modifies r0, either storing or loading the value of r0, then I get a segmentation fault
<jthomas_> any idea as to why this is happening
<jthomas_> any help would be great
<jthomas_> any help?
<ppisati> morning
<zul> ogra is there any documentation about putting ubuntu arm on a toshiba ac100?
<ogra_> zul, yes
<ogra_> zul, you got one ?!?
<zul> ogra_: yep, christmas came early
<ogra_> awesome
<ogra_> zul, https://launchpad.net/~ac100/+archive/ppa follow the link to my people account
<zul> android sucks as an os ;)
<ogra_> yeah
<ogra_> currentl installation means to jump thought some hoops
<lilstevie> zul: android serves a purpose
<lilstevie> just not on tablet devices
<ogra_> i'm working on a proper installer that should be ready within this week
<ogra_> lilstevie, i would use it on a tablet ... but on nothing with a keyboard
<lilstevie> ogra_: it is ok on the galaxy tab
<ogra_> yeah
<lilstevie> but ubuntu is still better
<ogra_> :)
<ogra_> zul, start with http://developer.download.nvidia.com/tegra/files/os/tegra_froyo_20110207.run.gz it contains the nvflash utiliy you will need to flash the new kernel to the device
<lilstevie> the easiest way to explain how android feels on the tab is like having a Ferrari that is locked out of 4th gear +
<zul> ogra_: cool ll poke around
<zul> and ask if i need help
<ogra_> zul, http://ac100.gudinna.com/README/ has outdated instructions for older images ... the commands are stil the same though
<lilstevie> it  works just not very very
<gildean> zul: and if you want 3d, suspend and sound, you can follow my guide for .32 http://ac100.tunk.org/wiki/phh
<ndec> ogra_: hi. i installed natty from the minimal FS. what's the meta package to install the full desktop? ubuntu-netbook or ubuntu-desktop?
<zul> gildean: meh
<gildean> but it has a bunch of nvidia-binaries and crap like that
<ogra_> ndec, up to oneiric its ubuntu-netbook
<ogra_> with this release we'll switch to -desktop on arm too
<ndec> ogra_: thx
<zul> im more interested in running other things other that desktop on it
<ogra_> gildean, zul surely wants to work with things like lxc
<ogra_> so he should use a sane kernel
<gildean> ogra_: yeah, just mentioning :)
<zul> ogra_: and normal server work loads ;)
<ogra_> yeah
<ndec> ogra_: so on natty ubuntu-netbook should install the unity2D?
<ogra_> zul, go for my .37 image then, if you run into issues, just ping ... same goes for the kernel, if you are mising options or patches, tell me
<ogra_> ndec, both actually
<zul> will do
<ogra_> unity as well as unity-2d
<ogra_> defaulting to 2d
<ndec> ogra_: ok.. 1gb is being installed ;-)
<lilstevie> I really wish I could crack the 3D accel nut on the tab
<lilstevie> unity would be win on the tab
<ogra_> lilstevie, use unity-2d as we do in all arm images ?
<lilstevie> ogra_: it fails
<ogra_> and florence so you have an android like kbd
<ogra_> it fails ?
<ogra_> bug number ?
<ogra_> :)
<lilstevie> ogra_: not bug number
<lilstevie> unless you want my own trac :p
<lilstevie> I have zero accel
<lilstevie> even 2D
<ogra_> and ?
<lilstevie> gnome-classic is the only thing that doesn't put too much load on the cpu
<ogra_> my ac100 does only framebuffer too
<ogra_> but unity-2d is snappier than the 3D one on my intel laptop
<lilstevie> your ac100 is also dualcore :)
<ogra_> true
<ogra_> but the cores are not actually used for graphics stuff
<lilstevie> my software framebuffer is a bit fail
<lilstevie> the SGX540 is meant to software accelerate without the need for the userland blobs
<lilstevie> it is a bug my end though
<lilstevie> the 2.6.32 sourcedrop from samsung had the most ugly unoptimized code
<sveinse> I'm sitting here upgrading our target to natty, and I've hit this --sysroot thing. How can I compile Qt (not from deb source) with xdeb ? E.g. are there any tutorials of how to build with xdeb out there?
<sveinse> uhm, *cross compile Qt
<sveinse> Dodgy network atm?
<Neko> if anyone's answering sveinse's questions, I'd also like to know how to get xdeb to work without actually packaging things as source packages...
<Neko> is there something like a cross-debhelper?
<Neko> hrw, nudge?
<hallyn> ogra_: my update fetched your new kernel, buti'm not booting from it.  how do i update it?  flash-kernel with options, or some different command?
<hallyn> went ahead an dared to flash-kernel
<hallyn> zul: how's your's treating you?
<hallyn> zul: yay, i have a running container
<zul> hallyn: missing some usb cables
<hallyn> doh
<hallyn> well lxc is working for me, with the -2 kernel.  will put off heavier testing till tomorrow
<hallyn> (since today is holiday :)
<stgraber> hallyn: now we just need some ARM machines with fast I/Os to actually do something useful in containers ;)
<zul> i actually need to see if openstack works first
<hallyn> zul: jikes, good luck.  gonna use an external hd for that?
<zul> nfs probably
<hallyn> stgraber: that would make it easier to test a range of uses, yes :)
<hallyn> zul: ah
<hallyn> maybe i'll install lvm on a big usb stick so i can do some quick cloning :)
<zul> bbl need to reboot to hopefully fix this freaking ipod
#ubuntu-arm 2011-05-31
<sveinse> I'm bumping my question from yesterday: Are there any descriptions available how to cross compile non-debianized source software (I'm building Qt) with xdeb?
<hrw> xdeb is to build debianized sources
<sveinse> hrw, So since the ubuntu/linaro toolchain don't support sysroot, there are no way of building non-debianized sources?
<sveinse> (Of course you know in advance the build deps for the sources)
<hrw> normal?
<hrw> ./configure --host=arm-linux-gnueabi;make kind?
<sveinse> I wonder if that works for Qt?
<sveinse> Qt does support cross compilation. The only problem are target armel library dependencies. And without sysroot, the rpath in these libs will be off
<hrw> sveinse: during oneiric cycle I hope that we will finally get multiarched headers so development will be much easier then is now
<sveinse> ok
<sveinse> to make some progress: If I want to cross build qt4-x11 from deb source, how do I do that?
<sveinse> with xdeb that is
<hrw> xdeb -a armel --prefer-apt --only-explicit qt4-x11
<hrw> I would try that
<sveinse> thanks, I'll do that
<hrw> cooloney: hi
<cooloney> hrw: hi
<ppisati> GrueMaster: when you have time - http://people.canonical.com/~ppisati/imx51/linux-image-2.6.31-608-imx51_2.6.31-608.26_armel.deb
<ppisati> GrueMaster: is another kernel with some mor CVEs fix, if you can boot test it
<ppisati> GrueMaster: it would be nice, so i can pull req
<GrueMaster> ppisati: Didn't I test this on Friday?
<ppisati> GrueMaster: new one
<ppisati> GrueMaster: more cve fix etcetc
<ppisati> GrueMaster: version didn't change since i didn't close it
<ppisati> GrueMaster: and you will get more and more :)
<GrueMaster> sigh.  Ok.
<ppisati> GrueMaster: just give me a "it boots" check
<GrueMaster> Yep.
<hrw> did someone know a tool which will give me filesystem with just selected packages fetched (with deps) and unpacked?
<GrueMaster> You mean like rootstock?
<hrw> forgot about that one...
<GrueMaster> ppisati: In the future, when you post these kernels, please increment some number so that I hve a way of knowing which one is installed.  Thanks.
<ppisati> GrueMaster: uhm, i don't know if i can without closing the release
<ppisati> GrueMaster: i'll check
<hrw> rootstock auto assume armel?
<GrueMaster> I know it is possible.  Others send me test kernels with bug ids in the version number all the time.
<hrw> and is also wrong tool. I need fs with 'libc6-dev libc6-dbg' and dependencies - no rootfs stuff needed in it
<ppisati> GrueMaster: ok, i'll put some custom "grue1, grue2, grue3, etcetc" so you can distinguish it
<GrueMaster> hrw: I have no other suggestions.   Sorry.
<hrw> no problem
<ppisati> hrw: but do you need a "release", or do you want some total custom image?
<GrueMaster> ppisati: boots.  No errors.
<ppisati> GrueMaster: k, pull is coming
 * GrueMaster wanders off for morning shower & coffee.
<hrw> total custom fs
<ppisati> hrw: i see, then i don't know any tool...
<ppisati> hrw: i mean, deboostrap still install a minimal system
<ppisati> hrw: if minimal + custom is ok, deboostrap
<ppisati> hrw: but i think (but i could be wrong) that rootstock exploits deboostrap
<hrw> it is using it
<ZeZu> On natty/omap4 if i build something w/ g++ -marm and try to change a pages attributes,  it fails (where-as it does not with the default build, read: thumb) ... thumb interop is not disabled so i'm confused as to why,  anyone have any thoughts on the subject before I dig it further / file bug report ?
<ZeZu> Data I pass looks valid :  Attempting to change atribs of 2 pages (PageSize: 4096) @ 0x1164000
#ubuntu-arm 2011-06-01
<nemoz> Hello, I would like to know what wifi usb devices people have used successfully on the beagleboard-xm with Ubuntu?
<nemoz> ARM Cortex-A8
<ogra_> plenty
<tonu> yes, plenty
<tonu> it does not matter is beagleboard or not. Anything supported on linux works
<ogra_> right
<ogra_> well, at least anything supported on ubuntu :)
<ogra_> minus ndiswrapper cards indeed :)
<nemoz> So it should be pretty safe buying any of the usual wifi dongles?
<ogra_> right
<ogra_> you will have the same issues you have on other arches (if you have issues)
<tonu> I used ALFA ones with RT8187 chipset
<nemoz> I was reading things about wifi devices not being recognised correctly by the device so I thought I would make certain
<tonu> also some others but ALFA is something I always can recommend
<hrw> I use tplink with ath9k_htc module
<nemoz> Just plug and go? Or any extra hoops
<hrw> just
<nemoz> actually there is an extra constraint, are the devices capable of creating and joining an ad-hoc network?
 * ogra_ never tried adhoc on omap
<hrw> I have AP under desk
<zul> ogra_: ping
<ogra_> zul, yeppers
<zul> ogra_: hi, so im suppose to press control-esc when the machine is powering on with the usb and the card plugged in right?
<ogra_> no card needed
<ogra_> but i wont do harm either i guess
<zul> ok so why is the usb needed again?
<ogra_> the LEDs should light up, the screen should stay black
<ogra_> the usb is the connection you flash the boot partitions on the internal MMC with
<ogra_> from the host computer using nvflash
 * ogra_ needs to reboot, brb
<zul> ok..
<ogra_> re
<zul> ogra_:  hey and where do you extract the linux4tegra tarball to?
<ogra_> your PC the USb is connected to
<zul> just anywhere on that pc?
<ogra_> yes
<lool> ogra_: Hey, while updating the list of images in a local mirror, some questions popped up; is there still a wiki page with the daily images which you folks care about?
<lool> I've noticed that there is an ubuntu-netbook project where the dailies aren't under ports: http://cdimage.ubuntu.com/ubuntu-netbook/ also I thought netbook was replaced by regular "ubuntu" (desktop)
<ogra_> it wasnt replaced yet, thats A2
<lool> so that image is going away, right?
<ogra_> there should be a release manifest wikipage page, not sure its there for oneiric yet
<ogra_> yes, ubuntu-netbook-preinstalled will just become ubuntu-preinstalled
<zul> ogra_: ok duh...i got it now
<zul> how long is flashing suppose to take usually?
<ogra_> a few seconds
<ppisati> guys, what's the status of PM on omap4?
<zul> ogra_:  ok its working now thanks for the help
<brendand> hi, i'm trying to boot an omap4 natty image on a pandaboard
<brendand> my SD card has 2 partitions, i 74MB and 1 2.6GB
<StevenK> ~,.
<StevenK> ~>
<ogra_> Daviey, http://people.canonical.com/~ogra/tegra/2.6.37/README first shot of the installer ... should make your life easier
<ogra_> NCommander, ^^ in case you want to play ^^^^
<Daviey> ogra_: groovy.. what boot img should i use?
<ogra_> http://people.canonical.com/~ogra/tegra/2.6.37/
<ogra_> download the files there
<zul> sweeeet
<ogra_> if it works it should make life easier ... i only tested it locally yet
<ogra_> (the ac100 models all differ a bit)
<ogra_> persia, in case yu are still intrested in setting up a wikipage for the ac100, http://people.canonical.com/~ogra/tegra/2.6.37/README should be a first start
<Daviey> standard platform++
<ogra_> heh
<persia> ogra_, Nice improvement.  It's worth mentioning that the 8GB model should have stuff on /dev/mmcblk0p7 and the 16GB model on /dev/mmcblk0p12 (and one needs to appropriately adjust the configuration).  I'm mostly waiting for you to confirm that it no longer requires a PPA and has a real image.
<ogra_> persia, no, the installer hides all that details
<persia> I'm not sure it's a good idea to have things automatically install to the "first partition", as this may not have the right amount of space.
<ogra_> ??
<persia> Oh, nevermind.  I read README incorrectly.
<persia> It takes the image *from* the first partition.
<persia> How are you detecting the appropriate target partition?  Just finding the largest?
<ogra_> yeah
<ogra_> yep
 * ogra_ will package all that stuff for oneiric, natty is my testbed atm
<ogra_> then you can look at the code :)
 * persia still thinks that the regular installers should be used, and that the speed issue should be solved generally, but this is a separate issue.
 * persia is extra uncomfortable about having unreviewable installation code, and hugs the old version of the SD image that allows one to debootstrap
<ogra_> well, i'm just to tired to make a branch and upload atm
<persia> Now is not a good time for you to upload :)
<ogra_> its just three initramfs files
<ogra_> and one script that adds an overlay to the initrd
<ScottK> rsalveti: Looking at Bug #791250 which you filed (I believe with the aid of a script).  It says "This log snippet might be of interest, since it triggered the matcher 'Purging chroot-autobuild'".  Wouldn't all build failures trigger on that?
<ubot2> Launchpad bug 791250 in kdegames "kdegames version 4:4.6.3-1ubuntu1 failed to build on armel" [High,Triaged] https://launchpad.net/bugs/791250
<persia> I don't really like that fix: there are several GL-capable video devices available for armel devices (note that this class of fix is pervasive, unfortunately, so this specific example isn't in any more need of fixing than anything else)
<rsalveti> ScottK: there can also be "Source-dependencies not satisfied" for broken dependencies
<rsalveti> and yes, it's a script
<rsalveti> lp:svammel
<ScottK> True.
<ScottK> I guess it seems like a pretty broad brush.
<ScottK> We don't really need a bug for every build failure.
<ScottK> When I'm curious about build failures I look at http://qa.ubuntuwire.com/ftbfs/ and not the bug tracker.
<ogra_> ++
<rsalveti> ScottK: we're tracking build failures with bug because the it's easier to go over the bug list at launchpad
<rsalveti> and use that at the arm porting queue
<rsalveti> and also put more folks involved on this
<persia> In the case where the build failure is particularly interesting, and someone has an idea to address the class of problem, bugs can be nice, but that's a special case.
<ScottK> rsalveti: Easier for who?  It's more stuff to mess with for us.
<persia> rsalveti, Please don't.  It annoys other developers.
<rsalveti> the script can also close the bugs once a newer package version is uploaded without build failures
<ScottK> Seems like pointless paperwork.
<ogra_> super pointelss paperwork
<ogra_> and annoying too
<rsalveti> I don't think it's pointeless
<ogra_> since now everyone is forced into that paperwork ... else we end up with tons of open bugs
<rsalveti> it helped identifying easily the issues we had with binutils and ld
<ogra_> the build logs didnt suffice ?
<rsalveti> and I really prefer a bug to be filled than just let it at the ftbfs list
<rsalveti> well, you need to go over all logs
<rsalveti> bugs you can trace status
<persia> rsalveti, The issue is that FTBFS is transient.  We did an automated build-failure-bug-report thing before (back in Dapper), and stopped because by the time people looked at many of the bugs, they had been addressed by some other upload addressing the transient issue.
<rsalveti> who is taking care of that
<rsalveti> details about what happened and such
<persia> Considering the number of packages that get updated for reasons having nothing to do with build failures, often in ways that affect them (new upstream versions, Debian syncs, etc.), it's especially pointless this early in the cycle.
<rsalveti> persia: that's why the script can also close bugs
<ScottK> rsalveti: I think it may be different near release, but in this stage of the cycle, it's just a lot of churn.
<ScottK> rsalveti: All of which doesn't keep people's inbox from getting clogged.
<persia> rsalveti, Why not just add status tracking to the FTBFS page, if that's what you need.
<rsalveti> persia: why not bugs?
<rsalveti> what's the problem with this?
<rsalveti> noise?
<ogra_> yes
<rsalveti> come on, it's a good thing to track the issues there
<ScottK> Low signal to noise ration.
<ScottK> rsalveti: We disagree.
<ogra_> noise, mail, harder to use interface, slowness
<rsalveti> if we're maintaining the bug list
<persia> Not just noise, but noise that often has zero value.  Noise with value can be tolerated.
<rsalveti> if you point me that the script is really creating just noise and no value, then it's ok
<ogra_> but most annoying as i said above, i need to invest extra time into weeding through LP if i gave back a package
<rsalveti> for now it's just people complaining because of noise
<ScottK> rsalveti: If it files a bug for a random FTBFS, it's noise.
<ogra_> (or even fixed the buildfailure)
<persia> rsalveti, We're so pointing.  Can you demonstrate some value?  Do you need anything other than status?
<rsalveti> persia: just check the bugs that were filled and changed status
<persia> It would be fairly easy to have the FTBFS tracker export some JSON, so you could parse it more easily (not that it's that hard to parse in the current state)
<rsalveti> for example, there are a lot of bugs for the gles porting for Qt
<persia> rsalveti, So, what value does this bring over the existing FTBFS tracker?
<Daviey> ogra_: Ah nice!  It works directly from the tarball
<rsalveti> it's a good thing to have bugs for that
<ogra_> Daviey, does it work for you ?
<rsalveti> persia: it's just a tracking tool
<rsalveti> that's already there
<rsalveti> and we can easily use
<rsalveti> if you want to improve the ftbfs to track the status I'd be fine with it
<persia> rsalveti, I disagree, but that's because I think that the assumption that armel == GLES is fundamentally flawed, and have hardware that you are breaking with the "transition"
<Daviey> ogra_: Don't know yet... i copied the contents of the tgz and got "No tarball found".... so now putting the tarball in place :)
<ogra_> rsalveti, if we can get around drowning in pointless bugs thorough that
<ScottK> rsalveti: Most of the tasks on the Qt GLES bug were added manually.  That one is a bit of an exception.
<ScottK> That was a case of trying to coordinate effecting deliberate change.
<ScottK> These auto bugs are completely different.
<ogra_> Daviey, heh, damned, READMEs dont allow <blink> :)
<rsalveti> well, I guess I can only put some more manual work before actually filling the bugs
<rsalveti> trying to identify it's valuable or not
<persia> ogra_, You could have written it in HTML: you are asking people to pull over HTTP after all...
<ScottK> rsalveti: Do you think filing a bug for every compiler warning in a build log is a good idea?
<ogra_> persia, yes, as well as i could have uploaded my code to a branch :P
<Daviey> ogra_: heh, i am a typical man... try first, read the instructions afterwards :(
<persia> rsalveti, That would have *huge* value, if you did.  Bugs with notes about *why* something FTBFS, or other useful information are very useful.
<ScottK> This is basically the same kind of noise only a lesser scale.
<rsalveti> so what you're saying is that is basically useless to track ftbfs in bugs in general?
<ScottK> rsalveti: I agree with persia.  If the bug includes some human pre-processing to indicate what went wrong or the class of fix, then it could have value.
<rsalveti> ok, that's something we can improve
<persia> No.  It's useless to have automatically-filed bugs with no additional information.
<ScottK> rsalveti: It's useless to track them in the bug tracker.  We have other tools for htat.
<Daviey> packages in Main, or ones a particualr team are going to work on for certain has value in having bugs for FTBFS IMO.
<ogra_> rsalveti, i usually open a bug if a first poke on a package didnt help, but i would never do it automatically
<ScottK> Daviey: I disagree.
<persia> Daviey, How do components affect this?  I don't see any relation.
<rsalveti> I also don't like the idea of just going over and filling without any kind of filter
<rsalveti> that's why I believe that if this is fixed, it'll actually bring value
<rsalveti> and not just noise
<ScottK> Unless there's more information available than what can be found in the build log, it doesn't help.
<Daviey> ScottK: I know you disagree.. we'll have to agree to differ :)
<Daviey> persia: In so far as Canonical /has/ to care about supporting Main, and if a particualr team is committed to certain packages it helps tracking.
<persia> rsalveti, What sort of filter do you imagine?  For me, the threshold is a filter that requires human intelligence: if we can figure it out in an automated manner, I'd rather have a realtime reporting system.
<rsalveti> persia: manual work before actually filling it
<rsalveti> checking at least if it looks like a bug
<Daviey> ogra_: 30 mins! bah.
<rsalveti> currently the script just goes and fill everything
<rsalveti> doesn't even ask if you want to check it first
<ogra_> Daviey, really depends on your devices ... 30 is worst case
<persia> rsalveti, If you did that, I'd be arguing that you were doing a good thing by filing the bugs :)
<rsalveti> sure, that's something I can do
<persia> Cool!
<Daviey> persia: A random package in universe that has never been touched in Ubuntu.. where it is most unlikely that any ubuntu contributor is going to fix, would just be a noise raising a bug.
<rsalveti> just tried today as slangasek was doing for past cycle
<persia> Daviey, And how does this differ from a random package in main that hasn't been re-uploaded since the Debian import in Warty?  I agree with the thoughts behind your statement, just don't believe it has any relation to components.
<ScottK> rsalveti: And if (thinking down the road) you had tags for classes of FTBFS bugs then that would be super useful as if someone has fixed (as an example) a linker failure in a cmake based package, fixing the second one of those is pretty easy.
<Daviey> If we rely on using a FTBFS tracker for packages we really care about... we need somewhere to link branches, diffs and discussion.. so the FTBFS tracker needs enriching. Would also be nice to be able to assign it to someone.. And track as Work Items.  Suddenly, the FTBFS tracker has re-implemented launchpad. :)
<persia> (nor that it is specific to Canonical: same applies for any of the other firms that sponsor developers to do stuff)
<persia> Daviey, Talk to the LP team: there is work *within* LP to integrate the FTBFS tracker.  That doesn't mean we should be using bugs.
<rsalveti> ScottK: yup, also thought about that
<ScottK> Daviey: I typically don't do any of those things with FTBFS, I just fix stuff.
<rsalveti> having specific tags can for sure help a lot
<Daviey> persia: I agree.. the fact is, I have raised FTBFS bugs for packages the server team care about.. Other teams can, or cannot do the same if they like. :)
<ScottK> rsalveti: You might also talk to dholbach about integrating that thought with the work he's doing on helping getting new developers involved.
<Daviey> ScottK: Well tracking work that needs to happen in the cycle helps to be able to check we are getting stuff done, and not duplicating effort.
<persia> Daviey, Implicit in that action is the presumption that nobody external to that team is likely to do anything.  I think such a presumption is actively harmful.
<Daviey> persia: hmm, no
<rsalveti> ScottK: yeah, will talk with him
<Daviey> persia: you are missundertanding me
<ScottK> Daviey: you don't need a bug to have a branch, so that's off your list.
<ScottK> Work items are for features, not bug fixing.  So that's out.
<Daviey> Having a bug against a package is being MORE open so other teams, within or external to Canonical can see the progress of the issue being resolved.
<ScottK> So except for assignment and discussion, I think the FTBFS page is fine and what fraction of FTBFS fixes need any of that?
<Daviey> If it's just remembered in my or ScottK's head... how can others see that it is being noticed and worked on?
<Daviey> directed to persia ^^
<ogra_> Daviey, but we have a list where it shows up already
<ogra_> why do we need another one ?
<Daviey> ogra_: I haz ubiquity!
<persia> Daviey, That's why we have an FTBFS tracker, and why the LP team is working to improve the available overviews of FTBFS status *within* launchpad.  It needs to be available, but having bugs is needlessly duplicative, unless there is useful value added in the bug.
<ogra_> it even categorizes packages by tasks
<ogra_> Daviey, awesome !
<ScottK> Daviey: Based on your logic, instead of MoM we should have it autofile bugs.
<persia> Well, by packagesets, so that groups (like the server developers) can easily see which packages interest them.
<Daviey> persia: but tracking work that needs to happen in the sub-cycle makes it easier aswell.
<persia> ScottK, We used to do that too :)
<ScottK> persia: I know.
<persia> Daviey, Yes, but the defect management system is the wrong way to "track work".
<Daviey> I do /not/ see the harm it has in having tracking bugs via this method util we have something better.
<Daviey> persia: FTBFS is a defect, no?
<ScottK> We already have something better.
<persia> No, because it's transient: see above.
<Daviey> we do not.
<Daviey> As i said at the start of this... i'm not trying to influence you to change what you think is better or not.
<persia> If you need WIs, the FTBFS tracker should be extended to allow folks to have stuff show up as WIs.  This is unrelated to polluting the bug tracker.
<ScottK> Daviey: The only thing we lack that a bug gives is the ability to assign someone work.  If someone is going to assign someone to fix a FTBFS then in that rare instance said someone can file a bug.
<Daviey> last cycle, when the server team tracked FTBFS issues via bugs - we got MORE community contributions than we had before we had the bugs.
<ScottK> That's far more efficient than N developers subscribed to bugs dealing with stuff in their inbox.
<persia> And assignment inherently assures that nobody other than the assignee will do the work.
<Daviey> Why do you both feel so strongly about this?
<persia> Daviey, Is this because of the bugs, or because of a lack of socialising potential server contributors to the existing tools?
<ScottK> Because I get so much bugmail already that I really dislike seeing even more of it autogenerated and thrown into my inbox for no point.
<Daviey> persia: Well probably both...
<persia> Because we did it before, and we drowned, and we turned off the automated systems, and it's *really* frustrating to encounter the same issue again, with certain forknowledge that it fails to scale.
<Daviey> ScottK: Well thanks to LP's latest bug mail filtering, that should be easier.
<NCommander> Daviey: LP's bug filtering is still very limited
<ScottK> Daviey: Not really.  I still don't seem to be able to unsubscribe from bugs as an individual without unsubscribing the entire team.
<NCommander> +1 ScottK
<persia> Daviey, No, because that makes everyone else do work.  Is the total sum of that work worth the benefit?  How does it compare to the total volume of work required to extend the existing tracker to meet your needs?
<ScottK> So the improvements turn out not to help much at all with the general use case I have.
<Daviey> Okay.. The only complaint i had last time was from ScottK.  If there were a handful of complaints, then i'd be a little more understanding.
<ScottK> Daviey: I think persia is referring to something general.
<NCommander> Daviey: for FTBFS that require cooridination or input, bugs are opened and generally go a long way. For the five minute fix type, not so much
<Daviey> Well the fact remains, it got results last time.
<persia> I am.  Specifics are relatively uninteresting to me.  I actively avoid any mail originating from launchpad anyway.
<micahg> ScottK: unsubscribing as an individual I think was just fixed
<persia> Daviey, Sure, but I stand by my argument that this is due to not exposing the common resources used by Ubuntu Developers to nascent members of your team combined with a poor definition of the current "server" packageset, making the current report insufficiently interesting to your team.  Both of these need be sorted *anyway*.
<Daviey> agreed
<persia> Daviey, And, please, if you do need WI tracking for FTBFS, at least file a bug against the FTBFS tracker and the WI tracker (two tasks).  You may or may not have time to actually enable these features, but the above IRC log is not a good way to capture the requirements (and the primary developers of both of those tools are not in this channel)
<Daviey> persia: ok
<Daviey> ScottK: Do you filter your bug mail on X-Launchpad-Bug-Tags ?
<persia> Thank!
<ScottK> micahg: Just as in when?  I tried a couple of days ago and couldn't.
<ScottK> Daviey: No.  I have a mailbox that it all goes into.
<micahg> ScottK: well, I'm in the beta test group, so I think I've had the feature for a couple weeks
<Daviey> ScottK: crikey.
<persia> micahg, Wasn't that allowing individuals to unsubscribe from specific bugs where they are subscribed to the package?  This is different from being a member of a team that is subscribed to a bug.
<micahg> ScottK: http://blog.launchpad.net/bug-tracking/coming-soon-improved-bug-subscriptions, it's coming soon :)
<micahg> persia: as I understood it, it was both
<persia> Hrm.  I hope so.
<ScottK> micahg: When I tried it a couple of days ago I could unsubscribe the team from the bug, but not just myself.
<ScottK> Daviey: I've experimented with more detailed sorting, but find all in one mailbox and use local search tools is more efficient for me than trying to predefine how I want stuff sorted out.
<micahg> persia: ScottK: right, so it's just the beta team ATM, it's the mute bug feature that does it, it's not subscription based
<ScottK> Ah.  OK.
<ScottK> There's a lot of release team bugmail I'll stop seeing soon after that lands then.
<micahg> it covers both use cases mentioned (subscribed to package/product and team mail that's not going to a ML)
#ubuntu-arm 2011-06-02
<ogra_> persia, your dnybook, is that a 16G model ?
<ogra_> *dyna
<NCommander> ogra_: this won't give us working sound on ac100, would it?
<ogra_> NCommander, well
<ogra_> NCommander, we have a codec driver ... we have working devices in pulse ... we just dont have anyone who has a clue how to wire up the sound devices in the driver internally
<NCommander> ogra_: i.e., needs kernel hacking on an ALSA level, right?
<ogra_> yes
<NCommander> ogra_: what's partition 6? (I've already flashed my device several times)
<ogra_> NCommander, LNX
<NCommander> ogra_: handy, also, don't I have to reflash the partition map?
<ogra_> no, just part 6
<ogra_> seems Daviey already ran into the first issue :(
<NCommander> ogra_: great. Last quesiton, your instructions seem to suggest that I need to use a USB key, or can I just use an SD card?
<ogra_> what do you want to achieve ? an internal install or one to external media ?
<ogra_> for internal it doesnt matter where you put the tarball, it will find it on SD as well as USB
<ogra_> for external you just need to make sure to put the tarball onto the media you dont want to install to :)
<ogra_> (and boot with both plugged in)
<NCommander> ah
<NCommander> Daviey: were you able to get your AC100 to work with the Android flashing tools?
<NCommander> ogra_: your installer crashed :-/
<persia> ogra_: Yeah.  Mine is 16G
 * NCommander has had no luck with ogra_'s installer
<NCommander> it appears /var doesn't get mounted
<NCommander> or something, as there are a lot of errors to that before it goes belly up
<persia>  /var shouldn't be on a separate partition.
<persia> (unless this is the overlay hack)
<persia> Do you have a promt of any sort?
<ZeZu> I can't connect an app to the local xserver from ssh on natty,  anyone know why?
<ogra_> persia, i'm looking for a /proc/partitions dump from such a dynabook
<damo22> What is the most powerful android phone on the market?
<ogra_> probably something yu should ask in an android channel ?
<damo22> (that uses an ARM cpu)
<damo22> okay sorry wrong channel..., does 11.04 run on arm? as far as i can see, rootstock builds karmic or jaunty images? or do i have an old version?
<dcordes> use >= maverick
<dcordes> for recent htcs
<dcordes> ogra_: the touchscreen rotation problem was solved by cnd
<ogra_> awesome
<ogra_> Daviey, ha ! i found a hack to open a terminal in oem-config
<ogra_> not really helpful since it runs as oem user though
<dcordes> ogra_: it would be helpful to add on screen keyboard in oem-config
<dcordes> the same assistive technology menu that's also in gdm login screen
<ogra_> i think there is a bug open for that
<dcordes> yes but it doesn't receive any attention
<dcordes> all the tablet devices on the market but nobody cares
 * ogra_ would first of all like to see florence integrated
<dcordes> we have onboard
<dcordes> I think it would be nicer to keep onboard and implement florence's auto show/hide features
<dcordes> https://bugs.launchpad.net/ubuntu/+source/oem-config/+bug/626055 oem-config
<ubot2> Ubuntu bug 626055 in smartphone "oem-config: make on-screen keyboard available" [Critical,Confirmed]
<dcordes> https://bugs.launchpad.net/smartphone/+bug/443986
<dcordes> at-spi
<ubot2> Ubuntu bug 443986 in smartphone "RFE: Add option to automatically show and hide onboard" [Undecided,New]
<Daviey> ogra_: ahha!
<Daviey> ogra_: now all i need is a root exploit.
<ogra_> heh
<damo22> does the samsung nexus s work with arm based ubuntu?
<ogra_> i can reproduce the bug here btw
<Daviey> ogra_: Oh?  What do you think it is?
<ogra_> no idea yet, but i used my brandnew ac100 and for internal install it exposes the same issue
<ogra_> i will try an external install now so i can check logs
<damo22> im thinking something like the htc desire z with a keyboard would be nice for an ubuntu install
<Daviey> interesting
<ogra_> i didnt have it on either installs to SD or USB
<dcordes> Daviey: yes
<Daviey> ogra_: If you want me to test anything, give me a shout.
<dcordes> damo22: yes, I don't see a problem
<damo22> what about the keyboard mapping?
<dcordes> damo22: it is google nexus s though. not samsung nexus s
<dcordes> damo22: the keyboard drivers present to userspace as normal keyboards so you can remap just like you would remap any other keyboard inlinux
<ogra_> aha, i think i found the issue with the ac100 installer
<dcordes> ogra_: do you know why http://packages.ubuntu.com/natty/kde/kde-config-qt-graphicssystem is missing in natty arm ?
<ogra_> likely because it depends on some gles stuff that wasnt built
<ogra_> just a guess though
<dcordes> https://bugs.launchpad.net/unity-2d/+bug/782326
<ubot2> Ubuntu bug 782326 in unity-2d "unity-2d: flickers with xf86-video-fbdev on some machines" [Undecided,New]
<ogra_> heh
 * ogra_ never used unity-2d on x86
<dcordes> :
<ogra_> ok, issue verified
 * ogra_ doesnt get why the error pops up during kbd config, its totally unrelated
<ogra_> NCommander, it was just the initramfs getting to big, nothing with /var ... i'll roll a fixed image later today
<ogra_> this 4MB restriction for the initrd is really hard to handle :(
<NCommander> ogra_: could I just get a headless tarball?
<NCommander> :-)
<ogra_> i can roll one, sure, but not right now
<ogra_> oneiric will have both :)
<_persia> NCommander: How badly do you want one?  I've an old one (but it has all the bugs ogra fixed in the past while)
<ogra_> since half the server team has ac100s now
<_persia> (not headless, but doesn't even try to perform an install)
<ogra_> so we need to give them server like images for their netbooks :)
<_persia> Ugh.  No.
 * ogra_ wishes he could find a way to use a bigger initrd than 4M somehow
<_persia> We need to integrate LXC and libvirt so that folks can play.
<ogra_> _persia, already happening ;)
 * ogra_ already had requests to add all the needed config bits to the ac100 kernel ...
<ogra_> -2-ac100 should be fully lxc capable
<_persia> ogra_: There are plenty of non-kernel issues to make it seamless still :)
 * lilstevie is looking forward to seeing what oneiric will bring
<ogra_> _persia, sure, but the platform support is there
<persia> That helps.
<dcordes> ogra_: how would I go about further investigating lack of pacakge
<dcordes> ogra_: is there a way to recommend a package being added in the arm ?
<dcordes> ubuntu ARM :)
<_persia> dcordes: Is the package missing entirely in Ubuntu, or just for armel?
<persia> For the most part we try *not* to do anything architecture-specific (this is not always avoidable)
<dcordes> persia: it is missing just for armel.
<dcordes> persia: http://packages.ubuntu.com/natty/kde/kde-config-qt-graphicssystem
<persia> dcordes, Take a look at the output of `apt-cache showsrc ${PACKAGE} | grep ^Architecture`
<dcordes> persia: ok
<persia> In this case, it's "any", which means that LP should attempt to build it for every architecture.
<persia> Next, check https://launchpad.net/ubuntu/+source/${SRCPACKAGE}/ and dig into the latest upload for your release
<dcordes> kcm-qt-graphicssystem (The binary 'kde-config-qt-graphicssystem' is part of the kcm-qt-graphicssystem package)
<persia> Right.  Now, if you look at the details for 1.2-0ubuntu1, you'll see the list of "Package files".  The ones ending "_armel.deb" indicate that armel binaries were generated.
<persia> You can verify they have been published by checking https://ports.ubuntu.com/ubuntu-ports/pool/universe/k/kcm-qt-graphicssystem/
<persia> You can check to make sure the "universe" component is enabled in /etc/apt.sources.list (if you need to enable it, be sure to update your apt cache (`apt-get update` is one way to do this))
<persia> Alternately, if you're using a mirror, check to make sure the package appears on the mirror.
<persia> (some mirrors only mirror subsets of Ubuntu, which is fine)
<dcordes> persia: ok
<persia> Oh, and if you're concerned about the output at packages.ubuntu.com : the system that uses to collect information is completely unaware of anything other than i386 and amd64, so it can never be right.
<janimo> ogra, rsalveti are out initrd images lz compressed now?
<ogra_> janimo, not that i know of
<janimo> the uInitrd are marked as gzip but inside it seems is is lz
<ogra_> just try file
<dcordes> persia: it would be nice to have a nicer web interface to the armel packages.
<janimo> file says :data
<ogra_> (on the initrd.img)
<dcordes> After this operation, 150 MB of additional disk space will be used.
<dcordes> I am not sure if it's so good to use so much extra space just for https://bugs.launchpad.net/unity-2d/+bug/782326
<ubot2> Ubuntu bug 782326 in unity-2d "unity-2d: flickers with xf86-video-fbdev on some machines" [Undecided,New]
<persia> dcordes, The number of packages that differ between architectures is well less than 1% of the archive.  I agree it would be nice to be able to export unified dists information, but that's pending a stack of other things, and will probably be some time.
<dcordes> persia: how about simple preliminary search feature ?
<persia> Hrm?  What do you mean?
<dcordes> something more comfortable than https://ports.ubuntu.com/ubuntu-ports/pool
<persia> What are you trying to accomplish?
<dcordes> I want to fix https://bugs.launchpad.net/unity-2d/+bug/782326
<ubot2> Ubuntu bug 782326 in unity-2d "unity-2d: flickers with xf86-video-fbdev on some machines" [Undecided,New]
<dcordes> I need to run all QT programs with this paramter: "-graphicssystem native"
<persia> No.  You need Qt to properly select "native" as the graphicssystem to use when presented with that hardware.
<persia> Ah, there seems to be a blueprint about that, but it appears to be "not started".  jazh appears to have been working on it.
<persia> apachelogger reported that Qt supports the QT_GRAPHICSSYSTEM environment variable, which might be a lighter-weight workaround in the meantime (see http://apachelog.wordpress.com/2010/09/05/qt-graphics-system-kcm/ )
<persia> (note that you'll need to configure the environment variable so that gnome-session sets it, as startkde is unlikely to run in a unity environment)
<janimo> ogra, I am looking at the uInitrd files in the preinstalled 11.04 and oneiric images and they seem to be lzma
<janimo> where are they generated?
<NCommander> janimo: as part of livecd-rootfs for preinstalls
<janimo> I am trying to debug the SD alignment issue so I need to change jasper scripts in initrd
<ogra_> i dont think they stay lzma after install
<NCommander> ogra_: with the ac100, the 'install' step completes fine, oem-config explodes into confetti
<ogra_> NCommander, yeah, thats caused by a to big initrd
<NCommander> ah
 * NCommander vaguely wonders how difficult porting u-boot to the ac100 would be. */pipedream*
<ogra_> i messed around with a diversion of plymouth in initrd, somehow that didnt work, so plymouth ends up in the initrd
 * Daviey vaguely wonders if NCommander will ever respond to his mails.
<janimo> NCommander, ah indeed. INITRD_COMPRESSOR=lzma there
<ogra_> NCommander, already ported, the prob is that kbd and display dont work
<janimo> ogra_, probably not after install
<ogra_> janimo, right, but the installed initramfs-tools default to gzip
<ogra_> so with the first local regeneration they switch
<NCommander> ogra_: I take it someone found the pads for the serial port
<janimo> ogra_, which reminds me. Why does the VFAT need to be rewritten when resizing on first boot? Isn't only the 2nd partition expanding
<janimo> ?
<ogra_> NCommander, yes
<NCommander> Daviey: er, what email?
<ogra_> janimo, to make sure MLO lands in the first sector again ... if that bug is gone (which i heard should be with next x-loader) we can drop that crap
<Daviey> NCommander: Subject: Ubuntu ARM Server release for 11.10 (server-o-arm-server)
<ogra_> apparently the whole CHS stuff is fixed
<janimo> ogra_, but does the resize not only entail increasing the number of cylinders? the first partition parameters should stay the same
<NCommander> Daviey: ack, sorry, I missed it the first time around
<janimo> I also read that bug is gone for a while already
 * NCommander sees your follow up
 * janimo tries to modify existing uInitrd and convince panda to take it without saying 
<NCommander> Daviey: davidm is working to schelude a call on a regular basis so we can sync wr.t. to our tasks and progress on said tasks
<janimo> wrong image format for source command
<Daviey> NCommander: super!  Thanks.
<dcordes> persia: ah I remember I tried that and failed automatically setting this (profile.d)
<persia> Isn't profile.d sourced by shells, rather than the session managers?
<dcordes> ah :)
<persia> dcordes, If you're creating a spice package, stuff something in /etc/X11/Xsession.d : If you want to do something for your user, put something in $HOME/.xsessionrc
<persia> There are very likely to be display-manager- and session-manager-specific ways to do this, but I suspect something general is more likely to meet your needs in a flexible manner.
<dcordes> Xsession.d is fine I already have a script there for screen rotation
<dcordes> and to remove the 'overlay scrollbars'
<dcordes> export LIBOVERLAY_SCROLLBAR=0
<dcordes> I will use that script as a global Xsession.d env script
<Vaati> hello all
<persia> hey Vaati
<Vaati> so, is this also for general arm dev ?
<ogra_> Daviey, NCommander, new installer image is up
<ogra_> should work now
<NCommander> ogra_: those are famous last works
<ogra_> and words too :)
<Vaati> lol
<Vaati> but, am I allowed to ask non-specific questions about arm development?
<ogra_> well, the installer is fine, i'm not yet sure my diversion hackery survives a dist-upgrade though
<Vaati> 'cos ##arm is rather silent...
 * ogra_ is just testing that
<dcordes> how can I test if Xorg parsed my environment variables ?
<persia> Vaati, We're mostly focused on integration of stuff and making sure all of Ubuntu is available on ARM (and as many devices as possible are supported by Ubuntu).
<Vaati> ok
<persia> If you have questions related to how things work, we can try, but we may not be the ideal resource.
<persia> And if you're writing arch-specific code that isn't kernel or driver related, some folk will encourage you to be portable :)
<Vaati> ok, well I'm trying to set up a gcc toolchain for the STM32 vl discovery board (arm7 cortex m3) under ubuntu
<Vaati> i.e.; I want to use ubuntu to program it
<Vaati> and I've found the stm32flash software, but apparently it requires a usart, so I cant use the on-board jtag...  however, someone created a bootloader called versaloon -- anyone familar with it?
<persia> Heh.  That's an area we probably ought to investigate: using ARM as a host for embedded development.
<Vaati> aww yeeaaah
<persia> We usually focus on running Ubuntu on the ARM chip (but I don't believe the m3 implements all the instructions used in Ubuntu)
<Vaati> ok
<dcordes> persia: I put "export QT_GRAPHICSSYSTEM=native" in /etc/X11/Xsession.d/54setupenv
<Vaati> well, has someone ported puppy linux to the m3 yet?
<Vaati> or some other form of *nix
<Daviey> ogra_: oooo
<Daviey> ogra_: just boot-installer-2.6.37-1-ac100.img, same tgz?
<ogra_> yep
<ogra_> tgz didnt change
<Daviey> super!
<Daviey> thanks for your attention to this ogra_
<persia> To the m3?  I'm not sure it *can* run Linux.  If it can, the Yocto folk are most likely to have a working environment.
<dcordes> persia: in fact even if I run "QT_GRAPHICSSYSTEM=native DISPLAY=:0 unity-2d-launcher" from a remote terminal, it still doesn't work
<Vaati> yocto?
<ogra_> Daviey, well, i want to have proper oneiric images so the natty ones are my testbed
<Vaati> ah, found a port
<ogra_> all the ac100 stuff will go to the archive soon
<Vaati> http://www.linux-arm.org/LinuxKernel/LinuxM3
<Vaati> if you were wondering
<persia> Vaati, You'll probably need ulibc with that: there's no MMU
<zul> ogra_: i know i might be a PITA but we could get like a minimal install without unity so just like a cli and ssh?
<ogra_> zul, read my conversation with persia above ;)
<ogra_> on my TODO
<zul> ogra_: cool thanks
<dcordes> persia: maybe unity-2d was compiled in a way it will not parse the QT_GRAPHICSSYTEM env var ?
<persia> That would be odd, but perhaps.
<Vaati> omg
<Vaati> I think I stumbled across a solution to a toolchain...
<Vaati> without even looking for it
<ogra_> sigh ... updates to gnome-user-guide always make me think my system is dead
<Vaati> at any rate -- what are the minimum specs for running ubuntu on an arm?
<ogra_> i wonder whats its doing all that time
<persia> ogra_, There's something annoying at the FS layer that needs sorting.  It's the same reason cp is slow to install.
<ogra_> well, all other packages arent that slow
<persia> Vaati, support for the ARMv7a ISA
<ogra_> it must do something special
<persia> ogra_, They don't have anything *near* the file count.
<persia> (unless I misremember g-u-g)
<ogra_> ah, now it moved
<ogra_> ok, i take everything i said about g-u-g back, ubuntu-docs is worse
<NCommander> we have ubuntu docs?
<persia> Yes.
<persia> A single source generates a package to populate yelp *and* the majority of the contents of help.ubuntu.com
<dcordes> Bug 791852
<ubot2> Launchpad bug 791852 in unity-2d "unity-2d: does not parse QT_GRAPHICSSYSTEM env var" [Undecided,New] https://launchpad.net/bugs/791852
<persia> Except that's not something unity-2d is *supposed* to do: that should happen in Qt.
<dcordes> persia: I don't understand. could you elaborate ?
<persia> Qt clients specifically should never care which graphicssystem is in use.  They should just call into Qt abstractions.  Qt then should turn those abstractions into something that actually does something on the system (frequently through additional abstraction layers).
<dcordes> persia: so at what place must the env var be present for the clients to get the correct graphicssystem ?
<persia> At the process level.  So, `QT_GRAPHICSSYSTEM=native unity-2d-launcher` ought do the right thing.  But this is because Qt notices the environment variable, not because unity-2d does.
<dcordes> this is what I do but it does not work. so I can assume something with Qt is fishy ?
<persia> I believe so.  I believe that the bug has the wrong task.  I'm not sure precisely *what* is responsible for handling QT_GRAPHICSSYSTEM though, but I suspect the bug would get attention from the right folk if retargeted to the right place (mind you, finding this probably requires more investigation)
<dcordes> ok I will leave it as is, affecting unity-2d, and hope for the unity folks to know what is the correct project affected :)
<dmart> zumbi_, hrw: I think the conclusion was that eglibc is misdetecting the new triplet as being non-eabi
<dmart> wrong channel
 * dmart sighs
<Daviey> ogra_ is man of the match, your latest boot img worked greated
<ogra_> awesome !
<ppisati> GrueMaster: Linux omap 2.6.39-3-omap #10 Thu Jun 2 17:41:26 CEST 2011 armv7l GNU/Linux
<ppisati> GrueMaster: i have usb
<ppisati> GrueMaster: beagle xm rev a
<ppisati> GrueMaster: i just ssh-ed in
<GrueMaster> Is this the same kernel that is in the current images?
<ppisati> GrueMaster: uhm no, latest oneiric
<GrueMaster> That's what I mean.
<ppisati> GrueMaster: ok, but then the bug will be fixed with the next release
<GrueMaster> The kernel I have is 2.6.39.3.4
<GrueMaster> Ah.
<ppisati> flag@omap:~$ cat /proc/version_signature
<ppisati> Ubuntu 2.6.39-3.10-omap 2.6.39
<GrueMaster> ok
<ppisati> GrueMaster: can you double check with latest oneiric?
<ppisati> and wait
<ppisati> one more check
<ppisati> Texas Instruments X-Loader 1.5.0 (Apr 11 2011 - 09:47:05)
<ppisati> U-Boot 2011.03 (Apr 20 2011 - 07:19:53)
<ppisati> do they correspond?
<GrueMaster> Latest image is 20110601, which I already tested.
 * ppisati wonders if correspond is the correct word at all...
<GrueMaster> x-loader & u-boot should be the same.
<ppisati> GrueMaster: please check
<ppisati> GrueMaster: i did a lot experimentation
<GrueMaster> Give me a sec to setup.
<ppisati> no hurry
<GrueMaster> x-loader & u-boot are the same on the 20110601 image.
<ppisati> ok
<ppisati> /proc/version_signature?
<GrueMaster> That should be in the bug report.
<ppisati> right
<ppisati> but is the same as mine...
<ppisati> uhmmm...
<ppisati> ok, i'll install that image then
<GrueMaster> I recommend the headless image, otherwise you won't get very far.
<ppisati> GrueMaster: k
 * ppisati -> out for a walk...
<GrueMaster> ogra_: Is there a way to restore factory default Toshiba image after installing your image?
<ogra_> GrueMaster, yes, you can restore the full backup you took before changing anything, vnflash should always work
<ogra_> *nvflash
<GrueMaster> Good to know.
<ogra_> indeed that requires that you actually backed up everything first :)
<GrueMaster> I haven't even started messing with it beyond plugging into power.
<ogra_> oh, you got one too now ?
<ogra_> (not michaels)
<GrueMaster> Got it yesterday.
<ogra_> wow
<ogra_> its like an epidemic thing how these things pop up around me :)
<lilstevie> lol
<Daviey> ogra_: Is this expected, nvec nvec.0: new transaction during send trying to retransmit! ?
<Daviey> Every minute or so in dmesg
<ogra_> Daviey, yes, thats a workaround in the kernel that makes your input devices not die
<ogra_> in the former kernel revision the complete input system locked up every time you see this message ... and only a shutdown, making the device 30sec powerless and reboot could make it work again
<Daviey> ah
<ogra_> we somehow get event storms on the nvidia event controller, nobody knows why yet
<ogra_> if you see that message in demsg it actually means nvec eas restarted
<ogra_> *was
<janimo> what is the easiest way to preseed a few values on the preinstalled headless image? I'd like to skip most installer questions as I run fresh images frequently and that slows the process down
<ogra_> janimo, well, currently only setting them on kernel cmdline is supported
<ogra_> but that works well
<janimo> can I set cmdline from uboot or only from boot.scr?
<ogra_> you could do it manually from u-boot shell but would have to manually type in the whole boot.scr content indeed
<janimo> ok. On the cmdline I pass a preseed file path or even the actual preseeded value list?
<ogra_> only values
<ogra_> and keys
<ogra_> as i said above, files arent supported yet, only setting preseed options directly on cmdline
<ogra_> for oneiric i plan to add file support though
<GrueMaster> Can't you set it to pull a preseed from http?
<GrueMaster> I've not dealt with preseeds before.
<ogra_> GrueMaster, the prob is that you need code to process it ... where it comes from doesnt matter much
<GrueMaster> I thought oem-config could handle it.
<persia> oem-config *consumes* preseeding
<ogra_> and the code processing preseed that i added last release simply only reads /proc/cmdline atm
<GrueMaster> hmmm.
<ogra_> right, what persia said
<ogra_> the code *setting* the options from file or cmdline is whats matters
<ogra_> that should be trivial to add though, will have it in place before A2
<ogra_> preseed files are a requirement for server images
<Martyn> Hey everyone!
<ogra> grmpf
 * ogra fights with oeniric
#ubuntu-arm 2011-06-03
<ppisati> morning
<ppisati> ogra_: do you have an imx51? or do you know who has one besides GrueMaster and ericm|ubuntu?
<ppisati> ogra_: i need an info about the parport module
<ogra_> hmm, so oneiric is a big fail here
<dhana013> Hi
<dhana013> any one haveing ubuntu 10.04 rootfs
<ogra_> just use rootstock
<ogra_> (see topic)
<dhana013> thanks
<dhana013> @ogra_
<ogra_> geez, oneiric is shaky
<ppisati> cool, using my own oneiric kernel i got usb back
<ppisati> config are the same
<ppisati> and kernel version is the same on both
<ppisati> uhmm....
<ogra_> toolchain isnt probably
<ppisati> ogra_: uh
<ppisati> ogra_: but would be really nasty
<ogra_> just a guess :)
<ppisati> ogra_: yep, but it's a variable indeed
<ppisati> ogra_: which toolchain do we use on the builder?
<ppisati> i think i can guess it from the boot msg
<ppisati> ogra_: and indeed the toolchain are different... oh sh*t...
<Utrinqueparatus> Has anyone here any experience with installing Ubuntu on a portable tegra based device like the advent vega?
<ogra> ha !
 * ogra has a stable oneiric session on the ac100
<lilstevie> :o
<hrw> ogra_: ubuntu/r will give sound?
<ogra_> hrw, ??
<hrw> ogra_: iirc you still lack sound on ac100 - right?
<ogra_> yep
 * hrw jokes about ubuntu/r
<ogra_> we have a working driver, but nobody understands the wiring
<ndec|home1> ogra_: sounds issues are chasing you ;-)
<ogra_> i'm pretty sure that will be fixed soon, with so many people getting ac100s suddenly
<ogra_> ndec|home1, lol, yeah
<ogra_> on the ac100 its easily worked around with a BT headset though
<hrw> ogra_: replaced screen with 720p one?
<ogra_> not yet
<ogra_> currently i use the second one to run oneiric on it :)
<ogra_> and to test the installer
<hrw> one with natty and one to tests?
<ogra_> yep
<hrw> like my pandas - one ubuntu, one linaro
<Utrinqueparatus> I am trying to slim down an install I have running on vega
<Utrinqueparatus> Is there anyway to do that without using the actual device?
<Utrinqueparatus> i.e i have gnome and unity 2d installed but they are killing it so I want to try XFCE or similar?
<ppisati> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/791552
<ubot2> Ubuntu bug 791552 in linux "No USB support on beagle/beagleXM" [Undecided,New]
<ppisati> yes, in the end seems it was the toolchain
<GrueMaster> ppisati: Weird.
<GrueMaster> Good hunting though.
<ppisati> GrueMaster: at least reverting to 4.5 fixes it
<ppisati> GrueMaster: actually ogra had the idea to check the toolchain :)
<ppisati> GrueMaster: we don't know yet if 4.5 was borked and proced a working code, and 4.6 broke it
<ppisati> or the other way around
<GrueMaster> Its odd that it broke omap but omap4 is ok.
<GrueMaster> I would think they use close to the same code for USB.
 * ppisati shrugs
<ppisati> really dunno
<ppisati> let me try the linaro kernel
<ppisati> uh wait
<ppisati> omap4 is still using 2.6.38
<ppisati> because we don't have a 2.6.39+omap4 branch
<ppisati> while for omap3 we are using 2.6.39
<ppisati> perhaps that's why we don't see the breakage there
<ppisati> natty kernel are ok, right?
<GrueMaster> Might be an interesting test to take the natty omap kernel and rebuild it with oneiric toolchain.
<ppisati> i'll do that
<GrueMaster> Yes, natty works fine.
<ppisati> ok
<ppisati> so, i try natty with 4.6
<ppisati> that's the new toolchain
<GrueMaster> on the parport_pc issue, it never really affected lucid (although the potential was there).
<GrueMaster> Maverick cups added a modprobe line to force the parport_pc module to load on start.  The simple solution was to not include that module in the armel kernels.
<GrueMaster> The proper fix would be to actually fix the driver to fail gracefully.
<dcordes> ogra_: with you being a member of the unity-2d team, may I ask you to have a quick look at https://bugs.launchpad.net/unity-2d/+bug/791852 and decide wether or not it's valid? I fear it will drown in the noise
<ubot2> Ubuntu bug 791852 in unity-2d "unity-2d: does not parse QT_GRAPHICSSYSTEM env var" [Undecided,New]
<ppisati> oh
<ppisati> gcc 4.6 and natty = same problem
<ppisati> on omap3 i mean
<GrueMaster> oops.
<GrueMaster> That's not good.
#ubuntu-arm 2011-06-04
<MrCurious> anyone know why ubuntu on pandaboard dedicates 320meg of ram to a tmpfs for dev, dev/shm, var/run, and var/lock?
<MrCurious> better question does anyone know how to change it so that tmpfs is not used? i have the fs moved to a fast usb disk
<MrCurious> ugh, unrolled uInitrd, but cant work out exactly how it is sucking up > 300M for a tmpf
<MrCurious> can anyone spare a hint on how to disable this tmpfs on 11.04 omap4
<MrCurious> anyone here awake?
<uragano2> Hello!i don't know where set JAVA_HOME...where is it?
<persia> MrCurious, By default, all tmpfs mounts are allocated 1/2 available RAM.  In practice, very little of this should be used (perhaps 1M for all of /dev, /dev/shm, /var/run, and /var/lock combined).  If you have more usage than this, you're probably running something that uses SHM (shared memory regions) heavily: attempting to put that on rotary media (or anything other than RAM) is likely to have a significant negative effect on performance.  If yo
<persia> u are encountering OOM issues, consider adding swap on your rotary disk.
<MrCurious> persia: thanks, i sorted it out
<MrCurious> it was due to being a upgraded 10.10
<MrCurious> it was set to only use 3/4 of the mem
<MrCurious> modified a boot flag
<MrCurious> and re-enabled a missing segment of 256meg
<persia> Ah.  The 320 looked like some memory was missing, and now it all makes sense :)
<MrCurious> yup
<MrCurious> now its on to building the software stack that i need
<persia> Excellent.
<MrCurious> dont suppose you know the name of the package that contains linux/videodev.h
<MrCurious> guessing a kernel header package or kernel package
<MrCurious> linux-source :D
<MrCurious> its coming back to me now
<persia> linux-headers-${FLAVOUR} is probably lighter-weight and more likely to match your needs.  In this case, `linux-headers-omap4`
<MrCurious> tried
<MrCurious> it lacked the file
<MrCurious> 75% done unpacking the full kernel
#ubuntu-arm 2011-06-05
<dcordes> persia: ping
 * persia prefers contentful pings
<MrCurious> persia: <ping> how was your last meal</ping>
<ScottK> 'last meal' seems very ominous.
<MrCurious> heh
<MrCurious> 73% done building OpenCV on pandaboard
<MrCurious> starting to get a good feeling
<persia> MrCurious, Does the libcv2.1 in the archives not work for your needs?
<MrCurious> not entirely sure what my needs are of yet. figured if i built from source, i would keep my options open
<MrCurious> i am on a voyage of discovery
<MrCurious> and example programs are very valuable :D
<persia> Heh.  May as well play then.  Most of us don't bother building from source unless we need to modify something (or are adding new software to the archive).
<MrCurious> i am half expecting to be needin gaccess to sources, and knowing that the lib and sources match 1:1 is a good thing
<MrCurious> a s aversion skew could couse ponderous oddaties
<persia> If you find anything where the binaries and sources *don't* match in the archive, that's a bug to be fixed at the earliest opportunity.
<MrCurious> no. i mean the sources i dl with the binaries installed on the system
<persia> How are you getting sources?  Generally we recommend `apt-get source` or similar, in case there are patches needed to build in Ubuntu.
<MrCurious> hmmm. if this attempt fails, i may petition you for the mojo to do it the way you suggest
<dcordes> https://bugzilla.mozilla.org/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=&content=webm I have a feeling this is the thing that happens when ff4 and fennec crash in natty when playing webm
<dcordes> persia: ok. content: unity-2d: QT_GRAPHICSSYSTEM: it seems like there is no activity about it. you proposed to report the problem in a different place and would like to ask your advise now. https://bugs.launchpad.net/unity/+bug/791852
<ubot2> Ubuntu bug 791852 in unity-2d "unity-2d: does not parse QT_GRAPHICSSYSTEM env var" [Undecided,New]
<dcordes> ogra_: would publicly available logs of this channel be a problem with you ? (you set the topic...)
<MrCurious> persia: do you know if the ubuntou people know that ubuntu-11.04-preinstalled-netbook-armel+omap4.img.gz is corrupt?
<gildean> dcordes: it requires someone with a stable irc-connection (ie. running irssi in a screen on a linux-server) and a public_html folder for that user to write the file into
<gildean> i'm not sure how many people are really using irc as it should be, most still seem to use clients on their workstations
<armin76> uh...isn't there a botlog already?
<dcordes> gildean: I have a friend who has such a setup. the question is if the channel is OK with that. maybe some prefer staying 'unlogged' :)
<gildean> haha, the channel has nothing to say to that
<gildean> if you can join, you can log
<gildean> that's the way it goes
<gildean> i've been using irssi from a shell for about 10 years now
<gildean> before that, i used random clients on workstations
<gildean> like mirc and xchat
<gildean> but i don't autolog bigger channels, as the logs usually tend to grow and i don't have unlimited space on this server where i run my irssi
<gildean> logging #ac100 takes up around 300-500KB per week
<dcordes> gildean: that's why I enjoy having some remote machine log everything. with web search function :)
<gildean> and double that because i log the channel with a weekly rotation and a separate full-log
<dcordes> well thanks for providing the ac100 log!
<MrCurious> anyone here know anything about bluetooth + pandaboard + ubuntu?
<dcordes> MrCurious: what's the problem about bluetooth + pandoraboard + ubuntu ?
<MrCurious> i cant work out how to get it to spot my bluetooth serial port
<MrCurious> i suppose i need to work out how to get it to pair or show devices that it sees
#ubuntu-arm 2012-05-28
<Aurum> hi all
<Aurum> I want to try ubuntu 2.6.xx version of kernel on panda
<Aurum> but I want to build it for myself ... also want comaptible u-boot ... Can anyone help ?
<Aurum> can anyone point me to kernel source code repo for panda ubuntu
<Aurum> ?
 * Aurum che connect
<Aurum> I am using https://wiki.ubuntu.com/ARMTeam which allows me to have image on my panda board but where can I find corresponding source code for bootloader and kernel ?
<Aurum> sebjan : I checke out your branch for u-boot ... for omap4 panda. Unable to find USB EHCI driver and Ethernet river
<Aurum>  can anyone tell how to clone omap4 panda kernel ?  I can find instructions for getting direct bins from http://omappedia.org/wiki/OMAP_Ubuntu_Core
<Aurum> but I want the source from which these are compiled
<int_ua> Hi :) I'm searching for a help with publishing a newer stable kernel for N900. Can anyone help?
<kaektech> Aurum: Try this:  http://elinux.org/BeagleBoardUbuntu.  It will compile for the panda.
<geser> janimo: Hi, as you hacked on ghc in the past, can you take a look at ghc on armel again? every build of haskell-* packages and also ghc itself fail on armel
<geser> https://launchpadlibrarian.net/106320724/buildlog_ubuntu-quantal-armel.ghc_7.4.1-3_FAILEDTOBUILD.txt.gz
<geser> Error: selected processor does not support ARM mode `movw r3,:lower16:stg_CHARLIKE_closure' (and more similar ones)
<int_ua> rsalveti: ping
<janimo> geser, will check
#ubuntu-arm 2012-05-29
<infinity> janimo: I'd assume it's because we moved the toolchain to ARMv5, but perhaps haven't told GHC about it.
<infinity> janimo: If you don't have the time to poke it, I can.
<infinity> janimo: My suspicion seems to be confirmed by the build log.  Grabbing the source now to have a look.
<twb> Don't forget you can ask #debian-haskell (OFTC) for advice re the ghc side of things
<suihkulokki> ubuntu armel is armv5 again?
<infinity> suihkulokki: SOrt of.
<infinity> twb: I suspect it's actuall llvm that needs some love.  Or maybe ghc just needs a violent re-bootstrap.
<twb> Last time I looked (karmic?) GHC on arm went via C
<twb> Didn't know they had transitioned to llvm
<twb> Oh and (at least at the time) ghc didn't support arm, really, it was just the debian haskell team making it kinda-work
<suihkulokki> infinity: you need to update the topic then :)
<hrw> suihkulokki: toolchain is armv5 but that does not mean that ubuntu/armel is armv5 again
<hrw> suihkulokki: no one rebuilt whole archive for it
<twb> What does "toolchain is armv5" mean?  That just those packages (presumably gcc, ld, etc) are compiled to run on armv5, though packages compiled WITH them target armv7?
<hrw> twb: right
<hrw> twb: ubuntu/armel was armv7 so most of packages still are. new ones will be armv5
<int_ua> Hi. Looks like we have a newer somewhat stable kernel for the Nokia N900. Can someone help with packaging it and publishing on some server, better in the official repository?
<twb> hrw: why the backflip?  Just because of raspberry?
<suihkulokki> twb: there is now armhf so having two armv7 ports doesn't make much sense
<twb> Oh.
<hrw> twb: who care about r/pi?
<twb> hrw: exactly
<twb> armhf branch isn't mentioned anywhere on https://wiki.ubuntu.com/ARM btw
<jackh> rasberry is ARMv5
<infinity> jackh: It's v6.
<jackh> twb: you mean ubunbu willl support that pi?
<infinity> twb: Hrm, wiki/ARM seems pretty out of date in general.
<jackh> infinity: ok, thanks for correct me
<infinity> jackh: We're making no such commitment.
<infinity> jackh: If we don't kill the armel port entirely, it might end up supporting the Pi, but that's still up in the air.
<jackh> infinity: seems lot of work of packaging, testing, fixing?
<infinity> jackh: Right now, we're just doing an organic/lazy rebuild.  But, like I said, we may still drop the port entirely, so no promises.
<jackh> infinity: seems not many devices and dev-boards are supported by ubuntu now
<jackh> infinity: i plan to do some work to support some of them
<infinity> omap, omap4, mx53, ac100, plus all the boards that Linaro ships kernels for...
<infinity> We have no real interest in building 50 images for every possible target.
<int_ua> jackh: what about N900?
<jackh> infinity: as you know they are too expensive, not suitable for young guys to buy
<jackh> infinity: i am try to do some on A8 systems, which is very cheap here
<infinity> jackh: 200 USD is "expensive"?  My, how times have changed.
<jackh> infinity: Pi is 25bugs, you know that
<infinity> Yes, but it's also not something you want to run a general prupose OS on.
<infinity> An Ubuntu desktop wouldn't actually boot on it even if we were v6.
<jackh> infinity: also hdmi is not pop here, i dont think they have hdmi tv
<jackh> infinity: so i will do the things from the minimal rootfs and adds things on, if i meet any problem, i will disturb you:)
<twb> infinity: these plans/changes will be set in stone as at the next release?
<infinity> twb: It's more about if someone wants to sponsor the port.  Canonical's not really keen on doing armel for free.
<twb> Nod.
<twb> I was just confused because I thought it had already been decided (like, two releases ago) that Ubuntu's armel was gonna be v7 and HF and the only arm port Ubuntu had
<infinity> ..?
<infinity> armel was never going to be HF.
<infinity> Hence armhf.
<twb> I guess I was misinformed
<twb> Or rather, I misunderstood
<suihkulokki> I guess twb is confusing hf with softfloat abi vs hf abi
<twb> I'll STFU now...
<suihkulokki> it is confusing, no need to feel shame :P
<jackh> hmm, infinity: suihkulokki: hf is hard floating, abi uses some mix of soft and hard floating, right?
<twb> In my head "hf" means you must have a hardware FPU
<infinity> Yeah, that's not what it means.
<twb> Has someone written this stuff down somewhere?  If so I'll just go read that
<infinity> soft is software FP, softfp is hardware FP, but soft's calling conventions, hard is hardware FP, and using a new calling convention that uses the VFP registers.
<infinity> soft ansd softfp are ABI-compatible, hard isn't.
<twb> IOW softfp will work on either, and can use a hardware FPU, but will have minor overheads compared to hard?  Whereas soft will simply ignore any hardware FPU?
<twb> Or does "hard" actually work without a hardware FPU?
<jackh> twb: iow, hf seems like a small intruction set
<jackh> twb: the instructions will ask for and get result from some hardware units
<suihkulokki> only softfloat works if you do not have VFP
<twb> OK
<twb> I guess all I really care about is making sure I pick the best build for whatever hardware is in front of me
<twb> (Where "best" balances performance and effort - e.g. maybe it is worth recompiling the kernel, but not the entire distro, for my specific unit.)
<jackh> twb: sorry, i still dont get what you want to do
<twb> jackh: buy a computer, then make it go SUPER FAST
<twb> Don't worry about it, I'm just talking shit
<jackh> twb: i got it
<jackh> twb: but that's x86 stuff, nothing to do with this channel
<twb> Er, not on arm boxes
<twb> Although my tf101 is still running oneiric and android's crappy kernel because I am actually too lazy to do anyhting but talk
<recur> anyone know how to get Xfbdev to load fonts?  My embedded device needs something nicer than the fixed font :D
<twb> There are broadly two font subsystems; the "x font system", which deals with bitmap fonts, and xft, which deals with outline fonts.
<twb> GTK2/3 and Qt3/4 are xft-based; almost everything is.  xterm uses xft if you say e.g. "xterm -fa monospace"
<twb> MOST apps that use xft, use a second library "fontconfig" to turn a logical font name like "Sans 12" into the path to a font file.
<twb> Anyway, if it's an xft app I wouldn't expect anything special to be needed on the X server side, it's all X app side
<recur> ohh cool
<recur> thanks two, this is good info
<recur> er twb, stupid spellcorrect ;)
<twb> Sigh.
<twb> You're about the fifth person in the last month to do that; it seems that everyone decided to turn on spell-checking at the same time...
<twb> It's probably a new "feature" in pidgin or whatever the hell is popular these days...
<furan> stupid question. I am working on desktop ubuntu with libavcodec-52, but when I installed libavcodec on my arm device I got -53. Is there any way to install -52 + dev?
<recur> I'm using Textual, it's disabled now :D
<twb> furan: if both boxes are running the same release, they should have the same version
<furan> they apparently aren't
<LetoThe2nd> maybe ont the desktop box there's medibuntu or such.
<twb> furan: back- or forward-porting is not something you should attempt unless you are an experienced packager
<twb> And that goes double for installing stuff directly (i.e. "make; make install" rather than "apt-get install")
<furan> desktop:Linux version 2.6.32-41-generic (buildd@vernadsky) (gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5.1) ) #89-Ubuntu SMP Fri Apr 27 22:22:09 UTC 2012
<furan> Linux version 3.2.0-psp7 (root@panda-a1-1gb) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu4) ) #1 Fri Apr 13 04:55:05 UTC 2012
<furan> and that's the device
<twb> furan: use lsb_release -a to check the relases, and look at "apt-cache policy" output to see if they have rogue package sources
<twb> That sounds like lucid vs. precise
<furan> hah, I guess I installed lucid instead of precise on my vmware instance
<furan> thanks
<furan> ugh now i've gotta change all my libavcodec stuff
<furan> oh well
<twb> it's better in the long run iMO
<janimo> infinity, good to know you're on ghc then :)
<janimo> also good to hear we try an armv5 armel flavour even if just experimenting
<ogra_> hmpf, i guess that got swallowed by my reconnect
<ogra_> janimo, any news about the new ac100 kernel ?
<ogra_> (would be nice to have something for A1 the binary drivers work with ... which means at least 3.1)
<janimo> ogra_, I will have a look, would be nice indeed. I did no check marvin24's tree in almost a month I think
<ogra_> well, i'm using a self rolled 3.1 since the new binary driver came out
<ogra_> despite the driver bugs it seems ot work just fine
<janimo> ogra_, I still hope all tegra2 stuff gets mainlined for 3.6 and maybe catches 12.10 :)
<ogra_> but you wanted to switch to 3.2 you said in the past, that will require somce signficant changes (devicetree)
<ogra_> 3.6 would be nice but i wouldnt count on it
<janimo> I wanted to switch to whichever kernel is least hassle to maitain :)
<janimo> if possible as new as possible to be in line with ubuntu
<ogra_> sure
<lilstevie> ogra_: you don't have any issues with 3.1
<ogra_> it would be nice to have working images for the quantal milestones though, since we have a policy that images have to work nowadays
<ogra_> i dont, no
<lilstevie> I still can't figure out what is causing my hang
<ogra_> seems as stable as 3.0 was
<lilstevie> as long as I break it is fine
<ogra_> lilstevie, try removing plymouth
<ogra_> (by removing the plymouth hooks and scripts from /usr/share/initramfs-tools and rebuilding the initrd)
<lilstevie> when I ask it to remove plymouth it wants to remove everything
<lilstevie> ah
<ogra_> yeah, mountall needs libplymouth iirc
<lilstevie> well waiting for bonnie++ to finish then I will try without plymouth
<lilstevie> also gpower is being a little trigger happy with the dual battery
<janimo> ogra_, btw IIRC you packaged the tegra armhf drivers right?
<ogra_> http://people.canonical.com/~ogra/nvidia-tegra/
<ogra_> waiting for a newer kernel before i upload to the archive
<janimo> ogra_, ah they completely fail with old kernel, ok
<janimo> both armel and armhf in there?
<ogra_> nope, only armhf
<janimo> or we drop armel completely for quantal
<ogra_> still waiting for mgmt decision ... as it seems we will keep it around in teh oinfrastructure but not touch it at all
<janimo> lilstevie, do you know what the status of mainlining tegra2 support is?
<lilstevie> janimo: not good afaik
<lilstevie> ogra_: removed the plymouth hook altogether from initramfs and it is still doing it
<ogra_> try also disabling the upstart plymouth jobs in /etc/init
<lilstevie> ok
<ogra_> or make plymouth non executable or move it to .orig and macke /usr/bin/plymouth a link to /bin/true
<ogra_> oh, and indeed, drop "splash" from the cmdline :)
<lilstevie> I don't have splash on the cmdline
<lilstevie> ogra_: symlinking plymouth and plymouthd with /bin/true worked
<ogra_> must be some issue with tegrafb or so
<lilstevie> probably
<ogra_> i saw that too, but only on tegra devices with 3.1 and newer kernels
<lilstevie> this is with 3.1
<ogra_> ah, yeah
<ogra_> i was told 3.2 would be better with that
<lilstevie> hm
<janimo> lilstevie, do you know if android and ubuntu can dual-boot on a tf101?
<janimo> adn whether there are other than 3g hw differences between tf101 and tf101g?
<lilstevie> janimo: depends how you mean by dual-boot
<lilstevie> janimo: I do it at the cost of recovery, but we have recently started getting kexec and kexecboot working
<lilstevie> janimo: as for the difference between the tf101 and tf101g; they are simple, 3G modem attached to mini pci-e port, and different sbk set in the cpu, the rest of the hardware is 100% identical
#ubuntu-arm 2012-05-30
<mythos> hui... i got my pi today =)
<mythos> and pandaboard es is on its way =)
<ogra_> http://www.ebay.com/itm/Raspberry-Pi-Fedora-Operating-System-8GB-SD-Card-Expanded-/300705977609
<ogra_> ;)
<ogra_> http://donaldclarkplanb.blogspot.co.uk/2012/05/raspberry-pi-7-reasons-why-it-wont-work.html
<rbasak> ogra_: ping
<rbasak> ogra_: dannf found an issue with Debian's flash-kernel that breaks Ubuntu completely, AIUI. Do you have time to discuss it now?
<rbasak> (as in today - I'll be about 20 mintues)
<ogra_> rbasak, yeah, go ahead (will be my last action today too)
<rbasak> dannf: over to you?
<ogra_> i'm aware that f-k will likely need adjustments
<ogra_> though we want to keep them as msall as possible
<dannf> ogra_: just the linux-base package / linux-version bit
<rbasak> Are you planning on uploading anyway even if we know it won't work?
<ogra_> uploading ?
<rbasak> Or do we want to get a fix in first?
<ogra_> it was synced this morning (EU time)
<rbasak> Ah
<rbasak> So we have a regression and it currently won't work at all for any board?
<ogra_> i will jump on it tomorrow (unless someone fancies to produce a patch tonight) and beat it in shape
<rbasak> I'm concerned about your approach here. Aren't we supposed to be testing first to prevent regressions in the development release?
<ogra_> the plan is to have at least omap and omap4 images ready for A1 so that means i have to touch it :)
<ogra_> rbasak, that would have taken weeks, we're pre A1 which is exactly the time to introduce such changed and fix issues before the first milestone
<ogra_> *changes
 * dannf looks at lp:ubuntu/flash-kernel - and yeah, it depends on the linux-version tool from debian's linux-base package
<ogra_> also it was discussed three times at three UDSes to do it that way
<rbasak> ogra_: regressions in d-i for ARM blocks our work.
<ogra_> thats why i warned you ahead of the change
<dannf> luckily, that means it shouldn't be installable either (luckily for any bleeding edge users)
<ogra_> right
<rbasak> By a day, which didn't really give us any time to work around the issue or prepare a fix in advance
<ogra_> images arent properly buildint anyway yet
<ogra_> *building
<ogra_> (due to buildd issues that were only fixed today too)
<ogra_> in any case this surely wont happen again, but we had to make a hard cut for f-k
<ogra_> since it was 80% hacks that simply werent portable to the new world order
<ogra_> (we forked about 4 years ago and it wasnt updated since, since the hacks would have been broken heavily)
<dannf> ogra_: one option is probably to discuss pulling in the linux-base package as well
<dannf> debian has split that out of the linux-2.6 package
<ogra_> right, I'll discuss that with the rest of foundations
<dannf> but that probably needs to be coordinated w/ the kernel team give the perf wrapper it adds (or disable that wrapper)
<ogra_> we have linux-tools that ships perf iirc
<dannf> ogra_: i don't think anyone disagrees that rebasing on debian is the right approach; the "how" is biting us, but the "why" is pretty obvious
<dannf> yeah, debian uses linux-base to chhoose the perf that's compatible w/ the current kernel abi
<dannf> it doesn't build a perf, just directs to it
<ogra_> linux-base should be installable according to the kernel team
<dannf> ah - maybe i misesd that; lemme try
<ogra_> as i said, i'll fix the issues tomorrow by A1 f-k should work fine
<ogra_> (and seriously depending on image buolds even before the first milestone was rolled should be reconsidered in your policy)
<rbasak> The trouble is that we can't work using precise, since that's fixed now
<rbasak> eg. highbank needs to go in quantal first before SRU
<rbasak> So we have to work on quantal
<ogra_> that wont work for f-k
<rbasak> Yeah f-k will need an old-style patch for precise
<dannf> i see it on packages.ubuntu.com, but apt doesn't see it on my armhf/quantal bxo.. /me digs
<ogra_> since they are completely different in both releases
<ogra_> dannf, make sure to use armhf ;)
<rbasak> I'm talking about process though - the general principle that we work on the dev release, and that we need netinst to work on the dev release.
<ogra_> the kernel team doesnt build for el anymore
<ogra_> rbasak, but it is pre-A1
<ogra_> nobody expects images or the installer to work before that ... this is the only time where such changes can be made
<rbasak> So essentially you're saying that the principle that the development release remains usable does not apply pre-A1?
<dannf> ogra_: my only armel box is a armv5 running debian, so that's not a problem :)
<ogra_> rbasak, installable
<rbasak> OK, I think I understand your POV now, thanks.
<ogra_> not usable ... using precise and upgrading should always work
<dannf> mystery solved, linux-base is in universe
<ogra_> installing should work after the first milestone (for the images that made it at least)
<ogra_> dannf, ah, i'll care for the MIr and promotion then
<dannf> ogra_: ack
<ogra_> dannf, that should keep you safe for d-i then though
<ogra_> i hope to have the worst bits solved before the weekend, the rest will happen during milestone freeze
<ogra_> dannf, rbasak, one other thing with the new f-k ... it wont allow booting without initrd by design, is that an issue for you guys (i assume not, else we can change that)
<dannf> ogra_: i don't *think* its a problem
<ogra_> (essentially i would like to keep the ubuntu changes close to zero if possible though)
<dannf> ogra_: +1
 * dannf much prefers hacking on the redesigned version
<ogra_> ++
<rbasak> We're using an initrd everywhere so I think it's fine
<rbasak> But isn't there a discussion on allowing initrd-less systems in ubuntu at some point? I never understood the motivation for this.
<ogra_> yeah, i though so
<ogra_> yes, i'm the driver behind that
<rbasak> So how is that going to work with a flash-kernel that requires an initrd?:)
<ogra_> and i want to make f-k work without initrd in the future, its just not top on my TODO (i would have moved it if you said its needed)
<rbasak> I see, thanks
<ogra_> the current initrdless ubuntu stuff is blocked on the kernel team anyway
<rbasak> So while you're here, what's the motivation/need for initrdless ubuntu anyway? Is this documented anywhere?
<ogra_> as long as the kernel doesnt learn about UUIDs its moot to move on
<ogra_> rbasak, 10 second boot vs 30 sec on the panda (and likely other u-boot based arches)
<dannf> faster boot maybe?
<ogra_> right
<rbasak> I see
<rbasak> Wouldn't UUID knowledge end up in the early-userspace code anyway?
<rbasak> The kernel doesn't truly support initrd-less any more anyway - just an embedded miniature initramfs now, right?
<ogra_> well, it would have to be in the kernel itself for us
<ogra_> up to precise initrdless booting still worked fine here
<ogra_> i havent tried anything newer than 3.2 yet
<ogra_> and i bet many embedded people would freak out if linus completely disabled initrdless
<rbasak> OK but it's not been truly initrdless for a while. There's a shim. Knowledge of UUID could be inserted into that shim.
<ogra_> right, that was one of the plans but needs to be done by the kernel team
<rbasak> I see
<ogra_> since that mini initrd lives inside the kernel binary
<rbasak> Yep
<rbasak> I'm with you now - thanks
<ogra_> we'll see if it goes anywhere in the future
<ogra_> ( i start doubting it ... though initrd less booting is on the request list for 5 years or more)
<ogra_> (but so is booting in less than 10sec)
<orated_> Hello! Is there any documentation/wiki where initrd.img  MLO  u-boot.img  uEnv.txt  uImage  uInitrd  zImage files are individually explained?
<prpplague> orated_: same question was just asked on #beagle and i know you are over there
<orated_> Oh, that is answered now! I remember same was questioned and I had exactly the same question yesterday  :)
<orated_> Thanks, I'll catch up in that channel
<dannf> ogra_, rbasak : https://code.launchpad.net/~dannf/flash-kernel/armadaxp/+merge/108066
<dannf> ogra_: rbasak : whups, should be : https://code.launchpad.net/~dannf/flash-kernel/armadaxp/+merge/108070
<janimo> lilstevie, thanks. Do you know a way to root a tf101g with ICS 4.0.3 on it? I found confusing instructions in the forum which do not seem to work (red-belly android on his back). Should the updater take any image called E101_SUPDATE?
<lilstevie> that is old
<lilstevie> like really old
<lilstevie> um
<lilstevie> there is a method that symlinks /data/tmp to /dev/block/mmcblk0p4 that should work
<lilstevie> mmcblk0p4 being the staging partition
#ubuntu-arm 2012-05-31
<janimo> lilstevie, does rooting always mean 1) downgrading to a firmware that has a vulnerability if the firmware is newer + 2) applying an old root method?
<twb> janimo: on what hardware?
<janimo> twb, I am interested in tf101g
<janimo> but for devices with no unlocked bootloader I guess the same generic methdos should apply?
<twb> g is the "prime" one?
<infinity> No, prime is tf201.
<janimo> the asus site docs say theupdater cannot to downgrades so  am not sure how the old root tricks fooled it into it
<janimo> anyway I was a fool to upgrade to ICS before making sure rooting requires a specific version of the firmware present
<twb> I deliberately bought the one with a known SBK
<janimo> twb, I bought the only model still on stock, but before making sure it should be rootable :(. I vaguely remembered all transformers are unlocked or rootable now
<twb> newer ones allegedly are if you ring up asus and ask for the key
<twb> In return for which they refuse all warranties for that particular S/N
<janimo> twb, hmm, you mean I could ring up asus and ask for a secure boot key? Or what key do you mean? I would happily do that if realistic
<janimo> altough I am not sure tf101g qualifies as new enough, it is still last year's model
<twb> janimo: that was on the primes, I heard
<twb> Where "ring up" means some wanktacular web form, I assume
<janimo> yeah, I eard primes are ulockable indeed
<janimo> btw the xda and various other web resources related to rooting are the most disorganized fountains of knowledge I ave ever seen
<janimo> it is relatively little possible information to be conveyed spread across numerous threads and lots of participants
<twb> Well they are web fora
<twb> i.e. fugly HTML usenet for people who are too stupid to configure a newsreader
<Daviey> twb: 'fora'?  Shame, you are one of them.
<twb> My high school did not offer latin, sorry
<twb> https://en.wiktionary.org/wiki/forum#Noun
<twb> fowler (1e) makes no comment.
<twb> Nor does Strunk & White (unsurprisingly, it being quite short)
<twb> Heh, I just noticed the "usage notes" on that URL come from fowler 2e, that travesty
<ogra_> rbasak, hmm, where is that binary header you mention in the review ? the merge page doesnt show anything like that
<ogra_> oh, i'm blind, ignore me
<rbasak> ogra_: np. I'm just doing highbank now. Could you hold off on a merge please?
<rbasak> ogra_: I'm basing my patch on dannf's.
<ogra_> sure, i'll fix the header during merge though, no need to wait for the US to get up :)
 * ogra_ wonders why no image has the new flash-kernel, but they all still build 
<ogra_> looks like we have a to loose dependency chain here, they should fail without it
<janimo> ogra_, is flash-kernel getting unified with the debian one this cycle?
<ogra_> janimo, well, as much as we can at least, depends if we get highbank and armadaxp into debian in time :)
<ogra_> for all the other arches yes though
<janimo> sounds good
<janimo> ogra_, what about the jasper/liveCd stuff, is that migration started?
<ogra_> your hack for updating the bootkloader has to go elsewhere too
<ogra_> no, but we plan to do this switch too this cycle
<NCommander> ogra_: is the hardware database for the new f-k uploaded yet? (I'm not sure which package its in)
<ogra_> it is in f-k itself
<ogra_> infinity wanted to split it out into an arch all package though
<ogra_> NCommander, dannf has done an armadaxp  patch and rbasak works on highbank
<ogra_> so dont worry, its all taken care of
<NCommander> ogra_: wait, I thought the entire point of this was so f-k could be synced, yet the HW database is in the new package?!
<ogra_> first step: sync and make sure all images work again (preferably by not changing flash-kernel but by adapting other packages to match the new world order)
<ogra_> next step: make sure our f-k changes land in debian
<ogra_> last step: split out the db
<NCommander> ogra_: then repeat steps one and two. Doesn't it make mor esense to split out the DB first :-)
<ogra_> no idea, i think it makes most sense to discuss it with debian and have them do the split ;)
<rbasak> /usr/sbin/dpkg-reconfigure: flash-kernel is broken or not fully installed
<rbasak> but apt-get -f install does nothing and there's no other indication of a problem
<rbasak> Any hints?
<rbasak> I need to run, back in an hour :-/
<ogra_> try to dpkg -i the deb
<NCommander> rbasak: is that with the new f-k? I wasn't aware you were taking the new f-k enablement
<ogra_> alÃ¶so the main/universe issues arent solved yet, did you install the necessary packages ?
<ogra_> NCommander, yes, he works on highbank support
<NCommander> rbasak: I'd much prefer having a boot menu, but I realize this has become a time sink now, so ATM, let's roll with the bootz method you had, then I'll get it fixed for the precise SRU/updated for quantal
<rbasak> ogra_: I have a working flash-kernel on highbank now. But one error: http://paste.ubuntu.com/1016144/. This appears to be coming from linux-base because it doesn't recognize flash-kernel as a bootloader. Do we know about this already? Presumably it'll affect all the other boards too?
<ogra_> well, flash-kernel isnt a bootloader
<rbasak> That's fine. But linux-base needs to not complain :)
<ogra_> well, linux-base also need to move to main, i dont expect the switch to work without hassle (never  did) ;)
<ogra_> i'll look into it, atm i'm rather trying to find out why the images dont fail if f-k is missing
<rbasak> I think this should be a Debian issue as well, which is why I'm confused.
<rbasak> f-k depends on l-b, but l-b will complain unless grub or lilo or a bunch of other bootloaders is installed
<ogra_> did you set Bootloader-sets-root in your db entry ?
<rbasak> Yes
<ogra_> to what ?
<rbasak> to "yes".
<rbasak> To override the one supplied by U-Boot, which doesn't know
<rbasak> Previously flash-kernel could write a kernel cmdline into boot.scr, but now it appears that it can't do that any more
<rbasak> But Bootloader-sets-root: yes will work for now
<ogra_> yes means it creates a file in the initrd which needs to contain a UUID
<ogra_> sigh, thats horrible perl in the linux-base postinst
<rbasak> more specifically it overrides the root= kernel parameter
<ogra_> well, yes, if the file exists in the initrd it will use the value in there
<rbasak> Perhaps I could try setting bootargs to omit root= in boot.scr, then I won't need that.
 * rbasak tries it
<ogra_> hmm, i wonder where "DebianKernel::BootloaderConfig" comes from
<ogra_> that seems to be the bit complaining
<ogra_> if (!is_fresh_installation() && version_lessthan($ARGV[1], '2.6.32-18')) {
<ogra_>     DebianKernel::BootloaderConfig::check($deb_arch);
<ogra_> }
<ogra_> that seems to be the code snippet that causes the complaint
<ogra_> and the real issue seems to be that "my @config_files " doesnt have anything for u-boot at all
<ogra_> lool, any idea ? ^^^^
<ogra_> rbasak, hmm, looking closer it doews exactly what its supposed to be, what you see there is a note not an error
<rbasak> ogra_: it stops the install with priority=critical. Not sure why, since the note is priority=high.
<ogra_> well, but we should be able to preseed it differently to quieten it
<rbasak> Shouldn't it be clever enough to detect flash-kernel and shut up?
<rbasak> The warning is meaningless when flash-kernel is in use
<ogra_> flash-kernel has nothing to do with it (as i said, its not a bootloader)
<ogra_> the code looks for known bootloader configs and doesnt know about u-boot
<ogra_> if i read it right it should be possible to switch that off by preseeding linux-base/disk-id-convert-auto to flase
<ogra_> *false
<ogra_> rbasak, do you have a virgin env around you could test that in ?
<rbasak> I can test a preseed option, yes.
<ogra_> or just hack the template of the package :)
<ogra_> which i think we should do if the package moves to main, having it check the bootloader configs just for reading out the latest kernel version from /boot doesnt really make sense
<rbasak> This is stupid though. I know that flash-kernel isn't a bootloader. But when we're using flash-kernel, then that depends on linux-base, and we know that no bootloader is required. So linux-base should not complain. It should detect flash-kernel as an exception to its warning, such that if flash-kernel is present it does not need to check for a bootloader and does not need to warn the user.
<ogra_> well, i beg to disagree :)
<rbasak> The message is "The boot loader configuration for this system was not recognized.". If flash-kernel is present, the boot loader configuration can be recognised. It's recognised as do-not-care.
<rbasak> OK, well I'll file a Debian bug and see what they say about it.
<ogra_> linux-base should learn about u-boot ... not about flash-kernel
<rbasak> flash-kernel is where u-boot knowledge is kept.
<ogra_> not always
<rbasak> Specifically, in that DB now. How else is linux-base to discover the situation?
<ogra_> specifically in debian where you are not required to use it at all for arm images
<rbasak> If linux-base is taking it upon itself to figure out the situation, it should be able to figure out the situation correctly.
<ogra_> right
<ogra_> but it looks for bootloaders not for flashing tools
<rbasak> flash-kernel is no longer a flashing tool
<ogra_> thats its purpose
<ogra_> just because we abuse it differently doesnt change its purpose in debian
<ogra_> what i dont get in the beginning is why linux-base checks that stuff at all
<ogra_> its only a tool to get you the latest kernel version in /boot
<rbasak> just reading up a bit: I'd say that linux-base should be figuring out the situation correctly, so it should be looking for both bootloaders _and_ flashing tools
<ogra_> rbasak, given we carry ubuntu changes in linux-base anyway 8and will go on doing so as long as debian ships perf in there) we should just change the preseed default
<rbasak> I'm testing the preseed as we speak
<ogra_> i will upload a change if that works and we should be done
<ogra_> we really dont want it to touch any bootloader configs in any ubuntu arch anyway
<lilstevie> janimo: downgrades are typically disallowed meaning new exploits are required
<rbasak> ogra_: no luck with the preseed. I tried "linux-base/disk-id-convert-auto boolean false" - was that right?
<rbasak> ogra_: the flash-kernel change is working though, and ready: https://code.launchpad.net/~racb/ubuntu/quantal/flash-kernel/highbank2/+merge/108173
<ogra_> rbasak, awesome, i'll take care for linux-base, dont worry about it
<rbasak> thanks ogra_!
<janimo> lilstevie, I was just looking at 'Wolf'd method' (sounds like some math theorem) on xda-forums which according to some allows ICS downgrades
<ogra_> rbasak, could be be a bit more verbose in the README entry ?
<ogra_> like "Calxeda highbank systems" or something like that ?
<rbasak> ogra_: I started off doing that, then I realised that the machine type in the db needed to match /proc/cpuinfo, and I made the README match that too. I'm not sure if they're doing that with the other machines or not?
<ogra_> no, i dont think armadaxp actually says "Marvell Armada XP Development Board (Ubuntu)" in cpuinfo :)
<rbasak> :-)
<rbasak> Go ahead and change if you like
<ogra_> will do
<lilstevie> janimo: pm me please :)
<ogra_> rbasak, merged and uploaded
<rbasak> thanks ogra_!
<ogra_> rbasak, linux-base uploaded with the postinst removed completely ... bug 1006717 is the MIR in case you want to follow it
<ubot2`> Launchpad bug 1006717 in linux-base "[MIR] linux-base" [Undecided,Incomplete] https://launchpad.net/bugs/1006717
<rbasak> thanks ogra_!
<ogra_> (and i dont think its worth filing a debian bug for linux-base ... it makes totally non-ubuntuish assumptions all over the place :) )
<GrueMaster> ogra_: the "Marvell Armada XP Development Board" in flash-kernel (12.04) was copy/paste from cpuinfo.  Just FYI.
<ogra_> GrueMaster, well, it doesnt have (Ubuntu) appended in cpuinfo i bet
<ogra_> i just think the README entry should get you an idea about the HW
<ogra_> and "highbank" is somewhat not telling you anything :)
<GrueMaster> I couldn't tell you what was in cpuinfo at this point.  I'm a bit removed from the project.  :P
<GrueMaster>  But iirc, I was the one that added the entry to flash-kernel, and it was a straight copy/paste.
<GrueMaster> Since cpuinfo is largely just raw text from the arm soc code (i.e. not derived from silicon), it could have been (knowing Marvell).
<ogra_> well, the db definitely needs the exact match ... the readme not so much
<GrueMaster> Yes, agreed.
<GrueMaster> Anyway, thought I'd add my $.02 worth.  Back to my real job.
<ogra_> heh, have fun
<dannf> ogra_: oh.. did i add Ubuntu to the wrong field?
 * dannf made that change post-test, after merging onto the ubuntu tree - might've screwed that up
<dannf> oh, nope - that's in the README. w/ that i was following suit w/ the precise's flash kernel which appeared to mark Ubuntu-only additions w/ (Ubuntu)
<dannf> but that's not in my debian tere
<XavierMiller> Leave
<janimo> lilstevie, managed to downgrade using wolf
<janimo> wolf's method. great.now on to rooting
<lilstevie> janimo: :)
#ubuntu-arm 2012-06-01
<trelane> hey, I have a bug report on the -PSP kernel from rcn-ee's minimal builds, is that your kernel?  Where should I send it?  Problem relates to plugging in a rtl8192cus
<rcn-ee> trelane, the rtl8192's are 50/50 if they'll work at this point.. i have one that works perfect, and the other that failes on every boot..
<trelane> ok, would dmesg output from insertion/failure be of help?
<rcn-ee> not really... have you tried 3.2-psp13? there's a couple musb fixes...
<trelane> I'll update now and report shortly
 * heathkid waiting on an update...
<trelane> rcn-ee, I used a clean 12.04-r1, and don't see the kernel in apt-get dist-upgrade
<rcn-ee> trelane, i don't have a repo setup for the kernel deb's..  it's mostly manual installling deb's... 3.2-psp13 for precise-armhf is still begin built.. but i have a cross built uImage/modules posted here for another user:  /msg MemoServ READ NEW
<rcn-ee> http://rcn-ee.homeip.net:81/testing/beaglebone/3.2-psp13/
<rcn-ee> as long as my smoke test is sucessful tomorrow, that' actually the default kernel going to be used in my monthly update demo images, this weekend..
<trelane> rcn-ee, sounds good
<Xase> Hi, is anyone here familiar with Ubuntu arm on Android handset, native not chroot?
<scientes> Xase, if its native, its not android
<scientes> also, chroots are native
<Xase> No kidding? I want to remove android.
<Xase> -_-
<Xase> I meant direct. Not side by side.
<Xase> It's still an android handset. Well at least till I remove Android.
<orated_> Hey prpplague
<prpplague> orated_: greetings
<orated_> prpplague: I'm trying to get ethernet working on BB B4 running Ubuntu 11.10 kernel 3.2. I asked in #beagle about the same and got directed here. Could you help me on that?
<prpplague> orated_: sorry i can not, i am sure someone here who normally does ubuntu stuff can possible help you
<orated_> Sure, I'll try
<orated_> Hello! I'm running Ubuntu 11.10 kernel 3.2 on BeagleBaord B4. Both the BeagleBoard and USB hub are externally powered with 5V supply. lsusb, ifconfig outputs as shown here - http://paste.ubuntu.com/1018497/ - How can I get ethernet working?
<orated_> I've a usb hub connected to the OTG port. A usb-ethernet adapter is connected to the hub. And a RJ45 cable from one of the four  ports of the router is connected to it. Second port of the same router is connected to the host system
<Xase> sudo if up usb0 ?
<GrueMaster> Hub off the OTG port?  Why not try the single USB port?  I'm not sure if the OTG port is enabled in the main kernel.
<Xase> sudo dhcpd?
 * GrueMaster didn't look at the pastebin output first.
<Xase> :P
<Xase> Hello GrueMaster. Probably dont remember me, but  hello nonetheless.
<GrueMaster> Been a while.  How's it going?
<Xase> Good. Still twiddling with my nook. id put serious effort into it but my computer  is beyond junky
<orated_> Xase: GrueMasterJust a moment, BB is not accepting commands, restarting
<orated_> Xase: sudo ifup usb0 gives - Ignoring unknown interface usb0=usb0.
<orated_> And sudo dhcpd, command not found
<orated_> GrueMaster: There is no USB port on Beagleboard B4, only USB OTG
<Xase> hrm my linux knowledge is short when it comees to networking :(
<orated_> Same here
<TypoNAM> that sucks orated_, I've used a beagleboard rev C and had USB ethernet networking with one of linksys's adapters with vanilla kernel. I used the working populated USB port and a powered USB hub to connect the keyboard, mouse, and ethernet adapter to :P
<TypoNAM> so I'm not sure if the OTG port will work the same way
<orated_> Probably its hardware defect. Or some kernel patch missing. - http://elinux.org/BeagleBoard#USB https://groups.google.com/forum/?fromgroups#!topic/beagleboard/KtUXwhWm2r4
<GrueMaster> orated_: I am not that familiar with the rev B board (I have a C4).  As I said earlier, I am not sure if the OTG port is enabled in the kernel.
<orated_> Thanks, I'll find about that
<orated_> I require network connection only for installing xfce and OpenCV related packages. Is it possible to chroot to the fs from the host to achieve the same? So that I can atleast start with the main task instead of getting stuck ...
#ubuntu-arm 2012-06-02
<janrinze> hi all, are there people here who have Ubuntu 12.04 installed on a Transformer TF101?  i have some questions about powersave and suspend modes
<janrinze> lilstevie: hi, is there any new work done on suspend/resume for the TF101?
<lilstevie> at the moment? no, I have been busy with uni
<janrinze> ah. ok
<janrinze> lilstevie: on Ubuntu 12.04 the screen saver kicks in quite swiftly but after that login is not really possible anymore due to looping..
<lilstevie> well then change the settings :)
<janrinze> true..
<lilstevie> tell it not to sleep
<janrinze> even with that it appears to go to sleep anyway..
<lilstevie> the up-to-date tree reboots on sleep
<lilstevie> wait, are you meaning how on power on it loops
<janrinze> there is no apm deamon running
<lilstevie> cause that is pulseaudio crashing lightdm
<lilstevie> if not, the display turning off looks like sleep
<janrinze> lilstevie: i am loged in over shh too and that works. however it will drop into powersave afer a few seconds again
<lilstevie> on initial boot yes?
<lilstevie> like you haven't logged in yet
<janrinze> the ssh becomes a bit slow to respond and the screen flips on after i type something in ssh :-)
<lilstevie> sudo apt-get autoremove pulseaudio
<janrinze> lilstevie: the pulseaudio is removed already, that was quite a challenge with the login issues :-)
<lilstevie> ok, disable sleep
<lilstevie> and it won't go to sleep
<lilstevie> make sure you tell it to never sleep for both on battery and on ac
<janrinze> having trouble to do anything at all on the desktop since it keeps cycling..
<janrinze> after a reboot all is fine. But once a sleep was initiated it will cycle again
<lilstevie> yes, so do it before it goes to sleep
<janrinze> :-) true again
<lilstevie> I only turn the screen off on my device
<lilstevie> sleep is turned off entirely
<janrinze> do you know of other people working on the kernel for the TF101?
<lilstevie> yes, but I wouldn't trust their kernels on my device :/
<janrinze> aha.
<lilstevie> http://forum.xda-developers.com/showthread.php?t=1683145 welcome to try it though
<janrinze> lilstevie: what is the best/recent kernel for the tf101?
<lilstevie> I don't agree with certain things like overclocking to 1.6 by default though
<janrinze> i am willing to roll my own ;-)
<janrinze> overclocking is not my aim.. stability is
<lilstevie> well there is https://github.com/lilstevie/linux_kernel_TF101
<lilstevie> that is the one I have running
<lilstevie> sleep looping is not an issue cause it will reboot :p
<janrinze> ok. i have Linux Tegra2 2.6.36.4 #5 SMP PREEMPT Fri Nov 4 22:21:17 EST 2011 armv7l armv7l armv7l GNU/Linux
<janrinze> that one is supplied in your OLiFE Prime package
<lilstevie> stackprotector is a little touchy and sleep breaks it
<janrinze> aha
<janrinze> i have worked on kernels for many ARM devices in the past and sleep was always dodgy..
<janrinze> so i am not surprised here ;-)
<lilstevie> hah
<lilstevie> sleep worked
<janrinze> lilstevie: but loops
<lilstevie> no
<janrinze> oh, what changed?
<lilstevie> I mean I had sleep working at one point
<lilstevie> I recompiled
<janrinze> aha
<lilstevie> must have exhaled at the wrong time
<janrinze> yeah, i know what you mean..
<lilstevie> because now it will not
<janrinze> is there stuff going upstream to main kernel?
<janrinze> would be nice to recompile a kernel from kernel.org and run that ;-)
<lilstevie> not likely
<janrinze> 2.6.36.4 is good enough for what i need a.t.m. so i might take a shot at building from your git repo
<lilstevie> heh
<janrinze> i have a lot of ARM boards laying around but none of them are Tegra 2.
<lilstevie> as long as it gets the device booting right
<janrinze> yeah
<janrinze> usually fbdev + usb is my main concern
<lilstevie> well fbdev and usb work :p
<janrinze> if that works (and networking of course) I can get most things working.
<lilstevie> yeah
<lilstevie> I can work with a little less :p
<janrinze> did uboot get any further?
<lilstevie> uboot is a pointless dead end :)
<janrinze> oh. because booting from a separate SDcard would be interesting.
<lilstevie> yeah, well we have been working on some stuff using kexecboot which has been promising
<lilstevie> at least on the tf201
<janrinze> is kexec not working on tf101?
<lilstevie> well tf201 has been higher priority cause I haven't officially released anything for that one yet
<lilstevie> :)
<janrinze> lilstevie: have you tried kexec on the tf101?
<janrinze> lilstevie: # CONFIG_KEXEC is not set .. from /proc/config.gz :-(
<lilstevie> if only it were that simple :p
<lilstevie> there is hardware that will not handle a kexec
<lilstevie> well, more the drivers are not built for it
<janrinze> hmm.. the tf101 specific drivers won't survive kexec.. ok
<lilstevie> we are using a derivation of http://forum.xda-developers.com/showthread.php?t=1266827
<lilstevie> we don't know what parts are not surviving cause it prevents the kernel being kexec'd to from booting
<lilstevie> but that hardboot works fine
<janrinze> if hard-boot works fine then i can kexec with args to boot from SDcard :-)
<lilstevie> you can boot from sdcard now
<lilstevie> you just need to edit the bootimg.cfg for the kernel image
<janrinze> how? that was not in the wiki nor in the readme
<janrinze> ah, but that is statically changing the pootparams
<janrinze> bootparams are flashed with nvflash.. right?
<lilstevie> no
<lilstevie> with the bootimg
<lilstevie> which can be flashed from userspace too
<janrinze> hm.. interesting..
<janrinze> lilstevie: dd from and to the bootimg partition i guess
<lilstevie> no
<janrinze> mount it?
<lilstevie> packing into a blob and dding to the staging partition
<lilstevie> boot partition is outside of the partition table
<lilstevie> bootloader is responsible for flashing it
<janrinze> the blob packer is new to me. most systems i use have u-boot so i can work with that quite well..
<janrinze> lilstevie: which partition is the staging partition?
<lilstevie> mmcblk0p4
<janrinze> i have that mounted under ext3
<janrinze> so putting the bootimg in there would suffice?
<lilstevie> no
<janrinze> and resetting the device of course
<lilstevie> it shouldn't be mounted
<lilstevie> just dd straight to it
<janrinze> ok, will try that once i have built the kernel.
<janrinze> lilstevie: when shutting down while in android i chose 'restore' option which now makes linux the default to boot. :-)
<lilstevie> heh as long as you remember to clear the tag
<lilstevie> also blobs will not flash if there is a tag in misc
<janrinze> i also did a 'wipe' which cleaned out the other partitions and they now show up in Linux as 4 partitions
<lilstevie> system, cache and data will always
<janrinze> is that the misc dir in mmcblk0p7 ?
<janrinze> lilstevie: /dev/fb1 is that a second framebuffer for hdmi output?
<lilstevie> misc is mmcblk0p3 like the whole thing
<lilstevie> and fb1 is the second framebuffer
<janrinze> oh. ok :-)
<lilstevie> doesn't always mean hdmi but in this case yes
<lilstevie> tegra fb1 can be hooked up to a few different busses
<janrinze> i was thinking to use that as a second monitor :-)
<janrinze> hopefully to get it to output 1920x1080
<lilstevie> without the tegra proprietary drivers that isn't happening :)
<janrinze> :-(
<janrinze> so 1280x720 should at least be possible or does it mean no hdmi at all?
<lilstevie> no hdmi at all
<janrinze> :( !!
<janrinze> how do the tegra drivers (beta releases) fit in there?
<janrinze> nvidia seems to provide some
<lilstevie> incompatible with the kernel
<janrinze> ok. so i would need a different kernel then. 3.x ?
<lilstevie> you would need a kernel that works on the device
<lilstevie> that has the interface
<lilstevie> that one I linked to before does
<lilstevie> but as I said I wouldn't trust it on my device
<lilstevie> if for no reason other than it burns the cpu at 1.6GHz
<lilstevie> (I do have other reasons though)
<janrinze> ok. i can understand
<janrinze> best would be then to get those sources and remove the 1.6 GHz stuff and build
<janrinze> will look into that.
<janrinze> lilstevie: do you know why/if XShm is supported? i get an error : X Error of failed request:  BadAccess (attempt to access private resource denied)
<lilstevie> hm
<lilstevie> not seen that
<janrinze> i have a program that uses XShm, it is not from Ubuntu
<janrinze> http://code.google.com/p/rtviewer/
<janrinze> lilstevie: ipcs shows that the kernel is not configured for shared memory, semaphores and message queues!
<janrinze> lilstevie: you still here?
#ubuntu-arm 2012-06-03
<janrinze> lilstevie: you still here?
<lilstevie> janimo: not really
<janrinze> lilstevie: lookslike there is no SYS V IPC in your kernel
<janrinze> lilstevie: rebuilt a kernel but it does not boot. will retry with the defconfig from your sources
<lilstevie> janrinze: yeah, sysvipc is missing from the released kernel
<lilstevie> but the kernel on git has it
<janrinze> lilstevie: apparently that is causing the XShm to fail..
<lilstevie> also, use the android ndk toolchain to build the kernel
<lilstevie> tegra is really really dodgy
<lilstevie> and breaks easy
<lilstevie> :p
<janrinze> huh android ndk toolchain? why?
<lilstevie> because that is what works without errors
<janrinze> does gcc from Ubuntu not build working kernels?
<lilstevie> and what asus use
<lilstevie> gcc from ubuntu "works"
<lilstevie> I was using it
<lilstevie> but it causes more problems than its worth
<janrinze> what kind of problems?
<lilstevie> compile errors galore
<janrinze> ah during module build, right?
<lilstevie> and in some cases non booting kernels
<lilstevie> not only during module builds
<janrinze> hmm.. that would be a serious issue.. does that mean Tegra is not fully ARM compatible?
<janrinze> or does it mean Tegra has bugs that need work-arounds?
<lilstevie> no, just that it is fragile
<janrinze> hmm.. weird. I have not had that problem with any other ARM platform before.
<lilstevie> I have had it on hummingbird
<janrinze> hummingbird, Samsung?
<lilstevie> yes
<janrinze> same as Exynos?
<lilstevie> it is older
<lilstevie> they call them exynos now
<janrinze> oh, ok because the Exynos (dual core A9) works fine here too..
<lilstevie> but the cpu that powers the original galaxy tab, and the galaxy s i9000
<lilstevie> these are single core A8s
<janrinze> hmm.. rebuilt a kernel but that one does not boot either..
<janrinze> lilstevie: tf101-gnu-linux-defconfig is what i have used.. is that correct?
<janrinze> lilstevie: i built the kernel natively on the TF101.
<lilstevie> yeah probably an error there
<janrinze> most likely. But how do you 'see' the console output or the boot log ?
<lilstevie> if you haven't seen it there isn't any
<janrinze> :-(
<janrinze> so no way to figure out what goes wrong?
<lilstevie> you could enable the android ramconsole driver
<lilstevie> with that enabled it will be at /proc/last_kmsg
<janrinze> hmm..
<janrinze> serial console over USB would be a lot more sensible ;-)
<janrinze> lilstevie: do you use the latest version of your git repo? the initrd in the OLiFE download may be to blame..
<janrinze> lilstevie: weird.. the original kernel won't boot either anymore now.
<lilstevie> janrinze: if you want serial console, ask asus for the pinout, I asked and got no response
<lilstevie> also are you flashing it with nvflash or blobs
<janrinze> I use OLiFE.. so i think nvflash
<lilstevie> to primary or recovery boot
<janrinze> recovery i guess, the primary is Android
<lilstevie> k
<lilstevie> IDK then
<lilstevie> should be working
<janrinze> i saw something about 'wiping' the disk.. perhaps i need to reinstall everything..
<lilstevie> :/
<janrinze> ok.. my bad, still was copying my own kernel to the device :/
<janrinze> linux has booted again..
<janrinze> lilstevie: can you send me a working .config for your git kernel?
<janrinze> lilstevie: apparently self-built kernels won't boot.. how do i get a kernel with SYS V IPC enabled?
<janrinze> lilstevie: the compiler supplied with the Android-NDK is not able to compile your kernel. many errors like "arch/arm/mach-tegra/suspend-t2.c:75: error: pllx causes a section type conflict" and more conflicts
<marvin24_DT> must be an ancient kernel ...
<marvin24_DT> 3.1 already?
<marvin24_DT> (sorry, just jumped in)
<janrinze2> lilstevie: i managed to build a working kernel :-)
<janrinze2> unfortunately the file browser in unity does not allow to add custom file handlers to be configured
<janrinze2> looks like 12.04 is a neutered version of Ubuntu
<janrinze2> i had better get Debian running on this device.. Ubuntu has become a toy OS.. unity seems to be built for noobs that need to be kept away from configuring anything at all...
<micahg> umm, isn't that nautilus?
<janrinze2> nautilus on Debian is easy to reconfigure, on 12.04 however it seems to be stripped of all configuration possibilities
<janrinze2> actually most stuff in unity seems to work counter intuitive
<micahg> I would think that's more upstream decisions, are you trying the version in unstable or stable?
<janrinze2> it probably is just me but i feel extremely restricted by unity
<janrinze2> i use 12.04..
<janrinze2> i have a program that is a raw file viewer. it needs to be associated to dng, pef, nef etc..
<janrinze2> apparently there is no way to do that in ubuntu 12.04
<janrinze2> micahg: do you know a work-around?
<micahg> if you haven't tried Debian unstable or testing recently, I'm saying that it might have been upstream GNOME that restricted it, as for associating, does a ~/.mailcap file help?
<micahg> #ubuntu might be able to help further
<janrinze2> hmm.. the irc client just crashed
<mythos> today comes my pandaboard \o/
<mythos> hmm... *will be delivered
<mythos> so ^^"
<janrinze2> at #ubuntu there is no help for changing file associations
<janrinze2> quite frustrating
<mythos> janrinze2, so you say, there is no way to define to use e.g. mplayer for avis?
<mythos> hmm... i'm quite tired... so my grammar is getting worse and worse
<janrinze2> nope only select from the list that is presented
#ubuntu-arm 2013-05-27
<infinity> angs: That's more of an openssl question than an ARM question, you'll have to read the source to see how it got there.
<infinity> angs: Also, given that Ubuntu doesn't run on anything less than armv7, I suspect this isn't really an #ubuntu-arm question. :P
<angs> yeah it is debian-arm :) I just wanted to ask here because debian and ubuntu are close to each other and nobody on #openssl replies
<infinity> Well, I think it's fair to point out that the openssl source package builds on Debian armel, which is armv4t, so you could just be doing something weird/wrong there.
<angs> I added "#define __ARM_ARCH__ 4"  in the beginning of the library, now it compiles the source without problem. although I am afraid it will cause a problem on the runtime
<angs> what does 4 stands for on armv4t?
<infinity> It stands for.. 4.
<infinity> As in ARMv4
<infinity> If your compiler isn't defining __ARM_ARCH_4__, you probably have bigger issues.
<doomlord> will ubuntu-arm run on the MK908 , if not what would be the issues in getting it to woork
<RagBal> Has anbody got Ubuntu core to work on BeagleBone? I can't seem to get the network interface to work after booting
<maxinux> yes
<maxinux> im 100% up on beaglebone black + ubuntu
<maxinux> ... power will be your next issue you run into :)
<maxinux> initializing ethernet will exceed usb power
<RagBal> Hmm
<maxinux> whats the issue your running into specifically?
<RagBal> Well I got it to boot, but when I try to use any network related stuff it gives me an error
<maxinux> ethernet cable is plugged in? whats ifconfig say?
<RagBal> I have to put the rootfs back on the SD to give you the exact erorr =)
<RagBal> ifconfig is not there yet
<maxinux> you are not running the image from armhf?
<maxinux> just load the base image up
<RagBal> I'm using the ubuntu core rootfs
<maxinux> beaglebone, or black?
<RagBal> http://cdimage.ubuntu.com/ubuntu-core/releases/13.04/release/ << ubuntu-core-13.04-core-armhf.tar.gz
<RagBal> Black
<maxinux> www.armhf.com/index.php/boards/beaglebone-black/
<maxinux> use the image :)
<maxinux> make that work first
<RagBal> Yea got that to work
<maxinux> no ifconfig, means no way to setup the interface
<maxinux> ifconfig and probably dhclient3 needed
<RagBal> What about 'ip'? Should be enough to configure it
<maxinux> iproute2 can handle it, yes
<maxinux> must setup your route and your ip
<maxinux> ip add <blah> and ip route add default gw ...
<RagBal> But I want to know what changes or additions are made to that rootfs from armhf so I can reproduce them =)
<maxinux> fair
<maxinux> if you made the image work once no probs with that :D
<maxinux> so you probably said something about no route?
<RagBal> Nope, it gave a weird error, let me try to recall it
<RagBal> maxinux, hmm I can't seem to boot it anymore, the kernel complains about no init found, try passing init= option to kernel
<maxinux> init=/sbin/init
<RagBal> Ah one sec
<maxinux> or /bin/init, but should be sbin
<RagBal> I see the init ini /sbin/init and pass it with the bootargs but it still refuses to find 'init'
<maxinux> ok time for my ubuntu arm question if anyones around.. also beaglebone black, using the armhf image  ... package management seems to be a complete fail... apt-get reports unable to locate packages, but the sources.list looks right to me
<hrw> maxinux: 1. pastebin output of 'apt-get update;apt-get install nano'
<hrw> then we can talk
<hrw> otherwise we waste our time
<maxinux> nbd.. 30s...
<maxinux> so nano is already installed on this image to begin with.. so that doesnt give much debugging info, but the errors from nmap are stil ldisplayed
<maxinux> http://pastebin.com/HEFhfrQ3
<maxinux> i wonder if going 12.04 instead of 13.04 would be wise
<hrw> run 'apt-get -f install'
<hrw> 13.04 is best you can get
<hrw> just it is visible that you got broken image to start with
<ndec> maxinux: did you start with a 'real' image from ubuntu.com, or did you make up an image (ubuntu-core, or debootstrap)?
<maxinux> is ther a real image on ubuntu.com ? i got the image from armhf.com
<maxinux> it seems its complaint was version not meeting what was required... so maybe just bad sources.list?
<hrw> maxinux: have you run 'apt-get -f install'/
<hrw> ?
<maxinux> yeah, that worked interestingly
<maxinux> it loaded libpcap 0.8 instead of 0.98 or newer
<maxinux> etc
<maxinux> which seems.. bad
<hrw> never mind - it has to fix your package database
<ndec> hmm.. i didn't know about armhf.com!
<maxinux> yeah, that seemed to do it
<hrw> after it finishes you can install anything
<maxinux> yeah, seems so, thanks!
<maxinux> that was silly
<maxinux> if i was gonna load x on here, whats the best meta package?
<hrw> I would go for xfce
<ndec> you can start with openbox
<maxinux> xfce is what i used to always use on slower hardware
<hrw> with modesetting x11 driver for start
<maxinux> cool, after that silliness (i usually try to avoid -f(orce) flags.. i should be set... only new to arm, not linux :)
<hrw> ;)
 * hrw off
#ubuntu-arm 2013-05-28
<wookey> doko: did you notice that you can't install crossbuild-essential-armhf and crossbuild-essential-arm64 in the same fs, because /usr/share/doc/gcc-4.7-base/copyright is differrent between gcc-4.7-base_4.7.3-1ubuntu1_armhf.deb and gcc-4.7-base_4.7.3-1ubuntu1_arm64.deb
<wookey> I haven't checked what's actually different yet.
<wookey> or whether I am just confused about something...
#ubuntu-arm 2013-05-29
<ra-fi> hi i have used at91sam9x5 ek board and i have used buildroot toolchain i would like to use qt based terminal emulator can you please suggest me any terminla emulator
<LetoThe2nd> ra-fi: you want a terminal emulator on your dev host to connect over serial, or what isthe question exactly?
<ra-fi> LetoThe2nd yes i need to connect my at91sam9x5 ek target on serial like ttyS0.
<LetoThe2nd> ra-fi: putty, or screen for example.
<hrw> picocom in any terminal?
<ra-fi> LetoThe2nd even before i have been trying many qt based terminal application but those all are not suited for my needs and i have not used Xorg supports in my target,and now i have tried qtterm serial emulator from qt it compiled successfully and  when i try to select /dev/ttyS0 it also selects but it does not perform any action when i give the commands like pwd,ls,ps...
<LetoThe2nd> ra-fi: i have no clue what you are talking about, i cannot understand that.
<ra-fi> LetoThe2nd sorry i am fresher for linux, ok, i have downloaded a qt based terminal emulator source from web which is 3BpiQtTerm01.tar.gz,and i cross compiled for at91sam9x5 board using buildroot toolchain and run the application it works but when i try to execute commands it does not work,.
<LetoThe2nd> ra-fi: sorry, but as this is #ubuntu-arm, i think what works on your buildroot rootfs or not is a bit offtopic.
<LetoThe2nd> ra-fi: i thought you were talking about running a terminal emulator on your ubuntu development desktop.
<LetoThe2nd> and ubuntu certainly does not run on the at91.
<ra-fi> LetoThe2nd oh its ok thanks for your effort
 * ogra_ wonders why anyone would run a terminal app *on* a board
<LetoThe2nd> ogra_: because, probably
<ogra_> ah, ineed, that clears it up
<ogra_> +d
<Snark> hi
<Snark> I saw a samsung chromebook in a store
<Snark> tried to find the little switch for the developer mode... and didn't find it
<Snark> it was a XE303C12-A02FR
<Snark> is it a developer-mode-less version!?
<hrw> Snark: key combination enables devmode
<hrw> Snark: very nice machine for arm development
<hrw> Snark: you live in France?
<Snark> yes
<Snark> oh, for the arm chromebook, it has been virtualized!
<hrw> Snark: does it has AZERTY keyboard?
<Snark> I had read a page for the other chromebook
<Snark> hrw: yes!
<hrw> fu :D
<hrw> Snark: 13.04 should work quite fine on it
<Snark> I was thinking about crouton
<hrw> feel free
<hrw> I just prefer to use systems directly rather than chroots
<Snark> I generally also do, but if I can get something usable more easily...
<Snark> (I'm using git for most of my stuff, so it's easy to reinstall if I change my mind)
<hrw> ;)
<hrw> bbiab
<hrw> guys: alsa-lib 1.0.27.1 contains UCM profiles from Ubuntu ;)
<wookey> does anyone here know what automake for 'build this program for the BUILD arch' is?
<hrw> wookey: BUILD_CC etc?
<wookey> yes, but how does that go in an automake file that has "noinst_PROGRAMS = i386_gendis"?
<hrw> I usually create a rule for such binaries
<wookey> (i386_gendis gets run later to generate a header file)
<wookey> OK, so if I add a specific rule for creating that binary that'll overwrite the default rulkes, and let me use $BUILD_CC. Something like that I guess
<purezen> Hey guys..! I have lately been running Ubuntu of my ARM chromebook.. And was hoping to find opportunities to get involved in the same..
<purezen> Hope you guys could list me some..
<hrw> purezen: you mean 'how can I help with ubuntu on chromebook'?
<purezen> In fact, I am posting this from my Chromebook itself.. 13.04 XFCE..
<purezen> hrw: I mean.. I would basically like to get involved in the same..
<hrw> purezen: there are few things to do
<purezen> Like getting Ubuntu to run on Chromebook.. i.e. polishing some existing processes..
<purezen> hrw: Ok..
<hrw> 1. write better installation howto then my blog posts ;D
<purezen> hrw: Oh.. well..:-D
<hrw> 2. add chromebook support to flash-kernel so kernel updates will be easier
<purezen> hrw: Ok.. I would need some more info. on that..
<hrw> 3. find out the reason and fix plytmouth issue
<purezen> hrw: Well.. I will have to look into that..
<hrw> 4. package 3.8/chromeos kernel
<purezen> hrw: Ok..
<hrw> I have 4th partially done but my chromebook is restored to chromeos and waits for samsung to get it repaired (I want speakers back)
<purezen> hrw: Ok..
<purezen> hrw: And by 4 you mean.. package for the Ubuntu repos..?
<hrw> we have 3.4/chromeos in repo so it is easier then it was
<hrw> purezen: sure
<wookey> purezen: and debian
<purezen> hrw: Ok..
<hrw> wookey: for Debian we can get 3.10-rc mainline with very partial support
<hrw> wookey: so far I did not noticed change in kernel policy in Debian
<purezen> wookey: Well..
<wookey> yeah just trying to discourage packages that only go into ubuntu. Do whatever can be done upstream upstream
<hrw> wookey: ucm profiles are on a way to debian - Jorgi packaged 1.0.27.1 which has them
<purezen> One thing though.. Basically guys.. am an engineering undergrad.. and a FOSS enthusiast.. So I was basically looking for opportunities to get involved in the summer..
<hrw> kernel signing tools are in Debian
<hrw> what left in Ubuntu is kernel and x11 driver
<purezen> Anything I can do to 'better' the graphics support for the same..?
<purezen> So guys.. To begin with I would need headers to approach the given tasks..
<purezen> Can you guys give me headers on approaching the 2nd task..?
<wookey> check out flash-kernel sources and automate whatever manual runes are used now. (I don't know runes for that)
<wookey> it has a sensble structure these days, so shouldn't be too hard
 * hrw out
<purezen> wookey: Thanks.. shall have a look at it..
<purezen> Also, hope you can tell how do I keep in touch with the developments regarding the same..?
<wookey> I don;t know where the chromebook people hang out. THis channel is quirte a good start
<ogra_> for ubuntu stuff thats definitely true
<purezen> wookey: Ok..
<purezen> wookey: Also, am quite new to this stuff.. so I hope it did be sufficient to communicate here..
<wookey> sure. you are doing fine so far. Ask if you don;t know how/where to find stuff
<purezen> wookey: Ok.. Thanks..:-)
#ubuntu-arm 2013-05-30
<houkouonchi-work> Anyone know what update the /boot/vmlinuz and /boot/initrd.img symlinks?
<houkouonchi-work> installing a linux-image debian package doesnt appear to be doing it so rebooting the machine after it loads the wrong kernel: http://pastebin.com/raw.php?i=cyiaYFbF
#ubuntu-arm 2013-05-31
<infinity> houkouonchi-work: It's the linux-image postinst that's meant to twiddle them.
<houkouonchi-work> infinity: well if you check my pastebin it doesn't appear to be doing it or do you have to do something special when making the linux-image .deb to get it to do that?
<infinity> houkouonchi-work: Well, the distro packages are clearly working, since your links point to -31- and -30- for current and old.
<infinity> houkouonchi-work: So, I'd assume your postinst is different from ours.
<infinity> houkouonchi-work: At which point, I can't say how yours is different, cause I haven't seen it.
<infinity> diff -u /var/lib/dpkg/info/linux-image-{3.5.0-31-highbank.postinst,3.9.0-ceph-b5b09be3-highbank} should be enlightening.
<infinity> houkouonchi-work: If you're producing yours with make-kpkg, rather than using our kernel packaging, it will probably be quite different.
<houkouonchi-work> well when you build a debian with make 'deb-pkg' do you need to specify something special to get it to do the the symlinks?
<infinity> See above, we don't use make-kpkg, we build our kernels as proper Debian source packages (from the 'linux' source package), so the method is quite different.
<houkouonchi-work> big differences ok so its part of the postinstall script of the .deb hmm
<houkouonchi-work> http://pastebin.com/raw.php?i=HwMs9Qr1
<infinity> You want a unified diff (-u), if you want that to be readable...
<houkouonchi-work> really the post install of the one i built is pretty much nothing
<infinity> Oh, but true, the make-kpkg one is mostly empty these days, it would seem.
<houkouonchi-work> yeah its pretty much non-existent
<infinity> So, it would seem there might need to be a hook script to do the symlink twiddling in the new world order.
<houkouonchi-work> http://pastebin.com/raw.php?i=HVBtbRWg <-- inline one not that its saying much
<infinity> (Or, use the Ubuntu packaging for your kernels instead, if your goal is just to add some patches to the highbank kernel...)
<houkouonchi-work> well its more like build kernels using newer ceph-client stuff
<houkouonchi-work> not really just a matter of patches
<houkouonchi-work> Do you think stealing the post install script off the ubuntu one is likely to work with a different one. It looks pretty generic so a quick look over it by me looks like it would probably work?
<infinity> Possibly.
<infinity> Though seems like overkill if all you want is the symlink twiddling.
<houkouonchi-work> i guess my $version is being specified in the file though... Yeah I guess I am just trying to figure out the best way to automate this
<houkouonchi-work> these kernel packages are all automated and the installation/testing is automated too the problem is if that symlink isnt correct when the machine is rebooted u-boot isnt loading the kernel
<houkouonchi-work> even though it says its flashing with it during the installation of the package...
<houkouonchi-work> might be easier if we just create the symlink in our code-base that does the testing after it does the install rather than doing it with the post install of the .deb I just wasnt sure what handled that stuff. Not super familiar with the .deb packaging system
<infinity> Well, there is no "flashing" to do with flash-kernel on highbank, that's a bit of a lie.
<houkouonchi-work> Thanks for the help
<houkouonchi-work> infinity: then it makes sense why it didnt boot the kernel =)
<houkouonchi-work> cant wait for these newer arm hardware. Even with like 10+ nodes and distcc it takes a long time to build stuff on them heh
<infinity> So, Debian's kernel postinsts are also still the massive long Perl postinst.
<infinity> I wonder why make-kpkg's is so anaemic.
<infinity> Waaait, so is the one in make-kpkg.
<infinity> houkouonchi-work: How are you building these kernel packages?
<infinity> houkouonchi-work: Are you using "make-kpkg" from the "kernel-package" package?
<infinity> houkouonchi-work: Cause that should provide you with something with the complex/useful postinst.
<houkouonchi-work> infinity: its kernels from git doing make debb-pkg
<tharvey_home> where did ubuntu core for 11.10 go?  I see lots of references to http://cdimage.ubuntu.com/ubuntu-core/releases/11.10 yet it doesn't exist (removed as 11.10 is no longer supported?)
<infinity> tharvey_home: 11.10 is EOL and gone, yeah.  Use 12.04.
<tharvey_home> so is core just another rootfs like server, desktop, cloud are?  is core the only one that supports arm?
<infinity> core is just a minimal rootfs with pretty much nothing installed but essential packages and apt.
<infinity> We also have full installer images for some platforms (like omap4/Panda), but not many.
<tharvey_home> would you call 'server' and 'desktop' a rootfs too then?
<infinity> And netboot installer images for things like highbank and armadaxp.
<infinity> server and desktop are installers, not rootfses.
<tharvey_home> where are the installer images and how would I go about creating one for a different board?
<infinity> http://cdimage.ubuntu.com/netboot/ for netboot images, http://cdimage.ubuntu.com/releases/12.04/release/ for some installer images.  Creating one for a specific board isn't trivial, and not something I'd try to explain at 1:30am.
<infinity> This is all very much a hacker's game right now, still.  It's not easy to give simple "this is how you do it" instructions for booting a board we don't support.
<infinity> But that's slowly changing with generic multiplatform kernels.
<infinity> Slowly.
<tharvey_home> well, I know how to 'boot' my board with say the core rootfs, I'm just not clear what the 'installer image' does for me - perhaps make it easier for someone to repeat my process less manually?
<infinity> tharvey_home: Possibly that, yeah.  But it's certainly not a necessity for people to have shiny installers, if you can give people simple instructions on booting and jamming a kernel/config into ubuntu-core.
<tharvey_home> looking at some of the installer images - I see they are just the bins needed like the bootloader, and kernel, boot scripts and then the .img* files are ie usd images you would dd to the usd?
<infinity> tharvey_home: The .img files are DDable to SD, yeah.
<infinity> tharvey_home: And for some platforms (androidish platforms, like ac100 or nexus devices), we provide a bootimg to stuff in the boot partition.
<tharvey_home> so the images presume a specific sized uSD for example?
<infinity> tharvey_home: The old preinstalled images we used in 12.04 actually just auto-resize to fill the card on first boot.
<infinity> tharvey_home: The images we did for 12.10 and later use the same installer as x86 desktop images and expect to install FROM the card to an external storage device (like a USB hard drive).
<tharvey_home> ah... neat.  Is there someplace I can see the installer script that does the auto-resize for the 12-04 images and the script that does the installing for 12.10?
<infinity> The "script" that does the installing for 12.10 is ubiquity.  It's the full desktop installer.
<infinity> The auto-resizing magic in 12.04 is in the jasper-initramfs package.
<tharvey_home> and what is used to 'build' the img file (what dictates the packages and actually installed them to a rootfs)?
<infinity> tharvey_home: That's a combination of live-build/livecd-rootfs, and the finishing touches are cdimage.  That's the part(s) of the process that I hinted at being pretty complex and not something for a 1:30am conversation. :)
<tharvey_home> infinity, no worries - thanks for the explanation
<LetoThe2nd> for the record_ he/she is banned in #pandaboard now
<hrw> who?
<hrw> morphis?
<LetoThe2nd> yes.
<brykt> Hi.
<brykt> I have installed ubuntu for ARM on a beaglebone black. Should it be possible to login to the BBB via ssh  when it has booted. I am able to ping the BBB, but when I try the ssh into it i get: ssh: connect to host 192.168.1.70 port 22: No route to host
<maxinux> yes you should be able to
<maxinux> can the bbb ssh into itself?
<brykt> I tried using "ubuntu" and "root" as users but still no luck.
<brykt> How do you mean ssh into itself?
<maxinux> ssh from it to it :)
<brykt> I dont have any acces to temrinal. My mointor does not work with the mini-HDMI output.
<ogra_> well, did you set up the network and did you install ssh ?
<hrw> ogra_: I just had to ask the same ;D
<ogra_> we dont offer any official images for the beagles anymore, best is to talk to the person who created that image
<maxinux> are you using the armhf image brykt?
<brykt> I flashed the eMMC by booting up from the mini SD-card....
<brykt> I dont know how to set it up.
<maxinux> so you got the image from armhf.com?
<brykt> I used the image from this page:
<brykt> http://elinux.org/BeagleBoardUbuntu#eMMC:_BeagleBone_Black
<ogra_> well, find the person who created it
<maxinux> ive not used that image
<maxinux> i use www.armhf.com/index.php/boards/beaglebone-black/ loaded on an SD card
<maxinux> though it can be loaded onto the mmc if you want
<brykt> ok, great. I will try that one...
<maxinux> note that it does not support fbdev out of th ebox
<maxinux> oh no screen
<maxinux> you dont care
<maxinux> that image will bring up eth0 automatically via dhcp on first boot  and has ssh going .. and supports all the wifi cards ive thrown at it... but i also reloaded a new kernel on it shortly thereafter... 3.8 > 3.2
<maxinux> though i suppose i could give you my  kernel and modules if you need it
<brykt> ah, ok. Will keep that in mind if I ever want to connect a screen.
<hrw> maxinux: iirc beaglebone black had 3.8 kernel out of the box
<maxinux> hrw:  angstrom comes with, but ubuntu does not
<hrw> maxinux: person which created image to blame then
<maxinux> im not complaining
<maxinux> i simply cross recompiled my kernel
<hrw> ;)
<maxinux> i jokingly recompiled on the bbb also
<maxinux> a few -6 hours later it was starting on modules
<brykt> You loaded Angstrom  3.2 from 3.8?
<maxinux> ? no
<maxinux> ubuntu arm image from armhf.com ships with kernel 3.2
<maxinux> i compiled 3.8.13 and loaded it on my bbb
<brykt> ah. ok... I'll get back to you if I cannot get the stuff I need the BBB for to work. Maybe 3.8.13 will solve it...
<T3CHKOMMIE> hello everyone.
<T3CHKOMMIE> I was wondering if I could get some pointers on imaging an SDcard with Ubuntu Server Arm...
<T3CHKOMMIE> I have a BeagleBone Black, and I have tried the documentation several times, but still cant get it to post.
<T3CHKOMMIE> does anyone know of a good method to getting the image on an SD card?
<mijk> hi
<maxinux> hi.
#ubuntu-arm 2013-06-01
<mijk> I'm debating building an arm "desktop"
<mijk> I've looked at a few options
<maxinux> im running ubuntu arm w/ xfce4 on bbb
<maxinux> sound is still a fail
<maxinux> and 720p max
<maxinux> raspi too slow still, but raspian is a reasonable distro
<mijk> i was looking at the via vab-800
<maxinux> looks nice
<maxinux> it can be a bit of an experience if you havent done it before
<mijk> i haven't
<mijk> i built a system that booted up the power supply, drives and usb devices, but i couldn't get the os to boot on the pandaboard
<mijk> i gave up because i had little time
<infinity> If you have a Panda, that's going to be a more fun experience than the VIA.
<infinity> The CPU on that VIA machine isn't what I'd call "fast".
<mijk> the problem was getting it to look like an atx system
<mijk> i had a make-shift io shield that was hell to make and far from practical
<mijk> he's not having any luck connecting
<lilstevie> <mijk> I'm debating building an arm "desktop" <-- This is something I'd love to do, but still waiting for an SoC with enough of a wow factor,
<lilstevie> fingers crossed on armv8
<iceroot> hi
<iceroot> is there a way to have flash?
#ubuntu-arm 2013-06-02
<bantone> I'm using the odroid x2 (armv7)
<bantone> is there a zfs package/module for linaro ?
<bantone> hm doesn't look like it from what I read.  not sure if someone made a patch for the latest kernel for it
<maxinux> recompile time
#ubuntu-arm 2014-05-27
<rooted-arm> does arm version of ubuntu supports java sdk ? java development and programming in general ?
<infinity> rooted-arm: Yep.
 * rooted-arm trying ubuntu-arm , brb
<rooted> hello :)
<rooted> ive tried to install gnome / ubuntu-desktop on my beaglebone, its says need more space 1004 into archieve memory , am using 64gm micro-sd
 * rooted l@@ks at the saver orga_ with an inisint* look.
<rooted> using raring ubuntu on beaglebone black. rev A6 , i guess.
<rooted> /boot/config-3.11.2-armv7-x14 no such file or directory ?
<MrBIOS_> hi folks, anybody alive?
#ubuntu-arm 2014-05-28
<vroomfondel|2> good morning
<vroomfondel|2> I am reading the ARMv7 architecture ref-man. It states that it covers also ARMv4 upwards. Is it that a binary executable for a v4 CPU would be executed identically on a v7?
<vroomfondel|2> i.e. binary compatibility since v4?
<MrBIOS> good morning
<brickedstuff> Anybody who can help me recover my Toshiba ac100 dynabook? : /
<MrBIOS> brickedstuff:  try http://forum.xda-developers.com/showthread.php?t=1055934 ?
<brickedstuff> hey thank you, but it seems like has some bigger issue : / i'm not even getting to the "toshiba" boot splash
<brickedstuff> i can get partitioninfo from nvflash, but that seems to be it... do you have some further hints for me? : \
#ubuntu-arm 2014-05-29
<ppisati> ogra_: i have a vintage question for you: do you recall, back then, when everything was nice and you made ubuntu arm images? well, you used to inject a script that resized the image to the full capacity of the sd card - i believe it was a script that you injected in the initrd or something - do you know where i can find it? i didn't find any sing of it in the old rootstock project FWIW
<ogra_> hmm
 * ogra_ goes to the basement of his mind to dig in some boxes
<ogra_> ppisati, jasper-initramfs ...
<ogra_> last upload was from infinity in precise ... i dont even know if it is still in the archive
<ppisati> https://launchpad.net/ubuntu/+source/jasper-initramfs
<ppisati> cool, i'll give it a try, thanks! :)
<ppisati> FYI: i tried to hack your rootstock-touch to create normal ubuntu images
<ppisati> but after jumping through some hoops i bailed
<ppisati> and now i'm tossing together a script that does it
<ppisati> much like the old rootstock
<ppisati> way simpler
<ppisati> hopefully
<ppisati> :)
<ogra_> hmm, it should be easy ... just changing the live-build call should be enough
<ogra_> in fact just changing the value of PROJECT (and dropping the click package hacks a bit lower down) should give you a proper build
<ppisati> ogra_: i kind of did that
<ppisati> ogra_: and i got to the point of getting a tarball
<ogra_> "kind of" :)
<ppisati> ogra_: but then you have the bootloader, the bootloader script and some other crap
<ppisati> ogra_: and that's when i encountered...
<ppisati> ogra_: cdimage or something
<ogra_> yeah, rootstock is only for rootfses indeed
<ogra_> right
<ppisati> and that's when i surrended
<rooted> its seems after expanding the size of the micro-SD rootfs , its take longer for booting up  , and its becoming slower , any hint ? beaglebone black
<ppisati> rooted: it takes more time to mount it (i guess)
<rooted> what is the solution ?
<ppisati> rooted: i guess none
<ppisati> rooted: what's the size of you sd/fs?
<ppisati> rooted: which fs are you using?
<rooted> so , i should use an external hd ?
<rooted> size of sd is 8gb
<rooted> ive expanded the fs to the whole sd
<ppisati> usb hdd are faster for sure
<rooted> well , it was fater for the default img .. ive just increased the size of the partition
<rooted> there is no unused partition on the sd , or should i make an empty space ?
<ppisati> rooted: no it's ok as it is
<ppisati> rooted: when a fs is mounted, some operations are done on it
<ppisati> rooted: so it's normal a delay with bigger fs
<ppisati> rooted: and the bbone doesn't have a super speedy cpu so, it all makes sense
<rooted> hmm
<rooted> i dont know alot about partitions , but i was comparing with the BBB sd, and the raspberry pi sd , its seems there is alot of partition on its sd.. and its runs fast.
<MrBIOS> http://www.wired.com/2014/05/ford-f150-aluminum-testing
<MrBIOS> sneaky sneakyâ¦I like it
<mistawright> hi guys i have my computer running ubuntu and the armv7 compiler installed so i can build software on it in the right arch. how can i specify that distcc use this compiler?
<mistawright> i have the gcc-arm-linux-gnueabi installed and have built the kernel etc using it. i need to have my beaglebone black running archlinux use distcc on this box but do not know how to specify the compiler used
#ubuntu-arm 2014-05-30
<MrBIOS> anybody alive?
<[[[asimov]]]> Does it work on samsung devices?
<[[[asimov]]]> Does it work on samsung devices?
#ubuntu-arm 2015-05-26
<cup`ocoffee> actually the current Pi2 is Armv7 â¦ idk maybe you will want to change the channel descriptionâ¦
<k1l_> pi =! pi2
<cup`ocoffee> well, ok :)
<k1l_> :)
#ubuntu-arm 2015-05-31
<jorrakay> Can anyone help me figure out why the main mirror has no binary-armhf folder?
<jorrakay> Or rather, how to get upgraded to 14.04.2 through dist-upgrade
<jorrakay> http://hastebin.com/qawetokina.rb
<infinity> jorrakay: That should be "deb http://ports.ubuntu.com/ubuntu-ports trusty main restricted universe multiverse"
<infinity> jorrakay: And then the same for trusty-updates and trusty-security.
<infinity> jorrakay: Your original installation would have used ports, not sure why you changed it and expected it to work.
<jorrakay> OK I changed them because i was following instructions for an EOL-upgrade
<jorrakay> I think it's gonna work. thanks infinity
#ubuntu-arm 2016-05-31
<jrayner> Hi, is this channel for aarch64 dicussion as well?
<k1l_> i guess: yes
#ubuntu-arm 2016-06-02
<IztokJeras> hi, I have an issue with the boot process (Systemd) on an Xilinx Zynq (ARM A9 CPU) board, what would be the most appropriate forum/mailing list/bug report for me to post to?
<IztokJeras> I ported Ubuntu base
<IztokJeras> hi, I have an issue with the boot process (Ubuntu base 2016.04) on an Xilinx Zynq (ARM A9 CPU) board, what would be the most appropriate forum/mailing list/bug report for me to post to?
#ubuntu-arm 2016-06-03
<KrisJace> Not only I cracked down the development but also solved few Libertine related problems, including an on screen keyboard. Libertine does not support phone's own OSK, so I developped my own to use inside applications running on xmir via libertine ;)
<KrisJace> More info in the vid description, documentation in the making.
<KrisJace> https://youtu.be/j__WaGH4aig
#ubuntu-arm 2017-05-29
<mercenaryship> is there a zip pack of arm tools?
#ubuntu-arm 2018-06-03
<ex-parrot> afternoon all. does anyone have Bionic running on the Pi 3 with functioning HDMI audio?
<ex-parrot> I'm tearing my hair out trying to make that go
<ex-parrot> I'm using the arm64 build
