[01:24] persia:Dove boards have PCIe slots :-) [01:27] users who have used ubiquity/oem-config before... anyway to force it to run on both tty0 and ttyS2 on first boot? === bjf is now known as bjf-afk [01:44] ping for ogra, this must be an oem-config bug.. on first boot after you create your first user, oem-config exits, then restarts oem-config again from scratch... force a reboot, then on the next boot oem-config starts again... however user does exist if you switch to tty2... [03:11] Is it possible to buy an ARM laptop today and easily install the latest Ubuntu Linux on it? === DavidBz is now known as berco [10:31] woah, mounting /proc in a qemu-arm-static chroot and then installing mono explodes in a funny way [10:56] ogra: So how does it fail? [10:56] ogra: Could you file a bug about that? [10:57] lool, well, it tries to enable binfmt :) [10:57] i doubt there is any easy way around [10:57] apart from having a fake proc, afaik persia and lifeless had some fuse based ideas for that during the sprint [10:57] It didn't fail for me [10:58] update-binfmts: warning: /usr/share/binfmts/cli: no executable /usr/bin/cli [10:58] found, but continuing anyway as you request [10:58] update-binfmts: warning: found manually created entry for python2.6 in [10:58] /proc/sys/fs/binfmt_misc; leaving it alone [10:58] (apt-get install mono-runtime) [10:58] right and then it tries to use the existing cli handler during package install [10:58] ah [10:58] i did apt-get install tomboy [11:00] lool, did you ever have contact with hppfs ? [11:00] seems that could work as a fake proc in a chroot [11:00] No [11:01] I'm not sure I'm in line with the fake proc idea [11:01] I think qemu-arm would have to emulate some of it due to the emulation it does [11:01] well, how else would you handle stuff that needs proc in a foreign chroot [11:01] right, so you still need to fake something [11:02] I'd personally prefer to use containers if we want to support this [11:02] thats a lot of overhead [11:02] No [11:02] It's almost zero overhead [11:02] well, we only need proc containers do so much more [11:03] and are quite complicated to set up for a user [11:08] lool, http://paste.ubuntu.com/384298/ [11:09] so ita a SIGABRT and i guess because it sees the binfmt handler and tries to exec it [11:09] ogra: Could you file a bug? [11:10] gar, apport doesnt know about qemu-arm-static [11:13] The unsupported syscall 242 ones are probably harmless (affinity stuff) [11:14] The unuspported syscall 26 is just a consequence of trying to run gdb under qemu-arm, wont work because ptrace() isn't emulated (and far from trivial I'm afraid) [11:15] yep [11:15] bug 528377 [11:15] Launchpad bug 528377 in qemu-kvm (Ubuntu) "qemu-arm-static fails installing mono assemblies if /proc is mounted in the chroot (affects: 1)" [Undecided,New] https://launchpad.net/bugs/528377 [11:17] i actually only started experimenting with mono in chroot again out of desparation, i have no idea what to do with the iso-codes hang [11:18] seems no matter what kernel or config i use, installing the ubuntu-netbook task hangs reliably at iso-codes unpacking [11:19] i thought its caused by swapping but that was a red herring [11:42] ogra: So the way you word the bug report, it sounds like of /proc is NOT mounted in the chroot, one can actually install mono; is this correct? [11:42] no [11:42] but i dont get the segfaults [11:42] What do you get? [11:42] it simply doesnt execute the installation of the assmeblies [11:42] and dpkg fails [11:43] i'll add a log for comparison once my machine has spare cpu cycles (rootstock running atm) [11:58] hi doko ;9 [11:59] oh, a rare guest :) [11:59] hehe [12:03] I was forced :-/ [12:05] NCommander: you might want to look at Mikael's comments in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40860 (tracked down to the very same binutils change) [12:05] gcc.gnu.org bug 40860 in libgcj "[4.4/4.5 regression] regressions in libjava testsuite on arm-linux" [Normal,Unconfirmed] [12:46] hey ogra, oem-config question... Should it run in an endless loop in lucid? ;) [12:47] no, it shouldnt, boot with debug-oem-config on the cmdline and file a bug with /var/log/oem-config.log attached please [12:47] against ubioquity [12:49] Thank so, debug-oem-config's the trick... First thing i'll do when i get to work.. [12:50] thanks :) [12:50] anyluck with the weird iso-codecs lockup today? ;) i'm seeing it to on my machines... Whats weird In debian it's actually locking up at I: Extracting zlib1g... [12:52] with debians qemu ? [12:52] squeeze.. so (ssh's in) [12:52] i'm trying to debug that since yesterday but given the time it takes to get to the hang its might still take more :) [12:53] i'm just trying it in a normal VM so that i can exclude rootstock here [12:54] rcn-ee, btw, if you file a bug for oem-config under rootstock, please subscribe ubuntu-armel [12:54] so we get the mails in the arm team [12:54] i know what you mean.. (QEMU PC emulator version 0.11.1)... what's weird, when i was building 'google os' images in a chroot, it locked up on that same package file.. [12:55] i think its something in qemu not handling a certain amount of CPU load or disk I/O [12:55] but its so damned hard to track down [12:56] isn't that "I: Extracting zlib1g..." [12:56] oh damn keyboard [12:56] funnily i can just install iso-codes just fine if i install it standalone [12:57] ynezz, thats not in the VM [12:57] seems very reasonable.. do you guys have a dedicated qemu hacker at ubuntu? [12:57] rcn-ee, well, lool is very passionate to get all qemu bugs solved and has the knowledge ... [12:58] he's not a "dedicated qemu hacker" per se i think though :) [12:59] yeah he's good.... anything show up weird in the vm machine log's file? (i could dump it too..) [13:00] i'm only just running it in a VM [13:00] before i suspected rootstock to be at fault ... thats to closed [13:00] hmm, fun [13:01] my VM doesnt even boot [13:01] whoops typoing the command doesnt really help :P [13:03] /tmp/ccQPoJy6.s:1847: Error: selected processor does not support `rsc r7,r7,#0' [13:03] hmm [13:04] whats that ? [13:04] reverse substract with carry [13:04] right [13:04] is that thumb only instruction? [13:04] or too old [13:04] only available on ARM, not Thumb [13:05] in the arm reference i have open its named in the thumb section [13:05] yeah thats what i expected [13:06] asac: there's a regular substract though [13:07] asac: sbc r7,#0,r7? [13:07] Hmm don't think you can pass an immediate as first arg though [13:08] what i find odd is that its not even marked as arm only in the reference quick card ... strange [13:09] asac: I certainly see it marked as such [13:10] asac: RSC is 5th in the substract instructions, and the fifth entry in Notes is "A" [13:10] So not in Thumb [13:12] oh right. i misinterpretetd the table [13:13] there's a blank which is hard to read [13:21] ogra: lool: Did you want the breakdown of the fuse proc idea? I think StevenK fiddled with some initial implenetation stuff. [13:23] persia, i would, seems lool doesnt ... he wants containers [13:23] containers are a more correct solution. [13:23] but way more complex [13:24] no [13:24] and do they guarantee i dont see the system kernel in /proc ? [13:24] no [13:24] right [13:25] The fuse hack was just to use fuse.pm to check the filename and if it matched one of a set of predefined files, perform some operation (either cat a fake file, or run the real file through a filter). If it doesn't match, feel the original file (or feed through an identity filter, depending on operation) [13:25] what we need is a /proc that emulates a generic arm machine [13:26] hrm, now i cant even purge iso-codes from my VM [13:27] just sits there in the ldconfig triggers [13:28] ogra: The fuse hack can give us that (at least enough to fake most stuff). [13:29] Just needs someone to write up the perl. [13:29] yeah [13:29] persia: I find it hard to imagine that we will get cpuinfo emulation in containers in the short term [13:29] Your python is better than your perl, right? How are you at python regexes? [13:29] persia: However I do believe we should use containers for things like binfmt [13:30] persia, i come from perl ... just needs a little refresh i guess [13:30] lool: So you think it makes sense to combine a container and the fuse-proc hack? [13:30] persia: The cpuinfo hack could either be done with fuse or in qemu; I think I find it more useful in qemu though [13:30] ogra: StevenK suggested perl was the better language for it because it's mostly just matching regexes and then running text filters. [13:30] I find things are complex and fragile enough that I'd prefer not to have to fiddle with fuse, personally [13:30] yeah [13:31] lool, to run containers you need to do massive changes to yxour chroot (which is the part i find complex) [13:31] lool: The advantage of fuse over qemu is that it's trivial to write such a hack in perl, but fixing qemu requires real thought. If you're up for doing it, it would be loads better. [13:32] ogra: No [13:32] huh ? [13:33] you need at least to create lots of stuff in /dev, need to hack mountall defaults etc [13:34] ogra: Shouldn't it be as simple as http://blog.bodhizazen.net/linux/lxc-configure-debian-lenny-containers/ ? [13:34] no [13:35] lenny is way easier :) [13:35] no upstart ... etc [13:35] he wrote one for lucid too [13:35] http://blog.bodhizazen.net/linux/lxc-configure-ubuntu-lucid-containers/ [13:35] but effectively /proc will stil show you the host CPU and features [13:36] Why doesn't udev work? [13:36] so its pointless to use containers imho [13:36] Again, containers are not going to solve the cpuinfo problem [13:36] Containers solve other issues. [13:36] They don't solve /proc [13:36] They actually help a lot with /proc, but not for cpuinfo [13:36] (well, they solve other /proc issues, but mostly of type /proc/nnnn) [13:36] Right. [13:37] Well, also not proc/[a-z]* mostly. [13:37] would they be able to solve binfmt ? [13:37] (i doubt that) [13:38] given that binfmt would still need a qemu-arm-static wrapper around the interpreter calls [13:39] * ogra goes for some lunch [14:15] urgh [14:16] maximizin the qemu window while it does something and then restoring it to its original size reults in massively blurry fonts [14:18] the funny think is that its only blurry in the center of the window ... top and bottom are crisp [14:24] I have a couple of patch suggestions for rootstock, where should I submit them? On launchpad? [14:24] mikeul: Ideally, submit them as merge proposals [14:24] via launchpad [14:24] yes [14:24] mikeul: bzr branch lp:project-rootstock my-feature; cd my-feature && hack && bzr commit; bzr send [14:25] they're trivial, but it'll be a good getting-to-know-launchpad exercise. [14:25] bzr send? I did bzr push" [14:27] mikeul: Checkout "bzr help send" then ;-) bzr push is when you want to do things manually [14:29] lool, send requires an email setup, no ? [14:29] * ogra checks the help [14:30] ah, not a local mailserver, just a client [14:31] why? who gets an e-mail? [14:31] mikeul: the email contact of the lp project [14:31] mikeul: if you prefer, you can just submit your branch for merging via the web ui [14:31] right [14:32] OK, so having pushed it to a personal branch, can I do that with "Propose for merging"? [14:32] yep [14:33] Or should I push it to the project-rootstock page instead and propose-for-merge there? [14:34] mikeul: I usually push to some personal lp page (e.g. lp:~mikeul/project-rootstock/make-everything-better ) and then do the merge proposal on LP. [14:40] mikeul, hmm, why do you add rmdir $BUILDDIR to the usage() function ? [14:41] $BUILDDIR wont exist if usage() is executed [14:45] mikeul, i think that requires more restructuring, i'm not really comfortable with creating $BUILDDIR just because non root users call --help, could you move the variables around a bit instead of adding the rmdir ? [14:46] its a good approach though [14:54] $BUILDDIR _did_ exist when usage() is executed. I called "sudo rootstock --help" a few times and ended up with several empty /tmp/tmp.xxxxxx dirs. [14:54] right, thats the actual bug :) [14:54] I'd be happy to move some things around to fix it differently. [14:55] e.g. to avoid creating /tmp/tmp.xxxxxx in the first place. [14:55] yes, BUILDDIR= and all variables that use ${BUILDDIR} need to move down a bit ... best is below the uid 0 check [14:56] (the script started as 50 lines ... and grew functions in several directions) [14:56] ogra, I'm familiar with that. [14:57] :) [15:00] OK, then move all the variable defs to after the cmdline parsing. I'll move the qemu-system-arm and debootstrap checks, too, since they're also not needed e.g. for --help [15:02] be careful though, some need to be initialized before the cmdline parsing [15:02] best to only move everything with $BUILDDIR in it [15:02] Oh yeah, that's why I went the quick-and-dirty rmdir route. [15:04] OK, can you give me an overview of how to handle that with bazaar? I can start from scratch and just post a new branch, but I'm guessing there's a different way. [15:05] just delete the rmedir with your next change ... the moving of the uid 0 check is fine [15:05] *rmdir [15:06] ah, OK, so just dump more commits on top of my existing ones? [15:06] right "revert last change and .... " [15:08] fyi, I'm a git'ter. Do you mean a) I can change the history in bzr to remove mention of 'rmdir' or b) I should make the changes "on top of" the existing ones. [15:09] i would just do it on top [15:09] OK [15:09] easy peezy [15:10] whois mikeul [15:10] oops [15:11] :) [15:27] FYI, I'm not going to get around to doing even those small changes today, will get to it soon. Signing out. [15:29] lool, so i am testing the same iso-codes issue in a real VM now instead of using rootstock, i'm at the point where apt stops moving in "unpacking iso-codes" ... i see nothing in the logs, apt-get and dpkg dont seem to consume to much CPU, one intresting thing i see is that dpkg.log seems to be behind and getting slowly filled ... dou you have any idea where else to look at ? [15:29] mikeul, dont worry :) [15:29] mikeul, thanks for doing the work :) [15:30] Kein Problem, ogra, have a nice weekend. [15:30] du auch :) [15:31] grmbl ... i should have installed iotop first [15:37] ogra: build karmic image today, using rootstock r82 and it boots :) [15:38] cool ! [15:41] sigh ... no strace either in ubuntu-minimal [15:42] ogra: Are you swapping? [15:42] ynezz: We figured out the mountall issues with mikeul BTW [15:42] i created a swapfile on the virtual disk after it hung already for 20min [15:42] ynezz: Missing rw on the kernel cmdline [15:43] ogra: can't login tho, maybe it's related to useradd http://paste.ubuntu.com/384439/ [15:43] yeah, looks like a bug [15:43] lool: yep, saw it in bzr log, thanks [15:44] i switched the default to install oem-config instead ... i havent tested with username/pw for a while ... its on my list [15:44] ynezz, i fear you need to mount your image and chroot into it to create the user [15:44] did it already, no problem [15:45] ah, k [15:45] just letting you know [15:45] yeah, thanks [15:45] seems the options are wrong, i'll look into it on the weekend [15:45] lool, so swapon after it was already stuck didnt help ... [15:46] even though i see 204 bytes of the swap being used now after 1h [15:46] err, 240 [15:46] apt-get now jumps between 80 and 95% CPU [15:47] but nothing happens beyond that === bjf-afk is now known as bjf [15:53] ogra: it's missing " around one param http://paste.ubuntu.com/384443/ [15:53] oh, right, it used to live directly in the installer script ... when i moved it i didnt add proper quoting [15:53] ynezz, thanks ! [15:54] np, that was easy :p [15:54] (in fact i didnt really care about it because oem-config should become the default) [15:54] but i'll add your fix with the next commit [16:14] bug 507503 [16:15] 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 committed] https://launchpad.net/bugs/507503 [16:16] ramana: morning (or afternoon) [16:18] bug 528524 [16:18] Launchpad bug 528524 in pulseaudio (Ubuntu Lucid) (and 1 other project) "Sound not working in all apps on dove (affects: 1)" [High,New] https://launchpad.net/bugs/528524 [19:24] I got this problem with ubuntu karmic http://paste.ubuntu.com/384586/ . I fixed it at Mamona with this patch (http://gitorious.org/mamona/openembedded/commit/4d4933fd97b85a52e48a5fa1a97bd34532864e32). Anyone with this problem? [20:39] ARGH($*)(@*#$)(*@!$#@$ [20:39] * NCommander hates OOo [21:18] alecrim_: Could you file a bug with your patch? [21:18] alecrim_: I'm pretty sure I saw this in the past, I think it was on the sheevaplugs [21:21] alecrim_: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=314334 [21:21] Debian bug 314334 in apt "apt: APT doesn't work on filesystems without shared writable mmap(), like JFFS2." [Wishlist,Open] [21:43] lool, ok! [22:05] <|nfecteD> rcn-ee: you around? [22:20] ramana: ping? [22:21] <|nfecteD> anyone want to give me whatever boot.scr they are using for lucid alpha 3? [22:25] |nfecteD: what are you trying to do? [22:25] * NCommander is the boot.scr writer guy [22:25] <|nfecteD> getting it to boot :/ [22:25] |nfecteD: which SoC? [22:26] <|nfecteD> beagleboard [22:26] <|nfecteD> init: plymouth-log main process (227) terminated with status 111 [22:26] |nfecteD: Beagleboard isn't officially supported by Ubuntu [22:27] <|nfecteD> thats the last thing i get during boot before it seems to hang [22:27] |nfecteD: http://elinux.org/BeagleBoardUbuntu - but here's the best set of directions I can give [22:27] oh wow [22:27] * NCommander feels honored [22:27] Beagle adopted my boot.scr mechanism [22:27] or something similar [22:28] |nfecteD: sounds like your making it to the initramfs and then its crashing. [22:28] <|nfecteD> yup [22:28] <|nfecteD> seems so... [22:28] I'd recommend trying #beagle and if no response, come back here [22:29] <|nfecteD> plymouth needs kms/framebuffer and initramfs i believe... [22:29] <|nfecteD> early patch, i'm messing with: [22:29] <|nfecteD> http://bazaar.launchpad.net/~robertcnelson/project-rootstock/initramf... [22:29] <|nfecteD> and boot.scr needs to be updated (simple) to also load the initramfs [22:29] <|nfecteD> into ram.. [22:29] <|nfecteD> found that on the beagleboard group now [22:31] <|nfecteD> i would think rcn built the newest rootfs with that patch so what im missing is what goes in the boot.scr [22:31] * |nfecteD pokes rcn-ee