[09:00] <persia> When updating the installation-guide to indicate new preseed options, am I understanding correctly that updates should be made to each language separately?
[09:12] <cjwatson> I've historically ignored the translations for practical reasons
[09:12] <persia> Heh.  That makes it easier then :)
[09:12] <cjwatson> we should be able to get some degree of po/ updates soon; I'd advise ignoring the ones that are only translated as whole-XML files
[09:12] <cjwatson> just because otherwise it'll take forever :-/
[09:12] <cjwatson> Rosetta now has installation-guide imported
[09:14] <persia> I suppose once that is complete it's worth fiddling the package to not diverge quite so much on a per-language basis.
[09:14] <persia> Where "that" means "the translations effort as a result of the rosetta import", for those not reading my mind.
[09:26] <cjwatson> I've been meaning to fix-upstream some of the places where Debian is hardcoded for a long time
[09:26] <cjwatson> needs a lot of care though :-/
[10:59] <CIA-52> ubiquity: cjwatson * r2887 ubiquity/ (3 files in 3 dirs):
[10:59] <CIA-52> ubiquity: Disable window minimise buttons if the installer is running in
[10:59] <CIA-52> ubiquity: standalone mode (LP: #249045).
[11:58] <CIA-52> oem-config: cjwatson * r537 oem-config/ (5 files in 4 dirs):
[11:58] <CIA-52> oem-config: Disable window minimise buttons when running in standalone mode at first
[11:58] <CIA-52> oem-config: boot (LP: #249045).
[12:06] <CIA-52> oem-config: cjwatson * r538 oem-config/ (debian/changelog debian/init oem-config-firstboot):
[12:06] <CIA-52> oem-config: Run oem-config in debugging mode if 'debug-oem-config' is set on the
[12:06] <CIA-52> oem-config: kernel command line.
[12:18] <MadsRH> Hi. Can anyone tell me what happened to the slideshow in the installer?
[12:19] <cjwatson> it hasn't been finished
[12:19] <cjwatson> simple as that
[12:22] <MadsRH> cjwatson -> I'm part on the artteam and I'm just wondering if it's because of missing artwork?
[12:22] <cjwatson> I don't think so, but evand would know for sure
[12:23] <cjwatson> (he's probably not up yet though)
[12:25] <CIA-52> ubiquity: cjwatson * r2888 ubiquity/bin/ubiquity: fix whitespace
[12:27] <MadsRH> cjwatson -> thanks :-D
[12:27] <baali> where does extra packages in preseed files get installed from?? in case mirrors are not mentioned
[12:29] <yannickm1> Hi.. is anyone on with familiarity of the installer system ?
[12:31] <cjwatson> baali: the default archive
[12:31] <cjwatson> yannickm1: yes
[12:31] <cjwatson> yannickm1: you kept leaving before I could answer
[12:31] <cjwatson> yannickm1: I really need to see logs
[12:31] <cjwatson> yannickm1: I'm sure I've asked you for them before
[12:32] <yannickm1> Hi.. sorry my internet at the office has been quite unstable
[12:32] <yannickm1> Ironically i'm currently at the offices of the biggest telecom company of australia LOL
[12:32] <cjwatson> as the topic mentions, you can use the mailing list instead
[12:32] <yannickm1> I did send an email :)
[12:32] <cjwatson> oh, you did :)
[12:32] <cjwatson> oops, sorry
[12:32] <yannickm1> hehe
[12:33] <baali> cjwatson, is it pool in CD/DVD in case of absence of network
[12:33] <cjwatson> I can only help you if you provide a syslog of your modified version versus an unmodified version
[12:33] <cjwatson> yannickm1: yes
[12:33] <cjwatson> baali: yes
[12:33] <cjwatson> err
[12:33] <yannickm1> cjwatson: I have the logs in my laptop, which i brought home today
[12:33] <cjwatson> yannickm1: wouldn't hurt to post the Packages file in question either
[12:34] <yannickm1> should i just send them to the mailing list ?
[12:34] <yannickm1> or post them on paste.ubuntu.com ?
[12:34] <cjwatson> yannickm1: either
[12:34] <cjwatson> mailing list is probably better
[12:35] <yannickm1> Ok, thanks, i'll post them shortly
[12:35] <cjwatson> thanks
[12:35] <baali> i am trying to install some packages like scim-tables but they are not getting done, so was wondering if it do from net only
[12:36] <yannickm1> but by the way, just my understanding of how it works (which helps solving those problems by myself lol), does the order of the Packages file matter ?
[12:37] <cjwatson> baali: for pkgsel/include, it should use the CD, although if the package is available on the network as well then it'll use that
[12:37] <cjwatson> yannickm1: it really, really shouldn't. Your problem is bizarre and suggests some other pathological condition
[12:38] <baali> cjwatson, yeah i am trying to follow https://help.ubuntu.com/community/InstallCDCustomization#Installing%20extra%20packages%20in%20your%20preseed%20file
[12:39] <baali> should i also follow part of modifying pool structure to make it work or only copying pack. will work
[12:40] <cjwatson> baali: if you're modifying the CD then you need to change the index files in dists/ as well
[12:40] <cjwatson> baali: please see https://help.ubuntu.com/community/InstallCDCustomization
[12:40] <yannickm1> cjwatson: *nods* I see. One last question. I'm creating a custom installer which setups a whole bunch of servers already configured, including authentication integration. I was thinking of giving the user the option of either just saying they want LDAP installed and configured, and provide the base dn, or alternatively to use an existing LDAP system. So in order to implement that, my impression was that the most appropriate 
[12:40] <cjwatson> yannickm1: you were cut off at "most appropriate" - IRC has a line length limit
[12:40] <baali> cjwatson, ahh great will do that thank you very much
[12:41] <yannickm1> ops
[12:41] <yannickm1> haven't used IRC in over a decade LOL
[12:41] <yannickm1> ... most appropriate way was to create a Task in TaskSel where the user can say if he wants built-in integration or not, and then based on that packages being selected of not, ask the appropriate questions / perform configuration. Do you think that's the right path, or there is a better way of doing it ?
[12:42] <cjwatson> tasksel is good for nominating tasks you want the machine to perform, but don't try to shoehorn extra questions into it
[12:42] <cjwatson> erm, if you can wait around, I'm late for meeting my wife for lunch and have to run
[12:42] <cjwatson> I can get back to you later
[12:42] <yannickm1> sure.. have a good lunch :) thanks for the help
[12:43] <baali> cjwatson, great i will try to do that
[12:43] <baali> have fun :)
[13:24] <yannickm2> cjwatson, i posted the logs and config/build files to the mailing list
[13:44] <CIA-52> debian-installer: cjwatson * r973 ubuntu/ (3 files in 2 dirs): Move mainline architectures to 2.6.27-7 kernels.
[13:46] <StevenK> Aww. No cursing in the commit log
[13:48] <cjwatson> why would I curse? it's just routine
[13:49] <StevenK> Well, it isn't as many ABI bumps as Hardy
[13:49] <StevenK> I think we're at what, 11?
[13:49] <persia> It's just been every day this week.
[13:50] <StevenK> Mmmm. -4 goes in, -5 goes in, -4 gets NBS'd, -6 goes in, -5 gets NBS'd, ...
[13:52] <cjwatson> I really don't see a reason to get upset about it
[13:52] <cjwatson> in any case cursing would be more effort than copying and pasting the commit log from the last one
[16:41] <evand> cjwatson: if you have a moment today, could you please review bug 276656 and 281100?
[16:41] <cjwatson> ok, will do
[16:41] <evand> thanks
[17:57] <persia> cjwatson, I pushed my work-in-progress on the ubiquity task for 280014 to lp:~persia/ubiquity/trunk.  From adding some debugging statements it seems that the sequence of events is the debconf queries for the username & hostname, then the check in lnfo_loop, and then the debconf query for passwd/allow-password-empty
[17:57] <persia> I'm not quite sure how that came to be the sequence, but have been trying shuffling bits about with little luck.
[17:58] <cjwatson> persia: why not just check passwd/allow-password-empty once up front?
[17:58] <persia> cjwatson, "up front"?
[17:59] <persia> (and also because I was trying to have minimal changes to coding style and practices)
[18:00] <cjwatson> oh, I see what you're doing. ok, that is up front
[18:00] <cjwatson> it's a bit odd though, that sort of get/set scheme is more for UI checkboxes
[18:00] <cjwatson> there's no point having a getter because it isn't changeable
[18:00] <cjwatson> and likewise no point preseeding it
[18:00] <cjwatson> (in usersetup.py)
[18:01] <cjwatson> if you stripped out that unnecessary stuff it would be fine
[18:01] <persia> I added the get and preseeding in my last wrap, because it didn't work without them.  Mind you, it doesn't work with them, so I'll revert to my previous patch, and just have the one try: chunk in usersetup.py
[18:02] <persia> I think the issue is in gtk_ui.py, but I know the if logic is correct because I stuffed it with print for one run, and it reported all the right values, it just was checking *before* reading from debconf, and so used the default value from base.py
[18:03] <persia> (and kde_ui.py of course, but I haven't been testing that as much)
[18:03] <cjwatson> I don't see why it doesn't work; it looks correct
[18:03] <cjwatson> certainly the default value in base.py should correspond to the default value in debconf templates, i.e. True
[18:04] <cjwatson> oh, I think I see, usersetup.prepare probably doesn't quite manage to run before info_loop, that sort of makes sense
[18:04] <persia> It seems to run about half of it, but it certainly seems racy.
[18:04] <cjwatson> persia: just do it in the block of code in base.__init__ starting with db = self.debconf_communicator()
[18:04] <cjwatson> that's what I actually meant by "up front"
[18:05] <cjwatson> you can fetch things out of debconf there before the UI starts up
[18:05] <persia> OK.  That feels like a bit of a hack, but with your blessing I'll do it that way :)
[18:05] <cjwatson> it's a bit non-modular, but it's fine for the moment
[18:05] <persia> At least it means I'm not chasing the race condition for any more days.
[18:06] <persia> It also means I get to drop the getter/setters from all the frontends, which makes it easier to maintain.
[18:07] <persia> Thanks a lot.
[20:07] <CIA-52> partman-base: cjwatson * r109 ubuntu/ (debian/changelog parted_server.c):
[20:07] <CIA-52> partman-base: Record that CHANGE_FILE_SYSTEM changes the partition table
[20:07] <CIA-52> partman-base: (LP: #149832).
[20:24] <CIA-52> tasksel: cjwatson * r1381 ubuntu/ (filter-tasks po/tasksel.pot): oops, fix skip-tasks
[20:26] <CIA-52> tasksel: cjwatson * r1382 ubuntu/tasksel.pl: might as well return early if filter-tasks outputs nothing
[20:28] <CIA-52> tasksel: cjwatson * r1383 ubuntu/debian/changelog: releasing version 2.73ubuntu11
[20:59] <CIA-52> pkgsel: cjwatson * r122 ubuntu/debian/ (changelog postinst):
[20:59] <CIA-52> pkgsel: Preseed unattended-upgrades/enable_auto_updates to true if
[20:59] <CIA-52> pkgsel: unattended-upgrades is selected.
[21:00] <CIA-52> pkgsel: cjwatson * r123 ubuntu/debian/changelog: releasing version 0.20ubuntu9
[21:03] <CIA-52> pkgsel: cjwatson * r124 ubuntu/debian/changelog: retroactively mention bug number
[22:09] <acoc> cjwatson, I see you make the LIVE_OUT location of download-live-filesystem empty before fetching the filesystem, is there a suggested way to use a local (livecd-rootfs created) squashfs
[22:09] <cjwatson> not particularly, you'll just have to hack that up
[22:10] <acoc> ok thanks
[22:10] <cjwatson> I suppose you could make find-live-filesystem output a file:/// URL
[22:10] <acoc> probably easier to just hack it up
[22:10] <cjwatson> maybe, you'd have to hack more places if you took other approaches
[22:10] <cjwatson> because you'd have to arrange for other places to look in wherever you actually keep the squashfs
[22:11] <cjwatson> although I suppose if you just build it in $LIVE_OUT to start with then you can just not call download-live-filesystem
[22:11] <cjwatson> s
[22:11] <cjwatson> up to you
[22:12] <acoc> do you remember the correct filename syntax for the squashfs file
[22:13] <acoc> most of the urls are a little dated in the script
[22:14] <cjwatson> ah yes, in fact just giving a plain filename will work
[22:14] <cjwatson>                                                 echo "/home/cjwatson/breezy-live/ubuntu/livecd.$ARCH.$ITEM"
[22:14] <cjwatson> like that
[22:14] <cjwatson> whether you want to use any variables in there depends entirely on your build process
[22:15] <acoc> alright thanks
[22:20] <cjwatson> evand: I think your latest patch in bug 276656 is fine; please go ahead and commit that
[22:20] <cjwatson> evand: and yes, send it upstream
[22:22] <cjwatson> evand: grub/uuid seems fine to me too
[22:23] <cjwatson> evand: though if anything goes wrong we'll have to guard it with an environment variable and use it only for USB
[22:24] <cjwatson> (hoping that won't be necessary though)
[22:24] <persia> cjwatson, I'm reminded.  Should the user-setup portion of 280014 go upstream?
[22:24] <cjwatson> persia: yes please
[22:25] <persia> And that's against user-setup, or debian-installer in Debian?
[22:25] <cjwatson> user-setup
[22:25] <persia> Thanks.
[22:25] <cjwatson> there may even be a bug about it already
[22:26] <cjwatson> #425859?
[22:26] <cjwatson> no
[22:26] <cjwatson> you get to file a new one I think :)
[22:30] <persia> That's OK.  I like filing bugs.
[22:35] <cjwatson> persia: is lp:~persia/ubiquity/trunk ready to merge now?
[22:36] <persia> I'm happy with it.  Does it look OK to you?
[22:37] <persia> It's the frontend-only test, which is a lot less code than the last branch.
[22:38] <cjwatson> yep, looks fine
[22:38] <cjwatson> did you uncommit or something? only one revision to merge ...
[22:38] <persia> --overwrite
[22:38] <cjwatson> aha
[22:38] <persia> I'm still a patchset user, although I have started using bzr diff to generate patches sometimes.
[22:39] <CIA-52> ubiquity: cjwatson * r2890 ubiquity/ (4 files in 2 dirs): merge from lp:~persia/ubiquity/trunk
[22:39] <cjwatson> patchset?
[22:39] <persia> Yeah.  Create a bunch of patches.  apply them together.  quilt makes this easy, although I mostly just use patch.
[22:40] <cjwatson> oh, right, I thought you were naming a tool
[22:43] <persia> No :)  I'm more manual then that.  For me, it's more flexible, but I hear that bzr shelve is supposed to do most of what I want, and it's on my list of things to learn.
[22:48] <cjwatson> http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/2006-01-09-bzr-shelve.html :-)
[22:52] <persia> heh.  Yep.