| * Tscheesy_ should take a buils-system larger then the atom next time - build is 6h and going on.. | 00:56 | |
| Tscheesy_ | ogra: no success - and not a big log: http://pastebin.ca/1338573 | 03:01 |
|---|---|---|
| ogra | Tscheesy, well, i didnt mean the shell output when i said please keep the log ;) have you kept the actual logfile thats mentioned in the output ? | 10:46 |
| Tscheesy | ogra: yes - but in the pastebin is also the last bit of the shell | 11:44 |
| Tscheesy | the logfile only contained : I killed | 11:45 |
| ogra | no, it should have the actual output from apt-get above | 11:45 |
| Tscheesy | i guess it's the jaunty-state is braking the b uild | 11:46 |
| Tscheesy | ogra: i always got this tiny logfile | 11:46 |
| ogra | well, the actual error is between line 2 and line 6 in your paste ... | 11:48 |
| ogra | way above before the stuff you captured | 11:48 |
| Tscheesy | hmm.. really the loggs are all 15byte big.. booting up the build-sys.. | 11:49 |
| Tscheesy | line 22-31.. aren't these the packages which are breaking the build? | 11:50 |
| ogra | yes, thats apt telling you about the packages it couldnt install ... but the info why they couldnt be installed is at the actual package install moment way above in the log | 11:51 |
| Tscheesy | ah now i get you.. way above in the shell output.. | 11:51 |
| ogra | what you showed me is only apt's summary | 11:51 |
| ogra | thats why i want the full log :) | 11:52 |
| ogra | the logfile should actually have everything before apt dies | 11:52 |
| Tscheesy | k.. needs's to output the std_out in a file? | 11:52 |
| ogra | the output should be in /home/tscheesy/openmoko/kubuntu/build-arm-rootfs-200902151752.log | 11:53 |
| Tscheesy | nope - only this line i mentioned - line 2 | 11:53 |
| ogra | hrm | 11:53 |
| ogra | thats a bug in the script then, weird, it should log in parallel | 11:54 |
| ogra | and it does that fine here | 11:54 |
| Tscheesy | do i need tto be root? or only sudo skript is enough? | 11:55 |
| ogra | sudo is fine | 11:56 |
| ogra | hmm, i dont see any issue with the script | 11:56 |
| ogra | did you modify it in any way ? | 11:57 |
| Tscheesy | no - only options when calling it | 11:57 |
| ogra | what was your commandline (without the password indeed) | 11:58 |
| Tscheesy | mom.. | 11:58 |
| Tscheesy | this was without specifiing a mirror..sudo ./build-arm-rootfs --fqdn ubuntu --login kubuntu --password kubuntu --imagesize 3G --seed kubuntu-desktop | 11:59 |
| * ogra does a testrun | 12:00 | |
| ogra | hmm, logging works fine here | 12:01 |
| Tscheesy | hmm.. has my atom as abuild-sys any influence? - gona test the new atom-Live anyway.. | 12:02 |
| ogra | ah | 12:03 |
| ogra | delete line 207 in the script | 12:03 |
| Tscheesy | yes? | 12:03 |
| ogra | it saves the log twice it seems if it dies with an error | 12:03 |
| ogra | so it overwrites the existing log with a second one | 12:04 |
| ogra | then you will get a proper log next run | 12:04 |
| Tscheesy | ok.. making a new run - after setting up the sstem for a long uptime ;) but i thing kubuntu-jaunty is too instable | 12:05 |
| ogra | fixed script uploaded | 12:05 |
| === ogra is now known as waldorf | ||
| === waldorf is now known as ogra | ||
| Tscheesy_ | ogra: if your interestet.. here's my recent log http://pastebin.ca/1339413 - had a quick look - dependencys.. | 22:36 |
| ogra | oh, it shouldnt log the panic :) | 22:36 |
| ogra | hrm, it cant start hal it seems | 22:40 |
| Tscheesy_ | z5834 yes | 22:42 |
| ogra | right, i'll do some testing tomorrow ... i will only be around very late tomorrow though | 22:43 |
| ogra | the rest of the errors are just subsequent fallout | 22:43 |
| Tscheesy_ | easy - i'll be interestet for hints | 22:43 |
| Tscheesy_ | thanks anyway - g'n8 | 22:46 |
| rwhitby | morning | 22:58 |
| * rwhitby leads the nslu2-linux.org project | 22:59 | |
| ogra | hey rwhitby | 22:59 |
| rwhitby | lool: got your email - ping me when you come online and we can talk about the nslu2-linux.org project sponsoring NSLU2 hardware for the ubuntu-arm effort. | 22:59 |
| rwhitby | ogra: g'day | 22:59 |
| rwhitby | I must admit I was unaware of the ubuntu-arm effort until the other day - how long has it been underway and where can I see the status? | 23:00 |
| ogra | d-i is nearly fully functional ;) still have to solve some preseeding differences between ubuntu and debian | 23:00 |
| ogra | well, we dont have an actual status tracking page, main objective for 9.04 was to get all of the main archive building and have at least a qemu (versatile) and one image that runs on real HW | 23:01 |
| rwhitby | ogra: if there are any outstanding questions about apex, flash layout, etc, feel free to ping me here. I'll add this channel to my bouncer list. Does anyone object if I drop a logger in the channel (http://logs.nslu2-linux.org/livelogs/) ? | 23:01 |
| ogra | (which currently is the nslu2 ) | 23:01 |
| ogra | i doubt anyone will object | 23:02 |
| persia | rwhitby, The channel is currently logged to irclogs.ubuntu.com. | 23:02 |
| ogra | which doesnt mean we mind a second logbot indeed :) | 23:02 |
| * persia isn't objecting, but pointing out possible duplication of resources | 23:02 | |
| ogra | best resource to see the status is probably http://qa.ubuntuwire.com/ftbfs/ | 23:03 |
| rwhitby | ogra: who in the project can best use NSLU2 hardware? | 23:07 |
| ogra | well, i have one, lool is surely the best to decide who else should get one | 23:07 |
| ogra | we currently have two devices in the team | 23:08 |
| rwhitby | how many core developers are on the team? | 23:09 |
| persia | Hard to answer that one: some people chase down build failures for non-ARM reasons, and most of the people chasing ARM are also chasing other things. | 23:10 |
| ogra | well, the canonical team cosists of five members, i cant tell much about the community, people come and go here ... there are also other teams where it proably makes sense to have the HW for test though | 23:10 |
| ogra | *tests | 23:10 |
| rwhitby | ogra: who is on the canonical team? | 23:11 |
| ogra | persia, StevenK, NCommander, lool and me atm but as i said it extends beyond these people there are many others that actively work on the arm port but only in a specific area | 23:13 |
| ogra | i also think the actual canonical team might be well enough equipped, we have access to quite powerful arm HW in the datacenter and to the builder machines, i guess getting HW to the community is more intresting, but on the other hand its hard to name specific people ... ubuntu on arm is still very young | 23:15 |
| rwhitby | ogra: the goal of the nslu2-linux.org project is to get the nslu2 supported by major embedded distributions. We'd achieved that for OpenEmbedded, Debian, OpenWrt, and now it seems Ubuntu should be the next on the list. | 23:16 |
| ogra | well, we're nearly there ... i'd say i'll have a fully working d-i by end of the week | 23:17 |
| ogra | the next build will work fine but needs a serial console since there are some remaining d-i questions before it kicks off the ssh server | 23:18 |
| ogra | everything beyond d-i is just general packages :) | 23:18 |
| ogra | which should generally work | 23:19 |
| rwhitby | nod | 23:19 |
| ogra | .. already ... | 23:19 |
| rwhitby | how is Ubuntu handling recovery on a headless device like the nslu2? | 23:20 |
| rwhitby | (e.g. when your disk needs an fsck on boot, and you have no serial port to type Ctrl-D on ...) | 23:20 |
| ogra | we have all the debian tools packaged so currently the same way as debian, all docs should apply | 23:20 |
| rwhitby | debian currently doesn't handle it at all | 23:20 |
| ogra | oh, right | 23:20 |
| ogra | well, thats something we can surely attack :) | 23:21 |
| rwhitby | if your disk has a problem, you can't boot the machine to any level of functionality to debug it | 23:21 |
| rwhitby | All other embedded distros for the nslu2 except Debian have a recovery rootfs in flash so you can ssh into that to debug rootfs on disk problems | 23:21 |
| ogra | we have a hacked sulogin already, making that work wiht something like sshd in a special maintnance system from flash might be possible | 23:22 |
| rwhitby | there is some work going on in debian to have the initrd running openssh or dropbear for recovery purposes. | 23:23 |
| ogra | so make a failed fsck reboot immediately and change the cmdline to have something like a "recover" keyword or some such | 23:23 |
| rwhitby | but it's not in Lenny as far as I know | 23:23 |
| ogra | ah, yeah, tahts easy to achieve | 23:24 |
| ogra | though it grows your initramfs to a certain size ... | 23:24 |
| rwhitby | the key thing is that there is 8MB of flash on an nslu2, and after d-i finishes it's work it should install an initrd in there that can do recovery actions on an attached disk | 23:24 |
| ogra | prob is ... we're having feature freeze by thursday | 23:24 |
| rwhitby | ah, ok. | 23:24 |
| rwhitby | next release then. | 23:25 |
| ogra | so i fear 9.04 might only have basic install support | 23:25 |
| rwhitby | BTW, Debian also have an outstanding inefficiency in the way they handle swapping of kernel and initrd. | 23:25 |
| ogra | but we have personal package archives on launchpad ... these can provide extra functionallity so such a feature can be developed out of the release cycle | 23:25 |
| rwhitby | they chose the wrong way to start, and now they have to swap twice instead of just letting Apex do the work for them. | 23:25 |
| rwhitby | if you change a single setting in Apex, you no longer need to swap anything when you flash - you can use the built kernel as-is and flash it directly without needing to byteswap it | 23:26 |
| ogra | right | 23:26 |
| rwhitby | trouble is that they had an installed base and couldn't change it. | 23:27 |
| ogra | the prob here is that we sync our packages from debian | 23:27 |
| rwhitby | this only affects the kernel and initrd flashing - doesn't affect userspace packages at all | 23:27 |
| rwhitby | (i.e. it's still armel) | 23:27 |
| ogra | if we would work i.e. with an unswapped kernel, flash-kernel needs changes etc | 23:27 |
| ogra | same goes for d-i | 23:27 |
| ogra | and we'd need to build the kernel with different endianess | 23:28 |
| rwhitby | right - ok, if you want to remain compatible with Debian at that level then you will also need to keep the inefficiency. It's not a big deal - you just get questions from people who try and write the kernel without swapping it and it fails. | 23:28 |
| ogra | surely something to address ... but a bit to much for 9.04 i think | 23:28 |
| rwhitby | kernel has same endianness - it's just swapped on load by Apex rather than being pre-swapped in flash. | 23:28 |
| ogra | no, i'm all for adressing any inefficiency :) | 23:29 |
| rwhitby | inefficiency is probably the wrong word - it's more just clarity and complexity. | 23:29 |
| ogra | but introducing new deltas means extra work which is rather something for 9.10 | 23:29 |
| rwhitby | if you have units in the field with 9.04 as-is, then it's just too hard to swap the scheme later. | 23:30 |
| rwhitby | and it's not a real problem anyway, so best just to leave as-is. | 23:30 |
| ogra | ok | 23:30 |
| rwhitby | it's transparent to users as long as they use the correct script for flashing | 23:31 |
| rwhitby | (which they have to do anyway due to the 16 byte header and hard-coded ramdisk offset header) | 23:31 |
| ogra | well, its ubuntu ... | 23:31 |
| ogra | you rarely use any scripts manually, we normally try to integrate with the packages | 23:31 |
| ogra | or the tools | 23:32 |
| rwhitby | right - postinst on kernel package | 23:32 |
| ogra | i.e. if you upgrade a kernel you wont have to do any manual steps, you just call update manager | 23:32 |
| ogra | well, a bit more than that | 23:32 |
| ogra | but also the kenrel package postinst | 23:32 |
| rwhitby | for those reasons, it's all transparent to users. | 23:32 |
| ogra | righ | 23:32 |
| ogra | t | 23:32 |
| rwhitby | so I guess we just need to work out an apex config which gives you the flexibility you need for kernel and initramfs sizes, and is upwardly compatible for Debian if they reflash apex on an existing device. | 23:33 |
| rwhitby | shouldn't be hard to do if it's just vma address changes | 23:34 |
| rwhitby | (and not flash layout changes) | 23:34 |
| rwhitby | btw, I maintain the upstream slugimage script, which packs the 8MB image from parts | 23:34 |
| ogra | yeah, i had to change the apex VMA default address to 4MiB today ... so it doesnt overwrite parts of the kernel | 23:34 |
| ogra | ah, cool | 23:34 |
| rwhitby | so I have intimate knowledge of the nslu2 flash layout, and the tricks in Apex and slugimage needed for > 1MB kernels | 23:35 |
| ogra | i'm (though coming from perl) slightly horrified by perl nowadays :) ... to much python in my life since i work on ubuntu | 23:35 |
| rwhitby | yeah, if I rewrote it today it would be in python | 23:36 |
| rwhitby | 4 years ago I didn't know enough python to write slugimage | 23:36 |
| ogra | well, it spoils you ... | 23:36 |
| rwhitby | perl was the path of least resistance for a quick hack script which is now in use for over 4 years ... | 23:37 |
| ogra | over the years i noticed that i returned to shell and C for stuff i want to be fast | 23:37 |
| ogra | and keep python usually for the things that involve guis | 23:37 |
| ogra | but i guess other ubuntu devs work differently ... i have just been burned to often during rewriting ltsp where i have to handle low specced HW a lot | 23:38 |
| ogra | and if you realize your thin clients suddenly take 5 mins to boot while they can do the same if you write everything in C within less than a minute you start to praise python less :) | 23:39 |
| rwhitby | indeed | 23:40 |
| ogra | right tool for the right task ;) | 23:40 |
| ogra | btw our kernel uses compcache by default ... so you get 48M by default on the nslu2 | 23:41 |
| * rwhitby googles compcache ... | 23:42 | |
| ogra | its a slightly insane way of providing compressed swap in ram | 23:43 |
| ogra | but it works well :) | 23:43 |
| ogra | despite the insanity of the idea | 23:43 |
| rwhitby | freaky. so what would have been in that RAM anyway is then compressed and stored in that part of the RAM as a swap space instead. | 23:46 |
| ogra | right | 23:47 |
| ogra | as i said, insane ... | 23:47 |
| ogra | but works | 23:47 |
| rwhitby | insanely devious | 23:47 |
| rwhitby | (in a good way) | 23:47 |
| ogra | you can easily add 20-50% | 23:48 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!