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