[02:30] Hi folks, I'm looking for a safe method to override the panel defaults provided by /usr/share/gconf/defaults/05_panel-default-setup.entries from the gnome-panel-data package [02:31] I know I can add another file in there 90_.entries to set any corresponding keys in 05_panel-default-setup.entries [02:32] but for example, 05_panel-default-setup.entries defines a top panel object, and I don't want a top panel object [02:33] I've had a look at the process mint use, and it seems they just script a bunch of gconf calls instead of using the standard gconf defaults dirs [02:34] I'm hoping someone has a simpler/preferred recommendation before I consider heading down that path [02:34] btw, I already posed this q in #ubuntu-devel, it was suggested I go here instead [08:53] ubiquity: evand * r3314 ubiquity/ (bin/oem-config-firstboot debian/changelog): [08:53] ubiquity: Remove code to account for last-good-boot in oem-config-firstboot as [08:53] ubiquity: the former has been abandoned. [09:33] I've documented the release process for ubiquity: https://wiki.ubuntu.com/Installer/Development/Release . I'm hoping to slowly codify our processes and ubiquity's architecture to lower the barrier for those wanting to get involved. [10:14] cleary: not something I know much about I'm afraid. The problem with a bunch of gconf calls of course is that they won't work very well for anything other than a live CD - tricky to get them applied for subsequently-created users. Have you considered simply changing the gnome-panel-data package? [10:19] cjwatson: does this look roughly okay to you (untested, I just want to make sure I'm heading in the right direction): http://pastebin.ubuntu.com/218729/ [10:21] evand: the patch itself is OK, but could you please check with people who do stuff with the CD sleeves (maybe Jane Silber) first? The reason it's just "Install" right now is because they asked for it to be short [10:22] ah, very good call [10:22] will do [10:38] does anyone have anything they want to land before I release a new ubiquity into the wild? I'll wait a few hours to be fair to those of you on other continents. === cjwatson_ is now known as cjwatson [10:50] not I [11:21] cjwatson, When I was speaking with Marion yesterday he had mentioned that he thought that the cdrom-detect udeb was bundled directly into the initrd. Do you happen to know if thats the case or not? [11:22] cody-somerville: it is the case for the cdrom initrd [11:22] it has to be [11:23] there's a MANIFEST.udebs file alongside the installer files that lets you inspect this for yourself [11:23] e.g. http://archive.ubuntu.com/ubuntu/dists/karmic/main/installer-i386/current/images/MANIFEST.udebs [11:27] debian-installer: cjwatson * r1121 ubuntu/ (10 files in 3 dirs): Move to 2.6.31-3 kernels. [11:33] cjwatson, How are udebs included in the initrd exactly? Is there just a small pool in the initrd, are they already installed, etc? If a newer version of a udeb thats included in the initrd is later found in the pool, will the new version get installed? [11:33] they're unpacked [11:34] I don't think newer versions get upgraded, but it's usually irrelevant since the opportunity to do so is generally after the older version has already been used (pretty much by definition - the purpose of the stuff in the initrd is to get far enough to be able to fetch more components) [11:34] i.e. if you're relying on this You're Doing It Wrong [11:36] cjwatson, I agree. I'm simply wondering if I can avoid rebuilding the initrd since I only really care about the newer cdrom-detect when I boot a second time but from the hard drive. [11:37] boot ... a second time? [11:37] cjwatson, recovery partition [11:38] oh right. You have to rebuild the initrd. Sorry. [11:38] no way around it [11:39] cjwatson, Could I have a copy of the hd-media initrd and boot using that for the recovery partition? [11:39] sounds like you're not clear on what the hd-media initrd does [11:39] it expects there to be an .iso file somewhere that it can mount and use [11:40] cjwatson, ah, right. [11:40] There really is no way around it [11:41] rebuilding the initrd is not that hard; you just have to build the debian-installer source package pointed at the right archives [11:41] Okay, sounds easy enough [11:42] normally it'll pick it up from /etc/apt/sources.list automatically [11:43] if that doesn't work right for some reason, you can fiddle with the stuff from build/Makefile that generates build/sources.list.udeb, or if necessary just plonk build/sources.list.udeb.local in place [11:43] debian-installer: cjwatson * r1122 ubuntu/debian/changelog: releasing version 20081029ubuntu48 [11:49] ubiquity: evand * r3315 ubiquity/ (4 files in 2 dirs): [11:49] ubiquity: Add a RELEASE marker in the desktop file to be substituted for the [11:49] ubiquity: release name and version by casper (LP: #154506). [11:50] casper: evand * r652 casper.trunk/ (debian/changelog scripts/casper-bottom/10adduser): [11:50] casper: Insert a version number in the name field for ubiquity's desktop file [11:50] casper: (LP: #154506). [12:02] casper: evand * r653 casper/debian/changelog: releasing version 1.181 [12:03] cjwatson, persia mentioned to me at AllHands that ubiquity can be started directly without booting into the live system like d-i. Is there a wikipage that talks about that feature? I can't seem to find one. [12:05] cody-somerville: https://wiki.ubuntu.com/DesktopCDOptions [12:07] cjwatson, I've already read that page but I'm wondering if theres any documentation on how you implemented only-ubiquity as for all I know only-ubiquity might still boot into the live system but just use a different session to forgo booting gnome. [12:08] debian/init in the source package [12:08] it still boots into the live system, yes [12:08] it simply doesn't start GNOME [12:08] or not all of it anyway [12:08] * cody-somerville nods. [12:09] cjwatson, One of the reasons we decided to use the alternative install was to avoid the overhead of booting into the live system. [12:11] cjwatson, Are there any benefits to using ubiquity for OEM installs or do you think d-i is the right way to go? [12:11] I don't know enough about it to answer that question; your decision AFAICT [12:11] I don't really want to be in the position of deciding that [12:11] I suspect you'll find ubiquity is faster to install even if it's slower to startup [12:14] cjwatson, We use the live-installer udeb to copy the contents of the live system to the target partition like ubiquity which I assume is the big performance gain of ubiquity over a traditional alternative install [12:14] cjwatson, Or are there other reasons why a ubiquity install would be faster? [12:15] that's the big gain [12:21] installation-guide: cjwatson * r461 ubuntu/debian/changelog: releasing version 20081208ubuntu4 [15:06] ubiquity: evand * r3316 ubiquity/ (d-i/manifest debian/changelog debian/control): [15:06] ubiquity: Automatic update of included source packages: grub-installer [15:06] ubiquity: 1.39ubuntu1, partman-auto 87ubuntu1. [15:22] ubiquity: evand * r3317 ubiquity/debian/changelog: releasing version 1.99.0 [15:38] ubiquity: cjwatson * r3318 ubiquity/debian/ (oem-config.lintian-overrides changelog oem-config.dirs rules): Use dh_lintian. === mterry_ is now known as mterry [16:58] partman-md: cjwatson * r933 mdcfg-merge/choose_partition/md/do_option: unlock units on delete [18:16] cjwatson: do you know if remix will install without the grub errors yet [18:29] evand, I just replied to Dylan's message, including a slideshow sketch [19:47] Is there an advanced menu for detecting disks. Karmic alpha 2 alternate installer doesn't let me choose the usb key as a destination medium. [19:47] s/\./\?/ [20:16] cjwatson, when you get a chance, can you look over https://code.launchpad.net/~mterry/ubiquity/translated-timezones/+merge/8698 ? In particular, the decision about whether we should MIR python-pyicu === robbiew is now known as robbiew-afk [20:35] What's the procedure for requesting a source package removal? (i.e. oem-config) [20:38] mpt: thanks! I'll take a look at it tomorrow. Very much appreciated. [23:48] re [23:48] cjwatson: thanks for the reply - I am doing this for a livecd environment [23:49] (however the plan is to eventually implement ldap support into the live env, so the multi-user thing will still be necessary) [23:50] guess forking is the only real option... I suppose it's not that big an issue on a stable package base