[17:55] <zyga> hey guys
[17:55] <zyga> hrw, ricardo!
[17:56] <zyga> hrw, please get me a t-shirt while the stock lasts ;-)
[18:01] <zyga> is the IRC feed on the screen?
[18:01] <wookey_> embedded is cool
[18:02] <wookey_> zyga - insult someone and see if they reply
[18:04] <wookey_> emdebian grip will get you down to 60MB or so, but that's not 'really small'
[18:05] <wookey_> this idea was emdebian's scheme in about 2001 :-)
[18:06] <wookey_> there is a very old implementations but it used CML to do the configuring, and CML is dead.
[18:07] <zyga> I have a use case
[18:07] <zyga> !
[18:07] <zyga> wookey_, ^^
[18:08] <Dr_Who> the concern I've always had with post processing or tools that put together the "minimal" fs based on a script is either way the intelligence is outside of the packaging system and away from the packages themselves,  so a package doesn't direct to the system it will be installed into what a minimum install is, so as times and packages change you have ongoing maint
[18:08] <wookey_> yeah we like this stuff :-)
[18:08] <zyga> wookey_, give me a tool that takes ubuntu archive and gives me a read-only initramfs image that I can boot and reboot and turn off the power and never corrupt the rootfs
[18:08] <zyga> hrw, hey :)
[18:08] <Dr_Who> yeah we are all fans :-)
[18:09] <zyga> how would I just do that?
[18:09] <wookey_> zyga wants it from the archve, not from a running machine. Can initramfs do that?
[18:09] <zyga> maybe what I'm asking for is a tool that does that
[18:09] <zyga> I'm sure it's doable
[18:10] <zyga> wookey_, I really want to make that from my x86 system
[18:10] <zyga> wookey_, then I want to copy that image to SD
[18:10] <zyga> wookey_, if mkinitramfs is the tool, I'll check it out
[18:11] <wookey_> The question is do we need to go smaller than what emdebian-grip does? (makes image about 2/3rds size)
[18:11] <wookey_> without just decided we want openWRT or buildroot
[18:12] <wookey_> The model people don;t want small images - they just want minimal executed instructions
[18:14] <zyga> wookey_, without a use case to drive this discussion is hard
[18:15] <wookey_> Does the router have enough RAM to run ubuntu?
[18:16] <wookey_> It's simpler.
[18:16] <wookey_> I wouldn;t say worse engineered
[18:17] <zyga> wookey_, most ISP-giveaway routers I saw have between 4 and 16MB of ram
[18:17] <wookey_> Why does someone want to run un-upgradeable ubuntu on router rather than openWRT or buildroot (or yocto/OE)?
[18:17] <wookey_> Is it really useful?
[18:18] <zyga> wookey_, more familiar maybe?
[18:18] <zyga> wookey_, +  the upgrade would be image based, not package based
[18:18] <rsalveti> yeah, we should just go with ubuntu/debian once we decided to have a working rootfs that would be able to update itself with packages
[18:18] <zyga> wookey_, but routers run mips a lot and we don't have that supported
[18:18] <wookey_> debian does :-)
[18:18] <rsalveti> if you just want to be image oriented, using ubuntu is useful but we'd have better tools/distros to do that
[18:19] <zyga> wookey_, kernels could be a problem
[18:19] <wookey_> agreed
[18:20] <zyga> and you may brick some devices with bad image (where brick I mean it's hard to recover without extra tools/hw)
[18:20] <wookey_> Emdebian baked targets exactly this area too
[18:20] <chihchun> you can still upgrade openwrt package with opkg anyway
[18:21] <wookey_> (un-upgradeable, but debian=packaged based)
[18:21] <wookey_> i.e use apt externally so all metadata is external to image
[18:21] <wookey_> still hard to get under 50MB
[18:21] <wookey_> kind of...
[18:22] <wookey_> SO yes I thinkg you can do this
[18:22] <wookey_> but I haven't actually treid myself
[18:22] <wookey_> It uses apt/dpkg
[18:22] <wookey_> but ocnfigured to keep metadata on the build machine
[18:22] <chihchun> get under 50Mb means you probably need a customized feed package which using only busybox and small libraries
[18:23] <wookey_> go look up 'emdebian baked'
[18:23] <wookey_> chihchun: exactly - you have to go to busybox instead of gnu base
[18:23] <wookey_> and debian/ubuntu don;t resally support that
[18:24] <wookey_> We did the work once in emdebian crush but it was really hard and not really maintainable
[18:24] <zyga> busybox in ubuntu would be nice
[18:24] <wookey_> yes the inirmafs idea can make small images
[18:24] <zyga> as an option
[18:24] <wookey_> but I stil don;t really see what you get from using 'ubuntu initramfs' over openWRT or buildroot
[18:25] <wookey_> because you've thrown away most of the goodness
[18:25] <zyga> wookey_, I just want to use the ubuntu archive
[18:25] <wookey_> I guess the /etc layout is more conventional
[18:25] <timchen119> I rememberd freebsd could installed their base system under 50mb without busybox when they're 2.X, not sure about now.
[18:25] <chihchun> the good feature of openwrt/openembedded is they also build dev env for you, how we do if we use initramfs approach
[18:25] <zyga> wookey_, I don't want to learn about other distros / systems
[18:26] <zyga> wookey_, just take a list of packages and get a small image that I can boot
[18:26] <wookey_> initramfs boots off busybox right?
[18:26] <zyga> wookey_, and optionally from initramfs, that I can ensure sudden power loss is not going to cripple it
[18:27] <wookey_> cross-arch installs work except for pre-inst scripts...
[18:27] <zyga> wookey_, how many packages need pre-inst scripts?
[18:27] <wookey_> which mostly don;t matter, but do for a few things (like mysql)
[18:27] <zyga> wookey_, what happens with other scripts? do they run via qemu or on first boot ?
[18:27] <wookey_> AH. OK. yes, that avoids the issue
[18:28] <wookey_> OK, so what is need to try this idea out?
[18:29] <wookey_> Does initramfs use busybox? Or GNU?
[18:31] <wookey_> emdebian-grip tools take out docs from existing packages
[18:31] <wookey_> (and languages)
[18:31] <wookey_> otherwise packages are binary identical
[18:32] <wookey_> Like hrw says that is instal-time stripping
[18:32] <wookey_> emdbeina-grip is pre-install (after package build)
[18:33] <chihchun_> initramfs uses busybox-initramfs
[18:34] <wookey_> emdebian-grip overall gets you about 1/3rd smaller on a base system
[18:34] <hrw> finally wrote name correctly
[18:35] <wookey_> how do the initramfs tools deal with running stuff on top of busybox OK?
[18:36] <wookey_> you can use dpkg from outside the image. so the data lives outside the image.
[18:38] <wookey_> gzipped apt files would be nice
[18:39] <hrw> apt files you can just remove
[18:39] <hrw> dpkg files are problem
[18:39] <wookey_> you have to download them again each time you want to update/upgrade, but yes.
[18:39] <hrw> status can be compressed but info/ directory would have to be tarred to not eat inodes
[18:39] <hrw> wookey_: you would fetch them anyway on update
[18:40] <wookey_> I still haven't understood how initramfs made from ubuntu binaries works OK with busybox, but standard image cannot use busybox.
[18:41] <wookey_> problem is usually use of unsupported options in init scripts or install scripts
[18:41] <wookey_> and mount
[18:41] <wookey_> and file
[18:41] <wookey_> and all sorts of stuff
[18:42] <wookey_> It is like the problem of using /bin/sh oinstead of bin/bash
[18:42] <wookey_> if something _really_ needs coreutils it needs to say so...
[18:43] <wookey_> 'essential' gets in your way here.
[18:44] <wookey_> because thngs don't declare their deps at the low-end
[18:44] <wookey_> indeed. I mean that you don't know whether a package need real mount or busybox mount
[18:45] <wookey_> pics are embedded
[18:50] <udsbotu> uds-grand-ballroom-g: 5 minutes left in this session!
[18:51] <udsbotu> uds-grand-ballroom-g: 4 minutes left in this session!
[18:51] <rsalveti> thanks!
[18:51] <rsalveti> lots of linaro folks
[18:51] <rsalveti> :-)
[18:51] <Dr_Who> thanks!
[18:52] <udsbotu> uds-grand-ballroom-g: 3 minutes left in this session!
[18:53] <udsbotu> uds-grand-ballroom-g: 2 minutes left in this session!
[18:54] <udsbotu> uds-grand-ballroom-g: 1 minute left in this session!
[18:55] <udsbotu> uds-grand-ballroom-g: This session has ended.
[19:19] <NMinker> Did you just say the upgrade bug for amd64 still exists on the Precise CDs?
[19:19] <bilal> NMinker: Not sure but I think that bug was squashed long ago
[19:20] <bilal> not exactly "long ago" but I mean before Precise release
[19:20] <NMinker> Alright, good to know
[19:20] <bilal> NMinker: Again, don't take my word to be 100% sure, since I could be wrong
[19:21] <bilal> since such bugs are largely hardware-specific.
[19:21] <bilal> and there's a fair chance that someone out there still has problems
[19:22] <NMinker> I had a problem when upgrade my amd64 VM (my normal one and the one I have for building ChromiumOS) from Natty to Oneiric
[19:25] <cjwatson> NMinker: we fixed several such bugs, but not necessarily yours; please file a bug with 'ubuntu-bug update-manager' if you find problems with upgrades to 12.04, so that we have a chance of fixing them by 12.04.1
[19:54] <udsbotu> uds-gb-g: 5 minutes left in this session!
[19:55] <udsbotu> uds-gb-g: 4 minutes left in this session!
[19:56] <udsbotu> uds-gb-g: 3 minutes left in this session!
[19:57] <udsbotu> uds-gb-g: 2 minutes left in this session!
[19:58] <udsbotu> uds-gb-g: 1 minute left in this session!
[19:59] <udsbotu> uds-gb-g: This session has ended.
[20:49] <sladen> works for me!
[23:56] <cjwatson> wc
[23:56] <cjwatson> (oops)