[04:26] <james_l> My apologies, but is anyone familiar with zubuntu here?
[04:30] <persia> james_l: No apologies needed.  Omegamoon was hanging out in here for a while some time back, but we never managed to get the Zubuntu kernel into Ubuntu.
[04:31] <persia> And only Ubuntu 9.04 can even run on that hardware: more recent versions require newer processors.
[04:31] <persia> (unless you're talking about https://launchpad.net/zubuntu , but I wouldn't expect this to be the right forum for that)
[04:31] <james_l> That's a pity (I'm trying to get a working setup of either zubuntu or angstrom, and so far I've found little out about zubuntu, so I figured I'd ask)
[04:32] <persia> Well, you *shoud* be able to install Ubuntu on your Zaurus, as long as you restrict yourself to 9.04.
[04:33] <james_l> Why is 9.04 the latest?
[04:33] <persia> Be warned that most of the default applications don't work very well at 640x480, so you may need to construct a special rootfs (the rootstock tool can help with this).
[04:33] <persia> Because the processor in those devices is old, and newer versions of Ubuntu require newer instruction sets that aren't supported.
[04:33] <persia> Same issue with the SheevaPlug, SmartQ series, etc.
[04:34] <persia> actually, I think the SmartQ series or Nokia n810 can run 9.10, but won't be able to run 10.04.
[04:34]  * persia isn't quite sure
[04:34] <persia> Note that *all* of these devices need custom kernels.
[04:35] <james_l> Yeah, I've played with that, unfortunately for every kernel I've tried, it's dying after Kernel Panic: aiiee attempted to kill init.
[04:35] <james_l> Even ones that work (minus a few things) on angstrom, so I'm kind of at a loss on them.
[04:35] <persia> If you want something that supports the newer instruction sets, the Netwalker and Efika MX seem to be widely available.  LOts of people use the BeagleBoard as well, but it's low on RAM
[04:35] <persia> (and these also all each require custom kernels).
[04:37] <persia> Hrm.  I suspect there's something special in the kernel configs.  Take a look at the kernel config for one of the Ubuntu-supplied kernels for 9.04 (-versatile might be a good candidate or the nslu2 kernel), and see if there are any obvious differences.
[04:37] <james_l> Custom kernels aren't much of a problem, I just can't seem to find the kernel command line options that it wants, does ubuntu use the standard init, or something else?
[04:37] <persia> Ubuntu uses upstart
[04:38] <james_l> Where is that stored?
[04:39] <persia> How do you mean?  Where can you download it, or where is it stored in the image?
[04:39] <james_l> Where it's stored in the image
[04:40] <james_l> ie, is it started as /sbin/init
[04:40] <persia> If you have an initrd or initramfs, it's going to be in there.  It provides /sbin/init, /sbin/initctl, /sbin/reboot, etc.
[04:40] <persia> Definitely /sbin/init
[04:41] <james_l> So it's not actually stored on the rootfs image?
[04:42] <persia> No, it's in *both* places.  If you're using initrd or initramfs, you need to have a copy there to deal with early boot, and you'll also have a copy in the rootfs to deal with keeping the system running.
[04:43] <james_l> Ok, sorry the way you mentioned it made it sound as if it was only in the initial ramdisk.
[04:45] <persia> Sorry.
[04:46] <james_l> Do you know if it requires a minimum kernel version?
[04:47] <persia> I don't offhand, but it's usually best to try to use the kernel that was released with a given release of Ubuntu.  For 9.04 that was 2.6.28
[04:48] <james_l> Thanks, I'll keep messing with it.
[04:49] <persia> Good luck.  If you get it working, please share: having a clean procedure to install Ubuntu on the Zauri would be appreciated by many.
[04:52] <james_l> Do you know where Omegamoon went? I've tried to contact him about a few things, but alas have had no response.
[04:58] <persia> I don't.  I haven't seen traffic from him in about a year in this channel.
[05:05] <james_l> Anyone else work on zubuntu?
[05:37] <james_l> persia: Any idea why when it boots, it would be killing init?
[06:54] <james_l> Huzzah, got it to not kill init.
[06:55] <james_l> On the other hand the touchscreen doesn't work
[06:55] <james_l> Ooops
[06:57] <persia> That's just a driver thing :)  Nice work.  What was the magic change?
[07:05] <james_l> Not much, I'm using the 1.0 from http://www.oesf.org/forum/index.php?showtopic=26510&st=0 on a tosa
[07:05] <james_l> tosa = SL-6000
[07:08] <james_l> I know the kernel works for TS, and I think I should have fixed that.
[07:10] <james_l> or not
[07:12] <persia> Oh, that should work.  The 2.0 stuff seems suspicious to me because I *know* that large chunks of the archive were recompiled for an instruction set not available on those devices.
[07:16] <james_l> Why was that, and does ubuntu have a build system capable of rebuilding them as armv5 (or even armv4)
[07:17] <persia> If you want ARMv4, I'll strongly recommend Debian armel.  The team there has been maintaining support for this ISA, and does a great job.
[07:18] <persia> Its potentially possible to attempt to rebuild everything that has changed since 9.04 with a toolchain that supports ARMv5, but that's 1) going to take months, and 2) likely to require a significant number of build machines and a separate archive.
[07:18] <persia> I know it *can* be done, because some people recompiled 7.04, 7.10, and 8.04 for armel even before it was properly supported.
[07:19] <james_l> I've got two SL-5500 which are strongarm (armv4 (l?)), and a SL-6000 which is armv5 (something or other)
[07:19] <james_l> months?
[07:19] <persia> But I expect that such an effort would take 4-8 months.
[07:19] <persia> Yeah, there are thousands of packages involved.
[07:19] <james_l> Why is ubuntu's build system so slow compared to others?
[07:19] <persia> I'm not sure to what you're comparing it, but I suspect the answer is that it's all native builds.
[07:19] <persia> I think our builds are faster than Debians.
[07:20] <persia> I'm not sure about other places.
[07:22] <persia> But to complete the answer to your question, ARMv7 was the initial target for Ubuntu armel, but it was impossible to get hardware at the time the project started.  As hardware has become available, each release has gotten closer to the target.  I'm hoping that we'll have enough hardware to be able to have a sane, stable, supported platform for buildds with our October release, but the path to get there has been confusing.
[07:22] <james_l> Well, I've done cross compiling with a number of things, gentoo, angstrom, and even some debian and while each is probably far smaller than ALL the packages, it hasn't been that bad. Maybe a week for any of those.
[07:23] <persia> Yeah.  Recompiling for a target rootfs is usually at most a tenth the size of recompiling the archive in terms of package count.
[07:24] <persia> But there's a couple other issues involved, as follows:
[07:24] <persia> 1) Not all packages in Ubuntu are set up for correct cross-compilation
[07:24] <persia> 2) Build-time test-suites run under cross-compilation don't tend to generate the expected results
[07:25] <persia> 3) The combination of native-built and cross-compiled binaries is poorly tested, and it's unknown whether there may be ABI changes.
[07:25] <persia> Since working around 1) involves 20,000 patches, we chose native compilation.
[07:26] <persia> And because of 3) we discourage cross-compilation because we don't know how it would affect things.
[07:26] <persia> 2) is a bit more of a happy accident, but would have likely been dealt with if we had to patch for 1)
[07:41] <ynezz> d'oh http://pastebin.ca/1806500
[07:42] <james_l> To be honest, that's a bit disappointing, considering that debian had the best CC years ago
[07:44] <persia> Well, it depends on the package.  Anything that cross-compiles well in Debian likely cross-compiles well in Ubuntu.
[07:44] <persia> But the vast majority of packages have never been tested.
[07:44] <persia> *so*, if you're just looking to do something small, you could rebootstrap with cross-compilation.
[07:44] <persia> But if you want the entirety of the archive, it's not necessarily safe.
[08:27] <lool> ynezz: I saw that double free once, but it's usually not fatal
[08:27] <lool> ynezz: Try with MALLOC_CHECK_=0
[08:34] <ynezz> ok, building again
[08:51] <ogra> lool, usually not fatal ? it usually kills apt during package install :)
[08:52] <ogra> lool, i think we should target that one for release and get doko on the case if possible
[08:57] <ogra> ynezz, hey, the screenshow in your new bug looks different from the old one :)
[08:58] <ynezz> it's same URL, isn't it? :)
[08:58] <ogra> ynezz, --serial ttyS2 .... vs console=ttyAMA0,115200 ;) you didnt build your image with the right serial device
[08:59] <ogra> rootstock needs to use --serial ttyAMA0 in this case
[08:59] <ericm> ogra, what did imx51 do to enable the serial console at boot by the way?
[09:00] <ericm> ogra, by modifying flash-kernel?
[09:00] <ogra> ericm, adding console=ttymxc0,115200 to the cmdline
[09:00] <ericm> ogra, I mean not in boot loader
[09:00] <ogra> no, we dont touch flash-kernel, the default cmdline is set durign image build
[09:00] <ericm> ogra, but the default will only be used when no cmdline is passed
[09:00] <ogra> right
[09:00] <ogra> as always
[09:01] <ericm> and u-boot will read the boot.scr scripts on disk to setup the command line, which is configured by flash-kernel
[09:01] <ynezz> ogra: ok, rebuilding with correct --serial
[09:01] <ericm> so for dove - I guess to modify flash-kernel will be a better approach
[09:01] <ogra> ericm, no, we dont want to have a console option by default in any of the images
[09:02] <ogra> we only added that for the dev release and will drop it in one of the betas
[09:02] <ogra> the cmdline on arm should not differ from the default in any other images
[09:02] <ericm> ogra, I'm going to close bug 452737
[09:02] <ogra> the boot.scr for dove is created by the image build scripts on the cdimage server
[09:02] <ubot4> ericm: Bug 452737 on http://launchpad.net/bugs/452737 is private
[09:04] <ogra> ericm, hmm, while its a bit late to enable that for lucid it might be helpful for L+1 until beta
[09:04] <ericm> ogra, ok - got you
[09:04] <ogra> ericm, but essentially it is fixed btw
[09:05] <lool> ynezz: note that you need to set MALLOC_CHECK_ in the installer script which gets copied by rootstock into the VM
[09:05] <ogra> see my last comment
[09:05] <ericm> ogra, right - if it is only wanted a way to enable that instead of every time
[09:05] <ogra> lool, i'll set that by default in my next upload(risking that we lose duplicate copunt for the bug)
[09:06] <ogra> ericm, yes, the liveimage specifically got that serialtty= option in casper to create the console
[09:06] <ogra> ericm, but it will only come up after boot for the login prompt, what i suspect Li wants on that bug is kernel bootmessages :)
[09:07] <ericm> ogra, exactly what he was talking about
[09:07] <ogra> right, so he needs to set console= on the images boot.scr ... its not that hard to do from an x86 system on the mounted USB key/SD card
[09:08] <ogra> (manually before booting)
[09:11] <ericm> ogra, see - so I'll close that one
[09:11] <ogra> yeah, but add proper comments :)
=== hrw|gone is now known as hrw
[09:13] <hrw> morning
[09:15] <ynezz> lool: something like that? http://paste.ubuntu.com/382126/
[09:16] <ogra> ynezz, yes
[09:17] <ogra> i'll add the same to rootstock as well
[09:20] <ynezz> ogra: I've rebuild that karmic image with this http://paste.ubuntu.com/382129/
[09:20] <ynezz> ogra: and it's same, that serial device had no effect on it
[09:22] <ogra> try without the --kernel-image parameter
[09:22] <ogra> thats actually only for the beagel board
[09:22] <ogra> better apt-get install linux-versatile after first boot manually :)
[09:23] <hrw> btw - rootstack under Debian/sid + DIST=lucid hangs after extracting last package
[09:23] <ogra> though you should get a login prompt
[09:23] <ogra> hrw on first stage ?
[09:24] <ogra> note that rootstock isnt really written for debian and i dont even test it in that context
[09:24] <ynezz> Kernel image must be specified
[09:24] <ogra> ynezz, no
[09:24] <ogra> not in rootstock
[09:25] <ogra> --kernel-image is an addition for the beagleboard and it extracts a kernel directly, circumventing the package system
[09:25] <ogra> (because beagle has no kernel in the archive yet)
[09:25] <ynezz> ah
[09:26] <hrw> ogra: http://hrw.pastebin.ca/1806559
[09:27] <ynezz> hm, had the same issue
[09:27] <ogra> hrw, yeah, problem with the difference of our qemu packages i think
[09:27] <ynezz> it's missing qemu-arm-static
[09:27] <ogra> debian doesnt have qemu-arm-static in any stable release ... and in testing its named differently
[09:27] <hrw> ok
[09:28] <ogra> (if it even entered testing already, not sure, might still be unstable)
[09:29] <ogra> ynezz, thats why we have packages for rootstock ;) they install the needed deps
[09:30] <ynezz> there was no qemu-arm-static in 9.04
[09:30] <ogra> right
[09:30] <ogra> thats why the 9.04 package uses a VM for that stage
[09:31] <ynezz> ah, ok
=== ogra changed the topic of #ubuntu-arm to: Ubuntu ARM Discussion & Development | https://wiki.ubuntu.com/ARM | Want to Submit a Bug? https://bugs.launchpad.net/ubuntu/+filebug | Debian ARMel TODO: http://wiki.debian.org/ArmEabiTodo | Build a rootfs from scratch: https://wiki.ubuntu.com/ARM/RootfsFromScratch | got package build issues in lucid ? see https://wiki.ubuntu.com/ARM/Thumb2 | no, we do not cross compile
[09:33]  * ogra thinks it became a FAQ so makes sense to have it in the topic :)
[09:34] <hrw> ogra: which HW is used for native builds?
[09:34] <ogra> imx51
[09:34] <hrw> cpu speed? memsize?
[09:35] <ogra> 800MHz, 512MB
[09:36] <hrw> where are times when 64MB 400MHz was good machine ;D
[09:37] <ogra> heh that was when we were young :) ... back then
[09:37] <hrw> I still have slower devices on desk
[09:38] <hrw> ogra: rootstock should have option to just generate images. as all is done in temporary dir it is harder to find where is image which was generated/used/failing
[09:38]  * ogra too
[09:39] <ogra> hrw, thats done with the --keepimage or --notarball options
[09:40] <ogra> apart from that both, the gtk GUI and the script tell you wheer the image was stored at the end of the build (the GUI also has an option to select the target dir)
[09:41] <hrw> dpkg-divert: cannot open diversions: No such file or directory
[09:41] <hrw> eggonlea: Second stage build in Virtual Machine failed !
[09:41] <hrw> eggonlea: Please see the log to see what went wrong.
[09:41] <hrw> ian_brasil: Cleaning up...
[09:41] <hrw> ~curse irssi tabcompletion
[09:41] <hrw> ian_brasil, eggonlea: sorry
[09:41] <ogra> lool, so i'm considering to change the image fs from ext2, what would you prefer, ext3 or 4 ?
[09:41] <ogra> hrw, heh
[09:41] <hrw> ext2 is fine for images
[09:41] <ogra> hrw, no, it causes fsck to kick in if the clock is off
[09:42] <ogra> ext3 should be common on all kernels nowadays
[09:42] <hrw> so go for ext3 and disable fsck by tune2fs
[09:42] <ogra> i wont screw around ion the rootfs :)
[09:43] <ogra> so no tune2fs
[09:43] <ynezz> ogra, lool: little change in error message :) http://paste.ubuntu.com/382146/
[09:43] <ogra> rootstock is supposed to build as identical installs as possible to a normal ubuntu
[09:44] <ogra> which is why the --user and --passwd options are not used by default anymore in the latest commits for example
[09:46] <ynezz> ogra: I've rebuilt that karmic image with http://paste.ubuntu.com/382148/
[09:46] <ynezz> ogra: but it's same
[09:47] <ogra> thats weird, it should work
[09:48] <ogra> do you see dmesg output on boot ? and do you see ttyAMA0 in there ?
[09:48] <ynezz> yes I see dmesg
[09:48] <ynezz> that screenshot was just the last part
[09:49] <ogra> you should be able to scroll back and there should be some message about ttyAMA0
[09:49] <ynezz> and I see ttyAMA0 there
[09:49] <ogra> very weird
[09:49] <ynezz> 1,2,3 too
[09:49] <ogra> then it should work
[09:49] <ynezz> the problem is with devtmpfs I think
[09:49] <ogra> no
[09:50] <ogra> devtmpfs is in all ubuntu kernels for lucid
[09:50] <ynezz> it get's mounted and is missing /dev/pts /dev/shm etc.
[09:50] <ogra> that should be handled by udev
[09:52]  * ogra goes for some breakfast
[09:53]  * hrw goes though rootstock and removes all removals
[09:53] <hrw> ~hail 25Mbps download
[10:11] <hrw> hmm. rootstack generated rootfs thinks that only dpkg is installed ;(
[10:25] <lool> ogra_cmpc: Please use ext4 for images of karmic+
[10:25] <lool> and if you care, ext3 for << karmic
[10:26] <persia> Why, particularly?
[10:27] <lool> ynezz: that's "interesting"
[10:27] <lool> ynezz: Do you reproduce with "ldconfig"?
[10:27] <lool> persia: are you asking me?
[10:28] <persia> lool: Yes, and specifically about your filesystem selection suggestions.
[10:28] <lool> ynezz: Yes, that might be the issue, but mountall should cope with that I think
[10:28] <persia> I don't disagree: rather I'm curious why one ought select those.
[10:28] <lool> persia: because ext4 was the default fs starting with karmic installs
[10:29] <lool> And I think all Ubuntu subprojects should be consistent here
[10:29] <lool> Just like we patched vmbuilder to do this as well for instance
[10:30] <persia> This makes lots of sense.  Thanks for the explanation.
[10:30] <ynezz> lool: how do you mean that 'ldconfig' ? mount that image and run it manualy using qemu-arm-static?
[10:30] <lool> ynezz: boot with init=/bin/sh
[10:31] <ynezz> lool: sorry, you're talking about that apt-get segfault?
[10:35] <lool> ynezz: Yes
[10:35] <lool> ynezz: I htink it's ldconfig
[10:39] <ynezz> lool: since it crashed I need to create qemu image manualy and copy the unfinished fs from /tmp/ right?
[10:39] <lool> ynezz: Sorry, I'm not sure about that part
[10:39] <lool> Probably there's a leftowver .img somewhere, unless it cleans it up on crash
[10:40] <ynezz> it cleans it
[10:41] <ynezz> ok I'll rebuild without that cleanup task and try it
[10:41]  * lool &
[10:42] <ynezz> ah it's in /tmp also, good
[10:51] <ynezz> lool: if I run /sbin/ldconfig nothing happens
[10:53] <ynezz> lool: running it with --verbose it do something
[11:08] <lool> ynezz: try apt-get install vim ... as in the log instead?
[11:08] <lool> ynezz: It would be great to have a smaller testcase than running rootstock
[11:09] <lool> I saw that once myself, but couldn't trigger it again afterwards
[11:09]  * ogra doesnt see it at all under lucid 
[11:09] <ogra> and i'm doing about ten testbuilds with rootstock per day currently
[11:10] <ogra> though most of the time only minimal with no seeds
[11:11] <ynezz> ogra: would you mind trying this 'sudo project-rootstock/rootstock --fqdn ubuntu --login ubuntu --password ubuntu --imagesize 2G --seed wget,vim,network-manager --dist lucid --serial ttyAMA0'
[11:11] <ynezz> ?
[11:11] <ynezz> it does happen to me when there's network-manager in the seed...
[11:12] <ogra> i'll try it in the next gui test later today
[11:12] <ynezz> ok, thanks
[11:12] <ynezz> without seed it's ok
[12:56] <ogra> ##################### REMINDER: mobile team meeting in #ubuntu-meeting in 5 min ######################
[15:20] <lool> ogra: Did you look at where rootstock would pull lucid kernels from?
[15:20] <ogra> i didnt change the code you know
[15:21] <lool> ogra: You might want to check 431790
[15:21] <lool> lp #431790
[15:21] <ubot4> Launchpad bug 431790 in debian-installer (Ubuntu) (and 1 other project) "debian-installer images aren't signed in the archive (affects: 1)" [Undecided,New] https://launchpad.net/bugs/431790
[15:21] <ogra> but its not active yet either
[15:22] <ogra> oh, thanks
[15:23] <ogra> looks good, what key would be used, the normal archive key ?
[15:25] <lool> I guess
[16:48] <ogra> lool, so it seems i can reproduce the issue with --seed wget,vim,network-manager here
[16:48] <ogra> i get the same segfault
[16:53] <lool> ogra: Ok great, can you investigate?
[16:53] <lool> Starting by a bug report etc.
[16:53]  * lool is about to leave for the day in 20 minutes or so
[16:55]  * ogra too
[16:55] <ogra> but i'll put it on my list
=== dmart is now known as Guest81189
=== Guest81189 is now known as dmart_
[18:43] <kiko> lrg, ping when you're around!
[19:34] <ogra> lool, the segfault does only happen with the non archive kernel ... i cant reproduce it with the archive kernel here, i guess i'll switch on the rootstock code to pull the deb with the next commit :)
[19:50] <asac> ok uploaded libv4l with workaround for arm gcc issue
[19:50] <asac> off
[19:50] <ogra> yay
[19:50]  * ogra is off too
=== dl9pf_ is now known as dl9pf
[21:14] <lool> ogra: Could you comment on whether you intend to use d-i kernel in https://bugs.launchpad.net/bugs/431790 ?
[21:15] <ubot4> Launchpad bug 431790 in debian-installer (Ubuntu) (and 1 other project) "debian-installer images aren't signed in the archive (affects: 1)" [Undecided,New]
[21:18] <lool> ~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~/c