NCommander | persia:Dove boards have PCIe slots :-) | 01:24 |
---|---|---|
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:27 |
=== bjf is now known as bjf-afk | ||
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... | 01:44 |
bobrown | Is it possible to buy an ARM laptop today and easily install the latest Ubuntu Linux on it? | 03:11 |
=== DavidBz is now known as berco | ||
ogra | woah, mounting /proc in a qemu-arm-static chroot and then installing mono explodes in a funny way | 10:31 |
lool | ogra: So how does it fail? | 10:56 |
lool | ogra: Could you file a bug about that? | 10:56 |
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:57 |
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 | 10:58 |
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:00 |
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:01 |
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:02 |
ogra | and are quite complicated to set up for a user | 11:03 |
ogra | lool, http://paste.ubuntu.com/384298/ | 11:08 |
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:09 |
ogra | gar, apport doesnt know about qemu-arm-static | 11:10 |
lool | The unsupported syscall 242 ones are probably harmless (affinity stuff) | 11:13 |
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:14 |
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:15 |
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:17 |
ogra | seems no matter what kernel or config i use, installing the ubuntu-netbook task hangs reliably at iso-codes unpacking | 11:18 |
ogra | i thought its caused by swapping but that was a red herring | 11:19 |
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:42 |
ogra | i'll add a log for comparison once my machine has spare cpu cycles (rootstock running atm) | 11:43 |
asac | hi doko ;9 | 11:58 |
ogra | oh, a rare guest :) | 11:59 |
asac | hehe | 11:59 |
doko | I was forced :-/ | 12:03 |
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:05 |
rcn-ee | hey ogra, oem-config question... Should it run in an endless loop in lucid? ;) | 12:46 |
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:47 |
rcn-ee | Thank so, debug-oem-config's the trick... First thing i'll do when i get to work.. | 12:49 |
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:50 |
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:52 |
ogra | i'm just trying it in a normal VM so that i can exclude rootstock here | 12:53 |
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:54 |
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:55 |
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:56 |
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:57 |
ogra | he's not a "dedicated qemu hacker" per se i think though :) | 12:58 |
rcn-ee | yeah he's good.... anything show up weird in the vm machine log's file? (i could dump it too..) | 12:59 |
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:00 |
ogra | my VM doesnt even boot | 13:01 |
ogra | whoops typoing the command doesnt really help :P | 13:01 |
asac | /tmp/ccQPoJy6.s:1847: Error: selected processor does not support `rsc r7,r7,#0' | 13:03 |
asac | hmm | 13:03 |
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:04 |
asac | in the arm reference i have open its named in the thumb section | 13:05 |
asac | yeah thats what i expected | 13:05 |
lool | asac: there's a regular substract though | 13:06 |
lool | asac: sbc r7,#0,r7? | 13:07 |
lool | Hmm don't think you can pass an immediate as first arg though | 13:07 |
asac | what i find odd is that its not even marked as arm only in the reference quick card ... strange | 13:08 |
lool | asac: I certainly see it marked as such | 13:09 |
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:10 |
asac | oh right. i misinterpretetd the table | 13:12 |
lool | there's a blank which is hard to read | 13:13 |
persia | ogra: lool: Did you want the breakdown of the fuse proc idea? I think StevenK fiddled with some initial implenetation stuff. | 13:21 |
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:23 |
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:24 |
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:25 |
ogra | hrm, now i cant even purge iso-codes from my VM | 13:26 |
ogra | just sits there in the ldconfig triggers | 13:27 |
persia | ogra: The fuse hack can give us that (at least enough to fake most stuff). | 13:28 |
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:29 |
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:30 |
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:31 |
lool | ogra: No | 13:32 |
ogra | huh ? | 13:32 |
ogra | you need at least to create lots of stuff in /dev, need to hack mountall defaults etc | 13:33 |
persia | ogra: Shouldn't it be as simple as http://blog.bodhizazen.net/linux/lxc-configure-debian-lenny-containers/ ? | 13:34 |
ogra | no | 13:34 |
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:35 |
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:36 |
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:37 |
ogra | given that binfmt would still need a qemu-arm-static wrapper around the interpreter calls | 13:38 |
* ogra goes for some lunch | 13:39 | |
ogra | urgh | 14:15 |
ogra | maximizin the qemu window while it does something and then restoring it to its original size reults in massively blurry fonts | 14:16 |
ogra | the funny think is that its only blurry in the center of the window ... top and bottom are crisp | 14:18 |
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:24 |
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:25 |
lool | mikeul: Checkout "bzr help send" then ;-) bzr push is when you want to do things manually | 14:27 |
ogra | lool, send requires an email setup, no ? | 14:29 |
* ogra checks the help | 14:29 | |
ogra | ah, not a local mailserver, just a client | 14:30 |
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:31 |
mikeul | OK, so having pushed it to a personal branch, can I do that with "Propose for merging"? | 14:32 |
ogra | yep | 14:32 |
mikeul | Or should I push it to the project-rootstock page instead and propose-for-merge there? | 14:33 |
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:34 |
ogra | mikeul, hmm, why do you add rmdir $BUILDDIR to the usage() function ? | 14:40 |
ogra | $BUILDDIR wont exist if usage() is executed | 14:41 |
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:45 |
ogra | its a good approach though | 14:46 |
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:54 |
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:55 |
ogra | (the script started as 50 lines ... and grew functions in several directions) | 14:56 |
mikeul | ogra, I'm familiar with that. | 14:56 |
ogra | :) | 14:57 |
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:00 |
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:02 |
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:04 |
ogra | just delete the rmedir with your next change ... the moving of the uid 0 check is fine | 15:05 |
ogra | *rmdir | 15:05 |
mikeul | ah, OK, so just dump more commits on top of my existing ones? | 15:06 |
ogra | right "revert last change and .... " | 15:06 |
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:08 |
ogra | i would just do it on top | 15:09 |
mikeul | OK | 15:09 |
mikeul | easy peezy | 15:09 |
ynezz | whois mikeul | 15:10 |
ynezz | oops | 15:10 |
ynezz | :) | 15:11 |
mikeul | FYI, I'm not going to get around to doing even those small changes today, will get to it soon. Signing out. | 15:27 |
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:29 |
mikeul | Kein Problem, ogra, have a nice weekend. | 15:30 |
ogra | du auch :) | 15:30 |
ogra | grmbl ... i should have installed iotop first | 15:31 |
ynezz | ogra: build karmic image today, using rootstock r82 and it boots :) | 15:37 |
ogra | cool ! | 15:38 |
ogra | sigh ... no strace either in ubuntu-minimal | 15:41 |
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:42 |
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:43 |
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:44 |
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:45 |
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:46 |
ogra | but nothing happens beyond that | 15:47 |
=== bjf-afk is now known as bjf | ||
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:53 |
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 | 15:54 |
asac | bug 507503 | 16:14 |
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:15 |
NCommander | ramana: morning (or afternoon) | 16:16 |
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 | 16:18 |
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? | 19:24 |
NCommander | ARGH($*)(@*#$)(*@!$#@$ | 20:39 |
* NCommander hates OOo | 20:39 | |
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:18 |
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:21 |
alecrim_ | lool, ok! | 21:43 |
|nfecteD | rcn-ee: you around? | 22:05 |
NCommander | ramana: ping? | 22:20 |
|nfecteD | anyone want to give me whatever boot.scr they are using for lucid alpha 3? | 22:21 |
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:25 |
|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:26 |
|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:27 |
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:28 |
|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:29 |
|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 | 22:31 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!