=== Martyn is now known as MartinB [02:23] NCommander: Great! Could we use NFS root with default uImage/uInitrd/rootfs now? [02:23] eggonlea: you have to rebuild the uInitrd for NFS mode [02:23] eggonlea: its not difficult [02:23] eggonlea: once you do that, it should just work [02:24] eggonlea: basically, you'll have to TFTP a boot.scr file that will download a uImage and uInitrd, set the command line, and boot [02:24] But why? I've looked into the initramfs which should have the ability to mount NFS already. [02:24] eggonlea: it does, but you need to flip the switch to tell it to actually try and do that ;-) [02:24] And actually I've tried that before with default initramfs. It did work. [02:25] eggonlea: hrm, interesting. Where'd you run into problems then? [02:25] the problem is in 1) /etc/fstab; 2) /etc/network/interface; and 3) /etc/init/network-manager [02:25] * NCommander got tripped up by finding out you have to set rw on the command line [02:25] 1 is easy [02:25] 2 is easy [02:25] ah [02:25] 3 needs an off switch [02:25] yes [02:26] Here's the fstab I'm using on my board [02:26] by specifying "nfsroot=xxx" and "boot=nfs" at the same time, I could use the default initramfs. [02:26] eggonlea: http://paste.ubuntu.com/410807/ [02:26] eggonlea: ooh, thats good to know, that means the documentation is out of date [02:26] and I commented out all items in fstab to use NFS. [02:26] Yes, the doc is really old. [02:27] You can force network-manager to off by specifying the interface in manual mode in/etc/interfaces/network [02:27] auto eth0 [02:27] iface eth0 inet manual [02:27] Put those lines in, and NM will ignore eth0 [02:27] Once "boot=nfs" is there, initramfs would deal with "nfsroot=xxx" correctly. [02:27] eggonlea: seems your one step ahead of me [02:27] Yes, I deal with interface eth0 as manual [02:28] hrm, that should turn NM off [02:28] If it doesn't, that's a bug [02:28] and can be worked around with apt-get remove network-manager :-) [02:28] It doesn't work until I remove NM from init. [02:28] eggonlea: is your eth device 0? [02:28] y [02:28] sometimes it likes to move to eth1, eth2, etc. [02:28] * NCommander got as high as eth37 [02:29] * NCommander was personally interested in seeing what happened when it got to eth255 ... [02:30] http://paste.ubuntu.com/410808/ [02:30] see line 25-53 of my /etc/init/mountall.conf [02:30] It's a bug. [02:30] We could follow up this. [02:31] eggonlea: if interfaces.nfs doesn't exist, it should work properly, my /etc/network/interfaces persists reboots [02:31] I'm wondering if standard Ubuntu could integrate something like that to deal with NFSROOT and normal boot smartly. :) [02:32] eggonlea: integrate in which way? [02:32] * NCommander notes that except for LTSP, we don't do a lot of network booted except for Mythbuntu [02:33] but the current initramfs DOES include NFS support already. [02:33] why not make one step forward to complete it? [02:34] eggonlea: definately something we can look at fixing although its too late for said work to land for 10.04. We can have a spec at UDS and look at improving the existing NFS support there [02:34] if ethx is configured already, just have NM leave it there (don't re-configure again). [02:34] That's fine. [02:34] eggonlea: NM is designed for normal users. We're not normal users :-/ [02:35] * eggonlea agrees. [02:36] Could NM be dynamically switched off (when initramfs detects "boot=nfs") by passing some parameter easily? [02:36] eggonlea: what do you use NFSroot for specifically? [02:37] eggonlea: hrm, it won'tbe hard to extend its init script to do extactly that. If your doing NFS root, its unlikely to want network-manager (unless you want to configure a WLAN device, but thats really pushing the usecase) [02:37] I use NFSroot the most time I use Ubuntu. It helps a lot when I transfer files between my development PC, share the powerful utilities in PC, etc. [02:38] I could even restore a broken rootfs easily by just tar and untar a backup. [02:39] I only use HD as root when installing a fresh one from livecd and release customized Ubuntu to customers (the released tarball would contains the scripts I pasted just now to support both of HD and NFS). [02:40] eggonlea: that's true. You can even do squashfs over NFS to get a clean environment every time [02:58] * DanaG wishes networkmanager wouldn't ignore usb0 ("can't determine driver") [03:43] DanaG: Please file a bug about that: it's surely fixable. [03:44] I know why it can't determine driver: /sys/class/net/usb0/device/driver symlink doesn't exist. [03:45] Then that's a kernel bug (and still fixable) :) [04:06] NCommander, I cannot even launch Chromium browser here (instead of rendering wrongly). Just install it from archive. Would try it on a latest fresh livecd. [04:06] I can [04:06] eggonlea: can't test it on Dove ATM (my PSU is MIA ATM), but I'll put it on a TODO item [04:06] eggonlea : What plaform are you testing on? [04:07] MartinB: he's on Dove ;-) [04:07] NCommander : I've got a tegra2 working here... [04:07] Dove. [04:07] thanks .. one sec [04:07] Y0, right? [04:07] MartinB: X0 [04:07] X0 [04:07] There are issues with Y0/Y1 on Lucid [04:07] Sure ... MAKE me go to the garage to get it. [04:07] sigh [04:07] as in, it doesn't work :-) [04:07] 2 mins [04:07] MartinB: where'd you get a dove board? [04:08] NCommander : Asked nicely after last UDS [04:08] MartinB: wow [04:08] NCommander : remember, I /live/ in Austin [04:08] MartinB: that's true [04:08] BRB [04:08] MartinB, so you are running Karmic on Y0? [04:09] eggonlea : No, I'm running something custom on the Y0, but I can always switch the image .. I just got the X0 out of the garage [04:09] I need to run an aptitude update and safe-upgrade, then we'll be in good shape [04:10] okay, done [04:10] what's the issue? Chromium doesn't run? [04:11] I use a SATA rootfs [04:11] Nothing happened after I clicked the icon. [04:11] no GUI launched, no segfault. [04:11] which build of chromium? [04:13] that in archive. [04:13] not PPA [04:14] * eggonlea reinstall it in case it's broken. [04:14] Get:1 http://10.38.164.98/ubuntu-ports/ lucid/universe chromium-browser-inspector 5.0.342.7~r42476-0ubuntu1 [598kB] [04:14] Get:2 http://10.38.164.98/ubuntu-ports/ lucid/universe chromium-codecs-ffmpeg 0.5+svn20100326r42726+42573+42890-0ubuntu1 [251kB] [04:14] Get:3 http://10.38.164.98/ubuntu-ports/ lucid/universe chromium-browser 5.0.342.7~r42476-0ubuntu1 [15.1MB] [04:15] 10.38.164.98 is my local mirror to ubuntu-ports [04:15] p chromium-browser - Chromium browser [04:15] got it [04:15] installed ... and I'm assuming you're using the default gnome desktop? [04:16] Netbook by default. [04:16] I've got both a server image, and a full desktop [04:16] I'll boot the desktop to check [04:19] works [04:19] no issue at all [04:20] Then, there must be something wrong with my rootfs. [04:20] *** glibc detected *** aptitude: double free or corruption (!prev): 0x002a1198 *** [04:20] hmm .. new error with aptitude install though [04:20] haven't seen that before [04:21] * eggonlea drop the current rootfs upgraded by apt-get update/upgrade and is going to install a fresh one from livecd [04:24] good idea [04:25] in fact, I should probably do the same [04:25] this one was built mid-Feb [04:25] I just hate wiping the hard disk :) [04:25] but with all these ARM devices around now, I can more easily create a rootfs [04:26] It would help if Ubuntu provides a mode to install automatically. [04:26] interesting... is the chromium ffmpeg-nonfree supposed to do h.264? [04:27] eggonlea: How do you mean? Do the dailies not work? [04:27] DanaG: Personally I don't think so because of license. But I'm not sure until I got it running here. [04:28] hmm, but I would've thought "nonfree" meant "includes things you're not supposed to install... but probably will install anyway." [04:28] persia: To install a Ubuntu to SATA from Livecd. [04:28] as in all those medibuntu things. [04:28] Alternately, we just need an ARM medibuntu. [04:29] I also just verified the chromium package works remotely [04:29] eggonlea: That should just work from the live images. How does it fail? [04:29] persia, e.g. record the install information on one machine and then apply this on all of the other machines. [04:30] eggonlea: That's installer preseeding, which should be well supported (and bugs are appreciated if it doesn't work) [04:30] * persia hunts up some docs [04:30] persia, sorry, I don't know our livecd support that already. [04:31] http://www.igotu.com/snapshot.png [04:31] So, there's a bug :) https://help.ubuntu.com/9.10/installation-guide/armel doesn't exist. https://help.ubuntu.com/9.10/installation-guide/i386/ should be mostly the same for most preseeding. [04:32] Running chromium remotely via X from the X0 to my mac :) [04:32] MartinB, looks good. I did not see any rendering error there. [04:32] works great [04:33] I'm also browsing the filesystem, as well as looking at images [04:33] MartinB, it's said rendering abnormally on Dove. [04:33] Hmmm. [04:33] worth verifying again tomorrow, but I'm not seeing an issue [04:34] * eggonlea reading... [07:06] Anbody from Compulab is here [07:11] siji: If nobody answers after a while, you might try asking the question you had intended to pose to someone from Compulab: it may be that someone else also has the answer. [07:11] persia,am really sorry [07:12] I was trying to get somebody from Compulab [07:12] earlier one mike used to be here alive [07:12] :) [07:13] I just want to knw more details abt compulab's omap based COM [07:13] specially performance point of view [07:13] with Ubuntu [07:14] No need to be sorry. I just believe in generalised questions :) I would have asked "Does anyone have any pointers to information about compulab's OMAP based COM, especially any information about performance?" [07:14] Unfortunately, I don't have any such pointers. Sorry. [07:20] persial, not only that, I posted a query to compulab last week and till havent got any reply (abt the pricing etc) [07:27] siji: If I were you, I'd be increasingly tempted by other solutions :) [07:30] :) === XorA|gone is now known as XorA === hrw|gone is now known as hrw [10:42] morning [11:11] guys: how much builds you do on your x86(-64) boxes and how much on arm boards? [11:12] all builds are done natively [11:12] we might cross-compile _occassionally_ for quick compile-testing.. [11:12] ok, so next question [11:13] how much you compile at all and how much take from repositories? [11:13] everything [11:13] I am trying to find out build power requirements [11:13] at least in lucid we recompiled the whole archive for v7 and thumb2 [11:14] No. [11:14] no ? [11:14] We recompiled *most* stuff. There's still stuff that hasn't been updated since warty. [11:14] * persia digs up automated lsits [11:14] i thought that fell under the "dont build it" policy [11:14] hrm? [11:15] i.e. did we have a policy to remove binaries for stuff that wasnt built in lucid ? [11:15] * amitk guesses that all of 'main' was native compiled? [11:15] We recompiled everything listed at http://qa.ubuntuwire.com/multidistrotools/unchanged/changed_since_karmic for lucid [11:15] We didn't recompile anything listed at http://qa.ubuntuwire.com/multidistrotools/unchanged/unchanged_since_karmic (yet) [11:15] amitk, everything was native compiled ... either in ubuntu or debian :) [11:15] No. Everything was native compiled in Ubuntu. [11:16] debian does native too [11:16] at least as far as i know [11:16] ogra: I meant all of 'main' was native (RE)compiled (for armv7) [11:16] Yes, but we don't use those results (which is part of why we don't, for example, have a working fpc today) [11:16] amitk, right [11:16] amitk: That is believed to be true, but I'm not sure anyone did confirmation. [11:17] persia, its only not true if asac made a mistake assembling the give back lists [11:17] A script was used that *tries* to identify ELF2 images to target which packages needed recompile. The script may have been buggy. [11:17] theoretically all of main should have been recompiled [11:17] Right. [11:18] * amitk guesses hrw has too-much-info now :) [11:18] plus everything that was uploaded during the cycle in universe [11:18] or synced [11:18] Inded. Everything in the first URL I posted above. [11:18] we recompiled everything thats in main and that isnt arch all [11:19] Did we? Did we recompile libx86 for armel? [11:19] persia, we tried to :P [11:19] * persia expects the answer is (slightly) more complicated [11:19] Oh, heh. 12th March. [11:19] given that it cant build on armel thats a moot point [11:19] ;) [11:20] libx86 should really be in PAS [11:20] That's kinda why I picked it. I thoguht the pointless-to-recompile ones were intentionally skipped. [11:21] Anyway, doesn't really matter. [11:21] right ;) [11:21] hrw: The real answer is that most stuff has been recompiled, and anything that can be demonstrated to have a bug that would be solved by recompilation can be trivially recompiled. [11:21] amitk: on 26th April I start Ubuntu/ARM work and try now to find out which kind of build will I use. now I do all on my desktop (+ potential VMs if needed) and sometimes run configure scripts on boards to check for strange variables. With Ubuntu/ARM I suspect more builds to be done on arm boards (beagleboard for example) but it takes much more time [11:22] We do all compilation in the repositories, but most of us test-compile before uploading. [11:22] * persia glares at asac [11:22] persia: libx86 was tried to recompile ;) [11:22] last attempt 3rd marc [11:22] i skipped stuff that was ftbfs since the beginning [11:22] 12th according to my logs, but sure. [11:22] hrw, get an XM :) [11:22] the 512M will really help [11:23] ogra: I have b7/c3/c3 here [11:23] not enough ram to be speedy [11:23] ogra: and would prefer armv7 with 1GB ram [11:23] hrw: Other commercially available stuff that can build is Efika MX and Netwalker, but there aren't kernels for those [11:23] * ogra wouldnt seriously build on a B or C beagle [11:23] * persia really approves of unified-omap kernels [11:23] persia, for 10.10 probably [11:24] ogra: Sure. Both of those are ARMv7 [11:24] ogra: thats why I do builds on my x86-64 [11:24] but have different (and sometimes conflicting) peripherials on the SoC [11:24] and we dont have any time left [11:25] hrw: Lots of packages *can't* cross-compile. Many of them can compile with qemu-system-arm or qemu-static-arm, but that's not that much faster than native (but RAM helps). [11:25] efika mx uses i.mx chip from freescale... that company and their linux support.... [11:25] persia: name one of them? [11:25] hrw: gcc [11:25] persia: I crosscompiled gcc yesterday [11:25] beyond that you need the same toolchain to be sure your binaries are sane [11:26] hrw: Not the Ubuntu package, you didn't, or you intentionally disabled the test suite. [11:26] persia: and then build vim with it on armv7a [11:27] And history aside, my Netwalker runs Ubuntu just fine (and ships with it). [11:28] hrw: Anyway, the general issue with cross-compilation in Ubuntu is that lots of packages need to run the results of the compile post-build/pre-install and so those need to run either natively or in emulation. Packages without test-suites are (wishlist) buggy. [11:28] how open and current is efika mx? [11:29] I have i.mx31 devices here and very bad kernel experience with them [11:29] From what I've heard, userspace is stock Ubuntu 9.04, the kernel source is available (but not upstream). [11:29] * persia doesn't have an Efika MX [11:29] freescale... [11:29] netwalker use which SoC? [11:29] i.MX51 [11:29] imx51 [11:30] argh [11:30] imx51 is currently our best supported arch [11:30] In terms of retail, cetainly. [11:30] at least it has the least glitches atm [11:30] ogra: with 5MB patch applied on mainline kernel? [11:30] Other SoC vendors need design wins :) [11:31] * ogra is expecting omapo to take that role in 10.10 but omap in 10.04 is still young and to late for making it sexy [11:31] *omap [11:31] ogra: :D [11:31] Especially with the unified kernel: it should almost auto-port to all sorts of retail stuff. [11:47] lool, Unsupported ioctl: cmd=0xc020660b have you seen that in arm chroots ? [11:49] ogra: Yes [11:49] hi [11:49] i've got a beagle board [11:50] should i try ubuntu on this? [11:50] lool, seems to not do any harm, do you think we could quieten it for release ? [11:50] neurre: Of course :) [11:51] neurre: Be warned that you may find the memory a bit low for the standard installs though. [11:51] how easy it is to try? [11:51] neurre: Very. Download the omap image from http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-live/current/ , dd to SD, and boot it. [11:52] dont do that on a rev B board ! [11:52] I believe it's currently buggy in a couple annoying ways (like broken USB support), but it ought boot. [11:52] it wont boot in 128M [11:52] Oh :( [11:52] i have 256MB [11:52] Do we have anything that boots on rev B? Server maybe? [11:52] server might boot [11:52] so this is rev C i suppose? [11:52] yes [11:52] hmm [11:52] the board should ahve a little sticker [11:52] next to the USB port [11:52] how do i get the thing to sd card? [11:53] use dd [11:53] There are some graphical tools too [11:53] * persia hunts a link [11:53] i need sdcard thing for my pc i suppose? [11:53] Yes. [11:53] ogra: easier check is availability of normal USB connector - Bx lacks them, Cx have [11:53] gotta go get one, then.. [11:54] ogra: or placement of hdmi connector. Cx have hdmi/svideo/audio, Ax/Bx have hdmi on same side as expansion connector [11:54] my B6 has a USB connector [11:54] ogra: EHCI one? [11:55] oh, i lied [11:55] * ogra hasnt looked at the B board for a while [11:55] I just unoacked B7 to compare [11:55] will lucid-netbook-armel+omap.img boot on beagleboard? [11:55] i always mix up the HDMI for USB [11:55] ogra: I didn't look into it [11:55] just like that, without need to do some boot time setenv stuff? [11:55] neurre: On rev C, yes. [11:55] does it include PVR drivers? [11:55] neurre: it will boot but default kernel does not have usb working yet [11:55] neurre, it will just boot, but still has lots of issues we hope to resolve before release [11:56] ok.. [11:56] neurre: If you don't like dd for some reason, https://help.ubuntu.com/community/Installation/FromImgFiles has some other options (although I don't know how well tested they are with SD targets instead of USB targets) [11:56] how about anything older? [11:56] hrw, it wont install either :) [11:56] ogra: yep [11:56] i still need to find the right installer magic ... but that requires a working kernel that lets me start the installer at all :) [11:58] neurre: Unfortunately, support for omap is very new in Ubuntu. There are some self-build instructions on elinux.org for older releases, but helping test the upcoming release helps make it great :) [11:58] ogra: You could always just add a hack in casper that added ubiquity to the session (in 10adduser) for testing purposes :) [11:59] persia, doesnt help if i hit OOM because of missing compcache :) [11:59] i can also boot with only-ubiquity to not load the desktop [12:00] (which is my fallback if compcache isnt sufficient actually) [12:00] heh, OK. === neurre is now known as neure [12:22] lool, why did we never use genext2fs for image building ? [12:22] * ogra is really thankful hrw pointed him to that [12:23] ;) [12:26] ogra: Because we didn't need it so far? no idea really [12:26] its quite awesome for creating ext2/3 images without root privileges [12:39] http://marcin.juszkiewicz.com.pl/2010/04/08/what-makes-a-good-developer-board/ [12:51] * persia reads avidly, and discovers the dual meaning of "board" :) [12:51] ? [12:52] There's a session starting in #ubuntu-classroom in about 10 minutes entitled "Q&A about the Developer Membership Board" [12:52] ah [12:53] Just an amusing coincidence, really. [12:54] ;) [13:04] hrw: Reviewing that post: why uboot only? Shouldn't OF or UEFI be also suitable? [13:07] persia: so far I used arm (armv4/v4t/v5te/v6/v7a), avr32, x86 devboards/embeddeddevices. most of them used u-boot, 2 were redboot (one migrated to u-boot later), x86 were standard bios [13:07] hrw: Did you try sheevaplug? [13:07] lool: have one under desk [13:07] lool: want to buy? [13:07] hrw: I wonder why you listed 2 serial ports and a JTAG connector on your wishlist after having used a sheevaplug [13:07] I really liked having the serial console and JTAG FTDI on the USB bus myself [13:07] hrw: I'll agree that redboot can be limiting :) I just was under the impression that OF and UEFI both were even more friendly than uboot when it came to nice flexible boot systems. [13:07] lool: sheevaplug is not devboard [13:08] lool: and usb serial/jtag on sheeva unregister from usb bus when you press reset [13:08] hrw: Still, it's a single USB cable to multiplex pretty much everything; uncluttered my desk [13:08] persia: did not used any of them [13:08] lool: agreed - I even got one or two devices move to that scheme [13:08] hrw: So you find it a problem that the JTAG has to be reconnected across reboots? [13:09] lool: but my desktop has 7 real serial ports ;D [13:09] while redboot is limiting, its very fast .... [13:09] Indeed. [13:09] Which is increasingly rare; laptops are now more numerous than desktops! [13:09] ogra: not if you have to load kernel from tftp on ep9301 cpu ;( [13:10] indeed, i meant for loading from local media [13:10] lool: I do not remember when last time I used my laptop for development... but it is so old that it has one real serial port [13:12] New laptops sometimes have real serial. [13:12] and costs extra for it [13:13] lastlog ioctl [13:13] oops [13:13] Well, maybe. I've never seen two models that were identical except for presence/absence of the port :) [13:14] And there's USB octopus serial cables with DB9/RJ48 on the ends. [13:19] amitk: You mean dmesg | grep oops [13:21] lool: no, I was doing a search in my irssi log about your discussion about ogra> lool, Unsupported ioctl: cmd=0xc020660b have you seen that in arm chroots ? [13:24] amitk: Yes, using qemu [13:24] amitk: qemu syscall emulation that is [13:25] ok [13:27] amitk: I was just kidding with the grep BTW :) [13:28] :) [13:41] yippie [13:41] my d-i fixes work, server gets further than the kbd selection [13:42] to sad it doesnt fins a target disk now :( [13:42] *find [13:43] hrm [13:43] it doesnt find ubuntu.seed .... [13:44] indeed because we build -server [13:53] heh [13:53] hmm [13:54] so do i default to ubuntu-server.seed for *all* alternate omap images now ? [13:54] we dont have a way to differentiate wrt cmdline [13:54] ? [13:55] lool, we stopped building normal alternate images and the debian-cd code defaults to file=/cdrom/preseed/ubuntu.seed atm [13:56] You mean alternate desktop images? [13:56] the server images we build use /cdrom/preseed/ubuntu-server.seed [13:56] lool, right [13:56] I don't understand why there would be any ARM specificity here though, it's just package selections and files in the image? [13:56] i wonder if we might care for desktop alternate images again at some point [13:56] Yeah, well if it's not desktop it might be netbook or something else [13:57] lool, the bootloader setup and cmdline code is arm specific [13:57] not the image [13:57] In any case, you can set the seed to the server one for server builds, but not for anything else [13:57] well, i cant [13:58] boot-armel+$subarch doesnt know its building server or desktop [13:58] it only makes a distinction if its live or alternate atm [13:58] and sets the seed based on that [13:59] and given that we dropped alternate desktop completely (since we dont support desktop on armel anymore) the seed thats getting added to the cmdline is wrong [14:03] ogra: Don't we build alternate desktop images on i386? [14:03] lool, we do [14:03] but we dont on armel targets [14:03] Why can't we use the same logic to set the seed? [14:03] heh [14:03] why didnt we ? [14:05] What I see currently: [14:05] data/lucid/preseed/ubuntu/ubuntu.seed [14:05] data/lucid/preseed/ubuntu-server/ubuntu-server.seed [14:05] data/lucid/preseed/ubuntu-server/amd64/ubuntu-server.seed [14:05] data/lucid/preseed/ubuntu-server/i386/ubuntu-server.seed [14:05] data/lucid/preseed/ubuntu-netbook/ubuntu-netbook.seed [14:05] So there's a base ubuntu-server seed and per subarch overrides if needed [14:05] not in the scripts [14:05] there's a base ubuntu seed (desktop), no override needed [14:06] i'm talking about boot-armel+$subarch here [14:06] we never added any logic to be selective based on $PROJECT [14:06] and if you build ubuntu-server it will still default to /preseed/ubuntu/ubuntu.seed [14:06] ogra: Apparently there's a simple macro you can call to get it [14:06] I suspect it's what "default_preseed" computes [14:07] Right, exactly, see tools/boot/lucid/common.sh for its code [14:07] So just source that and call default_preseed, then use $DEFAULT_PRESEED on the cmdline [14:07] ah, sweet [14:08] i thought i'd need to add a ton of "if [ "$PROJECT" = ubuntu-server ]; then" [14:08] which is why i brought it up here [14:09] (Perhaps not the best channel to discuss cdimage stuff though) [14:09] well, its debian-cd === bjf-afk is now known as bjf === hrw is now known as hrw|gone [16:07] * XorA wishes there was an ubuntu for his n810 [16:08] 9.10 ought be installable. [16:08] I know the Mer folk spent a lot of time working on that as the basis for their releases. [16:09] XorA, i had jaunty running on my n800, karmic should also work [16:10] ogra: but how would I install it? [16:10] Mer is sort of based on ubuntu, but touching apt-get leaves you with unbootable system 100% of the time [16:10] XorA: http://blog.linuxniche.net/?p=16 or similar is probably a sane place to start [16:10] well, i instealled the bootmenu stuff from maemo that enables you to run your rootfs from SD [16:11] Mer is more than sort-of based on Ubuntu. [16:11] then just created a chroot on the SD [16:11] The main reasons Mer wasn't *part* of Ubuntu for 9.10 were 1) issues with finding a way to handle the GTK+ patch, and 2) issues with the overhead of creating flavours in Ubuntu. [16:11] XorA: ping [16:11] and installed ubuntu-desktop in it (which wasnt a good idea, if you try that, take rather something like lxde :) ) [16:12] ogra: I just install lxde into Mer, now Ive got an unbootable system :-) [16:12] Hrm? That shouldn't be possible. [16:12]