[00:00] james_l: the man page ts.conf(5) says its the configuration for tslib ;) [00:00] ts.conf - Configuration file for tslib, controlling touch screens for embedded devices. [00:01] 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] is "confiugration" a command? maybe run in strace to see what it writes [00:08] Ah, found what I was looking for /etc/pointercal [00:08] * asac_the_2nd nods [00:19] Does anyone know if rootstock works with lucid or whether I should stick with karmic? [00:40] porter1: lucid as a host or a target? [00:40] persia, both [00:40] 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] It appears as though rootstock gets stuck after extracting in debootstrap, so I might try just executing by hand for now [00:41] 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] Yeah, I shouldn't have switched until the first beta, but it isn't too painful :) [00:43] I usually switch much earlier: I just like to warn folks :) [00:44] So 2.6.32-13 in ogra's archive is not supposed to run right in qemu I guess? [00:45] I don't know offhand. [00:45] I think lool was advocating extracting the kernel from the linux-versatile build in lucid. [00:46] oh [00:47] I might just stick with the 2.6.31 for a while then. THanks for the help. [01:03] bug 532342 [01:03] 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] bug 532343 [01:03] Launchpad bug 532343 in rootstock (Ubuntu) "think about rootstock .desktop file Categories (affects: 1)" [Undecided,New] https://launchpad.net/bugs/532343 [01:07] asac? [01:09] just bugs i filed ;) [01:09] feel free to comment or ignore :-P [01:13] hmm. rootstock-gtk is looping on CPU while nothing happens in UI ... just in the VM [01:26] filed [01:27] bug 532358 ;) [01:27] 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] asac: But the VM is slammed, right? [01:33] Or is the VM using one core and the GUI another for useless polling? === bjf is now known as bjf-afk [01:41] not yet [01:41] its currently doing [01:41] Selecting previously deselected package iputils-arping. [01:41] Unpacking iputils-arping (from .../iputils-arping_3%3a20071127-2_armel.deb) ... [01:41] Selecting previously deselected package iputils-tracepath. [01:41] Unpacking iputils-tracepath (from .../iputils-tracepath_3%3a20071127-2_armel.deb) ... [01:42] hmm. doesnt move though ;) [01:42] just spins and consumes cycles [01:43] did ogra say it did that or was idling? [01:55] He said he had some issues with installing some stuff, and was trying to get lool to look into it. [03:23] question about compiler optimizing an inline function that access private member data, could be possible reason for crash in kdebindings [03:24] Go ahead :) [03:24] 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] 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] 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] The problem is that the "tokens" variable is private data [03:30] tuxdavis: interesting, how'd you find this? [03:31] compiling the kdebindings in debug mode, then ran the smokegen through gdb, since that's what was segfaulting [03:34] tuxdavis: interesting. sounds like a GCC bug [03:34] not necessarily [03:35] 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] but I'm testing this right now, by removing the inline then seeing what happens [03:35] tuxdavis: wonder why that works w.r.t. to !ARM [03:36] the inline command is a "recomendation" to the compiler not a requirement [03:36] so it's possible that it's making the optimization on ARM, but not on others [03:36] So we'd actually have to compare the output of the preprocessor cross-platform to understand hwo the choice is made :( [03:37] most likely [03:38] I'm trying a very simple test, by commenting out the inline keywords then recompile and see what happens [03:42] it's recompiling smokegen with the updated header file right now [04:13] 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] 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] Could you pastebin the backtrace? [04:16] yes, though it would take a bit because it's currently recompiling with the updated header [04:16] No rush. [04:16] I just like to read backtraces. Often I can understand something from them. [04:16] I have a feeling that you're right, and that it's a scoping problem. [04:17] Have you also tried dfferent -O levels to see if the behaviour changes? [04:18] Unfortunately I don't know yet exactly how to tell cmake to compile with different optimization levels [04:19] 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] then recompiling ALL the source files with the different optimization flags [04:20] Manually isn't right. [04:20] The folk in #kubuntu-devel may be able to suggest how to wrangle cmake. [04:20] let me check the cmake documentation and see if there's something in there [04:20] That works too :) [04:33] persia: tuxdavis: edit the C and CXX options lines in CMakeCache.txt in the build directory for Release builds (I think), [04:33] then run make [04:33] alternately, install ccmake, and edit it that way [04:33] oooh, 2.6.33 kernel on rcn-ee.net [04:33] ah [04:33] Bummer: it still doesn't suspend. [04:33] "class suspend failed for cpu 0" [04:35] hmm, is command-not-found supposed to not-work on ARM? [04:39] DanaG: Did you install it? [04:40] yeah. [04:40] Then it ought just work. [04:40] Doesn't seem very different from 2.6.32. [04:40] * persia checks quick-like [04:42] DanaG: Indeed. Doesn't work for armel, ia64, powerpc, or sparc. Please file a bug and subscribe me. [04:42] file it on "Linux" package? [04:43] On command-not-found [04:43] ah. [04:43] If you've a bug in your kernel, talk to rcn-ee for now. [04:43] ah. [04:43] Need to get the kernel into the distro before it's worth filing bugs on LP about it. [04:43] Are there plans to have an official Ubuntu-repo beagleboard kernel? [04:43] `ubuntu-bug command-not-found` ought do the right thing. [04:44] I have plans to support every single device capable of running Ubuntu ever manufactured. [04:44] I have doubts my plans will come to fruition [04:44] From what I was told asking about NetWalker kernels, it basically requires the kernel team to have enough spare engineering resources. [04:44] 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] Aww. [04:45] Collies are cute. [04:45] * persia likes the slide action, but not the resultion so much [04:45] Drivers being broken or crappy, I can forgive... but not enabling CONFIG_UCB1X00_TS (or such)? That's "fail". [04:45] Oh, did I misremember? [04:45] "Collie" is SLC-1x00 ? [04:46] Yeah. [04:46] er [04:46] no [04:46] Collie is SL-5500. [04:46] Right, that's what I thought. [04:46] Also the SL-B500 in Japan. [04:46] Or anyway, whatever WAS the correct touchscreen driver... they didn't enable it. [04:46] That's annoying. [04:46] Last time I tried it was ages ago, though. [04:46] You recompiled, I hope. [04:48] 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] I much prefer the Ubuntu / Debian way: dpkg-buildpackage. or make-kpkg. [04:54] And, once we conquer the world, just apt-get install. [05:13] persia: have you heard of scratchbox? [05:14] lifeless: Yes. I don't like the concept of SDKs. [05:14] ok [05:15] Plus I don't really like cross-compilation (although I don't mind emulated compilation) [05:15] lifeless: Why? [05:16] just been talking to raster about why he had two laptops with him [05:16] one was a runtime environment, and th other a scratchbox environment? [05:16] two scratchboxes, one per vendor [05:16] Aha. [05:17] In our world, we'd have two pbuilder tar.gzs or two schroots on the same laptop. [05:17] But that runs slower. [07:03] ok, been trying to figure out why I keep seeing kernel panic trying to boot a jaunty fs on my hawkboard (OmapL138) [07:03] Finally in a doh moment I split my mmc card in half and had angstrom mount the jaunty half [07:04] And? [07:04] 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] Er,, L138 [07:04] 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] oh yea.. [07:04] sorry [07:04] l138 [07:05] http://focus.ti.com/docs/prod/folders/print/omap-l138.html ? [07:05] I even tried a trick switching boot arg /sbin/init to /bin/bash.. no dice [07:05] yes [07:05] that is the core chip on the hawkboard [07:05] Setting init to /bin/bash just launches a shell instead of the normal boot process. [07:05] angstrom works, and supposedly some have built android.. [07:06] It looks to me like you *should* be able to run Jaunty, but nothing newer. [07:06] right even that fails.. [07:06] it does report mounting rootfs [07:06] You're sure the kernel you're using works? [07:06] ext2.. the kernel boots angstrom just fine [07:07] is there a earlier than Jaunty option? or some way to specify processor familly? [07:07] No and No. [07:07] You might be interesed in Debian, but it may be possible to get Jaunty to work. [07:07] course.. what would be supper slick (though time consuming and probably problematic) would be to pull the sources and build [07:08] given arch / cross compiler arguments [07:08] Takes a few months :) [07:08] but thats just me [07:08] 20,000 packages is a bunch. [07:08] well yea if we built them all :) [07:08] just the seeds people are requesting.. [07:09] make their puters build them [07:09] shoot forgot to change nic === Elive_user28_en is now known as auzieman [07:10] I'm building a minimal jaunty now will try it.. [07:10] you mention debian and while I am a fan I am not a guru on debian [07:10] how the heck do we fetch the debian arm debs [07:11] From your local repo. [07:11] Or do you mean "Is there a tool like rootstock that runs on Debian?" [07:11] yes a rootstockish tool [07:11] my core install is actually Elive (Lenny based E217) [07:12] so I actually would rather not go into my vbox to wait on these.. [07:12] I don't know of one: we could hope that rootstock upstream extends the scripts to work also in Debian. [07:13] yea.. suppose its download for arch and then deb with chroot or such [07:13] But you should be able to run debootstrap from your angstrom or elive install to get a base chroot. [07:14] angstrom has a aptish tool I just was hoping for an ubuntu or deb source rather than angstrom.. [07:15] 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] No really. The program "debootstrap" will do 90% of what you want. [07:17] Most of rootstock is wrapping debootstrap around an emulated chroot. [07:17] Ill check it out.. [07:18] 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] I think the trick here is getting the sources in the right order and building them with the cross compiler [07:18] I don't know why you're getting "illegal instruction", but I'm unsure would get updates to fix that. [07:18] that way everything is a dead match to the kernel / uboot etc [07:18] debootstrap won't do that. It just gets the binaries in the right order and installs them in a chroot. [07:19] Bootstrapping is harder. [07:19] jep.. [07:19] 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] Though android will be a bit silly in my case as I just want headless.. but I think it would be funny [07:20] to run a robot using android [07:20] putting the droid back into its name [07:21] heh. Good pun. [07:21] 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] Dunno if you can get the robot controls working (but extra points if you can) [07:22] I'm being somewhat loopy .. planing on mostly python [07:22] python+android? Good luck. [07:23] pondering a few other packages like the openvision stuff [07:23] python is in android [07:23] so is some form of java [07:23] wait let me recheck the source tree.. I have a partial checkout [07:24] ./external/clearsilver/python [07:24] yep.. as well as wx bindings and a whole mess of sections [07:24] android is more linux than they would like us to think [07:25] It'S just an uncommon application :) [07:25] its part of WebKit and e2fsprogs in their world.. [07:25] 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] its a biatch of a build though [07:25] well yea [07:26] Doesn't mean you can't do stuff, just makes it a bit trickier (and faster) [07:26] shoot you should shell into angstrom on a hawkboard [07:26] audio drivers but no /dev/dsp [07:26] video drivers with no /dev/video [07:26] angstrom is (just) SUS compliant [07:29] but at the same time they offer stuff like ffmpeg but it cant find audio or video sources [07:29] oh here but best of luck getting it to run [07:30] heh. insufficient integration [07:30] Now only if you had Ubuntu work, we could look at integration;) [07:32] thats why I was hoping for an ubuntu bin set for my hawkboard :/ [07:33] the hawkboard has usb, audio, svga, 128mb nand + ram mmc slot 89.00 @300MHZ [07:33] You could put it in a lil case and use it as a simple workstation.. but running on a usb powersupply [07:33] and its actually very zippy on the shell [07:35] I would think ubuntu would be all over the hawk, beagle and a few of the other cheapish arm boards [07:36] 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] any how thanks for the help, Ill transfer the image in a few and retest it.. [08:14] yep jaunty is happish on hawkboards [08:15] at least so far.. [09:51] I: copying [../rootstock_0.1.99.2-0ubuntu1_source.changes] [09:51] I: copying [../utils] [09:51] cp: cannot stat `../utils': No such file or directory [09:51] ??? [09:51] * ogra wonders about his pbuilder [09:56] sigh, upgrading pbuilder doesnt fix it [09:56] 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] dyfet: status on "Package and maintain Canola and deps in lucid archive: TODO" [10:41] ? [10:41] thats still on beta list [10:42] asac: I packaged most of the deps and we have a ppa for canola, just needs the final push [10:42] (and got them packaged/sync'd e.t.c, I didn't do all the package work) [10:43] asac: most dependencies are satisfied by the work done for netbook-launcher-efl [10:44] persia: mobile-lucid-arm-lib-tests ... two items i need input on there ;) [10:46] JamieBennett: yeah. is that pp amaintained by us? [10:46] or by oem or someone else [10:46] asac: OEM from what I remember [10:46] i think its fine to say that spec is done if its packaged and maintained by us [10:47] asac: Canola needs bringing into universe ideally [10:55] JamieBennett: 532548 [10:55] JamieBennett: do you have the url for canola? [10:56] asac: http://openbossa.indt.org/canola/ [10:56] JamieBennett: sorry. the ppa i mean [10:56] asac: not, handy, let me look [10:58] asac: https://edge.launchpad.net/~canola/+archive/ppa?field.series_filter=lucid [10:59] looks like there are more dependencies than I remember [11:01] JamieBennett: all those need to get in? [11:01] asac: No [11:02] asac: we need to assess exactly what is needed [11:02] bug 532549 [11:02] Launchpad bug 532549 in ubuntu "[FFe] ubuntu-webmail (affects: 1)" [Undecided,New] https://launchpad.net/bugs/532549 [11:02] (just for record) [11:02] JamieBennett: seems the uploads were done after efl launcher landing [11:02] so without looking it feels all the packages are on top there [11:12] bug 532554 [11:12] Launchpad bug 532554 in ubuntu "[FFe] canola for lucid/universe (affects: 1)" [Undecided,New] https://launchpad.net/bugs/532554 [11:12] JamieBennett: ^^ filed that [11:12] asac: OK [11:12] didnt subscribe release yet, we first need the packages needde [11:13] dyfet was going to do that, not sure how far he got with it [11:13] thats why i pinged him first ;) [11:14] asac: yes :) [11:17] 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] thats why I was hesitant [11:22] dyfet: you have a package? from the list there seems to be a bunch of packages required [11:22] can you come up with a minimal list? [11:23] asac: they are packages also used by the new 2d launcher :) [11:23] canola itself is python, but it used a lot of enlightenment toolkit stuff... [11:24] dyfet: what about the media scanner? [11:25] dyfet: : https://edge.launchpad.net/~canola/+archive/ppa?field.series_filter=lucid [11:25] thats the list of packages in the ppa ... that we dont have in our archive [11:25] please come up with a list of items that nees to get done quick ;) [11:26] then we can decide if we put it in archive or not [11:26] Okay [11:26] cool ... at best i would have that before todays release meeting ;) [11:26] like in 3h [11:27] Well, I have to go to the eye doctor this morning [11:28] so it will likely be a bit later this afternoon [11:29] asac: let me finish off this weboffice packaging and I'll take a look at canonla dependencies [11:30] *canola* :) [11:30] heroic ;) [11:30] Selecting previously deselected package indicator-session. [11:30] Unpacking indicator-session (from .../indicator-session_0.2.4-0ubuntu2_armel.deb) ... [11:30] ogra: ^^ thats where it hangs for me [11:30] it seems [11:31] well its consuming CPU cycles [11:31] but doesnt move forward [11:31] ogra: does the output i see on console directly come from the qemu command? or is that piped out somehow too? [11:37] NCommander: the girlfriend or the cat ;) [11:51] asac, there read directly from a fifo [11:51] 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] s/there/they are/ [11:52] its intresting though that it gets stuck on a different package for you [12:04] 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] right [12:05] --keepimage [12:05] no dash [12:05] that gives you a qemu image [12:05] use -l and -p for it [12:05] else you get dropped into oem-config first [12:05] s/first/on first boot/ [12:06] sudo rootstock -l -p --keepimage -f blah -s ubuntu-minimal^ -i 3G [12:06] that? [12:06] -l and -p need parameters [12:06] yeah [12:06] -l -p [12:06] ok its running [12:06] and you wouldnt need 3G here :) [12:06] minimal fits in less than 1 [12:07] but i want to go in there and install the reest [12:07] oh, indeed, you want to keep the image ... so 3G is fine [12:07] so i think i need more space [12:07] yep [12:07] didnt think about that [12:07] i'm just trying the qcow2 conversion stuff here ... [12:08] not having to specify the size will be a huge win [12:09] 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] i got 4G here [12:09] (using the pae kernel) [12:09] how much has your machine ? [12:12] 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] ogra: qemu-static-arm wants a kernel [12:22] err system-arm [12:22] one sec [12:22] if i just pass the .img [12:22] 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] http://ports.ubuntu.com/ubuntu-ports/dists/lucid/main/installer-armel/current/images/versatile/netboot/vmlinuz [12:22] use that kernel [12:23] err [12:23] ok [12:23] arm-rootfs.img needs to be your .img indeed [12:23] but dont you add that anyway? [12:23] e.g. why is that gone after --keepimage? [12:23] the kernel ? [12:24] well. you go to second stage and boot the vm, dont you? [12:24] because rootstock isnt designed as a VM imagebuilder :) its just a sideeffect that a VM is used [12:24] --keepimage is just skipping the tarball creation [12:26] 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] hmm, using qcow2 seems to make the VM act faster [12:27] at least "felt" [12:36] yay, qcow2 works fine [12:36] * ogra tries a bigger task than ubuntu-minimal [12:49] The following packages have unmet dependencies: [12:49] libgtk2.0-bin: Depends: libgtk2.0-0 (>= 2.19.6-1ubuntu4) but 2.19.6-1ubuntu3 is to be installed [12:49] GRRRRR !!!!!! [12:50] i really start hating arch: all packages [12:55] noted [12:55] heh [12:55] i think for ports we should have special casing ... [12:56] so _all.deb dont get published until all the arch dependent packages are ready [12:56] assuming that prots has special code in the publisher already since its a different server [12:57] asac: canola dependencies - http://pastebin.ubuntu.com/388929/ [12:57] persia: If people want a stable URL to get a versatile kernel, the d-i one is probably best [12:59] JamieBennett: all packages are in that ppa? [12:59] ogra: well. you want to wait for really slow sparc? [13:00] anyway, i know that some folks in debian would want the archive to act like that [13:00] asac, rather than having broken images all the time or not being able to test rootstock [13:00] you have a local mirrorß [13:00] when its ok, stop upgrading ;) [13:00] i will novw have to wait half the day until i can do my next testrun [13:01] i dont have a local mirror [13:01] * ogra considers local mirrors a massive waste of space ... i use package proxies [13:01] package proxy is kind of a mirror [13:02] right, "kind of" [13:02] it verifies its content with the archive first [13:02] and hands the breakage through [13:03] i could use the file:// protocol directly on the cache ... but rootstock cant support that since qemu wont see it [13:03] probably something to implement in rootstock 5.0 or so :) [13:07] asac: Yes, all packages are there. Tested it in a Lucid VM and all is good. [14:26] The following packages have unmet dependencies: [14:26] initramfs-tools: Depends: initramfs-tools-bin (= 0.92bubuntu67) but 0.92bubuntu66 is to be installed [14:26] * ogra cries [14:26] there goes ubuntu-minimal [14:26] :/ [14:56] i am off the phone calls for torday :( [14:57] to prepare for the IRC meeting eh [14:57] you must loive your fridays [14:57] three calls in a row ;) [14:58] now crazy stuff like release team wants to know something [14:58] yeah [15:21] * ogra commits and pushes the autosize function for rootstock [15:21] yay ... no more need for defining the imagesize [15:26] nice :) === kblin_ is now known as kblin [15:42] 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] I: Getting Virtual Machine kernel from the server [15:42] I: Switching to Virtual Machine for second stage processing [15:42] I assume the Virtual Machine (QEMU ARM, right?) shoudn't take 10+ hours... [15:42] no [15:42] whats your host system running ? [15:43] core i7, 8 processors if you count hyperthreading, lots of RAM and Ubuntu 9.10 [15:43] ah, karmic [15:43] known issues? [15:43] and you use the packaged rootstock i guess ? [15:43] I did this time. === bjf-afk is now known as bjf [15:43] previously I used the tarball from launchpad [15:44] karimc is missing http://bazaar.launchpad.net/~project-rootstock-developers/project-rootstock/trunk/revision/31 [15:44] latest tarball on launchpad has that? [15:45] yes, i uploaded it this morning [15:45] thanks, will try. [15:45] though its not tested on karmic yet, i test on lucid only atm [15:46]