[00:00] <Samae> Does it allow me to tweak the kernel conf ?
[00:01] <topfs2> you pick a kernel deb you want to base it on, so if you need to tweak the kernel you need to compile it and package it
[00:02] <Samae> ok
[00:03] <Samae> and then it outputs a rootfs
[00:03] <ka6sox-away> topfs2, because its a uimage you can't just use make-kpkg kernel_image
[00:03] <ka6sox-away> ?
[00:03] <Samae> Well, I don't use uimage for now, or I'm not aware i'm using it
[00:04] <Samae> I just discovered that my tablet boots always on a rootfs.img, so i substituted the armel image or ubuntu 10.10 and it ran ok (appart for usb and touchscreen support)
[00:04] <ka6sox-away> Samae, which tablet?
[00:05] <Samae> up there ^
[00:05] <Samae> Archos 101 it
[00:05] <ka6sox-away> ah, archos.
[00:05] <ka6sox-away> okahy
[00:05] <Samae> Ow, I meant I don't use uboot
[00:06] <Samae> but yeah it boots on zImage or uImage apparently
[00:06] <Samae> so next step, new rootfs and new kernel with proper modules
[00:06] <Samae> :)
[00:07] <Samae> I'll be back
[00:07] <Samae> gudnite
[02:52] <rsalveti> ogra: the binary is the same name, but different path
[02:52] <rsalveti> ogra: the new package for omap3 is x-loader-omap3-beagle
[02:52] <rsalveti> as we're generating images compatible with beagle by default
[02:53] <rsalveti> ogra: /usr/lib/x-loader/omap3530beagle/MLO
[03:50] <cooloney> rsalveti: still around. can you boot up latest 2.6.38-rc2 on panda?
[07:52] <lilstevie> ok got a different situation here, the board that i am building a rootfs image for only has 320mb for its rootfs, does ubuntu arm support me splitting in to /usr /home /var / et al
[09:03] <hrw> lilstevie: generate tarball with rootfs and then split it manually into parts
[09:04] <ka6sox> hrw, does the maverick image use a initramfs?
[09:08] <hrw> yes, it does
[09:09] <ka6sox-away> hmmm..okay. I might have to do some playing then to get it to work.
[09:09] <ka6sox-away> hopefully it uses udev
[09:31] <lilstevie> hrw: then just make sure the other parts are mounted in the initramfs right?
[09:33] <hrw> probably
[09:33] <hrw> I use only / /home + /tmp in tmpfs on most of my machines
[09:34] <lilstevie> heh problem i have is that i only have 320mb in the available space for /
[09:34] <lilstevie> and the rest is split on SD cards
[09:34] <lilstevie> internal 16gb of which i can only flash 1.5GB of ext
[09:42] <ogra> i doubt loading off /var will gain you enough, you should offload /usr instead
[09:43] <ogra> as long as you use an initrd adding a line to fstab should be enough, no extra fiddling needed
[09:48] <lilstevie> ogra: but will that still give me enough space to be able to install stuff
[09:58] <ogra> well, thats a trial and r thing i guess
[09:58] <ogra> *error
[09:59] <ogra> of my installed 4G big system /usr eats 1.9G while /var occupies 350M
[09:59] <ogra> so sharing out /usr will definitely gain you more
[10:00] <hrw> 6.3GB /usr 8/2GB /var on my desktop
[10:00] <hrw> 6.3GB /usr 8.2GB /var on my desktop
[10:01] <ogra> hrw, apt-get clean ;)
[10:01] <hrw> ogra: 4GB is pbuilder
[10:01] <ogra> loading off /var surely gains you a lot too in the running system later
[10:02] <ogra> (logs, caches etc)
[10:02] <hrw> but yes, 800MB was apt cache
[10:02] <ogra> but for initial install if you are short on space /usr should be the first
[10:03] <ogra> and /tmp in tmpfs is something you should only do with a decent amount of ram
[10:03] <ogra> at least if you want to run apps like firefox
[10:03] <ogra> i wouldnt do that on 128M if you want to run any desktop bits
[10:03] <ogra> (for example)
[10:07] <lilstevie> I have 512mb ram usable
[10:08] <lilstevie> the SoIC has more ram but i dont know how to access it
[10:09] <lilstevie> and this is for arm :p does firefox have an arm port :p
[10:12] <hrw> port?
[10:12] <hrw> firefox nowadays just need to be compiled
[10:12] <lilstevie> heh fair enough
[10:13] <hrw> I remember days when anything mozilla based required strange patches to get it running
[10:13] <lilstevie> still trying to grasp how much will run on arm
[10:13] <hrw> lilstevie: 512MB ram? most will run
[10:13] <lilstevie> generally what is the best x manager to run in a touch environment
[10:13] <LetoThe2nd> running firefox on arm is absolutely no problem. compiling locally still is a bit of a strain, though.
[10:14] <hrw> lilstevie: which arm cpu you have?
[10:14] <ogra> LetoThe2nd, depends on your hardware ;)
[10:14] <lilstevie> hrw: yeah it has 512mb ram, and some other ram that is really not known if it is usable
[10:14] <lilstevie> hrw: hummingbird
[10:14] <hrw> nice cpu
[10:14] <lilstevie> yeah :)
[10:14] <ogra> lilstevie, i use an ac100 here atm, should all work fine
[10:15] <lilstevie> just hoping to free it from android hell :p
[10:15] <LetoThe2nd> ogra: adequte relation to HW given, of course. running ff on a pentium133 is also rather pointless.
[10:15] <hrw> lilstevie: so galaxy s/tab/nexuss?
[10:15] <lilstevie> for a tablet like device is not nice
[10:15] <lilstevie> tab
[10:16] <lilstevie> and i wasnt dumb enough to upgrade to one of the dev releases that has locked bootloaders so it just happily runs unsigned kernel/initramfs combos
[10:16] <lilstevie> has to be the most open device i have ever had lol
[10:16] <LetoThe2nd> ogra: on an openrd here ff worked quite good. :-)
[10:16] <hrw> bb in ~15minutes
[10:21] <hrw> heh.. someone remind about someone before leaving...
[10:22]  * hrw uses hummingbird to play youtube videos now.
[10:22] <lilstevie> lol
[10:22] <hrw> but on nexus s/android
[10:22] <lilstevie> the tab is nice hardware
[10:22] <hrw> lilstevie: tab has 1024x600?
[10:22] <lilstevie> yep
[10:23] <hrw> 16GB storage, 512MB ram, netboot resolution... looks like good target for ubuntu
[10:23] <lilstevie> yeah thats what i though
[10:23] <hrw> but I do not know would I switch
[10:24] <lilstevie> only thing I am going to struggle with is the initramfs
[10:25] <ogra> make sure you have your kernel and modules properly installed in the rootfs
[10:25] <ogra> then just run update-initramfs -c -v<version of your kernel>
[10:25] <hrw> lilstevie: on arm devices I just avoid initramfs and boot directly into rootfs
[10:26] <lilstevie> hrw: that is a tad difficult on the tab
[10:26] <lilstevie> as the kernel gets the initramfs compiled in
[10:26] <hrw> as hw is always same, rootfs is same device etc
[10:26] <ogra> you lose some functionality without initrd
[10:27] <ogra> (filesystem check, encrypted filesystems etc)
[10:29] <lilstevie> ogra: update-initramfs from inside qemu or just in the rootfs
[10:30] <ogra> either will work, it creates a /boot/initrd.img-<version>
[10:34] <sebjan> ll /mnt/`
[10:34] <sebjan> oups :)
[10:35] <lilstevie> SGX535 has full accel on ubuntu yes?
[10:39] <hrw> ogra: since when fsck needs initramfs?
[10:39] <hrw> ogra: fsck needs rootfs/ro
[10:39] <ogra> it happens before / is mounted rw
[10:39] <hrw> ogra: and for this initramfs is not required
[10:39] <ogra> well, i dont have fsck on systems where i dont use initrd
[10:40] <hrw> ogra: maybe thats because ubuntu forces initramfs to be used to fsck
[10:40] <ogra> might be, i never checked ... since we use initrd by default on all official images anyway
[10:50] <sveinse> ogra: How can I submit patches to rootstock?
[10:51] <ogra> sveinse, create your own branch on LP and file merge requests
[10:59] <hrw> speaking of merging....
[10:59] <lilstevie> ogra: does the kernel need to be in the rootfs
[10:59] <hrw> flash-kernel?
[10:59] <ogra> lilstevie, the modules do
[10:59] <ogra> i'm not sure update-initramfs checks for a vmlinuz file
[10:59] <ogra> worst case you can just touch it though
[11:00] <lilstevie> ok good cause my kernel isnt compiled until after i have the initramfs :p
[11:00] <ogra> hrw, yeah yeah ... did drop off my TODO, there are just other more pressing things atm
[11:00] <ogra> *didnt (indeed)
[11:04] <sveinse> I saw some comments above regarding initrd: What specifically is done in initrd? Because my (rootfs based) system does not use initrd at all, but it seems to work as intended
[11:04] <sveinse> ...I meant roostock based system
[11:07] <ogra> sveinse, make sure your users never ever install any filesystem encryption bits, raid or device manager ... all these need initrd
[11:08] <ogra> beyond that initrd indeed draws the splash and runs plymouth (whithout which fsck will not work since mountall uses libplymouth for communication)
[11:11] <lilstevie> so ogra let me get this right, best way to do it will be set up fstab, move modules in to place chroot to the rootfs then run update-initramfs
[11:11] <sveinse> ogra, ok thanks. Quite frankly it good to be without (except for fsck). I have a strict customer requirement of short bootup time.
[11:12] <sveinse> I see the PID counter is what around 3000, so it does alot at boot even without initrd
[11:54] <dmart> hi all ... does anyone know how to get verbose log output during bootup, preferably over serial?  I don't really know to to achieve this with upstart+plymouth
[11:55] <lool> dmart: remove quiet from cmdline and add nosplash?
[11:55] <lool> might not be enough though
[11:55] <ogra> no need for nosplash on serial though
[11:55] <ogra> dropping quiet should be enough (and indeed the right console= args)
[11:55] <lool> dmart: For serial, it's a matter of listing your serial console last if you want it to be the system console IIRC
[11:56] <lool> That is, console=ttyS2, console=tty0 will output some kernel messages on both, but /dev/console will only go to last arg, or something like that
[11:56] <ogra> just make it the only console
[11:56] <ogra> no need for tty0 if you want serial boot output
[11:57] <lilstevie> egh is there anthing that stops 32bit linux binaries executing on 10.10 64bit?
[11:58] <lilstevie> for some reason it keeps telling me file not found for the executable when it is clearly there
[12:04] <lool> lilstevie: What's the exact message?
[12:05] <lilstevie> No Such File or Directory
[12:05] <lilstevie> it clearly exists
[12:05] <lool> lilstevie: The full message
[12:05] <lool> lilstevie: Usually, it's missing ld-linux for 32-bits; it's in a separate package
[12:06] <lool> lilstevie: You want to install libc6-i386
[12:06] <lool> lilstevie: You can strace your binary to see which actual file is missing
[12:06] <lilstevie> /opt/toolchains/arm-2009q3/bin/arm-none-linux-gnueabi-gcc: no such file or directoy
[12:07] <lilstevie> directory*
[12:07] <lool> lilstevie: Ok; that sounds like missing 32-bits ld-linux; run strace -etrace=file /opt/toolchains/arm-2009q3/bin/arm-none-linux-gnueabi-gcc
[12:09] <lilstevie> http://pastie.org/1492398
[12:10] <dmart> lool: I don't think we're using quiet or splash... this is just a BSP bringup problem.
[12:11] <lilstevie> lool: installing libc6-i386 fixed :)
[12:43] <lilstevie> hm, ogra i get an error off that initramfs telling me it is the wrong datatype
[12:44] <lilstevie> cause it is aparently not cpio
[12:55] <ogra> its gzipped cpio
[12:57] <sveinse> Hmm. It seems getting rootstock to use more than "maverick" (e.g. maverick-updates and maverick-security) isn't as trivial as I hoped it would be. It seems debootstrap doesn't do a full "apt-get" resolution of the latest package. It seems to be locked against maverick/main. Objections?
[12:58] <lilstevie> yeah i figured it out
[12:58] <lilstevie> i ended up checking it with file
[12:58] <lilstevie> discovered that it was gzip
[12:58] <lilstevie> was a bit of a facepalm moment :/
[12:59] <sveinse> So perhaps it's better to rootstock/debootstrap and then do a apt-get upgrade after installation to get the maverick-security and/or maverick-updates
[13:03] <ogra> or properly patch rootstock to generate a proper sources.list
[13:04] <ogra> i.e. by installing and using python-apt
[13:08] <sveinse> ogra, I've added a --sources option to rootstock where you can provide your own sources.list
[13:08] <sveinse> However, debootstrap internals doesn't consider anything else than maverick/main
[13:13] <ogra> sveinse, you could prot rootstock to multistrap ;)
[13:28] <dcordes> hi
[13:30] <dcordes> In http://cdimage.ubuntu.com/ubuntu-netbook/daily-preinstalled/20110123/natty-preinstalled-netbook-armel+omap4.img.gz I get 'No valid session found' after gdm startup. Is it a known problem ?
[13:30] <dcordes> /etc/gdm/custom.conf has une-efl
[13:44] <rsalveti> dcordes: yup,algo got this with today's image
[13:44] <rsalveti> seems that I'm unable to log-in in any session
[13:45] <ogra> thats weird
[13:45] <ogra> but i think the whole session handling in gnome changed
[13:45] <ogra> once unity-2d is the default it should work again
[13:48] <rsalveti> yup, probably because of the gnome update
[13:52] <dcordes> rsalveti: any workaround ?
[13:53] <ogra> well, teeh gnome desktop session should work
[13:53] <ogra> *the
[13:53] <ogra> rsalveti, so about that xloader prob on omap3
[13:54] <ogra> the current build script looks for a package named x-loader-omap
[13:54] <rsalveti> I'm now trying to at least log-in at the gnome classic
[13:54] <ogra> and doesnt find it
[13:54] <ogra> so i assumed the binary package name changed
[13:54] <dcordes> rsalveti: ok hope it works
[13:55] <rsalveti> ogra: the package name changed and the mlo path
[13:55] <rsalveti> but if you didn't change, it should still work
[13:55] <ogra> right
[13:55] <rsalveti> as we didn't remove the old package yet
[13:55] <ogra> hmm
[13:55] <ogra> weird
[13:55] <ogra> it doesnt find it
[13:55] <rsalveti> hm, ok, we should remove just the omap 4 one
[13:55] <rsalveti> the version changed, but it kind of replaced the old x-loader package
[13:55] <rsalveti> used by omap 3
[13:56] <rsalveti> that could be the reason
[13:56] <rsalveti> dcordes: gnome classic seems to work
[13:56] <ogra> http://paste.ubuntu.com/557665/
[13:56] <dcordes> rsalveti: nice. is it 'gnome-desktop' in custom.conf ?
[13:56] <ogra> thats what i get in the buildlogs
[13:57] <rsalveti> ogra: yup, saw that when you pointed me the logs yesterday
[13:57] <rsalveti> dcordes: just select ubuntu classic desktop while log-in
[13:58] <rsalveti> ogra: you should now get x-loader-omap3-beagle
[13:58] <dcordes> rsalveti: ok. gdm doesn't use custom.conf any longer ?
[13:58] <sveinse> ogra, I have to admit I know nothing of multistrapping... :(
[13:59] <ogra> rsalveti, is there a transitional package ?
[13:59] <rsalveti> ogra: nops, as this package wasn't installed at any image
[13:59] <ogra> (though i'm not sure NCommander's way of extracting it would manage this, iirc he extracts the package directly)
[14:00] <rsalveti> and x-loader-omap doesn't make much sense now, as we also have overo
[14:00] <dcordes> can somebody recommend a known working qemu kernel for the current (above) natty builds ? I tried some yetserday and ran into illegal instruction problems which I think were NEON related
[14:00] <rsalveti> and soon have igepv2
[14:00] <rsalveti> that are all omap
[14:00] <ogra> indeed
[14:05] <sveinse> in regards of the igepv2: Are there any efforts on using the DSP from linux?
[14:06] <sveinse> or more specifically: ubuntu
[14:13] <rcn-ee> sveinse, it's possible with natty's 2.6.37 kernel, (dspbridge), just need to package 2 git project (dsp-gst, dsp-tools) then package the ti codec's..
[14:36] <ogra> rsalveti, http://ports.ubuntu.com/ubuntu-ports/pool/main/x/x-loader/ has not a single natty build, did anyone care for getting the newly natty binaries to main yet ?
[14:36] <rsalveti> ogra: hm, lp says it's published
[14:37] <rsalveti> or this is something that lp is not yet tracking?
[14:37] <ogra> published != main promoted
[14:37] <rsalveti> publish in main
[14:37] <ogra> that only means it went into the archive
[14:37] <rsalveti> *published
[14:37] <ogra> and the source is in main
[14:37] <ogra> but the binaries werent transitioned
[14:37] <ogra> http://ports.ubuntu.com/ubuntu-ports/pool/universe/x/x-loader/
[14:37] <ogra> all of them sit in universe
[14:38] <rsalveti> hm, ok, sources at main but debs still in universe
[14:38] <ogra> right
[14:38] <ogra> an archive admin needs to promote the beagle and panda binaries to main
[14:39] <rsalveti> do we need to find a bug? or just ask someone?
[14:39] <rsalveti> yup, at least beagle and panda
[14:40] <rsalveti> don't know if it's ok for linaro to have overo at universe
[14:40] <rsalveti> but then they can just ask it if it's a problem
[14:40] <ogra> pitti promotes for us
[14:41] <rsalveti> ogra: a lot easier when you ask for it :-)
[14:41] <ogra> heh
[14:41] <rsalveti> ogra: thanks anyway, and sorry for the confusion
[14:41] <ogra> well, all fine now
[14:42] <ogra> next publisher run we should be fine, i'll adjust the build scripts for the new names and file locations then
[14:43] <rsalveti> cool
[14:46] <ogra> ok, scripts adjusted
[14:47] <rsalveti> ogra: nice, are you firing up another image for it? or just wait until tomorrow?
[14:49] <ogra> we will have to wait until the promotion is done, i'll trigger an imagebuild later
[14:49] <rsalveti> ok
[15:01] <davidm> ogra, you about?
[15:01] <ogra> davidm, indeed i am
[15:02] <ogra> sorry, the canonical server kicked me outr
[15:02] <davidm> Ah was wondering what happened
[15:02] <davidm> cool
[16:16] <jcrigby> ogra, can bug #683683 be closed out?
[16:16] <ubot2> Launchpad bug 683683 in busybox "run-init on omap3, omap4 in natty dies if busybox is built with -marm" [High,Fix released] https://launchpad.net/bugs/683683
[16:16] <ogra> jcrigby, no idea, ask the toolchain guys
[16:16] <jcrigby> or is it still a bug but there is a workaround
[16:16] <ogra> its a toolchain issue
[16:16] <jcrigby> ogra, ok
[16:16] <ogra> the other tasks are fix released iirc
[16:20] <ogra> jcrigby, iirc davidgiluk assigned it to gcc (and doko moved it to gcc4.5 or so)
[16:20] <jcrigby> ogra, yes I see that.
[16:21] <ogra> the prob is that compiling with -marm breaks under 4.5 apparently
[16:21] <ogra> at least for busybox
[16:21] <jcrigby> ogra, right
[16:50] <sveinse> does anyone have a 101 for lp/bzr?  i *think* I have created a branch within rootstock, but I'm uncertain how to branch from the main branch...
[17:41]  * sveinse finally managed to make his own rootstock branch and commit his patch. First time of lp+bzr has quite a learning curve
[17:42]  * rsalveti brb, late lunch
[17:52] <rcn-ee_at_work> sveinse, thanks, i like that change, i'll be able to cleanup some of my roostock for debian tweaks.. ;)
[17:53] <sveinse> yeah, I'm working on a custom HW board, and we use rootstock all the time to generate the rootfs images
[17:53] <sveinse> so I can't use the official released images
[17:57] <rcn-ee_at_work> same here. ;)
[18:00] <sveinse> rcn-ee_at_work: running ubuntu or debian on target?
[18:00] <sveinse> ..presume ubuntu since you're here ;)
[18:01] <rcn-ee_at_work> all the above.. ;)  i'm really itching for debian wheezy with armhf.. ;)
[18:01] <sveinse> oh? how come?
[18:01] <sveinse> We've selected ubuntu as target OS since this had the best armv7 support when we had to choose
[18:03] <rcn-ee_at_work> yeah and it's pretty quick.. (lucid->natty)... but it's still using soft floating point...  so it'll be interesting if ubuntu enables hardfp for natty++ (i'm hoping)
[18:03] <sveinse> *that* I can put my vote to!
[18:05] <sveinse> is natty particularly faster then maverick? BTW I'm running on omap3 (3530)
[18:06] <rcn-ee_at_work> i wouldn't run it yet, as it's not even alpha-2, but it's a more patched gcc with the same compiler settings..
[18:07] <sveinse> wheezy will be targeted for armv7?
[18:08] <sveinse> I seem to be asking google the wrong questions...
[18:09] <rcn-ee_at_work> sveinse, it looks like wheezy will have the older "armel" and a new "armhf" for armv7 stuff .. http://wiki.debian.org/ArmHardFloatPort
[18:09] <sveinse> ah hf=hard float... thanks
[18:13] <Martyn> natty boots on the pandaboard nicely
[18:13] <Martyn> not so much on the Versatile Express .. yet
[18:19] <Martyn> Are there any known issues getting a graphic boot on the pandaboard at the moment?
[19:02] <ogra> rcn-ee_at_work, sveinse, ubuntu will have hf in about two releases
[19:04] <rcn-ee_at_work> thanks, ogra cool..
[19:04] <ogra> probably before wheezy :)
[19:05] <rcn-ee_at_work> ;) for those that wait for the 'release'.. ;)
[19:05] <ogra> indeed
[19:05] <rcn-ee_at_work> probally about 2 years just like squeeze...
[19:05] <ogra> the current debian hf port uses the ubuntu toolchain i think
[19:06] <rcn-ee_at_work> yeah it's that linaro/ubuntu gcc-4.5.
[19:06] <ogra> right
[19:37] <dcordes> rsalveti: tried out the gnome desktop session and it works
[19:37] <dcordes> rsalveti: somehow metacity didn't show up once
[19:38] <rsalveti> dcordes: check bug 707014
[19:38] <ubot2> Launchpad bug 707014 in netbook-launcher-efl "Ubuntu Netbook Edition 2D fails to launch from gdm by giving "No valid session found"." [Undecided,New] https://launchpad.net/bugs/707014
[19:38] <GrueMaster> Is this possibly due to a change in jasper-initramfs?
[19:38] <rsalveti> nops
[19:38] <rsalveti> gnome-session
[19:38] <GrueMaster> (I'm just now booting today's image).
[19:39] <GrueMaster> Hmmm
[19:41] <dcordes> rsalveti: cool thanks
[19:43] <dcordes> -Exec=gnome-session
[19:43] <dcordes> +Exec=gnome-session --session=une-efl
[19:44] <rsalveti> and a new file
[19:44] <dcordes> ok
[19:44] <rsalveti> une-efl.session at /usr/share/gnome-session/sessions
[19:45] <dcordes> it would be nice to be able to change the gnome-panel in nbl efl
[20:06] <dcordes> rsalveti: is there a way to do this except for using a converted gnome session? I had bad experience with that with nbl not coming up
[20:07] <rsalveti> dcordes: why you don't want to use a gnome-session for that?
[20:08] <dcordes> I'm not sure about how to start netbook-launcher-efl correctly when doing it manually
[20:08] <dcordes> just putt it in the session startup  before but it didn't come up sometimes
[20:08] <dcordes> even with large delay
[20:10] <dcordes> that was in maverick release images
[20:30] <LetoThe2nd> just giving rootstock a little try. when i follow the guide in the wiki and fire up the image in qemu, it fails with segmentation fault.
[20:30] <rsalveti> LetoThe2nd: https://wiki.ubuntu.com/ARM/RootStock/KnownIssues
[20:31] <rsalveti> I think we have the fix for at least 2 bugs, but not yet packaged
[20:31] <LetoThe2nd> rsalveti: so what to do? checkout trunk and use that?
[20:32] <rsalveti> bug is not related with rootstock, it's probably qemu
[20:33] <LetoThe2nd> rsalveti: just built it from scratch... might it be fixed in the ubuntu repos? probably not, i'd guess...
[20:33] <ogra> rsalveti, before you add that file to /usr/share/gnome-session/sessions talk to didrocks, there is a certain naming scheme that has to be used i was told
[20:34] <ogra> (great that there is a fix !)
[20:37] <rsalveti> ogra: oh, ok
[20:37] <ogra> i think the distro name needs to be in the filename
[20:37] <ogra> i had to make unity-2d 2d-ubuntu
[20:38] <rsalveti> could be, let me check with him
[20:39] <GrueMaster> That will suck.  Not good if people want to try different launchers.
[20:39] <ogra> ??
[20:40] <ogra> people will never see that file
[20:40] <ogra> its just a naming convention for the .session files that gnome put in place
[20:41] <ogra> wont matter if you call it efl-ubuntu or foo-ubuntu or whatever, you can still select the efl launcher in gdm
[20:42] <rsalveti> well, just got applied by janimo, but will talk to didrocks once he's on-line
[20:42] <ogra> thanks
[20:42] <ogra> with luck i'll kick out efl on wed. :)
[20:42] <rsalveti> :-)
[20:43] <ogra> though there might be a MIR blocker ...
[20:43] <ogra> -2d is currently untranslatable
[20:43] <ogra> (there is no gettext support yet)
[20:46] <rsalveti> hm
[20:48] <ogra> not sure i can get it past the MIR team that way, there are plans for gettext support, but no code or anything
[20:48] <LetoThe2nd> bottom line - is qemu always segfaults with "qemu: fatal: VS[LR]I.64 not implemented", is there any way to get started with rootstock, or is this just a showstopper for now?
[20:48] <rsalveti> LetoThe2nd: what qemu version are you using?
[20:48] <rsalveti> and what ubuntu version
[20:48] <LetoThe2nd> jd@tabr:~/rootstock$ qemu-system-arm --version
[20:48] <LetoThe2nd> QEMU PC emulator version 0.12.5 (qemu-kvm-0.12.5), Copyright (c) 2003-2008 Fabrice Bellard
[20:49] <LetoThe2nd> ubuntu 10.10, amd64.
[20:49] <rcn-ee_at_work> LetoThe2nd, are you trying to build a 'natty' arm rootfs?
[20:49] <LetoThe2nd> rcn-ee_at_work: just trying to get started with https://wiki.ubuntu.com/ARM/RootfsFromScratch
[20:50] <rcn-ee_at_work> LetoThe2nd, just for reference, can you pastebin your full 'rootstock' command..
[20:51] <LetoThe2nd> rcn-ee_at_work: of course. http://paste.pocoo.org/show/326221/
[20:53] <rcn-ee_at_work> yeah, your aren't giving qemu any chance with that...  unless you run it on an armel machine, xubuntu-desktop is going to kill qemu...
[20:56] <LetoThe2nd> rcn-ee_at_work: ok, trying it without seed now.
[20:56] <LetoThe2nd> rcn-ee_at_work: is there any particular reason why xubuntu kills qemu? or what other packages will have the same effect?
[20:56] <rcn-ee_at_work> LetoThe2nd, well just something less entensive for the inital install..
[20:58] <rcn-ee_at_work> LetoThe2nd, it varies on release, some *.deb packages cause issues when installed thru qemu...  Ever since lucid it's been a pain in the rear to track down..
[21:00] <LetoThe2nd> rcn-ee_at_work: i see.... strange. the message would indicate something missing in qemu's instruction set, so i'd guess it could happen with any package if the compiler only decided to put in that one instruction.
[21:04] <LetoThe2nd> rcn-ee_at_work: taking away the seed, the emulated system does not segfault, but just stop with a blinking cursor after leaving the kernels boot. :-/
[21:10] <rcn-ee_at_work> are you dumping any info to the serial console?
[21:10] <LetoThe2nd> rcn-ee_at_work: no, just stating with the exact example command given on the wiki page.
[21:12] <rcn-ee_at_work> LetoThe2nd, in your previous message "the emulated system does not segfault, but just stop with a blinking cursor" do you have a serial console for debugging
[21:14] <LetoThe2nd> rcn-ee_at_work: ok, probably stupid question - where?
[21:14] <LetoThe2nd> qemu-system-arm -M versatilepb -cpu cortex-a8 -kernel ./vmlinuz -hda qemu-armel-201101242154.img -m 256 -append "root=/dev/sda mem=256M devtmpfs.mount=0 rw"
[21:14] <LetoThe2nd> qemu-system-arm -M versatilepb -cpu cortex-a8 -kernel ./vmlinuz -hda qemu-armel-201101242154.img -m 256 -append "root=/dev/sda mem=256M devtmpfs.mount=0 rw"
[21:14] <LetoThe2nd> ohsry for doubleposting.
[21:16] <rcn-ee_at_work> ah, booting the image with qemu... sorry haven't done that for atleast a year...
[21:17] <LetoThe2nd> rcn-ee_at_work: for the protocol, i try to start following this: https://wiki.ubuntu.com/ARM/RootfsFromScratch ... hoping that the "demo" commands provide a working starting point.
[21:22] <rcn-ee_at_work> LetoThe2nd, based on the age of that wiki document, i bet it was with karmic's default, so you need to add "--dist karmic" but that's pretty old..
[21:37] <TheUni> rsalveti: around?
[21:37] <rsalveti> TheUni: yup
[21:38] <TheUni> rsalveti: i've just merged our massive code refactor, i'd like to begin working with you on an evaluation when you get a chance
[21:38] <TheUni> (xbmc)
[21:39] <rsalveti> TheUni: awesome, I can try to check this out this week and focus more on next week
[21:39] <rsalveti> as we moved it to alpha 3
[21:39] <TheUni> yep, i saw
[21:40] <rsalveti> TheUni: did you create any release for it? or basically current trunk?
[21:40] <TheUni> rsalveti: current master. release is still a ways out
[21:42] <rsalveti> np, will try to check that out
[21:42] <TheUni> rsalveti: as i've mentioned, you might not target for natty, but we would greatly appreciate some ideas when it comes to packaging. what we've got currently is a monstrosity :)
[21:42] <rsalveti> haha, np
[21:42] <rsalveti> let's see what we can at least get for natty
[21:56] <LetoThe2nd> rcn-ee_at_work: for the protocol: it works with dist karmic.
[21:57] <rcn-ee_at_work> yeah, karmic's easier for qemu... compile for armv6 vs armv7 + thumb for lucid/maverick/natty...
[21:58] <LetoThe2nd> rcn-ee_at_work: gotta read up a bit on qemus changes, maybe a more recent trunk might do :-)