[00:00] <asac_the_2nd> james_l: the man page ts.conf(5) says its the configuration for tslib ;)
[00:00] <asac_the_2nd> ts.conf - Configuration file for tslib, controlling touch screens for embedded devices.
[00:01] <james_l> Well, it doesn't seem to be, from pre-configuration (mirred axis) and post-configuration (working). /etc/ts.conf is the exact same.
[00:03] <asac_the_2nd> is "confiugration" a command? maybe run in strace to see what it writes
[00:08] <james_l> Ah, found what I was looking for /etc/pointercal
[00:08]  * asac_the_2nd nods
[00:19] <porter1> Does anyone know if rootstock works with lucid or whether I should stick with karmic?
[00:40] <persia> porter1: lucid as a host or a target?
[00:40] <porter1> persia, both
[00:40] <persia> rootstock has significant improvements in lucid as a host, but lucid itself is not yet at beta, so there are still rough edges.
[00:41] <porter1> It appears as though rootstock gets stuck after extracting in debootstrap, so I might try just executing by hand for now
[00:41] <persia> rootstock should support arbitrary guest (you may need a backported debootstrap).  lucid as a guess is not yet at best, so there are still rough edges.
[00:42] <porter1> Yeah, I shouldn't have switched until the first beta, but it isn't too painful :)
[00:43] <persia> I usually switch much earlier: I just like to warn folks :)
[00:44] <porter1> So 2.6.32-13 in ogra's archive is not supposed to run right in qemu I guess?
[00:45] <persia> I don't know offhand.
[00:45] <persia> I think lool was advocating extracting the kernel from the linux-versatile build in lucid.
[00:46] <porter1> oh
[00:47] <porter1> I might just stick with the 2.6.31 for a while then. THanks for the help.
[01:03] <asac> bug 532342
[01:03] <ubot4> Launchpad bug 532342 in rootstock (Ubuntu) "rootstock-gtk does not allow to specify the target rootfs tarball file path (affects: 1)" [Undecided,New] https://launchpad.net/bugs/532342
[01:03] <asac> bug 532343
[01:03] <ubot4> Launchpad bug 532343 in rootstock (Ubuntu) "think about rootstock .desktop file Categories (affects: 1)" [Undecided,New] https://launchpad.net/bugs/532343
[01:07] <persia> asac?
[01:09] <asac> just bugs i filed ;)
[01:09] <asac> feel free to comment or ignore :-P
[01:13] <asac> hmm. rootstock-gtk is looping on CPU while nothing happens in UI ... just in the VM
[01:26] <asac> filed
[01:27] <asac> bug 532358 ;)
[01:27] <ubot4> Launchpad bug 532358 in rootstock (Ubuntu) "rootstock-gtk is consuming a full core (CPU) while nothing happens in UI (affects: 1)" [Undecided,New] https://launchpad.net/bugs/532358
[01:33] <persia> asac: But the VM is slammed, right?
[01:33] <persia> Or is the VM using one core and the GUI another for useless polling?
[01:41] <asac> not yet
[01:41] <asac> its currently doing
[01:41] <asac> Selecting previously deselected package iputils-arping.
[01:41] <asac> Unpacking iputils-arping (from .../iputils-arping_3%3a20071127-2_armel.deb) ...
[01:41] <asac> Selecting previously deselected package iputils-tracepath.
[01:41] <asac> Unpacking iputils-tracepath (from .../iputils-tracepath_3%3a20071127-2_armel.deb) ...
[01:42] <asac> hmm. doesnt move though ;)
[01:42] <asac> just spins and consumes cycles
[01:43] <asac> did ogra say it did that or was idling?
[01:55] <persia> He said he had some issues with installing some stuff, and was trying to get lool to look into it.
[03:23] <tuxdavis> question about compiler optimizing an inline function that access private member data, could be possible reason for crash in kdebindings
[03:24] <persia> Go ahead :)
[03:24] <tuxdavis> If the compiler were to in fact perform the recommended optimization, would the calling function then be performing an illegal operation, since it would be accessing private data
[03:28] <persia> I wouldn't think that an inline function would have namespace to hold private data (although I'll admit to not having a deep understanding at that level)
[03:30] <tuxdavis> yeah in the "generators/parser/lexar.h" file in the kdebindings package, there is an inline function "inline int kind(std::size_t i) {return tokens[i].kind;}"
[03:30] <tuxdavis> The problem is that the "tokens" variable is private data
[03:30] <NCommander> tuxdavis: interesting, how'd you find this?
[03:31] <tuxdavis> compiling the kdebindings in debug mode, then ran the smokegen through gdb, since that's what was segfaulting
[03:34] <NCommander> tuxdavis: interesting. sounds like a GCC bug
[03:34] <tuxdavis> not necessarily
[03:35] <tuxdavis> it could be that the inline keyword should not be used inside a class if the function is going to be accessing private data
[03:35] <tuxdavis> but I'm testing this right now, by removing the inline then seeing what happens
[03:35] <NCommander> tuxdavis: wonder why that works w.r.t. to !ARM
[03:36] <tuxdavis> the inline command is a "recomendation" to the compiler not a requirement
[03:36] <tuxdavis> so it's possible that it's making the optimization on ARM, but not on others
[03:36] <persia> So we'd actually have to compare the output of the preprocessor cross-platform to understand hwo the choice is made :(
[03:37] <tuxdavis> most likely
[03:38] <tuxdavis> I'm trying a very simple test, by commenting out the inline keywords then recompile and see what happens
[03:42] <tuxdavis> it's recompiling smokegen with the updated header file right now
[04:13] <tuxdavis> it seems this is very likely a compiler test, because if you compile everything in debug mode, then run smokegen through gdb with the same args that the Makefile is giving it (on the "smoke/akonadi/akonadi_includes.h" file, then when it crashes, telling gdb to print m_session->token_stream->tokens[0].kind prints ok, whereas m_session->token_stream->kind(0) crashes, even though kind is defined as "inline int kind(std:size_t i) {return tokens[i]
[04:14] <tuxdavis> so the two prints are accessing the same data just one is passed through an inline function call, and the other is accessed directly
[04:15] <persia> Could you pastebin the backtrace?
[04:16] <tuxdavis> yes, though it would take a bit because it's currently recompiling with the updated header
[04:16] <persia> No rush.
[04:16] <persia> I just like to read backtraces.  Often I can understand something from them.
[04:16] <persia> I have a feeling that you're right, and that it's a scoping problem.
[04:17] <persia> Have you also tried dfferent -O levels to see if the behaviour changes?
[04:18] <tuxdavis> Unfortunately I don't know yet exactly how to tell cmake to compile with different optimization levels
[04:19] <tuxdavis> And to do it manually would require finding out exactly what commands are being passed on ALL the source files going into the smokegen executable
[04:19] <tuxdavis> then recompiling ALL the source files with the different optimization flags
[04:20] <persia> Manually isn't right.
[04:20] <persia> The folk in #kubuntu-devel may be able to suggest how to wrangle cmake.
[04:20] <tuxdavis> let me check the cmake documentation and see if there's something in there
[04:20] <persia> That works too :)
[04:33] <NCommander> persia: tuxdavis: edit the C and CXX options lines in  CMakeCache.txt in the build directory for Release builds (I think),
[04:33] <NCommander> then run make
[04:33] <NCommander> alternately, install ccmake, and edit it that way
[04:33] <DanaG> oooh, 2.6.33 kernel on rcn-ee.net
[04:33] <tuxdavis> ah
[04:33] <DanaG> Bummer: it still doesn't suspend.
[04:33] <DanaG> "class suspend failed for cpu 0"
[04:35] <DanaG> hmm, is command-not-found supposed to not-work on ARM?
[04:39] <persia> DanaG: Did you install it?
[04:40] <DanaG> yeah.
[04:40] <persia> Then it ought just work.
[04:40] <DanaG> Doesn't seem very different from 2.6.32.
[04:40]  * persia checks quick-like
[04:42] <persia> DanaG: Indeed.  Doesn't work for armel, ia64, powerpc, or sparc.  Please file a bug and subscribe me.
[04:42] <DanaG> file it on "Linux" package?
[04:43] <persia> On command-not-found
[04:43] <DanaG> ah.
[04:43] <persia> If you've a bug in your kernel, talk to rcn-ee for now.
[04:43] <DanaG> ah.
[04:43] <persia> Need to get the kernel into the distro before it's worth filing bugs on LP about it.
[04:43] <DanaG> Are there plans to have an official Ubuntu-repo beagleboard kernel?
[04:43] <persia> `ubuntu-bug command-not-found` ought do the right thing.
[04:44] <persia> I have plans to support every single device capable of running Ubuntu ever manufactured.
[04:44] <persia> I have doubts my plans will come to fruition
[04:44] <persia> From what I was told asking about NetWalker kernels, it basically requires the kernel team to have enough spare engineering resources.
[04:44] <DanaG> Oldest device I've tried Linux on: Zaurus "Collie" -- Angstrom claimed to offer support for it, and yet failed to enable config options for Zaurus Collie drivers in the kernel!
[04:45] <persia> Aww.
[04:45] <persia> Collies are cute.
[04:45]  * persia likes the slide action, but not the resultion so much
[04:45] <DanaG> Drivers being broken or crappy, I can forgive... but not enabling CONFIG_UCB1X00_TS (or such)?  That's "fail".
[04:45] <persia> Oh, did I misremember?
[04:45] <persia> "Collie" is SLC-1x00 ?
[04:46] <DanaG> Yeah.
[04:46] <DanaG> er
[04:46] <DanaG> no
[04:46] <DanaG> Collie is SL-5500.
[04:46] <persia> Right, that's what I thought.
[04:46] <persia> Also the SL-B500 in Japan.
[04:46] <DanaG> Or anyway, whatever WAS the correct touchscreen driver... they didn't enable it.
[04:46] <persia> That's annoying.
[04:46] <DanaG> Last time I tried it was ages ago, though.
[04:46] <persia> You recompiled, I hope.
[04:48] <DanaG> er, I don't remember, now.  I tried using openembedded; I ended up having to tell it to repeatedly copy MY .config over the one it tried to use.
[04:48] <DanaG> I much prefer the Ubuntu / Debian way: dpkg-buildpackage.  or make-kpkg.
[04:54] <persia> And, once we conquer the world, just apt-get install.
[05:13] <lifeless> persia: have you heard of scratchbox?
[05:14] <persia> lifeless: Yes.  I don't like the concept of SDKs.
[05:14] <lifeless> ok
[05:15] <persia> Plus I don't really like cross-compilation (although I don't mind emulated compilation)
[05:15] <persia> lifeless: Why?
[05:16] <lifeless> just been talking to raster about why he had two laptops with him
[05:16] <persia> one was a runtime environment, and th other a scratchbox environment?
[05:16] <lifeless> two scratchboxes, one per vendor
[05:16] <persia> Aha.
[05:17] <persia> In our world, we'd have two pbuilder tar.gzs or two schroots on the same laptop.
[05:17] <persia> But that runs slower.
[07:03] <Elive_user28_en> ok, been trying to figure out why I keep seeing kernel panic trying to boot a jaunty fs on my hawkboard (OmapL138)
[07:03] <Elive_user28_en> Finally in a doh moment I split my mmc card in half and had angstrom mount the jaunty half
[07:04] <persia> And?
[07:04] <Elive_user28_en> if i try to run (even with ld_library_path.. ) anything from jaunty I get illegal instruction
[07:04]  * persia looks up the OmapLi386
[07:04] <persia> Er,, L138
[07:04] <Elive_user28_en> did something change? There were posts of people claiming to have made it work
[07:04]  * persia has typed i386 too many times today
[07:04] <Elive_user28_en> oh yea..
[07:04] <Elive_user28_en> sorry
[07:04] <Elive_user28_en> l138
[07:05] <persia> http://focus.ti.com/docs/prod/folders/print/omap-l138.html ?
[07:05] <Elive_user28_en> I even tried a trick switching boot arg /sbin/init to /bin/bash.. no dice
[07:05] <Elive_user28_en> yes
[07:05] <Elive_user28_en> that is the core chip on the hawkboard
[07:05] <persia> Setting init to /bin/bash just launches a shell instead of the normal boot process.
[07:05] <Elive_user28_en> angstrom works, and supposedly some have built android..
[07:06] <persia> It looks to me like you *should* be able to run Jaunty, but nothing newer.
[07:06] <Elive_user28_en> right even that fails..
[07:06] <Elive_user28_en> it does report mounting rootfs
[07:06] <persia> You're sure the kernel you're using works?
[07:06] <Elive_user28_en> ext2.. the kernel boots angstrom just fine
[07:07] <Elive_user28_en> is there a earlier than Jaunty option? or some way to specify processor familly?
[07:07] <persia> No and No.
[07:07] <persia> You might be interesed in Debian, but it may be possible to get Jaunty to work.
[07:07] <Elive_user28_en> course.. what would be supper slick (though time consuming and probably problematic) would be to pull the sources and build
[07:08] <Elive_user28_en> given arch / cross compiler arguments
[07:08] <persia> Takes a few months :)
[07:08] <Elive_user28_en> but thats just me
[07:08] <persia> 20,000 packages is a bunch.
[07:08] <Elive_user28_en> well yea if we built them all :)
[07:08] <Elive_user28_en> just the seeds people are requesting..
[07:09] <Elive_user28_en> make their puters build them
[07:09] <Elive_user28_en> shoot forgot to change nic
[07:10] <auzieman> I'm building a minimal jaunty now will try it..
[07:10] <auzieman> you mention debian and while I am a fan I am not a guru on debian
[07:10] <auzieman> how the heck do we fetch the debian arm debs
[07:11] <persia> From your local repo.
[07:11] <persia> Or do you mean "Is there a tool like rootstock that runs on Debian?"
[07:11] <auzieman> yes a rootstockish tool
[07:11] <auzieman> my core install is actually Elive (Lenny based E217)
[07:12] <auzieman> so I actually would rather not go into my vbox to wait on these..
[07:12] <persia> I don't know of one: we could hope that rootstock upstream extends the scripts to work also in Debian.
[07:13] <auzieman> yea.. suppose its download for arch and then deb with chroot or such
[07:13] <persia> But you should be able to run debootstrap from your angstrom or elive install to get a base chroot.
[07:14] <auzieman> angstrom has a aptish tool I just was hoping for an ubuntu or deb source rather than angstrom..
[07:15] <auzieman> I could I suppose ponder trying to do the whole damn thing from sources (ewwwwwww) 2gb ram and duo cpu it'd take a while
[07:17] <persia> No really.  The program "debootstrap" will do 90% of what you want.
[07:17] <persia> Most of rootstock is wrapping debootstrap around an emulated chroot.
[07:17] <auzieman> Ill check it out..
[07:18] <persia> Note that using debootstrap doesn't do everything, there will be a few files missing (like /etc/fstab), but you ought be able to create those.
[07:18] <auzieman> I think the trick here is getting the sources in the right order and building them with the cross compiler
[07:18] <persia> I don't know why you're getting "illegal instruction", but I'm unsure would get updates to fix that.
[07:18] <auzieman> that way everything is a dead match to the kernel / uboot etc
[07:18] <persia> debootstrap won't do that.  It just gets the binaries in the right order and installs them in a chroot.
[07:19] <persia> Bootstrapping is harder.
[07:19] <auzieman> jep..
[07:19] <auzieman> for now I probably would just continue with Angstrom.. at least till the android git repos are back on line and I finally build that beasty
[07:20] <auzieman> Though android will be a bit silly in my case as I just want headless.. but I think it would be funny
[07:20] <auzieman> to run a robot using android
[07:20] <auzieman> putting the droid back into its name
[07:21] <persia> heh.  Good pun.
[07:21] <persia> Perhaps less good OS choice: from what I've heard, Android is stripped down below what many consider the minimum to maximise that GUI experience.
[07:22] <persia> Dunno if you can get the robot controls working (but extra points if you can)
[07:22] <auzieman> I'm being somewhat loopy .. planing on mostly python
[07:22] <persia> python+android?  Good luck.
[07:23] <auzieman> pondering a few other packages like the openvision stuff
[07:23] <auzieman> python is in android
[07:23] <auzieman> so is some form of java
[07:23] <auzieman> wait let me recheck the source tree.. I have a partial checkout
[07:24] <auzieman> ./external/clearsilver/python
[07:24] <auzieman> yep.. as well as wx bindings and a whole mess of sections
[07:24] <auzieman> android is more linux than they would like us to think
[07:25] <persia> It'S just an uncommon application :)
[07:25] <auzieman> its part of WebKit and e2fsprogs in their world..
[07:25] <persia> The base kernel and libraries are 100% linux, just stripped down enough that they aren't SUS or in some cases even POSIX compliant.
[07:25] <auzieman> its a biatch of a build though
[07:25] <auzieman> well yea
[07:26] <persia> Doesn't mean you can't do stuff, just makes it a bit trickier (and faster)
[07:26] <auzieman> shoot you should shell into angstrom on a hawkboard
[07:26] <auzieman> audio drivers but no /dev/dsp
[07:26] <auzieman> video drivers with no /dev/video
[07:26] <persia> angstrom is (just) SUS compliant
[07:29] <auzieman> but at the same time they offer stuff like ffmpeg but it cant find audio or video sources
[07:29] <auzieman> oh here but best of luck getting it to run
[07:30] <persia> heh.  insufficient integration
[07:30] <persia> Now only if you had Ubuntu work, we could look at integration;)
[07:32] <auzieman> thats why I was hoping for an ubuntu bin set for my hawkboard :/
[07:33] <auzieman> the hawkboard has usb, audio, svga, 128mb nand + ram mmc slot 89.00 @300MHZ
[07:33] <auzieman> You could put it in a lil case and use it as a simple workstation.. but running on a usb powersupply
[07:33] <auzieman> and its actually very zippy on the shell
[07:35] <auzieman> I would think ubuntu would be all over the hawk, beagle and a few of the other cheapish arm boards
[07:36] <auzieman> shoot they could make a little money just selling sdk kits / books for them and get a bunch of startups / hacks like me all involved..
[07:37] <auzieman> any how thanks for the help, Ill transfer the image in a few and retest it..
[08:14] <auzieman> yep jaunty is happish on hawkboards
[08:15] <auzieman> at least so far..
[09:51] <ogra> I: copying [../rootstock_0.1.99.2-0ubuntu1_source.changes]
[09:51] <ogra> I: copying [../utils]
[09:51] <ogra> cp: cannot stat `../utils': No such file or directory
[09:51] <ogra> ???
[09:51]  * ogra wonders about his pbuilder 
[09:56] <ogra> sigh, upgrading pbuilder doesnt fix it
[09:56] <ogra> i wonder how that broke
[10:08]  * ogra doesnt belive it ... even wiping my whole pbuilder sertup and rebuilding it doesnt fix it
[10:41] <asac> dyfet: status on "Package and maintain Canola and deps in lucid archive: TODO"
[10:41] <asac> ?
[10:41] <asac> thats still on beta list
[10:42] <JamieBennett> asac: I packaged most of the deps and we have a ppa for canola, just needs the final push
[10:42] <JamieBennett> (and got them packaged/sync'd e.t.c, I didn't do all the package work)
[10:43] <JamieBennett> asac: most dependencies are satisfied by the work done for netbook-launcher-efl
[10:44] <asac> persia: mobile-lucid-arm-lib-tests ... two items i need input on there ;)
[10:46] <asac> JamieBennett: yeah. is that pp amaintained by us?
[10:46] <asac> or by oem or someone else
[10:46] <JamieBennett> asac: OEM from what I remember
[10:46] <asac> i think its fine to say that spec is done if its packaged and maintained by us
[10:47] <JamieBennett> asac: Canola needs bringing into universe ideally
[10:55] <asac> JamieBennett: 532548
[10:55] <asac> JamieBennett: do you have the url for canola?
[10:56] <JamieBennett> asac: http://openbossa.indt.org/canola/
[10:56] <asac> JamieBennett: sorry. the ppa i mean
[10:56] <JamieBennett> asac: not, handy, let me look
[10:58] <JamieBennett> asac: https://edge.launchpad.net/~canola/+archive/ppa?field.series_filter=lucid
[10:59] <JamieBennett> looks like there are more dependencies than I remember
[11:01] <asac> JamieBennett: all those need to get in?
[11:01] <JamieBennett> asac: No
[11:02] <JamieBennett> asac: we need to assess exactly what is needed
[11:02] <asac> bug 532549
[11:02] <ubot4`> Launchpad bug 532549 in ubuntu "[FFe] ubuntu-webmail (affects: 1)" [Undecided,New] https://launchpad.net/bugs/532549
[11:02] <asac> (just for record)
[11:02] <asac> JamieBennett: seems the uploads were done after efl launcher landing
[11:02] <asac> so without looking it feels all the packages are on top there
[11:12] <asac> bug 532554
[11:12] <ubot4`> Launchpad bug 532554 in ubuntu "[FFe] canola for lucid/universe (affects: 1)" [Undecided,New] https://launchpad.net/bugs/532554
[11:12] <asac> JamieBennett: ^^ filed that
[11:12] <JamieBennett> asac: OK
[11:12] <asac> didnt subscribe release yet, we first need the packages needde
[11:13] <JamieBennett> dyfet was going to do that, not sure how far he got with it
[11:13] <asac> thats why i pinged him first ;)
[11:14] <JamieBennett> asac: yes :)
[11:17] <dyfet> I have a package for it, and it packages very nice now that we have etk for the launcher, but I was not certain if canola itself is being maintained, and it's based on a snapshot of the source repo
[11:17] <dyfet> thats why I was hesitant
[11:22] <asac> dyfet: you have a package? from the list there seems to be a bunch of packages required
[11:22] <asac> can you come up with a minimal list?
[11:23] <dyfet> asac: they are packages also used by the new 2d launcher :)
[11:23] <dyfet> canola itself is python, but it used a lot of enlightenment toolkit stuff...
[11:24] <JamieBennett> dyfet: what about the media scanner?
[11:25] <asac> dyfet: : https://edge.launchpad.net/~canola/+archive/ppa?field.series_filter=lucid
[11:25] <asac> thats the list of packages in the ppa ... that we dont have in our archive
[11:25] <asac> please come up with a list of items that nees to get done quick ;)
[11:26] <asac> then we can decide if we put it in archive or not
[11:26] <dyfet> Okay
[11:26] <asac> cool ... at best i would have that before todays release meeting ;)
[11:26] <asac> like in 3h
[11:27] <dyfet> Well, I have to go to the eye doctor this morning
[11:28] <dyfet> so it will likely be a bit later this afternoon
[11:29] <JamieBennett> asac: let me finish off this weboffice packaging and I'll take a look at canonla dependencies
[11:30] <JamieBennett> *canola* :)
[11:30] <asac> heroic ;)
[11:30] <asac> Selecting previously deselected package indicator-session.
[11:30] <asac> Unpacking indicator-session (from .../indicator-session_0.2.4-0ubuntu2_armel.deb) ...
[11:30] <asac> ogra: ^^ thats where it hangs for me
[11:30] <asac> it seems
[11:31] <asac> well its consuming CPU cycles
[11:31] <asac> but doesnt move forward
[11:31] <asac> ogra: does the output i see on console directly come from the qemu command? or is that piped out somehow too?
[11:37] <JamieBennett> NCommander: the girlfriend or the cat ;)
[11:51] <ogra> asac, there read directly from a fifo
[11:51] <ogra> asac, but the rootstock script doesnt matter, if you build with --keepimage and use ubuntu-minimal and then run qemu-system-arm the behavior will be the same
[11:52] <ogra> s/there/they are/
[11:52] <ogra> its intresting though that it gets stuck on a different package for you
[12:04] <asac> ogra: so i can use --keep-image and i can then switch in there and install the ubnutu-netbook thing?
[12:04]  * asac does that
[12:05] <ogra> right
[12:05] <ogra> --keepimage
[12:05] <ogra> no dash
[12:05] <ogra> that gives you a qemu image
[12:05] <ogra> use -l and -p for it
[12:05] <ogra> else you get dropped into oem-config first
[12:05] <ogra> s/first/on first boot/
[12:06] <asac> sudo rootstock -l -p --keepimage -f blah -s ubuntu-minimal^ -i 3G
[12:06] <asac> that?
[12:06] <ogra> -l and -p need parameters
[12:06] <asac> yeah
[12:06] <ogra> -l <login name> -p <passwd>
[12:06] <asac> ok its running
[12:06] <ogra> and you wouldnt need 3G here :)
[12:06] <ogra> minimal fits in less than 1
[12:07] <asac> but i want to go in there and install the reest
[12:07] <ogra> oh, indeed, you want to keep the image ... so 3G is fine
[12:07] <asac> so i think i need more space
[12:07] <ogra> yep
[12:07] <ogra> didnt think about that
[12:07] <ogra> i'm just trying the qcow2 conversion stuff here ...
[12:08] <ogra> not having to specify the size will be a huge win
[12:09] <ogra> given that you see the hang on a different package i wonder if the amount of RAM of the host somehow influences it
[12:09] <ogra> i got 4G here
[12:09] <ogra> (using the pae kernel)
[12:09] <ogra> how much has your machine ?
[12:12] <ogra> hmm, the conversion doesnt take to much time for raw->qcow2 ...
[12:12]  * ogra wonders about the way back once the fs is filled up
[12:22] <asac> ogra: qemu-static-arm wants a kernel
[12:22] <asac> err system-arm
[12:22] <ogra> one sec
[12:22] <asac> if i just pass the .img
[12:22] <ogra> qemu-system-arm -M versatilepb -cpu cortex-a8 -kernel ./vmlinuz -hda arm-rootfs.img -m 256 -append "root=/dev/sda mem=256M devtmpfs.mount=0 rw"
[12:22] <ogra> http://ports.ubuntu.com/ubuntu-ports/dists/lucid/main/installer-armel/current/images/versatile/netboot/vmlinuz
[12:22] <ogra> use that kernel
[12:23] <asac> err
[12:23] <asac> ok
[12:23] <ogra> arm-rootfs.img needs to be your .img indeed
[12:23] <asac> but dont you add that anyway?
[12:23] <asac> e.g. why is that gone after --keepimage?
[12:23] <ogra> the kernel ?
[12:24] <asac> well. you go to second stage and boot the vm, dont you?
[12:24] <ogra> because rootstock isnt designed as a VM imagebuilder :) its just a sideeffect that a VM is used
[12:24] <ogra> --keepimage is just skipping the tarball creation
[12:26] <ogra> the kernel above is what is used during build, its documented everywhere how to get it ... while it saves some bandwith to keep it i dont want to start storing a gazillion of files of one build
[12:27] <ogra> hmm, using qcow2 seems to make the VM act faster
[12:27] <ogra> at least "felt"
[12:36] <ogra> yay, qcow2 works fine
[12:36]  * ogra tries a bigger task than ubuntu-minimal 
[12:49] <ogra> The following packages have unmet dependencies:
[12:49] <ogra> libgtk2.0-bin: Depends: libgtk2.0-0 (>= 2.19.6-1ubuntu4) but 2.19.6-1ubuntu3 is to be installed
[12:49] <ogra> GRRRRR !!!!!!
[12:50] <ogra> i really start hating arch: all packages
[12:55] <asac> noted
[12:55] <ogra> heh
[12:55] <ogra> i think for ports we should have special casing ...
[12:56] <ogra> so _all.deb dont get published until all the arch dependent packages are ready
[12:56] <ogra> assuming that prots has special code in the publisher already since its a different server
[12:57] <JamieBennett> asac: canola dependencies - http://pastebin.ubuntu.com/388929/
[12:57] <lool> persia: If people want a stable URL to get a versatile kernel, the d-i one is probably best
[12:59] <asac> JamieBennett: all packages are in that ppa?
[12:59] <asac> ogra: well. you want to wait for really slow sparc?
[13:00] <asac> anyway, i know that some folks in debian would want the archive to act like that
[13:00] <ogra> asac, rather than having broken images all the time or not being able to test rootstock
[13:00] <asac> you have a local mirrorß
[13:00] <asac> when its ok, stop upgrading ;)
[13:00] <ogra> i will novw have to wait half the day until i can do my next testrun
[13:01] <ogra> i dont have a local mirror
[13:01]  * ogra considers local mirrors a massive waste of space ... i use package proxies
[13:01] <asac> package proxy is kind of a mirror
[13:02] <ogra> right, "kind of"
[13:02] <ogra> it verifies its content with the archive first
[13:02] <ogra> and hands the breakage through
[13:03] <ogra> i could use the file:// protocol directly on the cache ... but rootstock cant support that since qemu wont see it
[13:03] <ogra> probably something to implement in rootstock 5.0 or so :)
[13:07] <JamieBennett> asac: Yes, all packages are there. Tested it in a Lucid VM and all is good.
[14:26] <ogra> The following packages have unmet dependencies:
[14:26] <ogra> initramfs-tools: Depends: initramfs-tools-bin (= 0.92bubuntu67) but 0.92bubuntu66 is to be installed
[14:26]  * ogra cries
[14:26] <ogra> there goes ubuntu-minimal
[14:26] <ogra> :/
[14:56] <asac> i am off the phone calls for torday :(
[14:57] <ogra> to prepare for the IRC meeting eh
[14:57] <ogra> you must loive your fridays
[14:57] <asac> three calls in a row ;)
[14:58] <asac> now crazy stuff like release team wants to know something
[14:58] <ogra> yeah
[15:21]  * ogra commits and pushes the autosize function for rootstock
[15:21] <ogra> yay ... no more need for defining the imagesize
[15:26] <ynezz> nice :)
[15:42] <mturquette> trying to build lucid with roostock.  kicked off the build before leaving the office last night and this morning I am stuck at,
[15:42] <mturquette> I: Getting Virtual Machine kernel from the server
[15:42] <mturquette> I: Switching to Virtual Machine for second stage processing
[15:42] <mturquette> I assume the Virtual Machine (QEMU ARM, right?) shoudn't take 10+ hours...
[15:42] <ogra> no
[15:42] <ogra> whats your host system running ?
[15:43] <mturquette> core i7, 8 processors if you count hyperthreading, lots of RAM and Ubuntu 9.10
[15:43] <ogra> ah, karmic
[15:43] <mturquette> known issues?
[15:43] <ogra> and you use the packaged rootstock i guess ?
[15:43] <mturquette> I did this time.
[15:43] <mturquette> previously I used the tarball from launchpad
[15:44] <ogra> karimc is missing http://bazaar.launchpad.net/~project-rootstock-developers/project-rootstock/trunk/revision/31
[15:44] <mturquette> latest tarball on launchpad has that?
[15:45] <ogra> yes, i uploaded it this morning
[15:45] <mturquette> thanks, will try.
[15:45] <ogra> though its not tested on karmic yet, i test on lucid only atm
[15:46] <ogra> if everything works fine please report it here :)
[15:46] <mturquette> ogra: will do.
[15:46] <ogra> thanks :)
[15:46] <mturquette> looking at revision 31, I can't help but notice you ony pass 256M RAM to QEMU
[15:46] <mturquette> any reason why you run it that low?
[15:47] <ogra> yes, qemu-system-arm cant handle more
[15:47] <mturquette> well that would explain it ;-)
[15:47] <ogra> heh
[15:47] <ogra> for rollong a rootfs you dont really need more though
[15:47] <ogra> its all just apt/dpkg
[15:48] <mturquette> yeah, i'm not familiar with the overhead of package managers really.
[15:48] <asac> ogra: what bugnumber shoujld i name for the qemu problems?
[15:48] <ogra> asac, there is none yet
[15:49] <ogra> asac, bug 530000 might also be intresting but given i doubt that can be fixes before release probably nbot appropriate
[15:49] <ubot4`> Launchpad bug 530000 in qemu-kvm (Ubuntu) "mono assembly installation under qemu-arm-static hangs (affects: 1)" [Medium,Confirmed] https://launchpad.net/bugs/530000
[15:50] <asac> ogra: we need a bug for that if it consumes a full week ;)
[15:50] <asac> of your precious time
[15:50] <asac> RC bug even
[15:50] <asac> maybe open one even if not enough info
[15:51] <mturquette> how functional is the rootstock gui at this point?
[15:52] <ogra> asac, bug 532733
[15:52] <ubot4`> Launchpad bug 532733 in qemu-kvm (Ubuntu) "apt/dpkg in qemu-system-arm hangs if a big task is installed (affects: 1)" [Undecided,New] https://launchpad.net/bugs/532733
[15:52] <asac> * imx51 and dove in good shape
[15:52] <ogra> mturquette, its functional in lucid ... totally untested in karmic
[15:53] <asac> plars: GrueMaster: ^^ is that right statement?
[15:53] <ogra> mturquette, but still has issues i need to fix before release ... else i need to buy asac a triple core laptop to demote one core to the UI :)
[15:53] <asac> lol
[15:53] <ogra> asac, iirc todays build was broken
[15:54]  * ogra checks logs
[15:54] <asac> out of sync
[15:54] <asac> or anything serious
[15:54] <ogra> ah, no, todays was good
[15:54] <ogra> yesterdays was "artwork out of sync"
[15:55] <asac> !info newlib
[15:55] <ubot4`> asac: Package newlib does not exist in karmic
[15:55] <ogra> heh
[15:55] <asac> bug 514232
[15:55] <ubot4`> Launchpad bug 514232 in newlib (Ubuntu Lucid) (and 1 other project) "[arm] needs porting to thumb2 (affects: 1)" [High,Invalid] https://launchpad.net/bugs/514232
[15:55] <ogra> !info libnewlib0
[15:55] <ubot4`> ogra: libnewlib0 (source: newlib): newlib C library (runtime). In component universe, is extra. Version 1.17.0-0ubuntu5 (karmic), package size 1509 kB, installed size 4384 kB
[15:55] <asac> bug 507503
[15:55] <asac> !info source newlib
[15:55] <ubot4`> Launchpad bug 507503 in linux-mvl-dove (Ubuntu Lucid) (and 3 other projects) "VFP/NEON state is not preserved around signal handlers, causing state corruption between user processes (affects: 1)" [High,Fix released] https://launchpad.net/bugs/507503
[15:55] <ubot4`> asac: 'newlib' is not a valid distribution: hardy, intrepid, jaunty, karmic, lucid
[15:55] <asac> ubot4`: basterd
[15:55] <ubot4`> Factoid 'basterd' not found
[15:56] <ogra> !info newlib-source
[15:56] <ubot4`> ogra: newlib-source (source: newlib): newlib C library (source). In component universe, is extra. Version 1.17.0-0ubuntu5 (karmic), package size 4162 kB, installed size 4252 kB
[15:56] <ogra> he likes me more :P
[15:56] <asac> hwat a bad syntax
[15:56] <asac> bug 507416
[15:56] <ubot4`> Launchpad bug 507416 in uboot-imx (Ubuntu Karmic) (and 5 other projects) "CONFIG_NEON=y causes platform lockups with certain application/platform combinations (affects: 2)" [Undecided,Invalid] https://launchpad.net/bugs/507416
[15:57] <ogra> #GEEZ !!!!!!!!!!!!!!!!!!!!!!!!!!!11
[15:57] <ogra> Selecting previously deselected package iso-codes.
[15:57] <ogra> Unpacking iso-codes (from .../iso-codes_3.12.1-1_all.deb) ...
[15:57] <ogra> Selecting previously deselected package libgnomekbd4.
[15:57] <ogra> Unpacking libgnomekbd4 (from .../libgnomekbd4_2.29.5-0ubuntu1_armel.deb) ..
[15:57] <ogra> \o/
[15:57]  * ogra dances
[15:57] <ogra> asac, so qcow2 solves all our probs it seems
[15:57]  * ogra is so happy
[15:58] <ogra> ... and hopes it will survive now and not just hang later
[15:58] <ogra> doobeydoobeydoo ...
[16:00] <asac> bug 528524
[16:00] <ubot4`> Launchpad bug 528524 in totem (Ubuntu Lucid) (and 3 other projects) "Sound not working in all apps on dove (affects: 2)" [High,New] https://launchpad.net/bugs/528524
[16:01] <asac> ogra: wait till it finishes
[16:01] <ogra> indeed
[16:01] <asac> the current rootstock hangs randomly for me
[16:01] <ogra> but it looks so good
[16:01] <asac> bug 512959
[16:01] <ubot4`> Launchpad bug 512959 in nautilus (Ubuntu Lucid) (and 5 other projects) "causes crashes on armel with -Wl,-O1 (affects: 1)" [Low,Invalid] https://launchpad.net/bugs/512959
[16:01] <ogra> i'm convinced its an I/O prob with raw images
[16:01] <ogra> i suspected that since a while
[16:03] <ogra> asac, its also a lot faster with qcow2
[16:06] <plars> ogra: I wanted to start taking a look at the rootstock testplan, is that still accurate that I should pull that 200952 version? or should I just be using what's in trunk?
[16:07] <plars> oh wait, that's redboot
[16:07] <plars> nm
[16:07]  * plars goes to get more caffeine
[16:07] <ogra> wait for my next upload, if the build i'm testing now finishes then i seem to have a fix for the hang and it should be fully usable
[16:07] <plars> ogra: but still... should I be using what's in lucid? or just pull the branch and test from that
[16:08] <ogra> currently the branch only has one more commit beyond the package in lucid
[16:08] <ogra> oh no !
[16:09] <ogra> failed in buffer_write(fd) (11, ret=-1): backend dpkg-deb during `./usr/share/doc/cdparanoia/README.gz': No space left on device
[16:09] <ogra> tar: ./postinst: Cannot write: No space left on device
[16:09] <ogra> GRRRR !
[16:09] <plars> guess the autosize needs some work? :)
[16:09] <ogra> it shouldnt
[16:09] <ogra> qemu handles it on its own
[16:11]  * ogra tries with giving a virtual imagesize
[16:11] <ogra> it would be odd if that was needed though
[16:13] <asac> https://wiki.ubuntu.com/MobileTeam/ReleaseStatus/Lucid
[16:16] <ogra> is bug 528887 arm specific ?
[16:16] <ubot4`> Launchpad bug 528887 in maximus (Ubuntu Lucid) (and 2 other projects) "maximus does not give default focus to newly started apps in combination with efl launcher (affects: 1)" [Medium,Triaged] https://launchpad.net/bugs/528887
[16:16] <ogra> (i know i added the tag but it might also happen on x86)
[16:17] <ogra> asac, should we ping server for bug 517300 ? there was no reaction to me assigning it to them
[16:17] <ubot4`> Launchpad bug 517300 in likewise-open (Ubuntu Lucid) (and 1 other project) "[armel] likewise-open needs porting to ARM (affects: 1)" [High,Triaged] https://launchpad.net/bugs/517300
[16:17] <asac> ok at least qa team suffers from same desease ;) http://people.canonical.com/~pitti/workitems/canonical-platform-qa-ubuntu-10.04-beta-1.html
[16:18] <ogra> woah, slackers !
[16:18] <ogra> :)
[16:18] <asac> well http://people.canonical.com/~pitti/workitems/canonical-mobile-ubuntu-10.04-beta-1.html ;)
[16:18] <asac> isnt really that heroic either :-P
[16:18] <asac> i forced the green line down a bit at least ;) ...
[16:18] <asac> s/down/further down/
[16:19] <ogra> woah, we slackers !
[16:19] <ogra> :)
[16:19] <asac> well. its the final items
[16:19] <asac> those are usually the most painful ;)
[16:19] <ogra> report looks fine to me
[16:19] <asac> exce the webservice ones
[16:19] <asac> i updated it again with bugs
[16:20]  * ogra reloads
[16:21] <ogra> yup
[16:22]  * ogra gets coffee
[16:30] <asac> http://people.canonical.com/~pitti/workitems/canonical-server-ubuntu-10.04-beta-1.html
[16:30] <asac> they suffer from a different desease even ;)
[16:31] <ogra> lol
[16:31] <ogra> someone secretly loads off work items on them :)
[16:33] <asac> lets give them likewise ;)
[16:33] <ogra> heh
[16:33] <asac> one more doesnt matter i guess
[16:33] <ogra> should we make that a workitem ?
[16:34]  * ogra thought making it a critical bug would be enough :)
[16:34] <asac> ogra: its on our list now
[16:34] <ogra> yes, saw it
[16:34] <asac> because of that ;)
[16:35] <ogra> oh, you added it to our workitems as a foreign task for them ?
[16:35] <ogra> i.e. it shows up in the tracker ?
[16:47] <dmart_> Saw the new netbook image... nice (and it seems to mostly work too)
[16:48] <ogra> :)
[16:48] <dmart_> purple
[16:48] <ogra> we'll fix the remaining pieces soon :)
[16:48] <ogra> yeah
[16:48] <ogra> purple is the new brown !
[16:49] <dmart_> heh
[16:49] <dmart_> Colour scheme is a bit interesting in places, but I expect they'll iron that out soon enough
[16:51] <ogra> yeah
[16:51] <ogra> file bugs :)
[16:52]  * dmart_ is too lazy
[16:52] <dmart_> The artwork and themes usually goes through a bit of churn at this point anyways
[16:53] <ogra> indeed
[16:54] <ogra> but if you find something really bugging you dont hesitate :)
[16:54] <dmart_> sure
[16:54] <DanaG> dmart_: are you on the artwork team?
[16:54] <DanaG> I just posted a comment on the mailing-list.
[16:54] <dmart_> No, just admiring the results
[16:54]  * ogra hands dmart_ a paintbrush
[16:55] <ogra> now you are !
[16:55] <ogra> :)
[16:55] <dmart_> (you didn't want to do that...)
[16:56]  * ogra is with Joseph Beuys here ... everything is art ...
[16:56] <ogra> even code :)
[16:57] <dmart_> I need to work out how to change vim's syntax colour scheme to match then...
[17:02] <mturquette> QEMU ran out of disk space during roostock build.  log at,
[17:02] <mturquette> http://pastebin.com/kGwL89cY
[17:02] <ogra> mturquette, thats gui or cmdline tool ?
[17:02] <mturquette> cmdline
[17:03] <ogra> and what did you pick for the -i stting ?
[17:03] <ogra> *setting
[17:03] <ogra> a desktop install should have about 5G
[17:03] <mturquette> don't have -i.  is that image size?
[17:03] <ogra> yep
[17:04] <ogra> i'm just experimenting with auto-growing qemu images but i'm not there yet, you need to specify the size
[17:04] <ogra> mturquette, https://wiki.ubuntu.com/ARM/RootfsFromScratch might be helpful
[17:04] <mturquette> -i is under "additional options" not "required", so i left it out.
[17:05] <ogra> (a lot will change for lucid though, i want to get to a point where you dont need any options at all)
[17:05] <mturquette> sure sure.  I was actually going off of a beagle wiki since that is the platform I'm building for.  I'll specify an image size and try again.
[17:06] <ogra> hmm, i thought even the beagle wiki was setting size ...
[17:06] <mturquette> ogra: you're right it does.  I must have made an executive decision.
[17:06] <ogra> that i didnt put it in required options is simply due to the fact that it depends on what you actually install ... rootstock defaults to 1G and thats enough for basic installs ...
[17:07] <ogra> if you add desktop stuff to it it indeed grows
[17:07] <mturquette> i'm going with 5GB now.  guess I'll boot over NFS...
[17:07] <ogra> --seed lxde,gdm might work without -i :)
[17:23] <GrueMaster> asac: seems accurate
[17:23] <GrueMaster> imx51 and dove images are fairly stable for me at least.
[17:24] <ogra> plars, did you find out what was the issue with your dove installs ?
[17:24] <plars> ogra: I spent quite a bit of time messing with it last night, with a3 image
[17:24] <ogra> and ?
[17:24] <ogra> HW ok ?
[17:24] <plars> ogra: 1st few times, I couldn't even get it to boot successfully, then once I got it up, installed memtester, hit some errors, ran memtester again, no errors
[17:25] <ogra> weird
[17:25] <plars> ogra: this morning, having trouble booting again.  Instead of locking up again, it's complaining about the squashfs now
[17:25] <plars> ogra: rebooting now, I reseated the memory, but I don't have high hopes
[17:25] <ogra> well, as last resort get the ram replaced
[17:27] <DanaG> Or if you have multiple sticks of RAM, try with just one, or the other.
[17:29] <plars> DanaG: I only have the one stick, and I think it's ecc sodimm
[17:29] <plars> ogra: did we ever determine what kinds of memory would work on these boards?
[17:30] <plars> ogra: I thought someone was going to try a generic sodimm, NCommander maybe?
[17:30] <ogra> i never had the balls to do that
[17:30] <ogra> but afaik it needs to be specific marvell ram
[17:31] <ogra> i would be to scared to damage the board, i have a 1G DDR2 stick lying here that would fit in the socket though
[17:31] <ogra> but i also only have a Y0 here
[17:32] <plars> ogra: at least it's not soldering we need to do on this one :)
[17:32]  * ogra discovers qemu-nbd ... 
[17:32] <ogra> heh, yeah
[17:32] <ogra> though i dont mind soldering
[17:33] <ogra> hmm, with qemu-nbd i wouldnt need to convert the image back and forth all the time
[18:00]  * ogra calls it a day ... 
[18:00] <ogra> i hope i have rootstock fixed by monday ... i'll be around on the weeken
[18:00] <ogra> d
[19:22] <Martyn> Does anyone have a system image for the lange 5.1 board?
[23:30] <NCommander> plars: I never tried changing the RAM, plus you need a customized u-boot to match the board RAM configuration