[10:22] mpt: http://paste.ubuntu.com/550168/ - I'm sure there's an easier way, but that should tell you which theme packages aren't from maverick. [10:25] ah, broken [10:41] mpt: http://paste.ubuntu.com/550172/ - slight variation. This wont tell you if a package isn't in maverick, but it will tell you which releases have the version of the package you have installed. So look for a package that only has lucid for an option, I suppose. [10:48] usplash-theme-ubuntu | 0.27 | karmic | source, amd64, i386 [10:48] ah, that'd do it :) [10:48] That's the only item in the output that doesn't have maverick as an option [10:49] oh, no it isn't [10:49] It's just in universe after karmic [10:49] and according to Synaptic it's not installed anyway [10:49] ah, right, hm [10:50] I think the problem might be that the default theme was changed but the new default wasn't installed or the old default wasn't uninstalled [10:52] ev, http://paste.ubuntu.com/550176/ [11:31] ugh, this chroot with rapt thing on honeysuckle is proving to be quite the pain [11:31] contemplating moving that bit into a PPA [11:33] with some LP API black magic to figure out when a new version appears in the PPA [11:34] that or trying to convince IS to let me have full access to pbuilder. === mark___ is now known as mark [14:11] cjwatson: rbelem was asking me if we could have btrfs for the kubuntu-mobile image on arm. [14:12] rbelem: cjwatson's question was "Do we have a boot loader that can cope?" [14:12] ScottK, yup [14:12] cjwatson: So yes. [14:12] do you control your own kernel arguments for initial boot of the images? [14:12] or does that have to be done on the cdimage side? [14:12] ScottK, currently we boot kubuntu-mobile on n900 via uboot with meego kernel [14:13] uboot doesn't read the kernel off the filesystem? [14:13] cjwatson, i think it is builtin in kernel [14:13] whether btrfs is built into the kernel is beside the point [14:14] how does the boot loader load the kernel? [14:14] cjwatson: We're in kind of a hybrid position at the moment using a meego kernel, but we've got a linaro variant that also works in git that we're trying to switch to. [14:14] cjwatson, i mean the cmd line parameters [14:15] in that case I don't really have a good way to change the default fs for you. [14:15] mpoirer and apachelogger reported that linaro kernel is already booting [14:15] the standard way I would do that kind of thing is by passing a boot parameter when booting the installer [14:16] furthermore, partman-btrfs would have to be changed to avoid its current warning if and only if you're using a boot loader which can cope [14:16] which means I really do need you to answer my question above: how does the boot loader load the kernel? [14:16] because I need to know how to decide which boot loader is going to be used - I need to know whether this is armel-wide, or subarchitecture-specific [14:16] cjwatson, it uses a vfat boot partition, afaik [14:16] do you use a partman recipe? [14:17] cjwatson, i'm just using the same meego partition scheme [14:17] that doesn't answer my question, sorry [14:17] :-( [14:17] what installer do you use? [14:18] cjwatson, for now we are dd'ing the image to the first partition [14:18] then I don't see why I'm being asked to change anything :-) [14:18] you aren't using either of the two installers I co-maintain [14:19] I don't really understand what change I'm being asked to make ... [14:19] cjwatson, the fs from ext4 to btrfs [14:19] I don't know where that's set [14:20] (are you sure you don't mean ext3? nothing in cdimage mentions ext4 at all) [14:20] cjwatson, i think it is ext3, sorry [14:20] :-) [14:21] ah, I think I see where that is set [14:21] The preinstalled images are preinstalled into a particular file system? (sorry, I've no idea how this part of the system works) [14:21] has somebody checked that livecd-rootfs is capable of producing btrfs images? [14:21] it doesn't appear to have relevant code [14:22] so I think you guys need to write that if you want it [14:22] ScottK, i think it is, when i dd it the destination becomes ext3 [14:22] I'm happy to flip the switch in cdimage after that's done [14:22] cjwatson, cool [14:23] cjwatson, np with that :-) [14:23] you want lp:~ubuntu-core-dev/livecd-rootfs/trunk - search for IMAGEFORMAT [14:23] cjwatson, nice :-) [14:24] cjwatson, i will ping you when it is ready [14:24] thx cjwatson [14:25] sorry for my initial misunderstanding, I sometimes forget how radically different arm installation is from everything else [14:28] cjwatson, np :-) [14:28] cjwatson, another question... [14:29] cjwatson, is it possible to add a default user to the image? [14:32] dunno, I don't handle any of the software in question [14:32] ogra might know [14:43] cjwatson, oki [14:43] thanks cjwatson :-) [17:37] cjwatson: what are your thoughts on filtering out the C locale ('No localization') from the language list in ubiquity? mpt is arguing that it's not a language and thus no one would ever want to select it from that list. I'm inclined to agree. [17:37] it should be preserved in d-i but I'm OK with filtering it out of ubiquity. send any complaints about it to mpt. :-) [17:37] (it's popular for servers in particular.) [17:41] hahaha, okay [17:48] actually it was already filtered out if only-installable-languages was picked too i think [17:56] probably, but that goes further ... [18:01] cjwatson: do you recall why we don't jump straight into compiz (so nvidia and all that) on the live CD? It's been raised in the office that the install experience and the installed system experience are moving quickly apart when the installer uses metacity and the installed system uses unity. [18:03] there was no specific reason, using metacity was just easier to get going [18:03] at the time [18:03] and of course 3D drivers were often not installed [18:05] I'll file a bug (to use whatever black magic the desktop uses to gracefully fall back), since I'm already doings tons of that thanks to mpt running through a install [18:15] on the live cd you would have to build the nvidia kernel module during boot [21:24] cjwatson, how do you feel about different upstart jobs for debconf_ui and gtk/kde? it seems the stopping rc RUNLEVEL[2345] is a little bit racy still and causes oem-config's X to not always spawn before gdm gets X up first [21:25] side effect would be that the different oem-config frontend packages would have to conflict one another though [21:37] I'm quite sure it's possible to fix it given --verbose logs of what upstart is doing in each case [21:37] I don't see why different jobs should be necessary === JanC_ is now known as JanC